commit c03c1a14507dfaf8b856c2608f9ac216021fc222 Author: Linus Torvalds Date: Sun Oct 18 13:14:58 2026 -1000 Linux 7.3 commit f909e534f5e34feb2ea2701d54df63e21aa506fc Merge: 8486d357129126 ec6b083915e814 Author: Linus Torvalds Date: Sun Oct 18 09:06:02 2026 -1000 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "All fixes in drivers (or the tape ULD) and one core fix to bsg (the block ioctl equivalent of sg_io). The biggest is the race in auth updates fix in iscsi configfs, but the next biggest one is in bsg but the generic pieces of that are mostly threading reply_len" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: bsg: Pass reply_len to bsg_setup_queue() to fit UFS ARPMB replies scsi: libsas: Fix SMP IO deadlock during HA resume scsi: libiscsi: Validate the task named by a management response scsi: libiscsi: Validate the ITT reflected in a Reject PDU scsi: libiscsi: Reject a negative task index from parse_pdu_itt scsi: target: iscsi: Fix race in discovery auth updates scsi: target: Disable interrupts while holding delayed_cmd_lock scsi: st: Fix use-after-free race between st_remove() and st_open() scsi: st: Save the visited block for the partition the drive is in scsi: xen/scsifront: Check for a NULL shadow entry on a backend response commit 8486d357129126e27fb5d4e02622566bafc77035 Merge: 3d679a244e0deb b0f0c761ed3fa1 Author: Linus Torvalds Date: Sun Oct 18 08:59:16 2026 -1000 Merge tag 'spi-fix-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A small collection of driver specific fixes, all quite important if you have the relevant hardware" * tag 'spi-fix-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: spi-fsl-lpspi: directly return ret in fsl_lpspi_transfer_one() spi: spi-fsl-lpspi: pass struct fsl_lpspi_data instead of struct spi_controller if possible spi: imx: fix slab corruption from undersized DMA bounce buffers spi: tegra114: assert CS GPIO for every transfer in a message commit 3d679a244e0deb65d31cb02f1d1dcb790fcfcae2 Merge: 72732cbee632b1 d5a821f66047c2 Author: Linus Torvalds Date: Sun Oct 18 08:36:29 2026 -1000 Merge tag 'regmap-fix-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap fixes from Mark Brown: "The main thing here is a fix for lockdep warnings with MMIO regmaps that use a raw spinlock and a cache, some other lockdep fixes we'd done for the benefit of the maple tree on sleeping buses meant that we were doing allocations for those MMIO regmaps under a raw spinlock. While fixing that Michael Reeves also noticed that the debugfs files were briefly available without the cache structures backing them. There's also a fix for interrupt freeing on error in regmap-irq which had been hanging around because it's not super urgent" * tag 'regmap-fix-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: Drop map lock during cache init and exit regmap: Remove debugfs before cache teardown regmap: irq: Free the irqdomain we create commit 72732cbee632b1be22b636813c9be3df55c72bd9 Merge: a0ff06b3a7bd3a d33373c565af9c Author: Linus Torvalds Date: Sun Oct 18 08:16:56 2026 -1000 Merge tag 'i2c-fixes-7.3-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull i2c fixes from Andi Shyti: "Three independent clock management fixes, plus one for a simple reset mask blunder in the qcom-cci interrupt handler" * tag 'i2c-fixes-7.3-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: i2c: xiic: restore non-managed runtime PM to fix clk WARN flood i2c: qcom-cci: Fix HALT_ACK reset request being dropped i2c: qcom-geni: Restore the source-clock selection policy i2c: viai2c-wmt: Fix clock leak in wmt_i2c_probe() commit a0ff06b3a7bd3aa0cd99d0294e60b3ed28c9bfac Merge: 53cbbb09c1b874 7f9f2d6abc40f7 Author: Linus Torvalds Date: Sun Oct 18 08:13:58 2026 -1000 Merge tag 'firewire-fixes-7.3-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire fix from Takashi Sakamoto: "Fix a regression introduced in v6.19. It affects cancellation of the timer for split transaction timeout when handling a response. The issue is unlikely to occur in practice" * tag 'firewire-fixes-7.3-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: core: fix race condition in split transaction handling commit 53cbbb09c1b87425cd7184f81ecdb830aa3b0b87 Merge: 23a38e7bb2f9ad 41d1119e2f8577 Author: Linus Torvalds Date: Sun Oct 18 07:48:22 2026 -1000 Merge tag 'x86-core-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86/core update from Ingo Molnar: - Emit the FineIBT paranoid "cs" prefix as a byte, to work around a GNU toolchain build warning (Kees Cook) * tag 'x86-core-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/kcfi: Emit the FineIBT paranoid "cs" prefix as a byte commit 23a38e7bb2f9ad99c317a9f4e4c349054de9dfff Merge: 88328f850d956d 4505a262deae7d Author: Linus Torvalds Date: Sun Oct 18 07:38:37 2026 -1000 Merge tag 'x86-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fix from Ingo Molnar: - Fix kCFI decoding bug on CONFIG_FINEIBT=y kernels running in kCFI mode (Kees Cook) * tag 'x86-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/kcfi: Decode the kCFI check from the trap address commit 88328f850d956d267d11e2ee225ee1eaa902b8e0 Merge: 8573787061f1a5 2f93bcb3f9aaf6 Author: Linus Torvalds Date: Sun Oct 18 07:35:30 2026 -1000 Merge tag 'sched-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Ingo Molnar: - Fix __sched_setscheduler() class change race causing lost reschedules, exposed by recent RCU changes (K Prateek Nayak) - Fix s64 multiplication overflow in place_entity()'s vlag scaling code that can corrupt an entity's placement (Hui Su) * tag 'sched-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/fair: Avoid overflow in place_entity() sched/core: Call wakeup_preempt() for queued tasks during class change commit 8573787061f1a59fd73fc683c3c5cfd6bd07ea9f Merge: cf20e7f96ae688 e4c7c401c6b917 Author: Linus Torvalds Date: Sun Oct 18 07:20:03 2026 -1000 Merge tag 'perf-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf events fixes from Ingo Molnar: - Fix x86 Intel uncore driver bug on Diamond Rapids CPUs that erroneously always-cleared the invert bit (Guixiong Wei) - Fix accounting bug in the perf mlock 'gift' code causing unrelated RLIMIT_MEMLOCK functionality to fail (Lorenzo Stoakes) - Fix perf_pmu_migrate_context() bug leaving events behind during CPU hot-unplug (Haris Okanovic) - Update cgroup time when rotating multiplexed events, to fix time_running & scaled counts accounting bug (Antoine Huret) * tag 'perf-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Update cgroup time when rotating multiplexed events perf: Fix perf_pmu_migrate_context() leaving events behind perf: Track the perf mlock gift separately perf/x86/intel/uncore: Fix DMR CXL CM invert filter commit cf20e7f96ae688dd8611dd6dce8cb4a036fecc72 Merge: 32c52ec87d6245 7cbaa0f4579f48 Author: Linus Torvalds Date: Sun Oct 18 07:03:51 2026 -1000 Merge tag 'locking-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fixes from Ingo Molnar: - Fix FUT_OFF_MMSHARED futex hashing bug that can cause missed wakeups or spurious wakeups on futex-waiting tasks (Jann Horn) - Fix lockdep context tracking bug in the deferred hrtimer rearming entry code, which causes a lockdep chain leak that will eventually turn lockdep off (Mikhail Gavrilov) * tag 'locking-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: entry: Account the deferred hrtimer rearm as hardirq context for lockdep futex: Fix mm reuse handling for FUT_OFF_MMSHARED commit 7f9f2d6abc40f79e802b4063859eda343043b85c Author: Takashi Sakamoto Date: Sun Oct 18 11:55:04 2026 +0900 firewire: core: fix race condition in split transaction handling For a split transaction, either fw_core_handle_response() or split_transaction_timeout_callback() may manipulate the same transaction entry in the pending transaction list. The return value of timer_delete() is used to determine which function handles the entry. If the transaction is a split transaction and timer_delete() returns zero, the timeout callback may already be running. In this case, the response handler must leave the entry in the list for the timeout callback to remove. A previous code refactoring broke this behavior, introducing a race condition in which both functions could process the same transaction. This could lead to a use-after-free on the transaction initiator side. Fix the regression by ensuring that the response handler does not process the transaction when timer_delete() returns zero. The timeout callback is responsible for removing the entry from the pending transaction list. Fixes: fa2dc2710076 ("firewire: core: code refactoring to find and pop transaction entry") Link: https://lore.kernel.org/r/20261018025504.290598-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto commit 32c52ec87d6245ee2d12ed5dd509e40062939b50 Author: Lukas Zobernig Date: Fri Oct 16 15:04:35 2026 -1000 x86/insn-eval: Fix shadowed segment index in get_seg_reg_override_idx() Commit 45e1dccc0653 ("x86/insn: Simplify for_each_insn_prefix()") made for_each_insn_prefix() declare its own loop counter named idx. get_seg_reg_override_idx() keeps its result in a local of the same name, so the assignments in the loop body now write the loop counter: - the function always returns INAT_SEG_REG_DEFAULT, so FS and GS overrides are ignored; - a CS override sets the counter to INAT_SEG_REG_CS (2), the increment makes it 3, and prefixes.bytes[3] holds the last prefix, 0x2e again, so the loop never terminates. The UMIP emulation reaches this from the #GP handler for user space: an SGDT, SIDT or SMSW with a memory operand and a CS prefix leaves the task spinning in the kernel, never returning to user space, with a SIGKILL that is never delivered. Any user can thus tie up CPUs until reboot. With an FS or GS prefix, the emulated result is written to the wrong address. Rename the internal macro iterator variable. [ Lukas' original patch renamed the use site, I changed it to rename the iterator in the macro instead, but left Lukas' commit message and authorship - Linus ] Fixes: 45e1dccc0653 ("x86/insn: Simplify for_each_insn_prefix()") Signed-off-by: Lukas Zobernig Acked-by: Peter Zijlstra Acked-by: Borislav Petkov Signed-off-by: Linus Torvalds commit 58161ead29e50d70a317ea26b472e0c7508e69da Merge: a3bb7a0184fbf9 f91a4ac69629e1 Author: Linus Torvalds Date: Fri Oct 16 15:33:36 2026 -1000 Merge tag 'drm-fixes-2026-10-17' of https://gitlab.freedesktop.org/drm/kernel Pull drm fixes from Dave Airlie: "Last set of fixes, mostly amdgpu, some i915 and xe. I think the dma-buf revert is probably the most important: while it is technically correct the fallout from it means we shouldn't enable DMABUF_DEBUG like that yet, and fix the fallout first. Summary: MAINTAINERS update dma-buf: - revert dma-debug y on debug kernel due to msm interaction core: - fix drm_exec prelocked object interaction i915: - Fix ARL-S host bridge detection - Add sanity checks for malformed DMC firmware xe: - OA uAPI fix - shrinker fix - fix eviction of object with no bo resource - fix LRU for external objects amdgpu: - UVD fix - TTM sched entity fixes - SMU 14 fix - Userptr leak fixes - Runpm ref count fix - CRIU fix - UserQ fixes - USB4 fix - SDMA 3 fix virtio-gpu: - revert double setting blend property - reset device before deleting vqs on freeze vc4: - fix hdmi audio runtime_pm interaction amdxdna: - fix Kconfig invalid configuration rocket: - fix error path for failed init - fix core unbinding and scheduler lookup paths panthor: - fix immortalis configuration" * tag 'drm-fixes-2026-10-17' of https://gitlab.freedesktop.org/drm/kernel: (31 commits) drm/amdgpu/sdma3: Work around POLL_REGMEM / FENCE hang drm/amdgpu: keep the eviction fence until the last handle is closed drm/amd/display: Fix NULL sink dereference in USB4 bandwidth functions drm/amdgpu/userq: actually validate userq BOs drm/amdgpu: report the BO alignment in bytes in GEM_LIST_HANDLES drm/amdgpu: free the userptr ranges when a CS fails after parser_bos drm/amdgpu: don't drop the runtime PM reference twice in amdgpu_gpr drm/amdgpu: fix GEM object leak on ENOMEM in userptr ioctl drm/amd/pm: add zero fan stop temperature support on smu 14.0.2 drm/amdgpu: destroy mutex when tearing down ttm buffer entity drm/amdgpu: fix sched entity leak in ttm buffer entity init drm/amdgpu/uvd3.1: Fix checking whether UVD firmware keyselect was already set drm/panthor: fix immortalis condition drm/i915/cx0_phy: Fix ARL-S host bridge detection drm/i915/dmc: Add sanity check for DMC load address drm/i915/dmc: Harden DMC firmware payload parsing drm/exec: don't immediately add prelocked obj to array of locked objs drm/virtio: Reset device before deleting virtqueues on freeze drm/xe: Bump LRU for external objects on exec and rebind drm/xe/oa: Zero OA buffer at allocation ... commit a3bb7a0184fbf9fed14aacb9773fe9f6f2097c1b Merge: 4766082b791b51 8e8cd9a4c6dc00 Author: Linus Torvalds Date: Fri Oct 16 15:29:02 2026 -1000 Merge tag 'sound-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Here are the (hopefully) last bits for 7.3. At this time, all changes are small and device-specific ASoC fixes. Not super-urgent, but should be fairly safe to take" * tag 'sound-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ASoC: amd: yc: disable MSI on resume ASoC: nau8822: Fix the 128x oversampling switch bits ASoC: wm8978: Fix the 128x oversampling switch bits ASoC: max98371: Fix the Speaker DHT Min Volume bits ASoC: pcm3168a: Fix the DAC zero flag polarity bit ASoC: cs42l52: Fix the NG Type Switch bit ASoC: cs42l56: Put the Limiter Cushion control on the limiter register ASoC: stm32: spdifrx: fix synchronization state check ASoC: Intel: avs: Reset the stream unless it is already prepared ASoC: SOF: sof-client: Use event-handler mutex consistently ASoC: SOF: ipc4-topology: Fix shift-out-of-bounds for aggregated ALH capture commit 4766082b791b515953d87f7a24c2ea857e6c10b0 Merge: 9d586910e3d858 e8df1d194c39b7 Author: Linus Torvalds Date: Fri Oct 16 14:51:21 2026 -1000 Merge tag 'pci-v7.3-fixes-6' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fixes from Bjorn Helgaas: - Ignore Immediate Readiness on Samsung 990 PRO and 990 EVO Plus NVMe, which falsely advertise it; removal of unrelated delays in v7.2 caused post-FLR state restoration to fail, resulting in a VFIO passthrough regression (Alexander Gruhlke) -Don't treat ~0 as 'device is ready' in pci_dev_wait(); with RRS SV, a device may respond with RRS (resulting in data of 0x0001) or may not respond at all (typically resulting in ~0 data). A v6.12 change treated ~0 as 'ready', resulting in a regression with Intel and Samsung NVMe SSDs (Alexander Gruhlke) * tag 'pci-v7.3-fixes-6' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV PCI: Ignore Immediate Readiness on Samsung 990 PRO and 990 EVO Plus NVMe commit 9d586910e3d858fb25d061b7bf3f9642eca89213 Merge: e2c278bc37b522 54e1e89a97924f Author: Linus Torvalds Date: Fri Oct 16 14:37:20 2026 -1000 Merge tag 'printk-for-7.3-hotfix' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux Pull printk fixes from Petr Mladek: - Switch NBCON consoles to the emergency mode in emergency_restart() to see messages even in this shutdown code path - Postpone the start of printk kthreads after smp_init(). It prevents boot stalls on some HW - Typo fix in a previous hot-fix patch * tag 'printk-for-7.3-hotfix' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux: printk: Postpone kthread startup printk: fix kernel-doc name for nbcon_write_context_is_braille nbcon/reboot: Switch NBCON consoles into the emergency mode in emergency_restart() commit e2c278bc37b52222e53d5f88971ffcfacd6c97be Merge: 2d2fe9fd50b57f c47a7b11bcb3d4 Author: Linus Torvalds Date: Fri Oct 16 14:27:22 2026 -1000 Merge tag 'trace-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Fix NULL dereference when copying histogram field variable If event_hist_trigger_parse() creates an action that uses one of pseudo fields for its keys, the hist_data field element will have a NULL for its field member. When looking to match that key, the lookup uses key_field->field->name which will dereference a NULL pointer. Instead use the helper function that handles such cases: expr_field_str(). - Take the trace_types_lock when dropping the buffer_meta reference The tracing_buffer_meta_open() error return drops the trace_array reference with __trace_array_put() instead of trace_array_put() where the former doesn't take the lock and the latter does. - Fix NULL pointer dereference when reading per_cpu/cpuN/buffer_meta These files are created for every possible CPU. But it only contains data for CPUs that have come online. If one is read for a CPU that hasn't come online yet, it triggers a NULL pointer dereference. Have reading of CPUs that have not come on line yet return -ENODEV. - Fix an out-of-bounds shift in the log2 histogram modifier Histograms can take a log2 modifier to have the buckets defined by log2 increments. If a shift is greater than ULONG_MAX or above 2^63, the key falls into a lower order bucket. Use order_base_2() instead of "ilog2(n - 1) + 1" to have all overflowed keys go into the top bucket. - Fix the persistent ring buffer rb_meta_subbuf_idx() accounting The algorithm for finding the index of a sub-buffer in a persistent ring buffer buffer did not take into account the meta data at the beginning of the buffer causing the wrong index to be returned. As rb_subbufs_from_meta() does the proper accounting to find the first sub-buffer, use that function instead of repeating the logic (incorrectly) and make the calculations based off of that. - Fix the symbol name checks for the remote buffer code The remote ring buffer has a build time check to make sure its not using any code that will not be in the hypervisor. For various architectures, there has been false positive reports from this checker. Fix them. - Fix false warning in ring_buffer_map_get_reader() There is a WARN_ON() after rb_get_reader_page() if no reader is returned. But there are legitimate cases where this can happen. Remove the WARN_ON() and also a check that covers one of the legitimate cases that tries to exit out early. There's no need for the check if it just simply allows the return of NULL from rb_get_reader_page(). - Fix the ignored return value from resize_buffer_duplicate_size() Some clean up of the code in tracing_snapshot_write() removed checking the return value of resize_buffer_duplicate_size() and if that failed it would not be detected. - Fix the histogram timestamps for buffered events The histogram timestamps are taken from the events that are recorded. It currently reads ring_buffer_event_time_stamp() but if the event is buffered it does not read it properly. Use tracing_event_time_stamp() which handles both buffered and normal events. - Do not initialize tracefs if tracing is disabled at boot If tracing fails to allocate or some other error is detected, tracing_disabled is set. Do not initialize tracefs in this case as it may expect data to be initialized but is not. - Free eventfs inode after an RCU grace period Currently eventfs_inodes are freed after a SRCU grace period as the iterations in the code use SRCU. There are locations that the inode may still be accessed from the VFS that uses RCU which does not have the same synchronization as SRCU. Add an RCU wait before free eventfs inodes. - Do not fail persistent and remote buffers under memory pressure As persistent and remote buffers have their own pre-allocated memory, there's no reason to check how much memory is available before created them. By checking the memory pressure, these buffers may fail to be created even though their memory is already present. - Account for subbuffer size when checking how much memory is available Before allocating a ring buffer, the size is checked against the current memory pressure of the system. But it assumes every sub-buffer is of page size. This is no longer the case. Use the actual sub-buffer size when calculating how much memory will be used. - Reject non-stack fields for synthetic stacktrace fields Stack traces are special fields and the checks currently do not do enough to make sure that the fields being processed as stack traces are indeed stack traces. Update the logic to properly detect what is or is not a stack trace. - Fix a crash in print_graph_function_event() When a tracer does not define static or default flags the tr->current_trace_flags is set to NULL. If the ring buffer is not cleared when switching tracers, the previous tracers events could be read. The function_graph entries will dereference the tr->current_trace_flags and cause a crash. Set the tr->current_trace_flags to a empty set of flags to prevent it from being NULL. - Separate tracing filter predicate count from allocation The amount allocated for the predicate program is the number of predicates defined plus two for adding "true" and "false" at the end. The nr_preds is incremented by two to accommodate the booleans but is then used as the limit check for number of predicates. This is incorrect as it is now two higher than what is expected. Use a separate variable for the size of the predicate array. - Fix the filter operator stack check The operator stack increments the pointer and then writes the content onto the stack. The check for overflow compared the current pointer to see if it was greater than the stack size before doing so. This is an off by 2 error as the write will be at the size - 1 and the compare is done before the increment. Adjust the check accordingly. * tag 'trace-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing: Check operator stack capacity before pushing tracing: Keep the predicate limit separate from program capacity tracing: Fix crash in print_graph_function_event() tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields ring-buffer: Use subbuf_order in available memory estimation ring-buffer: Skip si_mem_available() for persistent and remote buffers eventfs: Free the eventfs_inode after an rcu grace period too tracing: Do not initialize tracefs work if tracing is disabled tracing: Fix hist trigger timestamps for buffered events tracing: Fix ignored return value of resize_buffer_duplicate_size() ring-buffer: Fix false warning in ring_buffer_map_get_reader() tracing: Fix simple_ring_buffer undef check on sparc64 tracing: Fix simple_ring_buffer undef check on parisc tracing: Fix empty symbol names in simple_ring_buffer undef check ring-buffer: Fix the sub-buffer array base in rb_meta_subbuf_idx() tracing: Fix the shift out of bounds in the log2 histogram modifier ring-buffer: Do not show buffer_meta for CPUs without a buffer tracing: Take trace_types_lock when dropping the buffer_meta reference tracing: Fix NULL dereference when copying keys for a field variable commit 2d2fe9fd50b57fc2563f4b7bd2fe83906f79c81a Merge: 70dd4ee72eb2d5 66c658033d842b Author: Linus Torvalds Date: Fri Oct 16 14:25:25 2026 -1000 Merge tag 'probes-fixes-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull probes fix from Masami Hiramatsu: - error out if BTF is required but unavailable Fix to return an error instead of NULL if BTF is not available when user specify '$args*' meta fetch argument for probe events. * tag 'probes-fixes-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing: probes: error if BTF is required but unavailable commit e8df1d194c39b7a5159d570798941851f70a8668 Author: Alexander Gruhlke Date: Sun Oct 11 21:01:45 2026 +0200 PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV With RRS Software Visibility, pci_dev_wait() considers a device ready as soon as reading the Vendor ID doesn't return the RRS value. Devices aren't required to respond with RRS while they aren't ready, so the read may return ~0 and pci_dev_wait() stops waiting too early. This was seen with Intel [8086:0a54] and Samsung [144d:a80c] NVMe SSDs. Also wait while the Vendor ID reads ~0. A VF's Vendor ID always reads ~0, so check its Command register instead, as is done without RRS SV. Fixes: d591f6804e7e ("PCI: Wait for device readiness with Configuration RRS") Link: https://lore.kernel.org/r/20250611101442.387378-1-hui.wang@canonical.com Suggested-by: Lukas Wunner Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Alexander Gruhlke Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Link: https://patch.msgid.link/20261011190145.23621-3-gruhlke@mailbox.org commit 0f8b5d90d179b9639be1dbeff59d6d971e6b0527 Author: Alexander Gruhlke Date: Sun Oct 11 21:01:44 2026 +0200 PCI: Ignore Immediate Readiness on Samsung 990 PRO and 990 EVO Plus NVMe The Samsung 990 PRO [144d:a80c] advertises Immediate Readiness, so pcie_flr() doesn't wait after FLR, but the drive returns ~0 for up to 7 ms. Since commit 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring BARs"), the config restore after FLR is lost, which breaks VFIO passthrough of the drive. Firmware 8B2QJXD7 responds right after FLR, but older firmware such as 1B2QJXD7 doesn't, and the firmware version isn't visible here. [bhelgaas: The Samsung 990 EVO Plus [144d:a80d] with 2B2QKXG7 firmware seems to have the same problem.] Ignore Immediate Readiness on these devices, so pcie_flr() waits. Fixes: 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring BARs") Link: https://bbs.archlinux.org/viewtopic.php?id=314833 Link: https://bbs.archlinux.org/viewtopic.php?pid=2312085#p2312085 Suggested-by: Lukas Wunner Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Alexander Gruhlke [bhelgaas: squashed in Samsung 990 EVO Plus from https://lore.kernel.org/all/20261016102042.641801-1-gruhlke@mailbox.org] Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Link: https://patch.msgid.link/20261011190145.23621-2-gruhlke@mailbox.org Link: https://patch.msgid.link/20261016102042.641801-1-gruhlke@mailbox.org commit 54e1e89a97924f5f1b57d93350e27993468300b0 Merge: 22430ae5d90ab2 5f339c46f15318 Author: Petr Mladek Date: Fri Oct 16 17:38:25 2026 +0200 Merge branch 'for-7.3-hotfix' into for-linus commit 70dd4ee72eb2d5793c62e71c14e3aba78e5a4e56 Merge: 7b441fe5a6c645 c5895eadf28711 Author: Linus Torvalds Date: Fri Oct 16 08:21:06 2026 -0700 Merge tag 'pinctrl-v7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - AMD: Clear S4 wake bits when firmware has _AEI, this is important for some AMD systems. - Do not accumulate sunxi npins across probe() attempts with deferred probe. (desc->npins just went ++ and ++...) - Qualcomm patch galore: split QUP functions on the Nord pin controller, fix an OF module alias on IPQ5210 so the module modprobes, fix two groups on the IPQ5018, make direction changes exclusive on the SPMI-GPIO, and fix the interrupt target width on four different SoCs. * tag 'pinctrl-v7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: sunxi: dt: do not accumulate npins across probe attempts pinctrl: amd: Clear S4 wake bits when firmware has _AEI pinctrl: qcom: ipq5018: replace gcc_plltest with pwm2 on gpio12 pinctrl: qcom: ipq5018: update PWM groups and corresponding pin functions pinctrl: qcom: spmi-gpio: make direction changes exclusive pinctrl: qcom: ipq5018: add missing pwm3 function on gpio13 pinctrl: qcom: qcs8300: Fix intr_target_width pinctrl: qcom: maili: Fix intr_target_width pinctrl: qcom: hawi: Fix intr_target_width pinctrl: qcom: nord: fix GPIO interrupt target width pinctrl: qcom: ipq5210: Publish the OF module alias pinctrl: qcom: nord: Split QUP1 SE2/SE3 into lane-pair functions commit 7b441fe5a6c6455cb91fdf8330abc752e7e247df Merge: 586a28a179864f dbd674ccf30f66 Author: Linus Torvalds Date: Fri Oct 16 08:17:30 2026 -0700 Merge tag 'pwrseq-fixes-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull power sequencing fix from Bartosz Golaszewski: - with the PCIe code reworked to power the endpoint via pwrctl before it starts the link training, we can now remove the workaround for WLAN power which instead started causing an issue with endpoint enumeration * tag 'pwrseq-fixes-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: qcom-wcn: power off WLAN at probe commit 586a28a179864ffe425e31087584b2ba07385fe0 Merge: 1dbb7422053fa0 205cccd06e5456 Author: Linus Torvalds Date: Fri Oct 16 08:14:37 2026 -0700 Merge tag 'gpio-fixes-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - gracefully handle unsupported fwnode-only, no-device GPIO lookup for shared pins - mark the GPIO controller as sleeping in gpio-nct6694 - fix a GPIO device reference leak in kunit tests - fix memory leak in error path in gpiod_set_array_value_complex() - fix races in GPIO controller and its associated irqchip setup in gpio-mxc - use atomic bitops where races can occur in gpio-mxc - fix build failure in gpio tools * tag 'gpio-fixes-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: mxc: fix race between gpiochip registration and IRQ domain setup gpio: mxc: fix wakeup_pads bit operations gpio: mxc: fix both_edges bit operations gpio: mxc: fix race between chained IRQ handler install and probe completion gpiolib: fix memory leak in gpiod_set_array_value_complex() on error paths gpio: kunit: fix GPIO device reference leak with __free() gpio: shared: gracefully handle no-device lookup of shared GPIOs gpio: shared: fix use-after-free bug when adding shared proxies tools: gpio: fix building from the top level with O= gpio: nct6694: Mark the GPIO controller as sleeping commit 5f339c46f153184570f16c8e789c9709b14cbe8b Author: John Ogness Date: Fri Oct 16 11:00:34 2026 +0206 printk: Postpone kthread startup There have been various bug reports related to SMP systems hanging on boot. The reports vary but seem to have some overlap with regard to missed IPI's during SMP setup. The reports also show that reverting NBCON console usage allows the bugs to disappear. The NBCON kthreads for console printing are started very early during boot using early_initcall(). Since these kthreads are asynchronously enabling/disabling interrupts during early boot, they may be interfering with early SMP setup on some hardware platforms. Starting the console printing kthreads later has shown to avoid the hanging on systems that could previously reproduce the issue. Postpone kthread starting until after all arch initcalls have completed. Reported-by: Derek Barbosa Closes: https://lore.kernel.org/linux-rt-users/arPmYPbFLf2EldIl@debarbos-thinkpadt14gen5.rmtusma.csb Fixes: 76f258bf3f2a ("printk: nbcon: Introduce printer kthreads") Signed-off-by: John Ogness Tested-by: Derek Barbosa Link: https://patch.msgid.link/20261016085441.857695-1-john.ogness@linutronix.de Signed-off-by: Petr Mladek commit 1dbb7422053fa0f4fb5f9acc3931617fc0091939 Merge: 519abe8d9acba7 214897acc8c2e5 Author: Linus Torvalds Date: Fri Oct 16 07:53:16 2026 -0700 Merge tag 'vfs-7.3-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: - Fix a range of use-after-frees during rcu pathwalk caused by non-rcu frees. Whatever ->permission(), ->d_revalidate(), ->get_link(), ->d_hash() and ->d_compare() read in rcu mode has to be freed after a grace period. umount(2) hides most of it because namespace_unlock() waits for one, but a chdir() out of a lazily unmounted directory or the close() of the last file on it drops the last reference without. * ext4_get_link() reads the sbi and the extent status counters for a symlink stored in a data block. Both are freed after a grace period now. * The unicode map of casefolded ext4, f2fs and tmpfs was freed under generic_ci_d_hash() and generic_ci_d_compare(). * ntfs3 with nocase freed its sbi and mount options under its dentry hash and compare. A remount freed the old options right away too. * eventfs freed an eventfs_inode after an SRCU grace period only while tracefs_d_revalidate() reads it under rcu_read_lock(). * afs and 9p are only saved by the grace period their private bdi gets in bdi_unregister(). They stop depending on it. * create_ipc_ns() leaked the mqueue mount and its superblock on a late failure. A long-term mount needs kern_unmount(). - Don't let idle threads pin the initramfs. The idle threads of the secondary cpus are forked from PID 1 with a private copy of its fs_struct, aren't on the task list so pivot_root() never moves them and never exit. So the initramfs stayed pinned forever on every machine with more than one cpu, 70 to 150 MB in the reports. They share init_fs now like init_task does. - A mount that copy_tree() leaves out can't take over a lock. copy_tree() drops mounts of mount namespace files from the copies it makes for unshare(CLONE_NEWNS) and propagation without looking at MNT_LOCKED. So root in a user namespace could bind a child's /proc//ns/mnt beneath a locked cover, let it take the lock over, unshare(CLONE_NEWNS) and read the file. copy_tree() refuses with EPERM now and the move beneath a locked mount is refused up front. - Revert "namei: don't reveal overmounted entries in refwalk" from the rc7 fixes. The bug class is bigger than that patch. - namei: lookup_fast_for_open() checked ->d_inode while traverse_mounts() checks the type in d_flags, which is set second, so a refwalk racing the instantiation could fail an O_CREAT open with ENOENT. Use d_is_negative() in both places. - Drop the smp_mb()s in mntput_no_expire_slowpath() and do_umount() that mnt_get_count()'s own barrier made redundant. - fsnotify: a mark added while fsnotify_destroy_marks() walks the connector could be missed and the connector detached, so an fdinfo read called igrab(NULL). New marks are refused during teardown. - pipe: a failed second fasync enable on an O_RDWR FIFO removed the existing reader entry and cleared FASYNC while the writer entry stayed, a use-after-free in send_sigio() later. - watch_queue: post_one_notification() could see nr_notes before the note pool behind it and dereference a NULL array. An unprivileged user can trigger that with a key watch. Publish nr_notes last. - pid_namespace: zap_pid_ns_processes() waits without bound for a tracer outside the namespace to reap its zombies and neither wait was freezable, so every suspend attempt failed. - exit: is_child_subreaper and has_child_subreaper shared a word with other bitfields written without a common lock, so racing prctl()s lost a bit. They are separate bools now. - autofs: a notification write that failed on a pipe the daemon had already replaced put the superblock into catatonic mode again and closed the replacement. Only do that for the current pipe. - ovl: reject a lowerdir ending with an unescaped backslash with EINVAL instead of a confusing ENOENT later. - ocfs2/dlm: take dlm_reco_state_lock when the debugfs state file walks the recovery participant list. - samples/pidfd: fix the userprogs typo that kept pidfd-metadata from being built. * tag 'vfs-7.3-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (24 commits) Revert "namei: don't reveal overmounted entries in refwalk" selftests/filesystems: test that a mntns file can't take over a lock fs: let idle threads share init_fs namespace: a mount that copy_tree() leaves out can't take over a lock namei: test for a negative dentry the way traverse_mounts() does fs: pass flags to copy_fs() ovl: reject lowerdir ending with unescaped backslash fsnotify: prevent mark additions during connector teardown pid_namespace: make zap_pid_ns_processes() freezable fs: drop the smp_mb()s that mnt_get_count() made redundant autofs: ignore notification errors from a replaced pipe ntfs3: free replaced mount options after a grace period ntfs3: free the sbi after a grace period unicode: free the map after a grace period ipc: drop the mqueue mount with kern_unmount() on setup failure eventfs: free the eventfs_inode after an rcu grace period too 9p: free the session after a grace period watch_queue: Fix note pool publication race in watch_queue_set_size() afs: free the super info after a grace period pipe: preserve existing fasync readers on writer setup failure ... commit 519abe8d9acba75678a2bc91a2f6c855b9d1c54e Author: Darrick J. Wong Date: Thu Oct 15 22:24:05 2026 -0700 MAINTAINERS: remove myself After 14 years at Oracle and 23 years working on Linux, I've decided to step back for a while. Signed-off-by: "Darrick J. Wong" Signed-off-by: Linus Torvalds commit 90201351a862182bdabfc1ad1c97b1e1b6ed5931 Author: Toke Høiland-Jørgensen Date: Fri Oct 16 10:50:11 2026 +0200 wifi: atk9k: Revert "wifi: ath9k: reject short WMI command responses" This reverts commit 93ce8ea70451e800601bc9444aa33043de15d67b. Mehmet reported that the offending commit breaks his AR9271 USB adapter which uses zero-length replies to commands that don't return a value. Revert the whole thing to restore the functionality. Cc: stable@vger.kernel.org # the offending commit is in 6.12.113 Reported-by: Mehmet Fide Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Linus Torvalds commit 214897acc8c2e5d6b63189d23ccaed6fa2af45a9 Author: Christian Brauner Date: Fri Oct 16 10:50:57 2026 +0200 Revert "namei: don't reveal overmounted entries in refwalk" This reverts commit 8189ab688f5a2c745dc90b63374da02f213d6994. This bug class is bigger than can be fixed with this simple patch. Back out of it and give us some time to fix this properly. Signed-off-by: Christian Brauner commit f91a4ac69629e1479745e82100863157e6967ec0 Merge: 7669e0b1b92a82 752480ad62964e Author: Dave Airlie Date: Fri Oct 16 18:37:20 2026 +1000 Merge tag 'amd-drm-fixes-7.3-2026-10-15' of https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.3-2026-10-15: amdgpu: - UVD fix - TTM sched entity fixes - SMU 14 fix - Userptr leak fixes - Runpm ref count fix - CRIU fix - UserQ fixes - USB4 fix - SDMA 3 fix Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patch.msgid.link/20261015221002.1728931-1-alexander.deucher@amd.com commit 7669e0b1b92a8296a3dace4f2cc49fec0dd83fd3 Merge: 2963ea57b061c4 d2ce8fcd778ee6 Author: Dave Airlie Date: Fri Oct 16 18:36:52 2026 +1000 Merge tag 'drm-xe-fixes-2026-10-15' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes An OA uAPI fix by zeroing OA buffer at allocation, and other 3 small fixes around eviction and shrinker. Signed-off-by: Dave Airlie From: Rodrigo Vivi Link: https://patch.msgid.link/atDNMV-Aohu6s0gE@intel.com commit e4c7c401c6b9174c0c893084fdaa6a84bd2520d7 Author: Antoine Huret Date: Thu Oct 15 14:55:56 2026 +0200 perf: Update cgroup time when rotating multiplexed events Since commit bd2756811766 ("perf: Rewrite core context handling"), perf_rotate_context() only updates the context time before scheduling out the flexible events. It no longer updates the cgroup time, which ctx_sched_out() used to do. Cgroup events take their times from the per-cpu cgroup clock, so between two cgroup switches the rotations see a frozen clock. The events rotated out lose the running time they accumulated, and the next update, usually a read, credits the whole interval to the events that happen to be on the PMU at that moment. As a result, the time_running of multiplexed cgroup events is wrong, and so are their scaled counts, as long as no other cgroup runs on the CPU, e.g. a busy job alone on its CPUs. Counting cycles over one second of a busy loop in a cgroup gives from half to several times the max frequency of the CPU. Update the cgroup time before rotating the CPU context, as was done before the rewrite. Fixes: bd2756811766 ("perf: Rewrite core context handling") Closes: https://lore.kernel.org/r/PR3PR07MB69223331EED5BEBE150375B7849C2@PR3PR07MB6922.eurprd07.prod.outlook.com/ Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Antoine Huret Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261015-perf-cgroup-rotation-time-v1-1-93e177dfee5d@bull.com commit e76b36b4be7160eaa14b416681e548b125702395 Author: Haris Okanovic Date: Tue Oct 13 13:56:00 2026 -0500 perf: Fix perf_pmu_migrate_context() leaving events behind __perf_pmu_remove() walks the group leaders of a CPU and PMU with perf_event_groups_for_cpu_pmu(), removing each one as it goes. perf_remove_from_context() takes the leader out of the groups rbtree, after which rb_next() on that node returns NULL, prematurely ending the walk. Other groups stay behind in the source context. On CPU hotplug, they are then torn down with the dying CPU. They keep running until teardown, while the PMU's interrupt and migrated events are on a new CPU, which drivers rely on never happening. Walk ctx->event_list instead and pick out the PMU's events by their pmu_ctx. Fixes: bd2756811766 ("perf: Rewrite core context handling") Signed-off-by: Haris Okanovic Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20261013185603.1347265-2-harisokn@amazon.com commit 78436f3882fb8d848c823bf8cf754988202c5ca5 Author: Lorenzo Stoakes (ARM) Date: Sat Oct 3 17:29:07 2026 +0100 perf: Track the perf mlock gift separately The locked_vm field in struct user_struct was originally introduced by commit 789f90fcf6b0 ("perf_counter: per user mlock gift") to provide an mlock-like budget for perf measured against mm->pinned_vm (since 2011). perf grants each user a 'gift' of perf_event_mlock_kb * online CPUs of buffer pages which is charged to user->locked_vm without any RLIMIT_MEMLOCK check. Only pages beyond the gift are checked against RLIMIT_MEMLOCK, per-mm, via mm->pinned_vm, which makes it different from the standard mlock() check, which is per-mm and made against RLIMIT_MEMLOCK. However, since this was introduced, a number of other components have utilised this field where a shared resource needed to be limited against RLIMIT_MEMLOCK. The other users are currently MSG_ZEROCOPY, io_uring, AF_XDP, iommufd, s390 KVM zPCI and most recently, secretmem in commit 97d34aa65c29 ("mm/secretmem: properly account locked pages"). This field is shared between all of these, but because the gift is not checked against RLIMIT_MEMLOCK, user->locked_vm alone can exceed it - 16 CPUs * 516 KiB is already more than the default 8 MiB - after which every other user of the field fails unconditionally. This was reported by a user who saw secretmem failing while running a simultaneous perf record. Resolve the issue by simply giving perf its own field separate from the rest. BPF used user->locked_vm up until commit 80ee81e0403c ("bpf: Eliminate rlimit-based memory accounting infra for bpf maps") which landed in 5.11. Thus also eliminate the now-defunct ifdef for CONFIG_BPF_SYSCALL for user->locked_vm. This issue exists between all of the components which use user->locked_vm and perf, however secretmem is the first user who has caused a report over many years and has been backported, so target the fix at that. Fixes: 97d34aa65c29 ("mm/secretmem: properly account locked pages") Closes: https://lore.kernel.org/20261002175651.811343-1-ameer.hamza@truenas.com Reported-by: Ameer Hamza Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261003-perf-locked-vm-fix-v1-1-d214dcaf0d76@kernel.org commit 2f93bcb3f9aaf6ceee1aec0a97d4fe386d48e781 Author: Hui Su Date: Mon Sep 28 21:47:54 2026 +0900 sched/fair: Avoid overflow in place_entity() place_entity() inflates an entity's virtual lag with lag * (load + weight) / load Commit 4823725d9d1d ("sched/fair: Increase weight bits for avg_vruntime") replaced the scaled-down weights used in this calculation with avg_vruntime_weight(), removing the arithmetic headroom provided by scale_load_down(). The multiplication can overflow s64 before the division even when the final quotient is representable. A task's hierarchical effective weight can be as small as 2 after avg_vruntime_weight() scaling under group scheduling, while entity_lag() bounds |vlag| by calc_delta_fair(cfs_rq_max_slice(cfs_rq) + TICK_NSEC, se) For example, with HZ=1000, NICE_0_LOAD=1048576, and the minimum scaled hierarchical weight scale_load(2)=2048, this bound is 891289600. With 114 maximum-weight entities, the runqueue load is 10361604096. The intermediate product is: 891289600 * (10361604096 + 2) = 9235189971864780800 > S64_MAX The signed overflow corrupts the entity's placement. Rewrite lag * (load + weight) / load as lag + lag * weight / load The two expressions are equivalent, but the latter avoids multiplying the virtual lag by the total runqueue weight. entity_lag() bounds vlag against the entity's effective weight, so the remaining lag * weight product stays bounded. rescale_entity() preserves this scale across h_load changes and already relies on the same product when rescaling vlag. Keep the original zero-load warning semantics by multiplying lag by weight after replacing the divisor with one. Fixes: 4823725d9d1d ("sched/fair: Increase weight bits for avg_vruntime") Signed-off-by: Hui Su Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260928124754.1692077-1-sh_def@163.com commit cf1f186e08dadb5abc4410d10fe3ada7ebf801ae Author: Guixiong Wei Date: Thu Oct 8 13:19:54 2026 +0800 perf/x86/intel/uncore: Fix DMR CXL CM invert filter The DMR CXL CM PMU places its invert filter at config bit 21 and its 9-bit threshold at bits 23-31. However, dmr_uncore_cxlcm uses GENERIC_PMON_RAW_EVENT_MASK, which covers the threshold through the generic bit 23 invert field and bits 24-31 threshold field, but does not include the relocated invert bit. As a result, uncore_pmu_event_init() silently clears bit 21 and inv=1 programs the same configuration as inv=0. Add bit 21 to a DMR CXL CM-specific event mask so the requested invert filter reaches hardware. Fixes: 6daf2c35b835 ("perf/x86/intel/uncore: Add IMH PMON support for Diamond Rapids") Signed-off-by: Guixiong Wei Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Zide Chen Link: https://patch.msgid.link/20261008051953.6293-2-weiguixiong@bytedance.com commit 2963ea57b061c4df37ab72637a4bcf320ee40353 Merge: 70db8dea2aac43 c347fef5f8f892 Author: Dave Airlie Date: Fri Oct 16 12:10:27 2026 +1000 Merge tag 'drm-misc-fixes-2026-10-15' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A revert for the blend mode property patch being applied twice and a patch to reset the device when frozen in virtio, a power state fix for vc4, a Kconfig fix for amdxdna, an error handling, reference counting, and a null pointer dereference fix for rocket, a revert for dma-buf for a commit introducing a dangling reference, a locking fix for exec, and a fix for panthor to handle 10-core GPUs. Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patch.msgid.link/atCZfcTvshZx6mcA@houat commit 70db8dea2aac43dd4f9a7ec2365d8c950efaa07d Merge: 24a19b953e2a3d 6a8bf59de3ef47 Author: Dave Airlie Date: Fri Oct 16 10:51:58 2026 +1000 Merge tag 'drm-intel-fixes-2026-10-15' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Fix ARL-S host bridge detection - Add sanity checks for malformed DMC firmware Signed-off-by: Dave Airlie From: Joonas Lahtinen Link: https://patch.msgid.link/atBtrhSxjkB7bVwm@jlahtine-mobl commit 2f2f7eeef8b0a1a9b9ca998231419873ccae8d4e Merge: 62f482ff73bf3a 59f522f5a0ece9 Author: Linus Torvalds Date: Thu Oct 15 15:10:26 2026 -0700 Merge tag 'soc-fixes-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "A small number of last minute bug fixes came up since LPC. Most of these are for devicetree files: - Tegra264 needs fan descriptions to keep the system from overheating - A cleanup on TI DRA7 caused a regression on PCI support and needs a fixup - The beaglev-fire board can no longer probe the mcp3564 sensor after a an inconsistent update in 7.1 - A few fixes address compile time dtc warnings on tegra The other three patches are all addressing minor problems in tegra drivers and the sama5 defconfig" * tag 'soc-fixes-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: configs: sama5: enable current Microchip KSZ DSA symbols soc/tegra: pmc: Fix uninitialised clock rate riscv: dts: microchip: beaglev-fire: remove double definition of gpio interrupts ARM: dts: ti/omap: dra7: fix PCIe PHY clock divider definition soc/tegra: fuse: Add missing newline to APBMISC error message arm64: tegra: Add PCIe root ports on Tegra264 arm64: tegra: Reorder reg and reg-names to match bindings arm64: tegra: Add PWM fan on Jetson AGX Thor DevKit arm64: tegra: Add PWM controllers on Tegra264 commit c47a7b11bcb3d45e29723afcf6336866476b1d08 Author: Taeyang Lee <0wn@theori.io> Date: Fri Oct 16 02:19:55 2026 +0900 tracing: Check operator stack capacity before pushing predicate_parse() uses the first operator stack entry before processing any opening parentheses. A push then increments top before writing. The existing check still permits that write when top already points to the last allocated entry, which can access beyond the operator stack. Reject the push when top reaches the last allocated entry. Cc: stable@vger.kernel.org Fixes: 39f7c41c908b ("tracing/filters: Enable filtering a cpumask field by another cpumask") Link: https://patch.msgid.link/atELO9L0I9kg5CpC@Taeyangs-MacBook-Pro.local Signed-off-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Steven Rostedt commit 803aa6fc2dbea25ab9d3ed19eca1c96d0ab17445 Author: Taeyang Lee <0wn@theori.io> Date: Fri Oct 16 02:19:05 2026 +0900 tracing: Keep the predicate limit separate from program capacity predicate_parse() adds two to nr_preds to reserve the terminal TRUE and FALSE entries. It also uses that increased value as the limit for parsed predicates. If the initial count is smaller than the number actually parsed, the program can fill the allocation and subsequent accesses can go past its end. Keep nr_preds as the predicate limit and use a separate value for the allocation size. This leaves space for both terminal entries and a zeroed entry when parsing stops at the limit. Cc: stable@vger.kernel.org Fixes: 39f7c41c908b ("tracing/filters: Enable filtering a cpumask field by another cpumask") Link: https://patch.msgid.link/atELCd1XjKVhrkFL@Taeyangs-MacBook-Pro.local Signed-off-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Steven Rostedt commit 3cc117514d69067a94d6c7479730dce41e678f50 Author: Hao Ge Date: Thu Oct 15 21:06:58 2026 +0800 tracing: Fix crash in print_graph_function_event() tracing_set_tracer() assigns the flags of the newly selected tracer with: tr->current_trace_flags = t->flags ? : t->tracer->flags; If the new tracer defines neither static flags nor default flags, like hwlat, irqsoff or wakeup, add_tracer() has no per instance flags copy for it, and both operands are NULL, so tr->current_trace_flags ends up being NULL as well. The ring buffer is not cleared when switching tracers: it is reset inside tracer_init(), after current_trace_flags was already assigned. If the buffer still holds function_graph entries of the previous tracer, printing one of them dereferences the NULL pointer. This was hit by cat trace during an ftrace stress test: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode RIP: 0010:print_graph_function_event+0xe/0x20 Call Trace: s_show+0x4d/0x110 seq_read_iter+0x2d4/0x490 seq_read+0x130/0x170 vfs_read+0xb5/0x370 ksys_read+0x6d/0xe0 do_syscall_64+0xbc/0x450 The snapshot buffer is not reset at all, so this can be reproduced without a race: echo function_graph > /sys/kernel/tracing/current_tracer echo 1 > /sys/kernel/tracing/snapshot echo hwlat > /sys/kernel/tracing/current_tracer cat /sys/kernel/tracing/snapshot Rather than teaching every user of tr->current_trace_flags about this corner case, make sure it is never NULL: when the newly selected tracer has no flags at all, tracing_set_tracer() falls back to a static empty no_tracer_flags. run_tracer_selftest() can hit the same case, so the same fallback is added there too. The existing users already handle opts == NULL, so these tracers keep behaving as before. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261015130658.221198-1-hao.ge@linux.dev Fixes: e29aa918a928 ("tracing: Have function graph tracer define options per instance") Suggested-by: Steven Rostedt Signed-off-by: Hao Ge Signed-off-by: Steven Rostedt commit b0f0c761ed3fa10754dc9295db85374a173123b7 Author: Marc Kleine-Budde Date: Fri Oct 9 12:16:36 2026 +0200 spi: spi-fsl-lpspi: directly return ret in fsl_lpspi_transfer_one() Both fsl_lpspi_dma_transfer() and fsl_lpspi_pio_transfer() only return negative error values in case of error or 0 in case of success. Directly return ret, there is no need to check for positive error values and return them as 0. Signed-off-by: Marc Kleine-Budde Link: https://patch.msgid.link/20261009-spi-fsl-lpspi-more-cleanups-v1-2-2d4549d5205e@pengutronix.de Signed-off-by: Mark Brown commit 4eac392e48fc0ddc6d5ac10d57aac7245c17d0d9 Author: Marc Kleine-Budde Date: Fri Oct 9 12:16:35 2026 +0200 spi: spi-fsl-lpspi: pass struct fsl_lpspi_data instead of struct spi_controller if possible Instead of passing a spi_controller pointer to functions and using spi_controller_get_devdata() to get the struct fsl_lpspi_data pointer, directly pass a struct fsl_lpspi_data pointer. Signed-off-by: Marc Kleine-Budde Reviewed-by: Frank Li Link: https://patch.msgid.link/20261009-spi-fsl-lpspi-more-cleanups-v1-1-2d4549d5205e@pengutronix.de Signed-off-by: Mark Brown commit 59eb22641f0c526dd064390b11cff99ae87c2858 Author: Richard Leitner Date: Thu Oct 15 22:58:00 2026 +0200 spi: imx: fix slab corruption from undersized DMA bounce buffers Since commit faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode"), the driver allocates its private DMA TX/RX buffers with kzalloc(dma_len), where dma_len is only rounded up to 4 bytes, but maps, syncs and unmaps them with DMA_CACHE_ALIGNED_LEN(dma_len), i.e. rounded up to the cache line size. As a result, the DMA API operates on memory beyond the end of the allocation. This was observed on a custom i.MX8MP platform with an mcp251xfd CAN controller under heavy RPMSG load, as a series of refcount_t warnings triggered from rpmsg_recv_done() in virtio_rpmsg_bus: refcount_t: addition on 0; use-after-free. refcount_t: underflow; use-after-free. refcount_t: saturated; leaking memory. Leading finally to an "Unable to handle kernel paging request" oops. Reproducing this problem took between 30 minutes and roughly 30 hours under the same workload. Hardware watchpoints on the refcount of a struct rpmsg_endpoint showed it was overwritten from 2 to 1 by __pi_memcpy_generic() in the irq/155-spi2.0 thread. Additionally it was found that a "normal" rpmsg_recv_done() took 11µs +/-2µs from its kref_get to kref_put. In the error case the same sequence took about 215µs +/-10µs. Based on this, an LLM was used to identify the size mismatch fixed here. Allocate the buffers with DMA_CACHE_ALIGNED_LEN(dma_len) so they cover the full mapped length, and use the same length for dma_sync_single_for_cpu() to stay consistent with map and unmap. With this patch applied, the same workload ran for more than 200 hours without the problem reproducing. Assisted-by: LLM Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode") Cc: stable@vger.kernel.org Signed-off-by: Richard Leitner Link: https://patch.msgid.link/20261015-fix-spi-imx-dma-v1-1-e28259671392@linux.dev Signed-off-by: Mark Brown commit d33373c565af9c8a28776af02bd20ba6e5724211 Author: Abdurrahman Hussain Date: Wed Oct 14 16:56:55 2026 -0700 i2c: xiic: restore non-managed runtime PM to fix clk WARN flood The devres conversion replaced manual pm_runtime_enable()/disable() with devm_pm_runtime_set_active_enabled() and dropped the remove-time runtime PM teardown. The managed release tears runtime PM down in the wrong order: it calls pm_runtime_dont_use_autosuspend() before pm_runtime_disable(), i.e. while runtime PM is still enabled, and devres is LIFO so the devm_clk_get_enabled() release runs afterwards. At remove(), pm_runtime_put_sync() leaves the device active with the autosuspend timer armed. Clearing use_autosuspend then makes rpm_idle() suspend immediately, and xiic_i2c_runtime_suspend() clk_disable()s the clock. The later devm_clk_get_enabled() release clk_disable_unprepare()s the already-disabled clock, so clk_core_disable() WARNs ("clkN already disabled") on every teardown. Drop the managed helper and restore the non-managed runtime PM setup and teardown, so runtime PM is enabled once in probe and disabled once in remove and the clock enable count stays balanced. Order the remove teardown so runtime PM is disabled before the usage count is dropped: pm_runtime_disable() followed by pm_runtime_put_noidle() instead of pm_runtime_put_sync(). Dropping the count first with autosuspend still enabled arms the autosuspend timer, and a preemption before pm_runtime_disable() lets it expire, suspend the device and clk_disable() the clock, which the devm release then disables again - the same WARN. Restore the non-managed IRQ request as well. The probe error paths now unwind runtime PM by hand via goto, and a devm-registered handler is only freed later during devres unwind, so it would stay live across the manual teardown (and across any future failing step added after it). Request the IRQ with request_threaded_irq() and free it explicitly in the probe error path and in remove. The probe error path also clears use_autosuspend, to match the teardown in remove(). Fixes: 50c63491ff26 ("i2c: xiic: switch to devres managed APIs") Signed-off-by: Abdurrahman Hussain Cc: # v7.1+ Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20261014-i2c-xiic-restore-runtime-pm-teardown-v8-1-40668c270069@nexthop.ai commit 62f482ff73bf3ae88b0c899115527752cf9cbf13 Merge: 045958acaa7520 4bcfe29021993c Author: Linus Torvalds Date: Thu Oct 15 12:24:14 2026 -0700 Merge tag 'iommu-fixes-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux Pull IOMMU fixes from Joerg Roedel: "AMD IOMMU: - Revert an interrupt remapping check removal that caused GPU regressions on some platforms Generic page tables: - Fix KUnit builds with distributed Clang ThinLTO by preserving compiler flags, preventing x86-64 code generation from arm64 bitcode" * tag 'iommu-fixes-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: iommupt/kunit: Use if_changed_rule for the kunit Revert "iommu/amd: Remove redundant check in irq_remapping_select()" commit 752480ad62964edf0254e151110d3e53a7cb37de Author: Timur Kristóf Date: Wed Oct 7 00:02:52 2026 +0200 drm/amdgpu/sdma3: Work around POLL_REGMEM / FENCE hang SDMA can randomly hang on Polaris 10. Hard to reproduce, but has been occurring sporadically in the Mesa CI on the RADV Polaris 10 job even when Mesa isn't using the SDMA engine. When Mesa actually uses the SDMA on Polaris, the hang becomes more frequent and the reproduction rate goes up significantly in the CI system. We don't know why the hangs occur, but it seems that inserting a single NOP packet before each POLL_REGMEM and FENCE packet works around it. At the moment it's unclear which GPUs are affected, so let's apply this to SDMA 3.x for now. Note that this issue is not documented or acknowledged by AMD. Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit c343a27ed90823d08de125f7c447d96d056b75d9) Cc: stable@vger.kernel.org commit 3c44cbcec5eb370713bbd2c315ed7c34d8ccec2b Author: Jesse Zhang Date: Mon Oct 12 12:24:03 2026 +0800 drm/amdgpu: keep the eviction fence until the last handle is closed amdgpu_gem_object_close() detaches the user queue eviction fence from the BO before it checks bo_va->ref_count, so closing any handle of a BO removes the fence, even when the file still has another handle to the BO and the bo_va with its GPU mappings stays. The BO can then be evicted without suspending the user queues of the file, which keep accessing it through mappings that are only marked for update. Seen on navi31 with a SDMA user queue: a BO opened twice in the same file (GEM_FLINK + GEM_OPEN) loses its eviction fence when the second handle is closed (traced attach/detach of the fence): attach bo=ffff8c78a6c84c00 GEM_CLOSE handle=7 detach bo=ffff8c78a6c84c00 while handle 6 and the mapping are still in use. Only detach the fence when the last reference to the bo_va goes away, matching amdgpu_gem_object_open(), which attaches it only when the bo_va is created. With this the fence stays until the file is closed. Fixes: 31f7efcdca4d ("drm/amdgpu: enable eviction fence") Signed-off-by: Jesse Zhang Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 8387982f03d4026b7dc11b0b5e3118298eee4d6a) Cc: stable@vger.kernel.org commit 55a67aa89342545b89f469dea6f29bfb6fac6f3d Author: Srinivasan Shanmugam Date: Thu Sep 17 11:44:33 2026 +0530 drm/amd/display: Fix NULL sink dereference in USB4 bandwidth functions allocate_usb4_bandwidth_for_stream() and allocate_usb4_bandwidth() both use ASSERT(stream->sink) before dereferencing stream->sink->link. ASSERT is compiled out in production builds, so a NULL stream->sink causes a NULL pointer dereference. link_set_dpms_off() already guards two earlier accesses to stream->sink with explicit NULL checks, confirming that stream->sink can legitimately be NULL. The subsequent call to deallocate_usb4_bandwidth() had no equivalent guard. Replace the ASSERT() calls with proper NULL checks that return false early, and add a matching stream->sink guard at the call site in link_set_dpms_off() consistent with the surrounding pattern. v2: Keep the existing ASSERT() calls for diagnostics (to report unexpected NULL sink), and add explicit NULL checks that return false before dereferencing stream->sink. Also add a matching stream->sink guard at the deallocation call site in link_set_dpms_off(). (Alex) Fixes: 8fa813b7fd1e ("drm/amd/display: Remove sink usage from DPMS") Reported-by: Dan Carpenter Cc: Nicholas Kazlauskas Cc: Dominik Kaszewski Cc: George Zhang Cc: Aurabindo Pillai Cc: Roman Li Cc: Ivan Lipski Cc: Dan Wheeler Cc: Alex Hung Cc: Tom Chung Signed-off-by: Srinivasan Shanmugam Tested-by: Dan Wheeler Reviewed-by: Roman Li Signed-off-by: Alex Deucher (cherry picked from commit 98029a0ce61feb52c563f65349dd9b25f672e355) Cc: stable@vger.kernel.org commit 32d0771ef4ca69c30a1db3aefa34dd177cd2a047 Author: Benjamin Cheng Date: Fri Oct 9 09:31:42 2026 -0400 drm/amdgpu/userq: actually validate userq BOs This was supposed to loop over the individual evicted list, as the kernel and always_valid evicted lists were already handled in amdgpu_vm_validate. Without this, BOs that were created and evicted before a userq was made would never end up in an eviction fence rearm. Also add the missing ref to the BO before drm_exec locks and refs it. Fixes: 4cdbba5a16aa ("drm/amdgpu: restructure VM state machine v4") Signed-off-by: Benjamin Cheng Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 18decfc9e8cc0fa70b6de9944cc27a37729edfbd) Cc: stable@vger.kernel.org commit d65a459dbc9a6c3b051e22c96f73598e34b31bfc Author: Jesse Zhang Date: Mon Oct 12 09:28:33 2026 +0800 drm/amdgpu: report the BO alignment in bytes in GEM_LIST_HANDLES The uapi documents drm_amdgpu_gem_list_handles_entry.alignment as "physical start_addr alignment in bytes", and GEM_OP GET_GEM_CREATE_INFO returns the same value in bytes, but GEM_LIST_HANDLES returns tbo.page_alignment, which is in pages. For a BO created with a 64 KiB alignment on navi31: GET_GEM_CREATE_INFO: alignment=65536 GEM_LIST_HANDLES: alignment=16 so a user such as CRIU that recreates BOs from this list uses the wrong alignment. Convert it to bytes. Fixes: f9db1fc52ceb ("drm/amdgpu: Add ioctl to get all gem handles for a process") Signed-off-by: Jesse Zhang Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit aa4493ae949c13e79aba0731394dd7a7e431342b) Cc: stable@vger.kernel.org commit 1b4da805a0ba354a549ce07459c871c17dd94fe0 Author: Jesse Zhang Date: Fri Oct 9 16:05:05 2026 +0800 drm/amdgpu: free the userptr ranges when a CS fails after parser_bos amdgpu_cs_parser_bos() allocates an HMM range for every userptr entry of the BO list and looks up the user pages. Those ranges are only freed when amdgpu_cs_parser_bos() itself fails or when amdgpu_cs_submit() checks them under the notifier lock. If amdgpu_cs_patch_jobs(), amdgpu_cs_vm_handling(), amdgpu_cs_sync_rings() or the early part of amdgpu_cs_submit() fails, nothing frees them: neither amdgpu_cs_parser_fini() nor amdgpu_bo_list_free() touch e->range. Each such CS then leaks the range, its hmm_pfns array (8 bytes per page of the userptr BO) and the BO reference the range holds. An IB on a ring that patches the CS in place (e.g. VCN) with an unmapped va_start fails in amdgpu_cs_patch_ibs() and takes this path. Free the ranges on those error paths. Ranges amdgpu_cs_submit() already dropped are NULL, so freeing them again is a no-op. Fixes: fec8fdb54e8f ("drm/amdgpu: fix userptr HMM range handling v2") Reviewed-by: Alex Deucher Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit c52a9542ed7cfd527feb938bd0accada2ac8d267) Cc: stable@vger.kernel.org commit de9f6bcdb44f0e410031002e2f103826ea6b6259 Author: Jesse Zhang Date: Fri Oct 9 13:21:33 2026 +0800 drm/amdgpu: don't drop the runtime PM reference twice in amdgpu_gpr amdgpu_debugfs_gpr_read() drops its runtime PM reference right after reading the wave registers. When copying them to userspace fails, it jumps to the err label, which drops the reference a second time. A read into a bad buffer on Navi31 either steals a reference somebody else holds (power/runtime_usage goes from 1 to 0) or underflows the count: amdgpu 0000:03:00.0: Runtime PM usage count underflow! The registers are already in the kernel buffer at that point, so finish the hardware access first and copy the buffer with a single copy_to_user() instead of the put_user() loop with its own error path. Fixes: 9eee152aab56 ("drm/amdgpu/debugfs: fix ref count leak when pm_runtime_get_sync fails") Reviewed-by: Alex Deucher Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit 31035bbd74f7c3e10c163db875b8e67f8b50ee6a) Cc: stable@vger.kernel.org commit 3c516a5646285442e1cd71dff2584b77eb4fc421 Author: Perry Yuan Date: Thu Sep 10 17:13:39 2026 +0800 drm/amdgpu: fix GEM object leak on ENOMEM in userptr ioctl When amdgpu_hmm_range_alloc() fails amdgpu_gem_userptr_ioctl() returns -ENOMEM right away and skips the cleanup every other error path goes through. The GEM object, the bo->parent reference on the VM root and the MMU notifier registration are all left behind. Use release_object here, not user_pages_done, range is still NULL at this point. Fixes: e095b55155ef ("drm/amdgpu: use user provided hmm_range buffer in amdgpu_ttm_tt_get_user_pages") Signed-off-by: Perry Yuan Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit bbe739e407a542073ec1a7872b14843566b4919e) Cc: stable@vger.kernel.org commit a2eae9f4fa1b07f8e6e61b48931228da051943f0 Author: Kenneth Feng Date: Thu Oct 8 20:28:09 2026 +0800 drm/amd/pm: add zero fan stop temperature support on smu 14.0.2 add zero fan stop temperature support on smu 14.0.2 Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5905 Signed-off-by: Kenneth Feng Reviewed-by: Kevin Wang Signed-off-by: Alex Deucher (cherry picked from commit f990c94a2633d0ead477eb1b174e254a6d292e66) Cc: stable@vger.kernel.org commit 5b0a459f990be2faba33229fd93f10f23745fab2 Author: Perry Yuan Date: Thu Sep 10 16:58:17 2026 +0800 drm/amdgpu: destroy mutex when tearing down ttm buffer entity Pair mutex_init() with mutex_destroy() on the GART window allocation failure path and in amdgpu_ttm_buffer_entity_fini(). This is a no-op without CONFIG_DEBUG_MUTEXES, but it keeps lockdep from seeing a live mutex after the entity is freed or re-initialized. Signed-off-by: Perry Yuan Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 03ac40aeed034a0a0d5824ad26f8fbe1f6463698) Cc: stable@vger.kernel.org commit b5629f4a0869f4b01cfbfdf27f2c349d68c5d9d4 Author: Perry Yuan Date: Thu Sep 10 16:57:31 2026 +0800 drm/amdgpu: fix sched entity leak in ttm buffer entity init amdgpu_ttm_buffer_entity_init() checks num_gart_windows after drm_sched_entity_init() has already attached the entity to a scheduler run-queue. Returning -EINVAL from that check leaks the entity. Move the ARRAY_SIZE() check before any resources are acquired. Fixes: 2c3725572561 ("drm/amdgpu: statically assign gart windows to ttm entities") Signed-off-by: Perry Yuan Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 4000d1cdd1eacd3422267d6c8b4f1c9333b0317e) Cc: stable@vger.kernel.org commit 800ea86e83e137395eba54103e5c459c2bc9965f Author: Timur Kristóf Date: Tue Oct 6 23:16:07 2026 +0200 drm/amdgpu/uvd3.1: Fix checking whether UVD firmware keyselect was already set The PASS_MASK is for a different register not for UVD_FW_START. It was a mistake to check this flag. It should be enough to check that the register is non-zero. Fixes: 889a2cfd889c ("drm/amdgpu/uvd3.1: Don't validate the firmware when already validated") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20261006211607.75407-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 9dee462c83259ca769aa1bf82228adee9831685c) Cc: stable@vger.kernel.org commit 045958acaa75205b31578cb22c4345e28dd2e4bf Merge: 9aa622dbaab8ad aa07285705f8d5 Author: Linus Torvalds Date: Thu Oct 15 08:20:20 2026 -0700 Merge tag 'net-7.3-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "This is considerably smaller than in recent history, mostly due to reduced capacity and increased backlog. Also we actively redirected more stuff towards next. I'm not aware of any pending regression. Current release - regressions: - eth: move netops initialization to fix crash Previous releases - regressions: - sched: fix use-after-free in __tcf_action_put() - rds: fix uninitialized trans dereference in CM event handler Previous releases - always broken: - vsock: treat TCP_CLOSING as once-established - netlink: avoid hashing the network namespace pointer - eth: mlx5: HWS, release L2 to L3 tunnel reformats to their own pool" * tag 'net-7.3-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (23 commits) net: stmmac: dwmac1000: clear the RGMII status interrupt net/sched: fix use-after-free in __tcf_action_put() calipso: keep BIG TCP payload_len in calipso_skbuff_setattr() MAINTAINERS: add Gustavo Luiz Duarte as netconsole reviewer net: bcmgenet: unshare the skb before writing the control block microchip: lan865x: move setting of netops to fix crash net: ti: icssm-prueth: Move setting of netops to fix crash net: ethernet: aeroflex: move setting of netops to fix crash net: ethoc: move setting of netops to fix crash net: au1000: move setting of netops to fix crash net: mv643xx: move setting of netops to fix crash net: ethernet: adi: Move setting of netops to fix crash net: ethernet: actions: Move setting of netops to fix crash net: hisilicon: hip04_eth: Move setting of netops to fix crash net: hisilicon: hisi_femac: Move setting of netops to fix crash netlink: avoid hashing the network namespace pointer net/mlx5: HWS, fix flow meter offset within its bulk net/mlx5: HWS, release L2 to L3 tunnel reformats to their own pool netlink: reset skb headers before unicast and multicast filtering sctp: revalidate output stream after association connect wait ... commit 9aa622dbaab8addcbe6f65f17c7b4d613d270f05 Merge: 6a66840a68683d c8f4cfe1cf93bc Author: Linus Torvalds Date: Thu Oct 15 08:12:47 2026 -0700 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull kvm fixes from Paolo Bonzini: "Even more x86 fixes: - Avoid a false positive panic in the #PF handler, if the kernel triggers a page fault within the asynchronous page fault handler before the flags are reset. This can happen for example because of a perf NMI. - Always reset a vCPU's MMU pointer back to the root MMU when loading nested guest state fails during RSM or KVM_SET_NESTED_STATE. Otherwise KVM tries to run a non-nested guest with a nested MMU, which can result in a NULL pointer dereference attempting to get the nested MMU's pgd (EPTP or nested CR3)" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: nVMX: Reset MMU back to the root MMU if loading L2 state fails for !VM-Entry x86/kvm: Don't consume async #PF flags on a kernel #PF in NMI context commit 6a66840a68683d9361a9b31faf3bd8104428ad29 Merge: 9fee1f650a0a9e dbc393f6f009a2 Author: Linus Torvalds Date: Thu Oct 15 08:06:26 2026 -0700 Merge tag 'hyperv-fixes-signed-20261015' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull Hyper-V fixes from Wei Liu: - Typo and comment fixes (Hemanth Selam, Jiangshan Yi) - Update maintainers list (Wei Liu, Long Li) - Two Hyper-V PCI driver fixes (Naman Jain, Sahil Chandna) - Small fixes for core Hyper-V code (Hardik Garg, Michael Kelley, Waiman Long) * tag 'hyperv-fixes-signed-20261015' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: MAINTAINERS: drop KY from Hyper-V maintainers list PCI: hv: Warn when wait_for_response() waits indefinitely PCI: hv: Probe vPCI buses asynchronously MAINTAINERS: remove myself from the Hyper-V entries mshv_vtl: Check per-CPU register page before mmap tools/hv: fix typo "retrive" in comment Drivers: hv: vmbus: fix typo "substract" in comment Drivers: hv: Don't reset VMBus connection state on error/exit paths x86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index() x86/hyperv: Fix stale comments after stimer message mode removal Drivers: hv: Avoid infinite retry loop in init_vp_index() commit 8e8cd9a4c6dc006e9bd51b8ad0079fb4576b48d3 Merge: 07c75552f7fe63 2a31b5378c6db9 Author: Takashi Iwai Date: Thu Oct 15 16:57:14 2026 +0200 Merge tag 'asoc-fix-v7.3-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v7.3 There's a relatively large block of fixes for errors in register field definitions here, resulting from an audit done after review of a prior series. The fixes themselves are very small and can be directly checked against the datasheets. Other than that we've got some driver specific fixes, the AMD fix is a little large but fixes a clear issue and won't affect other systems. commit aa07285705f8d5bac464eb1c5b7412f8e88b91e1 Author: Igor Velkov Date: Fri Oct 9 23:17:09 2026 +0300 net: stmmac: dwmac1000: clear the RGMII status interrupt Since commit 2e2c878a3141 ("net: stmmac: remove SGMII/RGMII/SMII interrupt handling") nothing on the RGMII path reads GMAC_RGSMIIIS, so RGSMIIIS stays pending behind GMAC_INT_MASK from the first link change on. stmmac_resume() resets the MAC in stmmac_hw_setup(); the reset sets GMAC_INT_MASK to 0 until dwmac1000_core_init() writes the mask again, and the pending status storms the line: dwmac_dma_interrupt: unexpected status 04000000 A register dump at the first message on ODROID-HC4 showed it: core int_status 00000001 int_mask 00000000 pmt 00000000 rgsmiiis 0000000d When the resume thread runs on the CPU that takes the MAC interrupt, the storm starves it: a soft lockup, then a watchdog reset or a hang. Read GMAC_RGSMIIIS in dwmac1000_irq_status() when the status is not masked, as the driver did before 2e2c878a3141; the read clears it. Wake-on-LAN resume from s2idle with the resume thread and the MAC interrupt on one CPU: Helios64 (dwmac-rk), 7.3-rc6, soft-locked in 3 of 3 resumes without a fix and in 0 of 10 with this patch; it ran with an out-of-tree dwmac-rk change that keeps the GMAC powered across suspend. ODROID-HC4 (dwmac-meson8b): 0 of 10 with this patch, 2 of 2 without a fix on a 7.3-rc5 build. irq_rgmii_n went up by one per resume. Fixes: 2e2c878a3141 ("net: stmmac: remove SGMII/RGMII/SMII interrupt handling") Assisted-by: LLM Signed-off-by: Igor Velkov Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20261009201709.1917585-1-iav@iav.lv Signed-off-by: Paolo Abeni commit a244c241593b5b38a08f0df2cb43c26574efbdcb Author: Lee Jones Date: Tue Oct 13 11:24:48 2026 +0000 tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields In check_synth_field(), when a synthetic event field is a stacktrace (field->is_stack) and the histogram field is not a "long[" stacktrace array, validation falls through to the generic size and signedness comparison. Because parse_synth_field() sets a stacktrace field's type to "__data_loc unsigned long[]", its size is sizeof(u64) and synth_field_signed() marks it as signed. Consequently, any 8-byte signed scalar histogram field passes the fallback check, and its scalar value is subsequently dereferenced as a kernel stacktrace pointer in get_field_size() and trace_stack(). Furthermore, checking strstr(hist_field->type, "long[") is insufficient because tracepoint fields defined with __bitmask() or __rel_bitmask() also have type "__data_loc unsigned long[]" or "__rel_loc unsigned long[]", whilst create_hist_field() treats them as 4-byte scalar values without HIST_FIELD_FL_STACKTRACE. Propagate HIST_FIELD_FL_STACKTRACE to variable references and field variables (whilst excluding variable aliases from per-element stacktrace capture), and reject any mismatch between HIST_FIELD_FL_STACKTRACE and field->is_stack in check_synth_field(). Cc: stable@vger.kernel.org Fixes: 00cf3d672a9d ("tracing: Allow synthetic events to pass around stacktraces") Link: https://patch.msgid.link/20261013112449.1006088-1-lee@kernel.org Signed-off-by: Lee Jones Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt commit 13d530f2daeda9493f4d07ddc5ca13e21318fbeb Author: Vincent Donnefort Date: Tue Oct 13 11:20:47 2026 +0100 ring-buffer: Use subbuf_order in available memory estimation To avoid failing in the middle of an allocation of a ring-buffer, __rb_allocate_pages() looks at the available memory estimation with si_mem_available(). Use the subbuffer order with this estimation to fail early if necessary for ring-buffers with an order > 0. Link: https://patch.msgid.link/20261013102047.1488347-3-vdonnefort@google.com Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page") Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt commit 205cccd06e545694754e1bf8d626ea96e742cd8a Author: Peng Fan Date: Tue Oct 13 14:01:12 2026 +0800 gpio: mxc: fix race between gpiochip registration and IRQ domain setup devm_gpiochip_add_data() makes the GPIO chip visible to consumers immediately. Since the chip sets .to_irq = mxc_gpio_to_irq, which calls irq_find_mapping(port->domain, offset), any to_irq() call between gpiochip registration and IRQ domain creation will operate on a NULL domain. Fix by moving devm_gpiochip_add_data() after the IRQ domain and generic irq chip are fully initialized, ensuring port->domain and the irq chip handlers are ready before the chip becomes visible to consumers. Fixes: d37a65bb4663 ("gpio/mxc: Move Freescale MXC gpio driver to drivers/gpio") Signed-off-by: Peng Fan Reviewed-by: Linus Walleij Reviewed-by: Frank Li Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20261013-gpio-mxc-cleanup-v7-4-c4d769587d3e@nxp.com Signed-off-by: Bartosz Golaszewski commit 170aeff46fb54f41545c85a72aec525aebc79d44 Author: Peng Fan Date: Tue Oct 13 14:01:11 2026 +0800 gpio: mxc: fix wakeup_pads bit operations gpio_set_wake_irq() can be called concurrently for different pins on the same port. The writer-vs-writer race is the concern: two concurrent gpio_set_wake_irq() calls for different pins on the same port both do a non-atomic read-modify-write on the same wakeup_pads word. The old |= and &= compile to separate load/modify/store instructions that can interleave, losing one CPU's update. assign_bit() uses an atomic RMW instruction, so concurrent writers to different bits in the same word are safe. The reader side (for_each_set_bit in noirq_suspend, wakeup_pads > 0) runs in noirq context where no concurrent writer can execute, so reader atomicity is not needed. wakeup_pads is a u32, while assign_bit() operates on unsigned long pointers. On 64-bit platforms, this causes an 8-byte read-modify-write on a 4-byte field, corrupting the adjacent is_pad_wakeup. So change wakeup_pads to unsigned long and reorder to avoid wasting words. And fix the enable/disable path unconditionally sets/clears the wakeup_pads bit even when enable_irq_wake()/disable_irq_wake() fails. Only update the bit on success. Fixes: f60c9eac54af ("gpio: mxc: enable pad wakeup on i.MX8x platforms") Assisted-by: LLM Reviewed-by: Frank Li Signed-off-by: Peng Fan Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20261013-gpio-mxc-cleanup-v7-3-c4d769587d3e@nxp.com Signed-off-by: Bartosz Golaszewski commit b7719c575dec69146f6d537fd616b27083c0cf45 Author: Peng Fan Date: Tue Oct 13 14:01:10 2026 +0800 gpio: mxc: fix both_edges bit operations gpio_set_irq_type() can be called concurrently for different pins on the same port. The IRQ core serializes per irq descriptor, but different pins have different descriptors, so on SMP systems two concurrent gpio_set_irq_type() calls for pins on the same port run without mutual exclusion. The read-modify-write of port->both_edges is performed outside the port-wide scoped_guard(gpio_generic_lock_irqsave) section, so concurrent updates for different pins can overwrite each other, causing missed interrupts or stuck IRQ lines on dual-edge triggered pins. The original uniprocessor MXC SoCs were not affected; the race became reachable on multi-core i.MX7 and i.MX8 SoCs that reuse this driver. Convert both_edges from u32 to unsigned long and use set_bit(), clear_bit(), and test_bit() to make the modifications atomic. Fixes: 910862ec092c ("mxc: emulate GPIO interrupt on both-edges") Reviewed-by: Frank Li Signed-off-by: Peng Fan Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20261013-gpio-mxc-cleanup-v7-2-c4d769587d3e@nxp.com Signed-off-by: Bartosz Golaszewski commit 38d44f78f041ffe60c8e2443b99434a199e7541d Author: Peng Fan Date: Tue Oct 13 14:01:09 2026 +0800 gpio: mxc: fix race between chained IRQ handler install and probe completion mxc_update_irq_chained_handler() is called before the IRQ domain, the generic IRQ chip, and the port list entry are set up. If an interrupt arrives in that window: - mx3_gpio_irq_handler() calls generic_handle_domain_irq() with port->domain still NULL. - mx2_gpio_irq_handler() walks mxc_gpio_ports, but the port has not been added to the list yet. Additionally, if any of the subsequent probe steps (gpio_generic_chip_init(), devm_gpiochip_add_data(), irq_domain_create_legacy(), or mxc_gpio_init_gc()) fail, the error paths never unregister the chained handler, leaving a dangling handler that points at freed memory. Move the handler installation after all its dependencies are ready and after list_add_tail(), so the handler is never live while the data structures it touches are incomplete, and is never installed if probe fails. Fixes: 5f6d1998adeb ("gpio: mxc: release the parent IRQ in runtime suspend") Assisted-by: LLM Reviewed-by: Frank Li Signed-off-by: Peng Fan Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20261013-gpio-mxc-cleanup-v7-1-c4d769587d3e@nxp.com Signed-off-by: Bartosz Golaszewski commit c28846ca1ac6134881114d272314623c8433e372 Author: Kent Gibson Date: Thu Oct 15 10:57:49 2026 +0800 gpiolib: fix memory leak in gpiod_set_array_value_complex() on error paths A drive-by review by Sashiko reports that, after a failed call to gpiochip_set_multiple(), gpiod_set_array_value() returns abruptly, bypassing the freeing of possibly alloced bitmaps, potentially leaking memory. It is an unlikely error path, but is possible. Defer the return code check until after the bitmap_free() block. Fixes: 9b407312755f ("gpiolib: rework the wrapper around gpio_chip::set_multiple()") Reported-by: Sashiko Link: https://lore.kernel.org/linux-gpio/sashiko-outbox-168233@kernel.org/ Signed-off-by: Kent Gibson Link: https://patch.msgid.link/20261015025749.47039-1-warthog618@gmail.com Signed-off-by: Bartosz Golaszewski commit 851bb4a42991666f515040e95e6f40191da9e899 Author: Bartosz Golaszewski Date: Wed Oct 14 10:44:02 2026 +0200 gpio: kunit: fix GPIO device reference leak with __free() KUnit aborts the test thread immediately using kthread_exit() so the variable annotated with __free() never really goes out of scope and the associated callback is not called. Schedule a kunit action instead. Fixes: a05cfd98c5ec ("gpio: kunit: add test cases for software node hogs") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20261013-gpio-kunit-plat-lookup-v3-0-3907f913e964%40oss.qualcomm.com?part=1 Link: https://patch.msgid.link/20261014-gpio-kunit-autofree-leak-fix-v1-1-5bfa7be0eb1f@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit cf73c3fc03c43a8a86fd487c62390b4744eff9ec Author: Bartosz Golaszewski Date: Wed Oct 14 11:38:26 2026 +0200 gpio: shared: gracefully handle no-device lookup of shared GPIOs We use platform lookup tables for shared GPIOs. This mechanism needs a struct device to work so fwnode-based lookup with no device associated currently causes a NULL-pointer deference. Adding this functionality will require a larger rework and it has never worked anyway so add a check that allows the kernel to gracefully handle this situation with an error ahead of implementing that functionality as a new feature. Cc: stable@vger.kernel.org Reported-by: Abel Vesa Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support") Link: https://patch.msgid.link/20261014-gpio-shared-fwnode-lookup-v4-2-2253ad645fd6@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit bd22f7e63509fa758cf500d9af3e88a3d3df96be Author: Bartosz Golaszewski Date: Wed Oct 14 11:38:25 2026 +0200 gpio: shared: fix use-after-free bug when adding shared proxies The GPIO lookup table can stay alive for longer than the kobject whose name string's address we're assigning to lookup->dev_id. Fix a potential UAF by duplicating the string. Cc: stable@vger.kernel.org Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support") Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20261014-gpio-shared-fwnode-lookup-v4-1-2253ad645fd6@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit 7b16eb911091aae237a8673da94e4dfb9cd21d54 Author: Jérémy Jean Date: Thu Oct 8 18:13:49 2026 +0000 net/sched: fix use-after-free in __tcf_action_put() __tcf_action_put() decrements the reference count before decrementing the binding count. Another thread can free the action between these operations, causing the binding-count update to access freed memory. KASAN reports it as: BUG: KASAN: slab-use-after-free in __tcf_action_put+0x327/0x340 Write of size 4 at addr ff11000000d46420 by task tc-put-pause/64 Hold the action IDR mutex across both counter updates and IDR removal, keeping cleanup outside the lock. Fixes: 16af6067392c ("net: sched: implement reference counted action release") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Jérémy Jean Reviewed-by: Simon Horman Link: https://patch.msgid.link/20261008181348.527035-2-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Paolo Abeni commit 8070ed578b6b9134e045627fb745c887a806d46e Author: Joas Antonio dos Santos Date: Fri Oct 9 12:59:19 2026 -0300 calipso: keep BIG TCP payload_len in calipso_skbuff_setattr() calipso_skbuff_setattr() adjusts payload_len by the length of the option it inserts or resizes: payload = ntohs(ip6_hdr->payload_len); ip6_hdr->payload_len = htons(payload + len_delta); GRO can build BIG TCP packets larger than IPV6_MAXPLEN, and stores payload_len == 0 for them; ipv6_payload_len() then falls back to skb->len. For such a packet forwarded to a destination mapped to CALIPSO, the code above writes len_delta (or 65536 + len_delta when shrinking) into payload_len, and ipv6_payload_len() no longer falls back to skb->len. nf_tables, conntrack and sch_cake rely on it. The same arithmetic also wraps when a packet grows past IPV6_MAXPLEN, and a BIG TCP packet that shrinks below IPV6_MAXPLEN should get its real length back. Set payload_len from the skb length with ipv6_set_payload_len(), which stores 0 above IPV6_MAXPLEN and the real length otherwise, as ipv6_gro_complete() does. The network header was just reset to skb->data, so skb->len - sizeof(*ip6_hdr) is the payload length. Tested on one kernel (arm64, QEMU) with SELinux permissive, a minimal mdp-generated policy (network_peer_controls=1), "netlabelctl calipso add pass doi:16" and a NetLabel mapping of fd00:2::/64 to CALIPSO DOI 16. calipso_skbuff_setattr() was called through netlbl_skbuff_setattr() from a test-only debugfs hook (not part of this patch) adding a level-only label; payload_len after the call: case before fix after fix real length 1000, unlabeled 1016 1016 1016 70000 GSO, payload_len 0 16 0 70016 65530 GSO, grows past MAXPLEN 10 0 65546 65540 GSO with a 24 byte hop header, shrinks below MAXPLEN 65528 65532 65532 1000 with a 24 byte hop header 992 992 992 (0 means ipv6_payload_len() returns the real length.) On the forward path, with a client injecting unlabeled UDP through a router to a server, the router adds the CALIPSO option and the server delivers all datagrams (Udp6InDatagrams 5, Ip6InTruncatedPkts 0) with this patch. Fixes: 81fbc812132c ("ipv6/gro: insert temporary HBH/jumbo header") Suggested-by: Eric Dumazet Suggested-by: Wang Zhan Signed-off-by: Joas Antonio dos Santos Assisted-by: Claude:claude-opus-5-5 Reviewed-by: Wang Zhan Acked-by: Paul Moore Link: https://patch.msgid.link/179156155963.36253.400481753322266658@gmail.com Signed-off-by: Paolo Abeni commit 1c1e8c24d537ba6133f08f523a2b8c626da4e966 Author: Breno Leitao Date: Fri Oct 9 06:39:25 2026 -0700 MAINTAINERS: add Gustavo Luiz Duarte as netconsole reviewer Gustavo has been the most active netconsole reviewer, let's add him to the MAINTAINERS file. Add an R: entry so get_maintainer.pl Cc's Gustavo on netconsole patches. Signed-off-by: Breno Leitao Acked-by: Gustavo Luiz Duarte Link: https://patch.msgid.link/20261009-netcon_main-v1-1-6d298ab5a0cd@debian.org Signed-off-by: Paolo Abeni commit 89771ce4f8f67dcffae561b2ccac95c0f6e3aa01 Author: Nicolai Buchwitz Date: Fri Oct 9 12:10:41 2026 +0200 net: bcmgenet: unshare the skb before writing the control block bcmgenet stores first_cb, last_cb and bytes_sent in the skb control block and reads them back on completion to free the skb and credit BQL. ether_setup() leaves IFF_TX_SKB_SHARING set, so the stack can resubmit a shared skb that is still in the ring. The next transmit overwrites last_cb, so the earlier slots complete without crediting their bytes and BQL stalls the queue until the watchdog resets it. Unshare the skb before writing the control block. Reproduce with pktgen in clone_skb mode, which hands the driver the same skb while earlier copies are still in the ring: modprobe pktgen pg=/proc/net/pktgen echo "add_device eth0" > $pg/kpktgend_0 echo "dst_mac AA:BB:CC:DD:EE:FF" > $pg/eth0 echo "dst 192.0.2.1" > $pg/eth0 echo "clone_skb 8" > $pg/eth0 echo "count 0" > $pg/eth0 echo start > $pg/pgctrl & sleep 5 echo stop > $pg/pgctrl wait cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight inflight stays nonzero on the now idle queue. clone_skb 0 leaves it at zero. Fixes: f48bed16a756 ("net: bcmgenet: Free skb after last Tx frag") Signed-off-by: Nicolai Buchwitz Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20261009-nb-genet-shared-skb-net-v1-1-c6d0a841977d@tipi-net.de Signed-off-by: Paolo Abeni commit 052b8920dd3c71438951113cad1d80a23cab7daa Merge: f88bb3606e4bd1 2a3f6d2a9ac364 Author: Paolo Abeni Date: Thu Oct 15 10:39:24 2026 +0200 Merge branch 'net-move-setting-of-netops-to-fix-crash' David Yang says: ==================== net: Move setting of netops to fix crash Commit ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") put a netdev_need_ops_lock() check on the phy_attach_direct() path, in phy_link_topo_add_phy(). With CONFIG_NET_SHAPER enabled netdev_need_ops_lock() reads dev->netdev_ops->net_shaper_ops, so any driver that connects a PHY before assigning ndev->netdev_ops now dies with a NULL pointer dereference at probe time. The breakage showed up in v7.3-rc1. ibm/emac was hit first and fixed by commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash"). These ten patches apply the same one-line move to the remaining in-tree drivers whose probe path attaches a PHY before filling in netdev_ops: 1. hisilicon/hisi_femac (crash reproduced on hardware) 2. hisilicon/hip04 3. actions/owl-emac 4. adi/adin1140 5. marvell/mv643xx_eth 6. amd/au1000_eth 7. ethoc 8. aeroflex/greth 9. ti/icssm-prueth 10. microchip/lan865x (attach happens inside oa_tc6_init()) Only patch 1 was reproduced and verified on hardware; patches 2-10 were found by source inspection and are neither build nor boot tested. Note that ti/netcp_ethss and cavium/thunder_bgx attach a PHY to netdevs that never get a netdev_ops at all (dummy netdevs), so they cannot be fixed by reordering and are not addressed here. ==================== Link: https://patch.msgid.link/20261008022656.3592191-1-mmyangfl@gmail.com Signed-off-by: Paolo Abeni commit 2a3f6d2a9ac364c68e4f5b24128ba14be48b024a Author: David Yang Date: Thu Oct 8 10:26:52 2026 +0800 microchip: lan865x: move setting of netops to fix crash lan865x_probe() assigns netdev_ops only after oa_tc6_init(), which connects the internal MAC-PHY through phy_connect_direct(). phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash"). Fixes: ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") Signed-off-by: David Yang Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20261008022656.3592191-11-mmyangfl@gmail.com Reviewed-by: Jijie Shao Signed-off-by: Paolo Abeni commit 955bb7cf680d8699ce94c73539af882840a9be43 Author: David Yang Date: Thu Oct 8 10:26:51 2026 +0800 net: ti: icssm-prueth: Move setting of netops to fix crash icssm_prueth_netdev_init() calls of_phy_get_and_connect() before ndev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash"). Fixes: ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") Signed-off-by: David Yang Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20261008022656.3592191-10-mmyangfl@gmail.com Reviewed-by: Jijie Shao Signed-off-by: Paolo Abeni commit d71483f0716e7ae98578817bfdc8a5b822d250f8 Author: David Yang Date: Thu Oct 8 10:26:50 2026 +0800 net: ethernet: aeroflex: move setting of netops to fix crash greth_of_probe() calls greth_mdio_init(), which connects the PHY, before dev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash"). Fixes: ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") Signed-off-by: David Yang Reviewed-by: Maxime Chevallier Acked-by: Andreas Larsson Link: https://patch.msgid.link/20261008022656.3592191-9-mmyangfl@gmail.com Reviewed-by: Jijie Shao Signed-off-by: Paolo Abeni commit c9f8ce62a5faa73515ff5457716bd7306d20fd93 Author: David Yang Date: Thu Oct 8 10:26:49 2026 +0800 net: ethoc: move setting of netops to fix crash ethoc_probe() calls ethoc_mdio_probe(), which connects the PHY, before netdev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash"). Fixes: ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") Signed-off-by: David Yang Reviewed-by: Maxime Chevallier Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20261008022656.3592191-8-mmyangfl@gmail.com Reviewed-by: Jijie Shao Signed-off-by: Paolo Abeni commit beabbafdd0f6779813a7656baa1b412b19bda911 Author: David Yang Date: Thu Oct 8 10:26:48 2026 +0800 net: au1000: move setting of netops to fix crash au1000_probe() calls au1000_mii_probe(), which connects the PHY, before dev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash"). Fixes: ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") Signed-off-by: David Yang Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20261008022656.3592191-7-mmyangfl@gmail.com Reviewed-by: Jijie Shao Signed-off-by: Paolo Abeni commit a3eef3d2cca032d8768b5eb07aab0f46b79bfd8a Author: David Yang Date: Thu Oct 8 10:26:47 2026 +0800 net: mv643xx: move setting of netops to fix crash mv643xx_eth_probe() connects the PHY before dev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash"). Fixes: ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") Signed-off-by: David Yang Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20261008022656.3592191-6-mmyangfl@gmail.com Reviewed-by: Jijie Shao Signed-off-by: Paolo Abeni commit ea1565cbf0637b966eb31a2cf9a8159d673d4e09 Author: David Yang Date: Thu Oct 8 10:26:46 2026 +0800 net: ethernet: adi: Move setting of netops to fix crash adin1140_probe() calls adin1140_phy_init(), which connects the PHY, before netdev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash"). Fixes: ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") Signed-off-by: David Yang Reviewed-by: Maxime Chevallier Reviewed-by: Ciprian Regus Link: https://patch.msgid.link/20261008022656.3592191-5-mmyangfl@gmail.com Reviewed-by: Jijie Shao Signed-off-by: Paolo Abeni commit c2c4824319850c87e77d26aeb8f860bc310a64d7 Author: David Yang Date: Thu Oct 8 10:26:45 2026 +0800 net: ethernet: actions: Move setting of netops to fix crash owl_emac_probe() calls owl_emac_phy_init(), which connects the PHY, before netdev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash"). Fixes: ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") Signed-off-by: David Yang Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20261008022656.3592191-4-mmyangfl@gmail.com Reviewed-by: Jijie Shao Signed-off-by: Paolo Abeni commit 0d9342701f14ec0a9465772b7cd5d515c1ecd818 Author: David Yang Date: Thu Oct 8 10:26:44 2026 +0800 net: hisilicon: hip04_eth: Move setting of netops to fix crash hip04_mac_probe() calls of_phy_connect() before ndev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash"). Fixes: ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") Signed-off-by: David Yang Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20261008022656.3592191-3-mmyangfl@gmail.com Reviewed-by: Jijie Shao Signed-off-by: Paolo Abeni commit 444889dfa27b54b39026e962464b1f8f9093e1ea Author: David Yang Date: Thu Oct 8 10:26:43 2026 +0800 net: hisilicon: hisi_femac: Move setting of netops to fix crash hisi_femac_drv_probe() connects the PHY before dev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. phy_link_topo_add_phy from phy_attach_direct+0xec/0x37c of_phy_get_and_connect from hisi_femac_drv_probe+0x1f4/0x558 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash"). Fixes: ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") Signed-off-by: David Yang Reviewed-by: Maxime Chevallier Reviewed-by: Jijie Shao Link: https://patch.msgid.link/20261008022656.3592191-2-mmyangfl@gmail.com Signed-off-by: Paolo Abeni commit f88bb3606e4bd11ee035b682cddc2999e604609a Author: Kyle Zeng Date: Wed Oct 7 18:14:00 2026 -0700 netlink: avoid hashing the network namespace pointer The netlink rhashtable key includes a raw struct net pointer and a user-controlled port ID. Both /proc/net/netlink and socket diagnostics expose the table's bucket order. By binding and rebinding chosen NETLINK_USERSOCK port IDs, an unprivileged reader can distinguish equal buckets and recover the low bits of the Jenkins hash. Its 32-bit seed and the limited set of kernel-image slides can then be searched offline to recover the address of init_net. Use the namespace's unique, non-address net_cookie in the comparison key instead. It is assigned before the per-net initializers run and remains unchanged for the namespace's lifetime. The lookup key and object hash are still built by netlink_compare_arg_init(), keeping lookup, insertion, removal and rehashing consistent while preserving namespace separation. Neither public table walker needs to change. Reading the socket's namespace cookie in netlink_compare() is safe under RCU, including during namespace teardown. netlink_release() removes the socket from the hash table and defers its final put with call_rcu(). cleanup_net() runs the per-net exit methods and waits for outstanding RCU callbacks with rcu_barrier() before freeing namespace storage. Unlike ns.ns_id, net_cookie is also available and initialized during setup_net() in older stable kernels, making the change straightforward to backport to v5.15 and later. Fixes: c428ecd1a21f ("netlink: Move namespace into hash key") Assisted-by: LLM Signed-off-by: Kyle Zeng Reviewed-by: Simon Horman Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20261008011359.63727-2-kylebot@openai.com Signed-off-by: Paolo Abeni commit dbc393f6f009a2bf7e4a22ef2d70b53f533f20f4 Author: Wei Liu Date: Thu Oct 15 00:48:50 2026 -0700 MAINTAINERS: drop KY from Hyper-V maintainers list KY has retired from Microsoft. Signed-off-by: Wei Liu commit ec6b083915e8146e147314a5f4f1285d07b57bfc Author: Stanley Jhu Date: Tue Oct 13 21:27:08 2026 +0800 scsi: bsg: Pass reply_len to bsg_setup_queue() to fit UFS ARPMB replies bsg-lib allocates a 96-byte (SCSI_SENSE_BUFFERSIZE) reply buffer per job, but struct ufs_rpmb_reply is 104 bytes: a 40-byte struct ufs_bsg_reply followed by a 64-byte EHS. When an Advanced RPMB command returns an EHS, ufshcd_advanced_rpmb_req_handler() copies it right after the 40-byte header and writes 8 bytes past the end of the buffer. Let each BSG transport pass its reply buffer size to bsg_setup_queue() and have ufs_bsg request sizeof(struct ufs_rpmb_reply), so the full reply reaches user space. Other transports keep SCSI_SENSE_BUFFERSIZE. Fixes: 6ff265fc5ef6 ("scsi: ufs: core: bsg: Add advanced RPMB support in ufs_bsg") Cc: stable@vger.kernel.org Signed-off-by: Stanley Jhu Link: https://patch.msgid.link/20261013132708.1669415-1-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) commit 81e097a064b28b4a1f6ca1a8b433e659c1bd64c0 Author: Xingui Yang Date: Mon Sep 28 12:02:34 2026 +0800 scsi: libsas: Fix SMP IO deadlock during HA resume smp_execute_task_sg() calls pm_runtime_get_sync() on the host before issuing an SMP command. When that command is itself issued from the HA resume path, the get_sync() deadlocks: it waits for the ongoing resume (the device is RPM_RESUMING), while the resume is blocked in sas_drain_work() waiting for that same SMP IO to complete. The deadlock needs an expander-attached SATA disk. During sas_resume_ha() -> sas_drain_work(), DISCE_RESUME -> sas_resume_sata() -> ata_sas_port_resume() requests ATA_EH_RESET, and the hard reset for such a disk is done via SMP PHY CONTROL (sas_ata_hard_reset() -> sas_phy_reset() -> sas_smp_phy_control() -> smp_execute_task_sg()). Direct-attached SATA resets through lldd_control_phy() and SSP devices use TMFs, so neither hits this. Replace the get_sync()/put_sync() pair with pm_runtime_get_noresume()/pm_runtime_put(). smp_execute_task_sg() only needs to hold off autosuspend while the SMP is in flight, and it must not try to resume the host: a sync resume issued from the HA resume path itself is what deadlocks, and by the time sas_resume_ha() runs, hw_init has already reinitialized the hardware, so the device is accessible without one. The usage reference is still required. Discovery work normally runs inside an event worker's PM reference, taken at sas_notify_port_event() notify time and held until the handler has flushed the disco queue. sas_rediscover_ex_phy() however requeues DISCE_REVALIDATE_DOMAIN from within the revalidation worker itself, and flush_workqueue() does not wait for work items queued during execution, so that chained revalidation runs with no outer PM reference - without the get_noresume(), its SMP could race autosuspend. For the BSG path, sas_smp_handler() is the only caller which may find the host autosuspended: expander SMP requests do not go through any SCSI device request queue, so nothing else in that path holds the host awake. Resume it there with pm_runtime_resume_and_get() and check the result. Fixes: 3dbbbf656b850 ("scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race") Signed-off-by: Xingui Yang Reviewed-by: John Garry Link: https://patch.msgid.link/20260928040234.992912-1-yangxingui@huawei.com Signed-off-by: Martin K. Petersen (Oracle) commit 66c658033d842bb75f81f20aaa4a378fe47be1a1 Author: Martin Kaiser Date: Wed Oct 14 10:37:40 2026 +0200 tracing: probes: error if BTF is required but unavailable traceprobe_expand_meta_args expands probe arguments based on BTF info. Return an error if we have arguments that need expanding but BTF is not supported. The params variable is now unused, it can be removed. Link: https://lore.kernel.org/all/20261014083838.31020-1-martin@kaiser.cx/ Fixes: d157d7694460 ("tracing/probes: Support BTF field access from $retval") Signed-off-by: Martin Kaiser Reviewed-by: Steven Rostedt Signed-off-by: Masami Hiramatsu (Google) commit 9fee1f650a0a9ea6fa7c0b26244a778dd92542d5 Merge: db7afcbf9eef65 d1a4549a3645e5 Author: Linus Torvalds Date: Wed Oct 14 16:11:57 2026 -0700 Merge tag 'wq-for-7.3-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq Pull workqueue fix from Tejun Heo: - Fix a NULL dereference in the check for whether the current task is running a memory reclaim work item when called from a kworker outside work item execution * tag 'wq-for-7.3-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: Fix NULL current_pwq deref in mem-reclaim helper commit c9fc60c18b6d42efdea0cd88ca132b2f452157c3 Author: Vincent Donnefort Date: Tue Oct 13 11:20:46 2026 +0100 ring-buffer: Skip si_mem_available() for persistent and remote buffers Persistent and remote buffer memory is pre-allocated by the time __rb_allocate_pages() is called. Skip si_mem_available() to avoid wrongly failing the allocation under memory pressure. For the same reason, unset user_thread. Link: https://patch.msgid.link/20261013102047.1488347-2-vdonnefort@google.com Fixes: be68d63a139b ("ring-buffer: Add ring_buffer_alloc_range()") Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt commit 2cd88c498ecff8e22bf4c397b8eb226db70ac343 Author: Christian Brauner Date: Fri Oct 9 23:51:54 2026 +0200 eventfs: Free the eventfs_inode after an rcu grace period too tracefs_d_revalidate() reads ->is_freed of the eventfs_inode that dentry->d_fsdata points to, and ->d_revalidate() is called in rcu pathwalk mode with nothing but rcu_read_lock() held. The dentry itself stays around for such a walker, but tracefs_d_release() drops its reference to the eventfs_inode when the dentry is killed, and release_ei() then frees it after a grace period of eventfs_srcu. An SRCU grace period doesn't wait for rcu_read_lock() sections, so the walker can read an eventfs_inode that is already gone. With a pathwalk held up in tracefs_d_revalidate() while the dentry goes away: BUG: KASAN: slab-use-after-free in tracefs_d_revalidate+0x76/0x90 Read of size 1 at addr ff1100010152d8d0 by task walker/97 Call Trace: tracefs_d_revalidate+0x76/0x90 lookup_fast+0x320/0x640 path_lookupat+0x160/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 vfs_fstatat+0x4d/0x90 __do_sys_newfstatat+0xa0/0x100 do_syscall_64+0x10e/0x5e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [...] Allocated by task 1: __kmalloc_cache_noprof+0x249/0x560 eventfs_create_dir+0x7a/0x590 event_create_dir+0x2fb/0xcf0 trace_add_event_call+0xbf/0x150 [...] Freed by task 11: kfree+0x1db/0x5b0 srcu_invoke_callbacks+0x3a3/0x620 process_one_work+0x937/0x1810 worker_thread+0x4f1/0xd60 Before commit 8e556432477e ("eventfs: Use SRCU for freeing eventfs_inodes") release_ei() used call_rcu(), which covered the walker, while eventfs_iterate() needs the SRCU grace period. Wait for both and chain call_rcu() from the SRCU callback. Cc: stable@vger.kernel.org Fixes: 8e556432477e ("eventfs: Use SRCU for freeing eventfs_inodes") Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-4-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Steven Rostedt commit b3b974008388ab59e44d764ba7a63c988fec2524 Author: Amit Machhiwal Date: Fri Oct 9 22:05:56 2026 +0530 tracing: Do not initialize tracefs work if tracing is disabled If trace buffer allocation fails during early boot (e.g. in early_trace_init() -> allocate_trace_buffers()), tracing_disabled is left set to 1 and the global trace array events list remains uninitialized. Later during boot, tracer_init_tracefs() (invoked via fs_initcall) queues tracerfs_init_work asynchronously without checking if tracing was disabled. When tracer_init_tracefs_work_func() runs, it calls event_trace_init() and init_tracer_tracefs(&global_trace, NULL) unconditionally. This leads to __find_event_file() dereferencing an uninitialized tr->events list, causing an early boot NULL pointer dereference Oops: BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000485be0 Oops: Kernel access of bad area, sig: 7 [#1] ... NIP [c000000000485be0] __find_event_file+0x70/0x3c0 LR [c000000000448874] init_tracer_tracefs+0x274/0xc80 Call Trace: init_tracer_tracefs+0x274/0xc80 tracer_init_tracefs_work_func+0x50/0x320 process_one_work+0x1e8/0x5c0 worker_thread+0x1dc/0x3d0 kthread+0x194/0x1b0 start_kernel_thread+0x14/0x18 Check tracing_disabled at the beginning of tracer_init_tracefs_work_func() and return immediately if tracing is disabled or failed to initialize, preventing the crash. Cc: stable@vger.kernel.org Fixes: 6621a7004684 ("tracing: make tracer_init_tracefs initcall asynchronous") Link: https://patch.msgid.link/20261009163557.88467-2-amachhiw@linux.ibm.com Reported-by: Michal Suchánek Closes: https://lore.kernel.org/all/arYskzbiaNzBR9MD@kunlun.suse.cz/ Signed-off-by: Amit Machhiwal Tested-by: Michal Suchánek Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt commit 9414ca3b99e5a7f1f3bf51c2a01b383e1b355dd0 Author: Tengda Wu Date: Tue Sep 29 10:40:15 2026 +0000 tracing: Fix hist trigger timestamps for buffered events Syzkaller triggered a WARN_ON_ONCE(!nest) warning: WARNING: kernel/trace/ring_buffer.c:821 at ring_buffer_event_time_stamp Call trace: ring_buffer_event_time_stamp hist_field_timestamp hist_fn_call event_hist_trigger event_triggers_call __event_trigger_test_discard trace_event_buffer_commit do_trace_event_raw_event_sched_switch trace_event_raw_event_sched_switch The warning is probabilistically reproducible and is related to syzkaller executing the following commands: echo 'prev_pid == 999999' > events/sched/sched_switch/filter echo 'hist:keys=common_timestamp' > events/sched/sched_switch/trigger The specific triggering process is as follows: CPU 0 CPU 1 (context switching) (echo 'hist:keys=common_timestamp' > \ events/sched/sched_switch/trigger) do_trace_event_raw_event_##call trace_event_buffer_lock_reserve if (!tr->no_filter_buffering_ref && trace_file->flags & EVENT_FILE_FL_FILTERED) return entry; // return directly event_hist_trigger_parse hist_register_trigger tracing_set_filter_buffering(file->tr, true); tr->no_filter_buffering_ref++; __trace_buffer_lock_reserve rb_start_commit local_inc(&cpu_buffer->committing); // skipped and not executed trace_event_buffer_commit __event_trigger_test_discard event_triggers_call event_hist_trigger hist_fn_call hist_field_timestamp ring_buffer_event_time_stamp nest = local_read(&cpu_buffer->committing); WARN_ON_ONCE(!nest) // trigger warning The root cause is that when an event file has a filter attached and the hist trigger has not yet been attached, trace_event_buffer_lock_reserve() writes the event into the per-CPU trace_buffered_event temp buffer instead of reserving it in the ring buffer, so cpu_buffer->committing is not incremented. When the event is later processed at commit time by a hist trigger, hist_field_timestamp() -> ring_buffer_event_time_stamp() sees a zero committing count, triggering WARN_ON_ONCE(!nest). tracing_event_time_stamp() was added by commit d8279bfc5e959 ("tracing: Add tracing_event_time_stamp() API") for exactly this case: if the event is the per-CPU trace_buffered_event, it returns the current ring buffer timestamp. But it never gained a caller. Use it in hist_field_timestamp(), so that a hist trigger that races onto a buffered event records the current time, which is only marginally later than when the event was recorded, instead of warning and recording a bogus timestamp. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260929104015.1689921-1-wutengda@huaweicloud.com Fixes: b94bc80df648 ("tracing: Use a no_filter_buffering_ref to stop using the filter buffer") Signed-off-by: Tengda Wu Signed-off-by: Steven Rostedt commit 3110d09bb98e3ac66482a7b257548a1683ec6c1a Author: Dmitry Kandybka Date: Mon Sep 28 18:26:32 2026 +0300 tracing: Fix ignored return value of resize_buffer_duplicate_size() When tr->allocated_snapshot is true, resize_buffer_duplicate_size() is called to update the snapshot buffer size. However, its return value was not checked. In case of a failed resize this could lead next snapshot being incomplete. Add resize_buffer_duplicate_size() result check and return error if resize fails. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260928152634.4354-1-d.kandybka@gmail.com Fixes: 180e4e390978 ("tracing: Add snapshot refcount") Signed-off-by: Dmitry Kandybka Signed-off-by: Steven Rostedt commit 89bab1dba8a0167ef0d819e0f55b6bafa038e87f Author: Krystian Kaniewski Date: Thu Sep 24 10:49:42 2026 +0200 ring-buffer: Fix false warning in ring_buffer_map_get_reader() The mmap reader can warn when it catches up with a writer that is still committing events. rb_get_reader_page() returns NULL in this case, but ring_buffer_map_get_reader() treats that result as an error. The initial rb_per_cpu_empty() check filters out an empty buffer, but it does not guarantee that the next reader page has committed data. Writers do not take reader_lock and can advance commit_page before publishing the committed length on the new page. rb_get_reader_page() can swap to that page, catch up with the writer and return NULL. Handle NULL through the existing no-data exit without warning. Remove the caller's reader_page == commit_page check as well, since the reader-page helper already handles that case. The existing metadata update and return path remain in place. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260924084946.20104-1-krystianmkaniewski@gmail.com Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions") Assisted-by: Gemini:gemini-3.8-flash syzbot Reported-by: syzbot+de3d7f9bcc9212f3fae1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=de3d7f9bcc9212f3fae1 Link: https://syzkaller.appspot.com/ai_job?id=488adc18-a10e-42d2-a205-25327c38837f Signed-off-by: Krystian Kaniewski Reviewed-by: Vincent Donnefort Signed-off-by: Steven Rostedt commit 0fa993581aaa58a34ae3dcebebe0fbf593fcb441 Author: Vincent Donnefort Date: Wed Sep 23 08:42:13 2026 +0100 tracing: Fix simple_ring_buffer undef check on sparc64 simple_ring_buffer relies on headers that end up including . On sparc64, this emits the undefined symbol current_thread_info_reg. Allow this symbol. Link: https://patch.msgid.link/20260923074213.3077182-4-vdonnefort@google.com Fixes: 1211907ac0b5 ("tracing: Generate undef symbols allowlist for simple_ring_buffer") Reported-by: Guenter Roeck Closes: https://lore.kernel.org/all/5574c9e6-9ed2-4ee6-a2b2-fb6ee81e83a1@roeck-us.net/ Signed-off-by: Vincent Donnefort Tested-by: Guenter Roeck Signed-off-by: Steven Rostedt commit ba875c4483359ad4c056e00d3da089c7db56bea6 Author: Vincent Donnefort Date: Wed Sep 23 08:42:12 2026 +0100 tracing: Fix simple_ring_buffer undef check on parisc simple_ring_buffer uses local_set() and cmpxchg() on unsigned long. Add them to undefsyms_base.c to extend the allowlist for the parisc architecture. Link: https://patch.msgid.link/20260923074213.3077182-3-vdonnefort@google.com Fixes: 1211907ac0b5 ("tracing: Generate undef symbols allowlist for simple_ring_buffer") Reported-by: Guenter Roeck Closes: https://lore.kernel.org/all/5574c9e6-9ed2-4ee6-a2b2-fb6ee81e83a1@roeck-us.net/ Signed-off-by: Vincent Donnefort Tested-by: Guenter Roeck Signed-off-by: Steven Rostedt commit c902b6d709845def1d1d3ab818e0b9d9b962ab16 Author: Vincent Donnefort Date: Wed Sep 23 08:42:11 2026 +0100 tracing: Fix empty symbol names in simple_ring_buffer undef check Sparc64 emits empty symmbol names. Skips them when establishing the allowlist and when extracing undefined symbols. Link: https://patch.msgid.link/20260923074213.3077182-2-vdonnefort@google.com Fixes: 1211907ac0b5 ("tracing: Generate undef symbols allowlist for simple_ring_buffer") Reported-by: Guenter Roeck Closes: https://lore.kernel.org/all/5574c9e6-9ed2-4ee6-a2b2-fb6ee81e83a1@roeck-us.net/ Signed-off-by: Vincent Donnefort Tested-by: Guenter Roeck Signed-off-by: Steven Rostedt commit db7afcbf9eef65aa8bfe6edb5ff4b4a92d1a4792 Merge: e177c722b3dd9a 2935062be77113 Author: Linus Torvalds Date: Wed Oct 14 15:58:16 2026 -0700 Merge tag 'sched_ext-for-7.3-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext Pull sched_ext fixes from Tejun Heo: - A task that skipped the BPF scheduler on its way back to its CPU's local queue could stall there until the watchdog fired, as the CPU had already decided to go idle. - Use-after-free of a destroyed user dispatch queue by a deferred re-enqueue request. - A task could be moved off a dispatch queue while the dispatching CPU was still running ops.dequeue() on it. - Bypass mode mishandled a sub-scheduler bypass overlapping an ancestor's, as across a system suspend. Descendants could leave bypass mid-teardown and tasks could be stranded on bypass queues. - The idle CPU selection helper could return a CPU outside the allowed CPUs of a pinned or migration-disabled task. * tag 'sched_ext-for-7.3-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: Wait for SCX_OPSS_DISPATCHING before moving tasks off DSQs sched_ext: Rename scx_reenq_wait_dispatching() to scx_wait_dispatching() sched_ext: idle: Respect task affinity in restricted CPU selection sched_ext: Fix the bypass dispatch claim for schedulers bypassed by an ancestor sched_ext: Propagate every bypass depth change to the descendants sched_ext: Fix use-after-free of a destroyed user DSQ by a deferred reenqueue sched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQ commit e177c722b3dd9ad432195b5c2cbbfe58c909a821 Merge: 0fcb05b72344f4 4e9f69d0825347 Author: Linus Torvalds Date: Wed Oct 14 15:50:48 2026 -0700 Merge tag 'pci-v7.3-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fixes from Bjorn Helgaas: - Leave ANFE masked on Apple T2 Secure Enclave, which fixes spontaneous poweroff regressions on MacBookPro16,1 and likely other models with the T2 caused by new Advisory Non-Fatal Error support (Jason Perlow) - Move dw-rockchip INTx IRQ setup from rockchip_pcie_host_init(), where it runs after every reset, to the rockchip_pcie_probe() path to avoid installing new IRQ handler (which causes INTx IRQs to be lost) and leaking an IRQ domain on every reset; fixes a regression added this cycle (Shawn Lin) * tag 'pci-v7.3-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: dw-rockchip: Move INTx IRQ setup to probe PCI/AER: Keep ANFE masked on Apple T2 Secure Enclave commit 25132363c723afc39aace8b098f547ab4a0ea759 Author: Donggeun Yoo Date: Fri Sep 18 16:15:07 2026 +0900 ring-buffer: Fix the sub-buffer array base in rb_meta_subbuf_idx() On a persistent ring buffer, rb_meta_subbuf_idx() can return an index one sub-buffer too high. rb_setup_ids_meta_page() then fills subbuf_ids[] shifted by one and leaves subbuf_ids[0] NULL, which __rb_map_vma() dereferences when userspace maps trace_pipe_raw. rb_update_meta_reader() writes two such indices into meta->buffers[], which rb_cpu_meta_valid() would reject on the next boot, discarding the previous boot's trace. A CPU's sub-buffer array starts after its meta header and the nr_subbufs integers that follow, aligned up to a sub-buffer. rb_meta_subbuf_idx() inverts that calculation but skips only the integers, not the header, so its base is one sub-buffer low whenever the omitted header size crosses the alignment boundary. Invert the calculation with rb_subbufs_from_meta() rather than repeating it. rb_range_buffer() maps an index back to an address through the same helper, so the two directions can no longer disagree. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260918071507.1019251-1-donggeunyoo.kernel@gmail.com Fixes: b14d032973d4 ("ring-buffer: Add ring_buffer_meta data") Signed-off-by: Donggeun Yoo Reviewed-by: Vincent Donnefort Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt commit 647c2f97fcb94bc642cefe6db004999974563f06 Author: Donggeun Yoo Date: Wed Sep 16 09:27:35 2026 +0900 tracing: Fix the shift out of bounds in the log2 histogram modifier The .log2 key modifier files a value under its base-2 order: # echo 'hist:keys=bytes_req.log2' > events/kmem/kmalloc/trigger hist_field_log2() computes that as ilog2(roundup_pow_of_two(val)). The out-of-line form of roundup_pow_of_two() is return 1UL << fls_long(n - 1); which shifts by 64 on a 64-bit kernel both when n is 0, where n - 1 wraps to ULONG_MAX, and when n is above 2^63. Both are ordinary keys, because the field fetch hands every value over as a u64: a syscall argument of 0 reaches the first, and one above 2^63 reaches the second. Keying sys_enter_lseek on offset.log2 and passing 0, 1, 2, 3, 1000, 2^63+1 and U64_MAX gives { offset: ~ 2^1 } hitcount: 1 { offset: ~ 2^10 } hitcount: 1 { offset: ~ 2^2 } hitcount: 1 { offset: ~ 2^0 } hitcount: 4 Keys above 2^63 land in the lowest bucket. With CONFIG_UBSAN_SHIFT=y the shift is also reported: UBSAN: shift-out-of-bounds in include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' __ubsan_handle_shift_out_of_bounds.cold+0xdd/0x1cb hist_fn_call.cold+0x8b/0xd9 event_hist_trigger+0x1cc/0x790 ftrace_syscall_enter+0x197/0x360 do_syscall_64+0x402/0x4b0 Use order_base_2(), which is ilog2(n - 1) + 1 for n > 1 and 0 below that. It returns what the old expression returned on every input the old one was defined for. Where it was not, 0 stays in bucket 0, which is where x86_64 had been putting it, and the keys above 2^63 move into bucket 64. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260916002735.808520-1-donggeunyoo.kernel@gmail.com Fixes: 4b94f5b7b4a5 ("tracing: Add hist trigger 'log2' modifier") Signed-off-by: Donggeun Yoo Assisted-by: Claude:claude-fable-5 Signed-off-by: Steven Rostedt commit 3f23cae09a4677a3f7c163a68388512cb231ff22 Author: David Carlier Date: Mon Sep 14 14:35:05 2026 +0100 ring-buffer: Do not show buffer_meta for CPUs without a buffer The per_cpu/cpuN/buffer_meta files are created for every possible CPU, but buffer->buffers[cpu] is only allocated once that CPU comes online. Reading the file of a CPU that never came online dereferences a NULL cpu_buffer in rbm_start(). Fail the open with -ENODEV when the CPU has no buffer, as the other per CPU ring buffer interfaces do. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914133506.4865-3-devnexen@gmail.com Fixes: 950032ffcee7 ("ring-buffer: Add output of ring buffer meta page") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260913134906.6E8A01F000FF@smtp.kernel.org/ Signed-off-by: David Carlier Signed-off-by: Steven Rostedt commit 2afe7575fb24b9d0476ae4a3a9862f7997216aa4 Author: David Carlier Date: Mon Sep 14 14:35:04 2026 +0100 tracing: Take trace_types_lock when dropping the buffer_meta reference tracing_buffer_meta_open() drops the trace_array reference with __trace_array_put() when ring_buffer_meta_seq_init() fails, without holding trace_types_lock. Use trace_array_put() like every other open error path. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914133506.4865-2-devnexen@gmail.com Fixes: 950032ffcee7 ("ring-buffer: Add output of ring buffer meta page") Signed-off-by: David Carlier Signed-off-by: Steven Rostedt commit a0777b9e53157f1f6848a0fd0650f5465391ea81 Author: Donggeun Yoo Date: Mon Sep 14 14:34:43 2026 +0900 tracing: Fix NULL dereference when copying keys for a field variable In event_hist_trigger_parse() where it needs to create actions like "onmatch", it calls: event_hist_trigger_parse() { create_actions() { action_create() { trace_action_create() { trace_action_create_field_var() { create_field_var_hist() Where create_field_var_hist() does a loop on the hist_data representing the keys. The issue is, if the keys uses one of the pseudo field types (like common_cpu), the hist_data field element will have NULL for its field member causing a NULL pointer dereference when accessing the key_field->field->name. # echo 'hist:keys=common_cpu:ts0=common_timestamp.usecs' > \ events/sched/sched_waking/trigger # echo 'my_synth u64 lat; int prio' > synthetic_events # echo 'hist:keys=common_cpu:wakeup_lat=common_timestamp.usecs-$ts0:\ onmatch(sched.sched_waking).my_synth($wakeup_lat,prio)' > \ events/sched/sched_switch/trigger KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:create_field_var_hist+0x771/0x1380 Call Trace: trace_action_create_field_var+0x360/0x600 trace_action_create+0x393/0xe80 event_hist_trigger_parse+0x3e47/0x69e0 trigger_process_regex+0x1a6/0x250 event_trigger_write+0xce/0x160 Instead of accessing it directly, use the proper handler expr_field_str() to get the name. The three previous patches are prerequisites: without them a .buckets key and a common_stacktrace key each render into a command that cannot be parsed back. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914053443.981201-5-donggeunyoo.kernel@gmail.com Fixes: 02205a6752f2 ("tracing: Add support for 'field variables'") Signed-off-by: Donggeun Yoo Assisted-by: Claude:claude-fable-5 Signed-off-by: Steven Rostedt commit 906f04fb1ebfed7b00ef33faa98499fc4f0e609d Merge: a7064be65fda06 eadfe727dd800f Author: Christian Brauner Date: Wed Oct 14 21:46:27 2026 +0200 Merge patch series "namespace: a mount that copy_tree() leaves out can't take over a lock" Christian Brauner says: Since commit c62a4766937e ("move_mount: transfer MNT_LOCKED") a mount can be moved beneath a locked mount. The lock moves from the old cover to the new mount which takes over the job of hiding what's under it and the old cover can be unmounted. That works as long as the new mount stays. But the caller picks the new mount and copy_tree() leaves a mount of a mount namespace file out of every copy made without CL_COPY_MNT_NS_FILE, together with everything mounted on it, and never looks at MNT_LOCKED. unshare(CLONE_NEWNS) and mount propagation make such copies. So a task that is root in its own user namespace gets rid of a locked cover on a file without a race and without touching the filesystem below it. It makes a child with a mount namespace of its own, binds the child's /proc//ns/mnt beneath the cover with MOVE_MOUNT_BENEATH, which hands the lock to that bind, and calls unshare(CLONE_NEWNS). The new mount namespace has nothing on the file. That's the usual way to mask a single file, a bind of /dev/null or of an empty file. With a bind of an ordinary file the file stays covered. copy_tree() already refuses to leave out a locked unbindable mount with -EPERM since commit df7342b24018 ("mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts"). Do the same for a locked mount of a mount namespace file. That also covers a tree copied with CL_COPY_MNT_NS_FILE and attached into a mount namespace of another user namespace where lock_mnt_tree() locks it. Note that unshare(CLONE_NEWNS) and clone(CLONE_NEWNS) fail with EPERM from such a mount namespace from then on. The mount can't be left out and it can't be unmounted. And refuse to move a mount of a mount namespace file beneath a locked mount in the first place. Otherwise the task ends up with a mount it can't unmount and an unshare() that fails for good. * patches from https://patch.msgid.link/20261014-work-namei-locked-mnt_ns_file-v1-0-24035bd5d8e9@kernel.org: selftests/filesystems: test that a mntns file can't take over a lock namespace: a mount that copy_tree() leaves out can't take over a lock Link: https://patch.msgid.link/20261014-work-namei-locked-mnt_ns_file-v1-0-24035bd5d8e9@kernel.org Signed-off-by: Christian Brauner (Amutable) commit a7064be65fda06712a73f858561e04591af74494 Merge: 98b6cf102b35b2 d2bdb9b61b4276 Author: Christian Brauner Date: Tue Oct 13 20:46:08 2026 +0200 Merge patch series "fs: don't let idle threads pin the initramfs" Christian Brauner says: Since v7.0 nullfs is the real rootfs and userspace can pivot_root() away from the initramfs and unmount it. systemd does exactly that and the initramfs is supposed to be freed afterwards. But it isn't (cf. [1]). The unpacked initramfs stays around forever. It shows up as Unevictable in /proc/meminfo with ramfs and as Shmem with tmpfs. In the reports that's between 70MB and 150MB. Two things keep it alive and neither is visible from userspace: (1) On v7.0 to v7.2 devtmpfsd unshares a copy of the initial mount namespace which since nullfs contains the initramfs mount. It doesn't show up in /proc//mountinfo because it's below the thread's root. That's already fixed in mainline by commit 66d2faeccbff ("devtmpfs: create private mount namespace"). (2) On all kernels since v7.0 the idle threads of the secondary cpus are forked from PID 1 and each of them gets a private copy of the fs_struct of PID 1 with the initramfs as root and pwd. Idle threads aren't on the task list so pivot_root() never moves them over to the new root and they never exit. With a single possible cpu there are no such idle threads which is why booting a VM with -smp 1 hides it. This series fixes (2) by letting the idle threads share init_fs like init_task already does. The first patch turns the umh boolean of copy_fs() into flags. The second patch is the actual fix and carries a reproducer. systemd could go back to emptying the initramfs when switching root like it did before nullfs and that's what [2] does. But that only frees the contents. The mount and the superblock stay pinned. And I don't think userspace should have to do that. With nullfs it's supposed to be able to just unmount the initramfs and be done with it. We could also teach chroot_fs_refs() about idle threads. But they are kernel threads and have no business holding a reference to the root of userspace to begin with. Of the stable kernels only v7.2 is affected and the backport looks different there. PID 1 still shares init_fs with all kthreads so passing CLONE_FS in fork_idle() is enough. It also needs 66d2faeccbff which applies cleanly. I've tested this with the reproducer from the second patch and with a systemd 262 initrd on 4 cpus. On vfs.fixes about 170MB stay Unevictable after switching root and with this series they're freed. Same for the backport on v7.2. [1]: https://github.com/systemd/systemd/issues/43911 [2]: https://github.com/systemd/systemd/pull/44144 * patches from https://patch.msgid.link/20261013-work-fs-idle_fs-v1-0-2063d1bcb5aa@kernel.org: fs: let idle threads share init_fs fs: pass flags to copy_fs() Link: https://patch.msgid.link/20261013-work-fs-idle_fs-v1-0-2063d1bcb5aa@kernel.org Signed-off-by: Christian Brauner (Amutable) commit eadfe727dd800fc5fca33e45dbfd392ade5bbbd6 Author: Christian Brauner Date: Wed Oct 14 21:45:14 2026 +0200 selftests/filesystems: test that a mntns file can't take over a lock Add a case to the locked mount test: - a bind of the mount namespace file of a grandchild moved beneath a locked cover must fail with EINVAL - a bind of an ordinary file beneath it takes the lock over, the old cover can go and the new one can't - the file is still covered after unshare(CLONE_NEWNS) Link: https://patch.msgid.link/20261014-work-namei-locked-mnt_ns_file-v1-2-24035bd5d8e9@kernel.org Signed-off-by: Christian Brauner (Amutable) commit d2bdb9b61b42766ed66eef822370ad44435f40fe Author: Christian Brauner Date: Tue Oct 13 00:11:07 2026 +0200 fs: let idle threads share init_fs With nullfs as the real rootfs userspace can pivot_root() away from the initramfs and unmount it: chdir(rootfs); pivot_root(".", "."); umount2(".", MNT_DETACH); That's what systemd does and the initramfs is supposed to go away at that point together with all the memory it uses. But on every machine with more than one possible cpu the initramfs superblock stays around forever (cf. [1]). With ramfs as rootfs the unpacked initramfs shows up as Unevictable in /proc/meminfo, with tmpfs as Shmem, and it is never freed. In the reports that's between 70MB and 150MB. The idle threads of the secondary cpus are created by fork_idle() from smp_init(). That runs in kernel_init(), i.e., in PID 1, after init_userspace_fs() moved PID 1 from nullfs into the initramfs. fork_idle() doesn't pass CLONE_FS so each idle thread gets a private copy of PID 1's fs_struct and with it a reference to the initramfs as root and as pwd. pivot_root() relies on chroot_fs_refs() to move everyone whose root or pwd is the old root over to the new root. Idle threads aren't on the task list though so chroot_fs_refs() never finds them. They never exit either. So they keep the initramfs mount and with it the superblock alive for good. I overlooked this when I added nullfs. Before that the rootfs could never be unmounted anyway so it didn't matter what pinned it. Idle threads are kernel threads and init_task, the idle thread of the boot cpu, already uses init_fs. So let the idle threads of the other cpus share init_fs as well instead of copying PID 1's filesystem state. Note that kernels before 7.3 need a different backport. There PID 1 still shares init_fs with all kthreads so passing CLONE_FS in fork_idle() is enough. They also have a second pin: devtmpfsd unshares a copy of the initial mount namespace, initramfs mount included. That was fixed in commit 66d2faeccbff ("devtmpfs: create private mount namespace"). Reproducer, as /init in an initramfs together with a 128MB ballast file, booted with root=/dev/sda to get ramfs and with -smp 4: // SPDX-License-Identifier: GPL-2.0 /* initramfs /init: switch root like systemd, check the old root */ #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include #include static void meminfo(void) { char line[256]; FILE *f = fopen("/proc/meminfo", "re"); while (f && fgets(line, sizeof(line), f)) if (!strncmp(line, "Unevictable:", 12) || !strncmp(line, "Shmem:", 6)) fputs(line, stdout); if (f) fclose(f); } int main(int argc, char *argv[]) { struct stat st; char dev[32], buf[32]; unsigned int maj, min; int fd, in, out; long r; if (argc > 1) { sleep(2); meminfo(); /* ustat() only finds live superblocks */ r = syscall(SYS_ustat, (unsigned)atoi(argv[1]), buf); printf("initramfs superblock %s\n", r ? "freed" : "pinned"); fflush(stdout); sleep(1); reboot(RB_POWER_OFF); } mount("proc", "/proc", "proc", 0, NULL); mount("devtmpfs", "/dev", "devtmpfs", 0, NULL); /* drop the fds console_on_rootfs() opened in the initramfs */ fd = open("/dev/console", O_RDWR); dup2(fd, 0); dup2(fd, 1); dup2(fd, 2); close(fd); setvbuf(stdout, NULL, _IOLBF, 0); meminfo(); stat("/", &st); maj = major(st.st_dev); min = minor(st.st_dev); /* new_encode_dev(), what ustat() expects */ snprintf(dev, sizeof(dev), "%u", (min & 0xff) | (maj << 8) | ((min & ~0xffu) << 12)); mkdir("/sysroot", 0755); mount("tmpfs", "/sysroot", "tmpfs", 0, NULL); mkdir("/sysroot/proc", 0755); mkdir("/sysroot/dev", 0755); in = open("/init", O_RDONLY); out = open("/sysroot/init", O_WRONLY | O_CREAT, 0755); fstat(in, &st); sendfile(out, in, NULL, st.st_size); close(in); close(out); mount(NULL, "/", NULL, MS_REC | MS_PRIVATE, NULL); mount("/proc", "/sysroot/proc", NULL, MS_BIND | MS_REC, NULL); mount("/dev", "/sysroot/dev", NULL, MS_BIND | MS_REC, NULL); chdir("/sysroot"); if (syscall(SYS_pivot_root, ".", ".") || umount2(".", MNT_DETACH)) perror("pivot_root"); execl("/init", "/init", dev, NULL); return 1; } Before: Unevictable: 131812 kB Shmem: 0 kB Unevictable: 131812 kB Shmem: 792 kB initramfs superblock pinned After: Unevictable: 131812 kB Shmem: 0 kB Unevictable: 0 kB Shmem: 792 kB initramfs superblock freed With -smp 1 the superblock is freed without this patch as well. [1]: https://github.com/systemd/systemd/issues/43911 Fixes: 576ee5dfd459 ("fs: add immutable rootfs") Link: https://patch.msgid.link/20261013-work-fs-idle_fs-v1-2-2063d1bcb5aa@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 69fbe94f80bc423613fa18dae6656757423732a2 Author: Christian Brauner Date: Wed Oct 14 21:45:13 2026 +0200 namespace: a mount that copy_tree() leaves out can't take over a lock Since commit c62a4766937e ("move_mount: transfer MNT_LOCKED") a mount can be moved beneath a locked mount. The lock moves from the old cover to the new mount which takes over the job of hiding what's under it and the old cover can be unmounted. That works as long as the new mount stays. But the caller picks the new mount and copy_tree() leaves a mount of a mount namespace file out of every copy made without CL_COPY_MNT_NS_FILE, together with everything mounted on it, and never looks at MNT_LOCKED. unshare(CLONE_NEWNS) and mount propagation make such copies. So a task that is root in its own user namespace gets rid of a locked cover on a file without a race and without touching the filesystem below it. It makes a child with a mount namespace of its own, binds the child's /proc//ns/mnt beneath the cover with MOVE_MOUNT_BENEATH, which hands the lock to that bind, and calls unshare(CLONE_NEWNS). The new mount namespace has nothing on the file. That's the usual way to mask a single file, a bind of /dev/null or of an empty file. With a bind of an ordinary file the file stays covered. copy_tree() already refuses to leave out a locked unbindable mount with -EPERM since commit df7342b24018 ("mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts"). Do the same for a locked mount of a mount namespace file. That also covers a tree copied with CL_COPY_MNT_NS_FILE and attached into a mount namespace of another user namespace where lock_mnt_tree() locks it. Note that unshare(CLONE_NEWNS) and clone(CLONE_NEWNS) fail with EPERM from such a mount namespace from then on. The mount can't be left out and it can't be unmounted. And refuse to move a mount of a mount namespace file beneath a locked mount in the first place. Otherwise the task ends up with a mount it can't unmount and an unshare() that fails for good. Chris also found a second mount that goes away by itself, a clone of an automounted mount that shrink_submounts() took along with its parent. Commit f78ddcc87224 ("namespace: never expire a locked mount") took care of that one. Chris's reproducer is appended. Mode nsfile reads SECRET after the unshare() on 7.3-rc7, with this patch the move_mount() fails with EINVAL and the file stays covered. nsfile-control uses an ordinary file and reads MASK both ways. // SPDX-License-Identifier: GPL-2.0 /* * Get rid of a locked cover with MOVE_MOUNT_BENEATH. * * The "admin" (root) makes a tmpfs W: * W/D file, holds SECRET, covered by a bind of a file with MASK * W/Dd/inner file, holds SECRET, Dd is covered by a bind of a directory * whose "inner" holds MASK * W/own directory of uid 1000 with the file "mine" and the * directory "minedir", whose "inner" holds MINE * W/dbg debugfs, mode 755. dbg/tracing is an automount point * The "attacker" is uid 1000. It enters a new user namespace with a new mount * namespace, so W and both covers are locked there. * * usage: prog MODE * plain put a bind of own/mine beneath the cover of D, unmount the cover * nsfile put a bind of the mount namespace file of a child beneath the * cover of D, then unshare(CLONE_NEWNS) * nsfile-control the same with a bind of own/mine * shrink put a bind of the automounted tracefs beneath the cover of Dd, * unmount the cover, put a tmpfs beneath W, call umount(W), which fails * shrink-control the same with a bind of own/minedir * The environment variable AUTOMOUNT_DIR names another automount point for "shrink". */ #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include #include #include #include #ifndef MOVE_MOUNT_BENEATH #define MOVE_MOUNT_BENEATH 0x00000200 #endif #define W "/run/x2" static void die(const char *what) { fprintf(stderr, "FATAL %s: %s\n", what, strerror(errno)); exit(2); } static void put_file(const char *name, const char *content) { int fd = open(name, O_CREAT | O_WRONLY | O_TRUNC, 0644); if (fd < 0 || write(fd, content, strlen(content)) < 0) die(name); close(fd); } static void show(const char *path) { char buf[32] = ""; int fd = open(path, O_RDONLY); if (fd < 0) { printf("attacker: open(%s) = %s\n", path, strerror(errno)); return; } if (read(fd, buf, sizeof(buf) - 1) < 0) snprintf(buf, sizeof(buf), "<%s>", strerror(errno)); close(fd); printf("attacker: read(%s) = \"%s\"%s\n", path, buf, strncmp(buf, "SECRET", 6) ? "" : " <-- HIT"); } static int say(const char *what, int ret) { printf("attacker: %s: %s\n", what, ret ? strerror(errno) : "ok"); return ret; } static void write_str(const char *path, const char *s) { int fd = open(path, O_WRONLY); if (fd < 0 || write(fd, s, strlen(s)) < 0) die(path); close(fd); } static void mounts(void) { if (system("grep x2 /proc/self/mountinfo")) printf("attacker: no mounts listed\n"); } static void admin_setup(void) { if (unshare(CLONE_NEWNS) || mount(NULL, "/", NULL, MS_REC | MS_PRIVATE, NULL)) die("unshare"); mkdir(W, 0755); if (mount("W", W, "tmpfs", 0, "mode=755")) die("mount W"); if (mkdir(W "/Dd", 0755) || mkdir(W "/maskdir", 0755) || mkdir(W "/dbg", 0755) || mkdir(W "/own", 0755) || mkdir(W "/own/minedir", 0755)) die("mkdir"); put_file(W "/D", "SECRET"); put_file(W "/Dd/inner", "SECRET"); put_file(W "/mask", "MASK"); put_file(W "/maskdir/inner", "MASK"); put_file(W "/own/mine", "MINE"); put_file(W "/own/minedir/inner", "MINE"); if (mount(W "/mask", W "/D", NULL, MS_BIND, NULL) || mount(W "/maskdir", W "/Dd", NULL, MS_BIND, NULL)) die("covers"); if (mount("dbg", W "/dbg", "debugfs", 0, "mode=755")) die("mount debugfs"); } static void become_attacker(void) { if (setgroups(0, NULL) || setresgid(1000, 1000, 1000) || setresuid(1000, 1000, 1000) || prctl(PR_SET_DUMPABLE, 1)) die("drop to uid 1000"); if (unshare(CLONE_NEWUSER | CLONE_NEWNS)) die("unshare user and mount namespace"); write_str("/proc/self/setgroups", "deny"); write_str("/proc/self/uid_map", "0 1000 1"); write_str("/proc/self/gid_map", "0 1000 1"); } /* clone the mount at @src and put the clone beneath the top mount at @where */ static int beneath(const char *src, const char *where) { char what[128]; int fd = open_tree(AT_FDCWD, src, OPEN_TREE_CLONE | OPEN_TREE_CLOEXEC); int ret; snprintf(what, sizeof(what), "open_tree(%s, OPEN_TREE_CLONE)", src); if (say(what, fd < 0)) return -1; ret = move_mount(fd, "", AT_FDCWD, where, MOVE_MOUNT_F_EMPTY_PATH | MOVE_MOUNT_BENEATH); snprintf(what, sizeof(what), "move_mount(clone, %s, MOVE_MOUNT_BENEATH)", where); say(what, ret); close(fd); return ret; } static void do_nsfile(int control) { char path[64] = W "/own/mine"; int pfd[2]; pid_t pid; char c; if (pipe(pfd)) die("pipe"); pid = fork(); if (pid < 0) die("fork"); if (!pid) { if (unshare(CLONE_NEWNS) || write(pfd[1], "g", 1) != 1) die("child"); pause(); exit(0); } if (read(pfd[0], &c, 1) != 1) die("sync"); if (!control) snprintf(path, sizeof(path), "/proc/%d/ns/mnt", pid); beneath(path, W "/D"); mounts(); say("unshare(CLONE_NEWNS)", unshare(CLONE_NEWNS)); show(W "/D"); mounts(); kill(pid, SIGKILL); waitpid(pid, NULL, 0); } static void do_shrink(int control) { const char *automount = getenv("AUTOMOUNT_DIR"); int fd, mfd; if (!automount) automount = W "/dbg/tracing"; beneath(control ? W "/own/minedir" : automount, W "/Dd"); say("umount2(Dd, 0), the old cover", umount2(W "/Dd", 0)); say("umount2(Dd, 0), the mount that was put beneath", umount2(W "/Dd", 0)); show(W "/Dd/inner"); say("umount2(W, 0)", umount2(W, 0)); fd = fsopen("tmpfs", FSOPEN_CLOEXEC); if (fd < 0 || fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0)) die("fsopen tmpfs"); mfd = fsmount(fd, FSMOUNT_CLOEXEC, 0); if (mfd < 0) die("fsmount"); say("move_mount(new tmpfs, W, MOVE_MOUNT_BENEATH)", move_mount(mfd, "", AT_FDCWD, W, MOVE_MOUNT_F_EMPTY_PATH | MOVE_MOUNT_BENEATH)); close(mfd); mounts(); say("umount2(W, 0)", umount2(W, 0)); show(W "/Dd/inner"); mounts(); } int main(int argc, char **argv) { const char *mode = argc > 1 ? argv[1] : "plain"; setvbuf(stdout, NULL, _IOLBF, 0); admin_setup(); become_attacker(); show(W "/D"); show(W "/Dd/inner"); say("umount2(D, MNT_DETACH)", umount2(W "/D", MNT_DETACH)); say("umount2(Dd, MNT_DETACH)", umount2(W "/Dd", MNT_DETACH)); if (!strcmp(mode, "plain")) { beneath(W "/own/mine", W "/D"); show(W "/D"); say("umount2(D, MNT_DETACH), the old cover", umount2(W "/D", MNT_DETACH)); show(W "/D"); say("umount2(D, MNT_DETACH), the mount that was put beneath", umount2(W "/D", MNT_DETACH)); show(W "/D"); mounts(); } else if (!strncmp(mode, "nsfile", 6)) { do_nsfile(!strcmp(mode, "nsfile-control")); } else { do_shrink(!strcmp(mode, "shrink-control")); } return 0; } Fixes: c62a4766937e ("move_mount: transfer MNT_LOCKED") Reported-by: Chris Mason Cc: stable@vger.kernel.org # v7.1+ Link: https://patch.msgid.link/20261014-work-namei-locked-mnt_ns_file-v1-1-24035bd5d8e9@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 98b6cf102b35b2bb48d1fd74d5f664eb66fe83eb Author: Christian Brauner Date: Mon Oct 12 14:57:04 2026 +0200 namei: test for a negative dentry the way traverse_mounts() does lookup_fast_for_open() only hands an O_CREAT open a cached dentry if it's positive. Otherwise the open goes on to lookup_open(), which takes the directory lock and creates the file. It tests for that with !dentry->d_inode, but traverse_mounts() later decides with the type in d_flags. And when a dentry is instantiated __d_set_inode_and_type() stores ->d_inode first and only then releases the type into ->d_flags. So a refwalk that took its reference to a negative dentry right before another task instantiates it can find ->d_inode already set in lookup_fast_for_open(), go on to step_into(), and still find the negative type in traverse_mounts(). The open then fails with -ENOENT, which an O_CREAT open must never do. rcuwalk doesn't get that far, the d_seq check in step_into() catches the instantiation. Use d_is_negative() so both look at the type. While the type is still negative the open takes lookup_open() and waits for the directory lock like any other O_CREAT open of a negative dentry. On its own the window is a couple of instructions in the creating task, so it takes an interrupt or a preempted vcpu in exactly the right spot. I haven't caught it without help in about 600 million racing O_CREAT opens. The debug patch below stalls the creating task between the two stores for names starting with "ocrace", the way an interrupt landing there would. The reproducer below opens "ocrace" with O_CREAT through symlinks on a strictatime tmpfs: following them updates their atime, which drops the walk out of rcuwalk, so the name is always looked up in refwalk. With echo 20 > /proc/sys/fs/ocrace_instantiate_us ./ocreat_enoent -t 60 on a KASAN kernel open() failed with -ENOENT 43 times in 4.9 million calls. With this patch it never failed in 4.8 million calls. Tracing step_into_slowpath() during such a run, each of the 98 -ENOENTs it returned came right after the same task had entered it with a dentry that was still typed negative. // SPDX-License-Identifier: GPL-2.0 /* * ocreat_enoent: open(O_CREAT) racing the creation of the same name. * * Writers unlink "ocrace" and create it again. Readers open it with * O_CREAT through a symlink of their own on a strictatime tmpfs. * Following the symlink updates its atime, which drops the walk out of * rcu mode, so the name is always looked up in refwalk. An O_CREAT open * must never fail with ENOENT. * * -p arms a cpu-clock perf timer with that period in ns on every writer, * so that interrupts land at random points in it. * * usage: ocreat_enoent [-t secs] [-w writers] [-r readers] [-p ns] */ #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include #include #include #define DIR "/tmp/oc" static atomic_int stop; static atomic_long opens, creates, enoent, other; static long period; static void die(const char *what) { fprintf(stderr, "FATAL %s: %s\n", what, strerror(errno)); exit(2); } static void *writer(void *arg) { (void)arg; if (period) { struct perf_event_attr attr = { .type = PERF_TYPE_SOFTWARE, .size = sizeof(attr), .config = PERF_COUNT_SW_CPU_CLOCK, .sample_period = period, }; if (syscall(SYS_perf_event_open, &attr, 0, -1, -1, 0) < 0) die("perf_event_open"); } while (!atomic_load(&stop)) { int fd; unlink(DIR "/ocrace"); fd = open(DIR "/ocrace", O_CREAT | O_RDWR | O_CLOEXEC, 0644); if (fd >= 0) close(fd); atomic_fetch_add(&creates, 1); } return NULL; } static void *reader(void *arg) { char lnk[64]; snprintf(lnk, sizeof(lnk), DIR "/lnk.%ld", (long)arg); while (!atomic_load(&stop)) { int fd = open(lnk, O_CREAT | O_RDWR | O_CLOEXEC, 0644); if (fd >= 0) close(fd); else if (errno == ENOENT) atomic_fetch_add(&enoent, 1); else atomic_fetch_add(&other, 1); atomic_fetch_add(&opens, 1); } return NULL; } int main(int argc, char **argv) { int secs = 60, nw = 4, nr = 12, c, n = 0; pthread_t t[256]; while ((c = getopt(argc, argv, "t:w:r:p:")) != -1) { switch (c) { case 't': secs = atoi(optarg); break; case 'w': nw = atoi(optarg); break; case 'r': nr = atoi(optarg); break; case 'p': period = atol(optarg); break; default: return 2; } } if (nw + nr > 256) return 2; mkdir(DIR, 0755); if (mount("oc", DIR, "tmpfs", MS_STRICTATIME, "mode=0755")) die("tmpfs"); for (long i = 0; i < nr; i++) { char lnk[64]; snprintf(lnk, sizeof(lnk), DIR "/lnk.%ld", i); if (symlink("ocrace", lnk)) die("symlink"); } for (long i = 0; i < nw; i++) if (pthread_create(&t[n++], NULL, writer, NULL)) die("writer"); for (long i = 0; i < nr; i++) if (pthread_create(&t[n++], NULL, reader, (void *)i)) die("reader"); sleep(secs); atomic_store(&stop, 1); for (int i = 0; i < n; i++) pthread_join(t[i], NULL); printf("%ds: %ld opens, %ld creates, ENOENT %ld, other errors %ld\n", secs, atomic_load(&opens), atomic_load(&creates), atomic_load(&enoent), atomic_load(&other)); umount2(DIR, MNT_DETACH); return atomic_load(&enoent) ? 1 : 0; } diff --git a/fs/dcache.c b/fs/dcache.c --- a/fs/dcache.c +++ b/fs/dcache.c @@ -32,9 +32,13 @@ #include #include #include +#include #include "internal.h" #include "mount.h" +/* debug: stall "ocrace*" names between ->d_inode and the type */ +static int sysctl_ocrace_instantiate_us; + #include /* @@ -200,6 +204,13 @@ } static const struct ctl_table fs_dcache_sysctls[] = { + { + .procname = "ocrace_instantiate_us", + .data = &sysctl_ocrace_instantiate_us, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = proc_dointvec, + }, { .procname = "dentry-state", .data = &dentry_stat, @@ -405,6 +416,10 @@ unsigned flags; dentry->d_inode = inode; + /* debug: an interrupt landing right here */ + if (unlikely(READ_ONCE(sysctl_ocrace_instantiate_us)) && + !strncmp(dentry->d_name.name, "ocrace", 6)) + udelay(READ_ONCE(sysctl_ocrace_instantiate_us)); flags = READ_ONCE(dentry->d_flags); flags &= ~DCACHE_ENTRY_TYPE; flags |= type_flags; Fixes: e747e15156b7 ("fs: try an opportunistic lookup for O_CREAT opens too") Cc: stable@vger.kernel.org # v6.12+ Link: https://patch.msgid.link/20261012-work-namei-ocreate-v1-1-c7883b17ee28@kernel.org Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner (Amutable) commit 9cd0df397a119d6b95ad68e2c82b69b4d620694e Author: Christian Brauner Date: Tue Oct 13 00:11:06 2026 +0200 fs: pass flags to copy_fs() Turn the umh boolean into a flags argument. Idle threads need their own case in copy_fs() as well and that's nicer than a second boolean. No functional changes. Link: https://patch.msgid.link/20261013-work-fs-idle_fs-v1-1-2063d1bcb5aa@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 99ae7dc439249b47a72eda07f78e02290fa1aebc Author: Guanglei Zhu Date: Mon Oct 12 17:55:38 2026 +0800 ovl: reject lowerdir ending with unescaped backslash In ovl_parse_param_split_lowerdirs() a backslash consumes the character that follows it. When the backslash is the last character of the lowerdir value, it consumes the NUL terminator: the loop exits normally and the backslash is kept in the output, so the lowerdir is passed downstream with a trailing backslash and the mount fails later with a confusing ENOENT from path lookup. A trailing unescaped backslash escapes nothing, so reject it with EINVAL. Signed-off-by: Guanglei Zhu Link: https://patch.msgid.link/20261012095538.938789-1-zhugl3@xiaopeng.com Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Amutable) commit 36ebddca56b9d8993d6dc984fdecc748ee1f5e06 Author: Kyle Zeng Date: Fri Oct 2 05:59:02 2026 +0000 fsnotify: prevent mark additions during connector teardown fsnotify_destroy_marks() keeps a reference to its current mark while it drops conn->lock to destroy the mark. This stabilizes the forward-walk cursor, but does not prevent a new mark from being inserted before it. For example, an inotify watch re-added after IN_IGNORED sorts before the old, detached mark for the same group. The walk can miss the replacement and then detach the entire connector from the object. The replacement is still on its group's marks_list and, for inotify, in the watch IDR. The group mutex no longer protects the connector's object from disappearing. An unprivileged fdinfo read racing the final detach can consequently call igrab(NULL): BUG: KASAN: null-ptr-deref in igrab+0x24/0x100 Write of size 4 at addr 0000000000000148 Call Trace: igrab+0x24/0x100 inotify_show_fdinfo+0x1dc/0x5e0 seq_show+0x397/0x690 Set a DESTROYING flag under conn->lock before starting the walk, and reject new marks on that connector with -ENOENT. The existing add-mark error paths undo the temporary group-list entry and the backend's watch allocation. Do not wait for teardown while holding the group mutex, which the destroyer needs. Once the old connector is detached, an add can install a fresh connector as before. This closes the insertion race for all object types using the common connector teardown, without changing the mark reference or SRCU lifetime rules. Fixes: 6b3f05d24d35 ("fsnotify: Detach mark from object list when last reference is dropped") Cc: stable@vger.kernel.org Signed-off-by: Kyle Zeng Signed-off-by: Christian Brauner (Amutable) commit 40d38f58fcfa1ddbe1b1046c32e23998d945967a Merge: 81933038f5e273 a291a5cf0023ef Author: Christian Brauner Date: Mon Oct 12 12:22:17 2026 +0200 Merge patch series "fs: drop the smp_mb()s that mnt_get_count() made redundant" Christian Brauner says: mntput_no_expire_slowpath() and do_umount() both have an smp_mb() between taking mount_lock and summing up the reference count. They pair with the smp_mb() in __legitimize_mnt(). The walker increments the count and then re-reads the seqcount. The unmounter writes the seqcount when it takes mount_lock and then sums up the count. They must not both miss each other's store. That's store buffering and it needs a full barrier on both sides. Since 7eb84d54fac5 ("fs: don't let a migrating task hide its reference from do_umount()"), which is in mainline now, mnt_get_count() has an smp_mb() between summing up the puts and the gets. In program order it sits after the seqcount write and before the loads of the gets. That's the barrier the walker needs. The outer ones don't order anything on top of it that anyone relies on. So drop them. I ran into this while getting rid of the grace period in namespace_unlock(). It doesn't depend on that work so I'm sending it on its own. A reproducer can't exercise this. The pairing is store buffering with a full barrier on both sides, which is exactly tools/memory-model/litmus-tests/SB+fencembonceonces.litmus: the walker's increment is the store to x and its re-read of the seqcount the load of y, the seqcount write in lock_mount_hash() is the store to y and the loads of the gets in mnt_get_count() the load of x. I had two litmus tests cut from fs/namespace.c in the series for this. Andrea pointed out that once the seqlock and the lock are peeled off that's all that's left of them, so I dropped them. They and their runs under the AArch64, POWER, RISC-V, MIPS and ARM models and with klitmus7 on x86 are in https://github.com/brauner/linux-formal kernel/mount/gp-on-demand-proposal/litmus/ * patches from https://patch.msgid.link/20261011-work-mount-fixes-5-v1-0-a9b9a8ecf565@kernel.org: fs: drop the smp_mb()s that mnt_get_count() made redundant Link: https://patch.msgid.link/20261011-work-mount-fixes-5-v1-0-a9b9a8ecf565@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 81933038f5e273d17ed22792f906889393b204c5 Author: Aviv Vaknin Date: Fri Oct 2 23:28:20 2026 +0300 pid_namespace: make zap_pid_ns_processes() freezable When the init of a pid namespace exits, zap_pid_ns_processes() waits until all other pids in the namespace are freed. A tracer outside the namespace that does not reap its traced zombies keeps those pids allocated, so this wait has no upper bound, and while it lasts every suspend attempt fails: Freezing user space processes failed after 20.006 seconds (2 tasks refusing to freeze, wq_busy=0): Neither wait is freezable. The first loop sleeps in do_wait(), which returns -ERESTARTSYS on the freezer's fake signal; the loop then clears TIF_SIGPENDING and waits again without ever freezing. The final loop sleeps in TASK_INTERRUPTIBLE, and since nothing clears TIF_SIGPENDING there, schedule() returns immediately after the first freeze attempt and the task spins until the wait ends. Sleep in TASK_INTERRUPTIBLE | TASK_FREEZABLE in do_wait(), so that the freezer can freeze tasks waiting there directly, and in TASK_IDLE | TASK_FREEZABLE in the final loop, like coredump_task_exit() does. This was hit with Chromium-based browsers: crashpad ptrace-attaches the threads of a crashed renderer, which is a pid namespace init, and does not reap those killed during the dump. Fixes: 3eb07c8c8adb ("pid namespaces: destroy pid namespace on init's death") Fixes: b9a985db9896 ("pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes") Cc: stable@vger.kernel.org # 6.1+ Suggested-by: Oleg Nesterov Signed-off-by: Aviv Vaknin Link: https://patch.msgid.link/20261002202820.3433318-1-vaknins33@gmail.com Acked-by: Oleg Nesterov Reviewed-by: Bradley Morgan Signed-off-by: Christian Brauner (Amutable) commit a291a5cf0023ef3a854a85549f2301da9f24d55b Author: Christian Brauner Date: Sun Oct 11 17:30:44 2026 +0200 fs: drop the smp_mb()s that mnt_get_count() made redundant Both mntput_no_expire_slowpath() and do_umount() have an smp_mb() between taking mount_lock and summing up the reference count. They pair with the smp_mb() in __legitimize_mnt(). A walker in __legitimize_mnt() increments the count and then re-reads the seqcount of mount_lock. The unmounter writes the seqcount when it takes mount_lock and then sums up the count. They must not both miss each other's store. Otherwise the walker keeps a reference to a mount that the unmounter finishes off. That's the store buffering pattern and it needs a full barrier between the store and the load on both sides. In commit 119e1ef80ecf ("fix __legitimize_mnt()/mntput() race") the barrier in the slow path of mntput_no_expire() as added and the one in do_umount() in commit 65781e19dcfc ("do_umount(): add missing barrier before refcount checks in sync case"). Back then mnt_get_count() didn't have a barrier of its own. Since commit 7eb84d54fac5 ("fs: don't let a migrating task hide its reference from do_umount()") it does. It sums up the puts, does an smp_mb() and then sums up the gets. In program order that barrier sits after the seqcount write in lock_mount_hash() and before the loads of the gets. That's all the walker needs. If the sum misses the walker's increment the walker sees the seqcount change and drops its reference under mount_lock where it finds MNT_DOOMED or MNT_SYNC_UMOUNT. The only thing the outer barrier orders on top of that is the seqcount write against the loads of the puts and nothing relies on it: (1) A put from the fast path of mntput_no_expire() never looks at the seqcount. If the sum misses such a put that's what the grace period is for. (2) All other puts happen under mount_lock and are ordered by it. (3) The slow path's own decrement right before the sum is a store on the same cpu and is read back in program order. So the outer barriers don't order anything that the inner one doesn't. That argument is made in the kernel memory model and every architecture has to implement its barriers according to it. herd7 against tools/memory-model agrees. Without the outer smp_mb() the walker against the slow path and against the busy check in do_umount() is "Never". If the inner smp_mb() goes as well it's "Sometimes". The litmus tests for this are in the next patch. Make the comments in __legitimize_mnt() and mnt_get_count() point at each other. Link: https://patch.msgid.link/20261011-work-mount-fixes-5-v1-1-a9b9a8ecf565@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 65676cd4203c0e41a94caf54080a7f0a95434bda Author: Sung Byeongchan Date: Thu Oct 8 02:35:42 2026 +0900 autofs: ignore notification errors from a replaced pipe autofs_notify_daemon() takes a reference to the current notification pipe under wq_mutex, then drops the mutex before writing the request. The write can block while the daemon enters catatonic mode and installs a replacement pipe. If the old pipe's reader is then closed, the delayed write returns -EPIPE and the generic error path enters catatonic mode again. That transition acts on the current superblock state, closes the replacement pipe, and releases the new daemon generation's wait queues. Only enter catatonic mode when the pipe which failed is still the current pipe. Factor the already-locked transition so the identity check and state change are atomic with respect to another replacement. This was reproduced on v7.3-rc5-337-gff47652a4b66c in a local QEMU guest. An unprivileged UID 65534 lookup filled the old packet pipe before a normal CATATONIC/SETPIPEFD restart. On the unmodified kernel, the new pipe received HUP and both a pending victim lookup and a later lookup failed with ENOENT in two out of two fresh-mount runs. With this change, the new pipe remained active, received an intact 304-byte request, and both victim lookups completed in two out of two runs. Normal lookup and restart-without-a-blocked-writer controls passed. No KASAN, oops, refcount, or lock diagnostic was observed. A source reproducer and complete local logs are available privately on request. The demonstrated impact is limited to denial of a shared autofs service during a legitimate daemon restart. No memory corruption, information leak, privilege escalation, or code execution primitive was observed. Fixes: 8d7b48e0bc5fa ("autofs4: add miscellaneous device for ioctls") Cc: stable@vger.kernel.org Signed-off-by: Sung Byeongchan Link: https://patch.msgid.link/20261007173542.593624-1-tjdqudcks0424@naver.com Acked-by: Ian Kent Signed-off-by: Christian Brauner (Amutable) commit c68b15ae11753dd84adf1e0fcd25fb3c288d6243 Merge: 5e531d62f1f883 56c3824de56b52 Author: Christian Brauner Date: Mon Oct 12 10:49:56 2026 +0200 Merge patch series "fs: fix a range of UAFs during rcu pathwalk caused by non-rcu frees" Christian Brauner says: While working on eliding the grace period in namespace_unlock() I went through what filesystems free when they're shut down and what a pathwalk in rcu mode can still read at that point. Since 66a97c2ec953's rcu pathwalk fixes that's the filesystem's job. Whatever ->permission(), ->d_revalidate(), ->get_link(), ->d_hash() and ->d_compare() look at in rcu mode has to be freed after a grace period. A few filesystems don't do that. Most of it is hidden by umount(2). namespace_unlock() waits for a grace period before it drops the mounts, so a walker that was inside the filesystem is gone by the time the filesystem is shut down. But the last reference to a mount doesn't have to go away in umount(2). A chdir() out of a lazily unmounted directory or the close() of the last file on it drops it without a grace period. A walker can then still be in the filesystem while ->put_super() and ->kill_sb() free what it reads. With KASAN on vfs.fixes: - ext4_get_link() reads sb->s_fs_info and the extent status counters in rcu mode for a symlink that keeps its target in a data block. ext4_put_super() destroys the counters, clears s_fs_info and frees the sbi right away. That's a NULL dereference, a use-after-free of the sbi or a fault on a destroyed percpu counter, depending on where the walker sits. - The unicode map of casefolded ext4, f2fs and tmpfs is freed from ->put_super() while generic_ci_d_hash() and generic_ci_d_compare() use it. - ntfs3 with nocase frees its sbi and mount options under ntfs_d_hash() and ntfs_d_compare(). A remount frees the old mount options right away too, that one needs no unmount at all. - eventfs frees an eventfs_inode after an SRCU grace period only, but tracefs_d_revalidate() reads it under rcu_read_lock(). No unmount needed either. The ipc patch is a different kind of bug. create_ipc_ns() leaks the mqueue mount and its superblock when it fails after mq_init_ns(). I ran into it while looking at the kern_unmount() users. afs and 9p look just as broken but nothing can reach it today. Both have a private bdi, and generic_shutdown_super() calls bdi_unregister(), which waits for a grace period before ->kill_sb() frees their private data. That grace period is there for the rcu readers of bdi_list and covers afs and 9p by accident. I don't want them to depend on that, so they free their private data after a grace period of their own as well. I appended the reproducers. The race reproducers hold a pathwalk inside the filesystem's callback for two seconds with a kprobe while the other side frees what it reads. For the ntfs3 remount the window is a single load and its dereference, so that one needs an mdelay() in the kernel. ext4 with a journal needs a kernel without lockdep since jbd2_journal_destroy() calls lockdep_unregister_key(), which waits for a grace period too. Clean this all up. * patches from https://patch.msgid.link/20261009-work-fixes-rcu-v1-0-7446d2d335e6@kernel.org: ntfs3: free replaced mount options after a grace period ntfs3: free the sbi after a grace period unicode: free the map after a grace period ipc: drop the mqueue mount with kern_unmount() on setup failure eventfs: free the eventfs_inode after an rcu grace period too 9p: free the session after a grace period afs: free the super info after a grace period ext4: free the sbi after a grace period Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-0-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 56c3824de56b5275c02ff6b6aa27ddbacfbb9b25 Author: Christian Brauner Date: Fri Oct 9 23:51:58 2026 +0200 ntfs3: free replaced mount options after a grace period ntfs_fs_reconfigure() replaces the old mount options with new mount options in sbi->options. The old mount options land in fs_context and are freed as soon as remount returns. With a pathwalk held up in ntfs_nls_to_utf16() between loading sbi->options and dereferencing it while a remount replaces them: BUG: KASAN: slab-use-after-free in ntfs_nls_to_utf16+0x7ae/0x7c0 Read of size 8 at addr ff110001044fd448 by task walker/98 Call Trace: ntfs_nls_to_utf16+0x7ae/0x7c0 ntfs_d_hash+0x22b/0x500 link_path_walk+0x11ad/0x1d30 path_lookupat+0x63/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 [...] Allocated by task 95: __kmalloc_node_track_caller_noprof+0x2a2/0x730 kmemdup_noprof+0x25/0x50 ntfs_fill_super+0x1e5/0x4550 [...] Freed by task 97: kfree+0x1db/0x5b0 put_fs_context+0x13c/0x7d0 path_mount+0x54a/0x2130 __x64_sys_mount+0x20c/0x270 That info is needed in rcu lookup in the dentry hash and dentry compary methods for ntfs3 and causes a UAF today. Delay freeing with an rcu grace period. ntfs_nls_to_utf16() reads ->nls and ->ads once under rcu_read_lock() so the hooks pair with the release in ntfs_fs_reconfigure(). That also covers callers outside of rcu pathwalk such as ntfs_lookup(). They don't hold rcu_read_lock() themselves and wouldn't be protected by the grace period otherwise. Remount refuses to change the iocharset so ->nls stays valid after rcu_read_unlock(). Fixes: a3a956c78efa ("fs/ntfs3: Add option "nocase"") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-8-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) commit c01b091b06412d3b1b53d8c2925f6de586c8a2fc Author: Christian Brauner Date: Fri Oct 9 23:51:57 2026 +0200 ntfs3: free the sbi after a grace period If the "nocase" mount option ntfs3 uses custom hash and dentry compare functions. Both access ntfs3 superblock private information in rcu pathwalk. ntfs_put_super() and ntfs3_kill_sb() drop the info without any rcu delay. A lookup that's still inside the filesystem when the last reference to the mount is dropped causes a UAF. With a pathwalk held up in ntfs_d_hash() while the last reference to the mount goes away: BUG: KASAN: slab-use-after-free in ntfs_nls_to_utf16+0x752/0x940 Read of size 8 at addr ff1100010453c850 by task walker/99 Call Trace: ntfs_nls_to_utf16+0x752/0x940 ntfs_d_hash+0x22b/0x500 link_path_walk+0x11ad/0x1d30 path_lookupat+0x63/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 [...] Allocated by task 95: __kmalloc_cache_noprof+0x249/0x560 ntfs_init_fs_context+0x2db/0x5a0 alloc_fs_context+0x52e/0xc70 [...] Freed by task 98: kfree+0x1db/0x5b0 deactivate_locked_super+0x9c/0xf0 cleanup_mnt+0x9f/0x130 task_work_run+0x131/0x250 The bug is currently masked by the grace period in namespace_unlock() for umount(2). Keep the necessary information until the filesystem private info is freed and free it with an rcu delay. ntfs3_free_sbi() now runs from an rcu callback and drops the upcase table via ntfs_put_shared(). So switch s_shared_lock over to spin_lock_bh(). Otherwise the callback can deadlock against a task holding the lock on the same cpu. Fixes: a3a956c78efa ("fs/ntfs3: Add option "nocase"") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-7-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) commit a96c5299bd7305eb984377681eb3222a57376405 Author: Christian Brauner Date: Fri Oct 9 23:51:56 2026 +0200 unicode: free the map after a grace period generic_ci_d_hash() and generic_ci_d_compare() read sb->s_encoding and dereference the unicode map while a pathwalk in rcu mode holds nothing but rcu_read_lock(). The filesystems that use them, ext4, f2fs and tmpfs, drop the map with utf8_unload() from ->put_super(), which runs when the last reference to the mount goes away. A lookup that is still inside such a filesystem at that point reads a freed map. With a pathwalk held up in utf8_casefold_hash() while the last reference to a casefolded tmpfs goes away: BUG: KASAN: slab-use-after-free in utf8nlookup+0x74c/0x950 Read of size 8 at addr ff110001030fe658 by task walker/98 Call Trace: utf8nlookup+0x74c/0x950 utf8byte+0x160/0x1560 utf8_casefold_hash+0x167/0x230 generic_ci_d_hash+0xdd/0x1c0 link_path_walk+0x11ad/0x1d30 path_lookupat+0x63/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 [...] Allocated by task 94: __kmalloc_cache_noprof+0x249/0x560 utf8_load+0x4e/0x570 shmem_parse_opt_casefold.isra.0+0x92/0x270 [...] Freed by task 97: kfree+0x1db/0x5b0 shmem_put_super+0x72/0x170 generic_shutdown_super+0x14c/0x530 kill_anon_super+0x3a/0x60 deactivate_locked_super+0x9c/0xf0 cleanup_mnt+0x9f/0x130 So far that has been hard to hit. umount(2) waits for a grace period in namespace_unlock() before it drops the mount, so only a mount whose last reference goes away elsewhere, like the close of a file or a chdir out of a lazily unmounted directory, can race a walker. So it is reachable. Delay the free until a grace period has passed. The map and the data table it holds a reference to then outlive any pathwalk that found the superblock before the mount went away. The reference on the data table module is dropped from the rcu callback as well. utf8-core is built in whenever CONFIG_UNICODE is set, so there is no module exit that would have to wait for the callbacks. Overlayfs points the s_encoding of an overlay at the map of its first layer without taking a reference of its own. That stays correct. The layer is held by the overlay, so its map is dropped only after the overlay is gone. Fixes: b886ee3e778e ("ext4: Support case-insensitive file name lookups") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-6-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) commit f0e48172a59e517e613b73f73cc35f24fd123aeb Author: Christian Brauner Date: Fri Oct 9 23:51:55 2026 +0200 ipc: drop the mqueue mount with kern_unmount() on setup failure mq_init_ns() creates the mqueue mount with fc_mount_longterm(), so its ->mnt_ns is MNT_NS_INTERNAL. When setting up the mqueue or ipc sysctls or msg_init_ns() fails afterwards, create_ipc_ns() drops it with a plain mntput(). With ->mnt_ns set that takes the fast path of mntput_no_expire(). The count drops to zero and nothing ever kills the mount, so the mount and the mqueue superblock are leaked. Commit dc55e35f9e81 ("ipc: Store mqueue sysctls in the ipc namespace") added the first failure path after mq_init_ns() and never dropped the mount. Commit 7229d74e5e8c ("ipc: create_ipc_ns: drop mqueue mount on sysctl setup failure") tried to fix that with a mntput() but that doesn't help for a long-term mount. Use kern_unmount(). free_ipc() open-codes the same thing for a namespace that made it. Fixes: dc55e35f9e81 ("ipc: Store mqueue sysctls in the ipc namespace") Fixes: 7229d74e5e8c ("ipc: create_ipc_ns: drop mqueue mount on sysctl setup failure") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-5-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 6e6928b396685574010244654e3412060b9d8471 Author: Christian Brauner Date: Fri Oct 9 23:51:54 2026 +0200 eventfs: free the eventfs_inode after an rcu grace period too tracefs_d_revalidate() reads ->is_freed of the eventfs_inode that dentry->d_fsdata points to, and ->d_revalidate() is called in rcu pathwalk mode with nothing but rcu_read_lock() held. The dentry itself stays around for such a walker, but tracefs_d_release() drops its reference to the eventfs_inode when the dentry is killed, and release_ei() then frees it after a grace period of eventfs_srcu. An SRCU grace period doesn't wait for rcu_read_lock() sections, so the walker can read an eventfs_inode that is already gone. With a pathwalk held up in tracefs_d_revalidate() while the dentry goes away: BUG: KASAN: slab-use-after-free in tracefs_d_revalidate+0x76/0x90 Read of size 1 at addr ff1100010152d8d0 by task walker/97 Call Trace: tracefs_d_revalidate+0x76/0x90 lookup_fast+0x320/0x640 path_lookupat+0x160/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 vfs_fstatat+0x4d/0x90 __do_sys_newfstatat+0xa0/0x100 do_syscall_64+0x10e/0x5e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [...] Allocated by task 1: __kmalloc_cache_noprof+0x249/0x560 eventfs_create_dir+0x7a/0x590 event_create_dir+0x2fb/0xcf0 trace_add_event_call+0xbf/0x150 [...] Freed by task 11: kfree+0x1db/0x5b0 srcu_invoke_callbacks+0x3a3/0x620 process_one_work+0x937/0x1810 worker_thread+0x4f1/0xd60 Before commit 8e556432477e ("eventfs: Use SRCU for freeing eventfs_inodes") release_ei() used call_rcu(), which covered the walker, while eventfs_iterate() needs the SRCU grace period. Wait for both and chain call_rcu() from the SRCU callback. Fixes: 8e556432477e ("eventfs: Use SRCU for freeing eventfs_inodes") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-4-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) commit bcec7fc2e224088daf94448d663b02e0d0b9c717 Author: Christian Brauner Date: Fri Oct 9 23:51:53 2026 +0200 9p: free the session after a grace period v9fs_vfs_get_link_dotl() reads ->cache from the v9fs_session_info in sb->s_fs_info to decide whether the symlink target sits in the page cache. It does that before it looks at the dentry, so it also does it in rcu pathwalk mode. Without loose or metadata caching the dentries have no ->d_revalidate() that would make the walk leave rcu mode before it gets there. v9fs_kill_super() frees the session and clears sb->s_fs_info without waiting for a grace period. Right now a pathwalk can't still be in v9fs_vfs_get_link_dotl() at that point, but only by accident. umount(2) waits for a grace period in namespace_unlock() before it drops the mount. And a mount whose last reference goes away elsewhere, like the chdir out of a lazily unmounted directory, still gets a grace period from bdi_unregister(). v9fs_fill_super() sets up a private bdi, so generic_shutdown_super() unregisters it from kill_anon_super() and bdi_remove_from_list() waits in synchronize_rcu_expedited() before v9fs_kill_super() frees the session. That grace period protects the rcu readers of bdi_list in the writeback code. It has nothing to do with pathwalk. Don't rely on it. Keep sb->s_fs_info and free the session after a grace period. Fixes: 712da38d134b ("9p: Enable symlink caching in page cache") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-3-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 5e531d62f1f8834faf7a4eed0d41105cf6570a8f Author: Cen Zhang (Microsoft) Date: Fri Oct 9 18:47:15 2026 -0400 watch_queue: Fix note pool publication race in watch_queue_set_size() There is a race between watch_queue_set_size() and post_one_notification(). watch_queue_set_size() publishes wqueue->notes, notes_bitmap, nr_pages and nr_notes with plain stores, and post_one_notification() reads them with plain loads under a different lock, so nothing orders the four stores against the poster's loads: depending on the build, notes can be stored last (gcc 14 on x86-64 does this). Since keyctl_watch_key() lets a watch attach to a queue before it is sized, post_one_notification() can already be running on another CPU at that moment: it reads nr_notes > 0, passes its bounds check, and then reads notes while it is still NULL, dereferencing notes[0]. An unprivileged user triggers this reliably by watching one of its own keys through a notification pipe and racing ioctl(IOC_WATCH_QUEUE_SET_SIZE) on that pipe against keyctl(KEYCTL_SETPERM) on the key from another CPU, triggering: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:post_one_notification.isra.0+0xa2/0x1e0 Call Trace: __post_watch_notification+0x148/0x180 keyctl_setperm_key+0x119/0x130 do_syscall_64+0x108/0x4c0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception in interrupt Fix this by publishing nr_notes last with smp_store_release(), and by reading it once with smp_load_acquire() in post_one_notification() before the bitmap and the page array are touched. A poster that observes a non-zero nr_notes then also observes the pool behind it; one that observes zero drops the notification as before. Fixes: c73be61cede5 ("pipe: Add general notification queue support") Reported-by: Dae R. Jeong Closes: https://lore.kernel.org/all/ZT-S8Q7tyutcvu_q@dragonet/ Reported-by: AutonomousCodeSecurity@microsoft.com Suggested-by: Dae R. Jeong Signed-off-by: Cen Zhang (Microsoft) Link: https://patch.msgid.link/20261009224715.46121-1-cenzhang@linux.microsoft.com Reviewed-by: Bradley Morgan Cc: Signed-off-by: Christian Brauner (Amutable) commit 59e483739f2fd14327ece3f60c4995d060ca46b7 Author: Christian Brauner Date: Fri Oct 9 23:51:52 2026 +0200 afs: free the super info after a grace period afs_atcell_get_link() resolves the @cell and .@cell symlinks of a dynamic root in rcu pathwalk mode. Before it looks at the dentry it gets the afs_net through afs_i2net(), which reads ->net_ns from the afs_super_info in sb->s_fs_info. The @cell dentries are kept around when unused and the dynamic root has no ->d_revalidate(), so a lookup that finds @cell in the dcache gets to ->get_link() in rcu mode. afs_kill_super() frees the afs_super_info with a plain kfree() in afs_destroy_sbi(). Right now a pathwalk can't still be in afs_atcell_get_link() at that point, but only by accident. umount(2) waits for a grace period in namespace_unlock() before it drops the mount. And a mount whose last reference goes away elsewhere, like the chdir out of a lazily unmounted directory, still gets a grace period from bdi_unregister(). afs_fill_super() sets up a private bdi, so generic_shutdown_super() unregisters it from kill_anon_super() and bdi_remove_from_list() waits in synchronize_rcu_expedited() before afs_destroy_sbi() runs. That grace period protects the rcu readers of bdi_list in the writeback code. It has nothing to do with pathwalk. Don't rely on it and free the afs_super_info after a grace period. Fixes: 30bca65bbbae ("afs: Make /afs/@cell and /afs/.@cell symlinks") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-2-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 40bb03d3ea6f6a915218508819ecc4d7a7fa260d Author: Kyle Zeng Date: Fri Oct 2 06:17:05 2026 +0000 pipe: preserve existing fasync readers on writer setup failure F_SETFL and FIOASYNC decide whether to invoke ->fasync() before pipe_fasync() takes pipe->mutex. Two enables of one O_RDWR FIFO can therefore both enter the callback. fasync_helper() allocates before checking for an existing entry. If the first enable installs both entries, a second enable can update the reader entry and then fail the allocation for the writer entry. The error path removes the pre-existing reader entry, clearing FASYNC while the writer entry remains registered. __fput() then skips ->fasync(), so a later pipe notification can dereference the freed file or its f_owner. An unprivileged memory-pressure reproducer triggers a KASAN slab-use-after-free in send_sigio() through this path. Keep the reader helper's result and undo the registration only if this call added it. The pipe mutex serializes changes to both lists, so a failed new registration still removes its reader, while a failed duplicate preserves the existing registrations and FASYNC. Successful duplicate enables continue to update fa_fd as before. Fixes: 76398425bb06 ("Move FASYNC bit handling to f_op->fasync()") Signed-off-by: Kyle Zeng Signed-off-by: Christian Brauner (Amutable) commit c17b44266a1f9fcb49b894d4611d1254bf1aa313 Author: Christian Brauner Date: Fri Oct 9 23:51:51 2026 +0200 ext4: free the sbi after a grace period ext4_get_link() follows a symlink that keeps its target in a data block in rcu pathwalk mode with ext4_getblk(EXT4_GET_BLOCKS_CACHED_NOWAIT). That reads s_mount_state in the ASSERT() of ext4_getblk() and again in ext4_es_lookup_extent(), and the lookup bumps the extent status hit or miss counter, all through sb->s_fs_info. ext4_put_super() destroys those counters, clears sb->s_fs_info and frees the sbi without waiting for a grace period. A pathwalk that is still in ext4_get_link() when the last reference to the mount goes away then dereferences a NULL s_fs_info, the freed sbi or the destroyed percpu counters. With a pathwalk held up in ext4_get_link() while the last reference goes away: KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af] RIP: 0010:ext4_getblk+0xf0/0x640 Call Trace: ext4_get_link+0x26c/0x410 pick_link+0xf96/0x1780 step_into_slowpath+0x9b8/0x1250 path_lookupat+0x484/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 vfs_fstatat+0x4d/0x90 __do_sys_newfstatat+0xa0/0x100 do_syscall_64+0x10e/0x5e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f So far that has been hard to hit. umount(2) waits for a grace period in namespace_unlock() before it drops the mount, so only a mount whose last reference goes away elsewhere, like the close of a file or a chdir out of a lazily unmounted directory, can race a walker. Keep sb->s_fs_info and free the sbi together with the extent status counters after a grace period. Split the counters out of ext4_es_unregister_shrinker() for that. The shrinker still gets wasted in ext4_put_super(), the counters go with the sbi. Fixes: 6493792d3299 ("ext4: convert symlink external data block mapping to bdev") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-1-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 28d2905d77bc2e7c20260a6bc6b4179bdf95cb06 Author: Nickolai Zeldovich Date: Sun Oct 11 08:34:39 2026 -0400 exit: fix lost-update race on the child_subreaper bitfields is_child_subreaper, has_child_subreaper, autoreap and, with CONFIG_POSIX_TIMERS=y, timer_create_restore_ids are 1-bit fields that share one memory location in struct signal_struct. A store to any of them is a read-modify-write of the whole word, and three of the stores run without a common lock: - PR_SET_CHILD_SUBREAPER writes me->signal->is_child_subreaper with no lock held. - propagate_has_child_subreaper(), run by walk_process_tree() from the same prctl in an ancestor, writes p->signal->has_child_subreaper of every descendant p under read_lock(&tasklist_lock), which does not exclude the other writers. - PR_TIMER_CREATE_RESTORE_IDS writes current->signal->timer_create_restore_ids with no lock held. When a process calls prctl(PR_SET_CHILD_SUBREAPER, 1) while an ancestor's PR_SET_CHILD_SUBREAPER walk visits it, or while another thread of the same process calls prctl(PR_TIMER_CREATE_RESTORE_IDS), the read-modify-write sequences interleave and one of the bits is silently lost: - If has_child_subreaper is lost, the process's orphaned descendants are reparented straight to init when it exits: find_new_reaper() tests father->signal->has_child_subreaper first and never looks for the ancestor subreaper. The service manager that registered as the subreaper never gets SIGCHLD for them and cannot wait() on them. - If is_child_subreaper is lost, the prctl returned 0 but the process is not a subreaper: orphans of its descendants skip it and are reparented to the next subreaper up or to init. PR_GET_CHILD_SUBREAPER reads back 0. - If timer_create_restore_ids is lost, the prctl returned 0 but timer_create() does not restore the requested timer ids (or keeps restoring them after _OFF), and _GET reads back the old value. Documentation/memory-barriers.txt requires all fields of one bitfield to be protected by one lock for exactly this reason. No lock is taken or documented for these flags, and the prctls need no privilege, so any process can hit the race against its own ancestors or descendants, or between two of its own threads. Make is_child_subreaper and has_child_subreaper separate bool members. Each store then has its own memory location and no read-modify-write of a neighbour. The readers and their locking are unchanged. autoreap stays a bit-field and so shares a memory location only with timer_create_restore_ids. That pair is race-free: autoreap is stored exactly once, in copy_process() before the new signal_struct is reachable by any other task, and timer_create_restore_ids is only stored to the signal_struct of an already running process. Fixes: 749860ce2427 ("prctl: propagate has_child_subreaper flag to every descendant") Signed-off-by: Nickolai Zeldovich Link: https://patch.msgid.link/20261011123440.768054-1-nickolai@csail.mit.edu Acked-by: Oleg Nesterov Signed-off-by: Christian Brauner (Amutable) commit f1365f97fb7498d805981102eee22d362ae643f2 Author: Sasha Levin Date: Sun Oct 11 18:33:42 2026 -0400 samples: pidfd: fix userprogs typo The Makefile adds pidfd-metadata to "usertprogs-always-y", which kbuild does not know, so the sample has not been built since the conversion to userprogs, even with CONFIG_SAMPLE_PIDFD=y. Fix the variable name. pidfd-metadata.c builds without warnings with gcc and clang for x86_64 and arm64. Fixes: 60fb0b1239719 ("samples: pidfd: build sample program for target architecture") Signed-off-by: Sasha Levin Link: https://patch.msgid.link/20261011223358.2327625-14-sashal@kernel.org Reviewed-by: Christian Brauner Signed-off-by: Christian Brauner (Amutable) commit 4c435828932bf46f29860e4a0375bcae101b778a Author: Cen Zhang Date: Sun Oct 11 23:35:06 2026 +0800 ocfs2/dlm: Protect the recovery list during debugfs reads Recovery participant records must remain alive while debug_state_print() walks reco.node_data and formats their fields. The formatter holds dlm->spinlock, but the recovery participant list is protected by dlm_reco_state_lock. In particular, dlm_destroy_recovery_area() detaches the list under dlm_reco_state_lock and frees the detached records after releasing it. A concurrent debugfs open can therefore read freed memory. Protect the participant traversal and field reads in debug_state_print() with dlm_reco_state_lock, matching the existing list writers. This also serializes the traversal against list_add_tail() during recovery-area initialization. Make the existing lock available to the debug code through dlmcommon.h; the lock remains internal to the OCFS2 DLM module. Release dlm->spinlock after formatting the other domain state and before acquiring dlm_reco_state_lock, so the debug reader does not nest the two locks. Leave recovery list insertion, detachment and freeing unchanged. KASAN report as below: BUG: KASAN: slab-use-after-free in debug_state_open+0x1169/0x12d0 Read of size 4 at addr ffff88810662ef80 by task dlm-state-stres/896 CPU: 1 UID: 0 PID: 896 Comm: dlm-state-stres Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? debug_state_open+0x1169/0x12d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? debug_state_open+0x1169/0x12d0 kasan_report+0xe0/0x110 ? debug_state_open+0x1169/0x12d0 debug_state_open+0x1169/0x12d0 ? __pfx_debug_state_open+0x10/0x10 full_proxy_open_regular+0x193/0x310 do_dentry_open+0x595/0x12d0 ? __pfx_full_proxy_open_regular+0x10/0x10 vfs_open_consume+0xd1/0x400 ? srso_alias_return_thunk+0x5/0xfbef5 path_openat+0x18d0/0x2020 ? __pfx_path_openat+0x10/0x10 do_file_open+0x21e/0x470 ? __pfx_do_file_open+0x10/0x10 ? _raw_spin_unlock+0x23/0x40 ? srso_alias_return_thunk+0x5/0xfbef5 ? alloc_fd+0x3a6/0x6b0 do_sys_openat2+0xf4/0x1b0 ? __pfx_do_sys_openat2+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __fput+0x5b5/0xa60 __x64_sys_openat+0x136/0x1e0 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Register dump omitted.] Allocated by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x28d/0x610 dlm_remaster_locks+0x147/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 Freed by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 dlm_destroy_recovery_area+0x285/0x460 dlm_remaster_locks+0x17c4/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff88810662ef80 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 0 bytes inside of freed 32-byte region [ffff88810662ef80, ffff88810662efa0) [Page and memory-state dumps omitted.] Fixes: 007dce53a29c ("ocfs2/dlm: Dump the dlm state in a debugfs file") Signed-off-by: Cen Zhang Link: https://patch.msgid.link/pm-ocfs2-objects-candidate-0049-v3-184e46c47f5283f06191@gmail.com Reviewed-by: Joseph Qi Signed-off-by: Christian Brauner (Amutable) commit c347fef5f8f8927985bd67835331ce4cf7ff43a4 Author: Erik Faye-Lund Date: Wed Oct 14 09:09:01 2026 +0200 drm/panthor: fix immortalis condition Exactly 10 cores is also valid for an Immortalis configuration, according to the public documentation: https://support.arm.com/compute-ip/immortalis-g715 So let's report this G715 with 10 cores as Immortalis as well, as long as it supports the ray-intersection feature. This matches what we do for more recent GPUs as well. Fixes: 3b1dc21d6d80 ("drm/panthor: Add support for Mali-Gx15 family of GPUs") Signed-off-by: Erik Faye-Lund Reviewed-by: Liviu Dudau Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patch.msgid.link/20261014070902.169273-1-erik.faye-lund@arm.com Signed-off-by: Steven Price commit 0fcb05b72344f40806cbe810de8872f1698bf053 Merge: 4056b3c9d3c92e 7b817748bf083a Author: Linus Torvalds Date: Wed Oct 14 08:23:37 2026 -0700 Merge tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux Pull crypto library fixes from Eric Biggers: "Fix two Poly1305 bugs including a lost carry bit, and add a regression test" * tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: lib/crypto: tests: Add Poly1305 split-update carry regression test lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON state lib/crypto: poly1305: Use memzero_explicit() in poly1305_final() commit 6a8bf59de3ef47ff51face6ea826395a1098baa0 Author: Dnyaneshwar Bhadane Date: Mon Sep 21 14:32:26 2026 +0530 drm/i915/cx0_phy: Fix ARL-S host bridge detection Fix is_arrowlake_s_by_host_bridge() which always returned false. The while loop always exits with pdev as NULL, so the return condition was always false, causing the wrong tx_misc value to be used. Check the host bridge ID inside the loop body. Once found early exit from the loop release the pci reference "pdev" and return true. v2: - Update commit message (Chaitanya) Bspec:74165,74491 Suggested-by: Jani Nikula Cc: Fixes: 3630a47b700e ("drm/i915/cx0_phy: Update HDMI TMDS C20 algorithm value") Signed-off-by: Dnyaneshwar Bhadane Reviewed-by: Chaitanya Kumar Borah Signed-off-by: Chaitanya Kumar Borah Link: https://patch.msgid.link/20260921090226.946472-1-dnyaneshwar.bhadane@intel.com (cherry picked from commit 0507cc5a476af0b6d037b19248bdd20dbe27487d) Signed-off-by: Joonas Lahtinen commit 7dedc5bb11f95e96fe80757c924d8d9aa7327759 Author: Dibin Moolakadan Subrahmanian Date: Tue Sep 22 19:05:38 2026 +0530 drm/i915/dmc: Add sanity check for DMC load address For DMC firmware header version 3, the firmware load address is stored in dmc_info->start_mmioaddr and later used by dmc_load_program(). Unlike the MMIO address table, the firmware load address is not validated. Add a sanity check to ensure it is within the valid range. BSpec: 69671, 68378 Fixes: 3d5928a168a9 ("drm/i915/xelpd: Pipe A DMC plugging") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:Sonnet-5 Signed-off-by: Dibin Moolakadan Subrahmanian Reviewed-by: Mitul Golani Signed-off-by: Ankit Nautiyal Link: https://patch.msgid.link/20260922133535.3180973-6-dibin.moolakadan.subrahmanian@intel.com (cherry picked from commit 5e47ee5c76ca9becde8df4ad5202845b7ffcbc4c) Signed-off-by: Joonas Lahtinen commit 8bb1858db453cd4250e3b633f5d2d09206024ca6 Author: Dibin Moolakadan Subrahmanian Date: Tue Sep 22 19:05:37 2026 +0530 drm/i915/dmc: Harden DMC firmware payload parsing Validate the conversion of the DMC firmware size from dwords to bytes using check_mul_overflow() before calculating the firmware payload size. Reject zero-length payloads and zero MMIO counts in the DMC firmware header so malformed firmware is caught early. Also set dmc_fw_size only after the payload allocation succeeds. Fixes: eb805623d8b1 ("drm/i915/skl: Add support to load SKL CSR firmware.") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:Sonnet-5 Signed-off-by: Dibin Moolakadan Subrahmanian Reviewed-by: Mitul Golani Signed-off-by: Ankit Nautiyal Link: https://patch.msgid.link/20260922133535.3180973-5-dibin.moolakadan.subrahmanian@intel.com (cherry picked from commit efde6601a1f1daedfe3dcc2816c934ddb44e3eef) Signed-off-by: Joonas Lahtinen commit c8f4cfe1cf93bce924e27f2abead7a4c4a487505 Author: Amirmohammad Eftekhar Date: Thu Oct 1 14:43:54 2026 -0700 KVM: nVMX: Reset MMU back to the root MMU if loading L2 state fails for !VM-Entry Reset the vCPU's MMU pointer back to the root MMU if loading L2 state fails in the "not from VM-Entry" case, i.e. when emulating RSM or handling KVM_SET_NESTED_STATE. Failure to unwind the MMU pointer results in KVM trying to run L1 with a nested MMU, and is especially problematic if the vCPU manages to free its nested state before the VM crashes. Constructing the root for a nested EPT MMU goes through vmcs12, which is dynamically allocated/freed when nVMX is enabled/disabled. And so if the nested state is freed with the MMU still pointing at the nested MMU, KVM will hit a NULL pointer deref when attempting to get L1=>L2 EPTP. BUG: kernel NULL pointer dereference, address: 0000000000000078 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 114a2d067 P4D 111743067 PUD 11141f067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 20 UID: 1000 PID: 1272 Comm: nested_tdp_faul Not tainted 7.3.0-rc4-8c89f11d1a99b-sink-vm #1914 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel] Call Trace: kvm_mmu_load+0xcd/0x870 [kvm] kvm_arch_vcpu_ioctl_run+0x18f5/0x1f80 [kvm] kvm_vcpu_ioctl+0x2c7/0x970 [kvm] __x64_sys_ioctl+0x90/0xd0 do_syscall_64+0x9c/0x4d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47491b Modules linked in: kvm_intel kvm irqbypass CR2: 0000000000000078 ---[ end trace 0000000000000000 ]--- RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel] Cc: David Woodhouse Fixes: 72e9cbdb4338 ("KVM: nVMX: fix SMI injection in guest mode") Fixes: 8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE") Cc: stable@vger.kernel.org Signed-off-by: Amirmohammad Eftekhar [sean: write changelog] Signed-off-by: Sean Christopherson Link: https://patch.msgid.link/20261001214356.3825100-2-seanjc@google.com Signed-off-by: Paolo Bonzini commit 81d99abe2bd81379abfb595e403bbbee6fbfc624 Author: EJ Campbell Date: Tue Sep 29 11:12:32 2026 -0700 x86/kvm: Don't consume async #PF flags on a kernel #PF in NMI context An async #PF "page not present" event arrives through the #PF vector, and its reason sits in the per-CPU apf_reason.flags until __kvm_handle_async_pf() reads and clears it. If an NMI arrives after the event is injected and before the #PF handler reads the flags, and the NMI handler itself takes a #PF, that fault reads and clears the flags belonging to the #PF it interrupted. It then finds interrupts disabled in the NMI context it interrupted, and panics: Kernel panic - not syncing: Host injected async #PF in interrupt disabled region Call Trace: panic+0x52/0x60 __kvm_handle_async_pf+0xb0/0xb0 exc_page_fault+0x71/0xb0 asm_exc_page_fault+0x27/0x30 RIP: 0010:__get_user_nocheck_8+0x6/0x20 perf_callchain_user+0x147/0x1a0 get_perf_callchain+0x12d/0x1c0 ... perf_event_nmi_handler+0x26/0x50 exc_nmi+0xe8/0x110 RIP: 0010:asm_exc_page_fault+0x0/0x30 The last RIP line shows the NMI landing on the first instruction of the #PF entry. perf with user call chains takes such a fault: the sampling NMI walks the user stack with __get_user(), which faults when a saved frame pointer is not a valid user address or the walk runs off the top of the stack. The same window exists when KVM, running as an L1 hypervisor with DELIVERY_AS_PF_VMEXIT, reads the flags itself after a #PF VM-exit. The NMI entry code saves and restores CR2 for this nesting, but not the async #PF reason. Andy Lutomirski described the race, with perf as the example, when async #PF delivery was reworked in 2020 [1]. Saving and clearing the flags across the NMI, next to CR2, was discussed there but not merged. Since that rework, Linux has stopped setting KVM_ASYNC_PF_SEND_ALWAYS, so the host delivers "page not present" only for user mode faults and a kernel-mode fault in NMI context (including kernel-mode #MC and #DB) cannot be an async page fault. In that case, return without touching the flags so that the interrupted handler finds them intact. Tested on v7.3-rc5 in a 4-vCPU, 2 GiB guest restored from a snapshot whose memory is served on demand through userfaultfd, so that reading it back takes async #PFs, while every thread samples hardware cycles with user call chains and points its frame pointer at an unmapped page. Without this patch the guest panicked as above in 3 of 3 runs. With it, the guest survived 3 of 3 runs of 60 seconds, and the host counted 148,441 to 153,334 kvm_async_pf_not_present events in the first 20 seconds of each. On 6.18.50 the results were the same: the guest panicked without the patch and survived with it. Link: https://lore.kernel.org/all/ed71d0967113a35f670a9625a058b8e6e0b2f104.1583547991.git.luto@kernel.org/ [1] Link: https://lore.kernel.org/all/20211126123145.2772-1-jiangshanlai@gmail.com/ [2] Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: EJ Campbell Link: https://patch.msgid.link/CADkxfh-uQTca_6jB1JPDq1MsKffF_UKGQR339oQSJNcoV75GNQ@mail.gmail.com Signed-off-by: Paolo Bonzini commit 4bcfe29021993cb167fd9bbdb849f7d7247a166f Author: Jason Gunthorpe Date: Tue Oct 13 10:13:30 2026 -0300 iommupt/kunit: Use if_changed_rule for the kunit Use if_changed_rule so rule_cc_o_c runs cmd_save_c_flags for the kunit objects. Without the saved flags CONFIG_LTO_CLANG_THIN_DIST runs the ThinLTO backend with no --target and generates x86_64 code from arm64 bitcode. Fixes: 1dd4187f53c3 ("iommupt: Add a kunit test for Generic Page Table") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202610110841.120JzAJG-lkp@intel.com/ Assisted-by: LLM Signed-off-by: Jason Gunthorpe Signed-off-by: Joerg Roedel commit 3ba149029a4389d1723194ebe34a63aedbc6a610 Author: Joerg Roedel Date: Wed Oct 14 15:39:54 2026 +0200 Revert "iommu/amd: Remove redundant check in irq_remapping_select()" This reverts commit 5e1afd4ea1d6a9bbaecf3e28707dac9c8b56bd45. This commit caused a regression with GPU devices on some platforms. Revert it for now. Signed-off-by: Joerg Roedel commit 7cbaa0f4579f48e92639c6abb761fdef8fbade47 Author: Mikhail Gavrilov Date: Tue Oct 13 12:13:18 2026 +0500 entry: Account the deferred hrtimer rearm as hardirq context for lockdep On a desktop debug kernel (PROVE_LOCKING, KASAN, LOCKDEP_CHAINS_BITS=19) lockdep switches itself off after about two days of uptime with "BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!", and locking is not validated until the next reboot. In the last such boot the pool ran out after 46.6 hours, and a fifth of it, 533509 of 2621431 chain hlocks in 63838 of 344717 chains, had been created by the deferred hrtimer rearm on return from interrupt. Make lockdep account that rearm as part of the timer interrupt it belongs to. Commit 15dd3a948855 ("hrtimer: Push reprogramming timers into the interrupt return path") moved the reprogramming of the clock event device out of the timer interrupt into the interrupt return path. On return to kernel mode irqentry_exit_to_kernel_mode_after_preempt() performs it after irq_exit_rcu() has already left lockdep's hardirq context. lockdep therefore records hrtimer_bases.lock and the timekeeper sequence count as taken by the interrupted context, on top of the locks that context holds, and every distinct held-lock stack an interrupt hits adds two lock chains. When the rearm runs from irq_enter_rcu() or __irq_exit_rcu() it is still inside lockdep's hardirq context, and there the same acquisitions reuse one pair of chains. The dependencies recorded on the return path are "lock held with interrupts enabled -> hrtimer_bases.lock". Such a lock is hardirq-unsafe and hrtimer_bases.lock is hardirq-safe, so a path in the reverse direction is already reported by the irq-safety checks without these edges. Re-enter lockdep's hardirq context around the rearm on the kernel return path. The return to user mode path holds no locks and is left alone, as is the rearm in __schedule(), which runs under the runqueue lock. With the same kernel tree, configuration and workload, one hour of uptime including a full kernel build, the chains of this shape, with hrtimer_bases.lock and optionally the timekeeper sequence count on top of a held-lock stack outside the scheduler, go from 13266 (96187 chain hlocks, 15.9% of those in use) to 4. Those 4 come from clock_was_set(), which takes cpus_read_lock() and each CPU's hrtimer_bases.lock and reads the clock under it. Fixes: 15dd3a948855 ("hrtimer: Push reprogramming timers into the interrupt return path") Signed-off-by: Mikhail Gavrilov Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20261013071318.33300-1-mikhail.v.gavrilov@gmail.com commit 3267512ad1c2cc0c7768c5b014dc2cceb398a801 Author: Jann Horn Date: Tue Sep 29 18:31:32 2026 +0200 futex: Fix mm reuse handling for FUT_OFF_MMSHARED A FUT_OFF_MMSHARED futex is a shared futex that refers to an MM. It is possible for a process to wait on a shared futex with a different MM because a FUT_OFF_INODE waiter can be requeued onto a FUT_OFF_MMSHARED futex by another process. This can cause FUT_OFF_MMSHARED waiters on a freed MM to consume wakeups intended for a newly allocated MM at the same address. Fix it by keying FUT_OFF_MMSHARED using a unique 64-bit per-MM ID. Leave private futexes as before to avoid influencing the performance of the hotpath. (Multi-threaded processes typically implicitly use FUT_OFF_MMSHARED by setting clear_child_tid such that it points into anonymous memory, which causes mm_release() in a multi-threaded mm to perform FUTEX_WAKE.) Fixes: 222993395ed3 ("futex: Remove pointless mmgrap() + mmdrop()") Closes: https://lore.kernel.org/r/CAG48ez0dLBpc3QtbAhMMVNHwHL94iHh2G+h-=BVFR4dDuzZr1g@mail.gmail.com/ Signed-off-by: Jann Horn Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260929-futex-mmshared-fix-v1-1-262b1ffeb3d0@google.com Cc: stable@vger.kernel.org commit 118a2cf4ced60777a2408001e2b4838fed1cea55 Author: K Prateek Nayak Date: Tue Oct 13 15:24:55 2026 +0000 sched/core: Call wakeup_preempt() for queued tasks during class change Paul reported recent RCU changes exposed a lost resched where CPU idles with a rcutorture thread waiting while being completely runnable. Dumping the rq state at the time of idling with runnable tasks showed the following: rq->next_class = &fair_sched_class rq->nr_running = 1 rq->cfs.h_nr_queued = 0 rq->rt.rt_nr_running = 1 Although the waiting task was an RT task, "rq->next_class" did not point to rt_sched_class and was stuck at the lower priority fair_sched_class. Inspecting sched_change_end() revealed the following race with __sched_setscheduler() for queued, but non-running tasks: CPU0 CPU1 ==== ==== __schedule() /* * rq->donor is a fair task that blocks. * rq->next_class = &fair_sched_class */ rq_lock(rq0) pick_next_task() /* nr_running = 0 */ pick_task_fair() sched_balance_newidle() raw_spin_rq_unlock(rq0) rq_lock(rq0) activate_task(rq0, p) /* p is a fair task */ rq0->nr_running++; rq0->cfs.h_nr_queued++; wakeup_preempt(rq, p) rq->next_class = &fair_sched_class resched_curr() rq_unlock(rq0) __sched_setscheduler(p) /* p is moved to SCHED_RR */ task_rq_lock(p) sched_change_begin() rq0->cfs.h_nr_queued--; rq0->rt.rt_nr_running++; sched_change_end() /* * p->on_rq = 1 (ctx->queued) * but p is not rq->donor * (!ctx->running) hence * resched_curr() is and * rq->next_class upgrade is * skipped. */ task_rq_unlock() raw_spin_rq_lock(rq0) /* * rq->nr_running = 1 * rq->cfs.h_nr_queued = 0 * rq->rt.rt_nr_running = 1 * rq->next_class = &fair_sched_class */ if (rq->cfs.h_nr_queued && ...) /* Above is false */ if (rq_modified_above(this_rq, &fair_sched_class)) /* Also false since rq->next_class is still fair */ /* * sched_balance_newidle() is considered to * have failed to pull any fair tasks and no * other wakeups were detected. */ return NULL; /* pick_task_fair() */ pick_task_idle() return rq->idle; next = rq->idle; /* Preemption indicators are lost */ clear_tsk_need_resched(prev); clear_preempt_need_resched(); rq->curr = rq->idle; !!! rq->idle switches in with rq->running == 1 but !need_resched() !!! In simple words, enqueue, followed by a class change of the newly queued task goes unnoticed in rq->next_class indicator and sched_balance_newidle() sees no fair task, nor any higher priority task enqueued. The above sequence will lead to CPU idling with a runnable task on the CPU. Call wakeup_preempt() for ctx->queued cases in sched_change_end() to re-evaluate rq->next_class after class change (ENQUEUE_CLASS) and set the NEED_RESCHED indicator accordingly. Newidle balance will correctly see an enqueue of a higher priority task if a queued task was upgraded when the rq_lock() was dropped and will retry the pick. Closes: https://lore.kernel.org/lkml/8fa7f795-518c-4507-b684-60b0c1cac2c5@paulmck-laptop/ Fixes: 704069649b5b ("sched/core: Rework sched_class::wakeup_preempt() and rq_modified_*()") Reported-by: Paul E. McKenney Tested-by: Paul E. McKenney Signed-off-by: K Prateek Nayak Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Reviewed-by: Phil Auld Link: https://patch.msgid.link/20261013152455.9039-1-kprateek.nayak@amd.com commit 19ed235c1adcaf40f05997dfe8b96eb209effd35 Author: Muhammad Mahdi Amirpour Date: Tue Oct 13 18:43:00 2026 +0330 printk: fix kernel-doc name for nbcon_write_context_is_braille Use the function name in the kerneldoc description. Fixes: c83e3d291243 ("braille: nbcon: Allow to use a serial console with NBCON API as Braille console") Signed-off-by: Muhammad Mahdi Amirpour Reviewed-by: John Ogness Link: https://patch.msgid.link/20261013151300.75966-1-ampr.mhd@gmail.com Signed-off-by: Petr Mladek commit 26401a4999f1596a515b2e704e7066ac09306488 Author: Christian König Date: Wed Oct 7 14:46:57 2026 +0200 drm/exec: don't immediately add prelocked obj to array of locked objs When a contention is detected the drm_exec object grabs a reference to the contended object, unlocks all other objects and pre-locks the contended one before anything else. The problem is that it is possible that this pre-locked object was about to be destroyed and drm_exec is now holding the last reference to it. So we never actually see this pre-locked object again to be explicitly locked and so also never reserve a slot for a dma_fence object on it. Should the driver now use drm_exec_for_each_locked_object() to add a new fence to all locked objects we eventually see a warning or even a BUG_ON() to prevent random memory corruption. Fix this by keeping the prelocked object out of the array of locked objs until it was explicitly mentioned by the driver again. If the prelocked object is never mentioned again by the driver just unlock and drop the reference at the end of the locking loop. Signed-off-by: Christian König Reported-by: Vitaly Prosyak Reviewed-by: Vitaly Prosyak Tested-by: Vitaly Prosyak Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") CC: stable@vger.kernel.org # v6.6+ Link: https://lore.kernel.org/r/20261007124657.9664-1-christian.koenig@amd.com commit d8e5fc3002294a28af53e97f6c83a35956e738f3 Author: Petr Mladek Date: Tue Oct 13 17:41:41 2026 +0200 nbcon/reboot: Switch NBCON consoles into the emergency mode in emergency_restart() When the system is going down a normal way, the NBCON kthreads are flushed and stopped properly via a syscore shutdown callback, see printk_kthreads_shutdown(). One missing piece is emergency_restart() where the kthreads are not stopped. It might be called from several non-panic code paths, e.g. sysrq-o, kdb_reboot(), or some watchdogs. Fix it by explicitly entering the emergency (atomic) mode and trying to flush the consoles there. Note that printk_trigger_flush() must be used instead of pr_flush() because the later is not safe in an atomic context. Reported-by: kernel test robot Closes: https://lore.kernel.org/all/202608061008.48a1e76e-lkp@intel.com/ Suggested-by: John Ogness Reviewed-by: John Ogness Link: https://patch.msgid.link/20261013154141.94016-1-pmladek@suse.com Signed-off-by: Petr Mladek commit 11bffcd9cb346732eab2914ef44fe777a3f0b585 Author: Yehyeong Lee Date: Wed Oct 7 10:58:42 2026 +0900 scsi: libiscsi: Validate the task named by a management response __iscsi_complete_pdu() fetches the task for five response types from one place and checks only that the index resolved: case ISCSI_OP_LOGOUT_RSP: case ISCSI_OP_LOGIN_RSP: case ISCSI_OP_TEXT_RSP: case ISCSI_OP_SCSI_TMFUNC_RSP: case ISCSI_OP_NOOP_IN: task = iscsi_itt_to_task(conn, hdr->itt); if (!task) return ISCSI_ERR_BAD_ITT; iscsi_itt_to_task() bounds the index against cmds_max and looks at nothing else, so a target can name any slot in the pool, including one that has never been used. task->conn is then NULL, and both iscsi_nop_out_rsp() and iscsi_complete_task() dereference it. One unsolicited NOP-In is enough; a Text Response carrying the same ITT crashes in iscsi_complete_task() instead. Require the task to be in flight and not a SCSI command, the way iscsi_itt_to_ctask() does for the command opcodes. [ 6.298634] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI [ 6.298642] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067] [ 6.298652] CPU: 1 UID: 0 PID: 111 Comm: iscsistart Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.298654] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 6.298656] RIP: 0010:iscsi_nop_out_rsp.constprop.0+0x46/0x160 [ 6.298691] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00 [ 6.298698] RSP: 0018:ffff88806c907be8 EFLAGS: 00010206 [ 6.298701] RAX: dffffc0000000000 RBX: ffff888006116800 RCX: 0000000000000020 [ 6.298702] RDX: 000000000000000c RSI: ffff88800525d578 RDI: 0000000000000060 [ 6.298703] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 6.298706] R10: 0000000000000020 R11: 0000000000000000 R12: 0000000000000000 [ 6.298706] R13: 000000000000002e R14: ffff8880056eb440 R15: ffff888006116800 [ 6.298707] FS: 00007fc02d1c2740(0000) GS:ffff8880b29bc000(0000) knlGS:0000000000000000 [ 6.298710] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.298711] CR2: 000055fe3b56ddf8 CR3: 00000000053b9004 CR4: 0000000000770ef0 [ 6.298712] PKRU: 55555554 [ 6.298713] Call Trace: [ 6.298714] [ 6.298714] __iscsi_complete_pdu+0x13a8/0x22a0 [ 6.298758] iscsi_complete_pdu+0x54/0xa0 [ 6.298759] iscsi_tcp_hdr_recv_done+0x870/0x2c80 [ 6.298778] iscsi_tcp_recv_skb+0x31e/0xec0 [ 6.298800] iscsi_sw_tcp_recv+0x12f/0x390 [ 6.298804] __tcp_read_sock+0x1ab/0x810 [ 6.298812] iscsi_sw_tcp_data_ready+0x18b/0x510 [ 6.298814] tcp_rcv_established+0x1f56/0x3a00 [ 6.298842] tcp_v4_do_rcv+0x449/0x960 [ 6.298847] tcp_v4_rcv+0x2245/0x3bc0 Fixes: 7996a778ff8c ("[SCSI] iscsi: add libiscsi") Cc: stable@vger.kernel.org Reviewed-by: Mike Christie Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20261007015842.634893-4-yhlee@isslab.korea.ac.kr Signed-off-by: Martin K. Petersen (Oracle) commit c5958c770b2a0ee492414e26b07da9164a0d1f5d Author: Yehyeong Lee Date: Wed Oct 7 10:58:41 2026 +0900 scsi: libiscsi: Validate the ITT reflected in a Reject PDU A Reject PDU carries a copy of the header it rejects, and iscsi_handle_reject() takes the ITT out of that copy to find the task to clean up: memcpy(&rejected_pdu, data, sizeof(struct iscsi_hdr)); ... task = iscsi_itt_to_task(conn, rejected_pdu.itt); That value is whatever the target put there. iscsi_itt_to_task() bounds the index against cmds_max and checks nothing else, so any task in the pool can be named, and iscsi_nop_out_rsp() then completes it. An index that has never been used gives a NULL task->conn: the pool is zeroed at session setup and conn is assigned only when a task is allocated. If the task was used and returned, iscsi_complete_task() hits its WARN_ON_ONCE(task->state == ISCSI_TASK_FREE) and the refcount underflows. An in-flight SCSI command is completed as successful - a 1 MiB read returned 1048576 with none of its buffer written and no warning. Validate the reflected ITT the way iscsi_itt_to_ctask() validates a command ITT, and require the task to be in flight and not a SCSI command. [ 6.248477] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI [ 6.249357] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067] [ 6.249951] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.250718] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 6.251616] RIP: 0010:iscsi_nop_out_rsp.constprop.0+0x46/0x160 [ 6.252043] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00 [ 6.252813] RSP: 0018:ffff88806c907b80 EFLAGS: 00010206 [ 6.253042] RAX: dffffc0000000000 RBX: ffff88800607e000 RCX: ffffffff8d571a25 [ 6.253345] RDX: 000000000000000c RSI: ffff88806c907c38 RDI: 0000000000000060 [ 6.253642] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff235a504 [ 6.253947] R10: 0000000000000003 R11: 7463656e6e6f6320 R12: 0000000000000000 [ 6.254251] R13: 0000000000000000 R14: ffff88806c907c38 R15: 0000000000000000 [ 6.254549] FS: 0000000000000000(0000) GS:ffff8880d95bc000(0000) knlGS:0000000000000000 [ 6.254887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.255140] CR2: 00007fc393e8ffc0 CR3: 0000000005252006 CR4: 0000000000770ef0 [ 6.255439] PKRU: 55555554 [ 6.255564] Call Trace: [ 6.255674] [ 6.255768] __iscsi_complete_pdu+0x18bf/0x22a0 [ 6.256733] iscsi_complete_pdu+0x54/0xa0 [ 6.256905] iscsi_tcp_data_recv_done+0xf4/0x250 [ 6.257103] iscsi_tcp_recv_skb+0x31e/0xec0 [ 6.257680] iscsi_sw_tcp_recv+0x12f/0x390 [ 6.258061] __tcp_read_sock+0x1ab/0x810 [ 6.258853] iscsi_sw_tcp_data_ready+0x18b/0x510 [ 6.259808] tcp_data_queue+0x1f13/0x4cd0 [ 6.260567] tcp_rcv_established+0x8a5/0x3a00 [ 6.261931] tcp_v4_do_rcv+0x449/0x960 [ 6.262269] tcp_v4_rcv+0x2245/0x3bc0 Fixes: 8afa1439fcff ("[SCSI] libiscsi: handle immediate command rejections") Cc: stable@vger.kernel.org Reviewed-by: Mike Christie Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20261007015842.634893-3-yhlee@isslab.korea.ac.kr Signed-off-by: Martin K. Petersen (Oracle) commit 8ee2a09a1dbb257c9e828ad2497f8e4832dfb142 Author: Yehyeong Lee Date: Wed Oct 7 10:58:40 2026 +0900 scsi: libiscsi: Reject a negative task index from parse_pdu_itt A transport that implements parse_pdu_itt hands libiscsi an index taken from the PDU, and both lookups bound it from above only: if (i >= session->cmds_max) i and cmds_max are both int, so a negative index passes and session->cmds[i] is read from before the array. be2iscsi produces one. beiscsi_parse_pdu() assigns the raw tag, *index = (int)itt; and beiscsi_complete_pdu() forwards an unsolicited NOP-In from the hardware async ring without replacing its ITT, so the value is the target's. It also reports the session's own age rather than the one in the tag, which leaves the age comparison in iscsi_verify_itt() with nothing to reject. Bound the index from below in both lookups. Fixes: bfead3b2cb46 ("[SCSI] be2iscsi: Adding msix and mcc_rings V3") Cc: stable@vger.kernel.org Reviewed-by: Mike Christie Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20261007015842.634893-2-yhlee@isslab.korea.ac.kr Signed-off-by: Martin K. Petersen (Oracle) commit e15b81f602edbdee39c335546f25486a1747f3f0 Author: Linfeng Sun Date: Tue Aug 11 20:48:43 2026 +0800 scsi: target: iscsi: Fix race in discovery auth updates Separate configfs opens can concurrently update the discovery AuthMethod parameter. Both callers may free the same value in iscsi_update_param_value(), causing a double-free. Protect the lookup and replacement with the discovery TPG access lock, as used by the other TPG configfs parameter updates. Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Signed-off-by: Linfeng Sun Reviewed-by: Mike Christie Link: https://patch.msgid.link/20260811124843.6817-1-linfeng.sun.dev@gmail.com Signed-off-by: Martin K. Petersen (Oracle) commit 04a67a8b1a4460345d22fe75d93430cbf7e651d7 Author: Yu Zhang Date: Sun Sep 27 19:13:29 2026 +1000 scsi: target: Disable interrupts while holding delayed_cmd_lock target_do_delayed_work() takes dev->delayed_cmd_lock with a plain spin_lock(). It runs from system_percpu_wq, so interrupts stay enabled while the lock is held. Every other acquisition of that lock uses spin_lock_irqsave(): target_handle_task_attr() and transport_complete_ordered_sync() in target_core_transport.c, and target_non_ordered_release() in target_core_device.c. That was safe while every caller of transport_complete_task_attr() ran in process context: target_complete_ok_work() from target_completion_wq, transport_complete_qf() from dev->qf_work_queue, and transport_generic_request_failure() from the submit and execute paths. Since commit 06933066d88a ("scsi: target: Add support for completing commands from backend context") that is no longer true. With complete_type=1 on a fabric that sets direct_compl_supp, target_complete() runs target_complete_ok_work() inline in the backend's completion context, which target_complete_cmd_with_sense() documents as "May be called from interrupt context". For iblock that is the bio end_io. target_complete_ok_work() starts with transport_complete_task_attr(), which takes delayed_cmd_lock in two ways: - Every ORDERED command is put on dev->delayed_cmd_list by target_handle_task_attr() and dispatched from there by target_do_delayed_work(), which marks it SCF_TASK_ORDERED_SYNC. Its completion therefore goes through transport_complete_ordered_sync(). - A SIMPLE command that completes while an ORDERED command is pending drops the last reference to the killed dev->non_ordered, and percpu_ref_put() then runs target_non_ordered_release() in the completing context. Both take the lock and, if commands are waiting, call schedule_work(&dev->delayed_cmd_work), which queues on system_percpu_wq, i.e. on the CPU that took the completion. Further completions for the same queue are typically delivered there too, so one arriving while the work holds the lock spins on it forever. Reaching this needs complete_type=1, which is not the default (vhost-scsi, the only fabric with direct_compl_supp, defaults to TARGET_QUEUE_COMPL), a backend whose I/O completes from interrupt context, and ORDERED commands from the initiator. Linux virtio_scsi guests send only VIRTIO_SCSI_S_SIMPLE and never take the ordered path; any guest that uses the ORDERED task attribute, which vhost-scsi accepts, does. target_do_delayed_work() is a work item and always runs in process context, so spin_lock_irq() is sufficient. Found by inspection; no runtime report. A single ORDERED command goes through both acquisitions, so with CONFIG_PROVE_LOCKING the first one completed through direct completion should produce an inconsistent lock state report on delayed_cmd_lock (hardirq or softirq, depending on where the backend completes). Fixes: 06933066d88a ("scsi: target: Add support for completing commands from backend context") Signed-off-by: Yu Zhang Reviewed-by: Mike Christie Link: https://patch.msgid.link/20260927091329.13482-1-yuz08559@gmail.com Signed-off-by: Martin K. Petersen (Oracle) commit 71caf7f84bd62a4bf91cc95abd2de690afb8d15f Author: Laurence Oberman Date: Tue Oct 13 16:25:48 2026 -0400 scsi: st: Fix use-after-free race between st_remove() and st_open() st_remove() drops the probe reference on the scsi_tape with kref_put() and only afterwards removes its index from st_index_idr. If that was the last reference, scsi_tape_release() frees the structure while it is still published in the idr. scsi_tape_get(), called from st_open(), looks up the tape in st_index_idr and takes a reference under st_ref_mutex and st_index_lock. remove_cdevs() does not wait for opens that are already past chrdev_open(), so an open that is blocked on st_ref_mutex while st_remove() holds it can take the mutex as soon as st_remove() drops it, find the freed tpnt in the idr and call kref_get() on it: BUG: KASAN: slab-use-after-free in st_open Write of size 4 ... st_open (drivers/scsi/st.c:254 drivers/scsi/st.c:1291) chrdev_open ... Freed by task ...: kfree st_remove (drivers/scsi/st.c:4512) Remove the index from the idr before dropping the reference, all under st_ref_mutex. A concurrent scsi_tape_get() now either runs first and holds a valid reference that keeps the tape alive, or runs afterwards and finds nothing, so st_open() fails with -ENXIO. This restores the ordering st_remove() had before the conversion to st_index_idr, where the tape was unpublished from scsi_tapes[] before the final kref_put(). Fixes: 6c648d95a6af ("[SCSI] st: get rid of scsi_tapes array") Cc: stable@vger.kernel.org Reported-by: Dingisoul Closes: https://lore.kernel.org/linux-scsi/20261007211520.1428497-1-dingiso.kernel@gmail.com/ Tested-by: Dingisoul Signed-off-by: Laurence Oberman Link: https://patch.msgid.link/20261013202548.249628-1-loberman@redhat.com Signed-off-by: Martin K. Petersen (Oracle) commit c9e9f024dd4f61f0f6636c9f2ed0830f87060e11 Author: Laurence Oberman Date: Tue Oct 6 12:42:50 2026 -0400 scsi: st: Save the visited block for the partition the drive is in set_location() saves the current tape location before switching partitions, so that switch_partition() can return to it later. It reads the location with READ POSITION but stores it in the st_partstat of STp->partition, ignoring the partition the drive reports. The two differ after a device reset. When the reset is recovered with MTREW, MTSEEK or MTEOM, st_ioctl() sets STp->partition = 0 and calls switch_partition() to return to STp->new_partition. A drive that was in partition 1 is still there, so set_location() files the partition 1 position under partition 0. The next switch to partition 0 locates to that block: if partition 0 holds less data, MTSETPART fails with EIO (BLANK CHECK), otherwise the tape is silently positioned at the wrong block. IBM ULTRIUM-TD5 (LTO-5), LU reset in partition 1 at block 1025: st 12:0:0:0: [st0] Visited block 1025 for partition 0 saved. ... st 12:0:0:0: [st0] Setting block to 1025 and partition to 0. st 12:0:0:0: [st0] Error: 402, cmd: 2b 2 0 0 0 4 st 12:0:0:0: [st0] Sense Key : Blank Check [current] st 12:0:0:0: [st0] Add. Sense: End-of-data detected Store the location in the st_partstat of the partition reported by READ POSITION. With the fix: st 12:0:0:0: [st0] Visited block 1025 for partition 1 saved. This is a pre-existing issue. It was not caught when testing the recent st reset series because the partition test was only run on scsi_debug: on the LTO drive it was skipped, since can-partitions is off in the test harness's stinit.conf, as is normal for LTO. scsi_debug hides the problem because its emulated tape returns to the beginning of partition 0 on an LU reset. It was found while validating a backport of that series to RHEL 9.8, when the partition tests were run on real hardware with can-partitions enabled. The same failure then reproduced on unmodified RHEL 9.8 and on upstream, and the fix makes the test pass on v7.3-rc3 and RHEL 9.8 with an LTO-5. The harness (https://gitlab.com/loberman/tapetest, test X03) now refuses to silently skip the partition tests on hardware. Fixes: 7081dc75df79 ("scsi: st: Restore some drive settings after reset") Assisted-by: Claude Signed-off-by: Laurence Oberman Link: https://patch.msgid.link/20261006164250.773840-1-loberman@redhat.com Signed-off-by: Martin K. Petersen (Oracle) commit 8c8222c255772713eb36cde695777a1fce224917 Author: Yehyeong Lee Date: Mon Oct 5 21:35:54 2026 +0900 scsi: xen/scsifront: Check for a NULL shadow entry on a backend response scsifront_do_response() validates the rqid in a backend response against VSCSIIF_MAX_REQS before using it to index info->shadow[], but then dereferences the entry to test ->inflight without checking that the slot is populated. Shadow slots are NULL before a command is submitted (the host private area is zeroed at allocation) and are reset to NULL in _scsifront_put_rqid() once a request completes, so an in-range rqid that does not correspond to an outstanding request makes the frontend dereference a NULL pointer. A malicious or buggy backend can thus crash the guest by returning a response whose rqid is in range but not in flight -- for example a spurious response before any command has been issued, or a duplicate of one already completed. The ring has only VSCSIIF_MAX_REQS (16) slots, so before the first command every in-range rqid selects a NULL slot. Reject a response whose shadow slot is not populated. Fixes: 6d1c2f48f3fc ("xen/scsifront: harden driver against malicious backend") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Reviewed-by: Juergen Gross Link: https://patch.msgid.link/20261005123555.253995-1-yhlee@isslab.korea.ac.kr Signed-off-by: Martin K. Petersen (Oracle) commit 4056b3c9d3c92ea45955641dbafeb9b960e146ef Merge: d77bd0d469e192 b963f2345fa204 Author: Linus Torvalds Date: Tue Oct 13 18:06:58 2026 -0700 Merge tag 'nios2_update_for_v7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux Pull NIOS2 fix from Dinh Nguyen: - Fix __wsum type degradation in csum_fold() * tag 'nios2_update_for_v7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: nios2: fix __wsum type degradation in csum_fold() commit d77bd0d469e1923e587bb919301c0bb29093e30a Merge: ca3e345926b00b 5b4bd13e055292 Author: Linus Torvalds Date: Tue Oct 13 18:02:11 2026 -0700 Merge tag 'for-v7.3-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply fixes from Sebastian Reichel: "power-supply core: - prevent unregistering a power supply while a callback runs power-supply drivers: - generic-adc-battery: Fix temperature IIO channel conversion - ds2780: Fix ds2780_get_capacity() returning raw value - max17042_battery: Fix vmin assigned instead of vmax in DT parsing - Fix maintenance charge table kernel-doc" * tag 'for-v7.3-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: power: supply: core: prevent unregistering a power supply while a callback runs power: supply: generic-adc-battery: Fix temperature IIO channel conversion power: supply: ds2780: Fix ds2780_get_capacity() returning raw value power: supply: Fix maintenance charge table kernel-doc power: supply: max17042_battery: Fix vmin assigned instead of vmax in DT parsing commit ca3e345926b00bd59106c1bf2022b1daf4164a67 Merge: cbc08c20479c6d a1ddc2721467fb Author: Linus Torvalds Date: Tue Oct 13 16:53:40 2026 -0700 Merge tag 'bootconfig-fixes-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull bootconfig fix from Masami Hiramatsu: - bootconfig: give the footer size static_assert a message Add a message to static_assert() macro because it is required for the compiler before C23. This fixes a warning. * tag 'bootconfig-fixes-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: bootconfig: give the footer size static_assert a message commit cbc08c20479c6da3db077f9b170bb8cc2d09df20 Merge: 03741bcea0a9ec d3eea584b56fec Author: Linus Torvalds Date: Tue Oct 13 16:51:44 2026 -0700 Merge tag 'turbostat-2026.09.28' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux Pull turbostat fixes from Len Brown. * tag 'turbostat-2026.09.28' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: turbostat 2026.09.28 tools/power turbostat: Fix add_counter issue if > 24 counters. tools/power turbostat: Fix PMT error path fd handling tools/power turbostat: Fix CWF PMT off-by-one tools/power turbostat: Fix fd_perf leak on reset tools/power turbostat: Sanity check GFX%rc6 and SAM%mc6 percentages tools/power turbostat: add NULL check after calloc() tools/power turbostat: Warn, but don't Err on out-dated perf systems tools/power turbostat: Read complete CPU lists commit 03741bcea0a9ec4c8f386fd5c6051c1a14070240 Merge: 24a19b953e2a3d e90ab3669181c6 Author: Linus Torvalds Date: Tue Oct 13 16:41:23 2026 -0700 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull kvm fixes from Paolo Bonzini: "More x86 fixes: - Fix a WARN if the SS bit is set in #NPF exit codes. The AMD manual is unclear about whether it can be set when the guest uses CET but the SupervisorShadowStackEn feature (which KVM does not use) is disabled. However, Hyper-V has started using CET now that KVM supports GMET (it wants the two feature in pairs), and that dissolves all the doubts: the SS bit *is* reported and not clearing it causes a WARN and/or a UBSAN splat. - If creating a vCPU ultimately fails, clear its entry in the AVIC Physical ID table used by hardware to perform IPI Virtualization and delivered posted IRQs. I.e. plug the same use-after-free hole related to IPI virtualization and posted IRQs that was fixed for APICv by commit b41f2ca6c0601 ("KVM: VMX: Fix stale PID-pointer table entry left after vCPU free"). - Use set_page_dirty_lock() instead of set_page_dirty() when marking a page dirty after writing back SNP firmware's desired CPUID state to userspace. Using set_page_dirty() is unsafe if the page/folio isn't locked (as pointed out by its function comment's big DANGER warning, which no one reads given the number of bugs of this exact nature). - When checking for an MMIO generation match, use the memslots for the current vCPU context (non-SMM vs. SMM), as a misbehaving guest can coerce KVM into incorrectly identifying a write as MMIO in order to bypass KVM's write-tracking" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes KVM: x86: Use active memslots for the per-vCPU MMIO cache KVM: SEV: Fix page dirtying in sev_gmem_post_populate() KVM: SVM: Clear AVIC Physical ID table entry if vCPU creation fails KVM: SVM: Use "is AVIC-addressable" helper to sanity check load()/put() KVM: SVM: Add paranoid helper for checking if vCPU is AVIC-addressable commit b963f2345fa20417401c51a69dedb6a58eea33a9 Author: Keith Busch Date: Tue Sep 22 08:34:16 2026 -0700 nios2: fix __wsum type degradation in csum_fold() csum_fold() shifts a bitwise __wsum type, which sparse reports as "restricted __wsum degrades to integer". Sparse only checks the body of a static inline once something instantiates it, so this went unnoticed until a recent block layer change added the first csum_fold() caller to a file built on this architecture. Force cast to a __u32 for the shift, as the other architectures do. Fixes: eea9507a69d6 ("nios2: Library functions") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609222053.5gjiJjtb-lkp@intel.com/ Signed-off-by: Keith Busch Signed-off-by: Dinh Nguyen commit 8907eb42c08b8eebe0f81fee256b34b5675d0e5a Author: Yuho Choi Date: Sat Sep 26 16:20:27 2026 -0400 drm/virtio: Reset device before deleting virtqueues on freeze virtgpu_freeze() waits for the control and cursor queues to drain and then deletes the virtqueues, but nothing tells the device to stop first. del_vqs() frees the vring backing, but does not provide a generic device quiesce operation. In particular, modern virtio-pci keeps enabled queues active until the device is reset, so the device is left DRIVER_OK with its queues pointing at memory that has been freed and may be reused while the guest is suspended. virtio_device_restore() only resets the device later, on resume. Reset the device before deleting the virtqueues, the way virtio_gpu_deinit() already does on removal. Fixes: cad6a879a7fb ("drm/virtio: Freeze and restore hooks to support suspend and resume") Cc: stable@vger.kernel.org Signed-off-by: Yuho Choi Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260926202040.1313385-1-oss.patchbox@gmail.com commit 8980bc573ae2d2b9d86d76aeb86c76e1597070bf Author: Carlos Jones Jr Date: Fri Oct 2 16:55:40 2026 +0800 spi: tegra114: assert CS GPIO for every transfer in a message The driver provides its own transfer_one_message() and therefore drives the chip-select GPIO itself rather than through the SPI core. The GPIO is asserted only in the is_first_of_msg path of tegra_spi_setup_transfer_one(), but tegra_spi_transfer_end() deasserts it whenever a transfer has cs_change set. For a multi-transfer message whose earlier transfers request cs_change -- for example a register read that sends the address in one transfer and clocks the data back in the next -- the CS GPIO is released after the first transfer and never re-asserted, so the remaining transfers are clocked with chip-select inactive and the peripheral never drives the bus. This was observed with an ADIS16470 IMU (adis16475 driver), whose register read is a two-transfer, cs_change-framed exchange: a logic analyzer showed the data frame clocked with CS high, and the driver read 0 while the device drove 0x4056 on the wire. Re-assert the CS GPIO for every transfer so that multi-transfer messages keep chip-select active across the whole message. gpiod_set_value() is idempotent and polarity-aware, so this is a no-op for the first transfer and for messages that keep CS asserted throughout. Fixes: 63c1440596ff ("spi: tegra114: add support for gpio based CS") Signed-off-by: Carlos Jones Jr Link: https://patch.msgid.link/20261002085540.1625-1-carlosjr.jones@analog.com Signed-off-by: Mark Brown commit 2935062be77113c1c4565ca9d0c72180449aafee Author: Kuba Piecuch Date: Mon Oct 12 21:07:46 2026 +0000 sched_ext: Wait for SCX_OPSS_DISPATCHING before moving tasks off DSQs A task can be found on a non-local DSQ while the CPU which dispatched it is still running ops.dequeue() and hasn't cleared SCX_OPSS_DISPATCHING. The DSQ consume and move paths don't wait for the dispatch to finish and can operate on the task concurrently with the dispatcher. Call scx_wait_dispatching() in scx_move_local_task_to_local_dsq(), unlink_dsq_and_switch_rq_lock() and move_task_between_dsqs() before they operate on the task. In scx_move_local_task_to_local_dsq(), wait before scx_resolve_local_dsq() as it may update p->scx.flags. Fixes: ebf1ccff79c4 ("sched_ext: Fix ops.dequeue() semantics") Fixes: cb86607ada73 ("sched_ext: Don't run ops.dequeue() with a DSQ lock held") Cc: stable@vger.kernel.org # v7.1+ Reviewed-by: Andrea Righi Assisted-by: Claude:claude-opus-5.5 Signed-off-by: Kuba Piecuch Signed-off-by: Tejun Heo commit 18f5c699d1d0a003b2959af5871b33ac9a2400ec Author: Kuba Piecuch Date: Mon Oct 12 21:07:45 2026 +0000 sched_ext: Rename scx_reenq_wait_dispatching() to scx_wait_dispatching() Waiting for SCX_OPSS_DISPATCHING to clear isn't specific to the reenqueue paths. Any path which takes a task off a DSQ can find it while the dispatch is still in flight, and the next patch calls the helper from the DSQ consume and move paths. Rename it to scx_wait_dispatching() and update its comment accordingly. No functional change. Reviewed-by: Andrea Righi Assisted-by: Claude:claude-opus-5.5 Signed-off-by: Kuba Piecuch Signed-off-by: Tejun Heo commit d2ce8fcd778ee6d92748c92d23a56d4416c29d86 Author: Thomas Hellström Date: Mon Oct 12 15:26:07 2026 +0200 drm/xe: Bump LRU for external objects on exec and rebind The VM's private BOs get their LRU position refreshed in bulk via ttm_lru_bulk_move_tail() on vm->lru_bulk_move, both after a successful non-LR exec and after the LR preempt-fence rebind worker runs. External objects (BOs potentially shared across VMs) are never added to that per-VM bulk move list, so their LRU position is never refreshed by either path. This makes external objects in active use look more evictable than they are. Add xe_vm_bump_lru(), which, under a single lru_lock critical section, performs the bulk move of the VM's private BOs and bumps each external object locked by the drm_exec transaction. Use it from both the non-LR exec path and the LR rebind worker, replacing the open-coded bulk move. Fixes: d490ecf57790 ("drm/xe: Rework xe_exec and the VM rebind worker to use the drm_exec helper") Cc: Matthew Auld Cc: Matthew Brost Cc: # v6.8+ Assisted-by: LLM Signed-off-by: Thomas Hellström Reviewed-by: Matthew Brost Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20261012132607.21387-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 324ba30cca180c2e1d02090743dd78ccb15b9e4a) Signed-off-by: Rodrigo Vivi commit fd8662823caa114a63f07222d2aa448f6ac5e864 Author: Bommu Krishnaiah Date: Tue Oct 6 07:33:14 2026 +0530 drm/xe/oa: Zero OA buffer at allocation ttm_bo_type_kernel BOs are not guaranteed to be zeroed on allocation and may contain data from previously freed pages. Since the OA buffer is mmap'able by userspace, this can expose stale kernel memory contents. Streams opened with DRM_XE_OA_PROPERTY_OA_DISABLED allocate the OA buffer without calling xe_oa_init_oa_buffer(). Zero the buffer at allocation to prevent information disclosure through mmap. The existing zeroing in xe_oa_init_oa_buffer() remains necessary for zero report-id/timestamp detection on enable/re-enable. Fixes: 392bf22238ff ("drm/xe/oa/uapi: OA buffer mmap") Assisted-by: LLM Cc: Umesh Nerlige Ramappa Cc: Ghimiray, Himal Prasad Signed-off-by: Bommu Krishnaiah Reviewed-by: Himal Prasad Ghimiray Reviewed-by: Umesh Nerlige Ramappa Reviewed-by: Tejas Upadhyay Link: https://patch.msgid.link/20261006020314.2711762-1-krishnaiah.bommu@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit 126c4c5388f9311a390b9b254a835b0cf0f55331) Signed-off-by: Rodrigo Vivi commit 448e76cbdc6652ccd3ba337b7a6e1f028859f2ed Author: Niranjana Vishwanathapura Date: Mon Oct 12 14:50:14 2026 -0700 drm/xe: skip eviction of a BO with no resource xe_evict_flags() switches on tbo->resource->mem_type to choose an eviction placement. An xe BO can reach eviction with no ttm.resource, e.g. an imported dma-buf BO whose resource was freed during teardown while its attachment is still live: the exporter then invalidates it via xe_dma_buf_move_notify() -> xe_bo_evict(), and the switch dereferences a NULL resource and faults. A BO with no resource has nothing placed or mapped, so there is nothing to evict. Return an empty placement (num_placement = 0), mirroring the handling already used for non-xe scatter-gather BOs just above; ttm_bo_validate() then takes the pipeline-gutting path and returns 0. Without the fix the xe_dma_buf@xe_test_dmabuf_move_notify_no_resource dynamic live selftest will fail with below stack. BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:xe_evict_flags+0xf4/0x140 [xe] Call Trace: xe_bo_evict+0x40/0xa0 [xe] ? ttm_bo_pipeline_gutting+0x71/0x180 [ttm] xe_test_dmabuf_move_notify_no_resource+0x182/0x440 [xe] xe_dma_buf_kunit+0x387/0x580 [xe] v2: Add Fixes tag and failure info in commit text (Matt Brost) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Assisted-by: GitHub-Copilot:claude-opus-4.8 Signed-off-by: Niranjana Vishwanathapura Reviewed-by: Tejas Upadhyay Link: https://patch.msgid.link/20261012215014.1495677-5-niranjana.vishwanathapura@intel.com (cherry picked from commit dbcfaac6331f1fcb0c2fe3ad3e9adb1e5d43ec0c) Signed-off-by: Rodrigo Vivi commit 5e0ed1108504dae408e8cfaabf7ee5f7bb180bca Author: Jianfeng Liu Date: Sat Sep 26 10:20:17 2026 +0800 Revert "dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels" This reverts commit 143755bdabaa96776c24f878014608e9cb44f930. That commit fixed a dangling reference in the DMABUF_DEBUG default and thereby enabled the option - and with it the page-stripping sg_table wrapper that dma_buf_map_attachment() hands to importers - on every kernel with DEBUG_KERNEL=y, i.e. virtually every distro kernel. drm/msm is broken by the wrapper. Both of msm's map paths consume sg->length and sg_phys() of the attachment sg_table: msm_iommu_pagetable_map() for the per-process GPU pagetables, and iommu_map_sg() (via iommu_map_sgtable()) for scanout. The wrapper zeroes sg->length and strips the page pointers, so mappings of imported dma-bufs silently map nothing, and userspace observes arm-smmu translation faults from UCHE, e.g. during hardware video decode (clapper, chromium) on Adreno systems: gpu fault: ttbr0=000000088a889000 iova=000000010741c000 dir=READ type=TRANSLATION source=UCHE Bisected on a Snapdragon X1E78100 laptop as v7.3-rc3 good, v7.3-rc4 bad, culprit 143755bdabaa9. Switching msm to sg_dma_address()/sg_dma_len() is not a trivial fix either: those fields are only valid for sg_tables that msm has dma-mapped itself, which native non-MSM_BO_WC objects' sg_tables are not, so the conversion needs more work. The msm maintainer has therefore requested restoring the previous default for v7.3, to be revisited once msm no longer consumes struct page and sg->length of imported sg_tables. Link: https://lore.kernel.org/linux-arm-msm/20260923074256.9357-1-liujianfeng1994@gmail.com/ Suggested-by: Rob Clark Cc: Christian König Cc: Sumit Semwal Cc: Karl Mehltretter Signed-off-by: Jianfeng Liu Signed-off-by: Sumit Semwal [sumits: as discussed on https://lore.kernel.org/all/CAO_48GEh1p52pA_-NE=rN=_NQ=oAXpeHgHGVZCH6uPnFq7G1gQ@mail.gmail.com/ applying this revert for 7.3 unblock] Link: https://patch.msgid.link/20260926022026.10539-1-liujianfeng1994@gmail.com commit 2a31b5378c6db9c4a8d399e5d10d32cd4b732bef Author: Mario Limonciello Date: Tue Oct 13 07:54:23 2026 -0500 ASoC: amd: yc: disable MSI on resume BIOS/firmware may re-enable MSI in PCI config space during system resume even though this driver only uses legacy INTx interrupts. If MSI is left enabled with stale address and data registers, the device can write interrupts to a bogus address and cause an IOMMU IO_PAGE_FAULT. Clear the MSI Enable bit before reinitializing ACP hardware on system resume. Keep runtime resume separate because firmware does not restore PCI configuration on that path. Fixes: c8212df7bc0f ("ASoC: amd: add acp6x pci driver pm ops") Reported-by: Marek Borůvka Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222119 Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20261013125425.3541206-1-mario.limonciello@amd.com Signed-off-by: Mark Brown commit 513444cc62e231a11c9b15ea88de0890da9b2b4f Merge: 8bf659bd54e1f0 1b0aad53ad715b Author: Paolo Abeni Date: Tue Oct 13 15:22:26 2026 +0200 Merge branch 'net-mlx5-hws-fix-reformat-release-and-meter-offset' Alexandre Cassen says: ==================== net/mlx5: HWS, fix reformat release and meter offset This series fixes two issues in fs_hws found while offloading one tc rule with its own encap and meter: - Releases L2 to L3 tunnel reformats to the pool they come from. - Makes a rule select its flow meter within the whole ASO bulk. ==================== Link: https://patch.msgid.link/20261007143830.1733583-1-acassen@corp.free.fr Signed-off-by: Paolo Abeni commit 1b0aad53ad715b15ccbad8c65d15c149c925f00a Author: Alexandre Cassen Date: Wed Oct 7 16:38:23 2026 +0200 net/mlx5: HWS, fix flow meter offset within its bulk The flow meter action is bound to the first ASO object of the bulk but the rule offset only indexes the meter within its own object. A rule past the first object runs on the wrong meter. Fixes: 82d3639ef7dc ("net/mlx5: fs, add support for flow meters HWS action") Signed-off-by: Alexandre Cassen Reviewed-by: Moshe Shemesh Acked-by: Tariq Toukan Link: https://patch.msgid.link/20261007143830.1733583-3-acassen@corp.free.fr Signed-off-by: Paolo Abeni commit 39e02ddf74bbe9c9080555232ba8100462cba2ad Author: Alexandre Cassen Date: Wed Oct 7 16:38:22 2026 +0200 net/mlx5: HWS, release L2 to L3 tunnel reformats to their own pool L2 to L3 tunnel reformats are now released to the el2tol3tnl pools. Fixes: aecd9d1020e3 ("net/mlx5: fs, add HWS packet reformat API function") Signed-off-by: Alexandre Cassen Reviewed-by: Yevgeny Kliteynik Acked-by: Tariq Toukan Link: https://patch.msgid.link/20261007143830.1733583-2-acassen@corp.free.fr Signed-off-by: Paolo Abeni commit 8642201f02e11eeb4ebcbccfa214cdf88318b06b Author: Heiko Stuebner Date: Tue Oct 13 12:57:56 2026 +0200 MAINTAINERS: Add myself as reviewer for the Rocket NPU driver While I definitly do not feel qualified (yet?) to tackle the changes to deeply IP-related parts, I can at least help Tomeu with the more basic changes. Reviewed-by: Tomeu Vizoso Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20261013105757.3924282-1-heiko@sntech.de commit 89c2c777df17eb0201c8e22afabbf3691f2a28fe Author: Igor Paunovic Date: Sat Sep 5 17:04:32 2026 +0200 accel/rocket: search every core slot when looking up a scheduler sched_to_core() walks rdev->cores[] up to rdev->num_cores, and rocket_remove() decrements num_cores for every core it removes. Unbind a core that is not the last one and the cores behind it fall outside the search, so sched_to_core() returns NULL for a core that is still bound and still running jobs. Neither caller checks the result: rocket_job_run(): rocket_fence_create(core), core->dev rocket_job_timedout(): dev_err(core->dev, "NPU job timed out") Unbinding the middle core of the three on an RK3588 while three clients are submitting to all of them faults twice, once from the surviving core's job queue and once from its reset work: KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] Workqueue: fdad0000.npu drm_sched_run_job_work [gpu_sched] pc : rocket_job_run+0x234/0x838 [rocket] Call trace: rocket_job_run+0x234/0x838 [rocket] drm_sched_run_job_work+0x2cc/0xad8 [gpu_sched] process_one_work+0x640/0x14f0 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: rocket-reset-2 drm_sched_job_timedout [gpu_sched] pc : rocket_job_timedout+0xf0/0x1e0 [rocket] Call trace: rocket_job_timedout+0xf0/0x1e0 [rocket] drm_sched_job_timedout+0x188/0x6a0 [gpu_sched] Both are the third core: the workqueue names are its device and its core->index, and it was left at slot 2 while num_cores had dropped to 2. Search all the slots that were allocated, the way find_core_for_dev() now does. A core that is still bound is then found, and the two callers get the pointer they already assume they have. This does not make unbinding one core out of several safe. An open client keeps an entity pointing at the scheduler of the core that went away: drm_sched reports it as not ready for every job that lands on it, and the client waits in dma_fence_default_wait for a fence that will never signal. Stopping the NULL dereference is what belongs in a fix; the rest wants more thought. Reported-by: Sidong Yang Closes: https://lore.kernel.org/dri-devel/apwUewaRnoTNXHCt@rock-5b-plus/ Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Igor Paunovic Assisted-by: LLM sparse checkpatch Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260905150432.7477-1-royalnet026@gmail.com commit 6eff1d69dae808a1518aee5a58d0853a8db3f1be Author: Igor Paunovic Date: Fri Sep 4 14:59:36 2026 +0200 accel/rocket: search every core slot when a core is removed rocket_remove() decrements rdev->num_cores for each core it removes, while find_core_for_dev() searches slots 0 to num_cores - 1. Unbinding the cores in the order they were bound therefore loses the last one: by the time it is removed the search range has already shrunk past its slot, so find_core_for_dev() returns -1 and rocket_remove() gives up without doing anything. num_cores never reaches zero, rocket_device_fini() never runs, and the file-scoped rdev keeps pointing at a device that is going away. Binding the cores again starts from that stale count, because rocket_probe() takes rdev->num_cores as the slot to fill. On an RK3588, which describes three cores, the second round lands on slots 1, 2 and 3 while rdev->cores was allocated with room for three: rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309 rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309 rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309 The write to rdev->cores[3] is past the end of the array. Nothing in tree reads the core array often enough to notice, so the overrun is silent today. It turned up while testing a devfreq series on top of this, where a worker walks every core a few times a second, and UBSAN caught the first bool it read out of the overrun entry: UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10 load of value 5 is not a valid value for type '_Bool' Workqueue: devfreq_wq devfreq_monitor Record how many slots were allocated and search all of them. Every core is then found on removal, num_cores reaches zero, the device is torn down and a later bind starts from a clean rdev. This does not make unbinding a single core out of several work. probe still takes num_cores as the slot to fill, so rebinding one core while its siblings stay bound would write over a slot that is already in use, and rocket_open() still reaches for cores[0] whether or not anything is there. Both of those want more thought than a fix should carry. Found by unbinding and rebinding all three cores on an Orange Pi 5 Plus. With this applied, 25 unbind/rebind rounds and 5 module unload/reload rounds run clean there: the cores land in slots 0, 1 and 2 every time, whichever order they are bound in, and the shared supply goes back to a single user after each round. Fixes: ed98261b4168 ("accel/rocket: Add a new driver for Rockchip's NPU") Cc: stable@vger.kernel.org Signed-off-by: Igor Paunovic Assisted-by: LLM sparse checkpatch Tested-by: Jiaxing Hu # RK3576, two cores Tested-by: Sidong Yang # RK3588, 3 cores Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260904125936.26234-1-royalnet026@gmail.com commit 4ac852419f0d317c7bd8db5b8acb3cc78be7fe33 Author: Guangshuo Li Date: Wed Jul 8 14:28:45 2026 +0800 accel/rocket: clear rdev on device init failure rocket_probe() stores the return value from rocket_device_init() in the file-scoped rdev pointer before checking whether it is an error pointer. If rocket_device_init() fails, rdev is left as an ERR_PTR. The rdev pointer is also used as the marker for whether the shared rocket device has already been initialized. A later core probe can therefore see a non-NULL rdev, skip rocket_device_init(), and dereference the error pointer when reading rdev->num_cores. Save the error code and clear rdev before returning from the rocket_device_init() failure path. Fixes: ed98261b4168 ("accel/rocket: Add a new driver for Rockchip's NPU") Signed-off-by: Guangshuo Li Reviewed-by: Igor Paunovic Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260708062845.716487-1-lgs201920130244@gmail.com commit 195f3d74b5de98969dc4fad956393bb00787efd1 Author: Loic Poulain Date: Mon Oct 12 14:54:56 2026 +0200 i2c: qcom-cci: Fix HALT_ACK reset request being dropped A HALT_ACK interrupt indicates that the corresponding I2C master has entered the halted state and must be reset before further operation. The M0 and M1 HALT_ACK status bits may be asserted simultaneously in a single interrupt. However, the interrupt handler currently overwrites the reset mask when processing each HALT_ACK condition, causing the first reset request to be lost if both events are reported together. Accumulate reset requests instead of overwriting them so that both masters are properly reset when M0 and M1 HALT_ACK events occur in the same interrupt. Fixes: e517526195de4 ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Loic Poulain Cc: # v5.8+ Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20261012-cci-fixes-v1-1-8cd4eb1fc5f9@oss.qualcomm.com commit 8bf659bd54e1f00e34cf5244b1d289c506fa47c0 Author: Kyle Zeng Date: Tue Oct 6 15:42:32 2026 -0700 netlink: reset skb headers before unicast and multicast filtering Socket filters can use SKF_NET_OFF and SKF_LL_OFF to read relative to an skb's network and MAC headers. Netlink producers may reserve headroom without resetting those headers, allowing a receiving socket's filter to read data before the initialized message. For example, IWPM HELLO replies are allocated with dev_alloc_skb(), which reserves NET_SKB_PAD bytes. An unprivileged NETLINK_RDMA user can attach a classic socket filter and disclose this headroom through the length of the delivered reply. The resets in netlink_dump() do not help because IWPM sends a separately allocated skb through netlink_unicast(). Reset both headers before running the receiver's filter in unicast and broadcast delivery, as is already done for dump skbs. This also covers other netlink producers that reserve headroom without changing their allocation or message-building code. Fixes: b1153f29ee07 ("netlink: make socket filters work on netlink") Assisted-by: LLM Signed-off-by: Kyle Zeng Link: https://patch.msgid.link/20261006224232.50724-1-kylebot@openai.com Signed-off-by: Paolo Abeni commit b7ad72414c673ce1fa1f463e807cd4f34f8be9bf Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Oct 7 12:57:39 2026 +0900 sctp: revalidate output stream after association connect wait When message interleaving is enabled, the first send waits for association establishment before building its data chunks. The wait drops the socket lock, and handshake processing can reduce the output stream count to the peer-advertised inbound stream count. sctp_stream_init() then frees the extension of every removed stream. The sender resumes with the stream that it checked before the wait. If the peer removed that stream, sctp_outq_tail() later dereferences its NULL extension. Fatal-oops policies then panic the host. KASAN: null-ptr-deref in range [0x38-0x3f] RIP: sctp_outq_tail+0x49e/0xaa0 Call Trace: sctp_primitive_SEND sctp_sendmsg_to_asoc sctp_sendmsg A range check alone is insufficient. Stream reconfiguration can grow the output count again while the lock is released without recreating extensions freed by the earlier shrink. The stream can then be in range while its extension remains NULL. The send-buffer wait has the same issue. Factor the range and extension checks into a helper and repeat both after each send-path wait that drops the socket lock. Once the lock is reacquired, the validation remains stable through data creation and queueing. If validation fails after the connect wait, the auto-created association is already established. Return ESRCH so the existing caller path keeps it under state-machine ownership instead of freeing it directly, which would leave protocol, counter and socket state inconsistent. Fixes: 668c9beb9020 ("sctp: implement assign_number for sctp_stream_interleave") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Acked-by: Xin Long Link: https://patch.msgid.link/20261007035739.3472432-1-4ncienth@gmail.com Signed-off-by: Paolo Abeni commit d5a821f66047c2effd06147b84775f9b2ce0f4aa Merge: 2e42cade8ff1ff abff0a48b110fe Author: Mark Brown Date: Tue Oct 13 00:11:44 2026 +0100 regmap: Fix cache lifecycle locking and teardown Michael Reeves says: Fix an "Invalid wait context" lockdep warning during Apple GPIO probe and correct debugfs ordering during cache teardown. Tested on Apple M3 MacBook Air (T8122): - All 4 GPIO controllers probe successfully with lockdep enabled. - The "Invalid wait context" warning no longer occurs. - The regmap KUnit suite passes and lockdep remains enabled. Link: https://patch.msgid.link/20261006-regcache-lifecycle-submit-v3-0-37bdd82fd47c@gmail.com commit abff0a48b110fe52d43999b4cb7c793a510a6bf1 Author: Michael Reeves Date: Tue Oct 6 18:03:16 2026 +1100 regmap: Drop map lock during cache init and exit On systems with CONFIG_PROVE_RAW_LOCK_NESTING enabled, Apple GPIO probe triggers an "Invalid wait context" lockdep warning. The driver uses a regmap with a raw spinlock and REGCACHE_FLAT. During regcache_init(), regcache_flat_init() allocates memory while holding the raw spinlock. The memory allocator can acquire a non-raw spinlock, which causes an invalid raw-to-non-raw lock nesting error. The abbreviated call chain is: apple_gpio_pinctrl_probe regcache_init regcache_flat_init __kmalloc_noprof __pcs_replace_empty_main refill_objects _raw_spin_lock_irqsave Cache allocation occurs before the regmap is published, cache destruction occurs after users have stopped accessing it, and regmap_reinit_cache() requires callers to prevent concurrent access. Remove the outer map lock from cache initialization and destruction. Keep it for cache population and normal register access. The Maple cache still uses its internal spinlock during teardown. That lock can also be acquired from hard IRQ context during register access. Add Maple-state irqsave helpers and use them during teardown to preserve the lock's IRQ-safe lockdep state. Fixes: fd4ebc07b4df ("regmap: Hold the regmap lock when allocating and freeing the cache") Suggested-by: Mark Brown Suggested-by: Liam R. Howlett Signed-off-by: Michael Reeves Reviewed-by: Peng Fan Link: https://patch.msgid.link/20261006-regcache-lifecycle-submit-v3-2-37bdd82fd47c@gmail.com Signed-off-by: Mark Brown commit 834035934cef9e60169de682f4dc9feafd49e51a Author: Michael Reeves Date: Tue Oct 6 18:03:15 2026 +1100 regmap: Remove debugfs before cache teardown regmap_exit() and regmap_reinit_cache() destroy the register cache before removing debugfs. A concurrent debugfs cache operation can therefore access cache state after the backend exit callback starts freeing it. Remove debugfs before cache teardown, and clear the debugfs pointer after removal. During cache reinitialization, recreate debugfs only after the new cache initializes successfully. Signed-off-by: Michael Reeves Reviewed-by: Peng Fan Link: https://patch.msgid.link/20261006-regcache-lifecycle-submit-v3-1-37bdd82fd47c@gmail.com Signed-off-by: Mark Brown commit 8cb5c17be3a2fadc41075d04ce1c24c831546aaf Author: Abel Vesa Date: Mon Sep 28 16:58:47 2026 +0300 i2c: qcom-geni: Restore the source-clock selection policy Currently, the source clock lookup prefers 32 MHz whenever that rate is available, regardless of the rate configured by the platform. Before the switch to looking up the clock index, the driver used the 32 MHz timing table only if the current source clock rate was 32 MHz, and the 19.2 MHz table otherwise. On X1E80100 CRD, this results in switching the source clock from 19.2 MHz to 32 MHz, which causes intermittent failures when probing the I2C HID keyboard. These range from corrupted HID descriptors to failed resets and transfer timeouts, which also affect the touchpad on the same bus. Restore the original selection policy: use 32 MHz if already selected, otherwise request 19.2 MHz. Look up the index for the selected rate and keep the check that rejects higher-frequency multiples. This retains the dynamic clock index lookup without preferring 32 MHz on platforms that previously used 19.2 MHz. Report the requested rate if the lookup fails. Fixes: cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in SE_GENI_CLK_SEL") Assisted-by: LLM Signed-off-by: Abel Vesa Tested-by: Hasty Heat Tested-by: Mitchell Augustin Reviewed-by: Mitchell Augustin Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260928-b4-i2c-qcom-geni-preserve-source-clock-v1-1-9aded7552a76@oss.qualcomm.com commit aaabefc79b0ff0018e8e3832169bbe359d0551fc Author: Wentao Liang Date: Wed Sep 16 07:06:31 2026 +0000 i2c: viai2c-wmt: Fix clock leak in wmt_i2c_probe() In wmt_i2c_probe(), i2c->clk is acquired using of_clk_get(). If any subsequent operation fails or when the module is unloaded, the clock reference count is never decremented via clk_put(), leading to a resource leak. Switch to devm_clk_get() so that the clock is automatically managed and released. Fixes: 560746eb79d3 ("i2c: vt8500: Add support for I2C bus on Wondermedia SoCs") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260916070631.1965713-1-vulab@iscas.ac.cn commit 4e9f69d08253471d92bcc46b363fbada06bd59c4 Author: Shawn Lin Date: Thu Sep 24 12:06:33 2026 +0800 PCI: dw-rockchip: Move INTx IRQ setup to probe Since commit b376b3ff9cb0 ("PCI: dw-rockchip: Implement .reset_root_port() and use for link down"), .reset_root_port() re-runs the host ops .init() callback to reprogram the Root Complex after a controller reset. That works for the register programming, but .init() is not re-entrant: it also creates the INTx IRQ domain and installs the chained INTx handler. Every Root Port reset therefore ends up with a second IRQ domain registered for the same fwnode: the previous one is leaked, as it is never removed, and worse, the INTx virqs of the downstream PCI devices were allocated in the previous IRQ domain and are never re-mapped, while the chained handler now looks up virqs in the new, empty domain. After a link down recovery, INTx interrupts are silently lost. Fix it by moving the of_irq_get_byname() lookup, the INTx IRQ domain creation and the chained handler installation out of .init() and into rockchip_pcie_configure_rc(), just before dw_pcie_host_init(). The lookup has to happen before the host is initialized, because dw_pcie_host_init() enumerates the bus and probes the downstream devices, and pci_assign_irq() maps their INTx interrupts at that point: if the domain does not exist yet, the mapping fails and the devices end up without a usable INTx. This also mirrors how the qcom driver requests its global IRQ, and leaves .init() with nothing but idempotent register programming, so both .reset_root_port() and dw_pcie_resume_noirq() can safely re-run it. Re-running of_irq_get_byname() on every resume is also gone. Fixes: b376b3ff9cb0 ("PCI: dw-rockchip: Implement .reset_root_port() and use for link down") Suggested-by: Niklas Cassel Signed-off-by: Shawn Lin Signed-off-by: Bjorn Helgaas Tested-by: Diederik de Haas # NanoPC-T6 Plus Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/1790222793-77182-1-git-send-email-shawn.lin@rock-chips.com commit 7209846a169f82cb2f3841778573d36944185892 Author: Jason Perlow Date: Mon Oct 12 14:51:27 2026 -0500 PCI/AER: Keep ANFE masked on Apple T2 Secure Enclave Commit eddba19b8b5f ("PCI/AER: Support Advisory Non-Fatal Errors") unmasks Advisory Non-Fatal Errors on devices which support Role-Based Error Reporting. On a MacBookPro16,1, enabling ANFE on the Apple T2 Secure Enclave Processor [106b:1802] causes spontaneous power loss. Leave the Secure Enclave's ANFE mask unchanged. Set a per-device flag with an EARLY fixup, before pci_aer_init() can unmask ANFE; a FINAL fixup would run too late. Keep the advertised RBER capability and all other AER initialization and reporting unchanged. Other Apple T2 functions and non-Apple devices retain the existing ANFE behavior. Setting the flag repeatedly and skipping the ANFE unmask operation are idempotent. The underlying device or firmware failure is not understood. [bhelgaas: Aditya posted essentially the same patch soon after: https://lore.kernel.org/all/20261010172301.12764-1-aditya.garg@linux.dev] Fixes: eddba19b8b5f ("PCI/AER: Support Advisory Non-Fatal Errors") Reported-by: Jason Perlow Closes: https://lore.kernel.org/linux-pci/CABZrw2HcaOh3DHTJtxU5dXrb3Vg19scr6+qR-xe_+R7rME35_Q@mail.gmail.com/ Assisted-by: LLM Signed-off-by: Jason Perlow Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/CABZrw2H+3yt2Y7xiq6OyAWaJM7P9ox-2nJxoQuJMwoJHLgi+YQ@mail.gmail.com/ commit 8ac49fbf00e580e8ee1a66b120f8b33d9ab81901 Merge: 0936bbd35a2476 4db45fc1da3d62 Author: Mark Brown Date: Mon Oct 12 19:52:02 2026 +0100 ASoC: Fix controls that write another control's bits HyeongJun An says: In the es8316 thread Mark suggested checking at registration time for controls whose register fields overlap [1]. Before adding such a check, I wanted to see what it would find in the tree today. A script expanded the control tables of every ASoC driver built by allmodconfig and looked for two controls in one table whose register fields overlap. It found 80 pairs in 33 drivers. Most are real bugs. The rest are deliberate, where two names drive the same field, such as the AC and DRC mode thresholds in sta32x. This series fixes six that I could confirm against the vendor datasheet. In each one, writing a control changes a different control, and the bits it should own cannot be reached. Most date back to the first version of the driver. One more is left out on purpose. The cs42l56 ADC Mute Switch writes the ADC invert bits. The real mute bits are also written by the cs42l56_mute() callback on every stream start and stop, so moving the control there would let the stream mute override it. I am not sure whether you would rather move it or drop it. I have none of this hardware, so these are checked against the datasheets only. More fixes, checked against the register headers, and the registration time check would follow. [1] https://lore.kernel.org/all/0fefbfe1-021b-46b2-8945-15956e75e37f@sirena.org.uk/ Link: https://patch.msgid.link/20261008130953.2446692-1-sammiee5311@gmail.com commit 4db45fc1da3d62d0fa6e8f1e457ae92e8741ed07 Author: HyeongJun An Date: Thu Oct 8 22:09:52 2026 +0900 ASoC: nau8822: Fix the 128x oversampling switch bits The DAC and ADC 128x Oversampling Switches use bit 5 of R10 and R14. The NAU8822 datasheet register map puts DACOS and ADCOS at bit 3 of those registers. In R14, bit 5 is inside HPF[6:4], which the High Pass Cut Off control owns. So turning on ADC oversampling changes the high pass cut-off, and the oversampling bit cannot be set. In R10, bit 5 is reserved, so the DAC switch has no effect. Use bit 3 for both. Fixes: 1e3cb6c321be ("ASoC: nau8822: new codec driver") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20261008130953.2446692-7-sammiee5311@gmail.com Signed-off-by: Mark Brown commit d0567ca9a2faa33efbe5ae84ef7b86423a93bffd Author: HyeongJun An Date: Thu Oct 8 22:09:51 2026 +0900 ASoC: wm8978: Fix the 128x oversampling switch bits The DAC and ADC 128x Oversampling Switches use bit 5 of R10 and R14. Table 66 of the WM8978 datasheet puts DACOSR128 and ADCOSR128 at bit 3 of those registers. In R14, bit 5 is inside HPFCUT[6:4], which the High Pass Cut Off control owns. So turning on ADC oversampling changes the high pass cut-off, and the oversampling bit cannot be set. In R10, bit 5 is reserved, so the DAC switch has no effect. Use bit 3 for both. Fixes: 823dba519122 ("ASoC: Fix broken bitfield definitions in WM8978") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20261008130953.2446692-6-sammiee5311@gmail.com Signed-off-by: Mark Brown commit f7934340c56a84fc1b246ebf6b2e806d775f3b54 Author: HyeongJun An Date: Thu Oct 8 22:09:50 2026 +0900 ASoC: max98371: Fix the Speaker DHT Min Volume bits Register 0x31 holds two 4-bit fields. The datasheet puts SPK_GAIN_MIN at bits 7:4 and DHT_VROT_PNT at bits 3:0. The Speaker DHT Min Volume and Speaker DHT Rotation Volume controls both use bits 3:0. So setting the minimum speaker gain changes the DHT rotation point, and SPK_GAIN_MIN cannot be set. Move Speaker DHT Min Volume to bits 7:4. Fixes: ca2cd6bc6663 ("ASoC: Add max98371 codec driver") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20261008130953.2446692-5-sammiee5311@gmail.com Signed-off-by: Mark Brown commit b26edc925c1cfa0184cd270ed81d4833db045ce0 Author: HyeongJun An Date: Thu Oct 8 22:09:49 2026 +0900 ASoC: pcm3168a: Fix the DAC zero flag polarity bit The DAC Zero Flag Polarity enum uses PCM3168A_DAC_ATSPDA_SHIFT, which is bit 6 of register 70. That bit is ATSPDA, the attenuation speed, which the DAC Volume Rate Multiplier enum already owns. The datasheet puts ZREV, the zero flag polarity, at bit 0. The header defines PCM3168A_DAC_ZREV_SHIFT for it, but nothing uses it. So changing the zero flag polarity changes the attenuation speed, and ZREV cannot be set. Use PCM3168A_DAC_ZREV_SHIFT. Fixes: a9b17a638af5 ("ASoC: pcm3168a: Add driver for pcm3168a codec") Link: https://www.ti.com/lit/ds/symlink/pcm3168a.pdf Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An Reviewed-by: Cezary Rojewski Link: https://patch.msgid.link/20261008130953.2446692-4-sammiee5311@gmail.com Signed-off-by: Mark Brown commit 8b08b98796d2da103f2432550c14a7c687e72080 Author: HyeongJun An Date: Thu Oct 8 22:09:48 2026 +0900 ASoC: cs42l52: Fix the NG Type Switch bit The NG Type Switch enum selects between "Apply Specific" and "Apply All", which is the NGALL bit. The datasheet puts NGALL at bit 7 of the Noise Gate Control register. The enum uses bit 6, which is NG, the noise gate enable owned by the NG Enable Switch. cs42l52.h names it CS42L52_NG_ENABLE_SHIFT. cs42l56 has the same Noise Gate register and puts its NG All Switch at bit 7. So changing the noise gate type turns the noise gate on or off, and NGALL cannot be set. Use bit 7. Fixes: dfe0f98b8d2e ("ASoC: Add support for CS42L52 Codec") Link: https://statics.cirrus.com/pubs/proDatasheet/CS42L52_F2.pdf Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20261008130953.2446692-3-sammiee5311@gmail.com Signed-off-by: Mark Brown commit 203436d2aeb7093290459e344e1912a418a6ebfd Author: HyeongJun An Date: Thu Oct 8 22:09:47 2026 +0900 ASoC: cs42l56: Put the Limiter Cushion control on the limiter register The Limiter Cushion control writes bits 4:2 of the ALC Thresholds register. Those bits are ALCMIN, which the ALC MIN control owns. The datasheet puts CUSH at bits 4:2 of the Limit Thresholds Control register, next to LMAX, which the Limiter MAX control already uses. So setting the limiter cushion changes the ALC minimum threshold, and the cushion itself cannot be set. Use CS42L56_LIM_THRESHOLD_CTL. Fixes: 272b5edd3b8f ("ASoC: Add support for CS42L56 CODEC") Link: https://statics.cirrus.com/pubs/proDatasheet/CS42L56_F2.pdf Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20261008130953.2446692-2-sammiee5311@gmail.com Signed-off-by: Mark Brown commit 6ac4544eff796666ce6fbcc4be8181c81dfccc85 Author: Hui Su Date: Mon Oct 12 02:31:00 2026 +0900 sched_ext: idle: Respect task affinity in restricted CPU selection The restricted select_cpu kfunc path handles single-CPU and migration-disabled tasks without going through scx_select_cpu_dfl(). It currently uses prev_cpu as the candidate, even though prev_cpu is only a hint and may no longer be usable after an affinity change. With a caller-provided @allowed mask, this can also return an idle CPU outside p->cpus_ptr. Derive the candidate from task state instead: use the sole CPU in p->cpus_ptr for single-CPU tasks and task_cpu(p) for migration-disabled tasks. Validate it against p->cpus_ptr and @allowed before claiming its idle state. Since the derived candidate may be on a different NUMA node from prev_cpu, also preserve SCX_PICK_IDLE_IN_NODE by rejecting cross-node candidates. Perform all checks before scx_idle_test_and_clear_cpu(), as a successful call consumes the CPU's idle bit. Fixes: 683d2d0faba1 ("sched_ext: idle: Introduce scx_bpf_select_cpu_and()") Cc: stable@vger.kernel.org Signed-off-by: Hui Su Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo commit 5bdeca322a6f8d10acaf67cccab1f69747ee7be3 Author: Tejun Heo Date: Sun Oct 11 11:35:12 2026 -1000 sched_ext: Fix the bypass dispatch claim for schedulers bypassed by an ancestor scx_bypass() claims bypass dispatch when the scheduler's depth goes from zero to one and releases it when the depth returns to zero, but propagates only the depth to the descendants, not the claim. A descendant that starts bypassing with its ancestor never claims, and one whose own bypass ends under the ancestor's keeps its claim, as its depth does not return to zero. A sub-scheduler enable whose bypass ends under a PM suspend thus leaks its claim: the parent keeps hosting bypass dispatch and the sub-scheduler's next bypass trips the WARN_ON_ONCE() on the claim. A sub-scheduler disable that starts under a PM suspend has no claim, so once the resume lifts the root's bypass its tasks sit on the parent's bypass DSQs with nobody consuming them. Claim for every descendant whose depth goes from zero to one in the propagation and release every scheduler in the subtree whose depth returned to zero once the tasks have moved out of the bypass DSQs. A parent that is bypassing itself when a descendant claims consumes only its own bypass DSQs, empty until it leaves bypass and becomes the host. Fixes: aa2a0a19686c ("sched_ext: Separate bypass dispatch enabling from bypass depth tracking") Cc: stable@vger.kernel.org # v7.1+ Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit dcf7f650a24897d59b071f7f9a454d8b0b188b27 Author: Tejun Heo Date: Sun Oct 11 11:35:12 2026 -1000 sched_ext: Propagate every bypass depth change to the descendants scx_bypass() propagates a depth change to the descendants only when the scheduler's own depth crosses zero, so an own bypass that starts under an ancestor's never reaches them. When the ancestor's bypass ends first, the descendants leave bypass while the scheduler is still bypassing: a sub-scheduler disabled under a PM suspend has its children re-queue their tasks through their own BPF schedulers at resume, mid-teardown. If the own bypass then ends, every descendant is decremented once more than incremented and dec_bypass_depth() warns, though no current caller gets there. Propagate on every call so that a descendant's depth is the sum of its own bypasses and its ancestors'. The early return follows the walk, as a descendant's depth is at least the scheduler's and nothing changes bypass state unless the scheduler's own does. Fixes: c7f0e467a27a ("sched_ext: Prepare bypass mode for hierarchical operation") Cc: stable@vger.kernel.org # v7.1+ Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit 0936bbd35a247665c64886135835faa3c3f4f29f Author: Avi Weiss Date: Sun Oct 11 06:54:59 2026 +0300 ASoC: stm32: spdifrx: fix synchronization state check The interrupt handler uses a logical AND to check whether SPDIFRX was in the SYNC state before clearing errors. Since both SYNC (1) and ENABLE (3) are nonzero, this also treats ENABLE as SYNC (and any other non-zero value that might be added). The logical && basically just converts this to check for != 0. So errors occurring while SPDIFRX is enabled cause the driver to retry synch instead of disconnecting the PCM stream. Fix is to change the logical && to equality (==) and only retry when exactly in sync state. Fixes: 0c93c291321f2 ("ASoC: stm32: spdifrx: retry synchronization in sync state") Signed-off-by: Avi Weiss Reviewed-by: Olivier Moysan Link: https://patch.msgid.link/20261011035459.2289403-1-thnkslprpt@gmail.com Signed-off-by: Mark Brown commit f6be9f558a83fe30a03bd3adae461c821a0cef8c Author: Sergey Tiraspolsky Date: Sat Oct 10 03:37:53 2026 -0700 ASoC: Intel: avs: Reset the stream unless it is already prepared Commit cfca1637bc2b ("ASoC: Intel: avs: Unprepare a stream when XRUN occurs") resets the HDA stream when ->prepare() is called in the XRUN state. User space does not always recover that way. PipeWire's ALSA backend recovers from an underrun with snd_pcm_drop(), snd_pcm_prepare() and a new start, so ->prepare() runs in the SETUP state, hdac_stream->prepared is still set and the reset is skipped. Every recovery attempt then fails the same way: spa.alsa: hw:avsmax98927,1p: snd_pcm_avail after recover: Broken pipe On a Google Pixelbook (Kaby Lake, max98927 speakers) this happens after an occasional underrun during normal playback and silences the speakers for one to four minutes, until the PCM is closed. It can be provoked by stopping PipeWire with SIGSTOP for 0.5 s during playback: in one run that single underrun led to 1297 failed recoveries over two minutes, until the sink was suspended. A plain alsa-lib program that recovers with snd_pcm_drop() and snd_pcm_prepare() hits the same loop, while snd_pcm_prepare() straight from XRUN recovers at once. Skip the reset only when the stream is already PREPARED, the repeated ->prepare() case the check exists for, and reset it otherwise. With this change both kinds of recovery succeed with a single restart. Fixes: cfca1637bc2b ("ASoC: Intel: avs: Unprepare a stream when XRUN occurs") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Sergey Tiraspolsky Acked-by: Cezary Rojewski Link: https://patch.msgid.link/20261010103753.16969-1-stiraspo@gmail.com Signed-off-by: Mark Brown commit e90ab3669181c6469e3647ef2b30ae408275f496 Author: Paolo Bonzini Date: Fri Oct 9 14:37:10 2026 +0200 KVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes When running Hyper-V from Windows 11, KVM is seeing the SS bit set in nested page fault error codes produced for shadowed NPT. The AMD manual is unclear about when SS is set, including whether it can be set when SupervisorShadowStackEn (bit 6) is not set in the MISC_CTL field of the VMCB. Nevertheless, the unexpected SS bit causes out of bounds accesses in permission_fault(), seen as either WARNs or UBSAN reports: kernel: UBSAN: array-index-out-of-bounds in arch/x86/kvm/mmu.h:225:27 kernel: index 34 is out of range for type 'u16 [16]' (in this case, the page fault error code is 34*2=0x44, i.e. SS|U; the report shows SS|U|W happening as well). Fix the handling of unknown error codes by dropping SS and (with a WARN) any bits not among those that permission_fault() expects to receive. At the same time, given the uncertainty about when hardware sets SS, follow the processor's behavior when constructing the fault's error code, and preserve the SS bit as passed to FNAME(walk_addr_generic). While the behavior is surprising, there's a possibility that Hyper-V expects it (Hyper-V does not even enable CET unless it finds MBEC/GMET!), so retain the information when reflecting the fault to L1 instead of unconditionally discarding it. Bisection shows that this started happening with commit 687ee95c1b6d ("KVM: nSVM: enable GMET for guests"), even though SHSTK was available to guests since Linux 6.18. However, this is not because bit 1 of MISC_CTL (GMET) somehow enables reporting the SS bit; rather, it's simply that Hyper-V never uses CET unless GMET is also present. The WARN is reproducible even with gmet=0, with some hacking of kvm-unit-tests's cet.c testcase to ensure that the first access to the shadow stack triggers a page fault. Reported-by: SimonP Fixes: 8db428fd5229 ("KVM: SVM: Enable shadow stack virtualization for SVM") Cc: stable@vger.kernel.org Reviewed-by: Sean Christopherson Closes: https://lore.kernel.org/all/asUqYEisPp9MJ8mQ@rika.bernkas.tel Signed-off-by: Paolo Bonzini commit 8240e19d329e9e1502fc96608d8afe6861e9df90 Author: Liam R. Howlett Date: Thu Oct 8 21:10:10 2026 -0400 accel/amdxdna: Fix Kconfig invalid configuration The amdxdna has a soft dependency on the amd_pmf module. It will use an exported function if it is available and fall back to another function if it is not enabled. amdxdna and amd_pmf are tridstate modules supporting both built [y] and modularized [m] in the .config file. Since the amdxdna decides to use the amd_pmf if it is either a module or built in (see drivers/accel/amdxdna/aie2_pci.h), then there is an issue if they are not compiled either both as modules or both as built-in. Adding the optional dependency to Kconfig does not allow the configuration from being selected. Fixes: f66d6cc6891e4 ("accel/amdxdna: Support sensors for column utilization") Signed-off-by: Liam R. Howlett Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20261009011010.3521631-1-liam@infradead.org commit 8e2fbe0e75d38690d551456658194c632933cb57 Merge: 4f6ac74fa594a9 98d446b7c01325 Author: Paolo Abeni Date: Mon Oct 12 18:12:11 2026 +0200 Merge branch 'net-rds-rdma-cm-event-handler-fixes-for-non-ib-devices' Allison Henderson says: ==================== net/rds: RDMA-CM event handler fixes for non-IB devices This is v4 of Aohan Mei's fix for the uninitialized transport pointer in the RDMA-CM event handler (v1 at [1], v2 at [2], v3 at [3]), now a two-patch set. Patch 1 is the fix itself. v3 only rejected a connect request arriving on a non-IB device; the active side can bind an id to one as well, and resolving a route on an iWARP id leaves cm_id->route.path_rec unset, which the ROUTE_RESOLVED case dereferences. Such a connection is now dropped at ADDR_RESOLVED instead of resolving a route. Patch 2 fixes a neighbouring problem in the same case: a synchronous rdma_resolve_route() failure was handed back to the rdma_cm, which then destroyed an id RDS still owns as ic->i_cm_id and would later disconnect and destroy again from the connection's shutdown. On net-next the rdma_cm ids RDS creates are restricted to IB devices (commit c7fca8aae6fe), which makes the non-IB cases impossible there; these are the fixes stable kernels without that API need. [1] https://lore.kernel.org/netdev/20260824111701.2979194-1-ljp1205831794@gmail.com/ [2] https://lore.kernel.org/netdev/20260825021223.3483044-1-ljp1205831794@gmail.com/ [3] https://lore.kernel.org/netdev/20260928044507.335883-1-achender@kernel.org/ ==================== Link: https://patch.msgid.link/20261003163408.250568-1-achender@kernel.org Signed-off-by: Paolo Abeni commit 98d446b7c013254a8a7b49720557676a3a851fde Author: Allison Henderson Date: Sat Oct 3 09:34:08 2026 -0700 net/rds: don't let the rdma_cm destroy an id RDS still owns on route failure rds_rdma_cm_event_handler_cmn() hands the return value of rdma_resolve_route() straight back to the rdma_cm on RDMA_CM_EVENT_ADDR_RESOLVED. A synchronous failure there - -ENOMEM from the route work allocation, an SA query that cannot be set up, a RoCE route with no usable device - makes addr_handler() destroy the id the event was delivered on. That id is ic->i_cm_id, and nothing clears the pointer: the connection sits in RDS_CONN_CONNECTING with a freed id until its shutdown calls rdma_disconnect() and rdma_destroy_id() on it. The ROUTE_RESOLVED case already avoids this: rds_ib_cm_initiate_connect() forces a zero return while ic->i_cm_id == cm_id, as the comment there explains. Do the same here - drop the connection and return 0 - so the id stays RDS's to destroy from the shutdown, and the reconnect gets a fresh one. Fixes: 55b7ed0b582f ("RDS: Common RDMA transport code") Assisted-by: LLM Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20261003163408.250568-3-achender@kernel.org Signed-off-by: Paolo Abeni commit 7afc36c92a2812de36ec2e15a6f281fca081beab Author: Andy Yan Date: Sat Oct 10 21:46:48 2026 +0800 MAINTAINERS: update my email address Switch my contact address to andyshrk@163.com Signed-off-by: Andy Yan Reviewed-by: Sebastian Reichel Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20261010134705.2131-1-andyshrk@163.com commit 492ba6ac1b1ffb8a06ff52db0825c1af2cdb28c8 Author: Aohan Mei Date: Sat Oct 3 09:34:07 2026 -0700 net: rds: fix uninitialized trans dereference in CM event handler rds_rdma_cm_event_handler_cmn() assigns trans only when the RDMA device is an InfiniBand CA (RDMA_NODE_IB_CA). On any other device type, e.g. an iWARP RNIC such as siw, trans stays uninitialized, but the event switch dereferences it: unconditionally in the RDMA_CM_EVENT_CONNECT_REQUEST case via trans->cm_handle_connect(), and (with a connection context) in the ROUTE_RESOLVED and ESTABLISHED cases. An RDS listener on an iWARP device therefore crashes the kernel as soon as a connect request arrives: with CONFIG_INIT_STACK_ALL_ZERO the wild load becomes a NULL dereference at offset 0xa0 (&trans->cm_handle_connect) in the iw_cm_wq workqueue. GCC masks the bug in default builds by folding the uninitialized load into &rds_ib_transport; Clang-built kernels take the real uninitialized path and oops. The active side can land on a non-IB device too: the id that rds_ib_conn_path_connect() creates is not restricted to a node type, so rdma_resolve_addr() binds it to whichever device serves the local address, and an iWARP RNIC on the same netdev qualifies. The crash there is different: resolving a route on an iWARP id never fills in cm_id->route.path_rec, and the ROUTE_RESOLVED case writes path_rec[0].sl before it calls into the transport. The iWARP transport was dropped long ago and IB is the only transport left, so make that explicit: initialize trans to &rds_ib_transport at declaration, drop the conditional assignment, reject a connect request that arrives on a non-IB device, and drop a connection whose address resolved to one instead of resolving a route on it. The rejection is limited to RDMA_CM_EVENT_CONNECT_REQUEST on purpose: a non-zero return from the handler makes rdma_cm destroy the id the event was delivered on, which is right for the request's freshly created id but would free a connection id that RDS still owns for any other event. On the active side the id stays ic->i_cm_id and the connection's shutdown destroys it, so that case returns 0. Fixes: dcdede0406d3 ("RDS: Drop stale iWARP RDMA transport") Reported-by: TencentOS Corvus AI Link: https://lore.kernel.org/netdev/20260824111701.2979194-1-ljp1205831794@gmail.com/ Link: https://lore.kernel.org/netdev/20260825021223.3483044-1-ljp1205831794@gmail.com/ Cc: stable@vger.kernel.org Assisted-by: CodeBuddy:Kimi-K3 Signed-off-by: Aohan Mei [achender: reject only on RDMA_CM_EVENT_CONNECT_REQUEST instead of bailing out for every event on a non-IB device, so that rdma_cm does not destroy connection ids RDS still tracks; drop a connection whose address resolved to a non-IB device before a route is resolved on it; changelog adjusted] Assisted-by: LLM Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20261003163408.250568-2-achender@kernel.org Signed-off-by: Paolo Abeni commit ffbfd3f98f4393e91dffce3a46ccb7cf5329cf2f Author: Thomas Hellström Date: Fri Oct 9 09:00:53 2026 +0200 drm/xe: Don't transfer shrinker pages for pinned bos on purgeable state change Pinned bos have their pages removed from the shrinker's shrinkable / purgeable counts on pin, and added back on unpin according to the bo's purgeable state at that time. However, xe_bo_set_purgeable_shrinker() unconditionally transfers pages between the shrinkable and purgeable counts. If the purgeable state of a pinned bo changes, for example by userspace madvising DONTNEED on a VMA of a bo that is also pinned as a scanout buffer, this underflows one count and, after unpin, leaves the other one permanently inflated. Only update the purgeable flag for pinned bos, and leave the page accounting to unpin. Fixes: 536a2ead3a8f ("drm/xe/bo: Add purgeable shrinker state helpers") Cc: Arvind Yadav Cc: Matthew Brost Cc: Himal Prasad Ghimiray Cc: Rodrigo Vivi Cc: Matthew Auld Cc: intel-xe@lists.freedesktop.org Cc: # v7.1+ Assisted-by: LLM Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20261009070053.7790-1-thomas.hellstrom@linux.intel.com (cherry picked from commit afe6bc012034123fd838328668e609bf57e46bd3) Signed-off-by: Rodrigo Vivi commit 4f6ac74fa594a918d41255c941256e1d51592d3b Author: Michal Luczaj Date: Mon Oct 5 02:26:22 2026 +0200 vsock: treat TCP_CLOSING as once-established Handle the TCP_ESTABLISHED -> TCP_CLOSING transition on OP_RST, which can race with the connect loop. Immediately break and return 0 on ESTABLISHED/CLOSING. The return value of connect() should reflect what happened up to the point the connection was established or failed. Events that occur afterwards must not affect it. E.g. even if OP_RW has already set sk_err, connect() should still return 0, not ENOBUFS because of it. Adapt the inaccurate comment above signal_pending(). Resetting a socket that is still present in connected_table can lead to memory corruption. The reporter noted lost transports for in-flight skbs, and I have reproduced crashes caused by re-insertion into connected_table. list_add double add: new=, prev=, next=. kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:__list_add_valid_or_report+0x11f/0x130 Call Trace: vsock_insert_connected.cold+0xe/0x13 virtio_transport_recv_pkt+0x10e9/0x1460 vsock_loopback_work+0x305/0x480 process_one_work+0xe4c/0x1560 worker_thread+0x4f1/0xd60 kthread+0x36e/0x470 ret_from_fork+0x47b/0x6b0 ret_from_fork_asm+0x1a/0x30 This fix is supplementary to commit 002541ef650b ("vsock: Ignore signal/timeout on connect() if already established"). Details under Link. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reported-by: Hyunwoo Kim Link: https://lore.kernel.org/netdev/anzT1fREOSyHT99k@v4bel/ Signed-off-by: Michal Luczaj Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20261005-vsock-connect-reset-closing-v4-1-15d41cfda3ed@rbox.co Signed-off-by: Paolo Abeni commit 52336337f1a01ad803c7f3ddb23f40222e9ad58d Author: Sasha Levin Date: Sun Oct 11 18:33:33 2026 -0400 tools: gpio: fix building from the top level with O= "make O= tools/gpio" fails: Makefile:27: /tools/build/Makefile.include: No such file or directory tools/Makefile clears srctree, and the gpio Makefile only works it out again when building_out_of_srctree is not set, which the top-level Makefile sets for O= builds. Also work out srctree when it is empty, as tools/bpf/Makefile does since commit a89b2cbf71d64 ("tools, bpf: Fix build for 'make -s tools/bpf O='"). Fixes: 4a6a6f5c4aeed ("tools: gpio: Use !building_out_of_srctree to determine srctree") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Sasha Levin Link: https://patch.msgid.link/20261011223358.2327625-5-sashal@kernel.org Signed-off-by: Bartosz Golaszewski commit fcbc48dc650d2f58bfe19c4486830de0e9cad62e Author: Ming Yu Date: Wed Oct 7 17:20:50 2026 +0800 gpio: nct6694: Mark the GPIO controller as sleeping The GPIO callbacks take a mutex and issue USB transfers, so this GPIO chip must not be used in atomic context. Change the can_sleep switch in struct gpio_chip to true. Fixes: 611a995e8ae1 ("gpio: Add Nuvoton NCT6694 GPIO support") Signed-off-by: Ming Yu Link: https://patch.msgid.link/20261007092102.3768818-2-a0282524688@gmail.com Signed-off-by: Bartosz Golaszewski commit dbd674ccf30f66f5eccf637964a93910df8dbf84 Author: François Roux Date: Sun Oct 4 18:51:24 2026 +0200 power: sequencing: qcom-wcn: power off WLAN at probe The WLAN enable GPIO is requested with GPIOD_ASIS and then kept at its current level, so that a WLAN module left powered on by the firmware is not switched off. The FIXME explains why: toggling it would take the PCIe link down, and the controller driver could not recover from that. That reasoning held while the PCIe link was trained before the sequencer probed. Since commit b921aa3f8dec ("PCI/pwrctrl: Switch to pwrctrl create, power on/off, destroy APIs"), qcom_pcie_host_init() powers the endpoint through pwrctrl before it starts link training, and defers until the pwrctrl driver is bound. That driver cannot bind before this sequencer has probed. Power-on therefore always comes before link training, and keeping the firmware state is now harmful. On the Microsoft Surface Pro 11 (X1E80100), the WCN7850 sits on a PCIe port without a PERST# GPIO. While pci-pwrctrl-pwrseq is not yet bound, the host init is deferred about ten times, and each attempt powers the PHY and controller back down. The later power-on only sets a GPIO that is already high, so the chip is never reset and the link never comes up: qcom-pcie 1c08000.pcie: Device found, but not active The endpoint is not enumerated and ath12k never probes. Bluetooth on the same chip fails too ("QCA Failed to send TLV segment (-110)"). Request the GPIO as GPIOD_OUT_LOW. The chip is then off when the sequencer probes, and pwrctrl powers it up cleanly right before link training. Drop the FIXME and the code that preserved the firmware state. Tested on a Surface Pro 11: - b921aa3f8dec plus a one-line version of this change: endpoint enumerated at 2.4 s, ath12k and Bluetooth working. - next-20260929 plus this patch: "PCIe Gen.3 x2 link up" at 3.4 s, ath12k and Bluetooth working, Wi-Fi connected. Without the change, neither kernel enumerates the endpoint. The culprit was found by bisecting v6.17..v7.1, with the DTB and .config held constant. Fixes: b921aa3f8dec ("PCI/pwrctrl: Switch to pwrctrl create, power on/off, destroy APIs") Closes: https://lore.kernel.org/all/CAPjyS8dY0Q_o3XmFjuKZZsjhzhoSNL+ZGJtw5cQt8HiV3sUtxA@mail.gmail.com/ Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: François Roux Tested-by: Dale Whinham Link: https://patch.msgid.link/20261004165124.4277-1-franzelfranzel@gmail.com Signed-off-by: Bartosz Golaszewski commit 3f57b34485dc01e5a2db60a89a6ae5439a897e53 Author: Dave Stevenson Date: Fri Oct 2 10:36:43 2026 -0300 drm/vc4: hdmi: Move packet RAM enable to PM runtime Audio can be triggered by the HPD handler and start up before video has been restored, calling vc4_hdmi_write_infoframe() for the audio infoframe. vc4_hdmi_write_infoframe() needs Packet RAM to be on to store the infoframe, however, if the video hasn't been enabled, vc4_hdmi_encoder_post_crtc_enable() hasn't been called and therefore, the Packet RAM can be disabled by the time vc4_hdmi_write_infoframe() executes, causing the following splat: [ 201.570266] ------------[ cut here ]------------ [ 201.570293] Packet RAM has to be on to store the packet. [ 201.570367] WARNING: drivers/gpu/drm/vc4/vc4_hdmi.c:683 at vc4_hdmi_write_infoframe+0x404/0x494 [vc4], CPU#0: wireplumber/1606 [...] [ 201.658650] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 201.758499] Call trace: [ 201.760967] vc4_hdmi_write_infoframe+0x404/0x494 [vc4] (P) [ 201.766607] vc4_hdmi_write_audio_infoframe+0x1c/0x28 [vc4] [ 201.772247] write_infoframe+0xbc/0x140 [drm_display_helper] [ 201.777975] drm_atomic_helper_connector_hdmi_update_audio_infoframe+0x80/0xdc [drm_display_helper] [ 201.787140] vc4_hdmi_audio_prepare+0x4ac/0x570 [vc4] [ 201.792252] drm_connector_hdmi_audio_prepare+0x24/0x30 [drm_display_helper] [ 201.799390] hdmi_codec_prepare+0x100/0x160 [snd_soc_hdmi_codec] [ 201.805471] snd_soc_pcm_dai_prepare+0xd4/0x100 [snd_soc_core] [ 201.811375] __soc_pcm_prepare+0x60/0x12c [snd_soc_core] [ 201.816752] soc_pcm_prepare+0x34/0x58 [snd_soc_core] [ 201.821863] snd_pcm_do_prepare+0x70/0x8c [snd_pcm] [ 201.826798] snd_pcm_action_nonatomic+0xe4/0x174 [snd_pcm] [ 201.832350] snd_pcm_prepare+0xc8/0xd8 [snd_pcm] [ 201.837021] snd_pcm_common_ioctl+0x458/0x614 [snd_pcm] [ 201.842308] snd_pcm_ioctl+0x30/0x48 [snd_pcm] [ 201.846802] __arm64_sys_ioctl+0x88/0xd8 [ 201.850769] invoke_syscall+0x48/0xf4 [ 201.854470] el0_svc_common+0x80/0xd8 [ 201.858171] do_el0_svc+0x1c/0x28 [ 201.861520] el0_svc+0x3c/0xb0 [ 201.864605] el0t_64_sync_handler+0x68/0xdc [ 201.868834] el0t_64_sync+0x198/0x19c [ 201.872536] ---[ end trace 0000000000000000 ]--- Considering that Packet RAM enable is essentially a power management configuration, move its enabling/disabling to the Runtime PM hooks. Note that post_crtc_disable() still stops all infoframes, but keeps Packet RAM enabled, leaving it to be disabled by runtime suspend. Link: https://github.com/raspberrypi/linux/issues/7069 Fixes: b47a72f30768 ("drm/vc4: hdmi: Switch to HDMI connector") Signed-off-by: Dave Stevenson Acked-by: Maxime Ripard Link: https://patch.msgid.link/20261002-vc4-hdmi-packet-ram-fix-v1-1-3d73148096c9@igalia.com Reviewed-by: Maíra Canal Signed-off-by: Maíra Canal commit 41d1119e2f8577b4bd01d31321c6761af9140ce7 Author: Kees Cook Date: Mon Oct 12 02:04:25 2026 -0700 x86/kcfi: Emit the FineIBT paranoid "cs" prefix as a byte The "cs" prefix on the LEA in the FineIBT paranoid caller template is padding: it places the LEA's 0xf0 immediate byte where it doubles as the LOCK prefix that makes the failing Jcc raise #UD. GNU as warns about it in every CONFIG_FINEIBT=y build: Warning: segment override on `lea' is ineffectual Clang's integrated assembler does not warn, and both assemble the same bytes. Emit the prefix with ".byte 0x2e" to silence GNU as. Build tested ARCH=x86_64 defconfig with CONFIG_CFI=y, with GCC 17.0.0 (experimental, with the kCFI series) and GNU as 2.47, and with Clang 24.0.0git: GNU as no longer warns, and the template assembles to the same bytes as before with both. Under QEMU with cfi=fineibt,paranoid, the paranoid caller check catches LKDTM's CFI_FORWARD_PROTO with both. Assisted-by: LLM Signed-off-by: Kees Cook Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20261012090436.1676525-2-kees@kernel.org commit 4505a262deae7df06e33617dfc104d5541eec91d Author: Kees Cook Date: Mon Oct 12 02:04:24 2026 -0700 x86/kcfi: Decode the kCFI check from the trap address Since commit b2250d63e6422 ("x86/kcfi: Optimize call sequence"), a CONFIG_FINEIBT=y kernel running in kCFI mode rewrites each kCFI call site at boot so that a failed check traps on the 0xd6 byte of "test $0xd6, %al", one byte past where the compiler's "ud2" was. handle_cfi_failure() steps "addr" back one byte to find the trap in .kcfi_traps, but decode_cfi_insn() still decodes from regs->ip, so it reads each instruction starting at its second byte. "movl $-, %r10d" then decodes as "movl $-, %edx", so the reported type is right by accident, but "addl -15(%r11), %r10d" decodes as "addl -15(%rbx), %edx", so the reported target is whatever %rbx holds: CFI failure at lkdtm_indirect_call+0x16/0x20 (target: 0x12; expected type: 0xc79a2d1b) Pass the adjusted address to decode_cfi_insn() and decode from it. Tested ARCH=x86_64 defconfig with CONFIG_CFI=y and CONFIG_LKDTM=y under QEMU, with LKDTM's CFI_FORWARD_PROTO and both Clang 24.0.0git and GCC 17.0.0 (experimental, with the kCFI series). With CONFIG_FINEIBT=y in kCFI mode, the report gives %rbx as the target without this change, and the expected lkdtm_increment_int() with it. With cfi=fineibt, with cfi=fineibt,paranoid, and with CONFIG_FINEIBT=n, it gives lkdtm_increment_int() both with and without this change. Fixes: b2250d63e6422 ("x86/kcfi: Optimize call sequence") Assisted-by: LLM Signed-off-by: Kees Cook Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20261012090436.1676525-1-kees@kernel.org commit c5895eadf287116434b7b01d67b92e8146f7ff61 Author: Pablo Mazzini Date: Wed Oct 7 07:01:07 2026 +0100 pinctrl: sunxi: dt: do not accumulate npins across probe attempts init_pins_table() adds to npins in the driver's static descriptor, so after a probe deferral the count doubles and the next probe fails with "pin 0 already registered". Reset it first. Signed-off-by: Pablo Mazzini Fixes: f5e2cd34b12f ("pinctrl: sunxi: allow reading mux values from DT") Reviewed-by: Andre Przywara Signed-off-by: Linus Walleij commit 59f522f5a0ece96ce051a27d15533667a1d0dee8 Merge: 558c56d4bf7ea1 afb1ecfeda3fc3 Author: Arnd Bergmann Date: Mon Oct 12 10:27:47 2026 +0200 Merge tag 'at91-fixes-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/fixes Microchip AT91 fixes for v7.3 This update includes: - use the correct Kconfig flags for the Microchip KSZ switch * tag 'at91-fixes-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: ARM: configs: sama5: enable current Microchip KSZ DSA symbols Signed-off-by: Arnd Bergmann commit 558c56d4bf7ea146e07dd97f5fca600adb175384 Merge: 182d918a68f69b b86eaddf467a9d Author: Arnd Bergmann Date: Mon Oct 12 10:13:38 2026 +0200 Merge tag 'tegra-for-7.3-arm64-dt-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes arm64: tegra: Device tree fixes for v7.3 This contains various fixes for Tegra264. While the PWM and fan patches look like they'd be feature additions, I'd like to get them into stable kernels because without them, these devices either end up with the fan running at full speed or not at all, neither of which are great, but in case of the fan not running at all, it can cause the system to overheat. The remainder are some minor fixes for PCIe, mostly to satisfy the device tree validation. * tag 'tegra-for-7.3-arm64-dt-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: arm64: tegra: Add PCIe root ports on Tegra264 arm64: tegra: Reorder reg and reg-names to match bindings arm64: tegra: Add PWM fan on Jetson AGX Thor DevKit arm64: tegra: Add PWM controllers on Tegra264 Signed-off-by: Arnd Bergmann commit 182d918a68f69b693e59c64af2572bdde07cbed2 Merge: 2f46e80fa993fd 2fabd2f406d0cf Author: Arnd Bergmann Date: Mon Oct 12 09:22:01 2026 +0200 Merge tag 'omap-for-v7.3/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap into arm/fixes ARM: dts: OMAP fixes for v7.3-rc - ti/omap: dra7: fix PCIe PHY clock divider definition * tag 'omap-for-v7.3/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap: ARM: dts: ti/omap: dra7: fix PCIe PHY clock divider definition Signed-off-by: Arnd Bergmann commit 2f46e80fa993fdee5e4fc5da80436e3e21bc2bd0 Merge: d610d871b18ee3 0f70fd6f4c1d6c Author: Arnd Bergmann Date: Mon Oct 12 09:19:45 2026 +0200 Merge tag 'riscv-dt-fixes-for-v7.3-rc' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes RISC-V devicetrees fixes for v7.3-rc Microchip: Remove double definition of interrupts on the BeagleV-Fire, which cause the sensor to be associated the wrong plic interrupt. Signed-off-by: Conor Dooley * tag 'riscv-dt-fixes-for-v7.3-rc' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: riscv: dts: microchip: beaglev-fire: remove double definition of gpio interrupts commit d610d871b18ee36ace235b0c01388518b9643976 Merge: 1fc2d80928b706 c5c95dbdc9011a Author: Arnd Bergmann Date: Mon Oct 12 09:17:14 2026 +0200 Merge tag 'tegra-for-7.3-soc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes soc/tegra: Fixes for v7.3 This contains two minor fixes for a missing newline in an error message and an uninitialized clock rate used during suspend. * tag 'tegra-for-7.3-soc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: soc/tegra: pmc: Fix uninitialised clock rate soc/tegra: fuse: Add missing newline to APBMISC error message Signed-off-by: Arnd Bergmann commit a1ddc2721467fb68241372db77657fd0dcf6cda5 Author: Sasha Levin Date: Sun Oct 11 18:33:41 2026 -0400 bootconfig: give the footer size static_assert a message static_assert() without a message is a C23 feature, so clang warns: main.c:498:56: warning: '_Static_assert' with no message is a C23 extension [-Wc23-extensions] Add a message. Link: http://lkml.kernel.org/r/20261011223358.2327625-13-sashal@kernel.org Fixes: 6ed5e20466c79 ("bootconfig: Fix unaligned access when building footer") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Sasha Levin Signed-off-by: Masami Hiramatsu (Google) commit 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907 Author: Linus Torvalds Date: Sun Oct 11 20:04:55 2026 -0700 Linux 7.3-rc7 commit e415915c5258ec7da3d783fba5e9983d03a76d07 Author: Dmitry Osipenko Date: Thu Oct 8 01:22:44 2026 +0300 Revert "drm/virtio: Add pixel blend mode property to cursor plane" The cursor blending mode was added twice because the same change was applied by accident from different patches. Revert the second patch. Reported-by: Marek Szyprowski Link: https://lore.kernel.org/dri-devel/ce84d3d2-e78b-4939-aecf-9ef7267bd42a@samsung.com/ Fixes: 6947b78df4d2 ("drm/virtio: Add pixel blend mode property to cursor plane") Signed-off-by: Dmitry Osipenko Reviewed-by: Marek Szyprowski Link: https://patch.msgid.link/20261007222244.295186-1-dmitry.osipenko@collabora.com commit d6d3455d8751854e0d1820f14184682e23ac4475 Merge: f47959816751f0 3d8cc52db2f86b Author: Linus Torvalds Date: Sun Oct 11 11:49:08 2026 -0700 Merge tag 'landlock-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux Pull Landlock fix from Mickaël Salaün: "This fixes a Clang bug by removing an annotation, which was introduced mostly for documentation" * tag 'landlock-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux: landlock: Drop __counted_by from landlock_domain.handled_masks commit f47959816751f02a711aab27cf1c805bd4964819 Merge: 5906f156e8818d 00765a3467b992 Author: Linus Torvalds Date: Sun Oct 11 11:33:26 2026 -0700 Merge tag 'spi-fix-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A small collection of driver specific fixes, plus a new device ID in the DesignWare device tree binding. One of the sg2044 fixes which enforces clock limits properly is more critical than average since getting them wrong might lead to data corruption" * tag 'spi-fix-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: dt-bindings: snps,dw-apb-ssi: Add Synaptics sl2610 spi spi: sg2044-nor: Honor SPI clock limits spi: sg2044-nor: Return transfer errors spi: cadence-qspi: Fix status polling with octal DTR chips spi: spi-nxp-fspi: exit stop mode before waiting for DLL lock commit 5906f156e8818d29839d7d7280b691f627b59883 Merge: d5b6dc381db93f 28c2388ee24cdb Author: Linus Torvalds Date: Sun Oct 11 11:28:36 2026 -0700 Merge tag 'regulator-fix-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "There's a couple of core fixes here: there were a couple of issues with of_regulator_bulk_get_all() not behaving consistently with the other bulk regulator APIs which caused memory leaks and error handling issues in users. We also have a couple of fairly standard driver specific fixes" * tag 'regulator-fix-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: ltc3676: don't read the write-only HRST and CLIRQ registers regulator: of: state who owns the array from of_regulator_bulk_get_all() regulator: of: fill in supply names in of_regulator_bulk_get_all() regulator: tps6594-regulator: Fix n_linear_ranges for TPS65224 BUCK2-4 commit d5b6dc381db93ff2d1888f7d99c06e0bd85f4083 Merge: 4375b45d7060a6 469fa055664bfd Author: Linus Torvalds Date: Sun Oct 11 09:23:19 2026 -0700 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Driver (and tape media changer) only fixes. Three of the fixes are about the same size, (ch, ufs decouble CQ and ufs avoid unsafe MMIO) but the unsafe MMIO is the least obvious logic change" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufs: core: Decouple CQ sweep from request iterator in MCQ scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock() scsi: ch: Do not keep references to data transfer element devices scsi: ufs: mediatek: Handle mPHY power-on failures scsi: qedi: Initialize callback state before registration scsi: ufs: core: Hold a clock reference across the probe commit 4375b45d7060a6a3f41e14a9181c5c913ea474a4 Merge: b7c0316c1a062d 41cab3a71dc7be Author: Linus Torvalds Date: Sun Oct 11 09:00:33 2026 -0700 Merge tag 'block-7.3-20261010' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull block fixes from Jens Axboe: - NVMe fixes via Keith: - Fix swapped ZRASF zone state values for full and read only - nvme-multipath revalidate head zones after unfreezing the head queue - Revert "nvme: do not reset controllers in NVME_CTRL_NEW state", which broke things - nvmet fixes for invalid NSIDs on feature 82h and using the local P2P device on metadata allocation failure - zloop: zero out only the unread tail of a short read * tag 'block-7.3-20261010' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: Revert "nvme: do not reset controllers in NVME_CTRL_NEW state" zloop: zero out only the unread tail of short reads nvmet: use the local P2P device on metadata allocation failure nvme-multipath: revalidate head zones after unfreezing the head queue nvme: fix swapped ZRASF zone state values for full and read only nvmet: return Invalid Field for invalid NSIDs feature 82h commit 3d8cc52db2f86b624308321c58513019f6b21eec Author: Nguyen Ngoc Thang Date: Sat Oct 10 23:44:49 2026 +0700 landlock: Drop __counted_by from landlock_domain.handled_masks With clang 22 and CONFIG_FORTIFY_SOURCE, the second landlock_restrict_self() call hits a bogus fortify report in inherit_ruleset(): memcpy: detected buffer overflow: 4 byte write of buffer size 0 Call Trace: __fortify_panic landlock_merge_ruleset __se_sys_landlock_restrict_self handled_masks[] lives in an anonymous struct inside the anonymous union that overlays work_free. For such a flexible array, clang computes the address of the __counted_by counter as the start of the array instead of &num_layers. The bound is then read from handled_masks[0], i.e. from the first layer's access masks, which is not a count. The same layout crashes clang itself in a standalone test. The annotation was added as documentation, so drop it rather than restructure the union. Keep the information in the member comment. Reported-by: syzbot+a0eecb22de4d821a9e5d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a0eecb22de4d821a9e5d Fixes: bd3a19800dd1 ("landlock: Add counted_by in landlock_domain") Signed-off-by: Nguyen Ngoc Thang Link: https://lore.kernel.org/r/20261010164450.194439-1-ngocthang2710.1999@gmail.com Reviewed-by: Günther Noack Reported-by: Konrad Dybcio Reported-by: Mike Bommarito Closes: https://lore.kernel.org/r/20261009115108.17819-1-michael.bommarito@gmail.com [mic: Rebased on master, where the array is handled_masks[], updated the fortify report, added the clang bug link and the other reports] Signed-off-by: Mickaël Salaün commit b7c0316c1a062dbadd0d62f1b796dd3264915242 Merge: 5f97a3ec36a1c2 fddcf4c5321b3e Author: Linus Torvalds Date: Sun Oct 11 08:53:11 2026 -0700 Merge tag 'io_uring-7.3-20261010' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull io_uring fixes from Jens Axboe: - Don't spin on local work the exiting task can't run. For a ring still R_DISABLED when the task got its tctx node, the submitter is set later and may be another task, so DEFER_TASKRUN local work stays pending forever and the exiting task spins in do_exit(). - Don't charge the SQ/CQ rings or provided buffer rings to RLIMIT_MEMLOCK. The region API conversion started charging them, which the rings had been exempt from. - Don't exempt disabled rings from task restrictions on register - Populate the CONNECT filter fields for a 24-byte sockaddr_in6 * tag 'io_uring-7.3-20261010' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: io_uring/cancel: don't spin on local work the task can't run io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6 io_uring/register: don't exempt disabled rings from task restrictions io_uring/kbuf: don't charge provided buffer rings to RLIMIT_MEMLOCK io_uring: do not charge the SQ/CQ rings to RLIMIT_MEMLOCK commit 5f97a3ec36a1c2c9e4847eaf1b071707792b9035 Merge: 4d61397c866eb1 7dfb218c829c1a Author: Linus Torvalds Date: Sun Oct 11 08:34:34 2026 -0700 Merge tag 'xfs-fixes-7.3-rc7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux Pull xfs fixes from Carlos Maiolino: "This fixes a data corruption vector where a user could trick the exchange-range feature to add shared blocks beyond the file's EOF, which may then be used to modify data on another file" * tag 'xfs-fixes-7.3-rc7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: fix exchange-range-to-eof file size exchange xfs: stop exchanging reflink flags when exchanging mappings commit 4d61397c866eb1ae656c39fa9f28766e4388776b Merge: b2d929a1c2a887 87db7795cbaaf6 Author: Linus Torvalds Date: Sun Oct 11 08:23:06 2026 -0700 Merge tag 'x86-urgent-2026-10-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fix from Ingo Molnar: - Work around AMD TLBI Erratum #1718 (Borislav Petkov) * tag 'x86-urgent-2026-10-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/CPU/AMD: Fix AMD TLBI Erratum #1718 commit b2d929a1c2a887dd046e0af2d4a06dbf4e7d87a6 Merge: b88c841d116419 d4f25b097e46d8 Author: Linus Torvalds Date: Sun Oct 11 08:13:52 2026 -0700 Merge tag 'riscv-for-linus-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: "Several security fixes, a significant strnlen() regression fix, and several other miscellaneous fixes: - Fix a regression in the Zbb-enabled strnlen() implementation when huge counts are specified - When userspace pointer masking is enabled, strip the tag from user-specified pointers in two spots in the RISC-V futex code where this was missing - When CONFIG_SHADOW_CALL_STACK=y, use a supervisor mode-only CSR bit to determine whether the trap came from userspace or not, rather than a userspace-writable register - Reset the HSTATUS.HU bit during CPU initialization to avoid unexpected behavior, as the RISC-V specification does not require this bit to be hardware-reset - Fix the T-Head GhostWrite probing code when !CONFIG_ERRATA_THEAD_MAE - Fix RV32 boots using 32-bit.config by constraining NR_CPUS - Implement a workaround for SiFive MAL-9092, which requires fences around hypervisor load/store instructions - Fix the RISC-V patch_map() code to work properly for EXECMEM addresses when !CONFIG_STRICT_MODULE_RWX - Fix ptrace register set access reporting when CFI landing pad or shadow stack support is enabled - Avoid copying garbage into the target's vstate when PTRACE_SETREGSET is called with a short iov_len - Fix load_unaligned_zeropad() on RV32 kernels with CONFIG_RISCV_EFFICIENT_UNALIGNED_ACCESS=y - Fix build breakage for any userspace program that includes uapi/asm/vendor/mips.h - Fix a build warning for 32-bit allmodconfig builds related to SiFive errata - Fix misspecified inline assembly constraints in the vector context save/restore code" * tag 'riscv-for-linus-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: fix load_unaligned_zeropad() fixup for RV32 riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp riscv: ptrace: Zero-initialize regset buffers before copyin riscv: ptrace: reject CFI regset access when extensions are absent riscv: fix NR_CPUS range leaking 64-bit default onto 32-bit builds riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE riscv: futex: untag the user pointer before the atomic access riscv: lib: Fix ZBB strnlen wrap-around regression on huge counts riscv: patch: fix handling of bpf-jit execmem addresses RISC-V: Clear HSTATUS.HU on CPU initialization RISC-V: errata: Add SiFive MAL-9092 workaround riscv: vector: Fix output operands in context save riscv: vector: Fix data pointer constraints in context save/restore riscv: limit sifive errata to CONFIG_64BIT riscv: hwprobe: use _BITULL() rather than BIT() in MIPS vendor uapi header commit b88c841d11641923fa3a4da011d7202cd89df68a Merge: a5ebb76233b79d 41363c27b8509b Author: Linus Torvalds Date: Sun Oct 11 08:10:43 2026 -0700 Merge tag 'input-for-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: - A fix for the ati_remote2 sysfs attributes handling, resolving type confusion after conversion to dev_groups - Updates to the xpad joystick driver adding support for the Corsair Novablade Pro controller (wired and 2.4 GHz wireless) and a newer hardware revision of the 8BitDo Pro 2 Wired Controller for Xbox. * tag 'input-for-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: xpad - add support for 8BitDo Pro 2 Wired Controller for Xbox Input: xpad - add support for Corsair Novablade Pro Input: ati_remote2 - fix type confusion in device attribute handlers commit 7dfb218c829c1acb626e0fe92c5fddb9a26a03e9 Author: Darrick J. Wong Date: Wed Oct 7 10:02:27 2026 -0700 xfs: fix exchange-range-to-eof file size exchange 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 commit d84d6c1a7f1e2de9e601703a326a4c1b7b421943 Author: Norbert Szetei Date: Wed Oct 7 16:43:22 2026 +0200 xfs: stop exchanging reflink flags when exchanging mappings 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 commit a5ebb76233b79db01e82e061173cb73c6d2b5c6b Merge: bb934c29fda8dc 7484bc43ba6b8e Author: Linus Torvalds Date: Sat Oct 10 16:57:30 2026 -0700 Merge tag 'edac_urgent_for_v7.3_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras Pull EDAC fix from Borislav Petkov: - amd64_edac: Shorten the ErrorInformation field read from the MCA_SYND MSR to only two bits. It is perfectly fine to do so because no system ever supported more than 2 bits of information (the Chip Selects used were only 4 maximum) and newer hardware will use only 2 bits anyway * tag 'edac_urgent_for_v7.3_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/amd64: Mask UMC chip select to the four implemented selects commit bb934c29fda8dcd409145a0deddc1a8095fec930 Merge: b62f58bd7187dd c61e23ed14359e Author: Linus Torvalds Date: Sat Oct 10 16:50:50 2026 -0700 Merge tag 'drm-fixes-2026-10-11' of https://gitlab.freedesktop.org/drm/kernel Pull drm fixes from Dave Ailie: "Live from Dublin Airport, it's Saturday Night drm fixes. This week has the missing misc fixes from last week which I tracked down and seemed to be a race/bug in my lei setup somehow, once I asked lei to ignore it's cache I got the missing email. But there are more misc fixes this week and amd and intel ones. The main ones in this are amdgpu and xe, with vc4, vmwgfx, nouveau and imagination in the middle, with a bunch of small single fixes. Bit busier than I'd like, but the missing misc might explain it, anyways time for me to fly home. fb: - defer setup when fbdev_probe() fails, not just on -EAGAIN bridge: - Fix unlocked list_del in drm_bridge_add() - Fix unlocked list access in drm_bridge_attach() - th1520-dw-hdmi: - Fix error check on dw_hdmi_probe() return value - Fix remove() callback aspeed: - Balance the display clock enable on teardown i915: - Fix a GT park race that could trigger spurious RPM wakelock warnings - Fix execbuffer relocation cleanup to avoid out-of-bounds free xe: - i2c removal - system Controller Maibox header handling - two bo pin/unpin accounting bugs - not emitting a w/a twice - xe_mmio_wait32() to honor delay/sleep maximums amdgpu: - Fix direct scanout alpha on some DRM_FORMATs - UserQ fixes - Fix tearing flips with PSR - GPU reset vblank fix - Debugfs register interface fix - Fix display mode patching - Expand Mac reserved memory workaround amdkfd: - SDMA doorbell fix - Fix dma-buf reference leak in error path imagination: - fix reference and vm_bo handling in remap() - size page table preallocation by device address gud: - don't keep a connector without a CRTC as connector_state panthor: - validate userspace queue count against initialized firmware slot count nouveau: - fix null ptr regression - skip turing CE workaround for non-GR vmwgfx: - validate pitch value - add blend mode property vc4: - drain hangcheck timer on unbind - free BO cache on teardown - use kvmalloc_objs for bo cache size list - disable V3D interrupt across runtime suspend - fix binner slot allocation - fix fw refcount leak" * tag 'drm-fixes-2026-10-11' of https://gitlab.freedesktop.org/drm/kernel: (39 commits) drm/nouveau: Skip the Turing CE workaround object for non-GR channels drm/vc4: Fix binner slot allocation failing on an idle GPU drm/vc4: Disable the V3D interrupt across runtime suspend drm/imagination: Size page table preallocation by device address drm/imagination: Fix reference and vm_bo handling in remap() drm/amdgpu: make Mac FB workaround generic drm/amdkfd: fix dma_buf reference leak in get_dmabuf_info drm/amd/display: Don't replace a sink mode that shares the native totals drm/amdkfd: align SDMA doorbell base for shader doorbell writes drm/amdgpu: copy debugfs register data outside the GRBM/SRBM locks drm/amdgpu: serialize vblank counter reads against GPU reset drm/amd/display: disable self-refresh on tearing flips drm/amdgpu/userq: return the memdup_user() error for the user MQD drm/amdgpu/userq: only accept doorbell BOs as queue doorbell drm/amd/display: Fix direct scanout alpha on some DRM_FORMATs drm/xe/i2c: cancel the client work on remove drm/xe/sysctrl: Fix mailbox header handling drm/i915/gt: Unmask interrupts only when ACTIVE is true drm/i915/gem: Prevent overstepping exec array boundary drm/gud: don't keep a connector without a CRTC as connector_state ... commit b62f58bd7187ddbefa66913ec742137680ca5b22 Merge: 3857c2fe544954 ae836408557420 Author: Linus Torvalds Date: Sat Oct 10 16:41:28 2026 -0700 Merge tag 'i2c-fixes-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull i2c fix from Andi Shyti: "Just one qcom-geni fix for a runtime PM reference leak during transfer setup" * tag 'i2c-fixes-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: i2c: qcom-geni: release runtime PM reference when set_rate fails commit c61e23ed14359e6289c08e55940dd3401fe27db0 Merge: 492c4ded0ff7c7 6ccf996a0dec18 Author: Dave Airlie Date: Sun Oct 11 04:57:56 2026 +1000 Merge tag 'drm-misc-fixes-2026-10-09' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A pointer assignment fix for gud, a reference fix and a preallocation size fix for imagination, a suspend fix and an allocation fix when idle for vc4, and a hardware variant fix for nouveau. Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patch.msgid.link/asjkbknTHg2t8JGy@houat commit 492c4ded0ff7c7f162f35eea37984db5b0f2b5ba Merge: a8013cbe8d4030 c7f44ec5c4ec76 Author: Dave Airlie Date: Sun Oct 11 04:53:22 2026 +1000 Merge tag 'amd-drm-fixes-7.3-2026-10-08' of https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.3-2026-10-08: amdgpu: - Fix direct scanout alpha on some DRM_FORMATs - UserQ fixes - Fix tearing flips with PSR - GPU reset vblank fix - Debugfs register interface fix - Fix display mode patching - Expand Mac reserved memory workaround amdkfd: - SDMA doorbell fix - Fix dma-buf reference leak in error path Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patch.msgid.link/20261008174658.2506431-1-alexander.deucher@amd.com commit a8013cbe8d403051aae151f9e35e5f3c8af89a02 Merge: 5a768f5f76d883 611857adc9e7b0 Author: Dave Airlie Date: Sun Oct 11 04:47:12 2026 +1000 Merge tag 'drm-xe-fixes-2026-10-08' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Fixes on: - i2c removal (Fan) - system Controller Maibox header handling (Mallesh) - two bo pin/unpin accounting bugs (Thomas) - not emitting a w/a twice (Tvrtko) - xe_mmio_wait32() to honor delay/sleep maximums (Alan) Signed-off-by: Dave Airlie From: Rodrigo Vivi Link: https://patch.msgid.link/asfEfgbIjs0GJ-RF@intel.com commit 069403dff337feb192bfc70fb28ddc8a171e20c1 Author: Tejun Heo Date: Fri Oct 9 12:01:45 2026 -1000 sched_ext: Fix use-after-free of a destroyed user DSQ by a deferred reenqueue A deferred reenqueue can read a freed user DSQ. The request stays on its CPU's deferred list until run_deferred() takes it, and the RCU callback that frees the DSQ assumes that the grace period has flushed it, so exit_dsq() checks the per-CPU node without the deferred list lock. A grace period waits for readers in flight, not for a pending run_deferred(). A run_deferred() which starts after the grace period began can detach the request right before the callback looks and then read the freed DSQ's id. Cancel the pending requests before the grace period instead. The irq work that frees the DSQ unlinks every CPU's request under the per-CPU deferred list lock, and schedule_dsq_reenq() ignores a new request under the same lock once the id is invalid. Only a run_deferred() that started before the grace period can hold a request, and it runs with IRQs disabled, so the grace period waits for it and nothing touches the DSQ after the callback. Fixes: 84b1a0ea0b7c ("sched_ext: Implement scx_bpf_dsq_reenq() for user DSQs") Cc: stable@vger.kernel.org # v7.1+ Reported-and-tested-by: Hui Su Link: https://lore.kernel.org/all/20261008024753.4096008-1-sh_def@163.com/ Signed-off-by: Tejun Heo commit 7a9df76679633cf26e0fea882a684012c6ec245a Author: Tejun Heo Date: Wed Oct 7 06:26:47 2026 -1000 sched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQ With SCX_OPS_ENQ_LAST, the last runnable task on a CPU is passed to ops.enqueue() instead of being kept running. Exiting tasks without SCX_OPS_ENQ_EXITING, migration disabled tasks without SCX_OPS_ENQ_MIGRATION_DISABLED and tasks on an offline rq skip ops.enqueue() and go straight to the local DSQ. This happens in put_prev_task_scx() after the pick has settled on idle, so nothing reschedules the CPU, which idles with the task queued until an unrelated wakeup lands on it or the watchdog fires. scx_mitosis, which sets SCX_OPS_ENQ_LAST without SCX_OPS_ENQ_EXITING, hit this during mass cgroup teardown: exiting tasks stuck in exit_mmap() for over 40 seconds. A task put on the local DSQ runs, as anywhere else. If the SCX_ENQ_LAST enqueue left the task on this CPU's local DSQ, set need_resched on the task being switched in, as proxy_resched_idle() does. resched_curr() would flag the task being put instead, and __schedule() clears that right after the pick. Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Cc: stable@vger.kernel.org # v6.12+ Reported-by: Xiangyu Bu Link: https://github.com/sched-ext/scx/pull/3870 Signed-off-by: Tejun Heo Cc: Dan Schatzberg commit 3857c2fe5449541e24afc5efdb0f81a8a8f9a3a0 Merge: b71ccf604fbdf7 79c168e2aa957e Author: Linus Torvalds Date: Sat Oct 10 01:30:04 2026 +0200 Merge tag 'pci-v7.3-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fix from Bjorn Helgaas: "This fixes some GPU initialization regressions caused by eddba19b8b5f ("PCI/AER: Support Advisory Non-Fatal Errors"), which appeared in v7.3-rc1. That commit also caused a MacBookPro16,1 spontaneous power-off regression; I expect a fix for that next week" * tag 'pci-v7.3-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI/AER: Skip error recovery on false alarms commit b71ccf604fbdf78450d3b17b5d69365caba29061 Merge: f7bec60381da15 c96ca94425b076 Author: Linus Torvalds Date: Sat Oct 10 01:26:56 2026 +0200 Merge tag 'mmc-v7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC/MEMSTICK fixes from Ulf Hansson: "MMC host: - cavium-octeon|thunderx: Destroy slot platform devices on remove - mtk-sd: Cancel request timeout work on remove - sdhci-sprd: Disable runtime PM on remove MEMSTICK: - Wait for request completion before freeing card - rtsx_usb_ms: Complete requests after eject instead of dropping them" * tag 'mmc-v7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: memstick: rtsx_usb_ms: complete requests after eject instead of dropping them memstick: core: wait for request completion before freeing card mmc: cavium-thunderx: destroy slot platform devices on remove mmc: cavium-octeon: destroy slot platform devices on remove mmc: sdhci-sprd: disable runtime PM on remove mmc: mtk-sd: Cancel request timeout work on remove commit f7bec60381da152e110bb71358c0903f9bc1826e Merge: 5f6ee187fa3a7b 2579cbe68005f4 Author: Linus Torvalds Date: Sat Oct 10 01:22:38 2026 +0200 Merge tag 'media/v7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media fix from Mauro Carvalho Chehab: "A fix for em28xx unregister code affecting devices with FM radio support" * tag 'media/v7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: media: em28xx: use video_unregister_device for radio_dev commit 5f6ee187fa3a7b3cee4b9dae6c3dda6d1d3237db Merge: 9a06d4b7c5feed 07c75552f7fe63 Author: Linus Torvalds Date: Sat Oct 10 01:20:08 2026 +0200 Merge tag 'sound-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A dozen of small fixes. All device-specific quirks or fixes, and nothing exciting is expected. - USB-audio and HD-audio quirks - HD-audio TAS2781 codec fix - ctxfi driver memory leak fix - ASoC AMD quirks - ASoC cs35l56 and adau1372 codec fixes" * tag 'sound-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ASoC: amd: acp: Add more ACP7.0 match entries for Cirrus Logic parts ASoC: amd: acp: Add DMI override for ASUS EXPERTBOOK AM7406CKA ASoC: sdw_utils: Switch CS35L56/57/62/63 to use OT25 DAI ASoC: cs35l56: Add DAI for SDCA OT25 stream ASoC: samsung: i2s: enable op_clk in probe to balance runtime PM ASoC: adau1372: fix invalid default state of output ASRC and DAC muxes ASoC: adau1372: allow sleepy powerdown GPIOs ASoC: amd: yc: Add DMI quirk for Acer Aspire Go 15 (AG15-21P) ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg3xxx (103c:8bfd) ALSA: hda/tas2781: Accept V1 calibration data without CRC ALSA: ctxfi: Fix memory leakage when clearing DAO input mappers ALSA: hda/realtek: Add quirk for ASRock NUC BOX-358H ALSA: usb-audio: Add native DSD support for Cambridge Audio streamers commit 9a06d4b7c5feedea819a00af0db1629e43f3def4 Merge: c8d4256f1081c1 4c66c423593e26 Author: Linus Torvalds Date: Sat Oct 10 00:57:46 2026 +0200 Merge tag 'pmdomain-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm Pull pmdomain provider fixes from Ulf Hansson: - imx: Serialize power on/off across sibling domains for imx8m-blk-ctrl - rockchip: Fix a couple of errors during probe * tag 'pmdomain-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm: pmdomain: rockchip: don't ignore clock lookup errors on attach pmdomain: rockchip: fix clock leak on domain probe failure pmdomain: rockchip: propagate subdomain add errors pmdomain: imx8m-blk-ctrl: Serialize power on/off across sibling domains commit c8d4256f1081c191773de9f46e2ad8f5e8d05d30 Merge: fc1c25014ff8e4 911655ab1dfb9d Author: Linus Torvalds Date: Sat Oct 10 00:49:55 2026 +0200 Merge tag 'dma-mapping-7.3-2026-10-09' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux Pull dma-mapping fixes from Marek Szyprowski: "Two more fixes for the corner cases in the DMA-mapping SWIOTLB code (Peng Fan and Marek Szyprowski)" * tag 'dma-mapping-7.3-2026-10-09' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux: swiotlb: fix default_swiotlb_limit() for non-growable default pool iommu/dma: skip swiotlb bounce for DMA_ATTR_MMIO in iommu_dma_map_phys commit fc1c25014ff8e416d75e8a5ba3b9c0ba5eb8e877 Merge: f99005fbed4e80 e58c3805ed325f Author: Linus Torvalds Date: Sat Oct 10 00:01:12 2026 +0200 Merge tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux Pull fsverity fix from Eric Biggers: "Fix a regression from commit f77f281b6118 ("fsverity: use a hashtable to find the fsverity_info")" * tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux: fsverity: RCU-delay the freeing of struct fsverity_info commit f99005fbed4e8071110faa350cc5fa453afa1455 Merge: 9515f634dbed2b 3d399224425573 Author: Linus Torvalds Date: Fri Oct 9 23:37:44 2026 +0200 Merge tag 'vfs-7.3-rc7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: "This contains fixes for the current development cycle. All of them came out of a review of the mount code that started with a bug report. The review modeled the corner cases of mount propagation, unmounting and mount reference counting and turned up a lot of bugs. Most of them years old. Most fixes come with a selftest. - Rework connected mounts. A mount that is unmounted together with its parent can stay attached to the parent to keep its mountpoint covered. That happens when the mountpoint is removed with rmdir(), unlink() or rename(), when a detached tree is dissolved, and for locked mounts in any umount that isn't synchronous, including the teardown of their mount namespace. The parent then owns the child and drops it on its own final mntput(). So any reference from the child's superblock back to one of its ancestors becomes a cycle that is never freed. A loop device backed by an image on a tmpfs and mounted on that same tmpfs is enough. Remove the directory the tmpfs is mounted on from the host, let the container's mount namespace exit, and the loop device, the tmpfs and the filesystem on the loop device are leaked for good. The same works with autofs, zram, ecryptfs, binfmt_misc, fuse passthrough, zloop, a mass storage gadget and md, and the selftests have reproducers for them. This has been possible since v4.1. It is also why "put_mnt_ns(): leave mounts connected" was reverted in -rc5. Keeping every mount of a dying mount namespace connected made these cycles trivial to create. Every unmounted mount is now detached from its parent. Where the mountpoint has to stay covered the mount leaves a cover on the parent instead, allocated together with the mount. A lookup on the unmounted parent that hits a cover finds an empty immutable directory or file on the private nullfs instance. Nothing leads from a cover to another mount, so no unmounted mount owns another one and no cycle can form. This is visible to userspace. A formerly connected mount can no longer be reached through its unmounted parent and ".." inside it leads nowhere, as for every other lazily unmounted mount. With that the private nullfs instance becomes reachable from userspace, so it now refuses mounts on top, is mounted read-only, and refuses fsnotify marks and file locks. Its inodes are shared by every holder and a watch or a lock would otherwise reach across users. may_decode_fh() now also decides its subtree check under a single mount_lock hold, as a racing umount could otherwise let it decode into what a locked child covered. - umount: * Don't silently unmount busy mounts. Since v4.13 propagate_umount() takes down propagated copies of the victim with children as long as each child is an overmount or another copy of the victim, but propagate_mount_busy() only ever checked copies without children or with just an overmount. A container that moved a tree beneath its copy of a host mount lost that tree from under its open file descriptor to a plain umount() on the host. propagate_mount_busy() now applies the same rules, walking each chain of copies once. * Don't let a migrating task hide its reference from umount(). mnt_get_count() sums the per-cpu counters under mount_lock but the mntget() and mntput() fast paths don't take it. A task that takes a reference on a cpu the sum has already passed and drops it after migrating to one the sum hasn't reached yet hides the reference it held to begin with, and umount() succeeds with the file still open. Gets and puts now live in separate per-cpu counters and all puts are summed before all gets with a full barrier in between, the way srcu_readers_active_idx_check() does it. mntget() is unchanged and mntput() gains an smp_wmb(). * Check each submount for references right before unmounting it. shrink_submounts() and mark_mounts_for_expiry() checked all their victims up front. Unmounting the first could move a busy overmount to where the next victim's propagated copy is looked up and it was then unmounted without a check. * Never expire a locked mount. A shrinkable mount moved beneath a locked mount with MOVE_MOUNT_BENEATH takes over the lock, and umount() of an unlocked ancestor expired it and revealed what it covered. That umount() now fails with EBUSY as it does for any other locked child. A lazy umount still takes the whole tree. - Overmounts and locked mounts: * Unhash a dentry before detaching the mounts on it. unlink(), rmdir() and rename() detach the mounts on the victim but only d_delete() it once its inode is unlocked, a window that includes an expedited RCU grace period. In between, a lookup from a mount namespace in which the dentry is a mountpoint found it hashed, positive and uncovered. Drop the dentry first, as d_invalidate() already does. * Don't reveal overmounted entries in refwalk. A refwalk that had grabbed the dentry before the unlink never rechecked it the way rcuwalk does with d_seq and mount_lock. Without any artificial widening three walkers read the covered file 27 times in a minute. step_into() now fails an unhashed dentry marked DCACHE_CANT_MOUNT with -ESTALE and the walk is retried. * Keep covered mounts covered in OPEN_TREE_NAMESPACE. Creating such a mount namespace only takes a user namespace and the copy followed bind mount rules: no children without AT_RECURSIVE and no unbindable mounts with it. An unprivileged user could see what mounts covered in the source, such as the parts of /proc and /sys that container runtimes mask. If the caller doesn't own the source mount namespace a non-recursive copy of a mount with something mounted below the requested directory is now refused and a recursive copy includes unbindable mounts, the way unshare() copies. * Keep the lock on a mount that a propagated copy is moved beneath. MNT_LOCKED moved to any mount that ended up beneath a locked mount, propagated copies included. A host mount and umount on a directory covered by a locked mount in a less privileged mount namespace left that cover unlocked for the namespace's owner to remove. Only mounts the caller places beneath take over the lock now. * Handle mount locking for automounts correctly. Which copies to lock was decided by the mount namespace of the task that triggered the automount. A task in a user namespace that triggered one on a host mount through a file descriptor got the host's own automount locked while its own copy stayed unlocked and could have nosuid, nodev and noexec cleared. Use the owner of the mount namespace the mount lands in. - Use-after-free and crashes: * Refuse an automount below a mount that is in no namespace. The private clones overlayfs uses for its layers have the MNT_NS_INTERNAL error pointer as their namespace, which finish_automount() let through and count_mounts() dereferenced. A fanotify filesystem mark on an overlayfs lower layer hands out file descriptors on such a clone. With debugfs as the lower layer opening "tracing" oopses with namespace_sem held for writing and every mount operation on the system blocks from then on. * Reset the old parent's ->overmount in mnt_change_mountpoint(). When propagate_umount() moved an overmount off a mount that a file descriptor kept alive, MOVE_MOUNT_BENEATH through that descriptor later followed the stale pointer into the freed overmount. * statmount() with STATMOUNT_BY_FD and pivot_root() read the parent of a mount that may be unmounted and only held by a file descriptor, while the parent's final mntput() can free it. statmount() now reads it under mount_lock and pivot_root() first checks that both mounts are in the caller's mount namespace. * Queue a mount only once for mount notifications. A mount reparented by one umount_tree() and taken down by the next under the same namespace_sem hold, as in shrink_submounts(), was queued twice. That cut the mounts queued in between out of notify_list while it still pointed at them, and once they were freed every later mount operation walked freed memory. * Don't let a pseudo dentry become the root of a mount. A bind mount of a bpf token file did that with a DCACHE_NORCU dentry, which is freed without an RCU grace period while lockless path walks may still look at it. Refuse to clone such a mount. * Don't inherit MNT_UMOUNT in clone_mnt(). A bind mount of a lazily unmounted nsfs or pidfs mount through its file descriptor started out flagged as unmounted. Among other things __detach_mounts() then dropped the namespace's reference on it, the mount outlived its namespace and mount_setattr() through the descriptor read the freed namespace. A recursive bind mount of such a mount also copied the unmounted stack still attached to it. That now fails with EINVAL, copying the mount itself still works. * Remove the fsnotify marks of a mount namespace in free_mnt_ns() instead of the RCU callback that frees the namespace, where taking the group mutexes meant sleeping in softirq context. - Propagation and copies: * Keep a copied mount unbindable. Since v6.17 clone_mnt() didn't copy the unbindable flag, so every mount namespace created with CLONE_NEWNS had bindable copies of all unbindable mounts. This had been fixed once before. * Refuse MOVE_MOUNT_SET_GROUP on an unbindable mount. It made the mount an unbindable slave, a state nothing else can produce, or silently dropped the unbindable flag. CRIU applies MS_UNBINDABLE after restoring sharing and isn't affected. * Check a recursive bind mount for mount namespace loops. Recursively bind mounting a tree from another mount namespace could put a mount of a namespace's file inside that same namespace, which then pins itself and all its mounts. Repeating it leaks without limit, the reproducer took Shmem from 380 kB to 65916 kB. The copy is now checked with check_for_nsfs_mounts() before it is grafted, as move_mount() does. * Look at the topmost mount for a mount namespace file. attach_recursive_mnt() never looked at the topmost mount of the source's chain of overmounts. If that was the chain's only mount namespace file an existing mount at a propagated destination got buried below the root of the nsfs file where no path walk reaches it. * Don't put a mountpoint on a dentry that's being removed. attach_recursive_mnt() makes a mountpoint of the source's root without its inode lock, so a racing rmdir() of that directory could leave a mount on it that nothing ever detaches. d_set_mounted() now checks cant_mount() as well. - nullfs: * Take no inode lock for readdir of an immutable directory. The root of every empty mount namespace is the same nullfs directory and iterate_dir() held its i_rwsem across ->iterate_shared(). A reader whose buffer faults on a FUSE mount of its own holds it for as long as its server wants, and with an exclusive locker queued behind it every lookup that misses the dcache, every create and every mount in that directory waits. One user of an empty mount namespace stalls all others. Directories with the new FOP_IMMUTABLE flag skip the lock. * Refuse to reconfigure internal superblocks through fspick(), MS_REMOUNT or the read-only remount that a synchronous umount() of the root does. For nullfs only root in the initial user namespace could do it, but the superblock is shared by every mount namespace and the flags showed up in statfs() for all of them. * Don't update the access time on nullfs and refuse F_SET_RW_HINT on an immutable inode. - unshare: Free an nsproxy that was never installed with nsproxy_free() when set_cred_ucounts() fails. put_nsproxy() dropped active references that were never taken, which triggered a warning and hid the caller's own namespaces from listns(). - Smaller changes: mount_setattr() checks the target before it walks the tree to allocate peer group ids, unshare() puts the old fs_struct before the old namespaces, dissolve_on_fput() drops the file's reference to the tree itself, disconnect_mount() is simplified and the documentation of the propagated unmount rule is brought up to date" * tag 'vfs-7.3-rc7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (58 commits) namespace: simplify disconnect_mount() selftests/filesystems: test covered mounts namespace: rework connected mounts nullfs: add an empty immutable regular file selftests/filesystems: check that reading the root of an empty mount namespace stalls nobody selftests/filesystems: add a helper that holds a readdir in a page fault readdir: take no inode lock on an immutable directory nullfs: refuse file locks fsnotify: let a filesystem refuse marks on its objects namespace: nothing is mounted on or written through knullfs namespace: keep the private nullfs instance in knullfs fhandle: decide the subtree check under mount_lock selftests/filesystems: check that an automount below an overlay layer is refused selftests/filesystems: check the atime of the empty mount namespace root selftests/filesystems: check that a lock lands on the right mount and stays namespace: keep the lock on a mount that a propagated copy is moved beneath namespace: never expire a locked mount nullfs: don't update the access time namespace: handle mount locking for automounts correctly namespace: refuse an automount below a mount that is in no namespace ... commit 9515f634dbed2bb8928fbb3b01102dd4e64f4aeb Merge: af32da41b0327b a9cd14bfb0c113 Author: Linus Torvalds Date: Fri Oct 9 23:32:55 2026 +0200 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "It finally seems to have calmed down on the arm64 fixes front, so please pull these two straightforward fixes for -rc7. One fixes the EL2 trap configuration for implementation-defined CPU PMU hardware during boot and the other fixes a kcov selftest failure by excluding our softirq early entry code: - Fix PMU EL2 trap configuration for CPUs with an IMPDEF PMU - Fix kcov boot selftest failure by excluding our early IRQ entry code" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: irq: exclude the softirq stack switch from KCOV arm64/boot: Don't set PMUv3p9 FGT2 bits without PMUv3 commit 41363c27b8509bd4efcba244803edac9ba25d1b5 Author: Bihaan Sen Date: Fri Sep 25 17:14:38 2026 +0530 Input: xpad - add support for 8BitDo Pro 2 Wired Controller for Xbox 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 commit f9282b8aa85a8c97c50d656db75feb6d76fc7cbe Author: Krzysztof Furman Date: Fri Oct 9 15:47:10 2026 +0100 Input: xpad - add support for Corsair Novablade Pro 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 commit f321cc430c49b6c1be0d53f2ef19d8342d8029cc Author: Haotian Zhang Date: Fri Oct 9 10:48:25 2026 -0700 Input: ati_remote2 - fix type confusion in device attribute handlers 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 commit 7b817748bf083ad715a8d70de63f2184178cc372 Author: Eric Biggers Date: Fri Oct 9 14:53:54 2026 +0200 lib/crypto: tests: Add Poly1305 split-update carry regression test Add a test case which reproduces the bug fixed by commit 24f07e8c07a0 ("lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON state"). It is written in a fairly general way, such that it should also be able to reproduce similar bugs in other implementations. Update the comment on test_poly1305_allones_keys_and_message() to more accurately describe what it does and differentiate it from the new test. Reviewed-by: Jason A. Donenfeld Link: https://patch.msgid.link/20261009125354.315476-3-ebiggers@kernel.org Signed-off-by: Eric Biggers commit 24f07e8c07a0c0dd275331cbb41c79a78741eef9 Author: Jérémy Jean Date: Fri Oct 9 14:53:53 2026 +0200 lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON state When poly1305_blocks_neon() resumes from a base 2^26 accumulator and the next update contains an odd number of full 16-byte blocks, it processes one leading block through poly1305_mult() so that the remaining NEON work has an even block count. That requires converting the accumulator to the base 2^64 form used by poly1305_mult(). The final ADC of that conversion stores the carry into d2, but the following accumulation and poly1305_mult() use h2. If the conversion carries across bit 128, the carry is dropped and the emitted tag is wrong. This was introduced by Cryptogams commit 03dc4adf91c8 ("arm/poly1305-armv*.pl: optimize branches."), which removed the reduction that consumed d2 shortly before Linux imported the code. OpenSSL's copy did not take that change. The carry is possible because the NEON code stores the accumulator [h0, h1, h2, h3, h4] in a lazily reduced, redundant base 2^26 form: its final carry chain leaves h0, h2, h3 < 2^26, but h1 and h4 may slightly exceed 2^26 - 1. For example, the reachable state h0 = 4 h1 = 2^26 h2 = 2^26 - 1 h3 = 2^26 - 1 h4 = 2^24 - 1 represents 4 + 2^26*2^26 + (2^26-1)*2^52 + (2^26-1)*2^78 + (2^24-1)*2^104 = 2^128 + 4, despite the bit representing the 2^128 term (bit 24 of h4) not being set; the extra comes from the h1 limb being above the normal base 2^26 range. When this value is converted into the non-redundant base 2^64 form, a carry into the new 2^128 bit (in bit 0 of h2) is necessary to preserve the value. Given the above bounds, a carry into bit 128 happens exactly when h1 >= 2^26, h2 = h3 = 2^26 - 1, and h4 mod 2^24 = 2^24 - 1. Store the carry into h2, matching the other base 2^26 to base 2^64 conversions in poly1305_blocks() and poly1305_emit(). This bug causes an incorrect tag to be emitted. However, this is unlikely to happen in practice where Poly1305 is used with a random key, since the random key tends to distribute the accumulator values throughout their valid range. There isn't an obvious way for an attacker without knowledge of the r_key to cause [h0, h1, h2, h3, h4] to land on the precise values where this bug occurs. [EB: Rewrote the commit message to more clearly describe the bug and its impact, and simplified explanation about why there's a carry bit.] Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Jason A. Donenfeld Signed-off-by: Jérémy Jean Link: https://patch.msgid.link/20261009125354.315476-2-ebiggers@kernel.org Signed-off-by: Eric Biggers commit da619121a5d271e78ec709a1f9a3c5f99b9e10ad Author: Eric Biggers Date: Tue Oct 6 10:34:32 2026 +0200 lib/crypto: poly1305: Use memzero_explicit() in poly1305_final() Use memzero_explicit() instead of a plain struct assignment to guarantee zeroization of the 'struct poly1305_desc_ctx'. Note that dead store elimination was only theoretically possible with link-time optimization here. But it's still worth fixing. Fixes: a1d93064094c ("crypto: poly1305 - expose init/update/final library interface") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/bug/linux-c3a6bd76-f6ab-4203-892a-cd06f7aa0c34 Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20261006083432.16328-1-ebiggers@kernel.org Signed-off-by: Eric Biggers commit bb44efdb084a0fd600b64f2aaed5d932caa0c944 Merge: a90ee4305c4a5d b3e6212dea2e43 Author: Paolo Bonzini Date: Fri Oct 9 17:49:26 2026 +0200 Merge tag 'kvm-x86-fixes-7.3-rc6' of https://github.com/kvm-x86/linux into HEAD KVM x86 fixed for 7.3-rcN - If creating a vCPU ultimately fails, clear its entry in the AVIC Physical ID table used by hardware to perform IPI Virtualization and delivered posted IRQs. I.e. plug the same use-after-free hole related to IPI virtualization and posted IRQs that was fixed for APICv by commit b41f2ca6c0601 ("KVM: VMX: Fix stale PID-pointer table entry left after vCPU free"). - Use set_page_dirty_lock() instead of set_page_dirty() when marking a page dirty after writing back SNP firmware's desired CPUID state to userspace. Using set_page_dirty() is unsafe if the page/folio isn't locked (as pointed out by its function comment's big DANGER warning, which no one reads given the number of bugs of this exact nature). - When checking for an MMIO generation match, use the memslots for the current vCPU context (non-SMM vs. SMM), as a misbehaving guest can coerce KVM into incorrectly identifying a write as MMIO in order to bypass KVM's write-tracking. commit fddcf4c5321b3ea5f72166c3fd36a9d1c34f80c7 Author: Cen Zhang (Microsoft Security FORGE Labs) Date: Thu Oct 8 15:16:02 2026 -0400 io_uring/cancel: don't spin on local work the task can't run io_uring_cancel_generic() refuses to sleep while any ring on the exiting task's tctx has local work pending. It assumes the task is that ring's submitter and that the next io_uring_try_cancel_requests() pass will run the work. This does not hold for a ring that was still IORING_SETUP_R_DISABLED when the task got its tctx node from io_uring_create() or io_ringfd_register(). The submitter is set later by IORING_REGISTER_ENABLE_RINGS, possibly from another task, and only the submitter may run local work on an IORING_SETUP_DEFER_TASKRUN ring. To the exiting task the work stays pending forever, the loop never reaches schedule(), and the task trips the WARN_ON_ONCE() once and then spins in do_exit(). An unprivileged user can set this up at will by creating a disabled ring, having a child enable it and stop, posting to the ring with IORING_OP_MSG_RING and exiting with a request in flight that only the child can complete. The exiting thread burns a CPU until the child runs or dies, and with panic_on_warn set the WARN panics the kernel. Fix by skipping the sleep only when io_allowed_defer_tw_run() allows the task to run the work. This is reasonable since work it cannot run cannot complete any of its requests either, so nothing is lost by sleeping. Drop the WARN_ON_ONCE() since handing a disabled ring to another thread is a supported scenario, not a bug state. Fixes: 360cd42c4e95 ("io_uring: optimise io_req_local_work_add") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) Link: https://patch.msgid.link/20261008191602.45101-1-cenzhang@linux.microsoft.com Signed-off-by: Jens Axboe commit aa5d5f8e502318e783545ba5d04bb40130b83e20 Author: Natasha Klaus Date: Fri Oct 9 16:38:07 2026 +0300 io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6 io_connect_bpf_populate() fills connect.port and connect.v6_addr for AF_INET6 only when addr_len >= sizeof(struct sockaddr_in6), i.e. 28 bytes. The IPv6 connect paths accept SIN6_LEN_RFC2133 (24 bytes), which already holds sin6_port and sin6_addr. io_connect() passes addr_len to the socket layer unchanged. At addr_len 24 the filter sees family AF_INET6 with port and address zero, while the kernel connects to the real destination. A filter that denies an IPv6 port or address is bypassed. Denying connect.port == P rejects [::1]:P with -EACCES at addr_len 28 but connects at addr_len 24. Use SIN6_LEN_RFC2133 as the threshold. sin6_scope_id stays zero when absent. The threshold mismatch was found by an AI coding assistant (Claude Code) comparing this hook against the net/ipv6 length checks on my instructions; it also drafted the reproducer and this patch. I verified the bypass and the fix in a VM on 7.3-rc6 and that 7.2 has the same code. Fixes: 899bea8248ce ("io_uring/net: allow filtering on IORING_OP_CONNECT") Cc: stable@vger.kernel.org # 7.2 Signed-off-by: Natasha Klaus Link: https://patch.msgid.link/20261009133807.730724-1-natalie.klaus@runtimeverification.com Signed-off-by: Jens Axboe commit 6da8f402e362b2f546e2efb7167fc9597aef6faf Author: Eugene Gvozdetsky Date: Fri Oct 9 01:08:49 2026 +0200 io_uring/register: don't exempt disabled rings from task restrictions A ring created with IORING_SETUP_R_DISABLED is exempt from its register restrictions until it is enabled. This lets the creator register the restrictions and then enable the ring with IORING_REGISTER_ENABLE_RINGS, whether or not that opcode is in the allowed set. Since commit ed82f35b926b ("io_uring: allow registration of per-task restrictions"), a ring also inherits restrictions from the task that creates it, and the same exemption applies to those. A task whose register opcodes are restricted can therefore create a disabled ring, issue any register opcode on it, and then enable it. Mark rings whose restrictions were inherited from the task, and keep checking register opcodes for them while the ring is disabled. Enabling such a ring now requires IORING_REGISTER_ENABLE_RINGS to be in the task's allowed set. Per-ring restrictions registered on a disabled ring work as before. Fixes: ed82f35b926b ("io_uring: allow registration of per-task restrictions") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Eugene Gvozdetsky Link: https://patch.msgid.link/20261009-iouring-task-restrict-fix-v1-1-a49daf55a12c@gmail.com [axboe: amend with inheritance flag fixup] Signed-off-by: Jens Axboe commit cde56daf4b93f474dc256dbcc5205035223ae6f5 Author: Jens Axboe Date: Thu Oct 8 13:07:38 2026 -0600 io_uring/kbuf: don't charge provided buffer rings to RLIMIT_MEMLOCK Just like with the SQ and CQ rings, the provided buffer rings were also not charged against the memlock limit prior to the below mentioned commit. Restore that behavior. Fixes: ef62de3c4ad5 ("io_uring/kbuf: use region api for pbuf rings") Reported-by: Hengyu Liang Cc: stable@vger.kernel.org Tested-by: Hengyu Liang Signed-off-by: Jens Axboe commit af32da41b0327b9c6a37856ba82b6760d6c8d10e Merge: 6c377d19d4a511 37f12441f55746 Author: Linus Torvalds Date: Fri Oct 9 06:40:28 2026 +0200 Merge tag 'net-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from wireless, wireguard, CAN and Bluetooth. We have one known regression to wrap up in VLAN handling. Current release - regressions: - Bluetooth: RFCOMM: fix deadlock on rfcomm_mutex Previous releases - regressions: - can: fix regression in handling RPS after migrating metadata to skb_ext - eth: - iavf: fix regressions in reconfig impacting bonding - mana: fix packet forwarding performance regression - stmmac: remove buggy VLAN acceleration support Previous releases - always broken: - a few high prio fixes for tun, and af_packet - amt: fix a UaF on tunnel teardown - eth: - bnxt: fix PCIe AER recovery and FLR handling issues - macb: don't modify Tx skbs before taking ownership - axienet: don't leak Tx skbs on interface stop - wifi: - nxpwifi: number of LLM-ish fixes - assorted mt76 fixes" * tag 'net-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (128 commits) net: macb: copy shared skbs before appending the FCS net: macb: check TX ring before modifying skb vsock: Fix memory leak in vmci_transport_recv_dgram_cb() wireguard: noise: reject response consumption after intermediate initiation wireguard: queueing: preserve tstamp_type when encapsulating packet net: openvswitch: validate transport header presence in set_ipv6_addr net/smc: protect clcsock lifetime in smc_getname ipv6: do not warn on route notification size race ipv4: do not warn on route notification size race ipv4: validate checksum_start before completing checksum ptp: ocp: fix PCIe delay estimation calculation xen/netfront: don't leak the skb when xennet_fill_frags() fails net/packet: call packet_parse_headers after virtio_net_hdr_to_skb xen/netfront: drop RX packets with a short Ethernet header net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits() net: sparx5: free the matchall entry on destroy selftests: mlxsw: Test port range occupancy on template create mlxsw: spectrum_flower: Fix port range register leak in tmplt_create() net: dsa: microchip: fix KSZ8765 fiber detection net/mlx5e: Order ICOSQ cc update after CQ doorbell ... commit 6ccf996a0dec1852dab94ad865f27b4904750e12 Author: Mary Guillemard Date: Wed Oct 7 16:30:15 2026 +0200 drm/nouveau: Skip the Turing CE workaround object for non-GR channels This workaround is here for the old Gallium driver and predate async CE and NVDEC. Instead of only skipping it for NVDEC, let's only apply it in case of GR channels. This should make async CE work properly on Turing by stopping the assign of a GRCE. (here CE0) Signed-off-by: Mary Guillemard Reviewed-by: Lyude Paul Reviewed-by: Daniel Almeida Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20261007-turing-async-ce-fix-v1-1-12ee6ccd1a3c@mary.zone commit 79c168e2aa957ed0054c93db17caba653b95e377 Author: Lukas Wunner Date: Thu Oct 8 14:26:00 2026 +0200 PCI/AER: Skip error recovery on false alarms Alex is seeing a probe failure of the amdgpu driver after the Root Port above an AMD Navi10 GPU has been reset. The reset was performed to recover from a Firmware First reported Fatal Error. However all status registers in the Root Port's AER Extended Capability are blank, so apparently the platform firmware raised a false alarm. The issue is only occurring since commit eddba19b8b5f ("PCI/AER: Support Advisory Non-Fatal Errors"). It looks like enabling Advisory Non-Fatal Errors causes code paths to be exercised in platform firmware which were never validated before. Skip error recovery on false alarms, i.e. if no unmasked errors were actually signaled. Note that this will also skip recovery if both the Status and Mask registers are "all ones", as would be the case for inaccessible devices. However that seems justified because it would imply either a hot-unplug event or a Surprise Down Error further up in the hierarchy. Interfering with recovery from that seems uncalled for. Fixes: eddba19b8b5f ("PCI/AER: Support Advisory Non-Fatal Errors") Reported-by: Alex Deucher Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222095 Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Tested-by: Alex Deucher Acked-by: Alex Deucher Link: https://patch.msgid.link/0552ed277e40a288e0157af799257ee6ec722534.1791460615.git.lukas@wunner.de commit cca01232d94adcb10f7c8c5bb8ce072b045fcb58 Author: Maíra Canal Date: Wed Sep 30 15:20:44 2026 -0300 drm/vc4: Fix binner slot allocation failing on an idle GPU 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 commit 6abc8e4dcfbc1d26a94c0ac037dfb3716f686b1f Author: Maíra Canal Date: Fri Sep 25 16:10:19 2026 -0300 drm/vc4: Disable the V3D interrupt across runtime suspend vc4_irq_disable() masks the V3D interrupt sources and then calls synchronize_irq() before the V3D is powered down. However, by itself, this is not enough to quiesce the interrupt handler. synchronize_irq() waits for handlers that have already set IRQD_IRQ_INPROGRESS, and for irqchips reporting IRQCHIP_STATE_ACTIVE. A GIC interrupt chip is able to mark an interrupt active as soon as a CPU acknowledges it, so there these checks cover the whole dispatch path. On RPi 0-3, however, the interrupt controller is ARMCTRL, which has no active state. A CPU that has read the hwirq out of the pending register but has not yet reached handle_level_irq() stays invisible to synchronize_irq(). During a power transition, vc4_irq() may therefore run after the power domain is off, where every V3D register read will return 0xdeadbeef. 0xdeadbeef has FLDONE, FRDONE and OUTOMEM set. This problem doesn't trigger NULL pointer dereference issues only because the functions vc4_irq_finish_bin_job() and vc4_irq_finish_render_job() return early when there is no job pointer, but OUTOMEM is still able to schedule vc4_overflow_mem_work() after vc4_irq_disable() has already cancelled it. Therefore, fix the spurious interrupts by disabling the interrupt line across the PM transition. To preserve the enable/disable balance, move vc4_irq_install() and request the IRQ line disabled before the first runtime resume. Fixes: 9b6f461582e6 ("drm/vc4: v3d: Stop disabling interrupts") Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260925191318.541938-1-mcanal@igalia.com Signed-off-by: Maíra Canal commit b59cabf9b4acb65f3f9968087ca0e18010d85076 Author: Hengyu Liang Date: Tue Oct 6 08:57:32 2026 -0400 io_uring: do not charge the SQ/CQ rings to RLIMIT_MEMLOCK Commit 8078486e1d53 ("io_uring: use region api for SQ") and commit 81a4058e0cd0 ("io_uring: use region api for CQ") made io_uring_setup() allocate the rings with io_create_region(). However, io_create_region() charges the memory to RLIMIT_MEMLOCK, and the rings had been exempt from that limit since commit 26bfa89e25f4 ("io_uring: place ring SQ/CQ arrays under memcg memory limits"). As of now, a user without CAP_IPC_LOCK gets ENOMEM from io_uring_setup() when their rings exceed the limit, which is 8 MiB by default. PostgreSQL developers have already hit this in their io_uring tests [1]. The issue can be reproduced with a simple liburing program, run as an unprivileged user: #include #include int main(void) { static struct io_uring ring[64]; int i; for (i = 0; i < 64; i++) if (io_uring_queue_init(4096, &ring[i], 0) < 0) break; printf("%d rings\n", i); return 0; } Before those commits (v6.13), it prints "64 rings". After those commits (v6.14), it prints "21 rings". This patch makes io_create_region() take the user to charge, and passes no user for the SQ/CQ rings. Link: https://www.postgresql.org/message-id/flat/667f7dcf-404b-4898-a426-57ca6e0617f6@gmail.com [1] Fixes: 8078486e1d53 ("io_uring: use region api for SQ") Fixes: 81a4058e0cd0 ("io_uring: use region api for CQ") Cc: stable@vger.kernel.org Signed-off-by: Hengyu Liang Link: https://lore.kernel.org/io-uring/20261006125732.3425762-1-hengyul@cs.unc.edu/ Signed-off-by: Jens Axboe commit 37f12441f557468a56c1e27790413aa78c82afa2 Merge: 7c24a4e87e2190 9151d6c4279910 Author: Jakub Kicinski Date: Thu Oct 8 11:48:53 2026 -0700 Merge branch 'net-macb-fix-software-fcs-handling-of-shared-and-requeued-skbs' Nicolai Buchwitz says: ==================== net: macb: fix software FCS handling of shared and requeued skbs While testing the genet MTU series I used a Raspberry Pi CM5 (RP1 GEM) as pktgen source for the CM4. With clone_skb the CM5 rebooted after a few seconds. Further investigation showed that macb_pad_and_fcs() appends the FCS in place, so the shared skb grows with every transmit until BQL completes more than was queued and dql_completed() hits its BUG_ON. The same code also modifies the skb before the TX ring check, so a NETDEV_TX_BUSY retry gets an skb that was already replaced or grown. Patch 1 checks the ring first, patch 2 copies shared skbs. Tested on Raspberry CM5 with pktgen at 60/20000 bytes, clone_skb 0/ 1000, burst 1/32. ==================== Link: https://patch.msgid.link/20261006-nb-macb-shared-skb-net-v1-0-a80641479041@tipi-net.de Signed-off-by: Jakub Kicinski commit 9151d6c42799105e109c8b54dbaad91ce0e17c47 Author: Nicolai Buchwitz Date: Tue Oct 6 07:41:33 2026 +0200 net: macb: copy shared skbs before appending the FCS macb_pad_and_fcs() appends the FCS in place when the skb has tailroom. A shared skb, as pktgen sends in clone_skb mode, grows by one FCS per transmit. BQL then completes more bytes than were queued and dql_completed() hits its BUG_ON. On a Raspberry Pi CM5 (RP1 GEM) pktgen with clone_skb 1000 burst 32 at 60 bytes kills the box within seconds. Copy shared skbs before appending the FCS. Clearing IFF_TX_SKB_SHARING would also fix it but makes pktgen refuse clone_skb on macb. Fixes: 653e92a9175e ("net: macb: add support for padding and fcs computation") Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20261006-nb-macb-shared-skb-net-v1-2-a80641479041@tipi-net.de Signed-off-by: Jakub Kicinski commit 6b48ed85ae0ca37c7403ef5d512be75975844f2f Author: Nicolai Buchwitz Date: Tue Oct 6 07:41:32 2026 +0200 net: macb: check TX ring before modifying skb macb_pad_and_fcs() replaces or extends the skb before the ring space check. On NETDEV_TX_BUSY the stack requeues an skb that is already freed or grown. Check the ring first, using the padded length for the descriptor count. Nonlinear skbs always take the copy path so the count can assume a linear skb. Fixes: 653e92a9175e ("net: macb: add support for padding and fcs computation") Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20261006-nb-macb-shared-skb-net-v1-1-a80641479041@tipi-net.de Signed-off-by: Jakub Kicinski commit 7c24a4e87e219072e5e106f6791146cbf3b056b3 Author: Ilia Gavrilov Date: Thu Oct 8 14:41:17 2026 +0000 vsock: Fix memory leak in vmci_transport_recv_dgram_cb() 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 commit fe4167bf53b61405f97614f644f6a63a5d6ad034 Merge: 3c6a4b11330fe4 d0305f8d900295 Author: Jakub Kicinski Date: Thu Oct 8 11:43:39 2026 -0700 Merge branch 'wireguard-fixes-for-7-3-rc7' Jason A. Donenfeld says: ==================== WireGuard fixes for 7.3-rc7 This series contains two important WireGuard fixes 1) Stop zeroing out skb->tstamp_type when encapsulating packets, so that fq behaves correctly, from Ramses de Norre. 2) Make sure handshake state isn't swapped out while locks are released, reported by Jérémy Jean. ==================== Link: https://patch.msgid.link/20261008130124.724119-1-Jason@zx2c4.com Signed-off-by: Jakub Kicinski commit d0305f8d90029556260c6824b61c493c424eba9e Author: Jason A. Donenfeld Date: Thu Oct 8 14:59:16 2026 +0200 wireguard: noise: reject response consumption after intermediate initiation 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 commit 65ab9de4bdd4c05d8277cfc20ae0b9f5aff60897 Author: Ramses de Norre Date: Thu Oct 8 14:59:15 2026 +0200 wireguard: queueing: preserve tstamp_type when encapsulating packet 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 commit 3c6a4b11330fe424557538a98fca9f0a4c5bf313 Author: Fernando Fernandez Mancera Date: Thu Oct 8 12:41:35 2026 +0200 net: openvswitch: validate transport header presence in set_ipv6_addr 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 commit 64a6b36b0e1855288080bc5f89769f27d6dc03c8 Author: Chengfeng Ye Date: Thu Oct 8 16:44:44 2026 +0800 net/smc: protect clcsock lifetime in smc_getname 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 commit d5788029c34fa7f27ab23f88a4f878e8913042a9 Merge: 6785011f8b16ab c97426ec649d99 Author: Jakub Kicinski Date: Thu Oct 8 11:32:39 2026 -0700 Merge branch 'ipv4-ipv6-do-not-warn-on-route-notification-size-races' Daehyeon Ko says: ==================== ipv4/ipv6: do not warn on route notification size races A nexthop group can grow between route notification sizing and filling. Both IPv4 and IPv6 can then legitimately return -EMSGSIZE, so remove the stale warnings while preserving their existing error paths. Patch 1 is unchanged from v1. Patch 2 adds the IPv6 counterpart requested by Ido. No new build or runtime test was run; both changes only delete the stale comment and WARN_ON(). ==================== Link: https://patch.msgid.link/cover.1791423190.git.4ncienth@gmail.com Signed-off-by: Jakub Kicinski commit c97426ec649d99596d8969e1a052c16b14b7b485 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Thu Oct 8 14:29:23 2026 +0900 ipv6: do not warn on route notification size race 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 commit e02a5b6588161673ef75a4bc5cdfb62bd493374d 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 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 commit 6785011f8b16abf40b1e9d8b2e332232b3e68822 Author: Michael S. Tsirkin Date: Wed Oct 7 18:42:49 2026 -0400 ipv4: validate checksum_start before completing checksum 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 commit f8c8bd159a9bf626dd4921b7746ff481fce8c758 Author: Vadim Fedorenko Date: Wed Oct 7 20:33:59 2026 +0000 ptp: ocp: fix PCIe delay estimation calculation 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 commit 93ccaf1c26e2133396173b76a071e59024daa622 Author: Josef Bacik Date: Wed Oct 7 17:57:32 2026 +0000 xen/netfront: don't leak the skb when xennet_fill_frags() fails 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 commit 513e23857a3a64fa73a1deb36a385eecd4ad7690 Author: Willem de Bruijn Date: Wed Oct 7 13:57:30 2026 -0400 net/packet: call packet_parse_headers after virtio_net_hdr_to_skb SOCK_RAW packet sockets incorrectly drop VLAN-tagged GSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM. packet_parse_headers() sets skb->protocol to VLAN but advances skb->network_header past the VLAN tags. virtio_net_hdr_to_skb() then flow dissects these packets, which parses the network header as a VLAN tag, and fails. Call packet_parse_headers() after virtio_net_hdr_to_skb() instead. This matches tun_get_user() and tap_get_user() and thus simplifies overall complexity. Commit 01fdecc0480d ("net: packet: fix wrong transport_header when sending VLAN-tagged frame") fixed the same issue for the transport header probe in packet_parse_headers(). That probe is now skipped if virtio_net_hdr_to_skb() already set the transport header, avoiding a redundant dissection. Implementation details: - Do not set skb->protocol to the RX wildcard ETH_P_ALL. SOCK_RAW then derives it from the link layer header, as before. SOCK_DGRAM now leaves it 0, or derives it from gso_type for GSO with NEEDS_CSUM. - Keep virtio_net_hdr_set_proto() last, so that the link layer protocol takes priority over gso_type. Reported-by: Junnan Zhang Closes: https://lore.kernel.org/netdev/20260821085722.24036-1-zhangjn_dev@163.com/ Fixes: dfed913e8b55 ("net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO") Signed-off-by: Willem de Bruijn Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20261007175816.3138556-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski commit 089e58805c452e52179482b1025a8e309a57f801 Author: Josef Bacik Date: Wed Oct 7 17:55:40 2026 +0000 xen/netfront: drop RX packets with a short Ethernet header handle_incoming_queue() pulls pull_to bytes into the head before calling eth_type_trans(). pull_to is the length of the first RX slot, capped at RX_COPY_THRESHOLD, and that length comes from the backend. Nothing checks it against ETH_HLEN. If the first slot is shorter than ETH_HLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is shorter than ETH_HLEN, eth_type_trans() reads the header past the end of the data instead. Pull at least ETH_HLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header. This also checks the return value of the pull, which was ignored. Fixes: 0d160211965b ("xen: add virtual network device driver") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261007-b4-xen-netfront-short-head-v1-1-12d7113a7e4e@toxicpanda.com Signed-off-by: Jakub Kicinski commit ab9414ed70bd783e902a85c350620dee269bcb2b 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() 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 commit 2b82e16d6084cbc651e3c902198f1945408ee1a5 Author: Daniel Machon Date: Wed Oct 7 17:03:15 2026 +0200 net: sparx5: free the matchall entry on destroy 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 commit ff6f5157e034f81c2d6482259fc656cd0fe5a8ff Merge: fc13ba44da197a 71198b59df56a9 Author: Jakub Kicinski Date: Thu Oct 8 10:49:26 2026 -0700 Merge branch 'mlxsw-fix-port-range-register-leak' Petr Machata says: ==================== mlxsw: Fix port range register leak When the mlxsw driver parses a port range template rule, it acquires the actual port range registers. The parsing is only done to determine the element usage, so the registers can be deallocated right away, but this is never done, and the registers are leaked. Plug this leak and add a selftest that would have caught it. ==================== Link: https://patch.msgid.link/cover.1791294384.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski commit 71198b59df56a9a0115115091cc1aad2a4e3c74d Author: Petr Machata Date: Tue Oct 6 16:21:29 2026 +0200 selftests: mlxsw: Test port range occupancy on template create Add a test that creates a tc chain template matching on both source and destination port ranges and verifies via devlink-resource occupancy that this does not leak port range registers, neither while the template exists nor after it is deleted. Reviewed-by: Ido Schimmel Signed-off-by: Petr Machata Reviewed-by: Jacob Keller Link: https://patch.msgid.link/e7b37b80adb7ac8b0ef20a22d7654a6656c1c545.1791294384.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski commit 7ea07afb230f1342ab0f9365edd0aae137f425d3 Author: Petr Machata Date: Tue Oct 6 16:21:28 2026 +0200 mlxsw: spectrum_flower: Fix port range register leak in tmplt_create() 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 commit fc13ba44da197a186f2f4d77c5b7d73d0f99f053 Author: Sebastien Royen Date: Wed Oct 7 10:05:57 2026 +0200 net: dsa: microchip: fix KSZ8765 fiber detection 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 commit b056ca4d3742d0769f91137bb1ce3215428398f7 Author: Li RongQing Date: Tue Oct 6 13:58:20 2026 +0300 net/mlx5e: Order ICOSQ cc update after CQ doorbell 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 commit 726be6a0e81ac603b34a5953623bb39c86cf495a Merge: 259c4a519100e9 c017800af5c71e Author: Jakub Kicinski Date: Thu Oct 8 10:43:15 2026 -0700 Merge branch 'veth-fix-peer-netdev_xdp_act_ndo_xmit-after-gro-is-toggled-while-down' Tianyi Gao says: ==================== veth: fix peer NETDEV_XDP_ACT_NDO_XMIT after GRO is toggled while down Toggling GRO on a veth device while it is down leaves its peer's NETDEV_XDP_ACT_NDO_XMIT flag stale once the device comes up. XDP redirects into the peer are then rejected with -EOPNOTSUPP, or, if GRO was turned off, accepted and then dropped with -ENXIO. Patch 1 refreshes the peer's flags in veth_open(). Patch 2 extends veth.sh to check the peer's flag after GRO is toggled while the device is down, in both directions. ==================== Link: https://patch.msgid.link/20261006173241.65945-1-tianyi@cloudflare.com Signed-off-by: Jakub Kicinski commit c017800af5c71ebb2e6209eebf5c60c19850ffe7 Author: Tianyi Gao Date: Tue Oct 6 18:32:37 2026 +0100 selftests: net: veth: test peer ndo-xmit after GRO toggle while down Test that toggling GRO on a veth device while it is down updates the peer's ndo-xmit XDP feature once the device comes up, for both GRO on and GRO off. xdp-features is only visible through netlink, so read it with the ynl CLI, as double_udp_encap.sh does. Skip the checks if the CLI is not found, as in an installed kselftest tree. Signed-off-by: Tianyi Gao Link: https://patch.msgid.link/20261006173241.65945-3-tianyi@cloudflare.com Signed-off-by: Jakub Kicinski commit 3f090039995f609a8e236f37980dee5712dded61 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 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 commit 259c4a519100e9182f264f8009ee212b32774277 Author: Hamza Mahfooz Date: Fri Oct 2 21:36:47 2026 -0400 net: mana: reserve RX buffer headroom to fix forwarding performance Commit 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") started handing out RX buffers with zero headroom so that two buffers fit into one page at the default MTU. The MANA TX path, however, stores the per scatter-gather entry DMA mappings in `struct mana_skb_head` at skb->head, and mana_start_xmit() therefore calls skb_cow_head(skb, MANA_HEADROOM). The port advertises this requirement as ndev->needed_headroom = MANA_HEADROOM. As a result every packet that is received and then forwarded out of a MANA port fails the skb_cow() in ip_forward() and gets reallocated and copied by pskb_expand_head(). This is invisible to a plain RX or TX workload, but it puts a full skb reallocation plus memcpy on the hot path of every single forwarded packet, which is exactly what a router/NVA workload does. Restore the headroom. Note that reserving MANA_HEADROOM (232) is not enough: ip_forward() asks for LL_RESERVED_SPACE(dev), which rounds hard_header_len + needed_headroom up to HH_DATA_MOD and is 256 bytes on ethernet. Use LL_RESERVED_SPACE() directly so the value keeps tracking both constants. Also, since LL_RESERVED_SPACE() tracks MANA_HEADROOM, it grows with MAX_SKB_FRAGS and for MAX_SKB_FRAGS >= 19 it is greater than 256, so we have to account for that by using the headroom the RX queue actually uses (instead of assuming XDP_PACKET_HEADROOM) and turning MANA_XDP_MTU_MAX into MANA_XDP_MTU_MAX(ndev) (note that at the default CONFIG_MAX_SKB_FRAGS=17 they are equivalent). At the default MTU on a 4K page this means a buffer no longer fits twice into a page (SKB_DATA_ALIGN(1500 + MANA_RXBUF_PAD + 256) = 2112), so the frag-vs-single decision is now made by computing the real buffer size instead of comparing the MTU against PAGE_SIZE / 2. The page_pool fragment path is still used wherever at least two buffers genuinely fit, e.g. on 16K and 64K page sizes. Measured on an Azure VM with a MANA NIC acting as a forwarding NVA (UDP, 1400 byte payload, 4 streams, 8 Gbps offered, only the forwarding node's kernel differs), 8 runs each, median: forwarded pps throughput before 272,830 3.06 Gbps after 390,560 4.37 Gbps (+43%) perf on the forwarding node, same workload: memset_orig __pi_memcpy pskb_expand_head before 10.07% 3.96% present after 0.94% 0.64% gone Cc: stable@vger.kernel.org Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") Signed-off-by: Hamza Mahfooz Reviewed-by: Simon Horman Link: https://patch.msgid.link/20261003013647.2051416-1-hamzamahfooz@linux.microsoft.com Signed-off-by: Jakub Kicinski commit 5a768f5f76d8833b02b00f99d246cba6c463760b Merge: 5da1129613f27b 5346b1cec6afa4 Author: Dave Airlie Date: Fri Oct 9 01:55:39 2026 +1000 Merge tag 'drm-intel-fixes-2026-10-08' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes drm/i915 fixes for v7.3-rc7: - Fix a GT park race that could trigger spurious RPM wakelock warnings - Fix execbuffer relocation cleanup to avoid out-of-bounds free Signed-off-by: Dave Airlie From: Jani Nikula Link: https://patch.msgid.link/49ac4a9f496e1dadbf71740eb0d1f443598b2632@intel.com commit 6c377d19d4a5116d9bec5203aa3c6c11523e7898 Merge: 47324d3a5b3abd 3e78d7b063230d Author: Linus Torvalds Date: Thu Oct 8 17:37:49 2026 +0200 Merge tag 'ext4_for_linus-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 Pull ext4 fixes from Ted Ts'o: "Mark the ext4 data=journal feature as being deprecated and will be removed in 2028. Also designate the primary branch that Sashiko and other tools use to find the primary development branch in the ext4 tree" * tag 'ext4_for_linus-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: mark data=journal as deprecated and will be removed in January 2028. MAINTAINERS: name the ext4 dev branch commit 3e78d7b063230d39ffc42e80ee665b6c32a6adeb Author: Theodore Ts'o Date: Thu Sep 24 10:58:12 2026 -0400 ext4: mark data=journal as deprecated and will be removed in January 2028. Signed-off-by: Theodore Ts'o commit 4b1d04693e5ef388d8c6110bc93ee0d0681f9711 Author: Matthias Goergens Date: Wed Sep 23 18:17:49 2026 +0800 MAINTAINERS: name the ext4 dev branch The ext4 T: entry names the repository without a branch, so tools that default to the repository's HEAD select master, which still points at a merge from October 2020 (96485e446260). Development happens on dev, which is also the branch linux-next merges. Name it. The Sashiko review bot, for one, falls back to HEAD this way and has been reviewing ext4 patches against that tree. Its review of an EA inode refcount fix reported a Critical double decrement and an undefined function after applying the patch to that stale baseline; neither holds on dev. Link: https://lore.kernel.org/all/20260916072420.316321F000FF@smtp.kernel.org/ Signed-off-by: Matthias Goergens Acked-by: Jan Kara Link: https://patch.msgid.link/20260923101749.3505886-1-matthias.goergens@gmail.com Signed-off-by: Theodore Ts'o commit 85b3a4d5032df9140867253dfc7611a30be7fdc6 Merge: 1cca81a683da7f 709ba1c547eaf3 Author: Linus Walleij Date: Thu Oct 8 13:38:23 2026 +0200 Merge tag 'pinctrl-qcom-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes Qualcomm pin control fixes for v7.3-rc7 - fix intr_target_width in several qualcomm pinctrl drivers - make direction changes exclusive in pinctrl-spmi-gpio - fix function issues in pinctrl-ipq5018 - add missing OF module alias to pinctrl-ipq5210 - split QUP1 SE2/SE3 into lane-pair functions Signed-off-by: Linus Walleij commit 47324d3a5b3abd781295044d01d92d09f184e872 Merge: 156c9ca041377f 0d6c5794fd6334 Author: Linus Torvalds Date: Thu Oct 8 13:35:07 2026 +0200 Merge tag 'pwrseq-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull power sequencing fixes from Bartosz Golaszewski: - add missing PCI device IDs for Thinkpad T14s gen6 which should have been part of commit a39ac4651e3b ("power: sequencing: pcie-m2: Match WCN6855 and WCN7851 UART BT variants by subdevice ID") in pwrseq-pcie-m2 - fix memory leak in pwrseq-pcie-m2 (leaking the array returned by of_regulator_bulk_get_all()) * tag 'pwrseq-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: pcie-m2: Fix leaking array from of_regulator_bulk_get_all() power: sequencing: pcie-m2: Add Lenovo ThinkPad T14s gen6 WCN7850 subsystem PCI ids commit 156c9ca041377f9ffa5967c7debc5fd0f667d395 Merge: b732c98215831d 7efa1a1953cd6b Author: Linus Torvalds Date: Thu Oct 8 13:33:05 2026 +0200 Merge tag 'gpio-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix runtime PM leak in error path in gpio-xilinx - fix race when arming the IRQ poll worker in gpio-mpsse - fix devres cleanup path on probe error in gpio-exar * tag 'gpio-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: mpsse: fix race when arming the IRQ poll worker gpio: exar: initialize the ID before registering its cleanup gpio: xilinx: fix runtime PM leak on request error path commit b732c98215831db36eff1cbbcd0df2f98b765f4e Merge: 0c2669a9f4a1d6 80ce29104123be Author: Linus Torvalds Date: Thu Oct 8 12:35:20 2026 +0200 Merge tag 'mm-hotfixes-stable-2026-10-07-21-48' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull MM fixes from Andrew Morton: - Update .mailmap entries for Andy Yan and John Garry - Fix read-only MAP_SHARED /dev/zero mappings so they retain shared-file semantics instead of being treated as anonymous memory, also avoiding a CONFIG_DEBUG_VM assertion - Fix 32-bit build warnings in the hugetlb-mmap selftest caused by using the wrong printf format for size_t values - Fix a boot-time crash when early function tracing causes CPA to free kernel page tables before the workqueues used for deferred freeing are available - Fix two MREMAP_DONTUNMAP locked_vm accounting leaks: one caused by an mlock-on-fault VMA self-merging, and one caused by partially remapping a locked VMA * tag 'mm-hotfixes-stable-2026-10-07-21-48' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mailmap: update entry for Andy Yan drivers/char/mem: mmap readonly MAP_SHARED-/dev/zero correctly selftests/mm: cleanup -Wformat issues in hugetlb-mmap mm: don't schedule deferred kernel page table freeing while booting mailmap: update addresses for John Garry mm/mremap: fix locked_vm leak by splitting VMA for MREMAP_DONTUNMAP mm/mremap: fix locked_vm leak from MREMAP_DONTUNMAP self-merge commit 911655ab1dfb9d526978a75df3b210132620d30a Author: Marek Szyprowski Date: Wed Sep 30 10:50:55 2026 +0200 swiotlb: fix default_swiotlb_limit() for non-growable default pool 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 commit f90f8afb61beb268ca8092e7f3a826b520d3e8da Author: Peter Ujfalusi Date: Thu Oct 8 12:01:43 2026 +0300 ASoC: SOF: sof-client: Use event-handler mutex consistently Protect IPC RX and FW state handler list unregister/dispatch paths with client_event_handler_mutex to match list registration and locking comments. Fixes: 5c19da34df02 ("ASoC: SOF: Use guard()/scoped_guard() for mutex locks where it makes sense") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Link: https://patch.msgid.link/20261008090143.15158-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown commit 746de48c3a250f0c264105dcbfcdf0c5001e970b Author: Peter Ujfalusi Date: Thu Oct 8 12:01:30 2026 +0300 ASoC: SOF: ipc4-topology: Fix shift-out-of-bounds for aggregated ALH capture When ch_count is smaller than blob->alh_cfg.device_count (e.g. a mono capture stream, such as a SmartMic, aggregated across multiple SDW links), step = ch_count / blob->alh_cfg.device_count truncates to 0. The subsequent GENMASK(step - 1, 0) then underflows step - 1 (u32) to UINT_MAX, causing GENMASK()'s internal shift to use an out-of-bounds exponent: UBSAN: shift-out-of-bounds in sound/soc/sof/ipc4-topology.c:2363:13 shift exponent 18446744069414584384 is too large for 64-bit type 'long unsigned int' Treat ch_count < device_count the same way as the existing "channels equal to output reference channels" case: apply the same ch_mask to every aggregated device instead of trying to split channels that can't be evenly divided. Fixes: 0390a102cc18 ("ASoC: SOF: ipc4-topology: use different channel mask for each sdw amp feedback") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Link: https://patch.msgid.link/20261008090130.15135-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown commit 789f290b2e81d42820bddcb4010ffbc2ae2ded54 Author: Gyeyoung Baek Date: Thu Oct 1 22:39:13 2026 +0900 drm/imagination: Size page table preallocation by device address 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 commit 196d4d10c1b33ae176685ff42a9994a5952b1d0f Author: Gyeyoung Baek Date: Thu Oct 1 22:39:12 2026 +0900 drm/imagination: Fix reference and vm_bo handling in remap() 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 commit 07c75552f7fe636a0695baae506a7d72fabd3be4 Merge: 13dffca9043500 9ca0d0d0249230 Author: Takashi Iwai Date: Thu Oct 8 10:49:55 2026 +0200 Merge tag 'asoc-fix-v7.3-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v7.3 A fairly small collection of fixes and a few device quirks, nothing especially remarkable unless you have the affected system. commit 00765a3467b992d0eb56704a28887256317eb4bd Author: Jisheng Zhang Date: Thu Oct 8 09:00:58 2026 +0800 spi: dt-bindings: snps,dw-apb-ssi: Add Synaptics sl2610 spi Add the compatible for the Synaptics SL2610 SoC SPI controllers, which are compatible with the Synopsys DesignWare APB SSI. Signed-off-by: Jisheng Zhang Acked-by: Conor Dooley Link: https://patch.msgid.link/20261008010058.28382-1-jszhang@kernel.org Signed-off-by: Mark Brown commit 0c2669a9f4a1d607e7591ae50ccf3c432a0aff08 Merge: 8fc6e594884a65 1fc2d80928b706 Author: Linus Torvalds Date: Thu Oct 8 06:44:07 2026 +0200 Merge tag 'soc-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: - Four distinct issues in TEE firmware, all fairly minor - Five devicetree mistakes on NXP i.MX8, lx2160a and Qualcomm based machines, one of these may cause file system corruption from an incorrect SD card supply voltage - Five fixes for clk drivers on new Qualcomm platforms, addressing issues with incorrect enable states * tag 'soc-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: MAINTAINERS: update my email address tee: optee: ffa: support shared memory offsets on large-page kernels optee: register TEE devices only once fully initialized tee: shm: reject zero-sized allocations in tee_dyn_shm_alloc_helper() arm64: dts: imx8mp-var-dart-sonata: Fix Sonata SD I/O supply arm64: dts: lx2160a: fix the iic5 spi3 pinmux offset and value arm64: dts: lx2160a: fix IIC1 pinmux submask rejected by pinctrl-single arm64: dts: lx2160a: fix incorrect pinmux clk: qcom: gpucc-kaanapali: Mark the GPU CX GDSC as votable clk: qcom: gpucc-glymur: Mark the GPU CX GDSC as votable clk: qcom: gcc-kaanapali: Fix always-enabling PCIE_RSCC clocks clk: qcom: gcc-hawi: Fix always-enabling PCIE_RSCC clocks clk: qcom: gcc-eliza: Fix always-enabling PCIE_RSCC clocks arm64: dts: qcom: x1-denali: Fix microphone distortion tee: qcomtee: fix kernel-doc warnings commit 8fc6e594884a65ec99c78ad05e7fae110ad714d9 Merge: 4cc6bbaeb3afe9 cfb3293c457328 Author: Linus Torvalds Date: Thu Oct 8 06:36:57 2026 +0200 Merge tag 'usb-mtu3.2026.10.06a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu Pull tracing fix from Paul McKenney: "Fix a double-dereference splat in TP_printk in usb mtu3. This was a pre-existing bug that can corrupt tracing output, but which was exposed this cycle by additional checking that was added to the tracing subsystem. This splat is reporting a double-dereference that can result in garbage traces being dumped due to the possibility of the TP_printk() being executed without the benefit of main memory being present. The fix is to move the extra dereference from TP_printk() time to TP_fast_assign() time" * tag 'usb-mtu3.2026.10.06a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu: usb: mtu3: Fix double dereference in TP_printk commit 4cc6bbaeb3afe9166380eccd8d166d2dd75c0278 Merge: 7b63ef2d55f245 26f90559a77cac Author: Linus Torvalds Date: Thu Oct 8 06:30:50 2026 +0200 Merge tag 'urgent.2026.10.01a' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux Pull RCU fix from Paul McKenney: "Fix spurious WARN_ON() for rcu_segcblist_n_cbs() in cleanup_srcu_struct() This issue was introduced by 78a38cbf6f20 ("srcu: Queue sdp->work when the delay timer is successfully deleted") during this merge window. Enough people are hitting this that I am sending it now rather than waiting for the next merge window. Especially given that it is a simple one-liner" * tag 'urgent.2026.10.01a' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux: srcu: Fix WARN_ON() for rcu_segcblist_n_cbs() in cleanup_srcu_struct() commit d4f25b097e46d82718bb737d4540c99b7ab0a408 Author: Karl Mehltretter Date: Mon Sep 7 21:07:50 2026 +0200 riscv: fix load_unaligned_zeropad() fixup for RV32 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 commit 6d25ffca055a77787c21a36b66c253f76239411b Author: Daehyeon Ko <4ncienth@gmail.com> Date: Tue Oct 6 12:51:08 2026 +0900 cipso: adjust cached option offsets when removing CIPSO 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 commit c57b2e60d4bf29707c51b39ed3bacbcce2f3ba2e Author: Haishuang Yan Date: Fri Oct 2 23:30:39 2026 +0800 bareudp: set the inner protocol to the protocol of the packet bareudp_xmit_skb() sets the inner protocol of the skb to the configured ethertype, and bareudp6_xmit_skb() does not set it at all. The inner protocol is used by skb_udp_tunnel_segment() to segment the inner packet when GSO has to be done in software, for instance when the lower device does not offload the checksum. With multiproto, an IPv4 device also carries IPv6, so the IPv6 header is parsed as an IPv4 one. With IPv6 underlay, the inner protocol is whatever the skb had before. In both cases segmentation fails and the packets are dropped. With veth tx checksum offload disabled, iperf3 TCP over bareudp gets about 10 Mbit/s with thousands of retransmits instead of about 700 Mbit/s for IPv6 over IPv4 and for both families over IPv6, while IPv4 over IPv4 works. At this point skb->protocol is the protocol of the inner packet, which bareudp_xmit() has already checked against the configuration, so use it on both paths. Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Fixes: 4b5f67232d95 ("net: Special handling for IP & MPLS.") Signed-off-by: Haishuang Yan Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20261002153039.462663-1-yanhaishuang@cmss.chinamobile.com Signed-off-by: Jakub Kicinski commit 1d6500523b8d5112afe0118173ebc8c1ca23784e Author: Tony Nguyen Date: Thu Oct 1 15:24:39 2026 -0700 e1000e: add system to disable K1 list Javier reports seeing packet loss issues related to the re-enablement of K1; disabling it makes the issues go away. Add the reported system to have K1 disabled by default. Reproduction steps (from the Link): Plug the cable and ping the default gateway on the LAN. No suspend/resume involved, machine freshly booted and on AC power. Nothing e1000e-related in dmesg apart from the link up/down messages; no "Hardware Unit Hang". Default (K1 enabled): $ ping -c 30 192.168.10.1 --- 192.168.10.1 ping statistics --- 30 packets transmitted, 18 received, 40% packet loss, time 29734ms rtt min/avg/max/mdev = 0.211/0.315/0.384/0.046 ms The lost packets are spread over the run (seq 6, 8, 9, 11, 13, 14, 16, 19, 20, 24, 25, 30), not a single burst. DHCP on this link also takes 1-2 minutes to get a lease, consistent with incoming packets being dropped. With K1 disabled at runtime: # ethtool --set-priv-flags enp0s31f6 disable-k1 on $ ethtool --show-priv-flags enp0s31f6 Private flags for enp0s31f6: s0ix-enabled: on disable-k1 : on $ ping -c 30 192.168.10.1 --- 192.168.10.1 ping statistics --- 30 packets transmitted, 30 received, 0% packet loss, time 29713ms rtt min/avg/max/mdev = 0.169/0.251/0.468/0.054 ms $ ping -c 30 192.168.10.1 --- 192.168.10.1 ping statistics --- 30 packets transmitted, 30 received, 0% packet loss, time 29677ms rtt min/avg/max/mdev = 0.101/0.222/0.360/0.064 ms I have only compile tested this, but Javier has tested that disabling K1 on his system (Lenovo ThinkPad P14s Gen 5 (Intel), I219-LM [8086:550a]) resolves his issues. Cc: stable@vger.kernel.org Fixes: 578294b8b60d ("e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor Lake") Reported-by: Javier Herrera Link: https://lore.kernel.org/intel-wired-lan/CAKRuCQLWEcci9hPgNUmvq44Bd2H30T5_vP=exMjsknXMN5Yh9A@mail.gmail.com/ Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20261001222443.3500206-7-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski commit 4d0697f192975dab5985e921989be1d85cf580e9 Author: Ziyi Guo Date: Thu Oct 1 13:57:11 2026 +0000 riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp 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 commit f202578efc738b883cfa04889eb97328914265a7 Author: Eric Dumazet Date: Wed Oct 7 06:56:15 2026 +0200 flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect() 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 commit a51d233ccd4889aadb71dace863525cc2b00271e Author: Eric Dumazet Date: Wed Oct 7 07:17:47 2026 +0200 bnxt_en: fix DMA mapping length for padded small packets 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 commit 7fadfc8dc63fe77b3a2dd1e023915f6fad7efdac Merge: 9b6c20f788472d 2e52da27096d9d Author: Jakub Kicinski Date: Wed Oct 7 17:52:03 2026 -0700 Merge branch 'bnxt_en-pcie-flr-aer-fixes' Michael Chan says: ==================== bnxt_en: PCIe FLR/AER fixes This patchset is split from the earlier 9-patch series to limit the fixes to the PCIe FLR/AER issues only (patches 7 to 9). The other fixes (patches 1 to 6) will be sent to net-next separately. The 1st patch is unchanged since v1. It refactors a bnxt_clear_bars() helper needed by patch 2 and 3. Patch 2 fixes an issue during driver init. in the kdump kernel on a Dell system with a smart PCIe switch upstream from the NIC. Patch 3 fixes an issue in the AER code path for non-fatal errors found by a partner. These patches have been regression tested on Broadcom 5750X and 5760X NICs running 237.x.x.x production FW. ==================== Link: https://patch.msgid.link/20261005204246.3822563-1-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski commit 2e52da27096d9dbc487f303bbc10d44ad837a8c4 Author: Pavan Chebbi Date: Mon Oct 5 13:42:46 2026 -0700 bnxt_en: Re-write the BARs following any type of PCIe errors 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 commit 386f887c8290f0747dd0180e98ec7a82811bc506 Author: Michael Chan Date: Mon Oct 5 13:42:45 2026 -0700 bnxt_en: Fix driver init in kdump kernel 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 commit 8f5d59b9cfa69beab3b52cca621bb301c5af98aa Author: Michael Chan Date: Mon Oct 5 13:42:44 2026 -0700 bnxt_en: Add bnxt_clear_bars() helper 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 commit 9b6c20f788472d2042717a3c2f1bc60b2b77083e 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 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 commit fd4e7f1137291c7446278a0189f8064f29b5a605 Merge: 23609bce9e1de5 9727d1c4e1c971 Author: Jakub Kicinski Date: Wed Oct 7 16:23:43 2026 -0700 Merge tag 'wireless-2026-10-07' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Some more fixes: - ath12k: revert broken panic handler - mt76: SAR/MLO/STA/NAPI fixes - nxpwifi: race fixes, validation - libertas: revert botched frame size fix - brcmfmac: fix crash on P2P removal - mac80211: fix WARN on downlink OFDMA frames * tag 'wireless-2026-10-07' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (25 commits) Revert "wifi: libertas: reject short monitor TX frames" wifi: brcmfmac: fix P2P device removal race in brcmf_detach() wifi: mac80211: don't estimate airtime for unsupported rate widths Revert "wifi: ath12k: add panic handler" wifi: nxpwifi: do not delete Rx reorder entries under RCU wifi: nxpwifi: fix inverted check in Tx BA stream entry deletion wifi: nxpwifi: handle authentication frame allocation failures wifi: nxpwifi: fix the authentication frame length handling wifi: nxpwifi: zero the channel statistics array wifi: nxpwifi: free the aggregation buffer when the RA list disappears wifi: nxpwifi: wait for the wakeup timer before the adapter is freed wifi: nxpwifi: delete the station entry on the uAP deauth event wifi: nxpwifi: protect sta_list against concurrent add and delete wifi: mt76: mt7996: fix uninitialized buf read in mt7996_variant_fem_init() wifi: mt76: mt792x: pick the SAR table layout from the table itself wifi: mt76: mt792x: treat 0xff ACPI SAR entries as no limit wifi: mt76: mt7603: initialize global station WCID wifi: mt76: mt7925: don't put the band auto marker in TGID wifi: mt76: mt7915: disable rx napi when removing device wifi: mt76: mt7996: fix struct mt7996_mcu_wed_rro_ba_delete_event layout ... ==================== Link: https://patch.msgid.link/20261007205143.464714-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski commit 9727d1c4e1c971fc42b049b645fdda6852758835 Author: Johannes Berg Date: Wed Oct 7 22:42:08 2026 +0200 Revert "wifi: libertas: reject short monitor TX frames" 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 commit d1a4549a3645e55cc9ade09e360280590b3c9559 Author: Pavankumar Kondeti Date: Mon Sep 28 09:25:46 2026 +0530 workqueue: Fix NULL current_pwq deref in mem-reclaim helper current_is_workqueue_mem_reclaim() uses current_wq_worker() to decide whether %current is a workqueue worker and then checks the current workqueue flags. However, current_wq_worker() only implies that %current is a kworker; it does not imply that the worker is currently executing a work item. worker->current_pwq is set while process_one_work() runs the work function and cleared afterwards. A kworker outside work-item execution can therefore have PF_WQ_WORKER set with current_pwq cleared. Guard the flag check with worker->current_pwq. Without a current_pwq, the worker is not executing on a WQ_MEM_RECLAIM workqueue, so the helper should return false. Fixes: da729ddd4a1b ("NFS/localio: issue IO inline when not in a memory-reclaim context") Signed-off-by: Pavankumar Kondeti Signed-off-by: Tejun Heo commit c7f44ec5c4ec760e74351f1843dcb8322f67cbf6 Author: Alex Deucher Date: Fri Sep 25 09:16:26 2026 -0400 drm/amdgpu: make Mac FB workaround generic 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 commit e6895021a328594368a2a19406a53ffca1ce51c7 Author: Haojie Li Date: Fri Oct 2 10:29:27 2026 +0800 drm/amdkfd: fix dma_buf reference leak in get_dmabuf_info 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 commit 54c998c55fc9cbc391b350d67b86e0c2a0748f1a Author: Adrian Betschart Date: Fri Sep 25 09:48:29 2026 +0200 drm/amd/display: Don't replace a sink mode that shares the native totals 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 commit f145d5b3f740de05d85257acdc82f6877180f5c6 Author: Saleel Kudchadker Date: Thu Sep 24 23:52:19 2026 +0000 drm/amdkfd: align SDMA doorbell base for shader doorbell writes 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 commit 16c64495859f13f75602f439588883f2a4a4d6a6 Author: Mikhail Gavrilov Date: Thu Oct 1 21:13:07 2026 +0500 drm/amdgpu: copy debugfs register data outside the GRBM/SRBM locks 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 commit 1a6023edfbb5673f55fab6348f135fb3b1428ea5 Author: Vitaly Prosyak Date: Tue Sep 29 20:18:26 2026 -0400 drm/amdgpu: serialize vblank counter reads against GPU reset 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 commit 2e54a92e0136c3ff5c7b542b95bf0940ad6687bf Author: Leo Li Date: Wed Sep 30 12:30:52 2026 -0400 drm/amd/display: disable self-refresh on tearing flips [Why & How] Immediate (tearing) flips breaks self refresh state machine assumptions, so disable PSR/Replay for them. Tested-by: Timur Kristóf Reviewed-by: Harry Wentland Signed-off-by: Leo Li Signed-off-by: Alex Deucher (cherry picked from commit acbdd213b37e095f15685f3e3ee6d35defa05616) Cc: stable@vger.kernel.org commit 76ceb6ed610cbf14341a9ba78c5c0b2199b9030a Author: Jesse Zhang Date: Wed Sep 30 14:21:19 2026 +0800 drm/amdgpu/userq: return the memdup_user() error for the user MQD 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 commit 7f7c88dbf4d543f6703e53bdeed380e886733167 Author: Jesse Zhang Date: Wed Sep 30 14:21:19 2026 +0800 drm/amdgpu/userq: only accept doorbell BOs as queue doorbell 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 commit 7744262f5d63f9faa4d59dec127ae1c8b2d56495 Author: Leo Li Date: Tue Sep 29 17:32:32 2026 -0400 drm/amd/display: Fix direct scanout alpha on some DRM_FORMATs [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 commit 59052a88ba5fe4a7bb34b3a0a42aa5d453d3bb97 Author: Zongmin Zhou Date: Wed Aug 26 19:57:11 2026 +0800 riscv: ptrace: Zero-initialize regset buffers before copyin user_regset_copyin() only copies `count` bytes, so a PTRACE_SETREGSET request with a short iov_len leaves the rest of the stack buffer uninitialized. In riscv_vr_set() that garbage is validated and copied into the target's vstate, and in riscv_cfi_set() it can be stored as the target's shadow stack pointer. Zero both buffers, as the get path already does. Fixes: 9300f0043974 ("RISC-V: Add ptrace support for vectors") Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files") Signed-off-by: Zongmin Zhou Link: https://patch.msgid.link/20260826115711.86861-1-min_halo@163.com Signed-off-by: Paul Walmsley commit adadf6df0bd55aa40ccbc6519fb443133e103227 Author: Chen Pei Date: Thu Aug 20 14:32:33 2026 +0800 riscv: ptrace: reject CFI regset access when extensions are absent riscv_cfi_get() and riscv_cfi_set() do not check whether the Zicfilp or Zicfiss extensions are present. On systems without them, PTRACE_GETREGSET on REGSET_CFI still succeeds and returns a zeroed user_cfi_state, misleading debuggers into believing the register set is available, and PTRACE_SETREGSET silently accepts writes that have no effect (e.g. clearing SR_ELP). Reject the access with -EINVAL when neither branch landing pads nor shadow stack is available to userspace, using the same availability helpers as the prctl path. Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files") Signed-off-by: Chen Pei Link: https://patch.msgid.link/20260820063233.2567-1-cp0613@linux.alibaba.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley commit 07e23d0b6f58eec351e52058b9a0a8af7b019c09 Author: Leo Yu-Chi Liang Date: Tue Oct 6 21:52:29 2026 -0700 riscv: fix NR_CPUS range leaking 64-bit default onto 32-bit builds rv32_defconfig is built in two stages: - the generic (64-bit-oriented) "defconfig" target runs first and resolves a concrete NR_CPUS value using the 64BIT default. - then 32-bit.config is merged on top via merge_config.sh, which does not touch NR_CPUS. The final "make olddefconfig" pass sees NR_CPUS=256 is still within the "2 512" range therefore never recalculates it against the 32BIT default of 32, silently keeping the leaked 64-bit-stage value. The NR_CPUS-scaled regions (percpu areas, ...etc) of the resulting CONFIG_NR_CPUS=256 on a 32-bit build bloats and does not fit in the percpu/stack layout for rv32 and hangs early boot on QEMU's virt machine. Fix this by explicitly specify the range for 32/64 and SBI_V01/!SBI_V01. Fixes: 0fa749771993 ("riscv: Raise default NR_CPUS for 64BIT to 256") Signed-off-by: Leo Yu-Chi Liang Link: https://patch.msgid.link/20261007045229.36114-1-leo.liang@sifive.com Signed-off-by: Paul Walmsley commit 298510bbc7c3017c0faf481c6ea66f1065b657b4 Author: Zongmin Zhou Date: Thu Sep 17 15:48:43 2026 +0800 riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE 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 commit 405290be962b32eec842776fbe3bdf81f15b1676 Author: Ziyi Guo Date: Tue Oct 6 14:02:00 2026 +0000 riscv: futex: untag the user pointer before the atomic access 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 commit 9ca0d0d0249230135dbf6fa1b9168e260151babc Author: Simon Trimmer Date: Wed Oct 7 13:08:57 2026 +0000 ASoC: amd: acp: Add more ACP7.0 match entries for Cirrus Logic parts This adds the following SoundWire configuration: cs42l43b link 0 UID 1 cs35l57 link 0 UID 0 cs35l57 link 0 UID 1 Signed-off-by: Simon Trimmer Link: https://patch.msgid.link/20261007130857.102432-1-simont@opensource.cirrus.com Signed-off-by: Mark Brown commit 7587fc10cba6c4a8d4c30ba480200370bc68dc74 Author: Simon Trimmer Date: Wed Oct 7 13:08:35 2026 +0000 ASoC: amd: acp: Add DMI override for ASUS EXPERTBOOK AM7406CKA A BIOS for this SKU has been observed with an incorrect acp-audio-config-flag, add the override so that it is forced to the correct value. Signed-off-by: Simon Trimmer Link: https://patch.msgid.link/20261007130835.102325-1-simont@opensource.cirrus.com Signed-off-by: Mark Brown commit 7b63ef2d55f24519e7e9e5f4d15dbea03f126e40 Merge: 0f2732620d6ec4 41c8899d59898f Author: Linus Torvalds Date: Wed Oct 7 15:58:48 2026 +0200 Merge tag 'for-7.3-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - fix command queuing and cleanup in encoded read/write ioctls - fix root and transaction association to avoid unnecessary lock contention and transaction start - properly handle replacing multiple xattrs in the same item - in scrub, fix root reference leak after reporting an unresolved file path * tag 'for-7.3-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix lost error return value in btrfs_listxattr() btrfs: fix xattr replace when multiple xattrs are packed in the same item btrfs: don't stash io_uring encoded data across -EAGAIN btrfs: unlock inode and extent in caller when io_uring read extent fails btrfs: free iov when btrfs_uring_read_extent() fails btrfs: always return -EIOCBQUEUED after btrfs_uring_read_extent_endio btrfs: scrub: fix local_root reference leak in scrub_print_warning_inode() btrfs: clear BTRFS_ROOT_IN_TRANS_SETUP on early exit from record_root_in_trans() commit 611857adc9e7b0ee1239a0baf38498922ca5a12e Author: Fan Wu Date: Mon Oct 5 20:04:14 2026 -0400 drm/xe/i2c: cancel the client work on remove xe_i2c_notifier() stores the DesignWare adapter in i2c->adapter and schedules i2c->work when the adapter is registered under the xe I2C platform device, and xe_i2c_client_work() then instantiates the AMC client device on that adapter. xe_i2c_remove() tears down the AMC, unregisters the client devices, the bus notifier and the adapter platform device, but it never drains i2c->work. A work item that is still queued or running when the adapter is unregistered dereferences i2c->adapter in i2c_new_client_device() after platform_device_unregister() has released the adapter. The work item is also embedded in the devm-allocated struct xe_i2c, so a work item still queued after the drm device devm unwind frees that allocation runs its callback on freed memory. The bus notifier is the only thing that schedules this work, and it is unregistered after the client devices. An instance that is still queued when the teardown runs can therefore write i2c->client[XE_I2C_CLIENT_AMC] while the loop is unregistering and clearing the same array, and an AMC client it instantiates late is only cleaned up by the adapter's own child sweep in i2c_del_adapter(). Move bus_unregister_notifier() in front of the client teardown loop and cancel the work right after it, so no new instance can be scheduled and a queued instance is drained before the client array is touched. A running instance still finds a live adapter, since the adapter is unregistered later. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Link: https://lore.kernel.org/intel-xe/20260912085932.101598-1-fanwu01@zju.edu.cn/ Cc: stable@vger.kernel.org Assisted-by: LLM, in-house static analysis tool Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260928013030.612592-1-fanwu01@zju.edu.cn Link: https://patch.msgid.link/20261006000413.318561-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit a23f27d5ec11c3f418c5e5531eea34ccda2b5b20) Signed-off-by: Rodrigo Vivi commit 5da1129613f27b5fdf7f3a47235e0fae71fa99ef Merge: a90ee4305c4a5d bca45af5998a05 Author: Dave Airlie Date: Wed Oct 7 21:28:15 2026 +1000 Merge tag 'drm-misc-fixes-2026-10-01' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Multiple patches for vc4 that improve memory safety and leaks, one error handling fix and a wrongful cast fix for th1520-dw-hdmi, one input validation fix and the blend mode property addition for vmwgfx, two locking fixes for drm_bridge, an input validation fix for panthor, an error handling fix for drm_dp_helper, EAGAIN handling fix for drm_fb_helper, and a clock reference leakage fix for aspeed. Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patch.msgid.link/ar5wE6ElDrxOfNBL@houat commit 1cca81a683da7f0ef2fbaf34442376044cbbad22 Author: Mario Limonciello Date: Mon Oct 5 13:01:47 2026 -0500 pinctrl: amd: Clear S4 wake bits when firmware has _AEI Commit ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe") preserves firmware-programmed S4 wake sources because some PCIe devices rely on them for Wake-on-LAN. The system that motivated that change does not expose ACPI GPIO events through _AEI. On a Chuwi CoreBook Plus, firmware exposes _AEI but also leaves the S4/S5 wake bit set for GPIO 24. This causes the machine to power back on immediately after shutdown even though Wake-on-LAN is not enabled. GPIO register dumps show that the only relevant difference is bit 15 on GPIO 24. Clearing that bit makes the machine remain off. GPIO 24 is not itself listed in _AEI, so _AEI is not a per-pin indication of which pins the OS manages; it is a platform level signal of which wake model the firmware follows. Use that signal to decide what to clear. Continue clearing S0i3/S3 bits on every system. Clear S4 bits when firmware exposes _AEI, indicating that the platform hands GPIO events to the OS, but preserve S4 bits when _AEI is absent so that firmware-programmed sources such as PCIe PME that bypass the GPIO IRQ wake API keep working. A platform that exposes _AEI for some pins while routing a wake capable device through a raw GPIO not listed in _AEI would lose that wake source unless firmware re-arms it during the sleep transition. No such system has been reported. Fixes: ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe") Reported-by: Olzhas Marat Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222041 Cc: stable@vger.kernel.org Tested-by: Olzhas Marat Reviewed-by: Shyam Sundar S K Signed-off-by: Mario Limonciello Signed-off-by: Linus Walleij commit fb52d063456741c623967882785e01272501949b Merge: 7529254014764a 4b7f393a01f88e Author: Mark Brown Date: Wed Oct 7 13:20:06 2026 +0200 ASoC: cs35l56/57/62/63: Use the correct SoundWire DP for feedback Richard Fitzgerald says: The amp feedback path (AEC) was incorrectly using SoundWire DP3. The firmware outputs SDCA OT25 feedback on DP4. DP3 is reserved for SDCA companion amp. This series adds a DAI for OT25 and switches the sdw machine driver to use the new DAI for the feedback path. Link: https://patch.msgid.link/20261005155235.1386525-1-rf@opensource.cirrus.com commit 4b7f393a01f88e8d03cba94cf4948652de14789b Author: Richard Fitzgerald Date: Mon Oct 5 16:52:35 2026 +0100 ASoC: sdw_utils: Switch CS35L56/57/62/63 to use OT25 DAI Change the CS35L56/57/62/63 entries in codec_info_list[] to use the OT25 DAI for amp feedback. The AMP feedback was incorrectly using a DAI connected to DP3, but that is reserved for SDCA companion amp. The correct amp output is DP4, which is the SDCA OT25 feedback output. Fixes: 898cd43bde307 ("ASoC: intel: sof_sdw: Add support for CS35L63 into machine driver") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20261005155235.1386525-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit 86c8360c97f66fa7830fd930e2dc69374007284b Author: Richard Fitzgerald Date: Mon Oct 5 16:52:34 2026 +0100 ASoC: cs35l56: Add DAI for SDCA OT25 stream Add a DAI for the SDCA OT25 stream on SoundWire DP4. The SDCA-defined OT25 stream is an amp reference feedback, typically used for AEC. The firmware outputs this on DP4. The firmware owns all control registers for this stream so there are no mixer controls or any other configuration options. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20261005155235.1386525-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit 08a3f02fea636e97a7422d1512f76dacdb5b0887 Author: Michele Dionisio Date: Thu Sep 24 14:30:27 2026 +0200 wifi: brcmfmac: fix P2P device removal race in brcmf_detach() 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 commit c96334f67061eb45cef1e54f73e1846d57615ad1 Merge: 420e393bc79601 05165f7b3b9ab6 Author: Johannes Berg Date: Tue Oct 6 18:00:35 2026 +0200 Merge tag 'ath-current-20261006' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git update for v7.3-rc7 In ath12k, revert the panic handler that landed in v6.11 since it can perform a voluntary context switch within an RCU read-side critical section. ================== Signed-off-by: Johannes Berg commit 420e393bc79601d764991591f38f84c4d6b6de0a Merge: 95148fe661ffb9 5e99bdb9472033 Author: Johannes Berg Date: Tue Oct 6 17:40:31 2026 +0200 Merge tag 'nxpwifi-fixes-20261006-v2' of https://github.com/nxp-upstream/nxpwifi-next Jeff Chen says: =============== nxpwifi updates for 7.3 This update contains fixes for station list synchronization, aggregation and reorder buffer cleanup, authentication frame handling, and several memory safety issues. Highlights: - fix concurrent sta_list add/delete races - clean up station entries on uAP deauthentication - fix Tx BA stream entry deletion logic - avoid deleting Rx reorder entries under RCU - improve aggregation buffer cleanup - fix authentication frame length validation - handle authentication frame allocation failures - fix wakeup timer shutdown ordering =============== Signed-off-by: Johannes Berg commit 95148fe661ffb90c8ecc94ce88c808a61801ea14 Merge: f394cbd0980c95 52f6a065e0810c Author: Johannes Berg Date: Tue Oct 6 12:46:20 2026 +0200 Merge tag 'mt76-fixes-2026-10-05' of https://github.com/nbd168/wireless Felix Fietkau says: =================== mt76 fixes for 7.3 - mt7925 ACPI SAR fixes - MLO fixes - sta handling fixes - mt7915 napi disable fix =================== Signed-off-by: Johannes Berg commit f394cbd0980c95c9173f8551a5eb4c4f28d598eb Author: François Roux Date: Tue Oct 6 10:37:51 2026 +0200 wifi: mac80211: don't estimate airtime for unsupported rate widths ieee80211_fill_rate_info() copies the driver's rate_info bandwidth into the rx_status as is, but ieee80211_get_rate_duration() only handles 20/40/80/160/320 MHz. When a driver reports another width, e.g. an HE/EHT RU allocation, it hits WARN_ON_ONCE() and returns 0 without setting *overhead. ieee80211_rate_expected_tx_airtime() then goes on using the uninitialized overhead, as Dan's static checker report points out. Seen on a Microsoft Surface Pro 11 (WCN7850, ath12k) while NetworkManager dumps station info: WARNING: net/mac80211/airtime.c:532 at ieee80211_get_rate_duration.isra.0+0xc0/0x180 [mac80211] ieee80211_get_rate_duration.isra.0+0xc0/0x180 [mac80211] sta_estimate_expected_throughput.isra.0+0x38/0x64 [mac80211] sta_set_sinfo+0x7fc/0x8e4 [mac80211] ieee80211_dump_station+0x4c/0x84 [mac80211] nl80211_dump_station+0x594/0x7e8 [cfg80211] Only accept widths that ieee80211_get_rate_duration() handles in ieee80211_fill_rate_info(). Other widths then give no estimate instead of a warning. Also return 0 from ieee80211_rate_expected_tx_airtime() when no duration could be computed, as ieee80211_calc_rx_airtime() already does. Tested on the Surface Pro 11 with next-20260929: Wi-Fi works and "expected throughput" is still reported (about 1049 Mbit/s for a 1297 Mbit/s HE 160 MHz tx rate). The warning itself is rare (twice in several days of use), so this does not prove it is gone, only that the change does not break the normal path. Fixes: 094dc1619cb0 ("wifi: mac80211: factor out part of ieee80211_calc_expected_tx_airtime") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/aneGlCMVnqRhlf6p@stanley.mountain/ Assisted-by: LLM Signed-off-by: François Roux Link: https://patch.msgid.link/20261006083751.4015-1-franzelfranzel@gmail.com Signed-off-by: Johannes Berg commit 0f2732620d6ec49d3e6c06831575eaec6bc99d42 Merge: 602042bf29f6ef fc79aeb86a2c24 Author: Linus Torvalds Date: Wed Oct 7 12:19:52 2026 +0200 Merge tag 'for-7.3/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fixes from Mikulas Patocka: "dm-integrity: - validate the superblock after re-reading it - fix buffer overflow if tag size > 64 dm: - fix reading up to 7 bytes beyond the end of block in dm-ioctl - fix reading free memory if the ioctls are called concurrently dm-crypt: - fix a crash on invalid table line dm-snap: - fix a crash on invalid table line" * tag 'for-7.3/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm-integrity: validate the superblock on resume dm-snap: reject the transient exception store for snapshot-merge dm: fix reading free memory in do_resume dm ioctl: don't let data_start run past the buffer dm-crypt: reject the lmk IV mode with AEAD ciphers dm-integrity: fix buffer overflow in inline mode with large tag size commit a9cd14bfb0c113f1cd77be4349784663bec71bb4 Author: Karl Mehltretter Date: Sat Sep 26 21:13:25 2026 +0200 arm64: irq: exclude the softirq stack switch from KCOV 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 commit 23609bce9e1de525d1d0e73fc68c6e7971d0b49e Author: Haishuang Yan Date: Wed Sep 30 20:48:18 2026 +0800 pfcp: make sure the SEID is linear before reading it 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 commit 5857e5a196b069766a39ceb754736326a43bc6bc 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 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 commit 0984ebc631792acf8fff105112ee74a6b8f1efcc 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 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 commit 538b529509c7ab0d909cb65bb7264edca1788d30 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 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 commit c8a900ded7759ca982910d3fb4a56f11529079b4 Merge: 86b785b18f8f4a 7f85d117057564 Author: Jakub Kicinski Date: Tue Oct 6 18:11:19 2026 -0700 Merge tag 'linux-can-fixes-for-7.3-20261001' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2026-10-01 The first patch is by zjamg and restores the skb header initialization lost during the v7.0 release cycle. Oliver Hartkopp contributes a patch for the CAN net layer to fix the unique skb identifier regression under RPS, introduced in the v7.0 release cycle, which causes lost packets. The last patch is by Ji-Ze Hong and fixes a struct size mismatch in the f81604 CAN driver, which results in a TX starvation. * tag 'linux-can-fixes-for-7.3-20261001' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: usb: f81604: fix struct f81604_int_data size mismatch can: fix unique skb identifier regression under RPS can: dev: init_can_skb(): restore skb header initialization ==================== Link: https://patch.msgid.link/20261001151905.1556270-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski commit 86b785b18f8f4a6b4a7392d1e2b29d6bb095011a 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" 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 commit 6fa2e7db99fb9ed67496c652fcfce5a31c6b73d0 Author: Victor Nogueira Date: Thu Oct 1 12:32:01 2026 -0300 selftests: tc-testing: add cls_route no-routing-attribute change tests Add a boundary pair for route4 change without a routing attribute: - a classid-only change of a wildcard filter (handle 0xffff8000) is a metadata-only update and must succeed; - the same change on a non-wildcard handle (0x10001) would rekey the filter to the wildcard bucket, leaving the handle userspace stored stale, and must be rejected with -EINVAL. The change of a wildcard filter is the flow iproute2 uses by default ("tc filter add ... route classid X:Y" gives handle 0xffff8000). Reviewed-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-0JB3.v1.20260923100921@mojatatu.com.2 Signed-off-by: Jakub Kicinski commit b72e025ac556984766392001e74b7587e145bcd0 Author: Victor Nogueira Date: Thu Oct 1 12:32:00 2026 -0300 net/sched: cls_route: reject change with no routing attribute 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 commit c5c4e1701059324914873f9e8e65c57ebd96ac96 Merge: f75b8de197e718 e32d80293a0e1a Author: Jakub Kicinski Date: Tue Oct 6 17:38:23 2026 -0700 Merge tag 'for-net-2026-10-05' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: Core: - hci_sync: Fix command skb lifetime during scan setup - hci_sock: Serialize dead-device detachment - RFCOMM: free the skb when the DLC has no owner - RFCOMM: connect the session socket without rfcomm_mutex - RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown - SCO: serialise sco_conn lifetime against sco_recv_scodata() - ISO: Reject concurrent BIS listener setup - ISO: Serialize concurrent connect calls - MGMT: Fix status of pending commands flushed on power off Driver: - btintel_pcie: fix TX descriptor bounds check - btintel_pcie: use managed IRQ teardown - btintel_pcie: Add shared HW reset for clean start * tag 'for-net-2026-10-05' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: ISO: Serialize concurrent connect calls Bluetooth: ISO: Reject concurrent BIS listener setup Bluetooth: hci_sync: Fix command skb lifetime during scan setup Bluetooth: hci_sock: Serialize dead-device detachment Bluetooth: RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown Bluetooth: btintel_pcie: use managed IRQ teardown Bluetooth: MGMT: Fix status of pending commands flushed on power off Bluetooth: btintel_pcie: Add shared HW reset for clean start Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex Bluetooth: btintel_pcie: fix TX descriptor bounds check Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata() Bluetooth: RFCOMM: free the skb when the DLC has no owner ==================== Link: https://patch.msgid.link/20261005194436.3594085-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski commit 602042bf29f6efde39cfb5fdd9289bf4854bc0c5 Merge: 0d32b3ec5f902b 980db94e3eeefd Author: Linus Torvalds Date: Wed Oct 7 02:24:23 2026 +0200 Merge tag 'wq-for-7.3-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq Pull workqueue fixes from Tejun Heo: - Fix a NULL dereference in the chained work check when a kworker queues work on a draining or destroying workqueue outside work item execution. * tag 'wq-for-7.3-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: Fix NULL current_pwq deref in chained work check commit f75b8de197e718e8bce8f5eb0cf54f592dc48d20 Merge: c5381ae1cd1481 489114c9ecae44 Author: Jakub Kicinski Date: Tue Oct 6 17:20:56 2026 -0700 Merge branch 'net-team-fix-transmit-skb-ownership' Weiming Shi says: ==================== net: team: fix transmit skb ownership The queue override path can pass an skb to a lower device, see that dev_queue_xmit() returned a drop, and then reuse the consumed skb. Fix the handoff decision separately from the transmit result. An AI-generated review of v1 forwarded by Jakub identified a separate broadcast-mode leak: bc_transmit() returns without consuming the skb when no port is txable. Fix that in the second patch. ==================== Link: https://patch.msgid.link/20261001182326.572045-1-bestswngs@gmail.com Signed-off-by: Jakub Kicinski commit 489114c9ecae44e523361a4b3e610ee5ebd9189c Author: Weiming Shi Date: Fri Oct 2 02:23:26 2026 +0800 net: team: free skb when broadcast has no txable port 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 commit b7454f1940c5e6d92e753853c476a769e452f30a Author: Weiming Shi Date: Fri Oct 2 02:23:25 2026 +0800 net: team: stop reusing skb after queue override 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 commit 0d32b3ec5f902bf40d03db08837f3eafbb6a4577 Merge: 762122d75e50e4 b8eb5fd5bdb4c0 Author: Linus Torvalds Date: Wed Oct 7 02:19:02 2026 +0200 Merge tag 'cgroup-for-7.3-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: - During CPU offline, the active mask drops the CPU before cpuset updates the effective CPUs, so a task placement in that window could find no active CPU in the top cpuset and dereference NULL. Restore the NULL check. - The cpuset v2-mode test read the subsystem's root pointer, which is stale during a cgroup filesystem rebind, and the hotplug handler evaluated it before taking the cpuset mutex. Record the mode in a flag and test it under the mutex. * tag 'cgroup-for-7.3-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup/cpuset: Call is_in_v2_mode() after acquiring cpuset_mutex in cpuset_handle_hotplug() cgroup/cpuset: Handle cpu hotplug race in guarantee_active_cpus() cgroup/cpuset: Don't access cpuset_cgrp_subsys.root in is_in_v2_mode() commit c5381ae1cd1481cc431c2bd79460472c6f1d3ce3 Author: Haishuang Yan Date: Thu Oct 1 12:22:32 2026 +0800 devlink: fix devlink_rel reference leak when notify work is pending 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 commit ca5012757bf027df83d51593a07656cb8c80caee Author: Quentin Freimanis Date: Sun Oct 4 22:28:26 2026 -0700 net: sparx5: start the TOD counters on non-PTP lan969x variants 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 commit 762122d75e50e4919ef77afc2dffdc4931c5be87 Merge: 69f80fef315329 e6ac89b8b1c12e Author: Linus Torvalds Date: Wed Oct 7 02:03:46 2026 +0200 Merge tag 'sched_ext-for-7.3-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext Pull sched_ext fixes from Tejun Heo: - Taking a CPU offline could hang, or stall until the watchdog ejected the BPF scheduler, when tasks on the dying CPU were still held by the scheduler or sitting on a user dispatch queue. Re-enqueue them onto the local queue when the runqueue goes offline so that the CPU pushes them off like the other sched classes. - The sequence number guarding against stale dispatches was per runqueue, so a task re-enqueued on another CPU could get the same number and a dispatch meant for its earlier instance was applied to the new one. Use a per-task counter. - A task dispatched to another CPU's local queue got its ops.dequeue() only when picked to run and flagged as a core-sched pick. Call it at insertion like for same-CPU dispatches. * tag 'sched_ext-for-7.3-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: Generate qseq from a per-task counter selftests/sched_ext: Add a test for ops.dequeue() on remote local DSQ moves sched_ext: Call ops.dequeue() when a task arrives on a remote local DSQ sched_ext: Fix CPU hotplug hang when a dying CPU's tasks sit in the BPF scheduler commit 80ce29104123be4d61b5912dae543c70af0fcb75 Author: Andy Yan Date: Thu Sep 24 18:50:33 2026 +0800 mailmap: update entry for Andy Yan I will use andyshrk@163.com for future review and discussion. Link: https://lore.kernel.org/20260924105052.768760-1-andyshrk@163.com Signed-off-by: Andy Yan Signed-off-by: Andrew Morton Reviewed-by: Shawn Lin Cc: Alexander Sverdlin Cc: Chuck Lever Cc: Jakub Kicinski Cc: Martin Kepplinger commit d3ed3a40951c964d30dc7fc63d13e87a873ea300 Author: Lorenzo Stoakes (ARM) Date: Thu Sep 24 15:48:24 2026 +0100 drivers/char/mem: mmap readonly MAP_SHARED-/dev/zero correctly Rather surprisingly, opening /dev/zero read-only then mmap()'ing it MAP_SHARED gets you true anonymous memory (albeit in a VMA with non-NULL vma->vm_file). This is a by-product of MAP_PRIVATE-/dev/zero being how anonymous memory was mapped in Linux's distant past. It happens because mmap_zero_prepare() gates on VMA_SHARED_BIT and when mapping a read-only file MAP_SHARED, do_mmap() clears VMA_SHARED_BIT and VMA_MAYWRITE_BIT. The gating is incorrect - the (poorly named) VMA_MAYSHARE_BIT flag exists explicitly to tell you if something was originally mapped MAP_SHARED. So the fix is simple - gate on this instead. This isn't exactly a common use case, but it's unexpected behaviour which now causes an assert if CONFIG_DEBUG_VM is set. While this bug has existed since the dawn of time for linux (or at least since 2.6.12), it hasn't caused issues in the past, so while it's incorrect behaviour, it doesn't seem necessary to backport that far. The mapping is now accounted at mmap time and can fail with -ENOMEM under strict overcommit, and read faults allocate folios. However this is normal behaviour for a read-only shmem mapping. Commit 93c0c8dc87f6 ("mm/rmap: use anon pgoff to track MAP_PRIVATE file-backed anon folios") is the first patch at which the debug assert fires, so target that instead. Link: https://lore.kernel.org/20260924-fix-dev-zero-readonly-shared-v1-1-153c2111e323@kernel.org Fixes: 93c0c8dc87f6 ("mm/rmap: use anon pgoff to track MAP_PRIVATE file-backed anon folios") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Reported-by: Closes: https://lore.kernel.org/linux-mm/6ab4ae75.80e1c6cc.1e8e5f.000d.GAE@google.com/ Acked-by: David Hildenbrand (Arm) Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Lance Yang commit 28eed9906e01d01cbdfb352e799413b2e8b33b76 Author: Carlos Llamas Date: Sun Sep 27 16:24:18 2026 +0000 selftests/mm: cleanup -Wformat issues in hugetlb-mmap Commit ae571cd6015c ("selftests/mm: hugetlb-mmap: add setup of HugeTLB pages") and commit 9c5a65f374f8 ("selftests/mm: merge map_hugetlb into hugepage-mmap") added logs of 'hugepage_size' which has a size_t type. However, the incorrect format specifier '%lu' was used which triggers -Wformat warnings when building for 32-bit: hugetlb-mmap.c:125:55: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat] 125 | ksft_print_msg("Default size hugepages (%lu kB)\n", hugepage_size >> 10); | ~~~ ^~~~~~~~~~~~~~~~~~~ | %zu hugetlb-mmap.c:134:47: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat] 134 | ksft_exit_skip("Not enough %lu Kb pages\n", hugepage_size >> 10); | ~~~ ^~~~~~~~~~~~~~~~~~~ | %zu Fix this by switching to the expected '%zu' format specifier. Link: https://lore.kernel.org/20260927162419.820609-1-cmllamas@google.com Fixes: ae571cd6015c ("selftests/mm: hugetlb-mmap: add setup of HugeTLB pages") Fixes: 9c5a65f374f8 ("selftests/mm: merge map_hugetlb into hugepage-mmap") Signed-off-by: Carlos Llamas Signed-off-by: Andrew Morton Reviewed-by: Sarthak Sharma Reviewed-by: SJ Park Acked-by: Lorenzo Stoakes (ARM) Cc: Mike Rapoport Cc: David Hildenbrand Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Shuah Khan Cc: commit 2fb552b0bee70c24c092720028ab4620f5eb2646 Author: Mikhail Gavrilov Date: Fri Sep 25 10:06:47 2026 +0500 mm: don't schedule deferred kernel page table freeing while booting 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: commit 29e0dd1f2ef82d0931ed1a4e6b1d8aa04650835d Author: John Garry Date: Wed Sep 23 08:53:24 2026 +0100 mailmap: update addresses for John Garry Point any employment addresses at my personal dev address. Link: https://lore.kernel.org/20260923075324.1382927-1-john.garry@linux.dev Signed-off-by: John Garry Signed-off-by: Andrew Morton commit 597e4b9ab48a3f841080f627722064853d3f650e Author: Lorenzo Stoakes (ARM) Date: Wed Sep 30 19:47:10 2026 +0100 mm/mremap: fix locked_vm leak by splitting VMA for MREMAP_DONTUNMAP The MREMAP_DONTUNMAP feature is highly unusual in that it permits mremap() operations that keep the original VMA in place. Historically this has led to a lot of bugs where non-obvious interactions occur between existing mremap() operations and the original VMA. Fix another of these - partial copies. The long-standing mremap() partial VMA logic has the baked-in assumption that the originating VMA is unmapped and thus moved. However MREMAP_DONTUNMAP defeats this by performing a partial copy instead since it keeps the source VMA around. An mremap(..., MREMAP_DONTUNMAP) operation disallows resizing of the VMA, but the operation can be performed partially: |-----------------| | | | v <------> <------> .new_sz. new_sz |--.------.--| |------| | .source. | | dest | |--.------.--| |------| <------------> old_sz The page tables in the specified range are moved, but the original VMA is kept intact. This interacts poorly with mlock()'d VMAs, as the VMA_LOCKED_BIT flag is cleared for the entire source VMA and set for the entire destination VMA. This results in an mm->locked_vm leak as the change is therefore not accounted correctly. The clear solution here is to make the portion of the source VMA which is mremap()'d distinct from the rest of it, a.k.a. split it. Therefore resolve this issue by splitting it ahead of the rest of the mremap() operation if the VMA is mlock()'d. This is valid, as the source VMA will lose its VMA_LOCKED_BIT flag, so if a partial remap it will become distinct from the rest of the VMA. In order to make this change re-expose split_vma() in vma.h for CONFIG_MMU (nommu doesn't compile mremap.c and uses a static helper instead). Finally, update the sys_map_count check to account for this case. Note that the early check does not use needs_pre_split() - this is because the VMA has not been looked up by this point, so be conservative and assume that the VMA is mlock()'d in this case for the purposes of the sys_map_count check. Link: https://lore.kernel.org/20260930-fix-dontunmap-partial-self-merge-v2-2-f388985a0f0a@kernel.org Fixes: e346b3813067 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Reviewed-by: Pedro Falcato Acked-by: Kiryl Shutsemau (Meta) Reviewed-by: Jose A. Perez de Azpillaga Tested-by: Anirudh Srinivasan Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Brian Geffon Cc: Minchan Kim Cc: commit 838bb60dc21553e32df90f2f3bac5b905376e7aa Author: Lorenzo Stoakes (ARM) Date: Wed Sep 30 19:47:09 2026 +0100 mm/mremap: fix locked_vm leak from MREMAP_DONTUNMAP self-merge Patch series "mm/mremap: fix two issues with MREMAP_DONTUNMAP", v2. The MREMAP_DONTUNMAP feature is highly unusual in that it permits mremap() operations that keep the original VMA in place. Historically this has led to a lot of bugs where non-obvious interactions occur between existing mremap() operations and the original VMA. Commit 397432cab17b ("mm/mremap: account mm->locked_vm correctly for MREMAP_DONTUNMAP") fixed an accidentally introduced bug around mm->locked_vm accounting, but this wasn't the only issue. And thus history repeats itself, as it turns out that mm->locked_vm accounting is broken by MREMAP_DONTUNMAP yet again by two further cases, and has been broken ever since the feature was introduced. Both relate to the fact that VMA_LOCKED_BIT is cleared on the source VMA (it has to be as all page tables are moved): 1. If an unfaulted VMA_LOCKONFAULT_BIT anonymous VMA self-merges it clears the VMA_LOCKED_BIT flag and permanently leaks mm->locked_vm pages. 2. If a partial mremap() is performed on a locked VMA there is a leak equal to the number of pages not copied. (Both for MREMAP_DONTUNMAP operations only) Both issues can be fixed by treating the source range as distinct from the destination range, which is the definition of what MREMAP_DONTUNMAP does so is appropriate. In case 1, simply disallow the self-merge, keeping adjacent source and destination VMAs distinct. In case 2, split the source range ahead of time if the VMA is mlock()'d, so accounting is always correct. Both changes were tested locally and confirmed to fix the issues. For the purposes of a backport, the fixes are kept distinct, a follow-up series can add self-tests. This patch (of 2): The MREMAP_DONTUNMAP feature is highly unusual in that it permits mremap() operations that keep the original VMA in place. Historically this has led to a lot of bugs where non-obvious interactions occur between existing mremap() operations and the original VMA. Fix another of these - self-merge. Self-merge occurs when a VMA is moved in front of or behind itself and the attributes of the VMA permit such a merge. Practically this can only happen for unfaulted anonymous VMAs due to the page offset equality requirement for merge: |------------| | | | v |...........||-----------||...........| | || unfaulted || | |...........||-----------||...........| ^ | | | |------------| This becomes problematic if the VMA is configured by the user to mlock-on-fault, i.e. the VMA_LOCKED_BIT, VMA_LOCKONFAULT_BIT VMA flags are set. MREMAP_DONTUNMAP clears mlock flags for the source VMA and maintains them for the destination VMA. Self-merge makes this impossible (there is only one VMA) and incorrectly clears the destination VMA's mlock flags. This causes a leak in mm->locked_vm as clearing this flag does not decrement the counter and the VMA no longer has VMA_LOCKED_BIT set so it is not decremented on unmap. Resolve this by simply disallowing a self-merge in this case - the source and destination VMAs are kept distinct and then are able to have distinct mlock() flags. Update dontunmap_complete() to make the now-redundant self-merge check a VM_WARN_ON_ONCE() instead to guard against future regressions. Also update the VMA userland tests to reflect the change. Link: https://lore.kernel.org/20260930-fix-dontunmap-partial-self-merge-v2-0-f388985a0f0a@kernel.org Link: https://lore.kernel.org/20260930-fix-dontunmap-partial-self-merge-v2-1-f388985a0f0a@kernel.org Fixes: e346b3813067 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Reviewed-by: Pedro Falcato Acked-by: Kiryl Shutsemau (Meta) Reviewed-by: Jose A. Perez de Azpillaga Tested-by: Anirudh Srinivasan Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Brian Geffon Cc: Minchan Kim Cc: commit 588003f74005bbe34cdb4a39f65312cd43cf6935 Merge: a463f55c791b96 d3daa33c7af92e Author: Jakub Kicinski Date: Tue Oct 6 16:23:11 2026 -0700 Merge branch 'ipv4-handle-nexthop-group-shrink-races' Daehyeon Ko says: ==================== ipv4: handle nexthop group shrink races fib_info_num_path() and fib_info_nhc() can observe different RCU generations of a replaceable nexthop group. An indexed consumer can therefore accept an index from a larger group and receive NULL after a concurrent shrink. Patch 1 is unchanged from v1. Patch 2 addresses the analogous fib_dump_info_fnhe() race Ido identified. Auditing the remaining accessor pairs found the same issue in the RCU-only hardware-flag notification path, fixed by patch 3. Separate patches retain the correct Fixes tag for each concurrency boundary. ==================== Link: https://patch.msgid.link/cover.1790915964.git.4ncienth@gmail.com Signed-off-by: Jakub Kicinski commit d3daa33c7af92e38f2274bbd2576f58bfbaf89e6 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 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 commit 4f4afc07dcb2edd4f9afa36595373f8cdb9b58c2 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Fri Oct 2 13:50:59 2026 +0900 ipv4: stop exception dump when nexthop group shrinks 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 commit 6619e01855e65ef35723685a557e3eb106f4ecf5 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Fri Oct 2 13:50:58 2026 +0900 ipv4: stop PMTU walk when nexthop group shrinks 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 commit a463f55c791b96cfd12df8b10ea737d45c80bb18 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Fri Oct 2 00:13:10 2026 +0900 vsock/virtio: account only unread bytes in read_skb() 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 commit 8bc60db48e8cba35488bbd6e1f94aa990afa275a Author: Daehyeon Ko <4ncienth@gmail.com> Date: Fri Oct 2 12:30:58 2026 +0900 ip6_gre: remove obsolete ERSPAN PMTU update A tc tunnel_key action can attach a METADATA_IP_TUNNEL dst to an skb, and mirred can redirect it to a native ip6erspan device. The legacy PMTU update in ip6erspan_tunnel_xmit() treats that metadata dst as a route. Since it has no output device, dst_dev(dst)->mtu dereferences NULL. On v7.2 with KASAN, an initial UID/GID 65534 process with CapEff 0 used self-created user and network namespaces to trigger: KASAN: null-ptr-deref RIP: ip6erspan_tunnel_xmit+0x10fc/0x2cc0 Kernel panic - not syncing: Fatal exception in interrupt The update is obsolete. Commit fe1a4ca0a2b7 ("ip6_gre: process toobig in a better way") changed IPv6 GRE Too Big handling to update the underlay route and removed the equivalent block from __gre6_xmit(). ip6_tnl_xmit() then propagates the underlay PMTU to the overlay route. Remove the stale ERSPAN copy and its now-unused dst variable. This eliminates the metadata-dst dereference and keeps ERSPAN aligned with IPv6 GRE PMTU handling. Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support") Cc: stable@vger.kernel.org Suggested-by: Ido Schimmel Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20261002033058.358137-1-4ncienth@gmail.com Signed-off-by: Jakub Kicinski commit 3d399224425573875b6f6f1181bd8cf9a28cc7d1 Author: Christian Brauner Date: Sun Oct 4 13:02:20 2026 +0200 namespace: simplify disconnect_mount() Rename disconnect_mount() and simplify it. Signed-off-by: Christian Brauner (Amutable) commit 9e320581ee632f0b141e52419065de53e7a033b0 Merge: 1514faf41f7ccd 3e78bf8433e0bd Author: Christian Brauner Date: Sun Oct 4 21:46:55 2026 +0200 Merge patch series "namespace: rework connected mounts" Christian Brauner says: This is a simplified version and doesn't require vacating existing mounts and doesn't require such heavy machinery. UMOUNT_CONNECTED as implemented allows for the creation of reference count cycles. Here's a simple example mkdir /x; mkfifo /ready /go unshare -m sh -c 'mount -t tmpfs tmpfs /x truncate -s 8M /x/img; mkfs.ext4 -q /x/img dev=$(losetup -f --show /x/img) mkdir /x/mp; mount $dev /x/mp echo $dev > /ready; read r < /go' & read dev < /ready rmdir /x echo > /go wait losetup -d $dev losetup -a Take a directory /x on the host, create a new mount namespace, mount a tmpfs on /x, use a file on that tmpfs as the backing file for a loop device, mount that loop device on that tmpfs. Now rmdir /x on the host. This will lazily unmount the mount on top of /x in the container with UMOUNT_CONNECTED. Once the namespace exits nothing references the mount anymore. Now the tmpfs is pinned by the backing file of the loop device and the loop mount is owned by the tmpfs superblock. Fun fact, such cycles can be formed by at least the following subsystems and I have added reproducers for all of them: (1) a loop mount P from an image on a tmpfs next to it, so that P's death shows as the loop device giving up its backing file (2) autofs with a FIFO on P as its pipe, zram with a device node on P as its writeback device, both on a minix image since vfat has neither (3) ecryptfs with its lower directory on P, under a passphrase token added to the session keyring (4) binfmt_misc in a new user namespace with an 'F' interpreter on P (5) a fuse server that answers FUSE_INIT with passthrough on and registers a file on P as a backing file (6) zloop with its zone files in a directory on P (7) a mass storage gadget on the dummy UDC with its LUN file on P, mounted from the SCSI disk the gadget shows up as (8) md with a RAID1 of one loop device and its bitmap file on P, which skips while SET_BITMAP_FILE has no way to succeed (9) rmdir of P's mountpoint from the parent, then the child exits, then the device must be free and LOOP_CLR_FD must release the file The underlying mechanism is UMOUNT_CONNECTED (MNT_LOCKED falls into the same class). With UMOUNT_CONNECTED an unmounted mount stays attached to its parent. This is used to protect revealing the underlying mount and is a non-negotiable security mechanism. So now the parent owns that mount and is put on the parent's final mntput(). That moves it to mnt_stuck_children and ultimately it's cleaned up by cleanup_mnt(). The fact that ownership of the child mount gets transferred to the parent turns every reference from a child's superblock back to one of its ancestors into a cycle. Don't keep the child attached at all. What the parent needs is that a lookup at the child's mountpoint keeps finding some mount, not the child itself and it's not a guarantee we have given really. When an unmounted mount would have stayed attached to its unmounted parent disconnect it like every other unmounted mount and leave a marker behind. A lookup on the parent that misses the mount hash and hits a marker finds knullfs. Either a file or a directory. Nothing leads from a marker to any other mount. The marker is owned by the parent and dropped by the parent's final mntput() or by __detach_mounts() when the mountpoint is deleted from under it. It is allocated together with the mount. With that every unmounted mount is a root and holds only its own reference which namespace_unlock() drops. No unmounted mount owns another one. A superblock that pins an ancestor can't form a cycle. It has a visible change. Mounts left connected (rmdir etc.) used to stay traversable through the parent for as long as something held the parent. Now it is detached with the umount. It lives as long as something references it but it isn't reachable through the parent anymore and ".." inside it leads nowhere which is the same as for every other lazily unmounted mount. * patches from https://patch.msgid.link/20261002-work-mount-cover-v1-0-232a8f52b43c@kernel.org: selftests/filesystems: test covered mounts namespace: rework connected mounts nullfs: add an empty immutable regular file Link: https://patch.msgid.link/20261002-work-mount-cover-v1-0-232a8f52b43c@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 3e78bf8433e0bdb013e2681c96fdb93e1966eb17 Author: Christian Brauner Date: Fri Oct 2 16:14:29 2026 +0200 selftests/filesystems: test covered mounts Test that mount cycles are resolved and test that mount covers behave as expected. Link: https://patch.msgid.link/20261002-work-mount-cover-v1-3-232a8f52b43c@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 01cbebb420709af722a769dddac26b30270ae4b2 Author: Christian Brauner Date: Fri Oct 2 16:14:28 2026 +0200 namespace: rework connected mounts UMOUNT_CONNECTED as implemented allows for the creation of reference count cycles. Here's a simple example mkdir /x; mkfifo /ready /go unshare -m sh -c 'mount -t tmpfs tmpfs /x truncate -s 8M /x/img; mkfs.ext4 -q /x/img dev=$(losetup -f --show /x/img) mkdir /x/mp; mount $dev /x/mp echo $dev > /ready; read r < /go' & read dev < /ready rmdir /x echo > /go wait losetup -d $dev losetup -a Take a directory /x on the host, create a new mount namespace, mount a tmpfs on /x, use a file on that tmpfs as the backing file for a loop device, mount that loop device on that tmpfs. Now rmdir /x on the host. This will lazily unmount the mount on top of /x in the container with UMOUNT_CONNECTED. Once the namespace exits nothing references the mount anymore. Now the tmpfs is pinned by the backing file of the loop device and the loop mount is owned by the tmpfs superblock. Fun fact, such cycles can be formed by at least the following subsystems and I have added reproducers for all of them: (1) a loop mount P from an image on a tmpfs next to it, so that P's death shows as the loop device giving up its backing file (2) autofs with a FIFO on P as its pipe, zram with a device node on P as its writeback device, both on a minix image since vfat has neither (3) ecryptfs with its lower directory on P, under a passphrase token added to the session keyring (4) binfmt_misc in a new user namespace with an 'F' interpreter on P (5) a fuse server that answers FUSE_INIT with passthrough on and registers a file on P as a backing file (6) zloop with its zone files in a directory on P (7) a mass storage gadget on the dummy UDC with its LUN file on P, mounted from the SCSI disk the gadget shows up as (8) md with a RAID1 of one loop device and its bitmap file on P, which skips while SET_BITMAP_FILE has no way to succeed (9) rmdir of P's mountpoint from the parent, then the child exits, then the device must be free and LOOP_CLR_FD must release the file The underlying mechanism is UMOUNT_CONNECTED (MNT_LOCKED falls into the same class). With UMOUNT_CONNECTED an unmounted mount stays attached to its parent. This is used to protect revealing the underlying mount and is a non-negotiable security mechanism. So now the parent owns that mount and is put on the parent's final mntput(). That moves it to mnt_stuck_children and ultimately it's cleaned up by cleanup_mnt(). The fact that ownership of the child mount gets transferred to the parent turns every reference from a child's superblock back to one of its ancestors into a cycle. Don't keep the child attached at all. What the parent needs is that a lookup at the child's mountpoint keeps finding some mount, not the child itself and it's not a guarantee we have given really. When an unmounted mount would have stayed attached to its unmounted parent disconnect it like every other unmounted mount and leave a marker behind. A lookup on the parent that misses the mount hash and hits a marker finds knullfs. Either a file or a directory. Nothing leads from a marker to any other mount. The marker is owned by the parent and dropped by the parent's final mntput() or by __detach_mounts() when the mountpoint is deleted from under it. It is allocated together with the mount. With that every unmounted mount is a root and holds only its own reference which namespace_unlock() drops. No unmounted mount owns another one. A superblock that pins an ancestor can't form a cycle. It has a visible change. Mounts left connected (rmdir etc.) used to stay traversable through the parent for as long as something held the parent. Now it is detached with the umount. It lives as long as something references it but it isn't reachable through the parent anymore and ".." inside it leads nowhere which is the same as for every other lazily unmounted mount. Link: https://gist.github.com/mvo5/63ef46482349f3b1c3957d463a0c9c6f Link: https://patch.msgid.link/20261002-work-mount-cover-v1-2-232a8f52b43c@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 54867884fef503e7a4aaede93ef1bf540ab10b53 Author: Christian Brauner Date: Fri Oct 2 16:14:27 2026 +0200 nullfs: add an empty immutable regular file Add nullfs_new_file() to allocate an empty immutable regular file on a nullfs instance as a dentry of its own. It is never hashed under the root and so can't be found by lookup. Reads return nothing, changes are refused, file locks, leases and delegations are refused as. Link: https://patch.msgid.link/20261002-work-mount-cover-v1-1-232a8f52b43c@kernel.org Signed-off-by: Christian Brauner (Amutable) commit ab699d296e066eb64f51d2a8a1d42237a3b186c8 Merge: d5a007b9b457c9 ee2d4c2d7cc18a Author: Jakub Kicinski Date: Tue Oct 6 15:35:42 2026 -0700 Merge branch 'net-always-dissect-gso-packets-in-__virtio_net_hdr_to_skb' Eric Dumazet says: ==================== net: always dissect GSO packets in __virtio_net_hdr_to_skb() This series fixes a bypass of untrusted GSO flow dissection in __virtio_net_hdr_to_skb() when VIRTIO_NET_HDR_F_NEEDS_CSUM is not set, and adds a kselftest covering VLAN-tagged GSO packets without NEEDS_CSUM: - Patch 1 fixes __skb_flow_dissect(), which computes key_control->thoff with min_t(u16, ...). This truncates skb->len and returns a bogus small transport offset when skb->len modulo 65536 is smaller than the transport offset. Offsets that do not fit in the u16 thoff now fail the dissection instead of being silently truncated. - Patch 2 initializes skb->dev and skb->network_header before calling virtio_net_hdr_*_to_skb() in tun_get_user(), tun_xdp_one(), virtnet_receive_done(), and raw_verify_header(), removes the '&& skb->network_header' condition and the unvalidated 'else if (gso_type)' fallback in __virtio_net_hdr_to_skb(), and moves virtio_net_hdr_match_proto() after skb_flow_dissect_flow_keys_basic() so it validates the dissected L3 protocol (keys.basic.n_proto) rather than the outer L2 protocol. - Patch 3 adds kselftests in tools/testing/selftests/net/tun.c verifying that VLAN-tagged (802.1Q) TCPv4 GSO packets without NEEDS_CSUM (both flags = 0 and flags = VIRTIO_NET_HDR_F_DATA_VALID) are accepted on a TAP device, that mismatched GSO types and truncated TCP headers without NEEDS_CSUM are rejected with -EINVAL, and that a 65540-byte frame is accepted. ==================== Link: https://patch.msgid.link/20261001191140.2818991-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski commit ee2d4c2d7cc18a2cd504044a75ea614e720248eb Author: Eric Dumazet Date: Thu Oct 1 19:11:40 2026 +0000 selftests: net: tun: add test for VLAN-tagged GSO without NEEDS_CSUM Add selftests in tun.c verifying that a VLAN-tagged (802.1Q) TCPv4 GSO packet without VIRTIO_NET_HDR_F_NEEDS_CSUM (both flags = 0 and flags = VIRTIO_NET_HDR_F_DATA_VALID) is accepted when written to a TAP device (/dev/net/tun with IFF_TAP | IFF_NO_PI | IFF_VNET_HDR). Also verify that the following are rejected with -EINVAL: - a mismatched GSO type (VIRTIO_NET_HDR_GSO_TCPV6 on a VLAN-tagged IPv4 packet). - a frame whose TCP header is truncated after 10 bytes. Pulling only sizeof(struct iphdr) + sizeof(struct tcphdr) bytes would accept it, so this requires the transport offset found by flow dissection. Finally, verify that a 65540-byte frame is accepted. Its skb->len is above U16_MAX while it is flow-dissected, before eth_type_trans() pulls the Ethernet header. Based on a reproducer by Michael S. Tsirkin . Signed-off-by: Eric Dumazet Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20261001191140.2818991-4-edumazet@kernel.org Signed-off-by: Jakub Kicinski commit 44378d02c5aaae24b60a75fbbb539b4aa4db503d Author: Eric Dumazet Date: Thu Oct 1 19:11:39 2026 +0000 net: always dissect GSO packets in __virtio_net_hdr_to_skb() Commit 9e8db5913264 ("net: avoid false positives in untrusted gso validation") added a '&& skb->network_header' check before flow-dissecting GSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM in __virtio_net_hdr_to_skb(), because some callers (such as tun_get_user(), tun_xdp_one(), virtnet_receive_done(), and raw_verify_header()) called virtio_net_hdr_*_to_skb() before initializing skb->network_header and skb->dev. Because __alloc_skb() and __build_skb_around() zero-initialize skb->network_header to 0 (unlike mac_header and transport_header which are initialized to ~0U), those four callers always had skb->network_header == 0 and bypassed flow dissection in __virtio_net_hdr_to_skb(). More generally, skb->network_header is an offset from skb->head (where 0 is also a valid offset whenever skb_headroom(skb) is 0), not a boolean flag. Whenever the 'if (gso_type && skb->network_header)' branch was skipped, the fallback 'else if (gso_type)' only pulled nh_min_len + thlen (40 bytes for TCPv4) without dissecting the packet, without validating ip_proto or n_proto, and without setting skb->transport_header. If the packet has a malformed network header, it is not rejected and a subsequent skb_probe_transport_header() also fails, leaving skb->transport_header at ~0U (0xffff). Similarly, if an IPv4 packet carries IP options (ihl > 5) or an IPv6 packet carries extension headers, pulling only nh_min_len + thlen can leave the TCP header outside skb->head. In both cases, tcp_hdrlen(skb) in skb_gso_transport_seglen() reads out-of-bounds: BUG: KASAN: slab-out-of-bounds in skb_gso_transport_seglen Read of size 2 by task poc/133 skb_gso_transport_seglen (net/core/gso.c:155) skb_gso_validate_mac_len (net/core/gso.c:270) tbf_enqueue (net/sched/sch_tbf.c:260) dev_qdisc_enqueue (net/core/dev.c:4227) __dev_queue_xmit (net/core/dev.c:4884) In addition, checking virtio_net_hdr_match_proto() only inside 'if (!skb->protocol)' before flow dissection both skipped validation when skb->protocol was pre-set by the caller and rejected VLAN-tagged frames whose outer L2 protocol is ETH_P_8021Q or ETH_P_8021AD. Fix this by: 1. Initializing skb->dev and skb->network_header (plus skb->protocol for IFF_TUN) before virtio_net_hdr_*_to_skb() in tun_get_user(), tun_xdp_one(), virtnet_receive_done(), and raw_verify_header(). In tun_get_user(), drop the redundant skb_reset_mac_header(skb) in the IFF_TUN case since __virtio_net_hdr_to_skb() unconditionally resets mac_header. 2. Removing '&& skb->network_header' and the unvalidated 'else if (gso_type)' fallback in __virtio_net_hdr_to_skb() so all GSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM are flow-dissected, have their transport header pulled into linear data, and have skb->transport_header set. 3. Moving the virtio_net_hdr_match_proto() check to after skb_flow_dissect_flow_keys_basic(), validating keys.basic.n_proto against hdr_gso_type. Fixes: 9e8db5913264 ("net: avoid false positives in untrusted gso validation") Fixes: d5be7f632bad ("net: validate untrusted gso packets without csum offload") Fixes: 924a9bc362a5 ("net: check if protocol extracted by virtio_net_hdr_set_proto is correct") Reported-by: Weiming Shi Closes: https://lore.kernel.org/netdev/20260927163117.746432-2-bestswngs@gmail.com/ Signed-off-by: Eric Dumazet Reviewed-by: Willem de Bruijn Cc: Michael S. Tsirkin Link: https://patch.msgid.link/20261001191140.2818991-3-edumazet@kernel.org Signed-off-by: Jakub Kicinski commit 99bda1ecbd56905f8bd934b9cdccd3bd251192b1 Author: Eric Dumazet Date: Thu Oct 1 19:11:38 2026 +0000 flow_dissector: avoid u16 truncation of skb->len when computing thoff __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 commit b8eb5fd5bdb4c03758b056c70e5e1d962ca89757 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() 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 commit 28c2388ee24cdbefbcc458fa41ef7bffaaa1cc83 Author: Abhishek Ojha Date: Tue Sep 1 21:07:01 2026 -0400 regulator: ltc3676: don't read the write-only HRST and CLIRQ registers 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 commit 61d44a2c07b2ad3f7db167f17ff2461ffe78441c Author: Han Gao Date: Thu Oct 1 02:22:51 2026 +0800 spi: sg2044-nor: Honor SPI clock limits 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 commit e130c54fbb603f9aeacf5029789b4a2c8c48f416 Author: Han Gao Date: Thu Oct 1 02:22:50 2026 +0800 spi: sg2044-nor: Return transfer errors 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 commit 7529254014764ae0b8c33d5c61a58f36c65b1a1c Author: Marek Szyprowski Date: Fri Oct 2 11:21:12 2026 +0200 ASoC: samsung: i2s: enable op_clk in probe to balance runtime PM 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 commit 90abb0eba21b765f3a0539f451ab0ec0e8730258 Merge: d0cb7a7b2a490c 36d0e05815ce84 Author: Mark Brown Date: Tue Oct 6 17:21:05 2026 +0200 ASoC: adau1372: two small bugfixes for the codec Link: https://patch.msgid.link/20261006-asoc-adau1372-fixes-v1-0-599cc17fb5f6@analog.com commit 36d0e05815ce84266c8b138cd4f84c3feeaf15f4 Author: Alvin Šipraga Date: Tue Oct 6 14:55:57 2026 +0200 ASoC: adau1372: fix invalid default state of output ASRC and DAC muxes 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 commit 64dd172bbffe6135d79a06ddad53dd2da4d8bd62 Author: Alvin Šipraga Date: Tue Oct 6 14:55:56 2026 +0200 ASoC: adau1372: allow sleepy powerdown GPIOs 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 commit 69f80fef3153299d9c72c53d1d71eef6354b6926 Merge: 22430ae5d90ab2 bc8ce2cea5f77c Author: Linus Torvalds Date: Tue Oct 6 16:10:57 2026 +0200 Merge tag 'ata-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fix from Niklas Cassel: - Set CHECK CONDITION for failed ATAPI commands. Since commit 2e1d2e65e773 ("ata: libata-scsi: terminate deferred commands on time out") failed ATAPI commands incorrectly stopped having CHECK CONDITION set for commands that had a SCSI midlayer byte set by scsi_check_sense(). SG_IO users therefore saw failed ATAPI commands as successful (Hengyu) * tag 'ata-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: libata-scsi: do not lose CHECK CONDITION for failed ATAPI commands commit 05165f7b3b9ab6817fe216c24f90755b7c5e15f3 Author: Yingying Tang Date: Thu Jun 11 20:23:32 2026 -0700 Revert "wifi: ath12k: add panic handler" 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 commit 5e99bdb94720331e2fd38c10c5b1afa1ce640835 Author: David Carlier Date: Wed Aug 26 00:17:10 2026 +0100 wifi: nxpwifi: do not delete Rx reorder entries under RCU The RCU guard is declared in the body of the per-TID loop, so it is still held across the teardown pass. nxpwifi_del_rx_reorder_entry() flushes the Rx workqueue and deletes the reorder timer synchronously, both of which sleep, so a station deauthenticating from the AP splats under CONFIG_DEBUG_ATOMIC_SLEEP. Scope the guard to the collection walk. The teardown does not need RCU: it serialises on priv->rx_reorder_tbl_lock[] and frees with kfree_rcu(). Fixes: 73b01e57ed3e ("wifi: nxp: add nxpwifi driver for IW61x") Assisted-by: Claude:claude-opus-5 Signed-off-by: David Carlier Signed-off-by: Jeff Chen commit 32d1a000e99612e010335760363936d85591fd69 Author: David Carlier Date: Wed Aug 26 00:17:09 2026 +0100 wifi: nxpwifi: fix inverted check in Tx BA stream entry deletion nxpwifi_is_tx_ba_stream_ptr_valid() returns true when the entry is still linked, and every caller passes an entry that is on the list, so the early return always fires and nothing is ever unlinked or freed. Entries leak on every teardown and, since nxpwifi_space_avail_for_new_ba_stream() counts them, Tx aggregation stops being negotiated once the stale count reaches the maximum. Changing the original dead && test to || to silence a NULL dereference report inverted the validity test along with it. Fixes: 00c786a7581e ("wifi: nxpwifi: fix multiple static analysis errors and warnings") Assisted-by: Claude:claude-opus-5 Signed-off-by: David Carlier Signed-off-by: Jeff Chen commit 7fa5fb9976c4532007a666624dc241021f74c8a9 Author: Linmao Li Date: Thu Aug 20 16:16:34 2026 +0800 wifi: nxpwifi: handle authentication frame allocation failures nxpwifi_cfg80211_authenticate() allocates the buffer it builds the management frame in and never checks the result: mgmt = kzalloc(frame_len, GFP_KERNEL); skb = dev_alloc_skb(...); if (!skb) { ... return -ENOMEM; } ... memcpy(mgmt->da, req->bss->bssid, ETH_ALEN); On allocation failure the memcpy() a dozen lines later dereferences NULL. The same sequence leaks mgmt when dev_alloc_skb() fails: that path returns without freeing it, while the success path drops it after nxpwifi_form_mgmt_frame(). Bail out when the allocation fails, and free it before returning on the skb error path. Fixes: 73b01e57ed3e ("wifi: nxp: add nxpwifi driver for IW61x") Signed-off-by: Linmao Li Signed-off-by: Jeff Chen commit 7769bb2457fcfa8216aeae84f32cb7084cab5637 Author: Linmao Li Date: Thu Aug 20 16:16:33 2026 +0800 wifi: nxpwifi: fix the authentication frame length handling nxpwifi_cfg80211_authenticate() builds a 3-address management frame in a temporary buffer and hands it to nxpwifi_form_mgmt_frame(), which copies it into the skb and splices in address4. The frame length is tracked in a single u16 that conflates the two lengths, and it gets both wrong. Truncation. req->ie_len and req->auth_data_len are both size_t. The IE policy caps req->ie_len at IEEE80211_MAX_DATA_LEN, but NL80211_ATTR_AUTH_DATA only has a four-byte minimum length policy. Since nla_len is a u16, a single authentication data attribute can carry up to 65531 bytes, enough for the combined frame length to exceed U16_MAX before it is assigned to pkt_len. With auth_data_len == 65510 and no IEs the length wraps to 6, kzalloc(6) succeeds, and the memcpy() below then writes 65506 user-provided bytes past a 6-byte heap object. Geometry. NXPWIFI_MGMT_HEADER_LEN is 30, which is the 24-byte 3-address header plus the address4 that the firmware expects. The temporary buffer only holds a struct ieee80211_hdr_3addr, so six of the bytes accounted for are never used, and passing that length to nxpwifi_form_mgmt_frame() makes it append ETH_ALEN on top of a length that already included it. The skb is sized without those six bytes, so the last skb_put_data() overruns the tailroom by exactly ETH_ALEN. It usually goes unnoticed because SKB_DATA_ALIGN() rounding leaves slack. The driver's other caller of the helper, nxpwifi_cfg80211_mgmt_tx(), adds ETH_ALEN to the skb size before allocating and passes the 3-address length, which is what this path should do too. Keep the two lengths apart. frame_len is the 3-address frame the driver builds: it sizes the temporary buffer and is what the helper is told. pkt_len is what the firmware sees, frame_len plus address4: it sizes the skb and goes into tx_info. Computing frame_len in size_t and rejecting anything that cannot be represented once ETH_ALEN is added removes the wrap. The value handed to the firmware is unchanged, so this is not a behavioural change for frames that were already valid. A tighter 802.11 bound may make sense, but that depends on the firmware's frame format and is a separate decision. Fixes: 73b01e57ed3e ("wifi: nxp: add nxpwifi driver for IW61x") Signed-off-by: Linmao Li Signed-off-by: Jeff Chen commit 050f03bb0effd773c877cfba3b651c6d380b1c15 Author: Linmao Li Date: Thu Aug 13 16:23:15 2026 +0800 wifi: nxpwifi: zero the channel statistics array adapter->chan_stats comes from vmalloc(), which does not clear the memory, and nxpwifi_cfg80211_dump_survey() reads it as soon as user space asks for survey data. For the entries no scan has filled in, a non-zero cca_scan_dur passes the validity check and stale bytes are reported to user space as noise, time and time_busy. Use kcalloc() instead. The array holds two entries per supported channel, small enough not to need vmalloc(), and the two callers change to kfree() accordingly. mwifiex fixed the same issue in commit 0e20450829ca ("wifi: mwifiex: Initialize the chan_stats array to zero"). Fixes: 73b01e57ed3e ("wifi: nxp: add nxpwifi driver for IW61x") Signed-off-by: Linmao Li Reviewed-by: Jeff Chen Signed-off-by: Jeff Chen commit d68d6d8d8bbb5596909479dc6cac58132d8f0dbf Author: Linmao Li Date: Thu Aug 13 16:23:14 2026 +0800 wifi: nxpwifi: free the aggregation buffer when the RA list disappears nxpwifi_11n_aggregate_pkt() drops ra_list_spinlock while it copies each subframe, so it rechecks the RA list after taking the lock again. The check inside the aggregation loop returns without releasing the skb_aggr it has been filling, leaking one tx_buf_size buffer along with the subframes already aggregated into it. Release skb_aggr there, the way the same check on the -EBUSY path already does. mwifiex fixed the same issue in commit 990a73dec3fd ("wifi: mwifiex: Fix memory leak in mwifiex_11n_aggregate_pkt()"). Fixes: 73b01e57ed3e ("wifi: nxp: add nxpwifi driver for IW61x") Signed-off-by: Linmao Li Reviewed-by: Jeff Chen Signed-off-by: Jeff Chen commit 5c9260d7c6990875fc788ebb86ea2bf08b492704 Author: Linmao Li Date: Thu Aug 13 16:23:13 2026 +0800 wifi: nxpwifi: wait for the wakeup timer before the adapter is freed nxpwifi_adapter_cleanup() stops adapter->wakeup_timer with timer_delete(), which does not wait for a running callback. The callback goes on using the adapter: wakeup_timer_fn() sets adapter->hw_status, walks the command queues through nxpwifi_cancel_all_pending_cmd() and calls adapter->if_ops.card_reset(). Both paths that reach nxpwifi_adapter_cleanup() free the adapter right afterwards, through nxpwifi_free_adapter() in nxpwifi_remove_card() and in the nxpwifi_add_card() error unwind. Use timer_delete_sync() so the callback has finished before the adapter is released. mwifiex fixed the same issue in commit ae5e95d41574 ("wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup()"). Fixes: 73b01e57ed3e ("wifi: nxp: add nxpwifi driver for IW61x") Signed-off-by: Linmao Li Reviewed-by: Jeff Chen Signed-off-by: Jeff Chen commit 128411832c62ca517e4abd938229f0ee40823fdb Author: Linmao Li Date: Fri Aug 7 21:25:54 2026 +0800 wifi: nxpwifi: delete the station entry on the uAP deauth event When a station leaves, the firmware reports EVENT_UAP_STA_DEAUTH. nxpwifi_uap_event_sta_deauth() tears down the reorder, BA and WMM state for that peer but leaves its nxpwifi_sta_node on priv->sta_list. Nothing else removes it. cfg80211_del_sta() only reports the departure upwards, it does not call back into cfg80211_ops.del_station, and that callback is the only caller of nxpwifi_del_sta_entry(). The entry therefore survives until the BSS goes idle and nxpwifi_del_all_sta_list() drops everything. Until then the departed station still looks associated to the driver. nxpwifi_handle_uap_rx_forward() finds the stale node for that address, treats the frame as intra-BSS traffic and requeues it for transmission instead of passing it up the stack, so traffic for that address is misrouted. The list also keeps one entry per station that has ever associated, and a station that comes back reuses the stale node along with its old statistics. mwifiex, which nxpwifi was derived from, deletes the entry in the same event handler. Fixes: 73b01e57ed3e ("wifi: nxp: add nxpwifi driver for IW61x") Signed-off-by: Linmao Li Tested-by: Jeff Chen Reviewed-by: Jeff Chen Signed-off-by: Jeff Chen commit ff9b465ddb95d7842282998348df88ff55f62c4a Author: Linmao Li Date: Fri Aug 7 21:25:53 2026 +0800 wifi: nxpwifi: protect sta_list against concurrent add and delete nxpwifi_del_sta_entry() unlinks an entry from priv->sta_list without holding priv->sta_list_spinlock. The comment above it gives the reason: the function is only reached from cfg80211_ops.del_station, which runs under the wiphy mutex. That mutex serialises this callback against other users of the same lock, including wiphy_work items. It covers neither of the two other writers of the same list: nxpwifi_add_sta_entry() from nxpwifi_uap_event_sta_assoc() nxpwifi_del_all_sta_list() from nxpwifi_uap_event_bss_idle() Both run from nxpwifi_process_event() on the driver's main work queue, a plain workqueue that never takes the wiphy lock, and both take sta_list_spinlock around their update. A station associating, or the BSS going idle, can therefore modify priv->sta_list while a hostapd del_station is walking it and unlinking an entry. Take the lock here too. As the traversal then runs under the write lock, list_for_each_entry() replaces the _rcu variant, matching nxpwifi_del_all_sta_list(). The same call path reaches nxpwifi_get_sta_entry() without rcu_read_lock(). Entries are freed with kfree_rcu() and every other caller holds it, so take it around the lookup as well. Fixes: 73b01e57ed3e ("wifi: nxp: add nxpwifi driver for IW61x") Signed-off-by: Linmao Li Tested-by: Jeff Chen Reviewed-by: Jeff Chen Signed-off-by: Jeff Chen commit f0a4447789ef28ba1aded2db19543d69c640b5e5 Author: Mallesh Koujalagi Date: Thu Sep 24 11:39:07 2026 +0530 drm/xe/sysctrl: Fix mailbox header handling The mailbox header was defined as __le32, which required cpu_to_le32() and le32_to_cpu() conversions whenever it was write or read. These conversions are unnecessary because the header is always handled as a 32-bit value, not as raw bytes. It is written with xe_mmio_write32() and read with xe_mmio_read32(), which already handle any required byte-order conversion through the underlying writel()/readl() accessors. As a result, the header value is already in CPU byte order when used by the driver. Keeping the extra conversions had no effect on little-endian systems and could cause an incorrect on big-endian systems. So use u32 for the mailbox header and remove the unnecessary endianness conversions. Fixes: 1f95f618182b ("drm/xe/xe_sysctrl: Add System Controller mailbox communication support") Suggested-by: Michal Wajdeczko Signed-off-by: Mallesh Koujalagi Tested-by: Anoop Vijay Reviewed-by: Umesh Nerlige Ramappa Signed-off-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260924060900.146167-18-mallesh.koujalagi@intel.com (cherry picked from commit 5137b391599579371c32f555958d3cf55e19bd88) Signed-off-by: Rodrigo Vivi commit 5346b1cec6afa4f9b4b49a9f84e3cfef95a3f7bb Author: Krzysztof Karas Date: Thu Sep 10 08:13:29 2026 +0000 drm/i915/gt: Unmask interrupts only when ACTIVE is true 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 commit ebe162db655881a38de43301151ff7ac940602b5 Author: Krzysztof Karas Date: Fri Sep 11 06:11:45 2026 +0000 drm/i915/gem: Prevent overstepping exec array boundary 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 commit 71ec70ea26e399eb8371fe9d2d5bf5dab09570fb 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 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 commit 52f6a065e0810c739a5dabd33a58047f08100f50 Author: Lu Huang Date: Wed Sep 30 16:54:35 2026 +0800 wifi: mt76: mt7996: fix uninitialized buf read in mt7996_variant_fem_init() 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 commit af97bf5a7e72da9026de184676df8e2fa57e1058 Author: Devin Wittmayer Date: Fri Sep 4 18:35:51 2026 -0700 wifi: mt76: mt792x: pick the SAR table layout from the table itself 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 commit 45f53d98cbaa078907b6a300ff3974dfb5ae8776 Author: Junjie Cao Date: Thu Sep 10 09:23:00 2026 +0800 wifi: mt76: mt792x: treat 0xff ACPI SAR entries as no limit 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 commit 456de496b53ae73e6e3020fec815dbdc88aa7c07 Author: Cristian Papa Date: Thu Sep 3 22:07:02 2026 -0300 wifi: mt76: mt7603: initialize global station WCID 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 commit 5796b2bf9ff718342773ac760d86eb126c112a4f Author: Devin Wittmayer Date: Thu Sep 10 19:44:28 2026 -0700 wifi: mt76: mt7925: don't put the band auto marker in TGID 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 commit 916c484d29d82f45c281da2786fcd6a1284430ce Author: Nicolas Cavallari Date: Mon Aug 10 17:45:10 2026 +0200 wifi: mt76: mt7915: disable rx napi when removing device 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 commit 9c9e4e4c8b45873e53774ab8207825b37b7565ec 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 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 commit 8f9e5807671ee97cacf1957f4a09e43f4f1017a9 Author: Aaron Ma Date: Wed Aug 26 12:36:58 2026 +0800 wifi: mt76: mt7925: restore the legacy BSS after MLO teardown 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 commit 7c2e6b43c3082c2242ecfa5875b2b4b2cd06140f Author: Felix Fietkau Date: Tue Sep 1 11:22:32 2026 +0200 wifi: mt76: use ALTX queue for packets to disassociated stations 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 commit 752770d7a58c821c17909c3ca67f9f14ab146a40 Author: Felix Fietkau Date: Tue Aug 18 12:58:25 2026 +0000 wifi: mt76: account non-AQL frames per peer rather than per link 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 commit 0ec14f8c8c5da1c9c314bce4f0bf53c009fbc998 Author: Felix Fietkau Date: Tue Aug 18 12:58:23 2026 +0000 wifi: mt76: mt7996: take over connection monitoring mt76 runs its own beacon monitor. mt76_beacon_mon_check() counts a miss for each affiliated link of an MLD, and it stops the count while the phy is off channel. mt7996 supplies it through mt76_rx_beacon(), but it does not set CONNECTION_MONITOR. Therefore mac80211 also starts its legacy monitor. The legacy monitor knows one interface, not a set of links. It also counts while the radio serves a different link. After seven beacon intervals it removes an association that still carries traffic on the other links. Set the CONNECTION_MONITOR flag to disable the legacy monitor. Fixes: 4df75606ece5 ("wifi: mt76: add per-link beacon monitoring for MLO") Link: https://patch.msgid.link/20260818125825.395538-3-nbd@nbd.name Signed-off-by: Felix Fietkau commit 22430ae5d90ab288b0ee2ad99ae941f4a666b694 Merge: 2c3418fffa9d03 c83e3d29124321 Author: Linus Torvalds Date: Tue Oct 6 11:32:54 2026 +0200 Merge tag 'printk-for-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux Pull printk fix from Petr Mladek: - Allow using Braille console with a serial console driver converted to NBCON API * tag 'printk-for-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux: braille: nbcon: Allow to use a serial console with NBCON API as Braille console commit 709ba1c547eaf37da36ded2ecf3ea4e304cdfa9a Author: Adriel Santos Date: Fri Oct 2 13:09:58 2026 -0300 pinctrl: qcom: ipq5018: replace gcc_plltest with pwm2 on gpio12 The pingroup table has gcc_plltest at function 5 of gpio12 and does not offer pwm2 on that pin, so the pinmux core rejects a request for pwm2 on gpio12 as an invalid group. On the hardware, function 5 of gpio12 carries the PWM2 output: the Xiaomi AX3000T v2 drives its blue status LED from PWM2 on gpio12. The vendor kernel shipped on that router (Linux 4.4, stock firmware 2.0.28) has pwm2 in this slot. Its pingroup table, as read from the firmware image, lists these functions for gpio12: gpio, blsp0_spi, blsp0_i2c, blsp1_uart0, _, pwm2, qdss_tracedata_a, _, _, _ and has pwm3 at function 4 of gpio13, matching commit c6c159fcdb4e ("pinctrl: qcom: ipq5018: add missing pwm3 function on gpio13"). Measured on the board: with gpio12 set to each of the 16 function values in turn, and PWM2 held at 0% and then at 100% duty, the pad level read back from GPIO_IN follows PWM2 only at function 5. There it does not follow PWM channels 0, 1 or 3, and the LED switches with PWM2. Functions 4 and 7, which the table leaves empty, do not carry PWM2. Put pwm2 in function 5 of gpio12 and list gpio12 in pwm2_groups. Drop gpio12 from gcc_plltest_groups: none of its functions is gcc_plltest any more, and selecting it would trigger the WARN_ON() in msm_pinmux_set_mux(). Fixes: 725d1c891658 ("pinctrl: qcom: Add IPQ5018 pinctrl driver") Assisted-by: LLM Signed-off-by: Adriel Santos Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20261002160958.908424-1-adriel@adriel.eu Signed-off-by: Bartosz Golaszewski commit 2c3418fffa9d037b2038a6db48be63f9e2291806 Merge: 67f0943b394d92 dd3ea3fcba7c75 Author: Linus Torvalds Date: Tue Oct 6 04:51:54 2026 +0200 Merge tag 'keys-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd Pull keys fixes from Jarkko Sakkinen: - key_get_persistent() created a new persistent keyring if one did not exist, but failed to set a timeout on it in an error path, preventing GC. Call key_set_timeout() regardless of key_link() result if a persistent keyring was created. - __key_create_or_update() made a copy of keyring->restrict_link before holding keyring->sem, which could cause add_key() to be executed against stale keyring restrictions. Fix it by copying the value only after taking keyring->sem * tag 'keys-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: KEYS: Fix add_key() race with keyring restriction keys: finalize persistent keyring timeout after link attempt commit 469fa055664bfd8717b087a80d59c03055789c17 Author: Stanley Jhu Date: Mon Sep 28 11:58:16 2026 +0800 scsi: ufs: core: Decouple CQ sweep from request iterator in MCQ In MCQ mode, ufshcd_mcq_compl_pending_transfer() uses blk_mq_tagset_busy_iter() to iterate over busy requests during error recovery and host reset. However, both iterator callbacks perform whole-queue operations redundantly for each visited request: - force_compl == true: ufshcd_mcq_force_compl_one() calls ufshcd_mcq_compl_all_cqes_lock() on every busy request, sweeping the entire completion ring (hwq->max_entries slots) once per active request under spin_lock_irqsave even though the first sweep already cleared all completion entries. - force_compl == false: ufshcd_mcq_compl_one() acquires cq_lock and polls CQTPy over MMIO via ufshcd_mcq_poll_cqe_lock() for every busy request without doing any per-request work. Sweep or poll each hardware queue (hba->uhq[i]) once at the start of ufshcd_mcq_compl_pending_transfer(). When force_compl is true, run blk_mq_tagset_busy_iter() afterward to complete residual in-flight requests with DID_REQUEUE, and remove the now-unused ufshcd_mcq_compl_one() callback. Fixes: ab248643d3d6 ("scsi: ufs: core: Add error handling for MCQ mode") Cc: stable@vger.kernel.org Reviewed-by: Bart Van Assche Signed-off-by: Stanley Jhu Reviewed-by: Peter Wang Link: https://patch.msgid.link/20260928035816.1294326-3-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) commit 375f3a5691dd46b5d05b90a8968872ec8b2248c5 Author: Stanley Jhu Date: Mon Sep 28 11:58:15 2026 +0800 scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock() During MCQ host reset, ufshcd_host_reset_and_restore() stops the host controller via ufshcd_hba_stop() (HCE = 0) before calling ufshcd_complete_requests(hba, true) -> ufshcd_mcq_compl_pending_transfer(hba, true) -> ufshcd_mcq_force_compl_one() -> ufshcd_mcq_compl_all_cqes_lock(). Because ufshcd_mcq_force_compl_one() is its sole caller, ufshcd_mcq_compl_all_cqes_lock() always runs with HCE = 0. Despite the comment above ufshcd_mcq_compl_all_cqes_lock() stating that reading CQTPy may not be safe with the controller disabled, the function still calls ufshcd_mcq_update_cq_tail_slot() at the end of its sweep: 1. Unsafe CQTPy MMIO read: Calling ufshcd_mcq_update_cq_tail_slot() at the end of the sweep reads CQTPy over MMIO while HCE = 0, directly contradicting the function's documented contract (commit 1373df88d535 ("scsi: ufs: core: Add a comment block above ufshcd_mcq_compl_all_cqes_lock()")) that reading CQTPy may not be safe with the controller disabled. 2. Spurious error logs on empty slots: Sweeping all max_entries slots visits empty entries where command_desc_base_addr is 0, causing ufshcd_mcq_process_cqe() to log unguarded dev_err(hba->dev, "Abnormal CQ entry!\n") messages. Fix both issues in ufshcd_mcq_compl_all_cqes_lock(): - Remove the ufshcd_mcq_update_cq_tail_slot() call and the redundant hwq->cq_head_slot = hwq->cq_tail_slot assignment without replacement. The two indices are already equal after the sweep: they are equal when the sweep starts, since ufshcd_mcq_poll_cqe_lock() consumes entries until cq_head_slot reaches cq_tail_slot, and the sweep advances cq_head_slot by exactly one full ring. Both indices are also reinitialized before the queue is reused. - Extract ufshcd_mcq_compl_cqe() and invoke it only on non-empty slots during full-ring sweeps, keeping "Abnormal CQ entry!" logging strictly for unexpected empty entries in ufshcd_mcq_poll_cqe_lock(). Fixes: ab248643d3d6 ("scsi: ufs: core: Add error handling for MCQ mode") Cc: stable@vger.kernel.org Reviewed-by: Peter Wang Signed-off-by: Stanley Jhu Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260928035816.1294326-2-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) commit 27c0f718d3b3c99e6d315308e95d987d0382a8a8 Author: Ahmed Abdelhaleem Ahmed Date: Tue Sep 22 15:46:46 2026 +0000 scsi: ch: Do not keep references to data transfer element devices ch_readconfig() looks up the scsi_device of every data transfer element whose SCSI id the changer reports in READ ELEMENT STATUS, and stores it in ch->dt[]. scsi_device_lookup() takes a reference, and nothing ever drops it: ch_destroy() frees the array with kfree(). ch->dt[] is read nowhere else - it only supplies the vendor, model and revision printed in the same loop. Once such a drive is removed, its scsi_device can never be released. It stays on the host's device list at its address, so a new device there is refused by anything that walks the list - target_core_pscsi reports "scsi_device_get() failed for H:C:T:L" - and the low-level driver's module can no longer be unloaded. Only a reboot recovers. It shows with any changer that reports its drives' ids; with the mhvtl virtual library (IBM 3573-TL personality), each create and remove of a library with four drives leaves four references behind, counted by the module's use count in lsmod. With ch not bound the count is unchanged, and with this patch applied it is unchanged too. Drop the reference as soon as the name has been printed, and remove the now unused dt[] array. That also removes the array leaked when ch_probe() fails after ch_readconfig(). The same leak was reported with an RFC patch in 2022, which was not merged. Fixes: daa6eda65a53 ("[SCSI] add scsi changer driver") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-scsi/20220719075442.6215-1-yanghao_ht@163.com/ Signed-off-by: Ahmed Abdelhaleem Ahmed Reviewed-by: Laurence Oberman Fixes: daa6eda65a53 ("[SCSI] add scsi changer driver") Link: https://patch.msgid.link/20260929-ch-dt-leak-v2-1-ddda8d635dca@gmail.com Signed-off-by: Martin K. Petersen (Oracle) commit 78e04810542da416d3bead707b60cec773f1524d Author: Pengpeng Hou Date: Sun Sep 20 11:49:53 2026 +0800 scsi: ufs: mediatek: Handle mPHY power-on failures The MediaTek helper enables VA09 before powering on the mPHY, but ignores the PHY result. A failure can leave VA09 enabled and publish mphy_powered_on as true, so a later power-on attempt is skipped. Check phy_power_on(), attempt to unwind VA09 on failure, and leave the state flag unchanged. Propagate the helper result from host initialization as well as its existing resume caller. Keep the original PHY error if the supply rollback also fails, and report that rollback separately. The issue was found by our static-analysis tool. Fixes: 561e3a8726b2 ("scsi: ufs-mediatek: Fix unbalanced clock on/off") Fixes: cf137b3ea49a ("scsi: ufs-mediatek: Support VA09 regulator operations") Assisted-by: gpt 5 Signed-off-by: Pengpeng Hou Reviewed-by: Peter Wang Reviewed-by: Stanley Jhu Link: https://patch.msgid.link/20260920034953.19535-1-hppiscas@163.com Signed-off-by: Martin K. Petersen (Oracle) commit d5a007b9b457c915ab1a53227e8939e4018aa97a Author: Jakub Kicinski Date: Mon Oct 5 18:19:20 2026 -0700 Revert "net: stmmac: propagate PTP addend and system time programming errors" This reverts commit 232d49dd4b40a666283de9e722899f088ed581b2. Anirudh reports a regression from this change. It is not appropriate for net this late in the release cycle in the first place, so let's revert and revisit in net-next. Reported-by: Anirudh Srinivasan Link: https://lore.kernel.org/CAEev2e8+fr1tJnSErD+2TtLDw5fGJbQOMcM5eefMnLyFUR+m7w@mail.gmail.com Fixes: 232d49dd4b40 ("net: stmmac: propagate PTP addend and system time programming errors") Signed-off-by: Jakub Kicinski commit 282f4a8aa95c5a01b96e55eb5da297560e5f2986 Author: Shao Mingyin Date: Mon Oct 5 19:02:38 2026 -0600 riscv: lib: Fix ZBB strnlen wrap-around regression on huge counts The aligned scan boundary is derived from the last valid byte, (s + count - 1). When count is huge (e.g. SIZE_MAX, which FORTIFY strcat/strlcat pass when the destination size is not known at compile time), s + count wraps around and the boundary lands before s, so the ZBB path returns a bogus length. The original implementation (5ba15d419fab) had the same wrap-around in its (s + count) & ~7 boundary computation; after 5d588c684833 the wrapped boundary is caught by the pre-loop guard "bgeu t0, t4, 2f", which then always exits for aligned strings of 8 or more characters and strnlen() returns 8 instead of the real length. This silently truncates strings built by fortified strcat: the dm sysfs name attribute shows "live-bas" instead of "live-base", the truncated name pollutes the udev database, and blivet/anaconda (as well as LVM/dm-crypt/multipath userspace) break on RISC-V systems. Detect the wrap-around and saturate the boundary to the top of the address space, making the scan equivalent to strlen(). The saturation clamps the increment to ~s, so it stays branchless and wrap-free: s + min(count - 1, ~s) == saturating_add(s, count - 1) Normal counts are unaffected. Fixes: 5ba15d419fab ("riscv: lib: add strnlen() implementation") Cc: stable@vger.kernel.org Suggested-by: David Laight Suggested-by: Qingfang Deng Signed-off-by: Shao Mingyin Acked-by: Michael Neuling Tested-by: Troy Mitchell Reviewed-by: Aurelien Jarno Link: https://patch.msgid.link/20260915152656708z04s4oSYY2BGj34F36RZa@zte.com.cn Signed-off-by: Paul Walmsley commit a510e1ae8c9030750c2edf7b0bc9b186cd8c7a06 Author: Wei-Jie Hung Date: Mon Oct 5 19:02:38 2026 -0600 riscv: patch: fix handling of bpf-jit execmem addresses Commit 8718e5a3090b ("riscv: patch: skip fixmap mapping when kernel text is already writable") gated the core_kernel_text() branch of patch_map() on CONFIG_STRICT_KERNEL_RWX, and explicitly left the vmalloc branch unchanged. That branch has a separate problem. That branch only creates a temporary writable fixmap alias when CONFIG_STRICT_MODULE_RWX is enabled, and otherwise assumes the target is directly writable and returns the address unchanged. That assumption no longer holds: bpf_prog_pack_alloc calls set_memory_rox() on every pack unconditionally in alloc_new_pack(), independently of any CONFIG_STRICT_*_RWX option, so BPF text in the vmalloc area is read-only regardless of what CONFIG_STRICT_MODULE_RWX says. With CONFIG_STRICT_MODULE_RWX=n, patch_map() returns the read-only address directly, the subsequent copy_to_kernel_nofault() takes a page fault and returns -EFAULT. bpf_arch_text_copy() turns that into -EINVAL, which propagates through bpf_jit_binary_pack_finalize() to the WARN_ON() in bpf_int_jit_compile() and leaves the program un-JITed. Note that BPF cannot be fixed the way kprobes was in commit bdc46e507b59 ("riscv: mm: make EXECMEM_KPROBES writable without CONFIG_STRICT_MODULE_RWX"). EXECMEM_BPF is already PAGE_KERNEL, i.e. writable at allocation time; the read-only mapping is established afterwards by generic code in alloc_new_pack(), which arch code cannot influence. The only place this can be handled is patch_map(). This is the same problem that was fixed on arm64 by commit b1480ed230ac ("arm64: patching: fix handling of execmem addresses"), and the fix is the same: CONFIG_EXECMEM is what actually tracks whether the vmalloc area can hold executable memory that needs a temporary alias to be written. CONFIG_BPF_JIT, CONFIG_KPROBES and CONFIG_MODULES all select it. Note that this is not limited to CONFIG_MODULES=n. Unlike arm64, riscv selects CONFIG_ARCH_OPTIONAL_KERNEL_RWX, so CONFIG_STRICT_MODULE_RWX can be disabled with CONFIG_MODULES=y as well, and the bug is reachable in that configuration too. The !CONFIG_MMU build is unaffected: it has its own __patch_insn_set() and __patch_insn_write() implementations and never calls patch_map(). Fixes: 2c9e5d4a0082 ("bpf: remove CONFIG_BPF_JIT dependency on CONFIG_MODULES of") Signed-off-by: Wei-Jie Hung Reviewed-by: Pu Lehui Tested-by: Pu Lehui Link: https://patch.msgid.link/20260914115607.350097-1-imbigking12@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley commit 6694612317e5225086e39ca1ba97ada2b1942e48 Author: Yong-Xuan Wang Date: Mon Oct 5 19:02:38 2026 -0600 RISC-V: Clear HSTATUS.HU on CPU initialization The RISC-V privileged specification does not mandate HSTATUS reset values, leaving the HU bit potentially set after hardware reset. When HU=1, hypervisor instructions (HLV/HLVX/HSV) can execute in U-mode to access guest memory, which may cause unintended behavior if not explicitly controlled. Clear HSTATUS.HU during CPU initialization to ensure hypervisor instructions are only available in HS-mode, preventing unexpected guest memory access from U-mode code. Signed-off-by: Yong-Xuan Wang Reviewed-by: Samuel Holland Link: https://patch.msgid.link/20260924-hstatus_hu-v2-1-7e970f5f1d8d@sifive.com Cc: stable@vger.kernel.org [pjw@kernel.org: capitalized RISCV_ISA_EXT_h to fix build; added stable cc] Signed-off-by: Paul Walmsley commit 148ab873d8194cb44f29474da3b4428fa2e100d1 Author: Yong-Xuan Wang Date: Mon Oct 5 19:02:38 2026 -0600 RISC-V: errata: Add SiFive MAL-9092 workaround SiFive cores with MAL-9092 require fence.rw instructions around HLV/HLVX/HSV hypervisor instructions to ensure proper memory ordering when accessing guest memory. Note that HSTATUS.HU is cleared during KVM initialization, restricting hypervisor instructions to HS-mode only. If future changes enable HSTATUS.HU for U-mode access, additional errata considerations will be needed. Signed-off-by: Yong-Xuan Wang Reviewed-by: Samuel Holland Link: https://patch.msgid.link/20260817-sifive-errata-v1-1-6a80f1a2743d@sifive.com Signed-off-by: Paul Walmsley commit 55b1276ef9c1c27e8a2b2c5e8ef0515b5ad0332c Author: Aurelien Jarno Date: Mon Oct 5 19:02:37 2026 -0600 riscv: vector: Fix output operands in context save 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 commit 572b25f3a6453d8e7fc28cc0cefe41ed15be166c Author: Troy Mitchell Date: Mon Oct 5 19:02:37 2026 -0600 riscv: vector: Fix data pointer constraints in context save/restore 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 commit 756724133bd3b89e097c92110221b44cafe0d06a Author: Arnd Bergmann Date: Mon Oct 5 19:02:37 2026 -0600 riscv: limit sifive errata to CONFIG_64BIT There are two errata for this vendor, and they both individually depend on CONFIG_64BIT already. However, an 32-bit allmodconfig produces this warning from clang for a condition that can never be true. arch/riscv/errata/sifive/errata.c:29:14: error: result of comparison of constant 9223372036854775815 with expression of type 'unsigned long' is always true [-Werror,-Wtautological-constant-out-of-range-compare] 29 | if (arch_id != 0x8000000000000007 || | ~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~ arch/riscv/errata/sifive/errata.c:42:14: error: result of comparison of constant 9223372036854775815 with expression of type 'unsigned long' is always true [-Werror,-Wtautological-constant-out-of-range-compare] 42 | if (arch_id != 0x8000000000000007 && arch_id != 0x1) | ~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~ Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260916083752.47310-1-arnd@kernel.org Signed-off-by: Paul Walmsley commit edba6017c19f97ecc718fad6b50e0908392247ac Author: Zongmin Zhou Date: Mon Oct 5 19:02:37 2026 -0600 riscv: hwprobe: use _BITULL() rather than BIT() in MIPS vendor uapi header 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 commit 7e170da2edec9fb0717543571cc14b0aabee2b46 Author: Leto Liu (刘涛) Date: Wed Sep 30 08:58:48 2026 +0200 net: airoha: Add retry mechanism to airoha_qdma_set_trtcm_param() CPU accesses QDMA via the bus. When multiple modules are using the bus simultaneously, CPU access to QDMA may encounter bus timeouts and fails, resulting in QDMA configuration failures and potentially causing packet transmission issues. In order to mitigate the issue, introduce a retry mechanism to airoha_qdma_set_trtcm_param routine in order to ensure the configuration is correctly applied to the hardware. It's enough to try a second time for the TRTCM config to be actually applied to make sure we are not in the middle of bucket handling as it does operate on fixed time slot internally. Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support") Signed-off-by: Leto Liu (刘涛) [ improve commit description, drop memory block, apply better loop logic] Signed-off-by: Christian Marangi Link: https://patch.msgid.link/20260930065855.46171-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski commit 73abd7db0c3f93d8968ce67b4d431a51200dc80f Merge: d4bfe16cbd1d05 0cb6939a4dfefa Author: Jakub Kicinski Date: Mon Oct 5 16:58:14 2026 -0700 Merge branch 'gve-various-xdp-fixes' Joshua Washington says: ==================== gve: various XDP fixes This patch series consists of a number of small XDP-related fixes. These changes are split off from https://lore.kernel.org/20260922194533.631387-1-joshwash@google.com in an effort to prevent blocking relatively simple fixes on more complex fixes that will need more feedback to merge. A summary of the changes: 1) fix an issue where XSK buffers that have not been processed are leaked when disabling XSK pools 2) fix an XSK buffer leak when an RX error descriptor comes back from the hardware 3) fix a deadlock introduced by attempting to acquire the netdev lock after it has already been acquired ==================== Link: https://patch.msgid.link/20260930214735.3288780-1-joshwash@google.com Signed-off-by: Jakub Kicinski commit 0cb6939a4dfefa822007b7a71986e06bc4f61f54 Author: Joshua Washington Date: Wed Sep 30 14:47:35 2026 -0700 gve: fix napi_disable deadlock when attempting to disable XSK pools 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 commit 9fed6a8ab8a5bacba2c709cb19d2dd6d2fa9112e Author: Joshua Washington Date: Wed Sep 30 14:47:34 2026 -0700 gve: fix XSK buffer leak on error descriptor 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 commit 73670ddb91a4d22e1deb3efd962242de1ec48e90 Author: Joshua Washington Date: Wed Sep 30 14:47:33 2026 -0700 gve: fix XSK buffer leak when rings are stopped 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 commit d4bfe16cbd1d05a8584b8604de28cb323cce1801 Merge: e3f33b0a1d89d7 da17990421d79f Author: Jakub Kicinski Date: Mon Oct 5 16:36:45 2026 -0700 Merge branch 'net-stmmac-fix-double-vlan-802-1ad-tag-handling' Ovidiu Panait says: ==================== net: stmmac: Fix double VLAN 802.1ad tag handling Currently, hardware VLAN stripping is broken for 802.1ad tags. vlan_rx_hw() hardcodes ETH_P_8021Q when putting the hardware tag into the skb, rather than using the actual protocol from the packet. Because of this, packets that contain an 802.1ad outer tag are incorrectly passed up the stack as having an 802.1Q tag. This issue was observed on the Renesas RZ/V2H platform (which has a dwmac4 IP), when testing QinQ ping: # DUT ip link add link end0 name end0.100 type vlan proto 802.1ad id 100 ip link add link end0.100 name end0.100.200 type vlan proto 802.1q id 200 ip addr add 172.16.3.2/24 dev end0.100.200 ip link set end0 up ip link set end0.100 up ip link set end0.100.200 up # Peer ip link add link eth0 name eth0.100 type vlan proto 802.1ad id 100 ip link add link eth0.100 name eth0.100.200 type vlan proto 802.1q id 200 ip addr add 172.16.3.1/24 dev eth0.100.200 ip link set eth0 up ip link set eth0.100 up ip link set eth0.100.200 up ping 172.16.3.2 -- FAIL -- Note that this series only fixes the issue on dwmac4. dwxgmac2 has the same issue but I do not have access to hw to test on. Since dwmac4 does not expose the tag type in the RDES3 descriptor, it cannot support hardware S-Tag stripping correctly. This series disables S-tag stripping for it, so the 802.1ad tags are left in place and are handled by the software VLAN path. ==================== Link: https://patch.msgid.link/20260928203441.34876-1-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski commit da17990421d79f1bfb4142f9d767fd33daecc3d8 Author: Ovidiu Panait Date: Mon Sep 28 20:34:41 2026 +0000 net: stmmac: Disable S-Tag processing on dwmac4 Currently, hardware VLAN stripping is broken for 802.1ad tags. vlan_rx_hw() hardcodes ETH_P_8021Q when putting the hardware tag into the skb, rather than using the actual protocol from the packet. Because of this, packets that contain a 802.1ad outer tag are incorrectly passed up the stack as having an 802.1Q tag. This causes QinQ ping between two hosts to fail. vlan_rx_hw() is shared by dwxgmac2 and dwmac4: on dwxgmac2 the tag type is available in the RDES3 write-back descriptor (the ET_LT field), so the outer tag type can be determined based on that info. However, dwmac4 doesn't seem to provide the tag type. The Length/Type field in RDES3 only indicates whether the packet is single or double-tagged, not which tag type was stripped. Since dwmac4 cannot report the stripped tag type, it cannot support hardware S-Tag stripping correctly. Therefore, restrict the NETIF_F_HW_VLAN_STAG_RX and NETIF_F_HW_VLAN_STAG_FILTER advertisement to dwxgmac2 only. With this, 802.1ad tags are left in place and handled by the software VLAN path. Fixes: 750011e239a5 ("net: stmmac: Add support for HW-accelerated VLAN stripping") Signed-off-by: Ovidiu Panait Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260928203441.34876-6-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski commit c63ce7b9c7e7b68267899e4a0fc14b35d2c1dfcc Author: Ovidiu Panait Date: Mon Sep 28 20:34:40 2026 +0000 net: stmmac: Do not advertise S-VLAN stripping when it is disabled C-VLAN and S-VLAN tag stripping are both controlled by the EVLS bit, so disabling rx-vlan-offload also disables S-VLAN tag stripping. However, rx-vlan-stag-hw-parse keeps being advertised as enabled: root@rzv2h-evk:~# ethtool -K end1 rx-vlan-offload off root@rzv2h-evk:~# ethtool -k end1 | grep -i vlan rx-vlan-offload: off tx-vlan-offload: off [fixed] rx-vlan-filter: on [fixed] vlan-challenged: off [fixed] tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: on [fixed] rx-vlan-stag-filter: on [fixed] Fix this inconsistency by making NETIF_F_HW_VLAN_STAG_RX follow NETIF_F_HW_VLAN_CTAG_RX. Fixes: 750011e239a5 ("net: stmmac: Add support for HW-accelerated VLAN stripping") Signed-off-by: Ovidiu Panait Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260928203441.34876-5-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski commit 354b07bc1dcaa94b40a5904159c1a53b33d7cf59 Author: Ovidiu Panait Date: Mon Sep 28 20:34:39 2026 +0000 net: stmmac: Rename double VLAN references to svlan The ESVL and DOVLTC bits control S-VLAN tag processing and have nothing to do with the double VLAN feature, which only provides a way to process an additional inner VLAN tag. However, the driver code that handles them always refers to "double VLAN", which is unrelated and makes the implementation confusing. The driver does not use any of the inner VLAN tag features, and the networking core does not support offloads for the inner tag anyway. To reduce the confusion regarding S-Tag vs double VLAN handling, rename double -> svlan. No functional change intended. Suggested-by: Joseph Steel Signed-off-by: Ovidiu Panait Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260928203441.34876-4-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski commit 69aa9e76677c97ba992df03a3c74d839470e7363 Author: Ovidiu Panait Date: Mon Sep 28 20:34:38 2026 +0000 net: stmmac: Stop toggling the EDVLP bit Currently, the double VLAN EDVLP bit is toggled whenever an 802.1ad VLAN is registered. This bit enables processing of the inner VLAN tag, which is completely unrelated to S-Tag VLAN handling. Move EDVLP handling into vlan_set_hw_mode() instead, and keep it always enabled, so that COE can work for packets with an inner VLAN header. Add a dedicated callback for dwxlgmac2, as it doesn't implement the set_hw_vlan_mode callback, like the other cores. Suggested-by: Joseph Steel Signed-off-by: Ovidiu Panait Link: https://patch.msgid.link/20260928203441.34876-3-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski commit 11705541e7d421706a54f7f6ead8a3316c91c2bc Author: Ovidiu Panait Date: Mon Sep 28 20:34:37 2026 +0000 net: stmmac: Remove VLAN perfect matching dead code stmmac_vlan_update() falls back to "perfect matching" when the VLAN hash filter is unavailable (!priv->dma_cap.vlhash). This fallback has been unreachable in normal operation since its introduction in commit c7ab0b8088d7 ("net: stmmac: Fallback to VLAN Perfect filtering if HASH is not available") because the NETIF_F_HW_VLAN_{CTAG,STAG}_FILTER features are advertised only when priv->dma_cap.vlhash is true. The fallback is also duplicating the code in vlan_add_hw_rx_fltr(), which is always available since stmmac_get_num_vlan() returns at least 1. Therefore, remove it. Signed-off-by: Ovidiu Panait Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260928203441.34876-2-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski commit e3f33b0a1d89d738e2b913dab519226eaf76e15b Author: Eric Dumazet Date: Thu Oct 1 22:12:53 2026 +0000 ipv4: free inet_opt and ireq_opt after an RCU grace period tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the child socket (newinet->inet_opt) without copying it. Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcp_check_req(). tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt under rcu_read_lock() only, and ip_build_and_send_pkt() and ip_options_build() then read opt->optlen twice. Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and inet_csk_reqsk_queue_drop() calls timer_delete_sync() before the child can be freed. Since commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table"), request sockets are processed without holding the listener lock, so nothing prevents the child socket from being freed while the SYNACK is still being built. TCP child sockets do not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt with a plain kfree(), leading to a use-after-free in ip_options_build(). A similar issue exists with request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program). reqsk_timer_handler() clones the request socket with inet_reqsk_clone(), so that the old request socket and its clone share the same ireq_opt, then reqsk_migrate_reset() clears the pointer in the old one. Another cpu holding a reference on the old request socket can still be using these options (sending a SYNACK, or creating a child in tcp_v4_syn_recv_sock()) when the clone is freed, and tcp_v4_reqsk_destructor() also uses a plain kfree(). Readers already use RCU, and other paths replacing inet_opt (do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use kfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor() as well. IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock() duplicates the options. tcp_v6_reqsk_destructor() has the same migration issue with ipv6_opt, which is only set by CALIPSO. This will be addressed in a separate patch. Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table") Fixes: c905dee62232 ("tcp: Migrate TCP_NEW_SYN_RECV requests at retransmitting SYN+ACKs.") Reported-by: Xinyang Ge Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20261001221253.2964024-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski commit fe4114221364899ab33c3f9574da6b108d3fa79e Author: Or Har-Toov Date: Wed Sep 30 20:04:06 2026 +0300 net/mlx5: Lag, split aggregate speed into oper and max helpers mlx5_lag_sum_devices_speed computes the LAG aggregate by summing oper speeds across all ports. This has two bugs. First, it relies on the assumption that a port whose carrier is down will report an oper speed of zero and therefore not contribute to the sum. This assumption does not always hold: when the link partner disconnects the port transitions to DOWN state but firmware may still report a non-zero oper speed, causing the aggregate to include a port that is not actively carrying traffic. Second, in active-backup mode only one port transmits at a time, so the aggregate should reflect a single port speed rather than the sum of all ports. Fix this by splitting mlx5_lag_sum_devices_speed into two helpers. mlx5_lag_get_devices_oper_speed reflects the speed currently available: it queries the vport state of each port and skips any port that is not UP, rather than relying on oper speed being zero. mlx5_lag_get_devices_max_speed is state-independent and returns the maximum achievable speed used as a fallback when speed is 0; for active-backup it takes the maximum single-port speed instead of the sum. The bugs were discovered during integration and reproduced on a back-to-back ConnectX-8 setup. The first bug (stale oper speed when link goes down) was observed: after the link partner disconnected, the aggregate TX speed reported to vports remained full speed because firmware still returned the last oper speed, causing vports to be rate-limited to the old aggregate speed. The second bug (active-backup summing all port speeds instead of the active port's speed) was also triggered: in active-backup mode the computed aggregate was double the expected value since both port speeds were summed even though only one port was active. Fixes: 28ea6036dad2 ("net/mlx5: Handle port and vport speed change events in MPESW") Signed-off-by: Or Har-Toov Reviewed-by: Shay Drori Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260930170406.148548-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit af7886fcfb6633472c24c5f782fbbbf32f4b55cc Merge: d333c8bca6dc3c 0a01e1df137fd7 Author: Jakub Kicinski Date: Mon Oct 5 15:44:45 2026 -0700 Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Fix i40e/ice/iavf VF bonding after netdev lock changes Jose Ignacio Tornos Martinez says: This series fixes VF bonding failures introduced by commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations"). When adding VFs to a bond immediately after setting trust mode, MAC address changes fail with -EAGAIN, preventing bonding setup. This affects both i40e (700-series) and ice (800-series) Intel NICs. The core issue is lock contention: iavf_set_mac() is now called with the netdev lock held and waits for MAC change completion while holding it. However, both the watchdog task that sends the request and the adminq_task that processes PF responses also need this lock, creating a deadlock where neither can run, causing timeouts. Additionally, setting VF trust triggers an unnecessary ~10 second VF reset in i40e driver that delays bonding setup, even though filter synchronization happens naturally during normal VF operation. For ice driver, the delay is not so big, but in the same way the operation is not necessary. This series: 1. Eliminates unnecessary VF reset when setting trust in i40e (reset only if revoking trust and VF has advanced features configured). 2. Fixes lock contention by polling admin queue synchronously 3. Eliminates unnecessary VF reset when setting trust in ice, (reset only if revoking trust and VF has advanced features configured). The key fix (patch 2/3) implements a synchronous MAC change operation similar to the approach used for ndo_change_mtu deadlock fix: https://lore.kernel.org/20260211191855.1532226-1-poros@redhat.com Instead of scheduling work and waiting, it: - Sends the virtchnl message directly (not via watchdog) - Polls the admin queue hardware directly for responses - Processes all messages inline (including non-MAC messages) - Returns when complete or times out This allows the operation to complete synchronously while holding netdev_lock, without relying on watchdog or adminq_task. The function can sleep for up to 2.5 seconds polling hardware, but this is acceptable since netdev_lock is per-device and only serializes operations on the same interface. Testing shows VF bonding now works reliably in ~5 seconds vs 15+ seconds before (i40e), without timeouts or errors (i40e and ice). Tested on Intel 700-series (i40e) and 800-series (ice) dual-port NICs with iavf driver. Thanks to Jan Tluka and Yuying Ma for reporting the issues. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: skip unnecessary VF reset when setting trust iavf: send MAC change request synchronously i40e: skip unnecessary VF reset when setting trust ==================== Link: https://patch.msgid.link/20260928224454.483072-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski commit d333c8bca6dc3c5e978f6698d39dd799f3b0dc8d 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 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 commit cf238c067eaae1cbfb00738e29219b9568d2313e 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 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 commit 83d5acca1f4f6132038ea88c72c5844f62e42d44 Author: Thomas Hellström Date: Fri Oct 2 12:08:29 2026 +0200 drm/xe: Fix shrinker accounting double-subtraction on nested external pins 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 commit f7fc61e66041b1f8300cad87005ba84604bfefd9 Author: Tvrtko Ursulin Date: Fri Sep 25 09:00:16 2026 +0100 drm/xe: Do not emit Wa_16010904313 twice During development of commit e8372edec948 ("drm/xe/xelp: Implement Wa_16010904313") one of the interim patch versions contained an incorrect rebase on top of some upstream changes, which caused Wa_16010904313 to be emitted both from the indirect context and from the workaround batch buffer. As this workaround needs to be emitted from the indirect context for rcs and ccs, but from the workaround batch buffer for bcs, vcs and vecs, we need to pass the location as an input parameter to setup_timestamp_wa() so it can decide whether to emit itself or not. Signed-off-by: Tvrtko Ursulin Fixes: e8372edec948 ("drm/xe/xelp: Implement Wa_16010904313") Cc: Matt Roper Cc: Rodrigo Vivi Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260925080016.64802-1-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi [Rodrigo: small adjustments on commit message for check-patch] (cherry picked from commit 38631a7bce195b88814b93bf2b6d3e48c827fef2) Signed-off-by: Rodrigo Vivi commit e7ed652b1312ffcb9ea2153946615856b5097c78 Author: Alan Previn Date: Tue Sep 29 12:20:37 2026 -0700 drm/xe/mmio: Fix xe_mmio_wait32() to honor delay/sleep maximums 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 commit 7484bc43ba6b8e189b482db5b75e7842890a82b1 Author: Vishal Badole Date: Fri Oct 2 17:02:03 2026 +0530 EDAC/amd64: Mask UMC chip select to the four implemented selects 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 commit 87db7795cbaaf636ae22ae031f4906db7bb77803 Author: Borislav Petkov (AMD) Date: Fri Oct 2 14:16:17 2026 -0700 x86/CPU/AMD: Fix AMD TLBI Erratum #1718 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 commit e32d80293a0e1a160d5e5101daa8c82148c07510 Author: Chengfeng Ye Date: Mon Oct 5 15:50:31 2026 +0800 Bluetooth: ISO: Serialize concurrent connect calls 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 commit 555ff78fa719f50ff4cdbdb40aa1acc6e8e327d3 Author: Chengfeng Ye Date: Mon Oct 5 00:25:48 2026 +0800 Bluetooth: ISO: Reject concurrent BIS listener setup 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 commit 9af12272061d206af8bc3e40215cb694421ab73a Author: Chengfeng Ye Date: Mon Oct 5 00:26:12 2026 +0800 Bluetooth: hci_sync: Fix command skb lifetime during scan setup 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 commit 381a0925c556a8d91a80a9b9e3e86651d60ffee3 Author: Chengfeng Ye Date: Mon Oct 5 00:24:42 2026 +0800 Bluetooth: hci_sock: Serialize dead-device detachment 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 commit 41cab3a71dc7be62114d91cc849424879062d324 Merge: 58304e139cb3fa 5755f1bd0217ff Author: Jens Axboe Date: Mon Oct 5 08:41:38 2026 -0600 Merge tag 'nvme-7.3-2026-10-05' of git://git.infradead.org/nvme into block-7.3 Pull NVMe fixes from Keith: "- Fix lock ordering revalidating zoned multipath heads - Fix swapped ZRASF zone state values for full and read only - Fix target p2pmem cleanup when the metadata allocation fails - Fix target status code for invalid NSIDs on reservation features - Revert the NVME_CTRL_NEW state change, which broke the Apple driver" * tag 'nvme-7.3-2026-10-05' of git://git.infradead.org/nvme: Revert "nvme: do not reset controllers in NVME_CTRL_NEW state" nvmet: use the local P2P device on metadata allocation failure nvme-multipath: revalidate head zones after unfreezing the head queue nvme: fix swapped ZRASF zone state values for full and read only nvmet: return Invalid Field for invalid NSIDs feature 82h commit 67f0943b394d920b6c142aad8c6af94340342ae7 Merge: a90ee4305c4a5d 28b7260548af3d Author: Linus Torvalds Date: Mon Oct 5 07:36:06 2026 -0700 Merge tag 'selinux-pr-20261005' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux Pull selinux fixes from Paul Moore: - Preserve SECURITY_LSM_NATIVE_LABELS when reusing superblocks Similar to a previous fix (see the commit description of Stephen's fix) we need to check to see if we have already mounted/setup the superblock passed into the security_sb_set_mnt_opts() LSM hook so we don't mistakenly unset SECURITY_LSM_NATIVE_LABELS. - Fix a potential AVC sequence number data race * tag 'selinux-pr-20261005' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux: selinux: preserve NATIVE_LABELS on already-initialized sb in set_mnt_opts selinux: fix data race on AVC latest_notif commit d0cb7a7b2a490c381ad97f53155d02a748b60dea 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) 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 commit 41c8899d59898f6fa51ceebd2b6e55257191a8ee Author: Filipe Manana Date: Fri Sep 25 17:12:45 2026 +0100 btrfs: fix lost error return value in btrfs_listxattr() 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 commit 858bee1c77857aabcc2327cd32dd8266332de332 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 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 commit 51562a8cb11628d3a5e105b4c347ec5473e5745f Author: Yang Xiuwei Date: Wed Aug 19 10:54:35 2026 +0800 btrfs: don't stash io_uring encoded data across -EAGAIN Returning -EAGAIN while leaving btrfs_uring_encoded_data in the cmd PDU leaks if the request is cancelled or the ring exits before reissue. io_uring does not free driver PDU allocations on cleanup. Write: io_queue_sqe() always issues with IO_URING_F_NONBLOCK first, so return -EAGAIN before allocating and free data on every exit. Read: free on nowait -EAGAIN too; only -EIOCBQUEUED keeps the allocation for btrfs_uring_read_finished(). Fixes: 34310c442e17 ("btrfs: add io_uring command for encoded reads (ENCODED_READ ioctl)") Fixes: e32dcdb0af9f ("btrfs: add io_uring interface for encoded writes") Signed-off-by: Yang Xiuwei Reviewed-by: David Sterba Signed-off-by: David Sterba commit b6e8add5d79d1f6f819a054c833bab452bd7365d 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 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 commit a8ea92830b3e0e163d4e829bdcb17ca83c0f951c Author: Yang Xiuwei Date: Wed Aug 19 10:54:33 2026 +0800 btrfs: free iov when btrfs_uring_read_extent() fails 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 commit 80a8dbb30d2b00b9c671b02bd73f700f6d20100f Author: Yang Xiuwei Date: Wed Aug 19 10:54:32 2026 +0800 btrfs: always return -EIOCBQUEUED after btrfs_uring_read_extent_endio 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 commit 1fd742c7479961da6d0bb794ef8ac6b7b9442847 Author: Wentao Liang Date: Wed Sep 16 17:16:10 2026 +0000 btrfs: scrub: fix local_root reference leak in scrub_print_warning_inode() 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 commit 3e6ff34afc7ec7a6156e58502b5a56771517cf93 Author: Filipe Manana Date: Fri Sep 18 11:58:00 2026 +0100 btrfs: clear BTRFS_ROOT_IN_TRANS_SETUP on early exit from record_root_in_trans() If we exit early because the transaction that last used the root already matches the current transaction, we leave the BTRFS_ROOT_IN_TRANS_SETUP bit set in the root (which we just set right before the exit). While this does not cause any functional issue, it makes callers of btrfs_record_root_in_trans() lock fs_info->reloc_mutex and call record_root_in_trans() for nothing, causing unnecessary lock contention, until one of them clears the bit in record_root_in_trans(). One caller of btrfs_record_root_in_trans() is start_transaction(), used to start new transaction or joining an existing one, which is a hot path. So clear BTRFS_ROOT_IN_TRANS_SETUP on early exit. Assisted-by: LLM Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba commit 5755f1bd0217ffe3c5cf85467bf6b0680f398265 Author: Keith Busch Date: Mon Oct 5 04:18:24 2026 -0700 Revert "nvme: do not reset controllers in NVME_CTRL_NEW state" This reverts commit c20bba234f3e1dcd81f7a2ec21ea7bf01a4cf35f. The standard transport drivers were okay with the patch, but the Apple driver needs a bit of work before it can handle the state transition requirement. Link: https://lore.kernel.org/linux-nvme/94912d46-381d-4988-800a-6ef3b595233f@cyberchaos.dev/ Reported-by: Yureka Lilian Signed-off-by: Keith Busch commit 58304e139cb3fa640da74bc02101f0926d0607e2 Author: Shin'ichiro Kawasaki Date: Wed Sep 16 15:56:57 2026 +0900 zloop: zero out only the unread tail of short reads 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 commit ae8364085574203e7f4ea961921a1c7493bcb6de Author: Rahul Pon Date: Wed Sep 30 16:46:41 2026 +0530 i2c: qcom-geni: release runtime PM reference when set_rate fails geni_i2c_xfer() takes a runtime-PM reference with pm_runtime_get_sync() and then returns directly if the set_rate() callback fails, leaking the reference and keeping the controller resumed for good. Route that error through the existing cleanup path, which drops the reference and resets the transfer state. Found by code review; compile-tested with arm64 defconfig plus ACPI and W=1. Fixes: 10e74f4c5046 ("i2c: qcom-geni: Enable I2C on SA8255p Qualcomm platforms") Assisted-by: LLM Signed-off-by: Rahul Pon Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260930111641.1134-1-theflyingrahul@gmail.com commit e58c3805ed325fe2d4ae2dd467c0486cc860b733 Author: Eric Biggers Date: Thu Oct 1 10:13:49 2026 -0700 fsverity: RCU-delay the freeing of struct fsverity_info __fsverity_get_info() calls rhashtable_lookup_fast(), which just uses rcu_read_lock() and doesn't directly synchronize with fsverity_remove_info(). For the same inode this isn't a problem: its fsverity_info is removed only at inode eviction time or upon failure to enable verity, when the inode no longer needs its fsverity_info and it will no longer be accessed via that inode. However, this is broken and can cause a use-after-free for concurrent __fsverity_get_info() for *different* inodes. Those rely on following fsverity_info::rhash_head in the rhashtable under rcu_read_lock() only. They also use fsverity_info::inode to do the key comparison. Fix this by RCU-delaying the freeing of 'struct fsverity_info' after it's been removed from the rhashtable. Fixes: f77f281b6118 ("fsverity: use a hashtable to find the fsverity_info") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Reviewed-by: Sandeep Dhavale Link: https://patch.msgid.link/20261001171349.81454-1-ebiggers@kernel.org Signed-off-by: Eric Biggers commit aaaaf87ea99b8766c9a8aa0e71aa42e6bc8a5320 Author: Denis V. Lunev Date: Tue Sep 29 09:25:19 2026 +0200 openvswitch: fix soft lockup in the netlink flow dump 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 commit 5158353121bae4f552cb677ce8c5c3ef52f93a0d Author: Zixuan Chai Date: Sun Sep 27 01:04:39 2026 +0800 net: bridge: avoid recursive multicast port cleanup 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 commit fd99864b0ac936e870c7ae28354c5cd3dad5efd0 Author: Miquel Raynal Date: Thu Oct 1 17:14:44 2026 +0200 spi: cadence-qspi: Fix status polling with octal DTR chips Most SPI NOR chips today use 0x05 as ReaD Status Register (RDSR) opcode. After almost every transaction, the core will wait for the said transation to be digested by the chip by polling its status register. This mechanism has been automated by certain chips, such as the Cadence QSPI controller. Unfortunately, the feature has been disabled for various (relevant) reasons. Disabling this feature has been done by setting WRITE_COMPLETION_CTRL_REG.DISABLE_POLLING_FLD, keeping the rest of the register intact. In this same register, there is also a field named WRITE_COMPLETION_CTRL_REG.OPCODE_FLD, which by default also contains 0x05, as primary RDSR opcode. As a result, both the SPI NOR and SPI NAND cores, primary users through spi-mem of the spi_mem_ops interface, do send their own RDSR. In this driver, such command goes through one of the fifth possible data path specifically crafted for short register-like commands, named STIG. In STIG mode, the opcode of the operation is written to OSPI_FLASH_CMD_CTRL_REG. This means that the opcode field of STIG configuration and the opcode field of the automatic polling configuration contain the same value. Unfortunately, the TRM explains in two different places that this configuration is forbidden, without explaining why it is problematic: $12.4.2.4.11 OSPI Software-Triggered Instruction Generator (STIG) ``` OSPI_FLASH_CMD_CTRL_REG[31-24] CMD_OPCODE_FLD bits should be set different than OSPI_DEV_INSTR_RD_CONFIG_REG[7-0] RD_OPCODE_NON_XIP_FLD and OSPI_DEV_INSTR_WR_CONFIG_REG[7-0] WR_OPCODE_FLD. ``` and $12.4.2.5.2 Configuring the OSPI Controller for Optimal Use ``` When using the OSPI Controller, the opcodes in OSPI_DEV_INSTR_RD_CONFIG_REG[7-0] RD_OPCODE_NON_XIP_FLD, OSPI_DEV_INSTR_WR_CONFIG_REG[7-0] WR_OPCODE_FLD and OSPI_WRITE_COMPLETION_CTRL_REG[7-0] OPCODE_FLD bit fields shall not match the opcode in the OSPI_FLASH_CMD_CTRL_REG[31-24] CMD_OPCODE_FLD bit field. ``` For some reasons, this is only unveiled now when testing in ODTR mode. Plain SDR modes work flawlessly with the same chips. One possible reason for this, is that the internal data path in ODTR mode is very different due to the extra opcode extension/repetition which may be interpreted differently (this is a wild guess). For sure there is an interference, as even the TRM states that there is some magic happening: $12.4.2.4.13 OSPI Command Translation ``` The WREN and the RDSR device instructions are the only ones that are sent by the controller under the hood. ``` I cannot probe the bus when the problem arises, so I don't know exactly what is sent on the bus. Practically speaking, the chip was driving the lines low (reading all 0s), which is not the usual default state when the chip is not driving the lines (all 1s). Other people on the mailing list claimed successfully using ODTR chips with this controller. My take here is that either they were using a variant of the IP without write completion at all (there is a quirk for it), or they were using chips slightly more flexible about their opcode sequency or maybe with different addr/dummy requirements. Clearing the WRITE_COMPLETION_CTRL_REG.OPCODE_FLD while disabling write completion polling entirely seems the best compromise. Signed-off-by: Miquel Raynal Link: https://patch.msgid.link/20261001-winbond-spi-next-cadence-rdsr-fix-v1-1-ec5ff594ba5d@bootlin.com Signed-off-by: Mark Brown commit a90ee4305c4a5df72c11b31dacfdc76e00fcf78a Author: Linus Torvalds Date: Sun Oct 4 13:45:25 2026 -0700 Linux 7.3-rc6 commit 94b6df050433875f493fb8298b58d7b0dc32eb9c Author: Haibo Chen Date: Mon Sep 28 19:53:11 2026 +0800 spi: spi-nxp-fspi: exit stop mode before waiting for DLL lock For 8D-8D-8D (octal DTR) mode the FlexSPI samples read data using MCR0[RXCLKSRC] = 3 (flash-memory-provided read strobe on the DQS pad), which requires the DLL to be locked. Per the i.MX95 Reference Manual (FlexSPI chapter, "DLL configuration for sampling"), when the serial root clock is above 100 MHz the DLL is enabled (DLLxCR[DLLEN] = 1, OVRDEN = 0) and software must then wait for STS2[xREFLOCK] and STS2[xSLVLOCK] to be asserted before starting a read or write. This DLL lock is relative to the serial root clock. While the module is in stop mode (MCR0[MDIS] = 1) the AHB and serial clocks are gated off internally, so the serial root clock the DLL locks against is not running. nxp_fspi_dll_calibration() both programs DLLxCR and then polls STS2 for lock. When it runs entirely in stop mode the STS2 REF/SLV lock bits never assert (observed as "DLL lock failed" with STS2 = 0). The MCR0 bit fields (RXCLKSRC) and the serial root clock rate still have to be reconfigured in stop mode, so keep entering stop mode around that. Only move the exit from stop mode (clearing MCR0[MDIS]) ahead of the DLL calibration/override step, so that the serial root clock is running when the DLL is calibrated and STS2 can report lock. Fixes: b4bde5cfff8e ("spi: spi-nxp-fspi: enter stop mode before reconfiguring MCR0 and DLL") Signed-off-by: Haibo Chen Link: https://patch.msgid.link/20260928-fspi-fix-v1-1-a0f9288cd5c8@nxp.com Signed-off-by: Mark Brown commit 1514faf41f7ccd64c987e1006ddebbe825a1664c Merge: cbade031e2ebb3 098bf3be6cecb9 Author: Christian Brauner Date: Sun Oct 4 21:46:09 2026 +0200 Merge patch series "mount: more bugfixes, trapped in the Black Lodge edition" Christian Brauner says: More bugfixes from work in this area: - unhash a dentry before detaching the mounts on it to avoid leaking sensitive data - don't reveal overmounted entries in refwalk - refuse F_SET_RW_HINT on an immutable inode - refuse an automount below a mount that is in no namespace - handle mount locking for automounts correctly - don't update the access time on nullfs - never expire a locked mount - keep the lock on a mount that a propagated copy is moved beneath - decide the subtree check under mount_lock - keep the private nullfs instance in knullfs - nothing is mounted on or written through knullfs - let a filesystem refuse fsnotify marks on its objects - refuse file locks on nullfs - refuse leases and delegations on nullfs - take no inode lock on an immutable directory * patches from https://patch.msgid.link/20261002-work-mount-fixes-4-v1-0-dd44b89d44ce@kernel.org: selftests/filesystems: check that reading the root of an empty mount namespace stalls nobody selftests/filesystems: add a helper that holds a readdir in a page fault readdir: take no inode lock on an immutable directory nullfs: refuse file locks fsnotify: let a filesystem refuse marks on its objects namespace: nothing is mounted on or written through knullfs namespace: keep the private nullfs instance in knullfs fhandle: decide the subtree check under mount_lock selftests/filesystems: check that an automount below an overlay layer is refused selftests/filesystems: check the atime of the empty mount namespace root selftests/filesystems: check that a lock lands on the right mount and stays namespace: keep the lock on a mount that a propagated copy is moved beneath namespace: never expire a locked mount nullfs: don't update the access time namespace: handle mount locking for automounts correctly namespace: refuse an automount below a mount that is in no namespace selftests/filesystems: check that an immutable inode takes no write hint fcntl: refuse F_SET_RW_HINT on an immutable inode namei: don't reveal overmounted entries in refwalk namespace: unhash a dentry before detaching the mounts on it Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-0-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit dd3ea3fcba7c75493760cdbccd35f029597e8d5e Author: 성병찬 Date: Wed Sep 30 13:18:01 2026 +0900 KEYS: Fix add_key() race with keyring restriction __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 commit 25bf14f817168079f731975b8998fc2af380f29e Author: Karl Mehltretter Date: Sat Sep 12 11:54:40 2026 +0200 keys: finalize persistent keyring timeout after link attempt 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 commit 5b4bd13e0552926648a46c2c9a12a24dfaee3715 Author: Alexey Charkov Date: Thu Sep 10 18:32:58 2026 +0400 power: supply: core: prevent unregistering a power supply while a callback runs Once a power supply is registered, its callbacks can immediately start firing from other contexts, such as external_power_changed() triggered by the TCPM stack. If a power supply is unregistered while the callback is still running, the driver data can already be freed when the callback tries to access it, leading to a use-after-free. This happens e.g. when the hardware bus carrying the power supply device malfunctions (e.g. I2C is hogged down by another malfunctioning device) immediately after the power supply is registered, and thus the core is still processing the callbacks which were queued up when the driver starts the removal, leading in some cases to a kernel crash, e.g.: [ 11.645942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000005 [ 11.646751] Mem abort info: [ 11.647006] ESR = 0x0000000096000004 [ 11.647338] EC = 0x25: DABT (current EL), IL = 32 bits [ 11.647806] SET = 0, FnV = 0 [ 11.648077] EA = 0, S1PTW = 0 [ 11.648356] FSC = 0x04: level 0 translation fault [ 11.648785] Data abort info: [ 11.649041] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 11.649524] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 11.649981] GCS = 0, Overlay = 0, DirtyBit = 0 [ 11.650390] [0000000000000005] user address but active_mm is swapper [ 11.650955] Internal error: Oops: 0000000096000004 [#1] SMP [ 11.651460] Modules linked in: [ 11.651742] CPU: 1 UID: 0 PID: 144 Comm: kworker/1:2 Not tainted 7.2.0-rc6-g62a9297af2cd #1 PREEMPT [ 11.652553] Hardware name: Flipper One rev. F0B1C2 (DT) [ 11.653024] Workqueue: events power_supply_changed_work [ 11.653511] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 11.654135] pc : __power_supply_is_supplied_by+0x18/0x100 [ 11.654624] lr : __power_supply_am_i_supplied+0x40/0xb8 [ 11.655098] sp : ffff80008192bb30 [ 11.655399] x29: ffff80008192bb30 x28: 0000000000000000 x27: 0000000000000000 [ 11.656049] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 11.656695] x23: ffff0000c19f4200 x22: ffffdb2232ba4ea8 x21: ffff80008192bc28 [ 11.657344] x20: ffff0000c1eef000 x19: ffff80008192bc18 x18: 00000000a0886e62 [ 11.657991] x17: 000000040044ffff x16: 04500072b5503510 x15: 0000000000000000 [ 11.658639] x14: 0000000000000000 x13: 0000000000000220 x12: 0000000000000000 [ 11.659286] x11: 0000000000000000 x10: ffff0000c1fdb2b0 x9 : ffffdb2232ba5590 [ 11.659934] x8 : 00000000e5b906e6 x7 : ffff0000c2502778 x6 : ffffdb22339793d0 [ 11.660581] x5 : ffff80008192bc18 x4 : ffff0000c19cbca0 x3 : 0000000000000000 [ 11.661228] x2 : ffff0000c1fdaf40 x1 : ffffffffffffffed x0 : ffff0000c1eef000 [ 11.661878] Call trace: [ 11.662103] __power_supply_is_supplied_by+0x18/0x100 (P) [ 11.662596] __power_supply_am_i_supplied+0x40/0xb8 [ 11.663040] psy_for_each_psy_cb+0x20/0x40 [ 11.663416] class_for_each_device+0x110/0x150 [ 11.663825] power_supply_am_i_supplied+0x68/0x100 [ 11.664262] bq257xx_external_power_changed+0x58/0x140 [ 11.664733] __power_supply_changed_work+0x60/0x80 [ 11.665170] psy_for_each_psy_cb+0x20/0x40 [ 11.665545] class_for_each_device+0x110/0x150 [ 11.665953] power_supply_changed_work+0x98/0x1b8 [ 11.666382] process_one_work+0x164/0x4c0 [ 11.666758] worker_thread+0x19c/0x320 [ 11.667104] kthread+0x138/0x150 [ 11.667408] ret_from_fork+0x10/0x20 [ 11.667744] Code: d503233f a9bd7bfd 910003fd a90153f3 (f9400c34) [ 11.668294] ---[ end trace 0000000000000000 ]--- Add a read-write semaphore between external_power_changed() and power_supply_unregister() to prevent the latter from returning (and thus the driver from freeing its data) while the callback is still running. Fixes: bc1540561c9e ("power_supply: Add API for safe access of power supply function attrs") Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260910-bq257xx-init-v3-1-4e219a1a04a5@flipper.net Signed-off-by: Sebastian Reichel commit 7704c4c5bb127673b4f0ead839919db573559e38 Merge: 06ac073129191a c98bf3b86609a1 Author: Linus Torvalds Date: Sun Oct 4 09:38:11 2026 -0700 Merge tag 'i2c-fixes-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull i2c fixes from Andi Shyti: "Three patches in xiic for fixing the block reads and a single cleanup in the at91 error path: - at91: also release DMA channels when deferring probe - xiic: fix SMBus block reads with PEC" * tag 'i2c-fixes-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: i2c: at91: release DMA channels when probe defers i2c: xiic: don't clobber msg->len to signal block-read completion i2c: xiic: defer RX_FULL until all trailing bytes are in FIFO i2c: xiic: preserve PEC byte length in SMBus block read setup commit 5a26d7d96a66a7fdfff4fbcb86035161033ad407 Merge: 2f15518682c779 b35ff7bd7dd569 Author: Mark Brown Date: Sun Oct 4 18:29:13 2026 +0200 regulator: of: Fixes to of_regulator_bulk_get_all() Alexey Charkov says: of_regulator_bulk_get_all() only fills in the .consumer part of the struct regulator_bulk_data for the regulators it gets, leaving .supply as garbage, while the rest of the regulator core expects a meaningful name there (e.g. for error prints), causing uninitialized memory access in any failure paths in the core. It also allocates the supplies array and hands it to callers, but never says the callers need to free it (which they don't currently), causing leaks. Fix the former and document the latter in the kerneldoc to help any new users avoid the leak. Link: https://patch.msgid.link/20260930-regulator-get-all-v2-0-ca82070d22f2@flipper.net commit b35ff7bd7dd56915a511eec56c8763ee8f9f7e9f Author: Alexey Charkov Date: Wed Sep 30 20:13:04 2026 +0400 regulator: of: state who owns the array from of_regulator_bulk_get_all() of_regulator_bulk_get_all() allocates the consumer array and hands it to the caller, but never said so. Its own error path frees the array, while regulator_bulk_free() only puts the regulators, so both callers release the regulators and leak the array. Spell the contract out in the kerneldoc. Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260930-regulator-get-all-v2-2-ca82070d22f2@flipper.net Signed-off-by: Mark Brown commit e2151c29cec73f6cc70abf1c7cbc7b9b202489f5 Author: Alexey Charkov Date: Wed Sep 30 20:13:03 2026 +0400 regulator: of: fill in supply names in of_regulator_bulk_get_all() 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 commit 6bca94e64255053ab2aa56f2588fda73d399b790 Author: Svyatoslav Ryhel Date: Sat Sep 26 17:29:05 2026 +0300 power: supply: generic-adc-battery: Fix temperature IIO channel conversion Temperature IIO channel data is provided in milli-degrees, while POWER_SUPPLY_PROP_TEMP is expected to be in deci-degrees. Adjust the existing logic to reflect this conversion properly. Fixes: 33088c0513818 ("power: supply: generic-adc-battery: add temperature support") Signed-off-by: Svyatoslav Ryhel Link: https://patch.msgid.link/20260926142905.206215-2-clamor95@gmail.com Signed-off-by: Sebastian Reichel commit 06ac073129191a01d77933ed381f89c67674db6f Merge: 942e4a0e46bfd0 a661c34fe693c8 Author: Linus Torvalds Date: Sun Oct 4 08:59:22 2026 -0700 Merge tag 'x86-urgent-2026-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: - Don't apply va_align to hugetlb mappings on AMD F15h systems that have custom va_align.bits values (Laurent Wandrebeck) - Fix PMD teardown handling regression flagged by lockdep (Mikhail Gavrilov) - Hide ptrace header register offset macros behind __ASSEMBLER__ or __FRAME_OFFSETS, to fix user-space build errors that may trigger if they happen to shadow these short and generic macro names (Nick Desaulniers) * tag 'x86-urgent-2026-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: {x86,um}/uapi/ptrace: Guard register offset macros with __ASSEMBLER__ or __FRAME_OFFSETS x86/mm: Drop unnecessary PMD page copy when freeing x86/mm: Don't apply va_align to hugetlb mappings on AMD F15h commit 942e4a0e46bfd0efd3f87f70bf186c54aaaeb138 Merge: a27611f8994c9a 28fa9af353bed2 Author: Linus Torvalds Date: Sun Oct 4 08:39:26 2026 -0700 Merge tag 'timers-urgent-2026-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fix from Ingo Molnar: - Fix task work flags management regression in the hrtimer rearming code that can leave task work items unprocessed (Karl Mehltretter) * tag 'timers-urgent-2026-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: hrtimer: Use the mask to clear TIF_HRTIMER_REARM from the exit work commit a27611f8994c9a4772156432badb533af33fd32d Merge: 1c915d6007fab5 357e8a77a501d9 Author: Linus Torvalds Date: Sun Oct 4 08:35:29 2026 -0700 Merge tag 'perf-urgent-2026-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf events fixes from Ingo Molnar: - Fix race between perf_event_exit_task() and perf_pending_task() (Luo Gengkun) - Fix perf header output management regressions (Ian Rogers) - Require kernel access for text poke events (Zhengchuan Liang) * tag 'perf-urgent-2026-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Require kernel access for text poke events perf: Replace perf_event_header__init_id with full header init perf: Fix race between perf_event_exit_task() and perf_pending_task() commit 1c915d6007fab5b87a8c2516dfd37dd614875f9c Merge: 6addb4f385570e f35e3b57842216 Author: Linus Torvalds Date: Sun Oct 4 08:29:27 2026 -0700 Merge tag 'locking-urgent-2026-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fixes from Ingo Molnar: - Don't run refcount kunit self-test when !CONFIG_KUNIT_ALL_TESTS (Kuan-Wei Chiu) - Fix futex private hash use-after-free on resize (Chris Mason) * tag 'locking-urgent-2026-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: futex: Fix private hash use-after-free on resize irq: Make refcount_interrupt kunit test selectable commit 098bf3be6cecb9b297f5a5865e89d36d16edf19e Author: Christian Brauner Date: Fri Oct 2 15:52:52 2026 +0200 selftests/filesystems: check that reading the root of an empty mount namespace stalls nobody A readdir of the root of an empty mount namespace stuck in the page fault of its buffer must stall neither a create nor a lookup in that directory. The test needs userfaultfd and skips without it. Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-21-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit fa15a241f0a862904d673d2514baf9a26c0893e8 Author: Christian Brauner Date: Fri Oct 2 15:52:51 2026 +0200 selftests/filesystems: add a helper that holds a readdir in a page fault A getdents64() whose buffer is a page registered with userfaultfd sits in handle_userfault() with whatever iterate_dir() took before it copied the entries. Add readdir_hold.h for tests that want to know what that blocks: it opens the userfaultfd before the test enters a user namespace, the fault happens in the kernel and needs CAP_SYS_PTRACE in the initial one, starts the readdir in a thread, waits until that thread is stuck, queues a create behind it and waits for it to settle, then probes a lookup with a watchdog and says whether it came back. The page is released afterwards so that everything drains on a kernel that still holds the lock across the copy. The two users follow. Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-20-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit e08f57a7dcb83818c058e415988c23beb6c5a47f Author: Christian Brauner Date: Fri Oct 2 15:52:50 2026 +0200 readdir: take no inode lock on an immutable directory iterate_dir() takes the directory's i_rwsem shared and holds it across ->iterate_shared(). For a directory that never has an entry and is never removed the lock keeps nothing still, it only orders every reader and every writer of that inode behind each other. For the directory of a nullfs instance that matters. The instance of the initial mount namespace is the root of every empty mount namespace and the private instance is the root of every kernel thread, so one inode is shared across users who have nothing else in common. And a reader can hold the lock for as long as it likes: back the getdents() buffer with a mapping of a file on a FUSE mount of your own, let the copy of "." and ".." fault and let the server wait. Queue an exclusive taker behind it, a mkdir() in that directory goes through start_dirop() before the read-only mount is reported, and from then on every lookup that misses the dcache in that directory, every create and every mount on it waits until the server answers. One user of an empty mount namespace stalls all the others. Add FOP_IMMUTABLE for the file operations of a directory that never changes and is never removed and let iterate_dir() skip the lock for it. The flag never changes for a file, ->f_pos is protected by f_pos_lock since directories are FMODE_ATOMIC_POS, IS_DEADDIR can't be set on such a directory and neither touch_atime() nor fsnotify take i_rwsem. Set it on the nullfs directory. The placeholder directories of libfs never have an entry either but their owners remove them, so they keep the lock. Fixes: 9d4e752a24f7 ("namespace: allow creating empty mount namespaces") Cc: stable@vger.kernel.org # v7.1+ Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-19-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 31a1fb90624d7e275db775a29a0e00a7f8b3df63 Author: Christian Brauner Date: Fri Oct 2 15:52:48 2026 +0200 nullfs: refuse file locks Refuse flock() and POSIX locks on nullfs. Its one inode is the root of every kernel thread and the following patches make it the directory that stands in for an unmounted mount, so a lock taken through one such directory would block the locks of every other holder and F_GETLK would tell them the pid of the holder. Give the directory file operations of its own: what libfs gives an empty directory plus ->lock and ->flock that fail with ENOLCK, the way a filesystem without lock support does. Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-17-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit c9ec8607b4d1ce4e862f5b6ba2f0eb727387988a Author: Christian Brauner Date: Fri Oct 2 15:52:47 2026 +0200 fsnotify: let a filesystem refuse marks on its objects Don't let nullfs be watched. fanotify refuses mount and filesystem marks on SB_NOUSER superblocks but inode marks of inotify, fanotify and dnotify go through. The one inode of knullfs is the root of every kernel thread and the following patches make it reachable from userspace as the directory that stands in for an unmounted mount. A watch placed through one such directory would report the opens through all the others, across users. Add FS_DISALLOW_NOTIFY next to FS_DISALLOW_NOTIFY_PERM, refuse a mark on any object of such a filesystem in fsnotify_add_mark_list() where every backend ends up and set it for nullfs. There's nothing to watch on a permanently empty and immutable filesystem. Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-16-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit e22e69c2ad8800bacab488d286ca3c5b5e68fcd9 Author: Christian Brauner Date: Fri Oct 2 15:52:46 2026 +0200 namespace: nothing is mounted on or written through knullfs Mark the root of knullfs with dont_mount(). Nothing is ever mounted on the root of a kernel thread and the following patches make that root reachable from userspace, so say it on the dentry where it doesn't depend on the mount being in no namespace. Let do_lock_mount() refuse such a target before it takes the inode lock and namespace_sem. The flag is sticky so the check needs no lock. The one under the locks stays for a mountpoint that is being removed. Make the mount read-only as well. Its one inode is immutable so nothing could be changed through it anyway, but MNT_READONLY makes that visible the usual way: EROFS instead of EPERM and ST_RDONLY in statvfs(). Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-15-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 4209cd7f546b55733d4d221109423600b025575a Author: Christian Brauner Date: Fri Oct 2 15:52:45 2026 +0200 namespace: keep the private nullfs instance in knullfs The private nullfs instance that kernel threads are confined to is only ever reachable through init_task's root and pwd. The following patches point mounts at it as well, so keep it in a global. No functional changes. Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-14-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 67b69b8a6ea730b1ee8fe682bd22b9b7fd5d9820 Author: Christian Brauner Date: Fri Oct 2 15:52:44 2026 +0200 fhandle: decide the subtree check under mount_lock may_decode_fh() lets a caller who is privileged over the mount namespace of @root decode handles below @root->dentry as long as the mount is mounted and no locked child covers something below it. The three parts are read one after the other without a lock: is_mounted() and capable_wrt_mount() read ->mnt_ns and has_locked_children() walks ->mnt_mounts under a mount_lock of its own. Today the gaps are harmless. A lazy umount in between clears ->mnt_ns, but the locked children stay attached to their unmounted parent, so the walk still finds them and the decode is refused either way. The following patches detach every unmounted mount from its parent. Then an umount between is_mounted() and the walk makes the walk come back empty and the caller decodes into what a locked child covered. So take mount_lock once and answer all three questions under it. is_mounted() is stable there, umount_tree() clears ->mnt_ns on the write side, and a mounted mount still has its locked children on its list. ns_capable() under the spinlock is fine, generic_permission() calls it in RCU walk already. has_locked_children() loses its locking wrapper, its other callers hold namespace_sem or mount_lock anyway. Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-13-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 39796254f4458a532dcef8197ec84b7c80ad2b18 Author: Christian Brauner Date: Fri Oct 2 15:52:43 2026 +0200 selftests/filesystems: check that an automount below an overlay layer is refused Make sure that we don't automount on top of internal things. Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-12-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 2244ca5662d7a5fd24d4aac0ab68458089efcabd Author: Christian Brauner Date: Fri Oct 2 15:52:42 2026 +0200 selftests/filesystems: check the atime of the empty mount namespace root No access time updates for immutable nullfs. Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-11-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 921c14fd00edb1e6c1e4248a669d65e391b89b7e Author: Christian Brauner Date: Fri Oct 2 15:52:41 2026 +0200 selftests/filesystems: check that a lock lands on the right mount and stays Check MNT_LOCKED: - A child in a user namespace of its own triggers the tracefs automount through a directory descriptor on the host's debugfs mount. The copy in the child's namespace has to be locked and the host's mount unlocked. - A child moves a bind of that automount beneath a locked covering mount, unmounts the covering mount and asks for the umount of an unlocked ancestor. This must not expire the mount which holds the lock now. - The host mounts and unmounts on a directory that a locked mount covers in a user namespace further down the propagation chain. That cover has to be locked afterwards as it was before. Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-10-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit d74d66aa708ccf2bc0b1e265a83fed0f2308d5c4 Author: Christian Brauner Date: Fri Oct 2 15:52:40 2026 +0200 namespace: keep the lock on a mount that a propagated copy is moved beneath attach_recursive_mnt() transfers MNT_LOCKED from the top mount to the mount that is moved beneath it with MOVE_MOUNT_BENEATH. This allows the owner of a user namespace to replace its locked /proc or its root. The mount beneath takes on the job of covering the underlying mountpoint allowing the top mount to be unmounted. Consider two mount namespaces: (H) The host H has a shared mount P with a secret in P/d (Z) Z is a user namespace made from M. Its copy of P receives propagation from the host's P and its copy of M's cover on P/d is locked Z's owner must not get to see P/d. Now (H) mounts X on P/d. This propagates into (Z). The copy of X lands beneath (Z)'s locked cover. The locked property is transfered from (Z)'s cover to the copy of X propagated beneath it. The cover is now unlocked. Now (H) unmounts X again. The copy of X in (Z) gets unmounted and the covering mount is left unlocked on top of P/d. (Z) can now unmount it: Z: umount2(P/d) = EINVAL /* the cover is locked */ H: mount X on P/d, umount X /* both propagate into Z /* Z: umount2(P/d) = 0 /* the cover is now unlocked */ Z: read P/d/secret = "covered-by-root" /* secret revealed */ So only transfer the locked property to the mount beneath for mounts the caller has placed. A propagated copy that lands beneath a locked mount is locked as well so that the mount at the bottom of the stack carries a lock the way every check expects. The mount on top of it remains locked to ensure that it keeps covering even if the propagated mount is unmounted again. Fixes: c62a4766937e ("move_mount: transfer MNT_LOCKED") Cc: stable@vger.kernel.org # v7.1+ Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-9-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit f78ddcc872248c7aa1d7e904928441a0be4c6d5d Author: Christian Brauner Date: Fri Oct 2 15:52:39 2026 +0200 namespace: never expire a locked mount 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) commit caf16f9b4aa66e5092f95e98cda54f2bb7482ed2 Author: Christian Brauner Date: Fri Oct 2 15:52:38 2026 +0200 nullfs: don't update the access time There's no point in updating access times of the nullfs instance. Raise S_IMMUTABLE. Fixes: 9d4e752a24f7 ("namespace: allow creating empty mount namespaces") Cc: stable@vger.kernel.org # v7.1+ Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-7-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 33aadc7c72055fca93cb5a3691d836ebf8b31c9b Author: Christian Brauner Date: Fri Oct 2 15:52:37 2026 +0200 namespace: handle mount locking for automounts correctly 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) commit ba985ce08471c555af2a2fbe217c1bc2e72a6d8c Author: Christian Brauner Date: Fri Oct 2 15:52:36 2026 +0200 namespace: refuse an automount below a mount that is in no namespace 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) commit 66cda7ec9abec7ec3b81678c48deab3450d038a6 Author: Christian Brauner Date: Fri Oct 2 15:52:35 2026 +0200 selftests/filesystems: check that an immutable inode takes no write hint Check that an immutable inode takes no write hint. Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-4-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) commit b0d1022b9bdb1e98aa7fb3244fdd50a58c61766c Author: Christian Brauner Date: Fri Oct 2 15:52:34 2026 +0200 fcntl: refuse F_SET_RW_HINT on an immutable inode 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) commit 8189ab688f5a2c745dc90b63374da02f213d6994 Author: Christian Brauner Date: Fri Oct 2 15:52:33 2026 +0200 namei: don't reveal overmounted entries in refwalk 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) commit 528b383dc35d1e5caf64ddf5d35f983ae543b0d0 Author: Christian Brauner Date: Fri Oct 2 15:52:32 2026 +0200 namespace: unhash a dentry before detaching the mounts on it 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) commit b52ef450139f5632d7e53e6fd5f5ec46c7029dac Author: Fuad Tabba Date: Wed Sep 30 13:12:12 2026 +0100 arm64/boot: Don't set PMUv3p9 FGT2 bits without PMUv3 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 commit 6addb4f385570ebc11c4eb499a4f1c149f313e84 Merge: a74306e2e676f9 5f43a2d35d5e74 Author: Linus Torvalds Date: Sat Oct 3 21:14:25 2026 -0700 Merge tag 'edac_urgent_for_v7.3_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras Pull EDAC fixes from Borislav Petkov: "This is more of the new normal of LLM-induced fixes of error paths. Oh well, they should be done eventually and hopefully we'll be back to normal soon-ish... one would hope... :-P AMD Versal NET: - Properly release a remote processor reference which was acquired at probe time, on memory controller instance remove A handful of Altera EDAC driver fixes: - Fix device node reference leaks covering both the success path and the various error paths, and route the single-bit setup function through the common exit label - Fix a use-after-free by releasing the devres group before freeing the control info structure in the error paths, since managed IRQ handlers could reference the freed dci struct if they fire at just the right time - Fix a memory leak by freeing the allocated control info structure when the devres group open fails in the Altera SDMMC setup path - Remove the __init marking from the Altera Arria10 setup paths and their helpers so they remain safely callable at runtime, including after deferred or re-triggered probing - Prevent the Altera driver from being unbound by removing their ->remove callbacks and marking them to suppress bind/unbind sysfs attributes, since unbinding could erase active system memory" * tag 'edac_urgent_for_v7.3_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/versalnet: Drop remote processor handle refcount on driver removal EDAC/altera: Fix device node reference leaks in the SDMMC ECC setup EDAC/altera: Fix use-after-free in error paths EDAC/altera: Fix memory leak on dci allocation failure EDAC/altera: Drop __init from ECC setup paths for re-probe safety EDAC/altera: Do not allow driver unbinding commit e6ac89b8b1c12e9104df45a14a26e2dfa96ded06 Author: Kuba Piecuch Date: Sat Oct 3 11:53:17 2026 +0000 sched_ext: Generate qseq from a per-task counter 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 commit 1fc2d80928b706147e371602dabd0ba927dfe4a3 Merge: 67c050583f8bfa b7f925fd5226de Author: Arnd Bergmann Date: Sat Oct 3 23:32:48 2026 +0200 Merge tag 'tee-fix-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into arm/fixes Reject zero-sized allocations in tee_dyn_shm_alloc_helper() * tag 'tee-fix-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee: tee: shm: reject zero-sized allocations in tee_dyn_shm_alloc_helper() Signed-off-by: Arnd Bergmann commit 67c050583f8bfa6daee282cbb21dcd6724f2333e Merge: f2e695a6c27241 93847823b6761e Author: Arnd Bergmann Date: Sat Oct 3 22:55:28 2026 +0200 Merge tag 'qcomtee-fix-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into arm/fixes Fix kernel-doc warnings * tag 'qcomtee-fix-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee: tee: qcomtee: fix kernel-doc warnings Signed-off-by: Arnd Bergmann commit a74306e2e676f9775457366fc047a660fbf02f26 Merge: 25d576ed111084 81493c1dd1b1eb Author: Linus Torvalds Date: Sat Oct 3 10:57:47 2026 -0700 Merge tag 'clk-fixes-for-linus-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Brian Masney: "Two small clk driver fixes: - spacemit: k3: Fix an issue that will trigger a system hang due to unavailable frequency - ti: composite: Reverts a commit that breaks OMAP3" * tag 'clk-fixes-for-linus-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: spacemit: k3: add CPU PLL rate tables clk: ti: composite: resolve parent clocks by name again commit d3eea584b56fecf5c3fba0979f0da28a6600d6a3 Author: Len Brown Date: Sun May 24 17:03:47 2026 -0400 turbostat 2026.09.28 Signed-off-by: Len Brown commit 154b96dab83fd953b9b82c8bcfa041cd6a9d74d3 Author: Len Brown Date: Sun May 3 14:17:54 2026 -0400 tools/power turbostat: Fix add_counter issue if > 24 counters. We allocate space for added counters ahead of time, and we arbitrarily chose 24 added counters of each type. If a future code flow hits this limit and continues, and then removes counters, we do a phantom increment and lose track of the number of added counters. Increment the count only if there is no error. Fixes: 388e9c8134be ("tools/power turbostat: Make extensible via the --add parameter") Assisted-by: Claude: Claude Sonnet 4.6 Signed-off-by: Len Brown commit 11741cc90f9176746b8595beab4fec8d736ebd18 Author: Len Brown Date: Sun May 3 15:23:25 2026 -0400 tools/power turbostat: Fix PMT error path fd handling It is possible to leak a file descriptor if a diretory open succeeds, but the scan fails. Close the fd on error. Also, on cleanup, check for NULL fd. Assisted-by: Claude: Claude Sonnet 4.6 Fixes: 4265a86582ea ("tools/power turbostat: Add PMT directory iterator helper") Signed-off-by: Len Brown commit 5e940dd96bef6ca03b3b1b4740351237e5ec17e3 Author: Len Brown Date: Thu Apr 30 21:40:36 2026 -0400 tools/power turbostat: Fix CWF PMT off-by-one Fix off-by-one error causing last CPU on CWF to never get a pmt counter allocated. Fixes: 5ce1e9bbb2a1 ("tools/power turbostat: Add CPU%c1e BIC for CWF") Assisted-by: GitHub Copilot (claude-sonnet-4.6) Signed-off-by: Len Brown commit 767c64414c4c5fffd6cbc3a1cf1fb8138b28645b Author: Len Brown Date: Thu Apr 30 21:28:19 2026 -0400 tools/power turbostat: Fix fd_perf leak on reset When turbostat notices a topology change, it frees perf file descriptors for each CPU to prepare to re-initialize. Fix an off-by-one error in that per-cpu loop that resulted in a file descriptor leak of the file for the highest numbered CPU in the system. Fixes: 67bab430f4e7 ("tools/power turbostat: Group SMI counter with APERF and MPERF") Assisted-by: GitHub Copilot (claude-sonnet-4.6) Signed-off-by: Len Brown commit 485c59972808078570d21317de8275af47a18696 Author: Len Brown Date: Mon Jun 22 15:29:34 2026 -0400 tools/power turbostat: Sanity check GFX%rc6 and SAM%mc6 percentages When measuring over a suspend cycle, GRX%rc6 and SAM%mc6 are observed to print as numbers much greater than 100%. Those numbers are not useful, and they mess up the columns. Detect when they are out of range, and print them as NaN. Signed-off-by: Len Brown commit 148aefa949b1da358c0ebd89e61b3efd48782b82 Author: longlong yan Date: Wed Sep 2 14:59:22 2026 +0800 tools/power turbostat: add NULL check after calloc() Three calloc() calls in turbostat lack NULL return checks, leading to potential NULL pointer dereferences on allocation failure: 1. rapl_perf_init(): the allocated `domain_visited` is used later via memset(domain_visited, 0, ...) without checking for NULL. 2. added_perf_counters_init_(): the allocated `domain_visited` is used later via memset() and domain_visited[next_domain] without checking for NULL. 3. pmt_add_counter(): the allocated `pcounter` is dereferenced immediately via strncpy(pcounter->name, ...) without checking for NULL. Add NULL checks after each calloc(), using the same error handling style already present in each function: err(-1, ...) for rapl_perf_init(), errx(1, ...) for added_perf_counters_init_(), and return 1 for pmt_add_counter(). Signed-off-by: longlong yan Signed-off-by: Len Brown commit 1de8307e861759386057f8683bdf0594b2c803f0 Author: Len Brown Date: Thu Aug 13 15:27:18 2026 -0400 tools/power turbostat: Warn, but don't Err on out-dated perf systems Some systems in the field have perf enabled, but their kernel perf support lacks the latest L2 stats. Warn, but don't Err on those systems, and suggest how to avoid the Warn. Fixes: dd23bfe4c317 ("tools/power turbostat: Add L2 cache statistics") Reported-by: David Arcari Signed-off-by: Len Brown commit 25d576ed11108470d0999054265108400db1b881 Merge: 9a32e0754d637c 8e242ada093af7 Author: Linus Torvalds Date: Sat Oct 3 09:05:47 2026 -0700 Merge tag 'char-misc-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc/IIO fixes from Greg KH: "Here is a set of char/misc/iio and other small driver subsystem fixes for 7.3-rc6 that resolve a number of reported issues. Included in here are: - lots of small iio driver fixes for reported problems - interconnect driver revert to resolve a regression - nitro_enclaves driver fix for a use-after-free - binder driver fixes for reported problems (in both the rust and C versions) All of these have been in linux-next with no reported issues" * tag 'char-misc-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (63 commits) iio: adc: ad_sigma_delta: fix use-after-free on unbind iio: accel: kxcjk-1013: reject duplicate event disable iio: buffer: serialize buffer teardown with mode claims iio: cdc: ad7150: fix OF matching and publish module aliases iio: adc: ade9000: fix NULL pointer dereference in clkout registration iio: adc: ad4030: fix invalid oversampling_ratio validation iio: adc: ad7173: Fix digital filter configuration iio: adc: stm32-adc: fix possible division by zero in processed channel iio: adc: stm32-adc: fix check on internal channel availability iio: proximity: isl29501: Fix return type of isl29501_register_write iio: imu: inv_icm42607: restore runtime PM on system resume errors iio: imu: inv_icm42607: propagate runtime suspend errors iio: adc: pac1934: check ACPI label duplication rust_binderfs: add transaction_report feature entry rust_binder: reschedule node refcount update on thread exit rust_binder: cancel deferred work items in thread exit binderfs: fix UAF write in binder_add_device binder: fix is_failure flag for superseded transaction cleanup binder: fix leaked fd fixups on TF_UPDATE_TXN supersede Revert "interconnect: qcom: x1e80100: enable QoS configuration" ... commit 9a32e0754d637c1d386a533ae36e41c8f4be8b10 Merge: 903e23eda5af2a 6c95ca52f27855 Author: Linus Torvalds Date: Sat Oct 3 08:59:37 2026 -0700 Merge tag 'tty-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial fixes from Greg KH: "Here are some small tty/serial driver fixes for 7.3-rc6. Nothing major here, just lots of small fixes for reported issues, some of them very long-standing: - tty hangup fixes that have been there since the BKL days and kept tripping people up over time. - vt selection bugfix - other vt bugfixes (memory leaks and screen update fixes) - n_gsm bugfix - qcom-geni serial driver bugfix - 8250 serial driver bugfixes - other tiny serial driver fixes All of these have been in linux-next, the last few only a few days but testing here seems solid (this pull request was generated on that tree)" * tag 'tty-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (37 commits) tty: add missing driver flag kernel-doc colon vt: selection: Fix unsigned underflow and slab-out-of-bounds read in paste_selection() vt: skip screen update for DEC alignment test on backgroup consoles vc_screen: reload vc pointer before if (ret) in vcs_write() to avoid UAF serial: sc16is7xx: reduce TX refill rate with half-FIFO trigger serial: sc16is7xx: refill TX FIFO below trigger using fresh TXLVL serial: tegra: don't clear the Tx FIFO on an Rx-only reset serial: sc16is7xx: fix TX gap caused by kfifo circular buffer wrap-around tty: fix saved termios reset race tty: serial: mpc52xx_uart: move static declarations up. tty: serial: max3100: shut down timer before freeing port tty: add break_wait kernel-doc serial: qcom-geni: keep registered console runtime active serial: qcom-geni: Fix unbalanced runtime PM resume for no_console_suspend serial: qcom-geni: avoid unused-function warning tty: serial: qcom_geni_serial: Keep console RX functional after deep idle soc: qcom: geni-se: Correct QUP Core ICC vote constants serial: 8250_bcm7271: fix use-after-free in brcmuart_remove() serial: vt8500: Fix clock reference leak in vt8500_serial_probe() kgdboc: Fix tty driver reference leak in configure_kgdboc() ... commit 903e23eda5af2a5491e698838645f84a8f90379b Merge: 8623551a424d34 a93862fa670a9c Author: Linus Torvalds Date: Sat Oct 3 08:42:54 2026 -0700 Merge tag 'usb-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB/Thunderbolt fixes from Greg KH: "Here is a big set of USB and Thunderbolt driver fixes for 7.3-rc6. They were delayed on my side due to conference travel, not the fault of the submitters at all. Included in here are: - lots of small thunderbolt fixes for reported issues due to more testing and devices and a few reverts as well based on that work - more usb-serial device ids added - usb-serial and cdc-acm driver hangup and other fixes - dwc3 driver fixes for reported problems - lots of usb gadget driver fixes as people again fuzz these drivers and send in fixes, which is nice to finally see - typec driver fixes for reported problems - octeon-hcd driver fixes for reported problems - more usb-storage quirks added - other small USB driver bugs resolved for reported problems All of these have been in linux-next without any reported issues" * tag 'usb-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (63 commits) usb: dwc3: gadget: fix IRQ storm on invalid event buffer count Revert "usb: dwc3: gadget: fix IRQ storm on invalid event buffer count" USB: gadget: dummy-hcd: Fix wait for outstanding request completions usb: typec: port-mapper: Only match USB4 port if host interface is available usb: cdns3: Fix NULL pointer dereference in cdns3_pci_probe usb: dwc3: gadget: fix IRQ storm on invalid event buffer count usb: typec: ucsi: Get the connector fwnode based on reg value usb: gadget: f_uac1_legacy: validate bRequest index in generic_{set,get}_cmd usb: core: clear both ep_in and ep_out for non-ep0 control endpoints USB: cdc-acm: skip URB restart in port_shutdown if disconnected usb: gadget: f_fs: Fix NULL pointer dereference in FUNCTIONFS_ENDPOINT_DESC usb: gadget: aspeed-vhub: cancel wake work on device removal thunderbolt: Disable CL states for the Anker Prime TB5 dock thunderbolt: stream: Announce support for FMODE_NOWAIT usb: typec: ucsi: displayport: Current CAM OOB index fixup usb: ohci-st: disable controller wakeup on removal usb: ohci-spear: disable controller wakeup on removal usb: ohci-s3c2410: disable controller wakeup on removal usb: ohci-da8xx: disable controller wakeup on cleanup usb: cdns3: fix use-after-free in cdns3_gadget_exit() ... commit 8623551a424d34a311bab3fb9243535c98e08c26 Merge: f7c918b8d9f789 3bf8d603fd4564 Author: Linus Torvalds Date: Sat Oct 3 08:10:37 2026 -0700 Merge tag 'input-for-v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: - A fix for the Samsung S6SY761 touchscreen driver to power on the controller before unmasking interrupts during resume and to re-enable touch sensing when the device is open - Updates to the Synaptics touchpad driver to enable SMBus/RMI4 mode on Lenovo ThinkPad T490 and restrict the ThinkPad T440p InterTouch disable quirk to LEN0036 so that ThinkPad L440 retains SMBus support - A quirk for the AT keyboard driver (atkbd) to skip keyboard deactivation on Lenovo IdeaPad Slim 3 15IWC11 so the internal keyboard functions properly - A DMI quirk for the i8042 controller to disable active multiplexing on Fujitsu LIFEBOOK U7410, preventing the internal keyboard and touchpad from dying shortly after boot. * tag 'input-for-v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: atkbd - skip deactivate for Lenovo IdeaPad Slim 3 15IWC11 Input: s6sy761 - fix resume ordering and restore sensing Input: synaptics - limit T440p InterTouch quirk to LEN0036 Input: i8042 - add nomux quirk for Fujitsu LIFEBOOK U7410 Input: synaptics - add LEN205b entry to smbus_pnp_ids for ThinkPad T490 commit f7c918b8d9f789e79ebedbc7660b682aa1984210 Merge: c5adb6c8a26d65 9c979cba980522 Author: Linus Torvalds Date: Sat Oct 3 08:02:40 2026 -0700 Merge tag 'drm-fixes-2026-10-03' of https://gitlab.freedesktop.org/drm/kernel Pull drm fixes from Dave Airlie: "Live from Brisbane airport, it's Saturday Night drm fixes. The misc fixes tree didn't get a PR this week, so I'll probably have that to you when I see it, there were a few patches in there. Otherwise amdgpu is the main act, mediatek has a guest spot, and xe/i915 bring in a fix each. xe: - keep VF LMEM bar size low if no VFs enabled i915: - Disable VRR DC balance by default to fix timing issues mediatek: - Add missing IS_ERR check for ovl_adaptor platform device - Fix VID_DOWNSAMPLE_CONFIG register offset - Fix pdev reference leak in mtk_drm_bind() - Fix runtime PM leak in mtk_hdmi_ddc_v2_probe() - Fix ovl adaptor platform device leak amdgpu: - dc_state_create_copy() fix - HDMI RGB limited range fix - eDP ASSR fix - DCE 6 fixes - DCE 8.1 fix - SI DPM fixes - Reset fixes - Workaround for multiple SDMA entities with DCC - PWM backlight fix - GPUVM fixes - Switcheroo fix - Error handling leak fixes - GC 6 unload FW leak fix - SDMA 7.1 fix - DML frame size limit fix - RGB vs YCbCr 4:4:4 fix - DP MST fix - DC Power module fixes - MacBookPro14,3 fix amdkfd: - SVM fix radeon: - sparc64 fix" * tag 'drm-fixes-2026-10-03' of https://gitlab.freedesktop.org/drm/kernel: (36 commits) drm/mediatek: Fix ovl adaptor platform device leak drm/mediatek: Fix runtime PM leak in mtk_hdmi_ddc_v2_probe() drm/mediatek: Fix pdev reference leak in mtk_drm_bind() drm/amdgpu: reset VI ASIC on MacBookPro14,3 drm/amd/pm/si: Fix updating clock limits on AC/DC drm/amd/display: Fix stale replay_events after mod_power stream removal drm/radeon: Read the VRAM VBIOS signature with readb() drm/amd/display: guard dc_sink dereferences in MST mode validation drm/amd/display: Try RGB before YCbCr 4:4:4 in stream validation drm/amd/display: Fix sanitizer check for the DML frame size limit drm/amdgpu/gmc12.1: properly pass flush_type to gmc_v12_1_flush_vm_hub() drm/amdgpu: drop userq callback assignment for sdma 7.1 drm/amdgpu/gfx6: fix firmware leak on teardown drm/amdgpu: fix ACP MFD device leak on init failure drm/amdgpu: fix IP instance memory leak on kobject add failure drm/amdgpu: skip the noirq suspend reset for a switcheroo-parked GPU drm/amdgpu/gmc12: properly pass flush_type to gmc_v12_0_flush_vm_hub() drm/amd/display: map PWM brightness through custom backlight curve drm/amdgpu: implement workaround for sdma dcc corruption drm/amdkfd: Fix always mapped range mapping to all ACCESS GPUs ... commit c5adb6c8a26d653fe1d0ee52908d998f7471e9eb Merge: e767a4ea70a399 e060d9069b49fe Author: Linus Torvalds Date: Sat Oct 3 07:54:58 2026 -0700 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "Half of this is broken hardware (AMU counters and TLB invalidation) and the other half is broken software (frequency scaling and signals). So it seems as though we're all as bad as each other. The AMU workaround is a little noisy, as it refactors an existing workaround so that it can more easily be applied to additional CPUs. Summary: - Fix handling of CPU erratum #2645198 when batching pte updates - Fix truncation of CPU frequency calculation by using 64-bit arithmetic in arch_freq_get_on_cpu() - Work around AMU erratum #3821522 on Cortex-A725 - Fix panic when trying to restore an SVE sigframe on a CPU that only supports SME" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems arm64: errata: Add Cortex-A725 erratum 3821522 workaround arm64: errata: Factor out broken AMU const counter cap arm64: topology: fix arch_freq_get_on_cpu() overflow above 4.19 GHz arm64: mm: Fix the break-before-make flush range for erratum 2645198 commit 13dffca9043500ed6033d770b491a043fb952bc5 Author: Jaidheer Sirigineedi Date: Fri Oct 2 13:59:51 2026 -0500 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg3xxx (103c:8bfd) The mute LED on the HP Pavilion Laptop 15-eg3xxx (PCI SSID 103c:8bfd, Realtek ALC287) does not work because the machine has no entry in the quirk table. No fixup is applied, so the mute LED is never driven, even though the mute function itself works. The LED is controlled via GPIO pin 4 (mask 0x10), which is exactly what ALC287_FIXUP_HP_GPIO_LED configures. This was verified on the hardware with hda-verb: setting the GPIO data bit lights the mute LED, and clearing it turns the LED off. hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x10 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION 0x10 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x10 # LED on hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x00 # LED off Add a quirk entry for 103c:8bfd using ALC287_FIXUP_HP_GPIO_LED. Signed-off-by: Jaidheer Sirigineedi Link: https://patch.msgid.link/20261002185951.33855-1-jaidheer7@gmail.com Signed-off-by: Takashi Iwai commit 408249089c48df1a4d23f60b831be3f3c311e6d1 Author: Mohamed Yassine Jebabli Date: Thu Oct 1 12:24:42 2026 +0200 ALSA: hda/tas2781: Accept V1 calibration data without CRC 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 commit 593d46fc6af9a0178a46e77d6d24b20d2314165f Author: Harin Lee Date: Thu Oct 1 23:45:01 2026 +0900 ALSA: ctxfi: Fix memory leakage when clearing DAO input mappers 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 commit 9a44b828dd7c0be1d0d6d6cf178d9727ceb6da6e Author: Eckhart Mohr Date: Thu Oct 1 20:34:00 2026 +0200 ALSA: hda/realtek: Add quirk for ASRock NUC BOX-358H Fix headphone jack detection for some devices Signed-off-by: Eckhart Mohr Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20261001183403.103990-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai commit 4e1462e7cd6a9b920f441842726cc2b9d232673e Author: Matus Gajdos Date: Fri Oct 2 14:52:37 2026 +0200 ALSA: usb-audio: Add native DSD support for Cambridge Audio streamers The Cambridge Audio streamer advertises the UAC2 RAW_DATA format on altsetting 2 of its playback interface, but without the DSD_RAW quirk flag the driver exposes it only as a SPECIAL format that cannot be used. Add QUIRK_FLAG_DSD_RAW for the device (USB ID 22e8:ca10), so the altsetting is exposed as DSD_U32_BE, enabling native DSD64/128/256 playback. Tested with: gst-launch-1.0 filesrc location=file.dsf ! \ avdemux_dsf ! dsdconvert ! \ alsasink device=hw:2,0 Signed-off-by: Matus Gajdos Link: https://patch.msgid.link/20261002125237.82188-1-matuszpd@gmail.com Signed-off-by: Takashi Iwai commit 4aa9c0f377a4de5e8fddce76b34ee4529639a1ff Author: Sang-Hoon Choi Date: Wed Sep 30 16:08:58 2026 +0900 nvmet: use the local P2P device on metadata allocation failure 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 commit b3ce7572130f7bdc71581d798df3fbfc3b64e7a5 Author: Palla Raghunath Date: Wed Sep 30 07:26:47 2026 +0100 nvme-multipath: revalidate head zones after unfreezing the head queue When a namespace on a multipath controller is updated, nvme_update_ns_info() freezes the head disk queue, commits the new limits, and then calls nvme_mpath_revalidate_zones() before it unfreezes the queue again. That is the wrong way round for blk_revalidate_disk_zones(). It starts a limits update, which takes q->limits_lock, and it freezes the queue itself while updating the zone resources. The block layer takes limits_lock before freezing the queue, never the other way around, so calling it with the head queue already frozen reverses that order. syzbot has hit this twice. One report goes through q->limits_lock. The other one is on linux-next, where blk_revalidate_disk_zones() also takes disk->zone_revalidate_mutex and holds it across alloc_workqueue() the first time a disk's zone resources are set up. Lockdep then sees: q_usage_counter(io) (frozen head queue, nvme_update_ns_info()) --> &disk->zone_revalidate_mutex --> wq_pool_mutex --> fs_reclaim --> q_usage_counter(io) WARNING: possible circular locking dependency detected kworker/u8:10/3352 is trying to acquire lock: (&disk->zone_revalidate_mutex){+.+.}-{4:4}, at: blk_revalidate_disk_zones+0x1c5/0x1650 but task is already holding lock: (&q->q_usage_counter(io)#75){++++}-{0:0}, at: nvme_update_ns_info+0x3ac/0x1200 ... blk_revalidate_disk_zones+0x1c5/0x1650 block/blk-zoned.c:2560 nvme_mpath_revalidate_zones+0x106/0x1c0 drivers/nvme/host/multipath.c:301 nvme_update_ns_info+0x984/0x1200 drivers/nvme/host/core.c:2620 The rest of the driver already does this correctly: nvme_update_ns_info_block() unfreezes ns->disk->queue before calling blk_revalidate_disk_zones(), and nvme_mpath_set_live() revalidates the head zones without freezing the queue. Do the same here, and only revalidate the head zones once the queue is unfrozen and the limits update has succeeded. Fixes: 224041412693 ("nvme-multipath: revalidate zones for namespace heads") Reported-by: syzbot+b0910be96b7c31314822@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b0910be96b7c31314822 Reported-by: syzbot+2e02ccadb3c5522a5c59@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2e02ccadb3c5522a5c59 Link: https://lore.kernel.org/all/2bfc96f2-7d0d-47e0-936e-8810abb31a9f@acm.org/ Cc: Shuah Khan Cc: Brigham Campbell Reviewed-by: Damien Le Moal Reviewed-by: Yao Sang Tested-by: Yao Sang Signed-off-by: Palla Raghunath Signed-off-by: Keith Busch commit 564e46d9f6e87912effa03f123d37a511d520f09 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 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 commit d99bc5b456fd63be46c8bda20dbf6ede93d2fc11 Author: Guixin Liu Date: Sun Sep 20 11:34:59 2026 +0800 nvmet: return Invalid Field for invalid NSIDs feature 82h 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 commit 3bf8d603fd45649c106cae6290a10f20b1bbb569 Author: Martino Papero Date: Wed Sep 30 22:10:41 2026 +0200 Input: atkbd - skip deactivate for Lenovo IdeaPad Slim 3 15IWC11 The internal keyboard on the Lenovo IdeaPad Slim 3 15IWC11 (83RR) does not work correctly with the default i8042 settings. Using i8042.nopnp=1 and i8042.dumbkbd=1 restores keyboard input, but prevents the Caps Lock LED from working. Using i8042.nopnp=1 alone does not fix the keyboard. The laptop works correctly when atkbd_deactivate_fixup is used instead. Add a DMI quirk for the 83RR to enable it. This was tested without any i8042 command-line parameters. Keyboard input and the Caps Lock LED work correctly, including after suspend and resume and after a cold boot. Link: https://lore.kernel.org/all/4f43465f-98ba-4722-8e29-03df20315369@kernel.org/ Signed-off-by: Martino Papero Reviewed-by: Hans de Goede Link: https://patch.msgid.link/c0b597b8-e7ad-4fba-a2bb-5d252e3dfbd3@lcb.to.it Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov commit e767a4ea70a3992c37ed604157d32f0dfbf9b1e3 Merge: ff47652a4b66c0 7a39c732a22ec4 Author: Linus Torvalds Date: Fri Oct 2 17:34:18 2026 -0700 Merge tag 'probes-fixes-v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull probes fixes from Masami Hiramatsu: - fprobe: Use guard(rcu_sched_notrace) and check rcu_is_watching() Exit handlers early if !rcu_is_watching() to prevent potential use-after-free during unregistration in idle/quiescent states. Switch to guard(rcu_sched_notrace) to avoid fast-path lockdep overhead and recursion while ensuring safe grace period synchronization. - kprobes: Skip disarmed probes when checking optkprobe overlap Continue past disarmed or unprepared probes in get_optimized_kprobe() to find active optimized probes. This avoids overwriting active jump displacements which can lead to panic. * tag 'probes-fixes-v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: kprobes: Skip disarmed probes when checking optkprobe overlap fprobe: Use guard(rcu_sched_notrace) and check rcu_is_watching() commit 9c979cba980522f044ea2b14d8cab87ea3cddb56 Merge: 47400a32d0d204 a22e5e4f2ebbdb Author: Dave Airlie Date: Sat Oct 3 09:32:39 2026 +1000 Merge tag 'amd-drm-fixes-7.3-2026-10-01' of https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.3-2026-10-01: amdgpu: - dc_state_create_copy() fix - HDMI RGB limited range fix - eDP ASSR fix - DCE 6 fixes - DCE 8.1 fix - SI DPM fixes - Reset fixes - Workaround for multiple SDMA entities with DCC - PWM backlight fix - GPUVM fixes - Switcheroo fix - Error handling leak fixes - GC 6 unload FW leak fix - SDMA 7.1 fix - DML frame size limit fix - RGB vs YCbCr 4:4:4 fix - DP MST fix - DC Power module fixes - MacBookPro14,3 fix amdkfd: - SVM fix radeon: - Sparc64 fix Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patch.msgid.link/20261001230115.1319089-1-alexander.deucher@amd.com commit 47400a32d0d2041a294fc6592a7956b4ec9ce0a0 Merge: 26fe67ec0dca01 048739be3e9cac Author: Dave Airlie Date: Sat Oct 3 09:27:36 2026 +1000 Merge tag 'mediatek-drm-fixes-20261002' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes Mediatek DRM Fixes - 20261002 1. Add missing IS_ERR check for ovl_adaptor platform device 2. Fix VID_DOWNSAMPLE_CONFIG register offset 3. Fix pdev reference leak in mtk_drm_bind() 4. Fix runtime PM leak in mtk_hdmi_ddc_v2_probe() 5. Fix ovl adaptor platform device leak Signed-off-by: Dave Airlie From: Chun-Kuang Hu Link: https://patch.msgid.link/20261001234906.14940-1-chunkuang.hu@kernel.org commit f2e695a6c27241374c9b007b718361badccb2f63 Author: Imre Kaloz Date: Thu Sep 24 12:12:45 2026 +0200 MAINTAINERS: update my email address Switch my contact address to kaloz@kernel.org and update .mailmap. Signed-off-by: Imre Kaloz Link: https://lore.kernel.org/r/20260924101245.5011-1-kaloz@kernel.org Signed-off-by: Arnd Bergmann commit e984d7bf468948179c6db506e74a8ed2896f29d6 Merge: 8166a325157ad6 3c0d2f1f431c51 Author: Arnd Bergmann Date: Fri Oct 2 23:39:01 2026 +0200 Merge tag 'optee-fixes-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into arm/fixes OP-TEE fixes for v7.3 - Register the TEE devices only once fully initialized - Support FF-A shared memory offsets on large-page kernels * tag 'optee-fixes-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee: tee: optee: ffa: support shared memory offsets on large-page kernels optee: register TEE devices only once fully initialized Signed-off-by: Arnd Bergmann commit 8166a325157ad6e4b4c3ae8295ad800461e4b081 Merge: 26fb480bee21a0 7ba5290db6bf36 Author: Arnd Bergmann Date: Fri Oct 2 23:38:27 2026 +0200 Merge tag 'imx-fixes-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into arm/fixes iMX fixes for 7.3 - Fix incorrect pinmux values for LX2160A. - Fix Sonata SD I/O supply to avoid filesystem I/O errors because the kernel was disabling LDO5 during late init. * tag 'imx-fixes-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux: arm64: dts: imx8mp-var-dart-sonata: Fix Sonata SD I/O supply arm64: dts: lx2160a: fix the iic5 spi3 pinmux offset and value arm64: dts: lx2160a: fix IIC1 pinmux submask rejected by pinctrl-single arm64: dts: lx2160a: fix incorrect pinmux Signed-off-by: Arnd Bergmann commit 26fb480bee21a025b89fc2307b09a29d21ee0d9e Merge: 1d0f326d2d5b8b 35ce3c571297ae Author: Arnd Bergmann Date: Fri Oct 2 23:34:21 2026 +0200 Merge tag 'qcom-arm64-fixes-for-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes Qualcomm Arm64 DeviceTree fix for v7.3 Fix microphone distortion on Hamoa and Purwa-based Surface Pro 11. * tag 'qcom-arm64-fixes-for-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: dts: qcom: x1-denali: Fix microphone distortion Signed-off-by: Arnd Bergmann commit 1d0f326d2d5b8b88bd6bde2bddbf415be4b90524 Merge: 72d3fcf802c45d 55981579b27b65 Author: Arnd Bergmann Date: Fri Oct 2 23:33:58 2026 +0200 Merge tag 'qcom-clk-fixes-for-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes Qualcomm clock fixes for v7.3 Mark Kaanapali and Glymur GPU CX GDSC's voteable to use the right programming model. Fix the PCIE_RSCC clock programming in Eliza, Kaanapali, and Hawi. * tag 'qcom-clk-fixes-for-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: clk: qcom: gpucc-kaanapali: Mark the GPU CX GDSC as votable clk: qcom: gpucc-glymur: Mark the GPU CX GDSC as votable clk: qcom: gcc-kaanapali: Fix always-enabling PCIE_RSCC clocks clk: qcom: gcc-hawi: Fix always-enabling PCIE_RSCC clocks clk: qcom: gcc-eliza: Fix always-enabling PCIE_RSCC clocks Signed-off-by: Arnd Bergmann commit ff47652a4b66c067c765a7ad464d930b5a9367cc Merge: 8f150ccedfbd61 19465a9aeb664f Author: Linus Torvalds Date: Fri Oct 2 14:04:11 2026 -0700 Merge tag 'cifs-fixes-7.3-rc6' of https://git.manguebit.org/linux Pull smb client fixes from Paulo Alcantara: "Fix a series of data corruption and I/O error bugs found by running generic/363 (fsx) in a loop against Windows Server 2022 and Samba. - Stop data dirtied past EOF through an mmap from reappearing as file content once the file is extended by a write, truncate, zero range, copy range or clone range - Flush dirty data and drain in-flight I/O before operations that assume the pagecache and the server agree on the file: querying allocated ranges, the O_TRUNC open, interior zero range, and server-side copy/clone - Stop a genuine size-extending zero range or preallocate from being refused with -EOPNOTSUPP when the inode is not read caching, by querying the server's authoritative EOF instead of trusting a stale cached i_size - Zero the untransferred tail of a short read, both in the netfs read-gaps path (where stale folio content could otherwise be written back to the server) and in the DIO/unbuffered read collector, and tell a real EOF apart from a stale cached remote_i_size after a lease downgrade - Require stable pages on signed connections so a buffered write can't modify a folio whose signature has already been computed and is in flight, which the server rejected with STATUS_ACCESS_DENIED and the client surfaced as -EIO - Split several cifsFileInfo flags out of a shared bitfield byte so concurrent updates taken under different locks no longer clobber each other through a byte-level RMW" * tag 'cifs-fixes-7.3-rc6' of https://git.manguebit.org/linux: smb: client: split cifsFileInfo bitfields to avoid shared-byte RMW races smb: client: require stable pages for signed connections smb: client: distinguish real EOF from a stale remote_i_size on read netfs: zero the tail of a short DIO/unbuffered read smb: client: only require read lease for size-extending preallocate netfs: zero gaps in read-gaps folio to avoid writing back stale data smb: client: only require read lease for size-extending zero range smb: client: drain and invalidate before server-side copy/clone smb: client: flush dirty data before zeroing a range smb: client: drain outstanding I/O before truncating on O_TRUNC open smb: client: flush and commit data before querying allocated ranges smb: client: discard post-EOF pagecache when extending a file via clone range smb: client: discard post-EOF pagecache when extending a file via copy range smb: client: discard post-EOF pagecache when extending a file via zero range smb: client: clear post-EOF pagecache when extending a file via truncate netfs: clear post-EOF pagecache when extending a file via write commit 6dc989ea46b96ce170840174b4a38c4a387fb005 Merge: 8b1f0af1fd5fd1 58858b8f14803a Author: Jakub Kicinski Date: Fri Oct 2 13:38:09 2026 -0700 Merge branch 'intel-wired-lan-driver-updates-2026-09-28-idpf-ice-iavf' Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2026-09-28 (ice) [part] For ice: Xuanqiang Luo resolves a use-after-free issue by changing order of operations so index is used before being freed. Bryan Fraschetti restores ordered MMIO writes for ice Tx doorbells by replacing writel_relaxed() call with writel(). Tristan Madani fixes representor use-after-free by releasing metadata_dst through dst_release() to ensure it is not freed until all references are dropped. ==================== Link: https://patch.msgid.link/20260928230429.495442-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski commit 58858b8f14803a7eeac297b3ce20f3b21bf2ff66 Author: Tristan Madani Date: Mon Sep 28 16:04:25 2026 -0700 ice: fix metadata_dst refcount handling on representor teardown 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 commit 7a579dec8423bba7bec96fcfcb2e30838b0858ee Author: Bryan Fraschetti Date: Mon Sep 28 16:04:24 2026 -0700 ice: Restore Ordered MMIO Writes for Tx Doorbells 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 commit 1402fc67d2f4e2e1fc7bf8ee0825b8ad994557ff Author: Xuanqiang Luo Date: Mon Sep 28 16:04:23 2026 -0700 ice: fix use-after-free in dynamic port cleanup 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 commit 8b1f0af1fd5fd113432233ed8a3862ee7c30a84f Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Sep 30 19:25:24 2026 +0900 tcp: reject net_iov in zerocopy receive mapping hints 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 commit 8f150ccedfbd610aa25509ff42365d70fb20478f Merge: d2dbe503fd8060 de020dc8049bfb Author: Linus Torvalds Date: Fri Oct 2 12:59:32 2026 -0700 Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Pull bpf fixes from Alexei Starovoitov: - Fix overflow of backward jump offset in constant blinding (Alexei Starovoitov) - Fix packet range of packet pointers sharing an id when var_off tightens umax of one pointer and not the other (Alexei Starovoitov) - Fix objects stuck in free_by_rcu_ttrace list of bpf memalloc (Alexei Starovoitov) - Fix use-after-free of progs detached from busy trampolines: wait for an RCU tasks grace period before freeing trampoline progs, and patch detached progs out of trampoline images that are still in use (Florent Revest) - Hold map BTF for the memory allocator destructor record to fix UAF in deferred bpf_mem_alloc destruction (Kumar Kartikeya Dwivedi) - Fix missing migration protection in resizable hashtab lookup_and_delete batch operation (Ömer Mete Kaya) * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf: Fix missing migration protection in __rhtab_map_lookup_and_delete_batch() selftests/bpf: Add a test for objects stuck in free_by_rcu_ttrace bpf: Fix objects stuck in free_by_rcu_ttrace bpf: Factor out __do_call_rcu_ttrace() selftests/bpf: Test packet range of pointers sharing an id bpf: Fix packet range of pointers sharing an id selftests/bpf: Detach a trampoline prog while a task sleeps before it bpf: Skip detached progs in trampoline images that are still in use bpf: Wait for an RCU tasks grace period before freeing trampoline progs bpf: Hold map BTF for the memory allocator destructor record bpf: Fix overflow of jump offset in constant blinding commit bcf2573a68a808a5b54cadafa72b6672e662c2bf Author: Suraj Gupta Date: Tue Sep 29 00:12:07 2026 +0530 net: xilinx: axienet: Free outstanding DMA buffers on dmaengine stop In the dmaengine path the driver pre-submits RX buffers and holds in-flight TX buffers whose SKBs are DMA-mapped by the driver and freed only in the completion callbacks. On ndo_stop() dmaengine_terminate_sync() aborts these descriptors without running their callbacks, and the driver then frees only the ring shells, leaking every SKB still owned by the engine and its DMA mapping on each ifdown. With 128 RX buffers pre-posted per channel, the mapping leak can eventually exhaust a limited IOMMU aperture. Clear the slot's skb in the TX and RX callbacks so a non-NULL skb marks a slot that still owns a live, DMA-mapped buffer, and on stop unmap and free every such buffer. axienet_dma_rx_cb() runs from the DMA tasklet and re-arms the RX ring on each completion, so it can race axienet_stop(): a completion may submit a fresh buffer after dmaengine_terminate_sync() has returned, leaving the channel armed with a buffer the teardown then frees while the engine may still write into it (dma_release_channel() does not stop it either). Add a lock that axienet_dma_rx_cb() holds across the @stopping check and the resubmit, and axienet_stop() holds to set @stopping before terminating. Once @stopping is set no callback can arm a new buffer, and any armed just before is aborted by the terminate, so teardown only frees buffers the engine no longer owns. Fixes: 6a91b846af85 ("net: axienet: Introduce dmaengine support") Cc: stable@vger.kernel.org Signed-off-by: Suraj Gupta Link: https://patch.msgid.link/20260928184207.2361931-1-suraj.gupta2@amd.com Signed-off-by: Jakub Kicinski commit d2dbe503fd806082acb0ca79a9d6641822988c2c Merge: 3b7cab693ba2ba 40cce45b921f79 Author: Linus Torvalds Date: Fri Oct 2 12:45:08 2026 -0700 Merge tag 'pci-v7.3-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fix from Bjorn Helgaas: - Allow driver to use AtomicOps if already enabled by hypervisor; fixes regression when Root Port is not visible in a guest (Nikola Prica) * tag 'pci-v7.3-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: Accept AtomicOps already enabled by the hypervisor commit 184b5ddf82d45d6f75cc83719a2e453392512bd2 Author: Jakub Kicinski Date: Wed Sep 30 18:26:39 2026 -0700 bonding: fix the program leak when XDP is replaced We need to release the reference on the old BPF prog, whether we are going to no-prog, or replacing the prog with another. Spotted by AI while running tests for the propagation series (leaked programs were accumulating). Selftest will come in the net-next series to avoid conflicts. Fixes: 9e2ee5c7e7c3 ("net, bonding: Add XDP support to the bonding driver") Fixes: 6d5f1ef83868 ("bonding: Fix negative jump label count on nested bonding") Acked-by: Daniel Borkmann Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20261001012639.298690-1-kuba@kernel.org Signed-off-by: Jakub Kicinski commit 3b7cab693ba2bab63774bf5b988e8a61b2ef0f32 Merge: 3f1fe48a36b0b6 684b413b5483f5 Author: Linus Torvalds Date: Fri Oct 2 12:25:40 2026 -0700 Merge tag 'block-7.3-20261002' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull block fixes from Jens Axboe: - NVMe fixes via Keith: - Fix an out-of-bounds write in nvmet_auth_challenge(), where sizeof() on a void pointer undercounted the challenge header and let a short AUTH_RECEIVE buffer pass the check - nvme-multipath fixes for an ANA log bounds check underflow, the command effects log lifetime for multipath heads, and only setting BLK_FEAT_ZONED after the zone info is known. - nvmet fixes for ns->enabled teardown ordering, rejecting I/O after the percpu ns reference is killed, device path preservation on allocation failure, and too-short SGL segments in pci-epf - nvme-tcp: revert the per-socket dynamic lockdep keys, and delay the socket reclassification - A DMA pool alignment quirk for the Micron 4100AT - Controller state/reset race fixes, and -Wformat-security workarounds - blk-mq: set RQF_USE_SCHED when the operation is known, and allow cached requests to be used for flush operations - Reject polled dio with user integrity metadata - Save the IRQ state in blkg_tryget_closest() - Set the zone write granularity in virtio_blk - ublk selftest fixes * tag 'block-7.3-20261002' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: (23 commits) virtio_blk: set the zone write granularity nvme-multipath: set BLK_FEAT_ZONED only after the zone info is known nvme: fix command effects log lifetime for multipath heads nvmet: don't allow I/O admission after percpu ns reference is killed nvmet: defer setting ns->enabled to false in nvmet_ns_disable() nvmet: copy the hostid into the ctrl before creating PR pc_refs nvmet-auth: fix out-of-bounds write in nvmet_auth_challenge() nvmet: pci-epf: reject too-short SGL segments nvme-multipath: fix underflow in ANA log bounds checks nvme: work around all -Wformat-security warnings nvme: work around -Wformat-security warning nvme: do not reset controllers in NVME_CTRL_NEW state nvme-tcp: delay nvme_tcp_reclassify_socket() Revert "nvme-tcp: lockdep: use dynamic lockdep keys per socket instance" drbd: remove unused drbd_nl_mcgrps[] array blk-mq: allow cached requests to be used for flush operations blk-mq: set RQF_USE_SCHED when the operation is known block: reject polled dio with user integrity metadata selftests: ublk: fix unused_result error blk-cgroup: save IRQ state in blkg_tryget_closest() ... commit 3f1fe48a36b0b6722dc3fd421d93512bac138e9a Merge: 5d144c294ae21c a92193c91e8839 Author: Linus Torvalds Date: Fri Oct 2 12:17:24 2026 -0700 Merge tag 'io_uring-7.3-20261002' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull io_uring fixes from Jens Axboe: - Fix a task_work add use-after-free with SQPOLL. The sqpoll thread could pop and complete the last request while io_req_normal_work_add() was still looking at them after the mpscq push. Use the same approach as DEFER_TASKRUN to protect from that, holding an RCU read lock across the add, and have exit wait for an RCU grace period for SQPOLL rings as well. - CQE32 ring fixes: correct the free entry check for 32b CQEs, zero the big_cqe for aux CQEs, and only post the dummy skip CQE on CQE_MIXED rings - Mark the source filter table as COW when cloning bpf filters, so registering another filter on the source doesn't modify the shared table in place - Initialize the task context before running the BPF loop - Requeue zcrx multishot receives stopped by a local resource - End a TX_TIMESTAMP multishot cmd when the CQ is full (lollipopkit) * tag 'io_uring-7.3-20261002' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: io_uring: fix task_work add use-after-free with SQPOLL io_uring/cmd_net: end TX_TIMESTAMP multishot when the CQ is full io_uring/zcrx: requeue multishot receives stopped by a local resource io_uring: initialize task context before running the BPF loop io_uring: zero big_cqe for aux CQEs on CQE32 rings io_uring: fix free entry check for 32b CQEs on CQE32 rings io_uring: only post the dummy skip CQE on CQE_MIXED rings io_uring/bpf_filter: mark source as COW when cloning filters commit 5d144c294ae21c1bfb275ba06ec73c2d1ab7cf92 Merge: ac7445c28e7a28 b4e7fc36e31f59 Author: Linus Torvalds Date: Fri Oct 2 12:08:41 2026 -0700 Merge tag 'sound-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A fair amount of small fixes, which became much larger as a pile of pending homework during my vacation in the last weeks. The majority of changes are device-specific quirks and ASoC updates, along with a few ALSA core fixes and USB-audio hardening as well as a few regression fixes. ALSA Core: - Serialize ALSA sequencer compat port-info ioctls HD-audio: - Fix ALC235 codec headset handling - Fix regression on Tegra194 controller support - Quirks / fixes for Lenovo, ASUS, Acer, Dell, Higole, HP, and IPASON laptops USB-audio: - Hardening for line6 and ua101 drivers to deal with malformed packets - Fix input device leak on probe error in caiaq driver - Apply quirks generically for Audient and Behringer devices - Quirks for ASUS SupremeFX Hi-Fi, HiBy FC4 (native DSD), and MSI MAG B850M MORTAR WIFI ASoC: - Runtime PM fixes for SDCA class function driver - Fix uninitialized stream configs in RT1017 and MAX98363 SDW codecs - AMD ACP SoundWire support for ASUS and Lenovo models - Quirks for Intel machines (Lenovo Yoga Slim 7, Chuwi Hi8) - Qualcomm LPASS fixes for playback constraints and WSA macro volume - Codec / platform fixes for rt274/rt286, cs42l43, wm8903, Tegra ASRC Misc: - Regression fix for silent playback on Creative Titanium HD - Error handling fix at probe via auto-cleanup in ice1712" * tag 'sound-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (53 commits) spi: cs42l43: Workaround for wrong speaker ID on Dell XPS 13 DX13260 ALSA: ice1712: Fix the error handling via auto-cleanup at probe ALSA: core: Define auto-cleanup for snd_card_free() ALSA: hda/realtek: Add ALC235 support for headset mode ALSA: hda/realtek: Add micmute LED quirk for Acer Swift SFG16-72 ALSA: hda/realtek: Fix mute and micmute LEDs on HP ENVY x360 15-ey0xxx ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 14-dv1001TU ALSA: ctxfi: Fix silent playback on Titanium HD (SB1270) ALSA: usb-audio: Apply IGNORE_CTL_ERROR quirk to all Audient devices ALSA: usb-audio: Apply boot quirk for Behringer models generically ASoC: codecs: lpass-wsa-macro: rewrite the interpolator volume after enabling clocks ALSA: hda/realtek: Fix speakers on ASUS PM3406CHA ALSA: hda/realtek: Add quirk for HP Pavilion AiO 24 speaker ALSA: hda/realtek: Add mute LED quirk for HP Laptop 15-fd2xxx ASoC: amd: acp-config: Add ACP70 DMI quirk for ASUS UM5406GA ALSA: hda/realtek: Add mute LED quirks for HP Pavilion 15-eh3174nw and HP Laptop 15-dw1xxx ASoC: Intel: Add quirk to block match table for Lenovo Yoga Slim 7 ALSA: hda/realtek: Add mute LED quirk for HP Victus 15-fb2xxx ALSA: hda/realtek: Add quirk for Acer Nitro AN515-45 ALSA: hda/realtek: Add quirk for Lenovo ThinkBook G8+ ... commit 23b1ab15ca91f2cffaf149d9bb0fafeb700c7db2 Author: Waiman Long Date: Fri Oct 2 12:54:38 2026 -0400 cgroup/cpuset: Handle cpu hotplug race in guarantee_active_cpus() 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 commit ac7445c28e7a28d5131bc9f9a143261e79495027 Merge: 4e9a2de02fedd0 eb13a1ff271b0d Author: Linus Torvalds Date: Fri Oct 2 11:28:45 2026 -0700 Merge tag 'random-7.3-rc6-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random Pull random number generator fixes from Jason Donenfeld: - VMGENID memory needs to be mapped with the decrypted tag, so that SEV-SNP machines can boot - A fix for an initialization race in VMGENID, followed by a cleanup - Trivial kernel doc cleanups in siphash and random.c - A fix for a new compilation failure with recent clang on PPC and RISC-V, due to generating an out-of-line memset in the vDSO * tag 'random-7.3-rc6-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random: random: vDSO: avoid call to memset() when zeroing reserved parameter random: fix vgetrandom_opaque_params kernel-doc random: vDSO: fix repeated word 'to' in comment siphash: clean up kernel-doc comments virt: vmgenid: move to using dev_set/get_drvdata virt: vmgenid: set driver_data before registering notification handlers virt: vmgenid: remap memory as decrypted commit 4e9a2de02fedd0137f058a6e69848072a20f8f34 Merge: 5e0f8396d4805a af2fb3ee6679b5 Author: Linus Torvalds Date: Fri Oct 2 10:51:34 2026 -0700 Merge tag 'slab-for-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/slab Pull slab fixes from Vlastimil Babka: - Stable fix for a potential deadlock in kfree_rcu() when called from set_cpus_allowed_force() (Harry Yoo) - MAINTAINERS update of the slab.git URL * tag 'slab-for-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/slab: mm/slab: do not wake up kswapd in __kfree_rcu_sheaf() MAINTAINERS: update slab.git URL commit 5e0f8396d4805a3e7f753fa58c8c55f1f3cc2160 Merge: 17a58009754886 3f35b678a1d6b4 Author: Linus Torvalds Date: Fri Oct 2 09:51:11 2026 -0700 Merge tag 'hid-for-linus-2026100201' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Benjamin Tissoires: - Revert of the Bolt integration into hid-logitech-dj (Benjamin Tissoires) - A couple of buffer overflow in Intel-thc-hid (Even Xu) - A couple of Sashiko findings fixes in hid-multitouch and HID-BPF (Aldo Ariel Panzardo and Benjamin Tissoires) * tag 'hid-for-linus-2026100201' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: selftest/hid: add test for negative return codes for hid_bpf_hw_request HID: bpf: cast size to ssize_t when checking hid_bpf_hw_request HID: Intel-thc-hid: Intel-quickspi: Fix buffer overflow HID: Intel-thc-hid: Intel-quicki2c: Fix buffer overflow HID: universal-pidff: Add support for Turtle Beach VelocityOne Race HID: multitouch: stop the release timer from being rearmed on remove Revert "HID: logitech: add Bolt receiver support for Logitech HID++ devices" commit 40cce45b921f7930886bcba43069edc579725457 Author: Nikola Prica Date: Mon Sep 21 13:19:03 2026 +0200 PCI: Accept AtomicOps already enabled by the hypervisor pci_enable_atomic_ops_to_root() currently fails when no Root Port is visible. That is common in passthrough guests (ESXi, Hyper-V): the Endpoint is assigned to the VM, but the Root Port above it is not visible in the guest topology. In those setups the hypervisor may already have enabled AtomicOp Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set, treat AtomicOps as already enabled and return success instead of failing the Root Port walk. After 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them"), pci_enable_atomic_ops_to_root() always returns failure if the Root Port is not visible, so drivers don't use atomics when they could. On systems where the Root Port is not visible but *does* support AtomicOps, this is a regression: prior to 1ae8c4ce1570, it enabled AtomicOps in the endpoint and returned success. Fixes: 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them") Signed-off-by: Nikola Prica [bhelgaas: commit log, code comment] Signed-off-by: Bjorn Helgaas Tested-by: Gerd Bayer Reviewed-by: Christian König Reviewed-by: Gerd Bayer Link: https://patch.msgid.link/20260921111903.978687-1-nikprica@amd.com commit 17a58009754886eeacb9b826aa6d7bf5e294454d Merge: ce1e0223d8ad42 015fb29a748342 Author: Linus Torvalds Date: Fri Oct 2 09:07:36 2026 -0700 Merge tag 'for-next-tpm-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd Pull tpm fixes from Jarkko Sakkinen. - tpm error handling and buffer size fixes * tag 'for-next-tpm-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: tpm: Disable TPM on null key name mismatch tpm: fix off-by-four bounds check in tpm2_get_random() tpm: Fix auth session leak in tpm2_get_random() error path tpm: Fix heap buffer overflow in tpm_transmit_cmd() commit 08e90633377f1b2567ab5ad6810b74c552246a07 Author: Palla Raghunath Date: Fri Oct 2 08:07:52 2026 +0100 Bluetooth: RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown 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 commit 25016fe8c1ed0fccae107bd629089139ffbafe08 Author: Runyu Xiao Date: Wed Sep 30 15:44:53 2026 +0800 Bluetooth: btintel_pcie: use managed IRQ teardown 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 commit 3c0d2f1f431c51a11253f28763be723ac782fd7a Author: Mahantesh Salimath Date: Thu Sep 10 16:11:24 2026 +0000 tee: optee: ffa: support shared memory offsets on large-page kernels 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 commit c108feca0a096f8db25d1b69130035025e9e936d Author: Shao-Fu Chen Date: Fri Sep 18 18:10:46 2026 +0800 optee: register TEE devices only once fully initialized 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 commit b4e7fc36e31f59b318d38afe621ac20650314d27 Merge: e6229c0402ea48 cad16d850e3759 Author: Takashi Iwai Date: Fri Oct 2 14:45:01 2026 +0200 Merge tag 'asoc-fix-v7.3-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v7.3 A bigger collection of fixes than usual due to your vacation but nothing hugely remarkable here, just fairly standard quirks and driver specific bugfixes. commit b7f925fd5226deb953c8dcdc9677d3fcc2717c00 Author: Georgiy Osokin Date: Mon Sep 28 17:31:13 2026 +0300 tee: shm: reject zero-sized allocations in tee_dyn_shm_alloc_helper() 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 commit de020dc8049bfb2b22e3b6d99c031feb2e22d112 Author: Ömer Mete Kaya Date: Tue Sep 29 11:10:34 2026 +0300 bpf: Fix missing migration protection in __rhtab_map_lookup_and_delete_batch() bpf_mem_cache_free_rcu() uses this_cpu_ptr() which requires migration to be disabled. All callers of rhtab_delete_elem() disable migration except __rhtab_map_lookup_and_delete_batch(), which calls it under rcu_read_lock() only. On CONFIG_PREEMPT_RCU, rcu_read_lock() does not disable preemption or migration, so the task can migrate between CPUs during the delete loop, causing this_cpu_ptr() to trigger: BUG: using smp_processor_id() in preemptible [00000000] code Fix by wrapping the delete loop in migrate_disable()/migrate_enable() in __rhtab_map_lookup_and_delete_batch(), matching the migration protection that the other callers already provide. Fixes: 818e00848227 ("bpf: Implement iteration ops for resizable hashtab") Reported-by: syzbot+fd7e415d891073b83e1f@syzkaller.appspotmail.com Signed-off-by: Ömer Mete Kaya Signed-off-by: Alexei Starovoitov Acked-by: Mykyta Yatsenko Link: https://patch.msgid.link/20260929081609.557899-1-omermetekaya0@gmail.com Closes: https://syzkaller.appspot.com/bug?extid=fd7e415d891073b83e1f commit 71a77ab76e74131a101f4d2d2afb0dcbf81b4e3c Author: Frank Li Date: Tue Sep 29 15:06:36 2026 -0400 net: allwinner: remove dmaengine_desc_free() dmaengine_desc_free() is designed for DMA_CTRL_REUSE. If DMA_CTRL_REUSE is not set, dmaengine_desc_free() will return -EPERM. if (!dmaengine_desc_test_reuse(desc)) return -EPERM; So calling dmaengine_desc_free() does nothing. dmaengine_terminate_(a)sync() will free all already allocated descriptors. Signed-off-by: Frank Li Reviewed-by: Joe Damato Signed-off-by: David S. Miller commit eb13a1ff271b0d180687eebb30611b0b276d5193 Author: Nathan Chancellor Date: Fri Sep 25 22:46:32 2026 +0100 random: vDSO: avoid call to memset() when zeroing reserved parameter After a recent change in LLVM [1], builds with the random vDSO implementation, such as PowerPC and RISC-V, fail when checking the vDSO: arch/powerpc/kernel/vdso/vdso32.so.dbg: dynamic relocations are not supported arch/riscv/kernel/vdso/vdso.so.dbg: dynamic relocations are not supported memset() is now generated when zeroing params->reserved for some builds because LLVM has an optimization (now run in more instances) that can recognize at compile time when it is assigning a static value to a contiguous area of memory and turn that into a call to memset(). Both clang and GCC assume memset() is always available [2]. Clang has an internal fiddly hook, -max-store-memset, which we can set to a high number, to disable generating out of line memset calls [3]. Similarly, GCC has -finline-stringops=memset to do the same [4], should this issue ever hit future version of GCC. While these options wouldn't make sense for normal kernel code, it is fine for the extremely limited and intentionally compact vDSO code. Link: https://github.com/llvm/llvm-project/commit/90cebef1411617fc3eedd359bdf00cb44b1c2439 [1] Link: https://gcc.gnu.org/onlinedocs/gcc-16.2.0/gcc/Standards.html#index-ffreestanding [2] Link: https://github.com/llvm/llvm-project/commit/b28eeb28bea39148738dc375e8a97072a1907e64 [3] Link: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-finline-stringops [4] Closes: https://github.com/ClangBuiltLinux/linux/issues/2183 Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Nathan Chancellor Signed-off-by: Jason A. Donenfeld commit f35e3b5784221654f9cdbd6222275a7fa203f6c3 Author: Chris Mason Date: Thu Oct 1 13:50:22 2026 +0000 futex: Fix private hash use-after-free on resize poll_state_synchronize_rcu(mm->futex.phash.batches) is used by futex_ref_drop() to check that a grace period has passed since the current hash was published. This relies on batches referencing a grace period which started after the hash pointer was assigned. __futex_pivot_hash() sets mmph->batches before it replaces mmph->hash: scoped_guard(rcu) { mmph->batches = get_state_synchronize_rcu(); rcu_assign_pointer(mmph->hash, new); } The scoped_guard(rcu) doesn't stop new grace periods from starting, and if one starts between those two assignments, futex_ref_drop() can move forward while a reader still holds a pointer to the old hash. Fix things by setting mmph->batches after assigning mmph->hash. The scoped_guard(rcu) isn't needed, so let's drop that as well. Fixes: 56180dd20c19 ("futex: Use RCU-based per-CPU reference counting instead of rcuref_t") Assisted-by: kres Signed-off-by: Chris Mason Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Paul E. McKenney Link: https://patch.msgid.link/20261001135022.2220288-1-mason@kernel.org commit 26f6b6357b1b06e6aaa9b8d796989cca785d8e1d Author: Kuan-Wei Chiu Date: Thu Oct 1 10:25:15 2026 +0200 irq: Make refcount_interrupt kunit test selectable Currently, refcount_interrupt_test is built unconditionally when CONFIG_KUNIT is enabled, causing it to run unexpectedly during boot. Fix this by introducing CONFIG_REFCOUNT_INTERRUPT_KUNIT_TEST so the test can be configured independently, following standard kunit practices. Fixes: 07a88e2bcd5b ("irq: Add KUnit test for refcounted interrupt enable/disable") Signed-off-by: Kuan-Wei Chiu Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Lyude Paul Reviewed-by: Radu Rendec Reviewed-by: Boqun Feng Link: https://patch.msgid.link/20261001082519.16195-2-boqun@kernel.org commit 232d49dd4b40a666283de9e722899f088ed581b2 Author: Lorenzo Bianconi Date: Tue Sep 29 15:10:11 2026 +0200 net: stmmac: propagate PTP addend and system time programming errors stmmac_update_subsecond_increment() ignores the error returned by stmmac_config_addend(), and stmmac_init_tstamp_counter() discards the addend and system time programming errors, always returning success. A failure to program the addend (PTP_TCR_TSADDREG) or to initialize the system time counter (PTP_TCR_TSINIT) is therefore silently swallowed, leaving the hardware timestamp counter in a non-running or partially configured state while the driver keeps operating as if timestamping were up. This matters for TAPRIO/EST offloading, which derives the gate base time from the hardware timestamp counter. The same hooks are also called from the PHC callbacks: settime64 and adjfine drop the error and report success to clock_settime() and clock_adjtime(), so a dead PTP reference clock goes unnoticed by ptp4l/phc2sys. Return error codes from stmmac_update_subsecond_increment(), stmmac_init_tstamp_counter(), stmmac_dl_ts_coarse_set() and the settime64/adjfine callbacks instead of silently returning success. On failure, roll back the partially applied configuration so the hardware and the driver bookkeeping stay consistent, and report the reason through the devlink extack. Also guard against a zero sub-second increment, which would otherwise divide by zero when computing the addend. Reset the persistent timestamping state (hwts_tx_en, hwts_rx_en, tstamp_config, systime_flags and tsfupdt_coarse) when (re)initializing timestamping, so a failed init does not leave TX/RX timestamping enabled on a counter that never started. Fixes: cc4c9001ce31 ("net: stmmac: Switch stmmac_hwtimestamp to generic HW Interface Helpers") Signed-off-by: Lorenzo Bianconi Reviewed-by: Maxime Chevallier Signed-off-by: David S. Miller commit f5e0b20f6c6d548d985acdd620c5110776c915c2 Author: Felix Fietkau Date: Tue Aug 18 12:58:21 2026 +0000 wifi: mt76: mt7996: program a link again if the driver holds it The firmware needs the driver to remove active links from the BSSINFO table when it destroys the interface. A link therefore stays registered from its first chanctx assignment until the interface goes away. If the driver holds the link already, a second add does nothing. mac80211 gives a non-AP MLD a new address each time it sets a link up. A link that comes back after a failed attempt thus carries an address that the hardware does not know, on a BSS that the driver never programs again. The station then authenticates from an address that nothing answers. The failure repeats until the driver tears the interface down for good. Program the address and the BSS again. This is the pair that the initial add sets up. For a station it does what mt7996_mcu_mld_link_oper() does for an AP. Fixes: 08813703ac41 ("wifi: mt76: mt7996: Destroy vif active links in mt7996_remove_interface()") Link: https://patch.msgid.link/20260818125825.395538-1-nbd@nbd.name Signed-off-by: Felix Fietkau commit 6c95ca52f27855dd2fb74131c8d4e8325d2af7de Author: Johan Hovold Date: Fri Oct 2 09:27:36 2026 +0200 tty: add missing driver flag kernel-doc colon A recent change adding a new TTY driver flag left out a colon required for well-formed kernel-doc. Fixes: 8df07fe93573 ("tty: fix saved termios reset race") Reported-by: Randy Dunlap Link: https://lore.kernel.org/ec3a09d6-4ba4-41b8-abb1-b59e265f4532@infradead.org Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20261002072736.2063004-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 4c9dc0faca98084922caeb689579d338cf3e1c29 Author: Sang-Hoon Choi Date: Wed Sep 30 02:37:34 2026 +0900 cxgb4/ch_ktls: disable softirqs around tid_list erases 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 commit c83e3d2912432107148cc5e288ddd153a84c0f43 Author: Petr Mladek Date: Thu Oct 1 16:07:27 2026 +0200 braille: nbcon: Allow to use a serial console with NBCON API as Braille console The Braille console is not registered in console_list. Instead, it is integrated with the virtual terminal (VT) and shows what is displayed on the terminal. It writes the data using con->write*() callback of the associated serial console driver. braille_write() is called from the VT code under console_lock(). The associated serial console driver can be converted to the NBCON API though. The situation is similar to flushing nbcon consoles in the legacy loop when some boot consoles are still registered, see nbcon_legacy_emit_next_record(). But there is a big difference though. braille_write() is not directly called from the code paths flushing registered consoles. The VT code expects that braille_write() succeeds. It does not replay the message when it can't acquire the ownership. As a result, braille_write(): + must try harder to get the ownership. + has to be synchronized only against non-printk serial console which depend nbcon_device_try_acquire() using NBCON_PRIO_NORMAL. Let's look at it from another side and try to simulate the original locking using the NBCON API: 1. Take con->device_lock(), aka the port->lock in the legacy serial console driver. 2. Acquire nbcon context to provide some synchronization for a panic() context. Use NBCON_PRIO_NORMAL because it contends only with nbcon_device_try_acquire() users. Do it in a busy loop. It should always succeed when con->device_lock() succeeded because all other users do the same. The only exception is when the context get acquired by a CPU handling panic. 3. In panic, disable interrupts and try to acquire the nbcon context. Use NBCON_PRIO_PANIC. And try even an unsafe takeover because otherwise the Braille console won't see the text shown during panic(). It is similar to the oops_in_progress/trylock handling in the legacy serial console driver. Finally, avoid the newline prepending logic in the existing serial console drivers when they are used as a Braille console. As explained above, the Braille console shows the last modified line on the terminal (VT). braille_write() is called when single characters are added. Most messages are not ended by newline. Anyway, the VT code does not have logic to reply partially printed messages. Fixes: 13189fa73afa ("printk: nbcon: Rely on kthreads for normal operation") Reviewed-by: John Ogness [pmladek@suse.com: Remove white space changes in braille_register_console(). Typo fix.] Link: https://patch.msgid.link/20261001140727.124398-2-pmladek@suse.com Signed-off-by: Petr Mladek commit 3acdd44385bc7e2e57605e073691ce69cc5a960d Author: Yuqi Xu Date: Mon Sep 28 16:24:38 2026 +0800 tipc: destroy topsrv workqueues before closing connections 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 commit f7b3ef049a1fee3f64e48a174530ab1c46bf1de9 Merge: 28bc1ef699610e 636035157a814f Author: David S. Miller Date: Fri Oct 2 07:52:32 2026 +0100 Merge branch 'dim-overflow' Shashank Mohan Jain says: ==================== lib/dim: fix 32-bit overflow in dim_calc_stats() On 32-bit kernels dim_calc_stats() multiplies the u32 byte, packet and completion counts of a DIM window by USEC_PER_MSEC (1000L) in 32-bit long arithmetic. Once a window carries more than about 4.3 MB, bpms wraps, and net_dim steers interrupt moderation on a meaningless throughput value. At 1 Gbit/s line rate a 64-event window passes that size when there are fewer than about 1,860 DIM events per second, which is common while NAPI keeps the interrupt masked under load. 32-bit users of the library include mtk_eth_soc (MT7621, MT7623), bcmgenet and bcmsysport on 32-bit ARM, xilinx_axienet on Zynq-7000 and MicroBlaze, and virtio_net in 32-bit guests. The overflow goes back to the mlx5e code the library was moved from. Patch 1 does the multiplications in 64 bits and divides with DIV_ROUND_UP_ULL(); the results on 64-bit are unchanged. Patch 2 adds a KUnit suite for dim_calc_stats() whose large-window cases fail on 32-bit without patch 1. It is part of this series as described under "Co-posting selftests" in maintainer-netdev.rst. The series is based on net (a7bfaba4823e) and has no dependencies; both patches also apply to mainline (fd179f8a05be) and net-next. The bug was found and the patches were prepared with Claude Code (Anthropic), model Claude Opus 5.5 (claude-opus-5-5). Tested: - KUnit (CONFIG_DIMLIB_KUNIT_TEST=y) on UML i386 (SUBARCH=i386): without patch 1, 4 of the 7 dim_calc_stats cases fail (many_bytes, bytes_32bit_limit, gigabit, many_packets); with it all pass. On UML x86_64 all cases pass with and without patch 1. Both were run on mainline and on net. - W=1 builds of lib/dim/ for UML x86_64 and i386 without warnings; dim.o references no libgcc 64-bit division helpers. A native i386 defconfig build (vmlinux and modules, DIMLIB=y) succeeds. - checkpatch --strict. Its "does MAINTAINERS need updating?" warning on patch 2 does not apply: lib/dim/ is already covered by the DYNAMIC INTERRUPT MODERATION entry. Not tested: 32-bit ARM or MIPS builds (no cross compiler was available), and no run on a 32-bit NIC. The traffic levels at which the drivers hit the overflow are derived from how they count DIM events, not measured. Signed-off-by: David S. Miller commit 636035157a814f289f293fd0edea1a367a637797 Author: Shashank Mohan Jain Date: Sun Sep 27 10:47:43 2026 +0530 lib/dim: add KUnit test for dim_calc_stats() Add a KUnit suite for the DIM library that checks the packet, byte, event and completion rates computed by dim_calc_stats(), including counter wraparound and windows whose byte or packet count times USEC_PER_MSEC does not fit in 32 bits. The latter cases fail on 32-bit architectures without the previous commit. Assisted-by: LLM Signed-off-by: Shashank Mohan Jain Signed-off-by: David S. Miller commit 0843b23890642a02ff85c36406224e8874e30664 Author: Shashank Mohan Jain Date: Sun Sep 27 10:47:42 2026 +0530 lib/dim: fix 32-bit overflow in dim_calc_stats() rates dim_calc_stats() computes the per-millisecond rates as DIV_ROUND_UP(nbytes * USEC_PER_MSEC, delta_us) where nbytes is a u32 and USEC_PER_MSEC is 1000L. On 64-bit the product is done in 64-bit long arithmetic, but on 32-bit architectures long is 32 bits wide and the product wraps as soon as a measurement window carries more than 4294967 bytes (about 4.3 MB). The same applies to the packet and completion counts, although those need more than 4.29 million packets or completions per window. A DIM window spans DIM_NEVENTS (64) events. Drivers count events per interrupt or per NAPI poll, so under sustained load a window can easily carry more than 4.3 MB: 64 full NAPI polls of 64 MTU-sized frames are already 6.2 MB, and drivers such as mtk_eth_soc count one event per interrupt while NAPI keeps polling with the interrupt masked. On 32-bit users of the library (for example mtk_eth_soc on MT7621, bcmgenet and bcmsysport on 32-bit ARM, or virtio_net in a 32-bit guest) bpms then becomes the product modulo 2^32 divided by the window length, and net_dim_stats_compare() makes its BETTER/WORSE decisions on a value that has little to do with the real throughput. For example, a 1 Gbit/s link at line rate that moves 5 MB in a 40 ms window gives bpms = 125000 on 64-bit but 17626 on 32-bit, and 5 million packets in 2 s gives ppms = 353 instead of 2500. Widen the products to 64 bits and divide with DIV_ROUND_UP_ULL(). The results are unchanged on 64-bit. Fixes: cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing") Fixes: 4c4dbb4a7363 ("net/mlx5e: Move dynamic interrupt coalescing code to include/linux") Assisted-by: LLM Signed-off-by: Shashank Mohan Jain Signed-off-by: David S. Miller commit 7a39c732a22ec4a369af9e19fbe3d666ec83eec4 Author: Leon Hwang Date: Wed Sep 30 13:36:18 2026 +0800 kprobes: Skip disarmed probes when checking optkprobe overlap On x86, an optkprobe at A replaces five bytes with a jump. If a disabled probe B is at A+2, get_optimized_kprobe() stops at B when arming a new probe C at A+4. It leaves A optimized: A A+1 A+2 A+3 A+4 A's jump | e9 | d0 | d1 | d2 | d3 | after C | e9 | d0 | d1 | d2 | cc | The INT3 for C overwrites the last byte of A's jump displacement, so execution can jump to the wrong address. B can have prepared optinsns while disarmed, but has no jump to unoptimize. Continue past disarmed and unprepared probes to find the active optimized probe before arming a probe in its jump. Link: https://lore.kernel.org/all/20260930053618.104498-1-leon.hwang@linux.dev/ Fixes: afd66255b9a4 ("kprobes: Introduce kprobes jump optimization") Cc: stable@vger.kernel.org Signed-off-by: Leon Hwang Signed-off-by: Masami Hiramatsu (Google) commit 26fe67ec0dca018767b038fe65c9fc9da058ac19 Merge: d87d131d18a192 c034e8a46e4cb7 Author: Dave Airlie Date: Fri Oct 2 11:26:46 2026 +1000 Merge tag 'drm-intel-fixes-2026-10-01' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes drm/i915 fixes for v7.3-rc6: - Disable VRR DC balance by default to fix timing issues Signed-off-by: Dave Airlie From: Jani Nikula Link: https://patch.msgid.link/5a9a11777f605b59550783923add4568e974a6ea@intel.com commit d87d131d18a1929441b9e48a6f8378938ae87098 Merge: 72d3fcf802c45d 72207463f7a4a6 Author: Dave Airlie Date: Fri Oct 2 10:34:50 2026 +1000 Merge tag 'drm-xe-fixes-2026-10-01' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Only 1 fix to Keep VF LMEM BAR size low if no VFs enabled from Marcin and a preparation patch for that. Signed-off-by: Dave Airlie From: Rodrigo Vivi Link: https://patch.msgid.link/ar5qJ-OV2gNI1TwN@intel.com commit 28bc1ef699610ee09ce3d46a00552f5a0a0144bd Author: Quchaosheng Date: Mon Sep 28 19:31:08 2026 +0800 net/packet: guard the ll header push in packet_rcv_spkt() 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 commit 2d3b94c6076a95553876a3c45c122edf62c27449 Merge: c9728fcf2e7fb4 c41817fcaf397f Author: Jakub Kicinski Date: Thu Oct 1 18:11:13 2026 -0700 Merge branch 'amt-send-the-relay-s-general-query-directly-from-the-receive-path' Omar Ramadan says: ==================== amt: send the relay's General Query directly from the receive path The relay queues its General Query on the amt device with a raw tunnel pointer in skb->cb, and a query that waits in a qdisc can outlive its tunnel: a use-after-free in amt_dev_xmit(), reported by Microsoft with a KASAN reproducer. Patch 1 sends the query directly from amt_request_handler(), inside the RCU section that found or created the tunnel, so it never waits in a qdisc and nothing is stored in skb->cb. Patch 2 adds the selftest Taehee asked for. It counts the queries that leave the relay through its amt device and expects none. It fails without patch 1 and passes with it. ==================== Link: https://patch.msgid.link/20260928202312.74574-1-omar@blockcast.net Signed-off-by: Jakub Kicinski commit c41817fcaf397f6ff7c530b682581f5eb5465844 Author: Omar Ramadan Date: Mon Sep 28 23:23:12 2026 +0300 selftests: net: amt: check that the relay's queries bypass the amt device The relay used to hand its General Queries to dev_queue_xmit() on the amt device, where a query could wait in a qdisc and outlive the tunnel it pointed to. The previous patch sends them directly from the receive path instead. Count the IGMP and MLD queries that leave the relay through amtr with tc flower filters on its egress, installed before the gateway comes up, and check that there are none. The forwarding tests before it already show that the gateway received its queries, since it cannot join without one. Without the previous patch the new test fails (one run counted 7 IGMP and 6 MLD queries); with it, all of amt.sh passes. Signed-off-by: Omar Ramadan Link: https://patch.msgid.link/20260928202312.74574-3-omar@blockcast.net Signed-off-by: Jakub Kicinski commit afae89de73dd693cfa329580ba0fba63bd3f0a11 Author: Omar Ramadan Date: Mon Sep 28 23:23:11 2026 +0300 amt: send the relay's General Query directly from the receive path 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 commit c9728fcf2e7fb4a7a8d08ebd9524c3b02ae1a021 Author: Jamal Hadi Salim Date: Wed Sep 30 03:31:02 2026 -0400 net/sched: em_text: reject unterminated algo before autoload 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 commit 26f90559a77cac4b8fdfa3491732b7c7e08210ac Author: Sunho Park Date: Sun Aug 30 18:56:05 2026 +0900 srcu: Fix WARN_ON() for rcu_segcblist_n_cbs() in cleanup_srcu_struct() The WARN_ON() added by commit 78a38cbf6f20 ("srcu: Queue sdp->work when the delay timer is successfully deleted") uses rcu_segcblist_n_cbs() to detect callbacks that srcu_barrier() failed to wait for. However, the ->len counter is decremented only at the end of srcu_invoke_callbacks(), after the invoking loop has finished. Since srcu_barrier() can return right after the barrier callback is invoked, cleanup_srcu_struct() can see a non-zero n_cbs even though the cblist is already physically empty, falsely triggering the WARN_ON() together with a still-pending delay_work timer. This can be triggered as follows, as seen in the syzbot report against kvm_destroy_vm() -> cleanup_srcu_struct(&kvm->srcu): 1. call_srcu(&kvm->srcu, &bus->rcu, __free_bus) starts SRCU grace period GP1. 2. GP1 ends: a delay timer is armed and sdp->work is queued, but sdp->work has not run yet. 3. Another call_srcu(&kvm->srcu, &bus->rcu, __free_bus) call invokes srcu_segcblist_advance(), which moves the GP1 callback to RCU_DONE_TAIL, and starts SRCU grace period GP2. 4. srcu_barrier() is called. It queues its barrier callback after the GP2 callback and waits for srcu_invoke_callbacks() to invoke it. 5. GP2 ends: another delay timer is armed, and the sdp->work queued in step 2 begins to run. Its srcu_invoke_callbacks() call invokes srcu_segcblist_advance() again, moving the GP2 and barrier callbacks to RCU_DONE_TAIL as well, and then invokes all of them. However, rcu_segcblist_add_len(), which updates srcu_cblist's ->len, has not run yet at this point. 6. srcu_barrier() returns once its callback has been invoked, and cleanup_srcu_struct() starts running. It finds the delay timer armed in step 5 still pending and srcu_cblist's ->len still non-zero (because step 5 has not reached rcu_segcblist_add_len() yet), and WARN_ON() fires even though every callback has actually been invoked. Use rcu_segcblist_empty(), which checks the actual head of the cblist, instead of rcu_segcblist_n_cbs(), which checks the racy ->len counter. Callbacks that have genuinely not been invoked yet still leave the list non-empty, so the WARN_ON() still catches callers that skip srcu_barrier() or queue callbacks after it. Link: https://lore.kernel.org/rcu/e6350377085ddd85d6ef00d8e9a67bd50c762d3c@linux.dev/T/#t Reported-by: syzbot+d4faf7db59e11f6fd1ab@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d4faf7db59e11f6fd1ab Fixes: 78a38cbf6f20 ("srcu: Queue sdp->work when the delay timer is successfully deleted") Suggested-by: Zqiang Signed-off-by: Sunho Park Signed-off-by: Paul E. McKenney Tested-by: Sean Christopherson commit 17e73bae400f6a434dc006e3bee92c94cf781954 Author: Chengfeng Ye Date: Tue Sep 29 00:12:46 2026 +0800 tipc: hold a reference to nodes found by link name 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 commit 048739be3e9cacae5301b68245668002fe6f0ce5 Author: Guangshuo Li Date: Mon Sep 21 21:11:56 2026 +0800 drm/mediatek: Fix ovl adaptor platform device leak mtk_drm_probe() creates an OVL adaptor platform device with platform_device_register_data() when the display pipeline requires the OVL adaptor. If a later initialization step fails, the probe error path releases the DRM resources without unregistering the already registered OVL adaptor device. The normal remove path likewise leaves the device registered after the DRM driver is unbound. Keep track of whether the OVL adaptor was successfully registered and unregister it on probe failure. Also recover the platform device from the stored DDP component device and unregister it during normal removal. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260921131156.403652-1-lgs201920130244@gmail.com/ Signed-off-by: Chun-Kuang Hu commit 8e9cb398593c1a4bfd50ac221f4ae5ab2a69a5ae Merge: d24e8ac715de2e 84bec0bf035258 Author: Jakub Kicinski Date: Thu Oct 1 15:59:29 2026 -0700 Merge branch 'ibmveth-fix-open-fail-unwind-after-lan-registration' Mingming Cao says: ==================== ibmveth: fix open-fail unwind after LAN registration ibmveth_open() has two independent unwind holes after the logical LAN is set up. Neither needs the MQ RX series. This posting is against current net.git. Patch 1 issues h_free_logical_lan() on every post-register failure. A pool allocation failure jumped to out_free_buffer_pools without the hypercall, so PHYP still owned the buffer-list page when it was unmapped. request_irq() failure already issued H_FREE before taking the same label. Fixes: d43732ce021f ("ibmveth: properly unwind on init errors") Patch 2 gives TX LTBs their own walk. out_free_buffer_pools reuses open()'s loop index, so after the pool unwind i is -1 and the TX buffers leak. 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). Fixes: d926793c1de9 ("ibmveth: Implement multi queue on xmit") The MQ RX series on net-next keeps the helper versions of these guards and does not depend on this pair. If both land, keep the helpers in that series; these two patches are the current single-queue open-fail path only. ==================== Link: https://patch.msgid.link/cover.1790357373.git.mmc@linux.ibm.com Signed-off-by: Jakub Kicinski commit 84bec0bf035258a1073ffd6f6dc8ea61806aa7d4 Author: Mingming Cao Date: Fri Sep 25 11:05:30 2026 -0700 ibmveth: fix TX LTB and filter unwind on open-fail 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 commit af0524bf4ce1a4cbd2946aa81751582951cfcab5 Author: Mingming Cao Date: Fri Sep 25 11:05:29 2026 -0700 ibmveth: h_free logical LAN on open-fail after register 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 commit 2af45da333bdd7be2666688a0f861e0750e40e49 Author: Wentao Liang Date: Wed Sep 16 17:42:29 2026 +0000 drm/mediatek: Fix runtime PM leak in mtk_hdmi_ddc_v2_probe() pm_runtime_get_sync() unconditionally bumps the usage counter, but nothing puts it back when devm_i2c_add_adapter() fails, leaving the DDC runtime-resumed after a failed probe. Drop the reference on that error path. Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188") Signed-off-by: Wentao Liang Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260916174229.2088824-1-vulab@iscas.ac.cn/ Signed-off-by: Chun-Kuang Hu commit 3753e34b73fcbe2a2edbe984614a008a261697ef Author: Wentao Liang Date: Wed Sep 16 17:40:58 2026 +0000 drm/mediatek: Fix pdev reference leak in mtk_drm_bind() When the device is not the mmsys master, mtk_drm_bind() returns early after taking a reference on the disp-mutex device via of_find_device_by_node(), without ever dropping it: mtk_drm_unbind() only puts mutex_dev for the master. Drop the reference before returning from the non-master path. Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260916174058.2088709-1-vulab@iscas.ac.cn/ Signed-off-by: Chun-Kuang Hu commit a22e5e4f2ebbdbb962cc3233094d189c4dfaa051 Author: Francisco Beltrán Millalén Date: Thu Sep 24 18:05:23 2026 -0300 drm/amdgpu: reset VI ASIC on MacBookPro14,3 On a MacBookPro14,3 with a Radeon Pro 555 (Polaris11), the framebuffer is at MC address 0 when amdgpu loads after a cold boot, as the firmware leaves it (MC_VM_FB_LOCATION = 0x007f0000), while the VBIOS ASIC_Init table places it at 0xF4_0000_0000 (0xf47ff400). amdgpu reads the location once, at init, so after a re-POST (S3 resume or GPU reset) the framebuffer has moved and the driver keeps programming the old one: the SMU is handed a table that was never written and the GPU does not come back, which leaves the internal panel black. Resetting the ASIC on load makes ASIC_Init run before the driver reads the location, so the driver uses the VBIOS placement from the start and every later re-POST puts the framebuffer back where it already is. Add the Radeon Pro 555 used in this machine to the existing VI reset quirk table. Tested on a MacBookPro14,3 on 6.18.49 with the quirk table backported (the kernel also carries unrelated local PCI and ACPI patches for this machine). The framebuffer is at 0x000000F400000000 after both cold and warm boot, and the GPU survived 9 S3 cycles (lid close and rtcwake, one of them with the lid closed for about 7.5 minutes and a USB-C disk attached), each followed by a few minutes of 3D load; no ring timeouts or VM faults were reported. The reset adds about 0.23 s to amdgpu init. Suggested-by: Christian König Suggested-by: Alex Deucher Link: https://lore.kernel.org/all/20260924132952.25054-1-fbeltranmillalen@gmail.com/ Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Francisco Beltrán Millalén Signed-off-by: Alex Deucher (cherry picked from commit b6b1d97218518003107d4446fac278fa3e0a19a0) Cc: stable@vger.kernel.org commit 08c9100f65299c64439e22e6057d750ae0e6c660 Author: Timur Kristóf Date: Wed Sep 23 14:03:54 2026 +0200 drm/amd/pm/si: Fix updating clock limits on AC/DC Assume that the AC limits are the maximum of all power states, and the DC limits are the maximum of battery power states. This shouldn't make any difference in practice, but is cleaner and more robust against bogus information in the VBIOS. Fixes: e6c5d36756e7 ("drm/amd/pm/si: Fix updating clock limits from power states") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923120354.1027996-2-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit ef8cb9dcc7db7b7abcbdbe870a080cc81e4f0bf3) Cc: stable@vger.kernel.org commit b76a5b7bee22556914f7cde210f695ef162d81bf Author: Simon Polack Date: Thu Sep 17 12:42:34 2026 +0200 drm/amd/display: Fix stale replay_events after mod_power stream removal [Why] mod_power_remove_stream() shifts the remaining power_entity slots down but does not move replay_events, and mod_power_add_stream() does not initialize it. replay_events therefore stay bound to the map slot instead of the stream. When several streams are disabled in one atomic commit, amdgpu_dm_mod_power_update_streams() removes them one after another. The eDP stream can then be looked up in a slot whose stale replay_events already have replay_event_hw_programming set, so amdgpu_dm_replay_set_event() returns early ("already in desired state") without calling mod_power_set_replay_event(). Replay is not disabled before the eDP panel is powered off. After DPMS on, the sink reports neither replay state nor frame lock (DPCD 0x378 = 0x00, no error bits), so the HPD IRQ recovery does not trigger and the panel stays black until a full modeset. Seen with an eDP panel using FreeSync Replay plus two DP-MST displays: DPMS off/on of all outputs leaves eDP black, while DPMS of eDP alone works. Doing an eDP-only DPMS first makes the next all-output DPMS fail reliably. [How] Shift replay_events together with the PSR cached fields in mod_power_remove_stream() and initialize it to replay_event_vsync in mod_power_add_stream(), matching the psr_event_vsync initial value used for PSR (both vsync events are driven together by amdgpu_dm_crtc_set_static_screen_optimze()). Tested on 7.3.0-rc3 (238650ef6c7c): the reproducer above now recovers reliably, and Replay still engages when the screen is idle. The issue was debugged with help from an AI assistant (Claude), which analysed ftrace/kprobe traces and the driver source, pointed to the missing replay_events handling and suggested this change. I collected the traces and built and tested the fix on the affected hardware. Fixes: 4cef2ac4c795 ("drm/amd/display: Introduce power module on Linux") Assisted-by: Claude:claude-opus-5 Signed-off-by: Simon Polack Reviewed-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 3d47e38e271195435e125527b224d11cfdb777b1) Cc: stable@vger.kernel.org commit de1eab13efef83fd2b76f4688de5bf672644596f Author: Imre Kaloz Date: Sun Sep 27 16:55:04 2026 +0200 drm/radeon: Read the VRAM VBIOS signature with readb() igp_read_bios_from_vram() checked bios[0]/bios[1] with a plain __iomem load, which faults on sparc64 before the copy runs at all. radeon_read_bios() already reads its two signature bytes with readb() ahead of its own copy; use the same accessor here, keeping the check before the allocation. Fixes: b442962a9e82 ("drm/radeon/kms: add support for "Surround View"") Signed-off-by: Imre Kaloz Signed-off-by: Alex Deucher (cherry picked from commit 09155b8932e5013dbce0f5cdff7d75264a279ee5) Cc: stable@vger.kernel.org commit 217f64f348c90cba62164e7ff38e0ccf78a5ca09 Author: Hari Mishal Date: Wed Sep 16 16:23:32 2026 +0200 drm/amd/display: guard dc_sink dereferences in MST mode validation dm_dp_mst_is_port_support_mode() reads aconnector->dc_sink->dsc_caps... for the DSC branch-throughput check, and get_conv_frl_bw()'s HDMI-PCON FRL-bandwidth path reads aconnector->dc_sink->edid_caps.max_frl_rate, both without a NULL check. dc_sink is cleared asynchronously on MST unplug, and both functions run from paths that the driver's own comments document as racing that teardown: the connector probe worker's ->mode_valid callback and a compositor's atomic check, neither of which holds the MST manager lock that the teardown path uses. The former does have an existing dsc_aux NULL check, but dsc_aux isn't reliably cleared in every path that clears dc_sink, so it doesn't cover this. Fail the port-support check and skip the FRL conversion path when the sink is already gone. Fixes: f04d275d94e1 ("drm/amd/display: add mst port output bw check") Fixes: 5c9b8b27a883 ("drm/amd/display: Tie FRL support into amdgpu_dm") Assisted-by: gkh_clanker_t1000 Signed-off-by: Hari Mishal Reviewed-by: Fangzhi Zuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 7c3db8da4e039698ae198c870712428644e965c7) Cc: stable@vger.kernel.org commit 106b4a2a78b2a2f14885604891957b84bba502db Author: Adrian Betschart Date: Fri Sep 11 17:13:14 2026 +0200 drm/amd/display: Try RGB before YCbCr 4:4:4 in stream validation amdgpu_dm_create_validate_stream_for_sink() walks encoding_order[] and uses the first encoding that validates. YCbCr 4:4:4 is listed before RGB, so an HDMI sink that advertises 4:4:4 gets YCbCr 4:4:4 whenever the "color format" property is left at AUTO, even though RGB fits the same link. That contradicts the documented AUTO behaviour for HDMI in enum drm_connector_color_format (RGB, falling back to YCbCr 4:2:0 only when the bandwidth is not available or the mode is 4:2:0-only), which the amdgpu implementation of the property also describes. It also leaves the "Broadcast RGB" property without effect on such sinks, since the quantization range it selects only applies to RGB output. Try RGB first. The mask still holds every encoding the sink supports, so a mode that cannot carry RGB falls back exactly as before. For reference, v7.2 picked RGB here unless YCbCr 4:4:4 was forced through debugfs, while earlier kernels picked YCbCr 4:4:4 for any HDMI sink that advertised it. Fixes: 0b0ff65d3ca1 ("drm/amd/display: Refactor stream validation") Suggested-by: Adolfo Rodrigues Assisted-by: Claude Code:claude-fable-5-1 Signed-off-by: Adrian Betschart Reviewed-by: Fangzhi Zuo Tested-by: Adolfo Rodrigues Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 7de432bc753133764dc40d37f9388da56de251e7) commit fbc988f236a60cf50a89da78fc6b7213daa9999c Author: Sasha Levin Date: Sun Sep 27 12:16:01 2026 -0400 drm/amd/display: Fix sanitizer check for the DML frame size limit Building x86_64 allmodconfig with clang fails: .../dml2_0/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:10491:13: error: stack frame size (3128) exceeds limit (3072) in 'dml_core_mode_programming' [-Werror,-Wframe-larger-than] That config enables both KASAN and UBSAN, and should get the 4096 byte limit meant for clang COMPILE_TEST sanitizer builds. The check in the dml and dml2_0 Makefiles concatenates the three symbols with no separator: ifeq ($(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)$(CONFIG_UBSAN)),y) KASAN and KCSAN cannot be enabled together, so before UBSAN was added the string was at most "y". UBSAN can be enabled alongside either of them, and with both set the string becomes "yy", $(filter y,yy) is empty, and the build falls through to the non-sanitizer limit of 3072. Adding UBSAN to the check therefore lowered the limit for the most heavily instrumented builds instead of raising it. Separate the symbols with spaces so that $(filter) sees individual words, and test for a non-empty result. Only the configs with two sanitizers enabled change behaviour. Found by KernelCI builds of the linus-next tree. Fixes: ebf8b0fd8508 ("drm/amd/display: Relax DML frame limit with UBSAN") Assisted-by: LLM Signed-off-by: Sasha Levin Signed-off-by: Alex Deucher (cherry picked from commit 0400d53fd03e7d4beb09fdabda42a7b2c4ca465d) Cc: stable@vger.kernel.org commit e3e7fdece7069d09ddd818564853174865d4796a Author: Alex Deucher Date: Fri Sep 25 16:11:38 2026 -0400 drm/amdgpu/gmc12.1: properly pass flush_type to gmc_v12_1_flush_vm_hub() In gmc_v12_1_flush_gpu_tlb(), flush_type was not properly passed to gmc_v12_1_flush_vm_hub(). This only affected the MMIO path. In most cases the flush would go through MES. Reviewed-by: Mukul Joshi Signed-off-by: Alex Deucher (cherry picked from commit 1f0f66fab18dfa8f14db82b8a6b82dcc21926248) Cc: stable@vger.kernel.org commit 1d1f1acecddf742eb1f305122209bc2034fd90b1 Author: Alex Deucher Date: Tue Sep 22 12:10:40 2026 -0400 drm/amdgpu: drop userq callback assignment for sdma 7.1 Not enabled in 7.1 so drop the assignment. Cc: Horatio Zhang Cc: Hawking.Zhang@amd.com Fixes: 4ed5116aacf6 ("drm/amdgpu: Add sdma v7_1_0 support") Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher (cherry picked from commit 106e19f69a066fb6354dac04e5f5ed43a06727f7) Cc: stable@vger.kernel.org commit cc172e177795c5f87bc2d71768d077e1c10633e8 Author: Willian Oliveira Date: Mon Sep 21 22:54:10 2026 -0300 drm/amdgpu/gfx6: fix firmware leak on teardown The firmware requested in gfx_v6_0_init_microcode() is not released when the GFX block is torn down, leaking the firmware resources. Add gfx_v6_0_free_microcode() and call it from gfx_v6_0_sw_fini() to release the PFP, ME, CE and RLC firmware. Signed-off-by: Willian Oliveira Signed-off-by: Alex Deucher (cherry picked from commit 386e81346f95ab0be5a82c5535de932e7a456924) Cc: stable@vger.kernel.org commit f0013046151b7467e62c471c1c83d63ea255799c Author: Guangshuo Li Date: Mon Sep 21 18:33:18 2026 +0800 drm/amdgpu: fix ACP MFD device leak on init failure acp_hw_init() registers ACP child devices with mfd_add_devices() before attaching them to the ACP power domain and initializing the hardware. If attaching a child to the power domain fails, or if the ACP reset or clock enable operation times out, the failure path frees only the source cell, resource, and platform-data allocations. The child platform devices already registered by mfd_add_devices() remain registered and are never released. Remove the children from the power domain and unregister the MFD devices on failures that occur after mfd_add_devices() succeeds. Keep mfd_add_devices() failures on the existing cleanup path since the MFD core already rolls back partially registered children itself. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: 25030321ba28 ("drm/amd: add pm domain for ACP IP sub blocks") Signed-off-by: Guangshuo Li Signed-off-by: Alex Deucher (cherry picked from commit 63da68d6a2279ec945581c990c5a59a5ae8b5560) Cc: stable@vger.kernel.org commit f5a5add3605935163dd0f75749b6a7869e9765af Author: Guangshuo Li Date: Sun Sep 20 00:55:11 2026 +0800 drm/amdgpu: fix IP instance memory leak on kobject add failure amdgpu_discovery_sysfs_ips() allocates ip_hw_instance with kzalloc_flex() and initializes its embedded kobject before calling kobject_add(). If kobject_add() fails, the return value is ignored and execution continues without dropping the initial kobject reference. The failed kobject is not retained in the kset list, so the normal sysfs teardown path cannot find it. As a result, ip_hw_instance_release() is never called and the ip_hw_instance allocation is leaked. Call kobject_put() when kobject_add() fails so the initial reference is dropped and ip_hw_instance_release() can free the allocation. Keep the existing best-effort sysfs behavior by continuing with the remaining IP entries after the failed registration. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: a6c40b178092 ("drm/amdgpu: Show IP discovery in sysfs") Reviewed-by: Lijo Lazar Signed-off-by: Guangshuo Li Signed-off-by: Alex Deucher (cherry picked from commit 5c75fbcca8af1096d8d9415b91d8ea6212c22ee1) Cc: stable@vger.kernel.org commit eadb85cca111152bd334b861fb53747ab851d13a Author: Theo Andersen Carton Date: Thu Sep 17 21:15:12 2026 +0200 drm/amdgpu: skip the noirq suspend reset for a switcheroo-parked GPU amdgpu_pmops_suspend_noirq() resets the ASIC unconditionally. When the GPU has been parked by vga_switcheroo it has neither power nor a PCIe link, so the reset cannot reach it: pci_set_power_state() reports the device as inaccessible and amdgpu_asic_reset() returns -EINVAL. A failure there aborts the entire noirq suspend phase, and with it the system suspend, so the machine cannot sleep at all while the GPU is switched off. amdgpu_device_prepare(), amdgpu_device_suspend() and amdgpu_device_resume() all bail out early on DRM_SWITCH_POWER_OFF. This callback was added later, for an unrelated reason, and did not inherit the check. nouveau guards every one of its PM callbacks the same way. Bail out the same way here. On a single-GPU system switch_power_state is never DRM_SWITCH_POWER_OFF, so this is a no-op there. Found on a MacBookPro11,5, where the Radeon is powered down through apple-gmux so that the internal panel can be driven by the iGPU instead. Every suspend failed in amdgpu_pmops_suspend_noirq() while the card was off; with this check a full S3 cycle completes. Fixes: 9e051720f9d3 ("drm/amdgpu: Ensure HDA function is suspended before ASIC reset") Signed-off-by: Theo Andersen Carton Signed-off-by: Alex Deucher (cherry picked from commit 539d0558638a6dcc066f1cf592b6b9a52adc8ea4) Cc: stable@vger.kernel.org commit 0bfb1bfc82e8fa386d4fad1caa5812b6afafa626 Author: Alex Deucher Date: Fri Sep 25 13:46:19 2026 -0400 drm/amdgpu/gmc12: properly pass flush_type to gmc_v12_0_flush_vm_hub() In gmc_v12_0_flush_gpu_tlb(), flush_type was not properly passed to gmc_v12_0_flush_vm_hub(). This only affected the MMIO path. In most cases the flush would go through MES. Reviewed-by: Mukul Joshi Signed-off-by: Alex Deucher (cherry picked from commit 6498e33f22a12fdc759a0c78bfe0547819277a36) Cc: stable@vger.kernel.org commit 51cc916648d1421e0271090fb4fa86550a7a96d9 Author: Ray Wu Date: Fri Sep 18 11:05:46 2026 +0800 drm/amd/display: map PWM brightness through custom backlight curve [Why/How] On the PWM path, convert the userspace brightness to an input signal and derive the target luminance from the custom backlight curve, then pass the resulting millipercent to the power module. This keeps PWM programming and backlight curve mapping in the power module, aligning the Linux path with the Windows behavior. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5723 Fixes: 3c108046e1d6 ("drm/amd/display: Add power module on Linux") Assisted-by: Cursor:Claude-Opus-4.8 Signed-off-by: Ray Wu Signed-off-by: Fangzhi Zuo Reviewed-by: ChiaHsuan (Tom) Chung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit bc4e099caa85e8d4c3555851a0feb07058c4a1fe) Cc: stable@vger.kernel.org commit eaeac1498b289b342449b678a567a9012360f91a Author: Pierre-Eric Pelloux-Prayer Date: Thu Sep 24 09:37:28 2026 +0200 drm/amdgpu: implement workaround for sdma dcc corruption For unknown reasons, on gfx12 using multiple entities can causes random corruption of BOs with DCC. This workaround seems to prevent the issue until the root cause is understood and fixed. Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5663 Fixes: 3a6f6eeb3db5 ("drm/amdgpu: give ttm entities access to all the sdma scheds") Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit cd647796ac1334acec0468fae49a0dacbba2a34c) Cc: stable@vger.kernel.org commit 0e4101c11aed803e6e69a83f8cc48160a676c19d Author: Andrew Martin Date: Mon Sep 14 12:19:10 2026 +0000 drm/amdkfd: Fix always mapped range mapping to all ACCESS GPUs CWSR ranges use the always mapped flag and only need a mapping on the GPU running the queue. However, svm_range_validate_and_map now updates the mapping on every GPU with the ACCESS attribute, which is all supported GPUs when XNACK is on. After the range is prefetched to VRAM, those GPUs may span different XGMI hives, so the page owner mismatches and is set to NULL. hmm_range_fault then tries to migrate the VRAM pages back to system memory, but svm_migrate_to_ram skips it because migrating pages back to system memory is not allowed while the GPU mapping is being updated, so the CPU page fault is never resolved. Only map to the ACCESS GPUs if the range is not mapped to any GPU and is not in VRAM. Fixes: b96f26104946 ("drm/amdkfd: Unmap svm range from GPU set to no-access") Signed-off-by: Andrew Martin Assisted-by: Claude:claude-opus-5 Acked-by: Alex Deucher Reviewed-by: Philip Yang Signed-off-by: Alex Deucher (cherry picked from commit 093cf8842ace35ce212858d5059fee007ec8e778) Cc: stable@vger.kernel.org commit 8228688eb40cc116127e80394cb8157417854c70 Author: Jesse Zhang Date: Wed Sep 16 13:44:41 2026 +0800 drm/amdgpu/gfx11: set KMD_QUEUE for kernel gfx queues Set KMD_QUEUE in the GFX MQD and kernel ring control registers so CP preserves kernel IB VMIDs instead of replacing them with the queue VMID. Use prop->kernel_queue to distinguish kernel and user MQDs. Signed-off-by: Jesse Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 893642e0e3b2f5aa818e0ee4a49e2d401d541e3a) commit 9fe5745f9d8eca38d31d9b672a1998edf856f651 Author: Jesse Zhang Date: Wed Sep 16 13:44:27 2026 +0800 drm/amdgpu/gfx12: set KMD_QUEUE for kernel gfx queues Set KMD_QUEUE in the GFX MQD and kernel ring control registers so CP preserves kernel IB VMIDs instead of replacing them with the queue VMID. Use prop->kernel_queue to distinguish kernel and user MQDs. Signed-off-by: Jesse Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 14741c01680a803050e949744089b57fa53e02f7) commit 56b2b97e7893f495b2e2a91cd3e405b6358c61f0 Author: Jesse Zhang Date: Sun Sep 20 17:20:21 2026 +0800 drm/amdgpu: fix empty fence backup and replay intervals amdgpu_ring_set_fence_errors_and_reemit() and amdgpu_ring_backup_unprocessed_commands() masked last_seq and sync_seq to fence-array indices before the loop, then walked a do/while until the two indices met. When hardware completed every command before the driver signalled the fences, last_seq == sync_seq, but the masked-index do/while could not tell that empty interval from a full table and walked the whole fence array, backing up and replaying already-completed commands. Read the raw sequence numbers, return early through amdgpu_fence_process() when they are equal, and mask only at the array index. Guard the force-completion against a NULL guilty_fence so a non-guilty backup does not dereference it. Signed-off-by: Jesse Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 78fbe156637a11456fcd29615a56e098ec8a6990) commit 6b6c4fab8815bd1da5643c19278d364026b8665b Author: Jesse Zhang Date: Thu Sep 17 15:31:04 2026 +0800 drm/amdgpu: support non-guilty job save on ring backup amdgpu_ring_backup_unprocessed_commands() is also used to preserve a ring that carries no guilty command - for example a collateral kernel gfx ring that shares the faulting pipe during a gfx user-queue pipe reset. Such a ring is backed up with a NULL guilty_fence and all of its unprocessed commands must be saved so they can be replayed after the reset rebuilds the ring's MQD. The early-return that skips an already-seen guilty fence compared "ring->guilty_fence == guilty_fence", which is also true when both are NULL. A non-guilty save therefore hit the early return and left ring_backup_entries_to_copy at 0, so the pending commands were dropped when the ring was rebuilt. Guard the early return with a non-NULL guilty_fence so a NULL fence never takes it and every unprocessed command is backed up. Signed-off-by: Jesse Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit b3f73daa1c2498273981b68b7534e540614069e3) commit cd883d0a3937df82a5ea03709ba8ba623b868419 Author: Timur Kristóf Date: Wed Sep 23 14:03:53 2026 +0200 drm/amd/pm/si: Check AMD_IS_MOBILITY flag for PPSMC_SYSTEMFLAG_GPIO_DC Unfortunately, some desktop boards eg. the FirePro D500 have the HARDWAREDC platform flag set and also have a battery power state configured in their VBIOS. This makes no sense for a desktop GPU and results in incorrect behaviour: the clocks are stuck at lowest. We observed that the kernel driver can work around the issue in two possible ways: 1. Set PPSMC_SWSTATE_FLAG_DC on all power states 2. Clear PPSMC_SYSTEMFLAG_GPIO_DC We think that the PPSMC_SYSTEMFLAG_GPIO_DC flag makes the SMC assume it's running on battery even though this is a desktop machine with no battery, and that's why it doesn't do DPM on power states without PPSMC_SYSTEMFLAG_GPIO_DC. Issue was uncovered by "Fix updating clock limits from power states" because previously the limits for the battery state were not tracked separately. However, battery power state has lower frequencies and voltages, so the kernel doesn't set the DC flag on the current power state anymore. That causes the SMC to be stuck on the lowest clocks. Let's clear PPSMC_SYSTEMFLAG_GPIO_DC on desktop GPUs. We can use the AMD_IS_MOBILITY flag to determine that. Fixes: e6c5d36756e7 ("drm/amd/pm/si: Fix updating clock limits from power states") Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16352 Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923120354.1027996-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 58473c7c49ce9f5f5a4a1c24ffb9aa1d3c8771f4) Cc: stable@vger.kernel.org commit 3a52d587d1fc8e8bf94ba1b07374f7ec91aaffb4 Author: Timur Kristóf Date: Wed Sep 23 14:20:33 2026 +0200 drm/amd/display: Mark DCE 6.4 as not APU DCE 6.4 is found in Oland chips, which were advertised as low-end gaming GPUs in 2013~2015 and then have been sold as low-end workstation GPUs until 2017~2019. These are not APUs. Fixes: 7c15fd86aaec ("drm/amd/display: dc/dce: add initial DCE6 support (v10)") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923122033.1046651-3-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 1072aa811ea1e61d5f763e4ec1bc6d24bb61f14a) Cc: stable@vger.kernel.org commit 687d31ea9ac76b299817060fa1e5582d6c752ae0 Author: Timur Kristóf Date: Wed Sep 23 14:20:32 2026 +0200 drm/amd/display: Fix fast updates on DCE 8.1 DCE8 should use legacy fast updates. This was already set for DCE 8.0 and 8.3, but it seems that DCE 8.1 (found in Kaveri chips) was forgotten. This fix should be backported to all kernel versions that have "Refactor fast update to use new HWSS build sequence", but this patch won't apply cleanly to older kernels due to another refactor in "Remove dc param from check_update". Fixes: 0baae6246307 ("drm/amd/display: Refactor fast update to use new HWSS build sequence") Fixes: 9ec11bb842b6 ("drm/amd/display: Remove dc param from check_update") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923122033.1046651-2-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 57605379559e3b5044c8274a1010ec658e5e73af) Cc: stable@vger.kernel.org commit 88427119e1f039c8cdffd63726c136a986ef519f Author: Timur Kristóf Date: Wed Sep 23 14:20:31 2026 +0200 drm/amd/display: Fix fast updates on DCE 6.x DCE6 should use legacy fast updates, just like all DCE8 - DCN2. Set that flag for DCE 6.0, 6.1 and 6.4 (all DCE6 versions). Technically DCE6 should have been included when the fast update code was refactored, but it just happened to work until now. A recent commit "Attach only plane updates that actually changed" has exposed this issue because with that commit, DC accidentally took the new fast update code path for DCE6 as well, which caused it to boot into a black screen with a flip done timeout. This fix should be backported to all kernel versions that have "Refactor fast update to use new HWSS build sequence", but this patch won't apply cleanly to older kernels due to another refactor in "Remove dc param from check_update". Fixes: 0baae6246307 ("drm/amd/display: Refactor fast update to use new HWSS build sequence") Fixes: 9ec11bb842b6 ("drm/amd/display: Remove dc param from check_update") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923122033.1046651-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 698fda6e360625850413a2d1a90b72ae5f03073d) Cc: stable@vger.kernel.org commit 5e08102d1d336593160d1434261d50b0c0f6cbe6 Author: Arthur Heymans Date: Sat Sep 12 17:11:37 2026 +0200 drm/amd/display: Preserve eDP mode on initial ASSR failure Commit 56d8ce9d8c17 ("drm/amd/display: Apply correct panel mode when reinitializing hardware") made ASSR failure fall back to the default panel mode unless eDP mode had previously been applied. However, dc_link is zero-initialized and DP_PANEL_MODE_DEFAULT is zero. Before the first call to dp_set_panel_mode(), panel_mode therefore looks like a previously applied default mode. If ASSR setup fails during the first link training attempt, the driver incorrectly trains the eDP link using the default scrambling mode. On a Google Vilboz Chromebook running self-built coreboot firmware and PSP verstage, this leaves the panel mostly black with corrupted output along the top edge. Track whether panel_mode has actually been initialized, and only consult the saved mode after it has been applied. This retains the recovery behavior while preserving eDP mode during initial link training. Fixes: 56d8ce9d8c17 ("drm/amd/display: Apply correct panel mode when reinitializing hardware") Assisted-by: Pi:gpt-5.6-sol Reviewed-by: George Zhang Reviewed-by: Alex Hung Signed-off-by: Arthur Heymans Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit ccb6c2702033f1002b45807fb3cc938760f26f78) Cc: stable@vger.kernel.org # 6.4.x commit eb5650d1f367722d0136de18998749008fe7d2a7 Author: Adrian Betschart Date: Thu Sep 10 20:56:48 2026 +0200 drm/amd/display: Default HDMI RGB output to limited range on CTA modes With the Broadcast RGB property at Automatic, amdgpu_dm_get_output_color_space() selects COLOR_SPACE_SRGB for RGB output, so DC neither compresses the pixels nor, without a QS-capable sink, signals full range in the AVI InfoFrame. A sink that follows CTA-861 treats the default quantization of a CTA video format as limited and expands 16-235 to 0-255: everything below 16 is crushed to black, everything above 235 clips. Follow the CTA-861 default for Automatic instead, as the DRM HDMI state helper (hdmi_is_limited_range()) and i915 do: limited range on an HDMI sink for CTA modes other than 640x480, full range elsewhere. Full and Limited keep their explicit meaning. The same rule applies to the BT.2020 RGB branch. With commit 892659399f64 ("drm/amd/display: Propagate HDMI RGB quantization selectability") the AVI InfoFrame then carries the matching Q value on sinks that support selection. Measured on a Radeon RX 7600 (DCN 3.2.1) driving a JVC DLA-RS4100 at 1920x1080p24 RGB 12 bpc: the sink reports the signal as limited range while the picture shows crushed shadows; rendering limited range in the client makes it match a reference source. The KUnit fixtures that reach amdgpu_dm_get_output_color_space() now carry a connector, since Automatic reads its display_info, and five cases cover the new rule. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5796 Reviewed-by: George Zhang Signed-off-by: Adrian Betschart Assisted-by: Claude Code:claude-fable-5-1 Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit d23f735d0eac52c673d91e21d146b09588537efc) commit 015e72cde567d2450e282c2790773463156b2d0a Author: Jiangshan Yi Date: Fri Sep 4 17:18:17 2026 +0800 drm/amd/display: check dc_state_create_copy() for NULL in dm_suspend dc_state_create_copy() can return NULL on allocation failure. dm_suspend() only conditionally skips dm_gpureset_toggle_interrupts() and continues execution, returning success. dm_resume() then dereferences the NULL cached_dc_state in link_enc_cfg_copy() and the following dc_state->stream_count loop, crashing during GPU reset recovery. Return -ENOMEM immediately if the copy fails, so the caller aborts suspend instead of leaving a NULL cached state for resume. Fixes: 8092aa3ab8f7 ("drm/amd/display: Add null checker before passing variables") Reviewed-by: George Zhang Signed-off-by: Jiangshan Yi Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 84b6d7932fdd2857795a257f9f258562a3cddcab) Cc: stable@vger.kernel.org commit ce1e0223d8ad4211275c82a17ed6d43ab81e13d9 Merge: 100638f0f016cb 30724547b221e0 Author: Linus Torvalds Date: Thu Oct 1 12:47:16 2026 -0700 Merge tag 'devicetree-fixes-for-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fixes from Rob Herring: - Fix another case of refcount leaks in of_irq_init() - Avoid refcount leak in coreboot node check - Fix overlay handling of a root node target path - Various error path fixes in the overlay code * tag 'devicetree-fixes-for-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: of/irq: Fix remaining refcount leaks in of_irq_init() of: Put coreboot node after compatibility check of/overlay: don't create "//" paths for fragments targeting the root of/overlay: don't leak fragment references when changeset init fails of/overlay: only treat a positive changeset id as registered of/overlay: put property on deadprops only after changeset add succeeds commit 100638f0f016cb0e6c75e95ff2b0495bca0b3054 Merge: bd35955b089ad8 f341dc4d934a69 Author: Linus Torvalds Date: Thu Oct 1 11:46:39 2026 -0700 Merge tag 'pm-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Restore the previous behavior on systems where the cpufreq pressure was not visible in the scheduler and is not expected to be visible there. It became visible after a change made during the 7.2 development cycle that had gone too far" * tag 'pm-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: intel_pstate: Fix max_freq fallback in cpufreq_update_pressure() commit bd35955b089ad881f57a5a2619687c804d057fec Merge: a940b03cee1524 572af6872e520c Author: Linus Torvalds Date: Thu Oct 1 11:04:27 2026 -0700 Merge tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux Pull crypto library fixes from Eric Biggers: - Fix a performance regression in certain AES encryption modes on certain architectures, introduced this cycle - Fix a small performance regression in the x86_64 optimized AES-GCM code, introduced in 6.15 * tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: crypto: aes - Fix undesired override of some optimized AES modes crypto: x86/aes-gcm - fix always true check for last AAD segment commit a940b03cee1524c10c16e0f73ec878bbd36202a2 Merge: d24e8ac715de2e f9bfc323e76120 Author: Linus Torvalds Date: Thu Oct 1 10:57:19 2026 -0700 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull kvm fixes from Paolo Bonzini: "The most intrusive change is reverting a commit from 7.3-rc1 that made struct kvm a bit too large, and fixing the same issue otherwise. There are again a lot of selftests lines; the sheer number of commits is not small but I don't expect much more for 7.3 due to people travelling to Plumbers next week. ARM: - Take a reference on the last IRQ loaded into an LR to prevent it from being freed while running the guest (Marc Zyngier) - Ensure that the ITS MOVALL command only affects LPIs that were previously affined to the source redistributor (Marc Zyngier) - Fix + test for honoring the host's trap configuration when running non-protected VMs while KVM is in protected mode (Fuad Tabba) - Use the host stage-1 mapping granularity for VM_PFNMAP mappings at stage-2 (Mostafa Saleh) x86: Various bugfixes where the guest could do stupid things on purpose to cause problems in the host: - Failed VMRUNs can cause pending TLB flushes to be dropped, and in general some actions done through VMCB control fields have to be redone if VMRUN fails - Toggling MSR interceptions or eVMCS execution controls can cause the host to use a stale MSR permission bitmap - Bad page tables can cause a WARN. Also fix issues in last week's pull request (my fault, for changing email workflow and thus missing feedback sent to kvm@ but not LKML). Generic: - Take kvm_lock when creating vCPUs. For almost two decades everybody thought it was not done for some unspecified performance reasons, but in reality it was only done because kvm_lock was originally a spinlock. This is a better fix than 97d65b544f48 ("KVM: Check for duplicate vcpu_id as early as possible", from the 7.3 merge window), and does not waste 2K per VM, hence its inclusion here" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (29 commits) KVM: arm64: Use stage-1 leaf size for VM_PFNMAP KVM: arm64: selftests: Check a feature hidden in an ID register is UNDEF KVM: arm64: Use the host's HCR_EL2 for non-protected VMs in pKVM KVM: arm64: Clear HCR_EL2.RW for 32-bit non-protected vCPUs KVM: arm64: Apply the fine-grained UNDEFs without FEAT_FGT KVM: arm64: vgic-its: Fix MOVALL handling of source redistributor KVM: arm64: vgic: Take a refcount on IRQs referenced by last_lr_irq KVM: arm64: vgic: Allow last_lr_irq to be NULL when LRs are not overflowing KVM: SEV: Do cache maintenance on the source VM *before* clearing SEV state KVM: SEV: Nullify "have run CPUs" mask pointer when freeing it KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12 KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt KVM: selftests: Verify that L0's TPR doesn't get clobbered KVM: selftests: Run the nested x2APIC with and without APICv being inhibited in L2 KVM: selftests: Add x2APIC MSR test for inhibiting APICv while nested KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are modified KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted KVM: SVM: Sync guest's PERF_CNTR_GLOBAL_CTL from h/w only on successful VMRUN KVM: SVM: Don't mark ASID fields as dirty when setting control.tlb_ctl KVM: SVM: Update control fields on #VMEXIT if and only if VMRUN succeeded ... commit f9bfc323e76120c2cd1fdea93bbf315eec5eb934 Merge: 973ea70393e885 71cc2c67fb8f8d Author: Paolo Bonzini Date: Thu Oct 1 13:13:57 2026 -0400 Merge tag 'kvmarm-fixes-7.3-2' of https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 7.3, round #2 - Take a reference on the last IRQ loaded into an LR to prevent it from being freed while running the guest (Marc Zyngier) - Ensure that the ITS MOVALL command only affects LPIs that were previously affined to the source redistributor (Marc Zyngier) - Fix + test for honoring the host's trap configuration when running non-protected VMs while KVM is in protected mode (Fuad Tabba) - Use the host stage-1 mapping granularity for VM_PFNMAP mappings at stage-2 (Mostafa Saleh) commit 7b12c538697f2d5014dfd378c73be193d700c7a9 Merge: 33a154a96e71a3 aeb709c767aeca Author: Kumar Kartikeya Dwivedi Date: Thu Oct 1 18:40:06 2026 +0200 Merge branch 'bpf-fix-objects-stuck-in-free_by_rcu_ttrace' Alexei Starovoitov says: ==================== bpf: Fix objects stuck in free_by_rcu_ttrace From: Alexei Starovoitov The objects that bpf_mem_alloc frees while RCU tasks trace GP is in flight stay in free_by_rcu_ttrace list until the same bpf_mem_cache frees or allocates in bulk again. Patch 1 - refactoring. No functional change. Patch 2 - the fix. Patch 3 - selftest. Signed-off-by: Alexei Starovoitov ==================== Link: https://patch.msgid.link/20260930095920.601738-1-alexei.starovoitov@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit aeb709c767aeca996e6011133e4f7bdb2a4af652 Author: Alexei Starovoitov Date: Wed Sep 30 09:59:20 2026 +0000 selftests/bpf: Add a test for objects stuck in free_by_rcu_ttrace Delete all elements of BPF_F_NO_PREALLOC hash map in one batch. The first free_bulk() starts RCU tasks trace GP and the rest of the elements are freed while it's in flight. Wait for call_rcu_ttrace_in_progress to clear in bpf_mem_cache of every cpu and check that free_by_rcu_ttrace and waiting_for_gp_ttrace lists are empty. Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20260930095920.601738-4-alexei.starovoitov@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit fbd97dd1d3ce32d32fb7be86acc3fdb7c04fa043 Author: Alexei Starovoitov Date: Wed Sep 30 09:59:19 2026 +0000 bpf: Fix objects stuck in free_by_rcu_ttrace do_call_rcu_ttrace() returns early when call_rcu_ttrace_in_progress is set and leaves the objects in free_by_rcu_ttrace. __free_rcu() frees waiting_for_gp_ttrace only and clears the flag. Hence the objects that free_bulk() or __free_by_rcu() added while RCU tasks trace GP was in flight stay in free_by_rcu_ttrace until free_bulk() or alloc_bulk() is called for the same bpf_mem_cache again, which may never happen. The number of such objects is not bounded. Turn call_rcu_ttrace_in_progress into three states: 0 - idle 1 - __free_rcu() is queued 2 - __free_rcu() is queued and free_by_rcu_ttrace got more objects since do_call_rcu_ttrace() sets 2. __free_rcu() does cmpxchg(1 -> 0) and starts the next GP when it fails. It cannot clear the flag first and check free_by_rcu_ttrace later, since bpf_mem_alloc_destroy() frees bpf_mem_cache without waiting for RCU callbacks when the flag is zero. Now __free_rcu() queues itself, so the one that didn't see 'draining' may do call_rcu_tasks_trace() after rcu_barrier_tasks_trace() in free_mem_alloc(). Queue it under rcu_read_lock() and do synchronize_rcu() before the barriers. Calling rcu_barrier_tasks_trace() twice works too, but creating and destroying hash maps in a loop on many cpus slows down to one free_mem_alloc() per GP and kworkers pile up. Fixes: 8d5a8011b35d ("bpf: Batch call_rcu callbacks instead of SLAB_TYPESAFE_BY_RCU.") Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20260930095920.601738-3-alexei.starovoitov@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit 47f4f695cec1eb82d961fdb466cd7c99d2865b7c Author: Alexei Starovoitov Date: Wed Sep 30 09:59:18 2026 +0000 bpf: Factor out __do_call_rcu_ttrace() Move the part of do_call_rcu_ttrace() that runs after call_rcu_ttrace_in_progress is set into __do_call_rcu_ttrace(). The next patch will call it from __free_rcu(). No functional change. Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20260930095920.601738-2-alexei.starovoitov@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit 33a154a96e71a34a1bcca9f40da343dbbf7b38b4 Author: Alexei Starovoitov Date: Thu Oct 1 14:52:55 2026 +0000 selftests/bpf: Test packet range of pointers sharing an id Add tests where two packet pointers share an id and tightening one pointer's umax from its var_off would put it less than their constant distance from the other's umax: with an index & 0x38 capped at 50, the base pointer keeps umax 50, so the pointer 8 bytes further on must keep umax 58, even though its known bits allow at most 56. These refused a valid program or accepted an out-of-bounds access before the fix: - check the advanced copy, load through the base: valid, was refused; - check the base, load the byte at base + 1 through a copy advanced by 8: was accepted; - check base + 4, load 4 bytes at base + 2 through base + 8: reads two bytes past the checked range, was accepted; - the same as the second with data_meta pointers checked against data: was accepted. These pass with and without the fix and cover nearby paths: - subtract an unknown scalar from a checked pointer and load below it (the range is kept across a new id); - reach a load through two paths whose checks cover 8 and 7 bytes after the loaded pointer; the second path must not be pruned by the first; - spill a copy of a pointer, check the pointer, fill the copy and load one byte past the checked range: the load is refused, and the copy has the range of the check. Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20261001145255.855630-2-alexei.starovoitov@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit b88822d2584f78cbdad1d8256510dcac108b5630 Author: Alexei Starovoitov Date: Thu Oct 1 14:52:54 2026 +0000 bpf: Fix packet range of pointers sharing an id Since commit 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers"), find_good_pkt_pointers() sets the range of all packet pointers sharing an id from the umax of the compared pointer, and check_packet_access() requires umax + off + size <= range. That assumes the umax of two such pointers differ by exactly their constant distance. reg_bounds_sync() breaks it when var_off tightens one umax and not the other: r4 &= 0x38 if r4 > 50 goto exit ; umax 50, var_off (0x0; 0x38) r5 = pkt + r4 ; umax 50 r6 = r5 r6 += 8 ; umax 56, not 58 Comparing r6 with pkt_end sets the range to 56, and the valid 8-byte load at r5 is rejected (50 + 8 > 56). Comparing r5 sets it to 50, and the out-of-bounds 1-byte load at r6 - 7, i.e. r5 + 1, is accepted (56 - 7 + 1 <= 50). Don't call reg_bounds_sync() on a packet pointer that keeps its id (a constant was added or subtracted) or its range (an unknown non-negative value was subtracted), so that var_off cannot tighten its umax. Only update the 32-bit bounds from var_off: reg_bounds_sanity_check() wants them constant when the lower half of var_off is, e.g. for pkt + 8. This relies on nothing else changing the 64-bit bounds of a packet pointer, which holds today. var_off of such a pointer is no longer narrowed by its bounds. Adjust three verifier_align expectations; the low bits, which the alignment checks use, don't change. veristat on the selftests shows no verdict changes and +0.8% insns in test_cls_redirect_subprogs. Fixes: 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers") Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20261001145255.855630-1-alexei.starovoitov@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit 71cc2c67fb8f8d5aa8154eb482e9846d2214f11b Author: Mostafa Saleh Date: Tue Sep 29 20:02:09 2026 +0000 KVM: arm64: Use stage-1 leaf size for VM_PFNMAP When commit 2aa53d68cee6 ("KVM: arm64: Try stage2 block mapping for host device MMIO") added VM_PFNMAP support to get_vma_page_shift(), stage-1 page tables did not support huge PFNMAP (as in VFIO-PCI vfio_pci_mmap_huge_fault()) and transparent_hugepage_adjust() was unsafe for MMIO as it dereferenced struct page. Since commit 6011cf68c885 ("KVM: arm64: Walk userspace page tables to compute the THP mapping size"), transparent_hugepage_adjust() instead walks the host stage-1 page tables via get_user_mapping_size() without touching struct page. Meanwhile, commit 3e509c9b03f9 ("mm/arm64: support large pfn mappings") enabled stage-1 huge PFNMAP. So. we can drop the VMA-based VM_PFNMAP size calculation in get_vma_page_shift() and let transparent_hugepage_adjust() derive the stage-2 mapping size directly from the populated stage-1 leaf for non-cacheable mappings as well. Assisted-by: LLM Cc: stable@vger.kernel.org Fixes: 2aa53d68cee6 ("KVM: arm64: Try stage2 block mapping for host device MMIO") Reviewed-by: Marc Zyngier Signed-off-by: Mostafa Saleh Signed-off-by: Oliver Upton commit e060d9069b49fe55f38057dfe592068014652671 Author: Mark Rutland Date: Thu Oct 1 14:08:36 2026 +0100 arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems When system_supports_sme() is true but system_supports_sve() is false, restoring a specifically crafted SVE signal context can result in the task erroneously having non-streaming SVE state. Subsequent attempts to manipulate the task's FPSIMD/SVE/SME state can result in a variety of problems, including fatal EL1 UNDEFs. In such configurations, the kernel always creates an SVE signal context when delivering a signal, and this can only be in one of two states: (1) SVE_SIG_FLAG_SM is set, and an SVE payload is present containing streaming mode SVE state. The recorded VL is the task's live streaming VL. (2) SVE_SIG_FLAG_SM is clear, and an SVE payload is not present. The FPSIMD context contains the non-streaming mode FPSIMD state. The recorded VL is 0. Currently restore_sve_fpsimd_context() correctly rejects cases where SVE_SIG_FLAG_SM is set and an SVE payload is not present, but fails to reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is present. Consequently, restore_sve_fpsimd_context() can place the task in a state where it has non-streaming SVE state even when this is not supported by HW. For example, this can cause a later EL1 UNDEF when the kernel attempts to restore the task's ZCR_EL1 value: | # ./sme-sigcontext-to-sve | Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP | Modules linked in: | CPU: 0 UID: 0 PID: 131 Comm: sme-sigcontext- Not tainted 7.3.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 61402009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : fpsimd_restore_current_state+0x258/0x458 | lr : exit_to_user_mode_loop+0xb8/0x188 | sp : ffff80008056be40 | x29: ffff80008056be40 x28: fff00000c1670000 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: ffff80008056bec0 x22: 0000000000000008 x21: 0000000000000040 | x20: 0000000000000081 x19: 0000000008800010 x18: 0000000000000000 | x17: 0000fffffd412570 x16: 0000000000001000 x15: 0000fffffd4123b0 | x14: 0000fffffd412780 x13: 0000fffffd412be8 x12: 0000000047435300 | x11: 0000fffffd412570 x10: 0000000000000000 x9 : 0000000045585401 | x8 : fff00000c18a6c44 x7 : 0000000000000000 x6 : 0000000000000002 | x5 : 0000000000000002 x4 : ffff800080568000 x3 : 0000000000000001 | x2 : 0000000008800010 x1 : fff00000c1670000 x0 : 0000000008800000 | Call trace: | fpsimd_restore_current_state+0x258/0x458 (P) | exit_to_user_mode_loop+0xb8/0x188 | el0_svc+0x1cc/0x1d0 | el0t_64_sync_handler+0xa0/0xe4 | el0t_64_sync+0x198/0x19c | Code: d5384101 f9400020 53175c03 36b80de0 (d5381202) | ---[ end trace 0000000000000000 ]--- | Kernel panic - not syncing: Oops - Undefined instruction: Fatal exception in interrupt | Kernel Offset: 0x291fb1000000 from 0xffff800080000000 | PHYS_OFFSET: 0x40000000 | CPU features: 0x0,00000000,0052802f,ffb88f43,3afcf73f | Memory Limit: none Rework restore_sve_fpsimd_context() to reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is not present. As parse_user_sigframe() rejects SVE signal frames when neither SVE nor SME are supported, it isn't necessary for restore_sve_fpsimd_context() to handle the case where neither are supported. Fixes: 7dde62f0687c ("arm64/signal: Always accept SVE signal frames on SME only systems") Signed-off-by: Mark Rutland Reviewed-by: Mark Brown Cc: Catalin Marinas Cc: Will Deacon Cc: stable@vger.kernel.org Signed-off-by: Will Deacon commit cad16d850e3759dd82cd869f739b56e9844a1fee Author: Richard Fitzgerald Date: Thu Oct 1 09:58:30 2026 +0100 spi: cs42l43: Workaround for wrong speaker ID on Dell XPS 13 DX13260 On Dell XPS 13 DX13260 create an acpi_gpio_mapping with exactly two GPIO entries to point at the two pins in the GpioIo(). Use this to read the speaker ID GPIOs. This fixes problems on Dell XPS 13 DX13260: - No speaker audio - The wrong firmware was loaded so the speaker protection did not match the speaker characteristics. The Dell XPS 13 DX13260 has two speaker ID GPIOs, to form a 2-bit ID. The ACPI GpioIo() has both pins but the Linux-specific spk-id-gpios property only has a mapping to the first pin. This meant that the speaker ID was wrong in most cases, and that would lead to the codec driver loading the wrong amp firmware, or not finding a firmware (as 0 is not a valid ID on this laptop). Assisted-by: Codex:gpt-6-sol Reported-by: Wiza Jalakasi Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221956 Tested-by: Wiza Jalakasi Fixes: f3c605147741e ("spi: cs42l43: Add GPIO speaker id support to the bridge configuration") Signed-off-by: Richard Fitzgerald Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20261001085830.4014291-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit e6229c0402ea4863ec74802d79d5b52b9398d66c Author: Takashi Iwai Date: Thu Oct 1 17:10:36 2026 +0200 ALSA: ice1712: Fix the error handling via auto-cleanup at probe We used the auto-cleanup via snd_card_unref() for errors at probe of ice1712 driver, but this may be problematic in a subtle way when an error happens at snd_card_register(); since snd_card_unref() skips the snd_card_disconnect() call, it may miss some resource clearance. For fixing the issue, use the new __free(snd_card_free) instead, which does call snd_card_free() explicitly at errors for avoiding such a pitfall. Fixes: d736eba9c453 ("ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup") Link: https://patch.msgid.link/20261001151039.592033-2-tiwai@suse.de Signed-off-by: Takashi Iwai commit f1d565dc92955f05383794e0fa27e61ee0555027 Author: Takashi Iwai Date: Thu Oct 1 17:10:35 2026 +0200 ALSA: core: Define auto-cleanup for snd_card_free() For the errors at the probe time, we'd need to call rather snd_card_free() instead of the snd_card_unref() -- the former calls explicitly snd_card_disconnect() that cleans up the registered devices, etc, while the latter may leak in corner cases. For convenience, define a new auto-clean with snd_card_free. Link: https://patch.msgid.link/20261001151039.592033-1-tiwai@suse.de Signed-off-by: Takashi Iwai commit 7f85d1170575645f9f327062d78017a23b2714eb Author: Ji-Ze Hong (Peter Hong) Date: Mon Aug 24 21:18:14 2026 +0800 usb: f81604: fix struct f81604_int_data size mismatch 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 commit 7093c3b8314a4ef7405c4066a2521398c455efe7 Author: Oliver Hartkopp Date: Thu Oct 1 13:57:24 2026 +0200 can: fix unique skb identifier regression under RPS 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 (can_skb_uid = 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. 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/ Cc: stable@vger.kernel.org Tested-by: Oliver Hartkopp Tested-by: Joerg Willmann Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20261001115724.27192-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde commit 0a04c0cb8606ff88399489d03ef255afe90d0d5f Author: zjamg Date: Thu Sep 17 20:37:16 2026 +0800 can: dev: init_can_skb(): restore skb header initialization Commit 9f10374bb024 ("can: remove private CAN skb headroom infrastructure") removed the skb_reset_mac_header()/skb_reset_network_header()/ skb_reset_transport_header() calls from init_can_skb(). As a result, RX skbs from alloc_can_skb() and friends again carry mac_header = 0xFFFF. When such an skb reaches packet_rcv_spkt() (SOCK_PACKET), the push length calculation overflows and triggers skb_under_panic -> kernel BUG -> full machine panic. The same issue was originally reported in 2014 on linux-can and fixed by commit 969439016d2c ("can: add missing initialisations in CAN related skbuffs"). packet_rcv_spkt() itself has never been hardened: only packet_rcv() and tpacket_rcv() gained dev_has_header() checks in commit d549699048b4 ("net/packet: fix packet receive on L3 devices without visible hard header"). Fixes: 9f10374bb024 ("can: remove private CAN skb headroom infrastructure") Cc: stable@vger.kernel.org Reviewed-by: Oliver Hartkopp Acked-by: Oliver Hartkopp Signed-off-by: zjamg Tested-by: Quchaosheng Link: https://patch.msgid.link/20260917123716.63116-1-ndaugoing@gmail.com Reported-by: Shaunak Datar Closes: https://lore.kernel.org/all/20260918151606.765490-1-shaunakkdatar@gmail.com Signed-off-by: Marc Kleine-Budde commit c24362650f7a8573dc9a9991a034b8500af8eb19 Author: Ali Ahmet Memis Date: Thu Jul 30 06:00:31 2026 +0300 tools/power turbostat: Read complete CPU lists CPU_SUBSET_MAXCPUS accepts CPU IDs through 8191, but the sysfs and cgroup CPU-list readers stop at 1024 bytes. A fragmented cpuset or hybrid PMU CPU list can exceed that size and be truncated. initialize_cpu_set_from_sysfs() can also pass a full, non-NUL-terminated buffer to parse_cpu_str(), causing an out-of-bounds read. Additionally, initialize_cpu_set_from_sysfs() returns with the file still open on success. It is now called once per CPU for thread_siblings_list, so large systems can leak thousands of descriptors during topology discovery. Use getline() so both readers receive a complete, NUL-terminated line. Close and free the sysfs CPU-list resources on every path, and report malformed input from the correct buffer. Fixes: eb187540d13a ("tools/power turbostat: Increase CPU_SUBSET_MAXCPUS to 8192") Fixes: 58839fdbd441 ("tools/power turbostat: Process HT siblings in CPU order") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Signed-off-by: Len Brown commit d24e8ac715de2e16a53c144005b1863660a5fbea Merge: 703033e2350c8c e23a64eb244356 Author: Linus Torvalds Date: Thu Oct 1 06:41:59 2026 -0700 Merge tag 'net-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from Bluetooth, WiFi and netfilter. We are actively retargeting several non-urgent fixes towards next, but the traffic on the ML looks ever-increasing, and propagating the push-back towards subsystems is not immediate. No known outstanding regressions. Current release - regressions: - netfilter: nft_set_rbtree: skip transaction elements during GC Previous releases - regressions: - sched: cls_api: reclaim an empty proto on the error path - core: - fix checksum offsets in skb_splice_from_iter() - cap skb->queue_mapping when the tx queue is picked - page_pool: fix use-after-free in page_pool_recycle_ring_bulk() - wifi: - mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue() - mac80211: drop oversized fragments to avoid extra_len overflow - netfilter: - flowtable: restore ieee80211 forward path - bluetooth: hci_conn: Lock parent access during enhanced SCO setup - eth: - bcmgenet: allocate RX buffers as page fragments - stmmac: fix rx Scatter-Gather support - octeontx2-pf: fix aura BPID assignment when CONFIG_DCB is enabled - gve: DQO: accept TSO packets with non-protocol gso_type bits - r8169: disable EEE on RTL8168h/8111h Previous releases - always broken: - tcp: refresh TS.Recent for accepted old ACKs - wifi: - ath11k: reset ar->num_stations on hardware start - cfg80211: fix RTS threshold setting for single-radio PHY - bluetooth: btintel_pcie: fix plen overflow in btintel_pcie_recv_frame() - eth: bcmgenet: fix NULL dereference in set_coalesce before first open Misc: - Eric is retiring from google and updating his contact info" * tag 'net-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (96 commits) net: phy: aquantia: fix system interface type not updated in forced mode net: usb: qmi_wwan: add Rolling Wireless RN947R net: mvneta: clear XDP pfmemalloc flag between frames ipv6: sr: use skb_get_hash_net() in seg6_make_flowlabel() net/mlx5e: Fix AF_XDP TX timestamp teardown NULL dereference r8169: disable EEE on RTL8168h/8111h octeontx2-pf: Fix RSS indirection table size sctp: check RCV_SHUTDOWN after the sendmsg connect wait net: sparx5: make ports inherit the switch base mac address type net: microchip: vcap: stop scanning after deleting key field netfilter: flowtable: restore ieee80211 forward path netfilter: flowtable: generalize pending status bit netfilter: bpf: reject invalid NAT manipulation types netfilter: nft_set_rbtree: skip transaction elements during GC ipvs: filter some flags received in the backup server ipvs: do not create invisible templates ipvs: bound LBLCR and LBLC cache growth ipvs: fix missing counter decrement in lblc netfilter: nft_flow_offload: drop flowtable reference on init error path selftests: net: check timestamp echo after an old ACK ... commit bca45af5998a05f34b13a2ef11e639bac9c62643 Author: Maíra Canal Date: Wed Sep 30 16:06:51 2026 -0300 drm/vc4: Use kvmalloc_objs() for the BO cache size list The BO cache size list has one entry per BO page count, so its size scales with the largest BO ever freed. A 64 MiB BO already needs at least an order-6 allocation, which fails under fragmentation and triggers a warn_alloc() splat on BO close: page allocation failure: order:7, mode:0x40cc0(GFP_KERNEL|__GFP_COMP) Call trace: ... warn_alloc+0x118/0x190 __alloc_pages_slowpath+0x4a8/0x520 ... __kmalloc_noprof+0x3ac/0x5d8 vc4_free_object+0x128/0x370 [vc4] drm_gem_object_handle_put_unlocked+0xb8/0x158 [drm] drm_gem_object_release_handle+0x74/0xe8 [drm] drm_gem_handle_delete+0x6c/0xa8 [drm] drm_gem_close_ioctl+0x34/0x50 [drm] The list doesn't need physically contiguous memory. Use kvmalloc_objs() so large lists can fall back to vmalloc(), avoiding the allocation failure. Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.") Reviewed-by: Thadeu Lima de Souza Cascardo Link: https://patch.msgid.link/20260930190721.1897264-2-mcanal@igalia.com Signed-off-by: Maíra Canal commit b41ff8b529278216cba22a5dcdc93fea2a3a9619 Author: Maíra Canal Date: Wed Sep 30 16:06:50 2026 -0300 drm/vc4: Free the BO cache size list on teardown 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 commit 703033e2350c8c9fcacd652f36675e1327221b10 Merge: 5cd9813d848d65 fdd6553e1e53b0 Author: Linus Torvalds Date: Thu Oct 1 06:31:40 2026 -0700 Merge tag 'sysctl-7.03-fixes-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl Pull sysctl fixes from Joel Granados: "Fix sysctl jiffies conversions errors introduced in 2dc164a48e6f ("sysctl: Create converter functions with two new macros") - Ensure that mult_hz does *not* wrap - Ensure we pass just the magnitude for the negative branch in proc_int_k2u_conv_kop" * tag 'sysctl-7.03-fixes-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl: time/jiffies: Saturate in mult_hz() instead of wrapping sysctl: Negate before converting in the int read path commit 8e242ada093af7d2ee82037f09c287fbc6f1e3f5 Merge: 540f55de8c9f79 9ee8306121495d Author: Greg Kroah-Hartman Date: Thu Oct 1 14:57:00 2026 +0200 Merge tag 'iio-fixes-late-7.3' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-linus Jonathan writes: IIO: Fixes for 7.3, or 7.4 merge window. Nothing here strikes me as particularly urgent. The core buffer one has been there a long time and is a race only seen during driver removal. core - Ensure buffer teardown on remove occurs under same locks as in other paths, preventing races around access to active_scan_mask. adi,ad-sigma-delta - Fix a use-after-free in driver unbind path by just always allocating a buffer that is large enough rather than trying to resize at runtime. adi,ad4030 - Fix validation of oversampling_ratio to check if value is in range before using it. adi,ad7173 - Fix swapped masks for filter fields being written. adi,ad9000 - Fix a potential NULL dereference. kionix,kxcfjk-1013 - Reject disable of disabled event with underflows on runtime PM. inv,icm42607 - Don't eat runtime suspend errors. - Make sure to put runtime PM back on errors in system resume. isil,isl29501 - Fix a wrong return type for register_write function so it can return error codes. st,stm32-adc - Fix checking for whether a channel actually exists. - Avoid a possible division by zero. ti,pac1934 - Fix missing memory allocation check. * tag 'iio-fixes-late-7.3' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio: iio: adc: ad_sigma_delta: fix use-after-free on unbind iio: accel: kxcjk-1013: reject duplicate event disable iio: buffer: serialize buffer teardown with mode claims iio: cdc: ad7150: fix OF matching and publish module aliases iio: adc: ade9000: fix NULL pointer dereference in clkout registration iio: adc: ad4030: fix invalid oversampling_ratio validation iio: adc: ad7173: Fix digital filter configuration iio: adc: stm32-adc: fix possible division by zero in processed channel iio: adc: stm32-adc: fix check on internal channel availability iio: proximity: isl29501: Fix return type of isl29501_register_write iio: imu: inv_icm42607: restore runtime PM on system resume errors iio: imu: inv_icm42607: propagate runtime suspend errors iio: adc: pac1934: check ACPI label duplication commit ecce445c6489895463b7ddec2af66338287fee4c Author: Myeonghun Pak Date: Sun Sep 13 18:30:19 2026 -0400 drm/aspeed: Balance the display clock enable on teardown 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 commit 755c94d178b7e972bb766199d34e4ba4f63a89eb 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 __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 commit 65db42a9fae05c46a5df5b7ca5c175b80f9c4278 Author: George Moussalem Date: Mon Sep 28 13:48:47 2026 +0400 pinctrl: qcom: ipq5018: update PWM groups and corresponding pin functions On multiple Linksys routers, GPIOs 1, 30, and 46 drive the PWM LED on the PWM1, PWM3, and PWM0 channels, respectively. Update the corresponding PWM groups to include these GPIOs and allocate the PWM functions to empty slots in the relevant pin groups. Signed-off-by: George Moussalem Link: https://patch.msgid.link/20260928-ipq5018-pwm-functions-v2-1-87bbcd706bc6@outlook.com Signed-off-by: Bartosz Golaszewski commit 7efa1a1953cd6b20b23a3524d5b4b81789c6ef25 Author: Fan Wu Date: Tue Sep 29 09:36:46 2026 +0000 gpio: mpsse: fix race when arming the IRQ poll worker 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 commit 45f7304679875eb000d67e194090ee7abd05c89c Author: Beata Michalska Date: Thu Oct 1 11:00:32 2026 +0200 arm64: errata: Add Cortex-A725 erratum 3821522 workaround Cortex-A725 erratum 3821522 affects the CNT_CYCLES event, which can incur a significant increment error when a CPU enters and subsequently exits WFE or WFI, and may no longer track the system counter frequency. The AMEVCNTR01_EL0 counter is used as the AMU constant counter for frequency invariance and CPPC FFH feedback counters. Wire the affected Cortex-A725 range into the shared broken AMU constant-counter capability so the affected counter is treated as unavailable by returning zero in the AMU counter paths. This prevents the broken counter from being used as a reference source. The erratum can also affect PMUv3 users of the CNT_CYCLES event, but this workaround intentionally does not change PMU event handling. Hiding or rejecting the PMU event from the erratum code would change the perf-visible PMU event interface, including raw event selection, and would need a separate PMU-specific approach rather than being folded into the AMU reference-counter workaround. Cc: stable@vger.kernel.org Signed-off-by: Beata Michalska Reviewed-by: Vladimir Murzin Signed-off-by: Will Deacon commit 573371caf7aea8582212da81dcead2c3f48fac4b Author: Beata Michalska Date: Thu Oct 1 11:00:31 2026 +0200 arm64: errata: Factor out broken AMU const counter cap Move the workaround from the erratum 2457168-specific cpucap to a generic broken AMU constant-counter one. This keeps the existing Cortex-A510 handling unchanged while allowing other errata with similar AMU constant counter issue to share the capability bit and call sites. Signed-off-by: Beata Michalska Reviewed-by: Vladimir Murzin Signed-off-by: Will Deacon commit cbade031e2ebb3ca0a423b1804ce87908b27c229 Merge: b4698e50d4601f b138e16fb1e813 Author: Christian Brauner Date: Thu Oct 1 14:18:49 2026 +0200 Merge patch series "mount: more bugfixes, the Oprah edition" Christian Brauner says: Yet more bugfixes falling out of my recent work in this area: - don't let a pseudo dentry become the root of a mount - don't drop active namespace references that were never taken - don't put a mountpoint on a dentry that's being removed - remove the fsnotify marks of a mount namespace in process context - don't reconfigure internal superblocks via remount and umount - check the mounts before reading their parents in pivot_root() - look at the topmost mount for a mount namespace file - keep covered mounts covered in OPEN_TREE_NAMESPACE - check a recursive bind mount for mount namespace loops - check a submount for references right before unmounting it - queue a mount only once for mount notifications * patches from https://patch.msgid.link/20260930-work-mount-fixes-3-v1-0-be34c83956ae@kernel.org: namespace: don't let a pseudo dentry become the root of a mount unshare: don't drop active namespace references that were never taken dcache: don't put a mountpoint on a dentry that's being removed namespace: remove the fsnotify marks of a mount namespace in process context selftests/filesystems: check that the nullfs root can't be reconfigured namespace: don't reconfigure internal superblocks via remount and umount namespace: check the mounts before reading their parents in pivot_root() selftests/filesystems: check that a mount namespace file on top doesn't bury a mount namespace: look at the topmost mount for a mount namespace file selftests/filesystems: check that OPEN_TREE_NAMESPACE keeps mounts covered namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE selftests/filesystems: check that a recursive bind mount can't pin the caller's mount namespace namespace: check a recursive bind mount for mount namespace loops selftests/filesystems: check that a busy submount survives a synchronous umount namespace: check a submount for references right before unmounting it namespace: queue a mount only once for mount notifications Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-0-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) commit b138e16fb1e81376cea89f727dda7bfccd140de4 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 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) commit 0b6f31a3c0b16066f812e94b52a704174a6f23cd Author: Christian Brauner Date: Wed Sep 30 15:32:08 2026 +0200 unshare: don't drop active namespace references that were never taken Active references on the namespaces of an nsproxy are taken when the nsproxy is installed into a task in switch_task_namespaces() and copy_namespaces() and dropped again by put_nsproxy() through deactivate_nsproxy(). But ksys_unshare() calls put_nsproxy() on an nsproxy that was never installed when set_cred_ucounts() fails. The new namespaces of that nsproxy go from zero to minus one and the namespaces shared with the caller lose a reference that belongs to the nsproxy the caller keeps using: WARNING: kernel/nscommon.c:171 at __ns_ref_active_put+0x1cd/0x230 nsproxy_ns_active_put deactivate_nsproxy ksys_unshare Afterwards the namespaces the caller lives in aren't listed by listns() anymore. set_cred_ucounts() only fails when alloc_ucounts() can't allocate and it only allocates when the real uid of the caller differs from its effective uid. Commit cefd55bd2159 ("nsproxy: fix free_nsproxy() and simplify create_new_namespaces()") separated the two cases on purpose. nsproxy_free() frees an nsproxy that was prepared but never installed and that's what a failed setns() uses in put_nsset(). Export it and use it for a failed unshare() as well. Fixes: a98621a0f187 ("unshare: fix nsproxy leak in ksys_unshare() on set_cred_ucounts() failure") Cc: stable@vger.kernel.org # v7.1+ Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-16-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 75f4197f1e11d2eb75c2d6f916a7d4764db621e5 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 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) commit 1a116222acdcc1bc1a8350727ae6f28907d44594 Author: Christian Brauner Date: Wed Sep 30 15:32:05 2026 +0200 namespace: remove the fsnotify marks of a mount namespace in process context 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) commit 5e83e3a38b4d1ee99b044b968b78e3ca0935bab3 Author: Christian Brauner Date: Wed Sep 30 15:32:04 2026 +0200 selftests/filesystems: check that the nullfs root can't be reconfigured Add a test for the root of an empty mount namespace: - fspick() of the root fails with EINVAL - mount(MS_REMOUNT) of the root fails with EINVAL - umount() of the root fails and doesn't remount it read-only Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-12-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) commit d791606bb915a8f27e36657696fd1d9a216c5c08 Author: Christian Brauner Date: Wed Sep 30 15:32:03 2026 +0200 namespace: don't reconfigure internal superblocks via remount and umount Commit 02587a4af82a ("fs: refuse fspick() on internal superblocks") blocked fspick() on SB_NOUSER superblocks. But that's not the only way to reconfigure_super(). mount(MS_REMOUNT) and umount() of the caller's root without MNT_DETACH. The root of an empty mount namespace is a nullfs mount and all mount namespaces share that superblock: nullfs: fspick: FAIL errno=22 (Invalid argument) nullfs: mount(MS_REMOUNT|MS_RDONLY): ok(0) nullfs after remount: statfs(/): magic=0x4e554c4c flags=0x21 RDONLY nullfs: umount2("/", 0): ok(0) Refuse both like fspick() does. Only root in the initial user namespace can do this and nullfs is empty and immutable so the flags don't buy anything. But they show up in statfs() for the root of every mount namespace on the host. Fixes: 9d4e752a24f7 ("namespace: allow creating empty mount namespaces") Cc: stable@vger.kernel.org # v7.1+ Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-11-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 6b7c001eb5857fa09041f47673666060a2e5fc1c Author: Christian Brauner Date: Wed Sep 30 15:32:02 2026 +0200 namespace: check the mounts before reading their parents in pivot_root() 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) commit c518a195f631cbf03444078d564d378cd9fa4a32 Author: Christian Brauner Date: Wed Sep 30 15:32:01 2026 +0200 selftests/filesystems: check that a mount namespace file on top doesn't bury a mount Add a test for moving a mount with a mount namespace file on top of it: - S, a bind mount of a file, with a newer mount namespace's file on top - A shared with a slave B that has Q on B/file - S moved onto A/file, its copy lands on B/file below Q B/file keeps reading Q and once Q is unmounted it reads the copy. Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-9-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 8714b44adac7b10506e1db3ef1710689751f0f10 Author: Christian Brauner Date: Wed Sep 30 15:32:00 2026 +0200 namespace: look at the topmost mount for a mount namespace file 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) commit fe187cbb48323aecb6fe58906341bc6478b6f2f0 Author: Christian Brauner Date: Wed Sep 30 15:31:59 2026 +0200 selftests/filesystems: check that OPEN_TREE_NAMESPACE keeps mounts covered Add a test for open_tree(OPEN_TREE_NAMESPACE) from a user namespace that doesn't own the mount namespace it copies from: - a file covered by a private or an unbindable tmpfs mount - the non-recursive copy of the parent mount fails with EINVAL - the recursive copy keeps the file covered in the new mount namespace - the owner of the mount namespace keeps the bind mount semantics Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-7-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 0febe278ec45b1ccdbe9bd5ff1ba365d8fd55e2a Author: Christian Brauner Date: Wed Sep 30 15:31:58 2026 +0200 namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE open_tree(OPEN_TREE_NAMESPACE) creates a new mount namespace from a copy of the tree at the given path. The caller needs to be privileged over its current user namespace because the new mount namespace will be owned by it. It doesn't need to be privileged over the mount namespace the tree is copied from. An unprivileged user just needs to create a user namespace first. The copy follows the rules of a detached bind mount. Without AT_RECURSIVE only the mount itself is cloned and its children are left out. With AT_RECURSIVE unbindable mounts are skipped. Both is fine when the caller has privileges over the source mount namespace because it could unmount those mounts anyway. Not so for an unprivileged user in that mount namespace. For them a mount namespace copy is what unshare() does. copy_mnt_ns() copies everything including unbindable mounts and lock_mnt_tree() makes sure nothing can be unmounted in the copy. Nothing that was covered gets revealed. create_new_namespace() only does the locking and so the covered content is right there in the new mount namespace: # mount -t tmpfs none /tmp/otn; mkdir /tmp/otn/covered # echo hidden > /tmp/otn/covered/under.txt # mount -t tmpfs none /tmp/otn/covered uid 1000, after unshare(CLONE_NEWUSER): fd = open_tree(AT_FDCWD, "/tmp/otn", OPEN_TREE_NAMESPACE); setns(fd, CLONE_NEWNS); open("/covered/under.txt", O_RDONLY) -> "hidden" Covering paths with mounts is how container runtimes mask parts of /proc and /sys and how admins hide things. When the caller's user namespace doesn't own the source mount namespace copy the way unshare() does and refuse a non-recursive copy of a mount that has anything mounted below the requested directory and copy unbindable mounts in a recursive copy. A caller that is privileged over the source mount namespace sees no change. Fixes: 9b8a0ba68246 ("mount: add OPEN_TREE_NAMESPACE") Cc: stable@vger.kernel.org # v7.0+ Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-6-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 7c07b183000eb0ae21408581df88cffbcd38d8a0 Author: Christian Brauner Date: Wed Sep 30 15:31:57 2026 +0200 selftests/filesystems: check that a recursive bind mount can't pin the caller's mount namespace Add a test for a recursive bind mount of a namespace file in another mount namespace: - a bind mount of the network namespace file, held through a descriptor - the caller's own mount namespace file stacked on top of it there - the recursive bind mount through the descriptor fails with EINVAL - a plain bind mount of the file still works The copy would pin the namespace it is put in otherwise. Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-5-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) commit c640a01a78e42302879006ed7b7d5a9a943ba815 Author: Christian Brauner Date: Wed Sep 30 15:31:56 2026 +0200 namespace: check a recursive bind mount for mount namespace loops 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) commit 520b5a15fc9db81404e337e2904bebaf147b2b03 Author: Christian Brauner Date: Wed Sep 30 15:31:55 2026 +0200 selftests/filesystems: check that a busy submount survives a synchronous umount Add a test for the shrinkable submounts of a synchronous umount: - P shared, P1 a slave that is shared in turn, P2 its peer - B on P/options with copies on P1 and P2, R on top of the copy in P2 - P with B moved below P1, R is the working directory - umount(P1) slides R to where the copy of B is looked up The umount fails with EBUSY and R stays mounted. Needs the tracefs automount below debugfs for the shrinkable mounts. Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-3-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 32bf92416614a1e3ff3524fc6b780259c7aad3ef Author: Christian Brauner Date: Wed Sep 30 15:31:54 2026 +0200 namespace: check a submount for references right before unmounting it 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) commit bd2feb7796b6585938a4241e7b7c4148a6f7b762 Author: Christian Brauner Date: Wed Sep 30 15:31:53 2026 +0200 namespace: queue a mount only once for mount notifications 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) commit 357e8a77a501d96c9517f01f4a211eed5e9c9184 Author: Zhengchuan Liang Date: Mon Sep 28 10:59:35 2026 -0700 perf: Require kernel access for text poke events Perf events with exclude_kernel=1 can be opened without kernel perf access. However, exclude_kernel does not suppress text-poke sideband records. Every PERF_RECORD_TEXT_POKE is marked PERF_RECORD_MISC_KERNEL and contains a raw kernel instruction address. An unprivileged task can therefore open and mmap a task-local software event with text_poke=1. Both opening a count-only tracepoint event and configuring UDP GRO for ESP-in-UDP cause updates to inline static calls; the observer receives the relocated addresses of the modified instructions. For a known kernel image, any such address reveals the runtime kernel text base despite KASLR. Call perf_allow_kernel() whenever attr.text_poke is set, regardless of exclude_kernel. Events that neither monitor kernel execution nor request text-poke records retain their existing permissions. Fixes: e17d43b93e54 ("perf: Add perf text poke event") Assisted-by: LLM Signed-off-by: Zhengchuan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/99131354c41e23188f778b92f90363775b482395.1790573390.git.zcliangcn@gmail.com commit b9d1fdc6f4ac1b6e49f9deafaf137da1407d9af1 Author: Ian Rogers Date: Tue Sep 29 15:23:32 2026 -0700 perf: Replace perf_event_header__init_id with full header init perf_iterate_sb() invokes its callback for each matching perf_event on the CPU and task context, passing a shared caller-allocated event structure. perf_event_header__init_id() mutated header->size in place by adding event->id_header_size, requiring sideband output callbacks to save and restore header fields across iterations. Three sideband callbacks failed to save and restore header.size around perf_event_header__init_id(): - perf_event_ksymbol_output() - perf_event_bpf_output() - perf_event_text_poke_output() When multiple events with attr.ksymbol, attr.bpf_event, or attr.text_poke and sample_id_all are active on the same CPU, each subsequent event receives a record whose header.size is inflated by all preceding events' id_header_size values while only a single id_sample is written, leaving uninitialized ring-buffer bytes at the end of the record and causing userspace perf to fail with -EFAULT ("Bad address") when parsing the sample_id trailer. Similarly, perf_event_mmap_output() set PERF_RECORD_MISC_MMAP_BUILD_ID in mmap_event->event_id.header.misc when event->attr.build_id was enabled, but only saved and restored header.size and header.type. If an event with attr.build_id was followed by an event with attr.mmap2 and !attr.build_id, the second event received PERF_RECORD_MISC_MMAP_BUILD_ID in header.misc while its payload contained maj/min/ino/ino_generation instead of a build ID. Rather than splitting header initialization between callers and output callbacks and saving/restoring mutated header fields, replace perf_event_header__init_id() with perf_event_header__init(), which initializes header->type, header->misc, and header->size alongside the sample_id fields on each invocation. Fixes: 76193a94522f ("perf, bpf: Introduce PERF_RECORD_KSYMBOL") Fixes: 6ee52e2a3fe4 ("perf, bpf: Introduce PERF_RECORD_BPF_EVENT") Fixes: e17d43b93e54 ("perf: Add perf text poke event") Fixes: 88a16a130933 ("perf: Add build id data in mmap2 event") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260929222332.973435-1-irogers@google.com Cc: stable@vger.kernel.org commit ffb684f2aa141eeb0caa6308422e7e05d1ded7c4 Author: Luo Gengkun Date: Sun Sep 20 07:50:26 2026 +0000 perf: Fix race between perf_event_exit_task() and perf_pending_task() A race condition exists between perf_event_exit_task() and perf_pending_task() during begin_new_exec(). During begin_new_exec(), perf_event_exit_task() may be called, and the PF_EXITING flag is not set on task. So perf_sigtrap() continues to execute and triggers WARN_ON_ONCE(event->ctx->task != current). Since both task exit and exec paths can call perf_event_exit_task() which sets ctx->task to TASK_TOMBSTONE, fix this by explicitly checking if event->ctx->task equals TASK_TOMBSTONE and dropping the redundant PF_EXITING check. Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events") Signed-off-by: Luo Gengkun Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260920075026.990582-1-luogengkun2@huawei.com commit c98bf3b86609a18ab16d067280257326e557c636 Author: Hongjian Dai Date: Wed Sep 30 00:43:40 2026 +0800 i2c: at91: release DMA channels when probe defers at91_twi_probe_master() can return -EPROBE_DEFER from at91_init_twi_recovery_info() after at91_twi_configure_dma() has already claimed the tx/rx DMA channels. at91_twi_probe() then returns without releasing them, and since dma_request_chan() is not devres-managed the channels leak on every deferred probe attempt. Release the channels before deferring the probe. Fixes: f7eeb1af8537 ("i2c: at91: release DMA channels on remove and probe error") Assisted-by: LLM Signed-off-by: Hongjian Dai Signed-off-by: Andi Shyti Link: https://patch.msgid.link/7D85C6CB6BF0A82E+20260929164340.41628-1-daihongjian@kylinsec.com.cn commit a93862fa670a9c99fd9a24fb2ef69e4f948d9bd5 Merge: 1ff77cbefe5a65 395e9f2967a7ac Author: Greg Kroah-Hartman Date: Thu Oct 1 13:26:31 2026 +0200 Merge tag 'thunderbolt-for-v7.3-rc6' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-linus Mika writes: thunderbolt: Fixes for v7.3-rc6 This includes following USB4/Thunderbolt fixes: - Fix XDomain property parser to reject oversized properties responses. - Revert a quirk that causes deadlock at shutdown. - Fix USB4STREAM to announce FMODE_NOWAIT. - Add a quirk that disables CL states for Anker Prime TB5 dock to avoid link instability. All these have been in linux-next with no reported issues. * tag 'thunderbolt-for-v7.3-rc6' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Disable CL states for the Anker Prime TB5 dock thunderbolt: stream: Announce support for FMODE_NOWAIT Revert "thunderbolt: Add quirk to reset host interface on DMA path teardown for AMD USB4 routers" thunderbolt: Reject oversized XDomain properties responses commit fc79aeb86a2c244c1f1894e2d8f2966fe2b60fa2 Author: Mikulas Patocka Date: Wed Sep 30 18:42:20 2026 +0200 dm-integrity: validate the superblock on resume dm_integrity_resume() re-reads the superblock from the device so that it picks up the flags and the recalculate position. It performs no validation on the result, while the constructor validates the superblock it reads and sizes all the in-memory structures according to it. The user may modify the superblock on the underlying device while the dm-integrity device is suspended, so that the two no longer agree. In particular, access_journal_data() shifts the journal entry index by ic->sb->log2_sectors_per_block, while ic->journal_section_sectors and the journal page list were computed with the value that was present at constructor time. Increasing log2_sectors_per_block makes the index run past the end of the journal, and dm-integrity then writes 512 bytes through lowmem_page_address(NULL). Snapshot the validated superblock in the constructor and refuse to resume if any of the fields that describe the on-disk geometry changed. Reported-by: syzbot+675c91651049ad042c5f@syzkaller.appspotmail.com Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Fixes: 118ba36e446c ("dm-integrity: fix recalculation in bitmap mode") Assisted-by: Claude:claude-opus-5 commit e23a64eb244356ee47c0620f0722d51bd88db522 Merge: 6e0022b5ae3dc5 3ae37eafd36694 Author: Paolo Abeni Date: Thu Oct 1 12:00:40 2026 +0200 Merge tag 'nf-26-09-30' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Pablo Neira Ayuso says: ==================== Netfilter/IPVS fixes for net The following batch contains Netfilter fixes for net. This batch fixes crashes as recent feature regression, one of the due to a dependency that has been pulled into -stable: 1) Expand existing ipset fix for bitmap sets to disallow comments updates from kernel-side adds, from Florian Westphal. 2) Drop flowtable reference if nf_ct_netns_get() fails, otherwise flowtable cannot ever be removed, from Aohan Mei. 3) nft_rbtree GC should collect end elements that contained in this transaction batch, new or deleted elements are never expired. From Weiming Shi. 4) Restrict nf_nat_bpf so it does not set unknown NF_NAT_MANIP_* values, from Fernando F. Mancera. 5) Flowtable GC must skip flows that are pending hardware updates, generalize the PENDING flag and use it to inhibit GC. 6) Restore flowtable with ieee80211 which broke due to a relatively recent commit, which was pulled in by -stable, causing a regression in 6.18 kernels. And the following IPVS fixes: 1) Fix accounting of cache entries in IPVS LBLC for destinations, which eventually fills up the table and trigger recurrent resizing, from Julian Anastasov. 2) Limit IPVS cache growth for LBLCR and LBLC schedulers, from Zhiling Zou. 3) Restrict IP_VS_CONN_F_ONE_PACKET for normal connections, do not allow to use it with templates. Also from Julian. 4) Sanitize flags in IPVS sync messages received in the backup. From Julian Anastasov. netfilter pull request 26-09-30 * tag 'nf-26-09-30' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: flowtable: restore ieee80211 forward path netfilter: flowtable: generalize pending status bit netfilter: bpf: reject invalid NAT manipulation types netfilter: nft_set_rbtree: skip transaction elements during GC ipvs: filter some flags received in the backup server ipvs: do not create invisible templates ipvs: bound LBLCR and LBLC cache growth ipvs: fix missing counter decrement in lblc netfilter: nft_flow_offload: drop flowtable reference on init error path netfilter: ipset: do not update comments from kernel-side adds ==================== Link: https://patch.msgid.link/20260930074142.298353-1-pablo@netfilter.org Signed-off-by: Paolo Abeni commit 39495ef5d6f8019e62d65807f217a7ca8232727a Author: Hui Peng Date: Sat Sep 19 11:00:41 2026 +0000 vt: selection: Fix unsigned underflow and slab-out-of-bounds read in paste_selection() In paste_selection(), the loop copies min_t(unsigned int, vc_sel.buf_len - pasted,tty->receive_room) bytes per iteration into tty_ldisc_receive_buf() and increments pasted += count. Because the selection mutex (vc_sel.lock) is dropped inside the loop Whenever the line discipline buffer fills up and paste_selection() sleeps on tty->write_wait, a concurrent TIOCLINUX (TIOCL_SETSEL) ioctl can replace vc_sel.buffer with a shorter selection and reduce vc_sel.buf_len below pasted. When paste_selection() resumes, vc_sel.buf_len - pasted underflows as an unsigned integer to a large positive value, causing tty_ldisc_receive_buf(ld, vc_sel.buffer + pasted, NULL, count) to read up to 4094 bytes out-of-bounds past the newly allocated vc_sel.buffer. Fix this by terminating the loop when pasted >= vc_sel.buf_len. Kernel stack trace (Linux 7.3.0-rc3): ================================================================== BUG: KASAN: slab-out-of-bounds in n_tty_receive_buf_common+0xa01/0x1650 Read of size 4094 at addr ffff888101c58010 by task kworker/u17:1/65 Workqueue: events_unbound flush_to_ldisc Call Trace: dump_stack_lvl+0x70/0xa0 print_report+0x153/0x4c6 kasan_report+0xf1/0x120 kasan_check_range+0x11c/0x200 __asan_memcpy+0x29/0x70 n_tty_receive_buf_common+0xa01/0x1650 tty_ldisc_receive_buf+0x66/0x110 tty_port_default_receive_buf+0x6b/0xb0 flush_to_ldisc+0x1b4/0x410 process_one_work+0x6ff/0x1110 worker_thread+0x4a8/0xb70 kthread+0x307/0x3e0 ret_from_fork+0x3ed/0x680 ================================================================== Fixes: e8c75a30a23c ("vt: selection, push sel_lock up") Cc: stable Assisted-by: LLM Signed-off-by: Hui Peng Link: https://patch.msgid.link/20260919110041.3763078-1-benquike@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0928ed9bd7946baee911efa401088697836e3b1e Author: Zizhi Wo Date: Sat Sep 5 14:43:37 2026 +0800 vt: skip screen update for DEC alignment test on backgroup consoles [BUG] Recently, we encountered a KASAN warning as follows: BUG: KASAN: slab-out-of-bounds in fb_pad_aligned_buffer+0x11f/0x140 Read of size 1 at addr ff1100015fd9f6a4 by task tty_fbcon_oob/1239 CPU: 7 UID: 0 PID: 1239 Comm: tty_fbcon_oob Not tainted 7.3.0-rc1 #100 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 Call Trace: ... kasan_report+0xf0/0x120 fb_pad_aligned_buffer+0x11f/0x140 ccw_putcs+0x86c/0xa80 fbcon_putcs+0x338/0x410 do_update_region+0x21d/0x450 do_con_write+0x1e0e/0x4880 con_write+0x13/0x80 n_tty_write+0x374/0x1010 file_tty_write.isra.0+0x404/0x7a0 ... reproduce: 1) open /dev/tty0, set a KDFONTOP ioctl with op.op = KD_FONT_OP_SET, op.width = 8 and op.height = 16 (visible VC1) 2) open /dev/tty1, set a KDFONTOP ioctl with op.op = KD_FONT_OP_SET, op.width = 28 and op.height = 24 (invisible VC2) 3) echo 3 > /sys/devices/virtual/graphics/fbcon/rotate_all 4) write EShash8(esc hash8) to tty1 [CAUSE] All VCs render to the framebuffer. setfont only modifies the target VC's font without resizing the framebuffer backing buffer (par->rotated.buf); the buffer is only resized for the visible VC (fbcon_do_set_font -> ... -> vc_do_resize -> update_screen). This relies on the con_should_update() check performed before every update_region(). However, the ESC # 8 path (do_con_trol -> do_update_region) omits the con_should_update() check. After changing the font size of an invisible VC, do_update_region() fills using the new font size against a buffer that was never resized, causing an out-of-bounds access. [FIX] Only push the update when the console is visible and not blanked, add the con_should_update() check in the do_con_trol() like every other call site of do_update_region() (update_region(), invert_screen(), ...). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Zizhi Wo Link: https://patch.msgid.link/20260905064337.3083103-1-wozizhi@huaweicloud.com Signed-off-by: Greg Kroah-Hartman commit 226bd5603371cd9f6642cbb9e9a677f445de3530 Author: Yi Yang Date: Tue Sep 1 11:31:31 2026 +0000 vc_screen: reload vc pointer before if (ret) in vcs_write() to avoid UAF The reload of 'vc' added by commit 8fb9ea65c9d1 ("vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF") sits after the 'if (ret)' block, so the copy-failure break path exits the loop without reloading vc. If the vc was kfree()'d via vc_port_destruct during the unlocked copy_from_user() window, the post-loop 'if (written && vc) vcs_scr_updated(vc)' is reached with a stale non-NULL vc. The '&& vc' guard from commit a287620312dc ("vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write") only handles the NULL case, not this stale-non-NULL case; vcs_notifier() then reads param->vc->vc_num from freed memory: BUG: KASAN: slab-use-after-free in vcs_notifier+0x7c/0xd0 Read of size 2 at addr ffff888007149190 Call Trace: vcs_notifier+0x7c/0xd0 atomic_notifier_call_chain+0x70/0xa0 vcs_scr_updated+0x77/0xa0 vcs_write+0x71b/0x7e0 Allocated by task: vc_allocate -> con_install -> tty_open Freed by task: kfree <- vt_ioctl (VT_DISALLOCATE -> vc_port_destruct) Move the reload to immediately after console_lock(), before 'if (ret)', so every break path below passes a fresh vc to the post-loop vcs_scr_updated(). Fixes: a287620312dc ("vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write") Cc: stable@kernel.org Signed-off-by: Yi Yang Link: https://patch.msgid.link/20260901113131.2760010-1-yiyang13@huawei.com Signed-off-by: Greg Kroah-Hartman commit d9feaa93328a6f885afb8ac6374897fafc294222 Author: Paul Mbewe Date: Wed Sep 30 16:56:28 2026 +0200 serial: sc16is7xx: reduce TX refill rate with half-FIFO trigger With the TX trigger set to 8 free spaces, THRI is generated roughly once per 8 transmitted bytes. At 115200 baud 8N1, this corresponds to approximately 0.7 ms between TX refill events. Set the TX trigger to 32 free spaces via TLR[3:0]. This makes each refill larger and reduces the refill rate by about 4x. At 115200 baud 8N1, the refill cadence becomes approximately 2.8 ms. The trade-off is that the time-to-empty after THRI asserts is reduced from 56 to 32 byte times. The fresh-TXLVL refill loop fills the hardware TX FIFO strictly below whichever trigger is selected. This patch changes only the refill frequency and the associated latency trade-off. With the two TX gap fixes applied in both configurations, changing the trigger from 8 to 32 free spaces produced the following median values from repeated top snapshots under the same continuous Modbus RTU load. Each transaction used an 8-byte RX request and a 255-byte TX response, so the workload was dominated by TX traffic: trigger=8 trigger=32 SPI IRQ thread CPU 15% 5% system CPU 44% 29% idle CPU 40% 52% one-minute load 2.02 0.99 The datasets contain 547 snapshots with trigger=8 and 535 snapshots with trigger=32. Only TLR[3:0] is changed. TLR[7:4] remains zero so the RX trigger retains its FCR setting. RX trigger tuning may also be useful, but generic RX/TX trigger configuration is left for follow-up work. SC16IS7XX_TX_TRIGGER_LEVEL is used for both the programmed TLR value and the TXLVL refill-loop threshold, keeping the hardware trigger and the software refill condition synchronized. TCR/TLR access requires EFR[4] and MCR[2], which are already enabled by the TCR setup immediately preceding the TLR write. Reviewed-by: Joachim Knorr Link: https://lore.kernel.org/linux-serial/20260623112225.82386-3-paultyson.mbewe@ziehl-abegg.de/ Signed-off-by: Paul Mbewe Link: https://patch.msgid.link/20260930145628.566535-3-paultyson.mbewe@ziehl-abegg.de Signed-off-by: Greg Kroah-Hartman commit 527484911a40f6e84cf47e8bc490f7da61ab4151 Author: Paul Mbewe Date: Wed Sep 30 16:56:27 2026 +0200 serial: sc16is7xx: refill TX FIFO below trigger using fresh TXLVL sc16is7xx_handle_tx() reads TXLVL once and sizes the hardware TX FIFO write from that value. TXLVL reports free space in the hardware TX FIFO. On this SPI-backed path, hardirq/softirq activity, RT scheduling, and waiting for synchronous SPI transfers can delay the refill while the UART continues draining. The TXLVL value can therefore become stale before the hardware TX FIFO write completes. One failing ftrace with the default 8-free-space trigger showed: tx_start txlvl=9 txlvl_read_us=580 tx_pre_write sent=9 pre_write_us=16 tx_segment sent=9 seg_us=364 tx_post_write txlvl_before=9 sent=9 txlvl_after=12 pending_after=29 post_gap_us=12 post_txlvl_us=130 The driver read 9 free spaces and wrote 9 bytes to the hardware TX FIFO, but the post-write TXLVL read still reported 12 free spaces while 29 bytes remained queued in the xmit kfifo. Even allowing for the post-write read window, the hardware TX FIFO had not been filled below the 8-free-space trigger, so no new threshold crossing was expected. The captured failing samples had the same pattern: data remained queued in the xmit kfifo while post-write TXLVL remained above the hardware trigger. The hardware TX FIFO then drained empty before another refill was requested, producing an unintended gap on the wire. Fix this by re-reading TXLVL after each hardware TX FIFO write while data remains queued in the xmit kfifo. If TXLVL is still at or above the trigger, top up the hardware TX FIFO again. Stop when the xmit kfifo is empty or a TXLVL read confirms that hardware TX FIFO free space is strictly below the trigger. Stopping when TXLVL was equal to the trigger still allowed TX gaps in the tested workload. Continuing until TXLVL was strictly below the trigger eliminated the observed gaps caused by stale-TXLVL under-fill. Program the hardware TX trigger explicitly through TLR using the same constant as the refill-loop threshold. This prevents the software refill condition from diverging from the programmed hardware trigger. Tested on SC16IS752 over 1 MHz SPI on an i.MX6ULL single-core PREEMPT_RT system, transmitting RS-485 at 115200 baud 8N1 under continuous Modbus RTU load. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@kernel.org Reported-by: Tobias Gannert Link: https://lore.kernel.org/linux-serial/20260623112225.82386-3-paultyson.mbewe@ziehl-abegg.de/ Signed-off-by: Paul Mbewe Reviewed-by: David Laight Link: https://patch.msgid.link/20260930145628.566535-2-paultyson.mbewe@ziehl-abegg.de Signed-off-by: Greg Kroah-Hartman commit 8aebfde6e84dceb7d47fe8001e50b754eb45d5df Author: Simon Gassner Date: Thu Oct 1 08:05:39 2026 +0200 serial: tegra: don't clear the Tx FIFO on an Rx-only reset tegra_uart_fifo_reset() applies the Tegra30 workaround for "cannot clear the Tx FIFO while FIFO mode is enabled" unconditionally: it leaves FIFO mode, writes the requested FCR clear bits, and re-enters FIFO mode. Leaving FIFO mode empties both FIFOs, so an Rx-only reset discards queued Tx data as well. The break handler in tegra_uart_decode_rx_error() calls it with UART_FCR_CLEAR_RCVR only. On a half-duplex RS485 board whose Rx line is pulled low while the transceiver drives the bus, every transmission raises a spurious break, and all but the first character of the frame is lost. Only take the FIFO-mode path when the caller actually asked for CLEAR_XMIT. Likewise only wait for TEMT in that case: with the Tx FIFO deliberately left intact, that loop would otherwise spin for a full frame time in hard IRQ context with the port lock held. Tested on a Colibri T30 (Tegra30) with Rx DMA: - Break during transmission: the reset still fires from tegra_uart_decode_rx_error(), and the complete frame now reaches the peer. Before this change only the character in the shift register was sent. - Internal loopback with a generated break: the Rx FIFO is correctly cleared by the plain FCR write, and subsequent receive works with no frame, parity or overrun errors. Fixes: e9ea096dd225 ("serial: tegra: add serial driver") Cc: stable@kernel.org Signed-off-by: Simon Gassner Link: https://patch.msgid.link/20261001060539.32659-1-simon.gassner@noxsystems.com Signed-off-by: Greg Kroah-Hartman commit abfafa6fc3c17b7dffa5dce3acc8dba70ed656b9 Author: Paul Mbewe Date: Wed Sep 30 16:32:07 2026 +0200 serial: sc16is7xx: fix TX gap caused by kfifo circular buffer wrap-around kfifo_out_linear_ptr() returns only one contiguous linear segment of the xmit kfifo. When transmit data wraps around the end of the kfifo, only the first segment up to the buffer end is sent. The remaining data at the start of the kfifo is not sent until the next TX interrupt fires, resulting in a visible mid-frame TX gap on the wire. The resulting gap is unintended: data remains queued in the xmit kfifo, but the hardware TX FIFO drains empty before the remaining segment is sent. Such gaps can break timing-sensitive serial protocols such as Modbus RTU. Modbus RTU requires a message to be transmitted as a continuous stream. For baud rates above 19200, the Modbus Serial Line guide recommends a fixed 750 us inter-character timeout. On the tested 115200-baud system, oscilloscope measurements showed mid-frame gaps exceeding that value. Receivers using the recommended timeout may therefore discard the incomplete message. The incomplete transfer also causes unnecessary TX interrupts: instead of using all available hardware TX FIFO space in one go, the driver requires an extra interrupt to send the remaining segment after the wrap. After the tty xmit buffer was converted to a kfifo, the driver used uart_fifo_out() to copy data into a linear staging buffer, allowing a transfer to span the kfifo wrap-around boundary. Commit 133f4c00b8b2 ("serial: sc16is7xx: fix TX fifo corruption") replaced uart_fifo_out() with a single kfifo_out_linear_ptr() call to remove the shared TX/RX buffer. Since kfifo_out_linear_ptr() exposes only one contiguous segment, that change lost the wrap-around handling. Fix this by calling kfifo_out_linear_ptr() in a loop, advancing through all contiguous segments until the available hardware TX FIFO space is exhausted or the xmit kfifo is empty. This fixes the kfifo wrap-around gap independently of the stale-TXLVL refill issue. Tested on SC16IS752 over SPI driving RS-485 at 115200 baud 8N1 on an i.MX6ULL-based board. Oscilloscope measurements confirmed mid-frame breaks at the kfifo wrap-around boundary before the fix; no such breaks were observed afterward. Fixes: 133f4c00b8b2 ("serial: sc16is7xx: fix TX fifo corruption") Cc: stable@kernel.org Reported-by: Tobias Gannert Reviewed-by: Joachim Knorr Link: https://lore.kernel.org/linux-serial/20260623112225.82386-2-paultyson.mbewe@ziehl-abegg.de/ Signed-off-by: Paul Mbewe Link: https://patch.msgid.link/20260930143207.542930-1-paultyson.mbewe@ziehl-abegg.de Signed-off-by: Greg Kroah-Hartman commit 8df07fe93573e9e548d6645273e9bcb6eb74059e Author: Johan Hovold Date: Wed Sep 30 15:18:45 2026 +0200 tty: fix saved termios reset race Resetting saved termios state on device registration is needed where a minor number can be reused for an entirely different device and where the old settings may prevent the port from even being opened (e.g. when CLOCAL is not set). Not all TTY drivers guarantee that the minor number is no longer in use when registering devices however, something which can lead to a use-after-free when closing a TTY (and saving its termios) races with re-registration. Add a new TTY_DRIVER_RESET_SAVED_TERMIOS flag to request that any saved termios state is reset on registration and only set it for drivers that make sure that the minor number is no longer in use. Fixes: 93857edd9829 ("tty: reset termios state on device registration") Reported-by: Chengfeng Ye Link: https://lore.kernel.org/20260926184154.3017929-1-nicoyip.dev@gmail.com Cc: stable@kernel.org # 4.12 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260930131845.1809256-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8167c1f071426706c233e93ecfd13aba7d5c06c8 Author: Rosen Penev Date: Sun Sep 27 13:35:01 2026 -0700 tty: serial: mpc52xx_uart: move static declarations up. Avoid a compilation error so that they're not used before being declared. Fixes: 4d105880666a ("tty: serial: mpc52xx_uart: add bounds check for psc_num array index") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609260356.tJWbd1WU-lkp@intel.com/ Signed-off-by: Rosen Penev Link: https://patch.msgid.link/20260927203501.14105-1-rosenp@gmail.com Signed-off-by: Greg Kroah-Hartman commit db0949bbd06db0a75b4b1076f1e25194be7d956a Author: Fan Wu Date: Sun Sep 27 05:59:57 2026 +0000 tty: serial: max3100: shut down timer before freeing port max3100_shutdown() stops the polling timer but returns early during system suspend. If the SPI device is unbound before resume, the serial core does not call max3100_shutdown() again, so max3100_remove() frees the port while the timer remains armed. max3100_timeout() may then access the freed port and re-arm the timer. Add final timer teardown to max3100_remove() and use timer_shutdown_sync() to prevent a racing callback from re-arming it. Also free the IRQ and destroy the workqueue there before freeing the port. Keep timer_delete_sync() in max3100_shutdown() so that a subsequent open() can re-arm the timer. The workqueue is created before request_irq() and destroyed on both request_irq() failure and normal shutdown. Its presence at remove thus identifies the IRQ left registered when suspend bypasses shutdown. Free the IRQ before destroying the workqueue, in both max3100_shutdown() and max3100_remove(), and cancel the pending work in between. free_irq() waits for a running interrupt handler to finish and no new handler can start afterwards, so a racing handler cannot queue work on a workqueue that is being destroyed; the force_end_work check in max3100_dowork() only narrows that window, as a handler delayed between the check and queue_work() could still run after the teardown has cleared the workqueue pointer. Cancelling the work also keeps destroy_workqueue() from waiting on a queued work item in case remove() ever runs while the freezable workqueue is still frozen, e.g. device removal during the resume window, before workqueues are thawed. This issue was found by an in-house static analysis tool. Fixes: 7831d56b0a35 ("tty: MAX3100") Cc: stable@kernel.org # 6.2+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260927055957.561030-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 4d69e74034b208588636ecc177e0dd43a7696af3 Author: Sang-Hoon Choi Date: Wed Sep 30 02:37:31 2026 +0900 gpio: exar: initialize the ID before registering its cleanup 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 commit 1ff77cbefe5a653ea12874c213ea4bd0d72c1067 Author: Jiazi Liu Date: Tue Sep 15 19:06:37 2026 +0800 usb: dwc3: gadget: fix IRQ storm on invalid event buffer count When dwc3_check_event_buf() reads a GEVNTCOUNT value exceeding the event buffer length, commit 63ccd26cd1f6 ("usb: dwc3: gadget: check that event count does not exceed event buffer length") returns IRQ_NONE without writing back GEVNTCOUNT. Since the DWC3 interrupt is level-triggered, the uncleared IRQ source keeps the line asserted, causing a tight IRQ storm that accumulates 99,900 unhandled interrupts and triggers spurious.c:184 BUG -> kernel panic. The resulting call stack: __report_bad_irq+0xac/0xc8 note_interrupt+0x340/0x468 handle_irq_event+0xac/0xc0 handle_fasteoi_irq+0x120/0x228 gic_handle_irq+0x68/0x108 ... kernel BUG at kernel/irq/spurious.c:184 To reproduce, write a bogus value exceeding the event buffer length directly to the GEVNTCOUNT register: devmem 4 0x1004 Write the bogus count back to GEVNTCOUNT to clear the IRQ source, consistent with the stale event clearing pattern in dwc3_event_buffers_setup(), and schedule error recovery to reinitialize the controller. Fixes: 63ccd26cd1f6 ("usb: dwc3: gadget: check that event count does not exceed event buffer length") Cc: stable Suggested-by: Thinh Nguyen Signed-off-by: Jiazi Liu Link: https://patch.msgid.link/20260915110637.17658-1-jiazi.liu1984@gmail.com Acked-by: Thinh Nguyen Signed-off-by: Greg Kroah-Hartman commit a3e981f42557d7bb4cb212462de463e0b6b8875b Author: Greg Kroah-Hartman Date: Thu Oct 1 10:16:44 2026 +0200 Revert "usb: dwc3: gadget: fix IRQ storm on invalid event buffer count" This reverts commit a107edec57659c5a1a2f016311b944af58c904c9. It was incorrectly applied, and was 2 versions old. The "correct" one will be added instead afterward... Cc: stable Cc: Jiazi Liu Reported-by: Thinh Nguyen Fixes: a107edec5765 ("usb: dwc3: gadget: fix IRQ storm on invalid event buffer count") Signed-off-by: Greg Kroah-Hartman commit 6e0022b5ae3dc5b833af0fcc1578dc20a1d6bc71 Author: Bartosz Golaszewski Date: Wed Sep 23 17:14:35 2026 +0200 net: phy: aquantia: fix system interface type not updated in forced mode aqr_gen1_read_status() decodes the MDIO_PHYXS_VEND_IF_STATUS register to determine which SerDes interface the PHY is currently using on its system side and stores the result in phydev->interface. phylink relies on this value to configure the MAC. The autoneg == AUTONEG_DISABLE check is not correct: MDIO_PHYXS_VEND_IF_STATUS is set by the PHY firmware based on the negotiated link speed, not based on whether autoneg was used to reach it. When the link comes up at 1G in forced mode, the register correctly reads SGMII, but the early return prevents phydev->interface from being updated. It stays at whatever value it held before (typically 2500BASE-X from the initial autoneg run), so phylink configures the MAC for the wrong interface and the link cannot come up. Remove the autoneg guard so that the system interface type is always decoded when the link is up. Cc: stable@vger.kernel.org Fixes: 110a2432c520 ("net: phy: aquantia: add downshift support") Signed-off-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260923-qcom-sa8255p-emac-v15-1-e82f33720737@oss.qualcomm.com Signed-off-by: Paolo Abeni commit 0d6c5794fd633427f0d4ad8b51d94061295649da Author: Alexey Charkov Date: Wed Sep 30 20:10:21 2026 +0400 power: sequencing: pcie-m2: Fix leaking array from of_regulator_bulk_get_all() of_regulator_bulk_get_all() allocates the consumers array and hands it to the caller, who is expected to free it at an appropriate time. pwrseq-pcie-m2.c never did, leading to a memory leak. Add an explicit kfree() for the consumers array. Cc: stable@vger.kernel.org Fixes: 52e7b5bd62ba ("power: sequencing: Add the Power Sequencing driver for the PCIe M.2 connectors") Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260930-m2-pwrseq-kfree-v1-1-82678b02c126@flipper.net Signed-off-by: Bartosz Golaszewski commit 9ee4266827cfb67b9fbb89136ea6a8f3d7809f5c Author: Zeyu Li <13776528859@163.com> Date: Sat Sep 26 22:03:36 2026 +0800 ALSA: hda/realtek: Add ALC235 support for headset mode The ALC235 (0x10ec0235) is registered as the ALC255 codec variant in patch_alc269(), but the headset mode functions were missing a case for it, so the CTIA/OMTP jack type detection and routing never ran on this codec. As a result, a plugged-in headset is detected (jack presence works) but the microphone signal is never routed, leaving the capture stream permanently silent. Verified on an ASUS M5451GA laptop (HDA:10ec0235,10431814): with the ALC255 coef sequence applied, the headset microphone works correctly. Signed-off-by: Zeyu Li <13776528859@163.com> Link: https://patch.msgid.link/20260926140336.27896-1-13776528859@163.com Signed-off-by: Takashi Iwai commit b263ff9b0fc5c1f371d65c4eb196b31263d039ff Author: Alan Stern Date: Sun Sep 20 17:37:34 2026 -0400 USB: gadget: dummy-hcd: Fix wait for outstanding request completions The dummy-hcd driver emulates synchronize_irq() by waiting until its private callback_usage counter drops to 0 (with the private lock not held). This counter is incremented whenever a gadget driver callback occurs (which requires the private lock to be dropped), but not when a request completion handler is called. This is an oversight. Request completion is triggered by timer interrupts (emulating device IRQs in a real UDC), and the interrupt handlers are supposed to have completed when the synchronize_irq() emulation routine returns -- they aren't supposed to be in the middle of a completion callback. If this happens it can lead to a gadget driver's unbind routine running before all outstanding request completions have finished, maybe even allowing the gadget driver's module to be unloaded while a completion handler is still running. Fix the oversight by incrementing the callback_usage value across request completion callbacks. Link: https://lore.kernel.org/linux-usb/7a87e293-633c-4100-aa8d-91560ba5e5c5@rowland.harvard.edu/ Fixes: 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change") Tested-by: Minseo Kim Signed-off-by: Alan Stern Cc: stable Link: https://patch.msgid.link/f23b9e1a-f110-441a-a1d8-95f442ec09d5@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit aef5a7e207656ad6abdeeaa0bfc8ee9a1f9c02f6 Author: Marek Maslanka Date: Fri Sep 25 15:16:50 2026 +0200 usb: typec: port-mapper: Only match USB4 port if host interface is available typec_port_match() adds a component match for the USB4 port whenever a USB 3.x port that shares the _PLD with the Type-C connector has the "usb4-host-interface" property, regardless of whether a USB4 port can ever be registered for it. The component framework binds the aggregate device only once every match has found its component, so if the USB4 port never shows up, the USB 2.0 and USB 3.x ports are not linked to the connector either: the "connector" symlinks are never created and USB devices enumerated on those ports are never linked with the Type-C partner. This happens in at least two cases: 1. CONFIG_USB4 is not reachable from the Type-C core, i.e. CONFIG_USB4=n, or CONFIG_USB4=m with CONFIG_TYPEC=y as in the x86_64 gki_defconfig. usb4_usb3_port_match() is then a stub that always returns false. 2. The firmware references a USB4 host interface that is disabled. For example, on Intel Alder Lake-N (ChromeOS Nissa) the TCSS xHCI USB3 ports (SS01-SS04) reference TDM0/TDM1, whose _STA returns 0 because the SoC has no integrated Thunderbolt/USB4 and the DMA controllers are disabled in TCSS DEVEN. No PCI device is enumerated for them. Only add the USB4 component match if CONFIG_USB4 is reachable and the referenced host interface is available and has been enumerated as a device. The latter mirrors the check in usb_acpi_add_usb4_devlink(), see commit 623dae3e7084 ("usb: acpi: fix boot hang due to early incorrect 'tunneled' USB3 device links"). Fixes: 4fd7a1f0f7f2 ("usb: typec: Connect Type-C port with associated USB4 port") Cc: stable Signed-off-by: Marek Maslanka Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260925131650.3777399-1-mmaslanka@google.com Signed-off-by: Greg Kroah-Hartman commit e5052f2c5c73c1dcca42bafc0bc737af2b2af059 Author: Jie Deng Date: Mon Aug 10 10:36:26 2026 +0800 usb: cdns3: Fix NULL pointer dereference in cdns3_pci_probe The Cadence USBSS controller is a two-function PCI device. The first probed function allocates the driver data and stores it with pci_set_drvdata(), while the second function reuses it via pci_get_drvdata() when pci_is_enabled() reports that the first function has already been probed. When the second function is probed while the first one has been enabled but has not yet set its driver data, pci_get_drvdata() returns NULL, and the subsequent wrap->devfn assignment dereferences a NULL pointer and crashes the kernel. logs: Call trace: cdns3_pci_probe+0xa4/0x300 local_pci_probe+0x44/0xa8 pci_call_probe+0x54/0x158 pci_device_probe+0x84/0x100 really_probe+0x184/0x3d0 __driver_probe_device+0x80/0x178 driver_probe_device+0x44/0xe8 __driver_attach+0xec/0x1f8 bus_for_each_dev+0x7c/0xe0 driver_attach+0x28/0x38 bus_add_driver+0x110/0x238 driver_register+0x64/0x128 __pci_register_driver+0x50/0x60 cdns3_pci_driver_init+0x28/0x38 do_one_initcall+0x5c/0x280 do_initcalls+0x104/0x1d8 kernel_init_freeable+0x140/0x218 kernel_init+0x28/0x1f8 ret_from_fork+0x10/0x20 Return -EPROBE_DEFER in this case so that probing is retried after the first function has completed its probe. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable Signed-off-by: Jie Deng Acked-by: Peter Chen Link: https://patch.msgid.link/20260810023626.70669-1-dengjie03@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit a107edec57659c5a1a2f016311b944af58c904c9 Author: Jiazi Liu Date: Mon Sep 7 15:37:56 2026 +0800 usb: dwc3: gadget: fix IRQ storm on invalid event buffer count When dwc3_check_event_buf() reads a GEVNTCOUNT value exceeding the event buffer length, commit 63ccd26cd1f6 ("usb: dwc3: gadget: check that event count does not exceed event buffer length") returns IRQ_NONE without writing back GEVNTCOUNT. Since the DWC3 interrupt is level-triggered, the uncleared IRQ source keeps the line asserted, causing a tight IRQ storm that accumulates 99,900 unhandled interrupts and triggers spurious.c:184 BUG -> kernel panic. The resulting call stack: __report_bad_irq+0xac/0xc8 note_interrupt+0x340/0x468 handle_irq_event+0xac/0xc0 handle_fasteoi_irq+0x120/0x228 gic_handle_irq+0x68/0x108 ... kernel BUG at kernel/irq/spurious.c:184 To reproduce, write a bogus value exceeding the event buffer length directly to the GEVNTCOUNT register: devmem 4 0x1004 Write the bogus count back to GEVNTCOUNT to clear the IRQ source, consistent with the stale event clearing pattern in dwc3_event_buffers_setup(), and schedule error recovery to reinitialize the controller. Fixes: 63ccd26cd1f6 ("usb: dwc3: gadget: check that event count does not exceed event buffer length") Cc: stable Co-developed-by: Thinh Nguyen Signed-off-by: Thinh Nguyen Signed-off-by: Jiazi Liu Suggested-by: Thinh Nguyen Link: https://patch.msgid.link/20260907073756.22329-1-jiazi.liu1984@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6c51f09c6db5868a5090e8dd4d7764660c87f1ad Author: Prashanth K Date: Wed Sep 16 09:58:08 2026 +0530 usb: typec: ucsi: Get the connector fwnode based on reg value ucsi_find_fwnode() currently maps UCSI connectors to Device tree connector nodes based on the order in which connector child nodes are described in DT. This can fail because the ordering of child nodes isn't guaranteed in Device-tree. For example, DTB may contain connector@1 before connector@0, causing connector numbers to be associated with the wrong fwnode. As a result, role switch and Type-C notifications can be delivered to the wrong remote endpoints. Fix this by using the "reg" property of each connector to match its corresponding fwnode. While at it, if the reg property isn't present, then fall back to the old method. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: stable Signed-off-by: Prashanth K Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260916042808.2879079-1-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 9062d50e75c24dc7911be05c9b1719b3b256af15 Author: Liu Chao Date: Mon Sep 21 15:25:51 2026 +0800 usb: gadget: f_uac1_legacy: validate bRequest index in generic_{set,get}_cmd generic_set_cmd() and generic_get_cmd() use the low nibble of ctrl->bRequest as an index into con->data[]: u8 cmd = (ctrl->bRequest & 0x0F); /* 0 .. 15 */ ... con->data[cmd] = value; /* OOB when cmd >= 5 */ struct usb_audio_control (include/linux/usb/audio.h) declares data as a 5-element array, so indices 5 through 15 write (or read) up to 44 bytes past the end of the array on the heap. A malicious USB host can craft a class-specific SET_CUR / GET_CUR request with an arbitrary bRequest value, triggering the out-of-bounds access from an IRQ completion handler with no further preconditions. Add an ARRAY_SIZE() guard to both functions. Fixes: c47d7b09891a ("USB: audio: add USB audio class definitions") Cc: stable Reviewed-by: Weibin Liu Signed-off-by: Liu Chao Reviewed-by: Ivy Lopez Link: https://patch.msgid.link/20260921072551.3708191-1-liuc63@xiaopeng.com Signed-off-by: Greg Kroah-Hartman commit 0e8baa78d872f2db440d8b9ded946ab8dceb89eb Author: Hui Peng Date: Sun Sep 20 23:17:02 2026 +0000 usb: core: clear both ep_in and ep_out for non-ep0 control endpoints In usb_enable_endpoint(), non-zero control endpoints (where usb_endpoint_xfer_control(&ep->desc) is true) populate both dev->ep_in[epnum] and dev->ep_out[epnum] with the same struct usb_host_endpoint pointer. However, usb_disable_endpoint() only clears either dev->ep_out[epnum] or dev->ep_in[epnum] depending on the direction bit of epaddr when reset_hardware is set, leaving the opposite direction's array slot pointing to the disabled/freed endpoint. Clear both dev->ep_out[epnum] and dev->ep_in[epnum] when disabling a non-ep0 control endpoint with reset_hardware set, and update the function kerneldoc accordingly. Tested in QEMU against Linux 7.3.0-rc3 using dummy_hcd and raw-gadget to enumerate a USB device with a non-zero control endpoint (bEndpointAddress 0x01, bmAttributes USB_ENDPOINT_XFER_CONTROL), verifying that both dev->ep_in[1] and dev->ep_out[1] are cleared when the interface is disabled. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Assisted-by: LLM Signed-off-by: Hui Peng Acked-by: Alan Stern Link: https://patch.msgid.link/20260920231702.110963-1-benquike@gmail.com Signed-off-by: Greg Kroah-Hartman commit dc614d6bc991740d41d5a99ac7765c4b675dda88 Author: Yuchao Zhang Date: Fri Sep 18 19:43:09 2026 +0800 USB: cdc-acm: skip URB restart in port_shutdown if disconnected acm_port_shutdown() is called from the tty-port machinery whenever the last user closes the port. acm_disconnect() sets acm->disconnected and calls tty_port_tty_vhangup(), which eventually triggers port_shutdown(). At that point acm_disconnect() has already called acm_poison_urbs() and is about to free the control and read URBs. However, acm_port_shutdown() unconditionally calls acm_unpoison_urbs() and, when the ALWAYS_POLL_CTRL quirk is set, immediately re-submits the ctrlurb and all read URBs. If the concurrent acm_disconnect() then frees those URBs and their DMA buffers while they are in-flight, the result is a use-after-free in acm_ctrl_irq() or acm_read_bulk_callback() accessing the freed DMA memory. Fix by checking acm->disconnected after draining the delayed anchor and returning early: if we are in a disconnect path the URBs must remain poisoned and must not be resubmitted. The early return is placed after the delayed-anchor drain loop because that loop only cancels write-side accounting (wb->use = false and autopm counter) and does not touch the hardware path. Fixes: f58752ebcb35 ("USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10 INGENIC touchscreen") Cc: stable Signed-off-by: Yuchao Zhang Link: https://patch.msgid.link/20260918114309.3659635-2-ndaugoing@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9cd072788c76595529eb38f42bf94d23852f8534 Author: Yuchao Zhang Date: Fri Sep 18 08:54:38 2026 +0800 usb: gadget: f_fs: Fix NULL pointer dereference in FUNCTIONFS_ENDPOINT_DESC When user space sets up FunctionFS with only full-speed descriptors (e.g., flags = FUNCTIONFS_HAS_FS_DESC) and the gadget operates at a higher speed (such as USB_SPEED_HIGH or USB_SPEED_SUPER), config_ep_by_speed() detects that the function lacks descriptors for the current speed, logs a warning, and falls back to full-speed descriptors. The endpoint is then successfully enabled via usb_ep_enable(), and epfile->ep becomes valid. However, when user space subsequently issues the FUNCTIONFS_ENDPOINT_DESC ioctl to query the endpoint descriptor, ffs_epfile_ioctl() selects the descriptor index solely based on gadget->speed: switch (epfile->ffs->gadget->speed) { case USB_SPEED_SUPER: case USB_SPEED_SUPER_PLUS: desc_idx = 2; break; case USB_SPEED_HIGH: desc_idx = 1; break; default: desc_idx = 0; } desc = epfile->ep->descs[desc_idx]; memcpy(&desc1, desc, desc->bLength); Because user space only supplied full-speed descriptors, epfile->ep->descs[1] is NULL. Dereferencing desc->bLength triggers an immediate kernel NULL pointer dereference panic. Fix this by falling back through lower speed descriptors if the current speed descriptor was not supplied, matching the fallback logic in config_ep_by_speed() and historical f_fs behavior. If still missing, fall back to epfile->ep->ep->desc (the active descriptor), and return -EINVAL safely if no valid descriptor is found. In addition, mark desc as const to match struct usb_ep::desc and avoid discarding qualifiers. Fixes: c559a3534109 ("usb: gadget: f_fs: add ioctl returning ep descriptor") Cc: stable@kernel.org Signed-off-by: Yuchao Zhang Acked-by: Michał Nazarewicz Link: https://patch.msgid.link/20260918005438.81263-2-ndaugoing@gmail.com Signed-off-by: Greg Kroah-Hartman commit 20388c8d1d74c203fec8194c45cd31afdfab934e Author: Fan Wu Date: Tue Sep 8 04:17:39 2026 +0000 usb: gadget: aspeed-vhub: cancel wake work on device removal wake_work is armed from the gadget .wakeup callback to resume suspended downstream ports, and it is never cancelled in ast_vhub_remove(), so a work item queued before or during removal can run after devm has freed vhub and its ports, a use-after-free. Cancelling the work alone is not sufficient: usb_gadget_wakeup() takes no lock and the unbind path never clears wakeup_en, so a remote-wakeup request in flight on another CPU can re-arm the work after the cancel and before vhub is freed. ast_vhub_del_dev() already clears d->registered under vhub->lock before unregistering the gadget. Refuse the wakeup in ast_vhub_udc_wakeup() once d->registered is clear: the check and the schedule_work() are then atomic against the unbind, so a wakeup that passed before the flag was cleared is drained by the cancel_work_sync() after the del_dev loop, and one that arrives later returns without arming. Also move INIT_WORK() to the top of ast_vhub_probe(), since the probe error path reuses ast_vhub_remove() and would otherwise cancel a never-initialized work item. This issue was found by an in-house static analysis tool. Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Benjamin Herrenschmidt Link: https://patch.msgid.link/20260908041740.613713-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 19465a9aeb664f1d710d0d22c07c31bfb7c85446 Author: Frank Sorenson Date: Wed Sep 30 15:47:15 2026 -0500 smb: client: split cifsFileInfo bitfields to avoid shared-byte RMW races The invalidHandle, swapfile, oplock_break_cancelled, offload, and status_file_deleted fields are stored in the same bitfield byte in struct cifsFileInfo, but are updated in different code paths that may run simultaneously, and are protected by different locks. Since bitfield assignments generate byte-level read-modify-write operations, a modification to one flag can overwrite a concurrent modification to another flag. To avoid these races, convert these flags from a bitfield to separate bool fields. Closes: https://lore.kernel.org/r/7689764e-c0f6-4016-9557-b54cf4a3de4e@redhat.com Fixes: 3bc303c254335 ("cifs: convert oplock breaks to use slow_work facility (try #4)") Fixes: 4e8aea30f7751 ("smb3: enable swap on SMB3 mounts") Fixes: ffceb7640cbfe ("smb: client: do not defer close open handles to deleted files") Fixes: 173217bd73365 ("smb3: retrying on failed server close") Signed-off-by: Frank Sorenson Cc: stable@vger.kernel.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 5cd9813d848d6565f0ca7825a8405c4e48441cf9 Merge: 551c722f408096 aa650d87a49884 Author: Linus Torvalds Date: Wed Sep 30 19:08:10 2026 -0700 Merge tag 'audit-pr-20260930' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit Pull audit fix from Paul Moore: "A single audit fix for a potential UAF error in some audit filter configurations" * tag 'audit-pr-20260930' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit: audit: fix exe mark UAF in kill_rules() commit 7375d38364a9aa66fb31716bcefef38aecad75d8 Author: Reinhard Speyerer Date: Fri Sep 25 15:14:32 2026 +0200 net: usb: qmi_wwan: add Rolling Wireless RN947R Add Rolling Wireless RN947R 0x9300 composition: DIAG + ADB + NMEA + MODEM + RMNET + QDSS + ADPL T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=9300 Rev= 0.00 S: Manufacturer=Rolling Wireless S: Product=RN947R S: SerialNumber=xxxxxxxxxxx C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#=21 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#=22 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Reinhard Speyerer Link: https://patch.msgid.link/arZzuOOvLUZtdOlv@arcor.de Signed-off-by: Jakub Kicinski commit 4d0e2704118511e37790641d591454354e7c0d6c Author: Dave Airlie Date: Wed Sep 30 17:36:15 2026 +1000 nouveau: check gsp->rm as well as gsp pointer before gcx ready In turing systems where gsp exists, but can end up not being used, we need to add a second check. Fixes: cb4c7603678c ("drm/nouveau/gsp/r570: Add support for INTERNAL_GCX_ENTRY_PREREQUISITE") Reported-by: Woody Suwalski Tested-by: Woody Suwalski Reviewed-by: Lyude Paul Signed-off-by: Dave Airlie Link: https://lore.kernel.org/nouveau/20260930212151.3926202-1-airlied@gmail.com/T/#u commit 8f1c2a10500a84a621ff13073f96deea0753ed42 Author: Lorenzo Bianconi Date: Tue Sep 29 15:43:03 2026 +0200 net: mvneta: clear XDP pfmemalloc flag between frames mvneta_swbm_add_rx_fragment() sets XDP_FLAGS_FRAGS_PF_MEMALLOC on the xdp_buff when a fragment page is a pfmemalloc one (page under memory pressure). The xdp_buff is reused for the next frame, but only the XDP_FLAGS_HAS_FRAGS bit was cleared at frame start, so the pfmemalloc bit leaked from one frame into the following ones. mvneta_swbm_build_skb() propagates the flag to skb->pfmemalloc through xdp_update_skb_frags_info(), so the skb of a subsequent fragmented frame could be wrongly marked as pfmemalloc even if none of its pages are under pressure. Clear all the xdp_buff flags in mvneta_swbm_rx_frame(), which is invoked for each new frame, instead of just the XDP_FLAGS_HAS_FRAGS bit. Fixes: ed7a58cb40bd ("net: marvell: rely on xdp_update_skb_shared_info utility routine") Reviewed-by: Simon Horman Signed-off-by: Lorenzo Bianconi Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260929-mvneta-xdp-clear-frag-fix-v4-1-1e63b25eeed8@oss.qualcomm.com Signed-off-by: Jakub Kicinski commit 8ec454dcd00ce3375119111c6394964455b36d0d Author: Eric Dumazet Date: Mon Sep 28 19:45:24 2026 +0000 ipv6: sr: use skb_get_hash_net() in seg6_make_flowlabel() Since commit d58e468b1112 ("flow_dissector: implements flow dissector BPF hook") __skb_flow_dissect() needs a net pointer, either from skb->dev, skb->sk, or since commit 3cbf4ffba5ee ("net: plumb network namespace into __skb_flow_dissect") a caller provided pointer. syzbot was able to reach seg6_make_flowlabel() with an skb having neither skb->dev nor skb->sk set: a TIPC UDP bearer sends a discovery message through an IPv4 route using seg6 encap, while net.ipv6.seg6_flowlabel is set to 1. seg6_make_flowlabel() already has a net pointer, use skb_get_hash_net(). WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0x910/0x5368 net/core/flow_dissector.c:1126, CPU#0: syz.0.17/4930 Call trace: __skb_flow_dissect+0x910/0x5368 net/core/flow_dissector.c:1126 (P) __skb_get_hash_net+0xe0/0x29c net/core/flow_dissector.c:1903 skb_get_hash include/linux/skbuff.h:1663 [inline] seg6_make_flowlabel+0xcc/0x1ec net/ipv6/seg6_iptunnel.c:132 __seg6_do_srh_encap+0x320/0xbf4 net/ipv6/seg6_iptunnel.c:161 seg6_do_srh+0x4b4/0xa44 net/ipv6/seg6_iptunnel.c:431 seg6_output_core+0x164/0x688 net/ipv6/seg6_iptunnel.c:681 seg6_output+0x44/0x1ac net/ipv6/seg6_iptunnel.c:744 lwtunnel_output+0x3d0/0x664 net/core/lwtunnel.c:356 dst_output include/net/dst.h:470 [inline] ip_local_out+0x110/0x148 net/ipv4/ip_output.c:131 iptunnel_xmit+0x50c/0xd38 net/ipv4/ip_tunnel_core.c:97 udp_tunnel_xmit_skb+0x220/0x348 net/ipv4/udp_tunnel_core.c:187 tipc_udp_xmit+0x75c/0x9c0 net/tipc/udp_media.c:202 tipc_udp_send_msg+0x214/0x374 net/tipc/udp_media.c:274 tipc_bearer_xmit_skb+0x260/0x3b0 net/tipc/bearer.c:576 tipc_enable_bearer net/tipc/bearer.c:366 [inline] __tipc_nl_bearer_enable+0xc90/0xfb0 net/tipc/bearer.c:1048 tipc_nl_bearer_enable+0x2c/0x48 net/tipc/bearer.c:1057 genl_family_rcv_msg_doit+0x1e4/0x2d4 net/netlink/genetlink.c:1114 Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook") Reported-by: syzbot+9408fbe0e6452a12e9ab@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6abac2eb.3654fce1.1bec97.0000.GAE@google.com/ Signed-off-by: Eric Dumazet Reviewed-by: Xuanqiang Luo Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260928194524.3617299-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski commit 7b97273cbebe9dd4fddc457f0c4f2a124d0e3996 Author: Prathamesh Deshpande Date: Sat Sep 26 17:53:57 2026 +0100 net/mlx5e: Fix AF_XDP TX timestamp teardown NULL dereference During XSK TX queue teardown, outstanding descriptors are completed without a CQE. If one requested a TX timestamp, the completion path passes that NULL CQE to mlx5e_xsk_fill_timestamp(), which dereferences it. Return zero when no CQE is available, indicating that teardown did not produce a TX timestamp. Fixes: ec706a860eba ("net/mlx5e: Implement AF_XDP TX timestamp and checksum offload") Signed-off-by: Prathamesh Deshpande Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260926165402.5902-1-prathameshdeshpande7@gmail.com Signed-off-by: Jakub Kicinski commit 3cdeaef1754ab8155cdd828c958ada3d36e9ad9a Author: Oleksij Rempel Date: Fri Sep 25 09:10:40 2026 +0200 r8169: disable EEE on RTL8168h/8111h Force EEE off on the RTL8168h/8111h (RTL_GIGA_MAC_VER_46) at PHY connect with phy_disable_eee(). Commit 202fef9bbbf5 ("net: phy: realtek: fix EEE advertisement write on the internal PHY MMD path") made EEE actually advertise on the generic Realtek PHY; the write had been a no-op before. On the RTL8168h that un-masks a latent defect: once EEE negotiates, RX silently stalls after ~7-20 minutes. The carrier stays up, no counter or dmesg moves, and only "ip link set down/up" recovers it; disabling EEE keeps the link stable. Root-causing the RTL8168h LPI/RX path needs hardware not available now, so disable EEE for this version. Use phy_disable_eee() rather than dropping the version from rtl_supports_eee(): the latter also skips rtl_enable_tx_lpi(), whose disable branch clears the MAC TX-LPI bits (ERI 0x1b0[1:0]) on link up. rtl_hw_start_8168h_1() does not clear them (the RTL8402/RTL8106e init does), so a warm reboot from an EEE-active state could otherwise leave TX-LPI asserted while the PHY no longer negotiates EEE. Keeping the version EEE-capable preserves that clear path. This also covers the RTL8168M, which shares RTL_GIGA_MAC_VER_46. Reported-by: Dennis Piecha Closes: https://lore.kernel.org/all/353419280.954808.1790290283530@mail.yahoo.com/ Fixes: 202fef9bbbf5 ("net: phy: realtek: fix EEE advertisement write on the internal PHY MMD path") Cc: stable@vger.kernel.org Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20260925071040.2137178-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski commit 9e792901418d814295674d1f53d6b615fb5c15c8 Author: Jari Seppälä Date: Mon Sep 28 11:47:11 2026 +0300 octeontx2-pf: Fix RSS indirection table size The conversion to the dedicated RSS context operations replaced the pointer to struct otx2_rss_ctx with an inline u32 ind_tbl[] array. However, otx2_rss_init() still uses sizeof(*rss->ind_tbl) to set rss_size. This now yields the size of one u32 (4), rather than the 256 entries in the indirection table. The RSS initialization and hardware programming loops use rss_size, so only four entries are initialized and programmed despite the NIX LF being allocated a 256-entry table. On an OCTEON CN102 with eight RX queues, the table contained 0, 1, 2, 3 followed by zeros. Traffic was concentrated on queue 0 and ethtool -X equal 8 did not correct the table. Use ARRAY_SIZE() to count the indirection table entries. On the same hardware, this restores the full table repeating queue numbers 0 through 7, and bidirectional multi-flow traffic increments multiple RX queues. Runtime testing on an Asterfusion ET2500 (OCTEON CN102 A0). Fixes: 62e01d8c4170 ("eth: otx2: migrate to the *_rxfh_context ops") Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/netdev/361df563-e29e-43bf-8806-24bdfefed33d@nocloud.org/ Signed-off-by: Jari Seppälä Reviewed-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260928084711.2462571-1-jase@nocloud.org Signed-off-by: Jakub Kicinski commit 4f1da630d13de0370e2f6361f961f1c8b384af1c Author: Jun Yang Date: Sat Sep 26 17:55:15 2026 +0800 sctp: check RCV_SHUTDOWN after the sendmsg connect wait sctp_wait_for_connect() drops the socket lock while it sleeps. An out-of-the-blue ABORT can then be processed from the socket backlog and unlink the association. If a concurrent shutdown(fd, SHUT_RD) sets RCV_SHUTDOWN, the waiter breaks with err == 0 before checking asoc->base.dead. Its final sctp_association_put() can then free the association, leaving sctp_sendmsg_to_asoc() to continue with a dangling pointer. Check RCV_SHUTDOWN along with the wait error in sctp_sendmsg_to_asoc() before using the association again. The check only accesses the socket, so it needs no additional association reference. Return the existing -ESRCH so that sctp_sendmsg() skips freeing a new association that may already have been destroyed. Keep sctp_wait_for_connect() unchanged to preserve its behavior for the connect() caller. Fixes: 668c9beb9020 ("sctp: implement assign_number for sctp_stream_interleave") Cc: stable@vger.kernel.org Reported-by: TencentOS Corvus AI Signed-off-by: Jun Yang Acked-by: Xin Long Link: https://patch.msgid.link/20260926095606.68601-1-juny24602@gmail.com Signed-off-by: Jakub Kicinski commit 5642b1648d5c4561d8ed7a410d0a7017f706604d Author: Quentin Freimanis Date: Sun Sep 27 21:50:12 2026 -0700 net: sparx5: make ports inherit the switch base mac address type When the switch uses a random base MAC address it does not mark each port's address as random: $ dmesg | grep "MAC addr" sparx5-switch e00c0000.switch: MAC addr was not set, use random MAC $ cat /sys/class/net/eth0/addr_assign_type 0 0 is NET_ADDR_PERM, so userspace thinks this is a stable address. With a random MAC reported as NET_ADDR_PERM, systemd's MACAddressPolicy=persistent [1] leaves it unchanged, so a DHCP client gets a new IP address every boot and a static reservation can't be used. Reporting it as NET_ADDR_RANDOM makes systemd replace it with a stable address derived from the interface name and machine-id. Fixes: f3cad2611a77 ("net: sparx5: add hostmode with phylink support") Signed-off-by: Quentin Freimanis Reviewed-by: Simon Horman Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20260928045012.30178-1-quentin@q-lab.dev Signed-off-by: Jakub Kicinski commit 30724547b221e0e670ddfef140fc7d816b2aaec6 Author: Wentao Liang Date: Thu Sep 17 12:42:47 2026 +0000 of/irq: Fix remaining refcount leaks in of_irq_init() Successfully initialized controllers are moved to intc_parent_list, but the final cleanup only frees the descriptors. The device node references taken with of_node_get() and the interrupt parent references are therefore leaked on the normal return path. Drop both before kfree(), as the intc_desc_list cleanup already does. Fixes: 8363ccb917c6 ("of/irq: add missing of_node_put") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917124247.2151674-1-vulab@iscas.ac.cn Signed-off-by: Rob Herring (Arm) commit be35a3e003941fc25b4e72d8d4fd44f8a98ac1af Merge: 99b43ede9e355b 6f63e919fe1e33 Author: Jakub Kicinski Date: Wed Sep 30 14:05:59 2026 -0700 Merge tag 'wireless-2026-09-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Still more fixes coming in, notably: - ath11k: avoid running out of stations on HW restart - mac80211: - drop too large fragmented MPDUs - mesh path handling fixes - validation improvements - reject CSA with bad 320 MHz bandwidth - cfg80211: fix RTS for single radio devices * tag 'wireless-2026-09-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (27 commits) wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue() wifi: mac80211: reject invalid 320 MHz CSA bandwidth wifi: mac80211: set info->band for 802.3 encap offload frames wifi: mac80211: prevent AP VLAN tx from other interfaces wifi: cfg80211: preserve hidden-group beacon IE ownership wifi: mac80211: keep fallback association elements alive wifi: mac80211: shut down RX BA session timer on teardown wifi: mac80211: validate TX status rate metadata wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE wifi: ath9k: reject short WMI command responses wifi: ath9k: Clean up device initialisation guards wifi: ath11k: reset ar->num_stations on hardware start wifi: cfg80211: fix RTS threshold setting for single-radio PHY wifi: mac80211: handle empty FILS association request payload wifi: mac80211: minstrel_ht: validate fixed rate index wifi: p54: validate firmware record lengths wifi: mac80211: fix mesh fast xmit path deletion UAF wifi: mac80211: drop oversized fragments to avoid extra_len overflow wifi: wlcore: Fix runtime PM leak in wlcore_remove() wifi: mac80211: drain PS delivery work during station teardown ... ==================== Link: https://patch.msgid.link/20260930124440.224799-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski commit 77f21a59e8cf7efcc1c4b3e9176e8b99993a7ae4 Author: Yuho Choi Date: Wed Sep 23 21:13:50 2026 -0400 of: Put coreboot node after compatibility check of_find_compatible_node() returns a referenced device node, but EXCLUDED_DEFAULT_CELLS_PLATFORMS used the result only as a boolean and discarded the reference. This leaked a reference each time the address-cells or size-cells warning condition was evaluated on a coreboot system. Use a helper that checks for the coreboot node with a scoped reference, so the reference is dropped once the check is done. Fixes: 8600058ba28a7 ("of: Add coreboot firmware to excluded default cells list") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260924011358.734722-1-oss.patchbox@gmail.com Signed-off-by: Rob Herring (Arm) commit 707ce102521496c67860d81221b20c56d8255f2f Author: Oleg Keri Date: Fri Sep 25 15:25:58 2026 +0200 drm/dp: don't mark the AUX backlight enabled when enabling failed 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 commit 28b7260548af3d35773477993ad4e4de41578dd7 Author: Stephen Smalley Date: Mon Sep 28 10:19:17 2026 -0400 selinux: preserve NATIVE_LABELS on already-initialized sb in set_mnt_opts 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 commit 9ee8306121495d2a25aa5d1bfd519f2748786b83 Author: Fan Wu Date: Wed Sep 23 09:48:07 2026 +0000 iio: adc: ad_sigma_delta: fix use-after-free on unbind ad_sd_buffer_postenable() allocates sigma_delta->samples_buf with devm_krealloc() at runtime, so its devres entry sits after all probe-time entries of the driver. devm resources are released in reverse allocation order, which means unbind frees samples_buf before iio_device_unregister() disables the buffers and detaches the trigger pollfunc. The data ready IRQ is still enabled at that point, so ad_sd_trigger_handler() can still run and memcpy() incoming samples into the freed samples_buf. Fix this by preallocating the buffer in devm_ad_sd_setup_buffer_and_trigger(), before the triggered buffer and the IRQ are set up, so it is freed only after iio_device_unregister() has drained the trigger handler via free_irq(). Size it for the worst case of all sequencer slots being active; ad_sd_validate_scan_mask() already caps the number of active channels at num_slots. This issue was found by an in-house static analysis tool. Fixes: 8bea9af887de ("iio: adc: ad_sigma_delta: Add sequencer support") Cc: stable@vger.kernel.org Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Nuno Sá Signed-off-by: Jonathan Cameron commit dd30c10ff60d2b30386c23bb7c61cc97f2385c97 Author: Jiale Yao Date: Fri Sep 25 22:09:43 2026 +0800 iio: accel: kxcjk-1013: reject duplicate event disable The IIO core does not filter duplicate writes to the event enable attribute. kxcjk1013_write_event_config() already ignores repeated enable requests, but a repeated disable request still calls kxcjk1013_set_power_state(data, false), dropping a runtime PM reference that was not acquired for this request. This can underflow the runtime PM usage count and trigger a "Runtime PM usage count underflow" warning. Return early when the requested state already matches ev_enable_state. Fixes: b4b491c0832e ("iio: accel: kxcjk-1013: Support thresholds") Signed-off-by: Jiale Yao Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit 84bb0fc46ccf6a545b8fdf57cda83770186ed8dd Author: Jinseob Kim Date: Mon Sep 21 15:24:21 2026 +0900 iio: buffer: serialize buffer teardown with mode claims Buffer-mode claims hold mlock to guarantee that the device remains in buffer mode until the claim is released. Normal buffer updates take info_exist_lock followed by mlock in iio_update_buffers(). However, iio_device_unregister() disables and deactivates all buffers without taking mlock. This can invalidate buffer state, including active_scan_mask, while a buffer-mode claim is held. Take mlock in iio_disable_all_buffers() so that unregister honors the mode-claim lifetime guarantee. The info_exist_lock -> mlock ordering matches iio_update_buffers(). Fixes: 0a8565425afd ("iio: core: introduce iio_device_{claim|release}_buffer_mode() APIs") Suggested-by: Jonathan Cameron Signed-off-by: Jinseob Kim Reviewed-by: Joshua Crofts Reviewed-by: Nuno Sá Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit 52da294027f53e7084c18dd4b4f73354a40382f3 Author: Pengpeng Hou Date: Sun Sep 20 11:33:03 2026 +0800 iio: cdc: ad7150: fix OF matching and publish module aliases The OF match entries use positional initializers, which initialize the name field rather than compatible. Consequently the advertised AD7150, AD7151 and AD7156 compatible strings do not describe OF compatible matches. The table is also not exported for module alias generation. Use designated compatible initializers and publish the OF table. Keep the existing I2C ID table and its device-variant selection unchanged. The issue was found by our static-analysis tool. Fixes: 89f2d5b080bc ("staging:iio:cdc:ad7150: Add of_match_table") Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Jonathan Cameron commit 49ee1c6a3ebda6b7de06b2961b0e09c1c3fe536a Author: Linmao Li Date: Wed Aug 26 16:31:56 2026 +0800 iio: adc: ade9000: fix NULL pointer dereference in clkout registration ade9000_setup_clkout() passes NULL as the register address when registering a divider clock. During clock registration, the common clock framework calls clk_divider_recalc_rate(), which dereferences the address through readl(). As a result, probing an ADE9000 configured as a clock provider with an external input clock crashes. CLKOUT passes CLKIN through without changing its rate. Register it as a 1:1 fixed-factor clock, which does not require register access. This change does not affect the configuration using the internal clock, for which the driver does not register a clock provider. Fixes: 81de7b4619fc ("iio: adc: add ade9000 support") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li Reviewed-by: Antoniu Miclaus Signed-off-by: Jonathan Cameron commit d615210564205993e8f0e7ccb57cc2e66b7d5706 Author: Salah Triki Date: Thu Sep 3 12:43:09 2026 +0100 iio: adc: ad4030: fix invalid oversampling_ratio validation In ad4030_set_avg_frame_len(), the logarithm is calculated before input validation. Passing zero or negative values leads to an undefined result from ilog2(). Validate that the input is strictly positive prior to computing its logarithm. Fixes: 949abd1ca5a4 ("iio: adc: ad4030: add averaging support") Assisted-by: LLM Signed-off-by: Salah Triki Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit 9ec6ecc95dda6d91fa6f671cd972dd4bfc05ba38 Author: Marcelo Schmitt Date: Wed Sep 16 14:01:34 2026 -0300 iio: adc: ad7173: Fix digital filter configuration Filter enable and filter type selection masks were swapped on data preparation for filter configuration register write. Use the correct masks to set each property of post filter configuration. Fixes: ff06b39be1a1 ("iio: adc: ad7173: support changing filter type") Signed-off-by: Marcelo Schmitt Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit c5de6a6f855fdcf1e0ea549fb227a316db51c405 Author: Fabrice Gasnier Date: Wed Sep 16 19:15:04 2026 +0200 iio: adc: stm32-adc: fix possible division by zero in processed channel In case the conversion has failed or returned zero, processing *val can lead to a division by zero. Need to check for errors, or converted value is zero, before processing the data. In case the converted value is zero, e.g. the Vrefint channel, this should be considered as invalid in all cases. Fixes: 0e346b2cfa85 ("iio: adc: stm32-adc: add vrefint calibration support") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260911161555.244F31F000FF@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Fabrice Gasnier Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron commit 9db3deeb2de485a9d412f0825f9ab4c8e2bccf44 Author: Fabrice Gasnier Date: Wed Sep 16 19:18:38 2026 +0200 iio: adc: stm32-adc: fix check on internal channel availability If an unsupported internal channel like vddgpu is requested, the driver prints a warning but falls through and assigns it a valid int_ch below. This causes a problem later during setup: stm32_adc_int_ch_enable() { ... case STM32_ADC_INT_CH_VDDGPU: stm32_adc_set_bits(adc, adc->cfg->regs->or_vddgpu.reg, adc->cfg->regs->or_vddgpu.mask); ... } Because the register offset is uninitialized (0), this performs a read-modify-write on offset 0, which corresponds to the ISR register. Fix this by returning before a valid int_ch is assigned. Choice is made to keep current driver behavior to warn about the channel name. Fixes: cf0fb80ae167 ("iio: adc: stm32-adc: add stm32mp13 support") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260911162602.D323F1F000FF@smtp.kernel.org/ Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko Signed-off-by: Fabrice Gasnier Signed-off-by: Jonathan Cameron commit e8dd273d199f5bbe295a8e3d8b777c5505b6b2e1 Author: Salah Triki Date: Thu Sep 17 14:00:52 2026 +0100 iio: proximity: isl29501: Fix return type of isl29501_register_write isl29501_register_write() was returning a u32 instead of an int. Since the function returns negative error codes (such as -ERANGE or return values from i2c_smbus_write_byte_data()), returning an unsigned integer type prevents callers from correctly checking for negative error conditions. Fix this by changing the function return type from u32 to int. This was found through manual code review. Fixes: 1c28799257bc ("iio: light: isl29501: Add support for the ISL29501 ToF sensor.") Signed-off-by: Salah Triki Reviewed-by: Joshua Crofts Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit 87775fff21b14cd37604530b1783f0a9db8f95a7 Author: Linmao Li Date: Mon Aug 24 11:55:31 2026 +0800 iio: imu: inv_icm42607: restore runtime PM on system resume errors pm_runtime_force_suspend() leaves runtime PM disabled after it succeeds and expects pm_runtime_force_resume() to restore runtime PM management during system resume. The resume callback returns early if enabling the vddio regulator or synchronizing the register cache fails, skipping the matching pm_runtime_force_resume() call. Runtime PM consequently remains disabled after the system has resumed, so runtime autosuspend can no longer turn off sensors enabled afterward. Call pm_runtime_force_resume() on both error paths. Keep the first error as the return value and report a runtime PM restore failure separately. Fixes: 3007c1530f96 ("iio: imu: inv_icm42607: Add PM support for icm42607") Signed-off-by: Linmao Li Tested-by: Kanak Shilledar Tested-by: Chris Morgan Signed-off-by: Jonathan Cameron commit c1774272c76e92fc3df10a8fedfc033716e55d1b Author: Linmao Li Date: Mon Aug 24 11:55:30 2026 +0800 iio: imu: inv_icm42607: propagate runtime suspend errors The runtime suspend callback returns success when updating PWR_MGMT0 fails. The PM core then marks the device suspended even though the shutdown outcome is unknown. If the write did not reach the sensor, the sensors remain running and draw power while the device is idle. The condition need not persist. If the bus error clears, a later sensor access either reads the current PWR_MGMT0 value from hardware or retries programming the requested enabled mode, allowing normal operation to resume. Return the underlying errno to the PM core. -EAGAIN and -EBUSY retain their transient-error semantics; other errors put runtime PM into an error state and cause later PM acquires to fail until the status is explicitly reset. In the normal idle case, a successful system suspend can perform that reset. This leaves the transient-versus-fatal classification to the PM core and matches the sibling ICM-42600 driver. Keep a void wrapper for the managed teardown action, where errors can only be logged. Fixes: 3007c1530f96 ("iio: imu: inv_icm42607: Add PM support for icm42607") Signed-off-by: Linmao Li Tested-by: Kanak Shilledar Tested-by: Chris Morgan Signed-off-by: Jonathan Cameron commit cc07fae1de5dbf514a9a3978050ee3cf5fe20d3c Author: Kuba Piecuch Date: Wed Sep 30 14:23:59 2026 +0000 selftests/sched_ext: Add a test for ops.dequeue() on remote local DSQ moves Add a dequeue_remote test that makes moves of tasks in the BPF scheduler's custody to another CPU's local DSQ the common case, both via SCX_DSQ_LOCAL_ON dispatch and via scx_bpf_dsq_move_to_local(). The BPF scheduler tracks each task's custody state and triggers scx_bpf_error() if a custody period doesn't end with exactly one ops.dequeue() before the task runs, or if it ends with an SCX_DEQ_CORE_SCHED_EXEC dequeue of a task without a core cookie. Without the previous patch, the test fails with: sched_ext: dequeue_remote: dequeue_remote.bpf.c:141: 15 (rcu_preempt): late ops.dequeue() with SCX_DEQ_CORE_SCHED_EXEC (enq_cpu=3 cpu=2 seq=1) ... ops_dequeue+0x114/0x170 set_next_task_scx+0x104/0x1e0 __pick_next_task+0xc7/0x180 __schedule+0x154/0x1870 Reviewed-by: Andrea Righi Assisted-by: Claude:claude-opus-5.5 Signed-off-by: Kuba Piecuch Signed-off-by: Tejun Heo commit af701b8d3238b9eb7cd450b0491300452c700bf5 Author: Kuba Piecuch Date: Wed Sep 30 14:23:58 2026 +0000 sched_ext: Call ops.dequeue() when a task arrives on a remote local DSQ When a task in the BPF scheduler's custody is moved to another CPU's local DSQ, ops.dequeue() is only called once the task is picked for execution, from set_next_task_scx() with SCX_DEQ_CORE_SCHED_EXEC, even though no core-sched pick took place. It should instead be called without flags when the task is inserted into the destination DSQ, as it is for same-rq dispatches. move_remote_task_to_local_dsq() sets p->scx.sticky_cpu across the migration so that deactivate_task() on the source rq doesn't end custody. Since commit b75aaea24c9f ("sched_ext: Properly mark SCX-internal migrations via sticky_cpu"), enqueue_task_scx() only clears it after inserting the task, so task_leave_custody() still sees the migration in progress and skips the custody exit. Clear p->scx.sticky_cpu as soon as enqueue_task_scx() has read it, as was done before that commit. The source side is unaffected. Fixes: ebf1ccff79c4 ("sched_ext: Fix ops.dequeue() semantics") Cc: stable@vger.kernel.org # 7.1.x: 18d62044cda7: sched_ext: Preserve rq tracking across local DSQ dispatch Cc: stable@vger.kernel.org # 7.1.x Reviewed-by: Andrea Righi Assisted-by: Claude:claude-opus-5.5 Signed-off-by: Kuba Piecuch Signed-off-by: Tejun Heo commit e06b678e3b4e12fdaa0b51a7a5a54abc5dbd6469 Author: Waiman Long Date: Tue Sep 29 23:18:33 2026 -0400 cgroup/cpuset: Don't access cpuset_cgrp_subsys.root in is_in_v2_mode() After seeing the patch [1] to guard is_in_v2_mode() with RCU, it makes me realize that is_in_v2_mode() may be called in a context where a new cgroup filesystem is being rebound with stale cpuset_cgrp_subsys.root pointer. Avoid this potential UaF situation by adding a new cpuset_v2_mode flag which is set when the cpuset_v2_mode mount option is used. This flag is written into only when cpuset_bind() is being called with a stable cpuset_cgrp_subsys.root value. The is_in_v2_mode() helper is modified to read the new cpuset_v2_mode flag instead of accessing cpuset_cgrp_subsys.root directly. [1] https://lore.kernel.org/lkml/20260929084124.626693-2-arighi@nvidia.com Fixes: b8d1b8ee93df ("cpuset: Allow v2 behavior in v1 cgroup") Signed-off-by: Waiman Long Reviewed-by: Ridong Chen Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo commit 53c5c2c1095eb21e214811fec16cd75f89d72ee2 Author: Paulo Alcantara Date: Mon Sep 28 10:23:00 2026 -0300 smb: client: require stable pages for signed connections When signing, cifs computes the SMB signature over the pagecache folios in place and then hands those same folios to the socket. If a buffered write mutates a folio while a write subrequest is still in flight, the signature no longer matches the data that follows it, the server rejects the write with STATUS_ACCESS_DENIED (-EACCES), and the error is latched in the mapping, so the next fsync()/fallocate() returns -EIO. Mark the mapping for stable writes so netfs_perform_write() waits for writeback to complete before modifying an in-flight folio. This is only needed when the connection is signed. Fixes: 3ee1a1fc3981 ("cifs: Cut over to using netfslib") 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 commit 75aa4b4d557114276bb72e19a9bce5cb27b5e4b8 Author: Paulo Alcantara Date: Sun Sep 27 18:56:55 2026 -0300 smb: client: distinguish real EOF from a stale remote_i_size on read smb2_readv_callback() sets NETFS_SREQ_HIT_EOF whenever a short read lines up with netfs_read_remote_i_size(inode), the server's EOF as the client currently believes it. That belief can be stale: after a lease downgrade and handle reopen, the tracked remote_i_size can sit below the client's own i_size while an extending write hasn't reached the server yet. A read in that gap comes back short for a reason that has nothing to do with the file's real size, but was still marked HIT_EOF, and netfs reports a short read for it as-is. Only treat it as real EOF when the position is also at or past the client's own i_size; otherwise mark it NETFS_SREQ_CLEAR_TAIL instead, which tells netfs the shortfall is safe to zero-fill rather than report as a short read. This is what fsx (generic/363) sees as "short read: 0x0 bytes instead of 0x" against a Windows server. Fixes: 1da29f2c39b6 ("netfs, cifs: Fix handling of short DIO read") 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 commit dd05add7b2b6004c5fa3a1f276f56d8668f86b65 Author: Paulo Alcantara Date: Sat Sep 26 19:20:30 2026 -0300 netfs: zero the tail of a short DIO/unbuffered read 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 commit b5d59e7270d078ab28a9c4b4d11dc3eb24671988 Author: Paulo Alcantara Date: Sat Sep 26 18:34:51 2026 -0300 smb: client: only require read lease for size-extending preallocate smb3_simple_falloc() refuses any fallocate that clears FALLOC_FL_KEEP_SIZE with -EOPNOTSUPP whenever the inode is not read caching: /* if file not oplocked can't be sure whether asking to extend size */ if (!CIFS_CACHE_READ(cifsi)) if (!keep_size) { ... return rc; } As with smb3_zero_range(), the read lease is only needed to trust the cached size when deciding whether the request extends the file. When it is not held, the size can instead be fetched from the server, which is authoritative, rather than refusing the request outright: after flushing, query the server's end of file and take the larger of it and the cached size for the interior-vs-extend decision. The larger of the two is used because the server's end of file reflects another client's growth while the cached size reflects this client's own writes that may not have reached the server yet; using the server size alone would wrongly treat an interior request as extending when a range flush left an extending write unwritten. smb3_simple_fallocate_range(), which performs the actual interior emulation, decided whether the range already lies past EOF from its own i_size_read(inode) rather than the old_eof computed above. In the leaseless case, that is exactly the stale, undershooting size this patch works around: a genuinely interior range can read as past EOF by that stale count, which skips the FSCTL_QUERY_ALLOCATED_RANGES check entirely and overwrites already-allocated server data with zeroes instead of only filling the holes. Pass old_eof into smb3_simple_fallocate_range() and use it for that comparison instead of re-deriving a second, inconsistent one. Rejecting interior requests is observed as generic/363 randomly failing against Windows Server with do_preallocate: fallocate: Operation not supported fsx issues an interior, non-KEEP_SIZE preallocate while the inode is transiently not read caching: the server had just downgraded the file's lease from RWH to RH after breaking the write caching, and the ensuing handle reopen/revalidation left CIFS_CACHE_READ momentarily clear. The range sat within the server's end of file, so no extend was needed, yet it was refused and fsx aborted. This keeps the emulation correct even when a genuine lease break from another client leaves the inode without read caching -- the case the -EOPNOTSUPP guard turned into a hard failure. The extra flush and round trip only happen when both keep_size is false and no read lease is held; every other case is unchanged. Fixes: 9ccf3216238c ("Add support for original fallocate") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org commit 8db55c5cd831a786a1a2a2d391aa80354535a353 Author: Paulo Alcantara Date: Sat Sep 26 17:44:50 2026 -0300 netfs: zero gaps in read-gaps folio to avoid writing back stale data netfs_read_gaps() leaves gaps around a streaming write's dirty region unread on the server side, so a short/EOF response there left stale folio content that later got written back. Zero it after the read completes, not before: netfs_wait_for_read() returns rreq->transferred once ret >= 0, so build an iterator over the same bvec array the read used, advance past ret, and zero the rest. The dirty region already maps to sink pages in that array rather than the real folio, so this can't touch it, and only the actual shortfall gets zeroed instead of the whole gap upfront. Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") 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 commit fafc68cccf8a00ed0a1f47c1413a3f16ce4dcdfa Author: Paulo Alcantara Date: Sat Sep 26 17:15:47 2026 -0300 smb: client: only require read lease for size-extending zero range smb3_zero_range() refuses any FALLOC_FL_ZERO_RANGE that clears FALLOC_FL_KEEP_SIZE with -EOPNOTSUPP whenever the inode is not read caching: /* if file not oplocked can't be sure whether asking to extend size */ rc = -EOPNOTSUPP; if (keep_size == false && !CIFS_CACHE_READ(cifsi)) goto zero_range_exit; The read lease is only needed to trust the cached i_size when deciding whether the range extends the file. When it is not held, the size can instead be fetched from the server, which is authoritative, rather than refusing the request outright: query the server's end of file and take the larger of it and the cached size for the interior-vs-extend decision. The larger of the two is used because the server's end of file reflects another client's growth while the cached size reflects this client's own writes that may not have reached the server yet; using the server size alone would wrongly shrink the file when the range flush above left an extending write unwritten. The query isn't lease-protected either, so its result is only trusted to confirm the range is interior, never to justify extending: if it still shows the range going past EOF, refuse with -EOPNOTSUPP instead of calling SMB2_set_eof(), which could otherwise shrink the file if another client extended it further between the query and the call. For the same reason, take the larger of the already-computed i_size and a fresh i_size_read(inode) right before that call, instead of relying on either alone: the local variable carries the query's result, which is never written back to the inode, while a concurrent write on this client can still extend the cached i_size during the flush, the query, or the zero-data round trip that happen in between. Rejecting interior ranges is observed as generic/363 randomly failing against Windows Server with do_zero_range: fallocate: Operation not supported fsx issues an interior, non-KEEP_SIZE zero range while the inode is transiently not read caching: the server had just downgraded the file's lease from RWH to RH after breaking the write caching, and the ensuing handle reopen/revalidation left CIFS_CACHE_READ momentarily clear. The range sat well within the server's end of file, so no extend was needed, yet the range was refused and fsx aborted. This keeps the emulation correct even when a genuine lease break from another client leaves the inode without read caching -- the case the -EOPNOTSUPP guard turned into a hard failure. The extra round trip only happens on the no-lease path; the common cached case is unchanged. Fixes: 30175628bf7f ("[SMB3] Enable fallocate -z support for SMB3 mounts") 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 commit c9b1194e8ec99d95db25db45edd2fbf690f043ab Author: Paulo Alcantara Date: Sat Sep 26 13:04:44 2026 -0300 smb: client: drain and invalidate before server-side copy/clone cifs_file_copychunk_range() and the clone (FICLONE) path of cifs_remap_file_range() do not serialise the destination page cache against the server-side copy the way the other server-side range operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range() and smb3_insert_range()) do. cifs_file_copychunk_range() invalidates the destination range with filemap_invalidate_inode(), which takes and drops the mapping's invalidate_lock internally, so the lock is no longer held when the copychunk ioctl is issued. It also never drains in-flight netfs I/O on the target. The clone path never takes the invalidate_lock at all (only i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not drain outstanding I/O. As a result an asynchronous destination writeback can complete after the server-side copy/clone has run and reinstate stale data over the region just written by the server, corrupting the file. This is the same class of corruption as commit d7d2adcd022b ("smb/client: flush dirty data before punching a hole") and has been seen randomly in generic/363 against Windows Server. Fix both paths to follow the established ordering: hold the target mapping's invalidate_lock across the flush and invalidation of the destination and the server ioctl, and call netfs_wait_for_outstanding_io() on the target to drain in-flight writes before the ioctl is issued. Only the target inode's invalidate_lock is required, as the source is merely flushed and not invalidated; i_rwsem (already held via lock_two_nondirectories()) is acquired before the invalidate_lock, matching the VFS lock ordering. Since filemap_invalidate_inode() takes that same lock internally, replace it with its own unmap/flush/invalidate steps instead of calling it, and return early on a zero-length copy to avoid a range underflow. Fixes: 8101d6e112e2 ("cifs: Fix copy offload to flush destination region") Fixes: c54fc3a4f375 ("cifs: Fix flushing, invalidation and file size with FICLONE") 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 commit 8f8d32c1044f70e46e87550e039a15ff20a4b21c Author: Paulo Alcantara Date: Sat Sep 26 12:59:18 2026 -0300 smb: client: flush dirty data before zeroing a range smb3_zero_range() emulates FALLOC_FL_ZERO_RANGE by invalidating the page cache over the target range with truncate_pagecache_range() and then issuing FSCTL_SET_ZERO_DATA to the server. Dirty data was only flushed conditionally, when the range reached or extended EOF. For a purely interior zero range that does not reach EOF, no flush happened, so a dirty folio overlapping the range could be written back to the server after the FSCTL and refill the range that was just zeroed with stale data. Fix this by unconditionally flushing and waiting for dirty data in the range before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA, exactly as was done for smb3_punch_hole() in commit d7d2adcd022b ("smb/client: flush dirty data before punching a hole"); the two paths are structurally identical here. This is observed as generic/363 randomly reading stale data where a zeroed range is expected against Windows Server. Fixes: 91d1dfae4649 ("cifs: Fix FALLOC_FL_ZERO_RANGE to preflush buffered part of target region") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org commit 3581f843defa0bb30fd7da1e7dba170465e13a95 Author: Paulo Alcantara Date: Fri Sep 25 20:16:09 2026 -0300 smb: client: drain outstanding I/O before truncating on O_TRUNC open cifs_do_truncate() flushes the pagecache with filemap_write_and_wait() before resetting the file size to zero, but that does not wait for direct/async I/O that was already in flight, which can complete after the truncate and reinstate stale data past the new EOF. Drain outstanding netfs I/O with netfs_wait_for_outstanding_io() before resizing the file. Reported-by: Frank Sorenson Fixes: a8603b52b39f ("smb: client: fix data corruption with concurrent writes and O_TRUNC") 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 commit aa994489bd835547c191827acc460192e147032d Author: Paulo Alcantara Date: Fri Sep 25 19:35:12 2026 -0300 smb: client: flush and commit data before querying allocated ranges The mode 0 / FALLOC_FL_KEEP_SIZE fallocate emulation for small interior ranges in smb3_simple_fallocate_range() issues FSCTL_QUERY_ALLOCATED_RANGES and zero-fills any sub-range the server reports as an unallocated hole, to force block allocation without changing file contents. This is unsafe against Windows servers. Per the Win32 documentation, FSCTL_QUERY_ALLOCATED_RANGES only reports ranges that *may* contain nonzero data and is explicitly not coherent with recently written data: "a call to FSCTL_QUERY_ALLOCATED_RANGES [after writing to a network file] would not necessarily return a correct list of allocated regions. To ensure coherency [...] flush the data to the file" fsx (generic/363) reproduces the resulting corruption against Windows Server 2022: a range is written, an uncached read returns the data, yet the next FSCTL_QUERY_ALLOCATED_RANGES on that range reports it as a whole hole, so the emulation overwrites live data with zeroes. A network trace confirmed the WRITE, the READ returning data and the query returning an empty range list within microseconds. Samba does not exhibit this; its query is coherent with the written data. Write back the dirty pages, drain any outstanding I/O and issue an SMB2 FLUSH to force the server to commit the data before querying the allocated ranges, so the query reflects the data actually present. With this, generic/363 passes against both Windows Server 2022 and Samba over 100000 fsx operations. Fixes: 966a3cb7c7db ("cifs: improve fallocate emulation") 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 commit 4721587f96cb8de8164f3fd203093a0875560999 Author: Paulo Alcantara Date: Sun Sep 20 16:38:03 2026 -0300 smb: client: discard post-EOF pagecache when extending a file via clone range cifs_remap_file_range() discarded the pagecache only for the folios overlapping the destination region, so when a clone extends the file the folio straddling the old EOF - which may hold data dirtied past EOF through an mmap - was never dropped and became visible as file content once the file was extended. Start the discard at the smaller of fstart and the old EOF. i_size is still old here, so nothing past the old EOF is flushed to the server. Fixes: c54fc3a4f375 ("cifs: Fix flushing, invalidation and file size with FICLONE") 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 commit 7b473ac7cd6f7e087876d3c67b1bc6df662fb429 Author: Paulo Alcantara Date: Sun Sep 20 16:37:41 2026 -0300 smb: client: discard post-EOF pagecache when extending a file via copy range cifs_file_copychunk_range() invalidated the pagecache only for the destination region, so when a copy extends the file the folio straddling the old EOF - which may hold data dirtied past EOF through an mmap - was never dropped and became visible as file content once the file was extended. Start the invalidation at the smaller of the destination offset and the old EOF. filemap_invalidate_inode() writes back before invalidating while i_size is still old, so nothing past the old EOF is flushed to the server. Fixes: 8101d6e112e2 ("cifs: Fix copy offload to flush destination region") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org commit da4fe97fb6c730d9c94a115c7bfa6f98e0d578d0 Author: Paulo Alcantara Date: Sun Sep 20 16:09:30 2026 -0300 smb: client: discard post-EOF pagecache when extending a file via zero range smb3_zero_range() removed the pagecache only for the range being zeroed, so when it extends the file the folio straddling the old EOF - which may hold data dirtied past EOF through an mmap - was never dropped and became visible as file content once the file was extended. Lower the discard boundary to the smaller of the zero-range offset and the old EOF. Fixes: 72c419d9b073 ("cifs: fix smb3_zero_range so it can expand the file-size when required") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org commit 35024595f641e790e24609f3f046e1667e3b280a Author: Paulo Alcantara Date: Sun Sep 20 15:05:44 2026 -0300 smb: client: clear post-EOF pagecache when extending a file via truncate cifs_setsize() relied on pagecache_isize_extended() to zero the tail of the folio straddling the old EOF, but that helper is a no-op on CIFS (i_blkbits is 14), so data dirtied past EOF through an mmap survived and became visible once the file was extended. Use netfs_clear_stale_post_isize() instead, called after i_size is updated since cifs_setsize() callers hold i_rwsem exclusively for the whole resize. truncate_pagecache() is then called as in truncate_setsize(): a no-op on extend, and it drops the pagecache beyond the new EOF on shrink. Also thread old_size as an explicit parameter through cifs_setsize() and cifs_resize_file_locked(), captured by each caller before its own resize RPC. This closes a race where a concurrent stat() could adopt the RPC's already-updated server size via is_size_safe_to_change() before cifs_setsize() reads old_size itself. Closes: https://sashiko.dev/#/patchset/20260921230755.1133425-1-pc%40manguebit.org Fixes: c510edb9734a ("cifs: call pagecache_isize_extended() in cifs_setsize() when extending") 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 commit 69bf14300b50631e7c2271289d347bbd1b19a06c Author: Paulo Alcantara Date: Mon Sep 21 11:17:26 2026 -0300 netfs: clear post-EOF pagecache when extending a file via write Fix netfs to erase the contents of a hole created after the EOF by an ordinary write if dirty data has been previously left there by writes through an mmapped region. Neither the buffered nor the unbuffered/DIO write path clears that stale pagecache. Zero the tail of the folio straddling the EOF before an extending write. That is the only folio that can hold data written past the EOF through an mmap, as pages wholly beyond the EOF can't be faulted in. The folio is zeroed rather than dropped so a concurrent extending write can't lose data. Both write paths downgrade the i_rwsem to shared, so extending writes can run concurrently and the i_size read by the caller may be stale by the time the folio is locked. Re-read i_size under the folio lock and clamp the zeroed range up to it, so a racing write that already put data into the folio isn't clobbered. Wait for any writeback on the folio to finish before zeroing it so that the pagecache isn't modified while it may still be read by the transport during transmission. Honour IOCB_NOWAIT by returning -EAGAIN rather than blocking on the folio lock, on writeback, or in folio_mkclean()'s rmap walk when the folio is mapped. truncate_pagecache() can't be used here: it must be called with the i_rwsem held exclusively, but these write paths only hold it shared, and it would block unconditionally, breaking IOCB_NOWAIT. Callers that hold i_rwsem exclusively for the whole resize (truncate, setattr, fallocate, clone) exclude any genuine concurrent buffered writer, so staleness can instead be decided from the folio's dirty state, as pagecache_isize_extended() already does for filesystems that serialise writes against truncate/setattr via a single i_rwsem. Export netfs_clear_stale_post_isize() helper to handle such case. The helper is required by the CIFS client to fix generic/363. Closes: https://sashiko.dev/#/patchset/20260921230755.1133425-1-pc%40manguebit.org Fixes: 938e13a73b24 ("netfs: Implement buffered write API") Fixes: 153a9961b551 ("netfs: Implement unbuffered/DIO write support") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org commit c96ca94425b076dc398d929366e378d1e22ec794 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 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 commit ec86c43dcfff68eab4db9bdafcd3e2b16e342e18 Author: Osama Abdelkader Date: Tue Aug 4 18:00:47 2026 +0200 drm/panthor: validate userspace queue count against initialized firmware slot count 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 commit 572af6872e520c7102e58362ef7cd7c2ed4342be Author: Eric Biggers Date: Tue Sep 29 15:27:52 2026 -0700 crypto: aes - Fix undesired override of some optimized AES modes The new library APIs for AES encryption modes were wired up to the traditional crypto API via crypto/aes.c. However, for now the kernel is still in a transitional state where various architectures still have architecture-optimized implementations of AES modes in arch/*/crypto/, wired up to the traditional crypto API only. Because of that, the crypto/aes.c algorithms were given a cra_priority of only 110 to prevent them from overriding arch/*/crypto/ in the traditional crypto API. However, because of how the traditional crypto API works, the cra_priority trick doesn't work in cases where the relevant algorithm isn't directly implemented by arch/*/crypto/ but rather is provided by a template instance using other code in arch/*/crypto/. For example, x86 doesn't have its own "ccm(aes)" but rather relies on the "ccm" template constructing it from the x86-optimized "ctr(aes)". The existence of the library-based "ccm(aes)" prevents that, even though its priority is lower than what the template would produce. Thus, "ccm(aes)" ends up using the slower single-block AES code. Therefore, skip wiring up the relevant library-based code to the traditional crypto API on architectures where this problem can occur, as determined by what exists in arch/*/crypto/ for each architecture. This is ugly, but it's also temporary: these conditions will go away as architecture-optimized implementations of AES modes are migrated into the library. But until then, we need to prevent performance regressions by ensuring that the optimized code continues to be used. Fixes: 20df21a482aa ("crypto: aes - Add CBC and CBC-CTS support using library") Fixes: 8ca62072faa1 ("crypto: aes - Add GCM support using library") Fixes: f70ad727d1d6 ("crypto: aes - Add CCM support using library") Fixes: 94efa0c9fb36 ("crypto: aes - Add XTS support using library") Closes: https://github.com/sparclinux/issues/issues/106 Acked-by: Ard Biesheuvel Tested-by: Stian Halseth Link: https://patch.msgid.link/20260929222752.36427-1-ebiggers@kernel.org Signed-off-by: Eric Biggers commit 819f6aacbb1d1621c6a62721e708835fe1fb75d8 Author: Jakub Gawlik Date: Wed Sep 30 16:58:39 2026 +0200 ALSA: hda/realtek: Add micmute LED quirk for Acer Swift SFG16-72 The Acer Swift SFG16-72 (1025:173b) uses the ALC245 codec, but its mic-mute LED is not enabled by default. Apply the existing ALC245_FIXUP_ACER_MICMUTE_LED quirk to enable the mic-mute LED. Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Jakub Gawlik Link: https://patch.msgid.link/20260930145839.374762-1-jakubgawlik13@gmail.com Signed-off-by: Takashi Iwai commit 2f15518682c779b1014552cb2ccb4a2052f85f27 Author: Ridham Khurana Date: Wed Sep 30 10:53:25 2026 +0000 regulator: tps6594-regulator: Fix n_linear_ranges for TPS65224 BUCK2-4 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 commit b3e6212dea2e4328a841ceb37f377583176dc735 Author: Jinu Kim Date: Fri Aug 7 20:28:18 2026 +0900 KVM: x86: Use active memslots for the per-vCPU MMIO cache KVM tags the per-vCPU MMIO cache with a memslot generation so that a memslot update invalidates cached MMIO information. Both the fill and validation paths use kvm_memslots(), which unconditionally selects address space 0, even when the vCPU is running in SMM and using address space 1. Commit 56f17dd3fbc4 ("kvm: x86: fix stale mmio cache bug") added the memslot generation to the cache key so that a memslot update could not leave a stale entry valid. When commit 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space") added the SMM address space, these helpers were not converted to use the active memslots. Consequently, an update to the SMM memslots can leave an entry from the old SMM address space apparently valid after the vCPU returns to the normal address space. A guest can then cause an access to valid RAM at the same GFN to be returned to userspace as KVM_EXIT_MMIO. Completing that exit through the VMM's RAM address space writes the backing page without going through KVM's write-tracking path. If the page backs a nested EPT table, KVM can continue using shadow translations derived from the old contents. The WARN_ON_ONCE() in kvm_mmu_write_protect_fault() catches this invalid cache and memslot combination. Use the vCPU's active memslots when caching and validating the entry. Memslot generations are unique across address spaces, so the generation also distinguishes the normal and SMM views. This matches the MMIO SPTE cache, which already uses kvm_vcpu_memslots(). On an unpatched current-mainline kernel, a regression test that fills the cache in SMM and updates only the SMM memslots fails the intended RAM write and triggers the kvm_mmu_write_protect_fault() warning. With this change, the same test completes the RAM write without a warning. The x86/smm_test, set_memory_region_test, and memslot_modification_stress_test selftests also pass. Fixes: 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space") Cc: stable@vger.kernel.org Signed-off-by: Jinu Kim Link: https://patch.msgid.link/20260807112818.958190-1-kimjw04271234@gmail.com Signed-off-by: Sean Christopherson commit 97818b2fa7082e940ddd36dab12a68615300e798 Author: Jann Horn Date: Mon Aug 10 17:33:59 2026 +0200 KVM: SEV: Fix page dirtying in sev_gmem_post_populate() set_page_dirty() requires that the caller holds some kind of lock to ensure that the page's mapping does not concurrently go away. That is not the case for a random page we got from get_user_pages_fast(), so use set_page_dirty_lock(). Fixes: 97cd21d57e9b ("KVM: SEV: Mark source page dirty when writing back CPUID data on failure") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260810-x86-kvm-setpagedirty-v1-1-85f180892d4f@google.com [sean: tag for stable] Signed-off-by: Sean Christopherson commit 88c15bbd43ae95a2c81f3f21a7fd8f4fb0914902 Author: Naveen N Rao (AMD) Date: Wed Sep 23 08:51:08 2026 -0700 KVM: SVM: Clear AVIC Physical ID table entry if vCPU creation fails If vCPU creation fails after kvm_arch_vcpu_create(), the AVIC Physical ID table entry corresponding to that vCPU continues to point to the freed APIC backing page which can result in UAF. Address this by clearing out the corresponding AVIC Physical ID table entry in the vcpu_free() callback, similar to the VMX commit b41f2ca6c060 ("KVM: VMX: Fix stale PID-pointer table entry left after vCPU free"). Though unlikely, it is also possible that svm_vcpu_create() itself fails after the AVIC Physical ID table entry has been setup if memory allocation fails in svm_vcpu_alloc_msrpm(). Clear the entry in this path as well. Note: this change depends on commit 97d65b544f48 ("KVM: Check for duplicate vcpu_id as early as possible"), which ensures that a vCPU with a duplicate ID is never created. Otherwise, a valid AVIC Physical ID table entry for an existing vCPU will be cleared. Fixes: 44a95dae1d22 ("KVM: x86: Detect and Initialize AVIC support") Signed-off-by: Naveen N Rao (AMD) Tested-by: Atish Patra [sean: use avic_is_addressable_vcpu()] Link: https://patch.msgid.link/20260923155108.1550622-4-seanjc@google.com Signed-off-by: Sean Christopherson commit 12e0d427c335f6f140087def6b2002419ee5f6b0 Author: Sean Christopherson Date: Wed Sep 23 08:51:07 2026 -0700 KVM: SVM: Use "is AVIC-addressable" helper to sanity check load()/put() Use avic_is_addressable_vcpu() instead of open coding a check on the bounds of the allocated table for the sanity checks when loading/putting AVIC state for a vCPU. If KVM botches the allocation, then KVM will already have performed an OOB write in avic_init_backing_page(), i.e. being super paranoid in load()/put() doesn't provide meaningful protection in practice. Cc: Naveen N Rao (AMD) Reviewed-by: Naveen N Rao (AMD) Link: https://patch.msgid.link/20260923155108.1550622-3-seanjc@google.com Signed-off-by: Sean Christopherson commit 86a24feec1919b7858bb1062d5160f0e12aa5c7d Author: Sean Christopherson Date: Wed Sep 23 08:51:06 2026 -0700 KVM: SVM: Add paranoid helper for checking if vCPU is AVIC-addressable Add a helper to check if a vCPU is addressable by AVIC hardware, i.e. has an APIC ID that fits in the physical ID table, and use the more paranoid helper when determining if a vCPU is compatible with AVIC when initializing the vCPU. KVM is supposed to reject vCPU creation if the vCPU's ID is greater than or equal to max_vcpu_ids, i.e. simply checking the architectural maximum *should* suffice. But piecing together why this is safe is unnecessarily difficult, and there is no meaningful downside to being extra cautious. Suggested-by: Naveen N Rao (AMD) Reviewed-by: Naveen N Rao (AMD) Link: https://patch.msgid.link/20260923155108.1550622-2-seanjc@google.com Signed-off-by: Sean Christopherson commit 97384ef06c4fa79f7265ecd65c240bf40a8a9c41 Author: Harrison Lucas Date: Tue Sep 29 11:43:48 2026 -0600 ALSA: hda/realtek: Fix mute and micmute LEDs on HP ENVY x360 15-ey0xxx The HP ENVY x360 2-in-1 Laptop 15-ey0xxx (SSID 103c:8a31, ALC245 with CS35L41 I2C amps) currently only gets ALC287_FIXUP_CS35L41_I2C_2, so the mute and micmute LEDs on the keyboard never light up. On this machine the mute LED is driven by COEF 0x0b bits 2-3 and the micmute LED by GPIO 0x04 (active low), which is exactly what ALC245_FIXUP_HP_X360_MUTE_LEDS sets up. Switch the quirk to ALC287_FIXUP_CS35L41_I2C_2_HP_MUTE_LEDS, which keeps the CS35L41 setup and chains to that LED fixup. Verified by driving the COEF and GPIO values by hand with hda-verb, following Master Playback Switch and Mic ACP LED Capture Switch. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Harrison Lucas Link: https://patch.msgid.link/20260929174348.167537-1-tiiowsalt@gmail.com Signed-off-by: Takashi Iwai commit ece609abc95cc0f75e633d93f3d868b030d9a8fe Author: renpanpan Date: Wed Sep 30 14:55:04 2026 +0800 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 14-dv1001TU The HP Pavilion 14-dv1001TU (subsystem ID 103c:8987) uses a Realtek ALC287 codec. The mute LED on this machine is controlled by GPIO bit 0x10, which was verified via hda-verb, but the subsystem ID is missing from the quirk table. As a result, the ALC287_FIXUP_HP_GPIO_LED fixup that drives GPIO 0x10 is never applied and the mute LED stays off even though the associated LED class device toggles correctly. Add the missing SND_PCI_QUIRK entry to map this subsystem ID to ALC287_FIXUP_HP_GPIO_LED so the mute LED works as expected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221810 Signed-off-by: renpanpan Link: https://patch.msgid.link/20260930065504.24151-1-rppxj178543@163.com Signed-off-by: Takashi Iwai commit 4fa0c91c2c4c604e6080690a698d4c6405ba96ca Author: Harin Lee Date: Wed Sep 30 20:58:24 2026 +0900 ALSA: ctxfi: Fix silent playback on Titanium HD (SB1270) Commit 4b490e0d103c ("ALSA: ctxfi: Add ADC helper functions for GPIO") moved the GPIO_DATA read into hw_adc_stop(), but the Titanium HD (SB1270) setup in hw_adc_init() uses the local data variable holding the GPIO_CTRL value. Writing this value to GPIO_DATA sets the output mute bits. Playback runs without errors, but the outputs stay muted. Re-read GPIO_DATA before setting the speed mode bits. Also, add the delay after writing the mode bits, as in the original sequence. On affected kernels, switching the output selection was reported to restore clean playback. Fixes: 4b490e0d103c ("ALSA: ctxfi: Add ADC helper functions for GPIO") Cc: stable@vger.kernel.org Reported-by: Dany Patoine Closes: https://lore.kernel.org/linux-sound/DM6PR02MB5433A42E81FEFAC400DD1905EA8B2@DM6PR02MB5433.namprd02.prod.outlook.com/ Signed-off-by: Harin Lee Link: https://patch.msgid.link/20260930115824.739412-1-me@harin.net Signed-off-by: Takashi Iwai commit fcbde6227fcc53c73f08c56b2539e462d545cac6 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 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 commit c9417c1c5269e2bd0570fbe53e4ec03a8d31f008 Author: Mikulas Patocka Date: Wed Sep 23 12:40:16 2026 +0200 dm: fix reading free memory in do_resume 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 commit 57889076afd1be890150c32ffde3b691fe5707c8 Author: Cristian Ciocaltea Date: Tue Sep 1 21:50:38 2026 +0300 drm/bridge: Fix unlocked list access in drm_bridge_attach() drm_bridge_attach() inspects bridge->list to warn about bridges being attached without a previous drm_bridge_add() call, but it does so without holding bridge_lock. The list head can be concurrently written by drm_bridge_add(), drm_bridge_remove() and __drm_bridge_free() while they operate on neighbouring entries of bridge_list or bridge_lingering_list, all of them under bridge_lock. Hence the unlocked read is a data race, even though it is unlikely to change the outcome of list_empty() in practice. Perform the check with bridge_lock held. Fixes: 76f1a9711b83 ("drm/bridge: add warning for bridges attached without being added") Signed-off-by: Cristian Ciocaltea Reviewed-by: Luca Ceresoli Tested-by: Luca Ceresoli Tested-by: Igor Paunovic # RK3588 Orange Pi 5 Plus, dual HDMI Tested-by: Robin Räber Link: https://patch.msgid.link/20260901-dw-hdmi-qp-scramb-v11-14-bc12954a0688@collabora.com Signed-off-by: Luca Ceresoli commit b62e3db8cdc1680e1c3390591e872f485148541a Author: Cristian Ciocaltea Date: Tue Sep 1 21:50:36 2026 +0300 drm/bridge: Fix unlocked list_del in drm_bridge_add() When re-adding a bridge that was previously removed, drm_bridge_add() drops it from bridge_lingering_list without holding bridge_lock. Both bridge_list and bridge_lingering_list are protected by bridge_lock, as they are concurrently modified by drm_bridge_remove() and __drm_bridge_free(), and walked by the debugfs 'bridges' file. Running the list_empty() test and the list_del_init() outside of the lock may therefore corrupt either list. Perform both under bridge_lock. Fixes: 17805a15d175 ("drm/bridge: add list of removed refcounted bridges") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260723015004.1F5711F000E9@smtp.kernel.org/ Signed-off-by: Cristian Ciocaltea Reviewed-by: Luca Ceresoli Tested-by: Luca Ceresoli Tested-by: Igor Paunovic # RK3588 Orange Pi 5 Plus, dual HDMI Tested-by: Robin Räber Link: https://patch.msgid.link/20260901-dw-hdmi-qp-scramb-v11-12-bc12954a0688@collabora.com Signed-off-by: Luca Ceresoli commit 99b43ede9e355ba35244cc9470bf1819774ce39d Author: Harshit Mogalapalli Date: Thu Sep 24 23:39:36 2026 -0700 net: microchip: vcap: stop scanning after deleting key field The only call outside the KUnit tests is in sparx5_tc_add_rule_copy(), which passes a fixed key list with no duplicate entries. Therefore, the potential double-free is not currently reachable in tree. However, vcap_filter_rule_keys() is exported and does not require its key list entries to be unique. If a future or external caller supplies the same key at another position that the inner loop visits, it calls list_del() and kfree() a second time on the freed field, leading to a potential double-free. Break the inner loop after removing a matching field. The outer safe list traversal continues to process the remaining rule fields. Fixes: 465a38a269e9 ("net: microchip: sparx5: Support for copying and modifying rules in the API") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/ahs-lCAXXikkaHky@stanley.mountain/ Signed-off-by: Harshit Mogalapalli Reviewed-by: Daniel Machon Signed-off-by: David S. Miller commit bc8ce2cea5f77c4bd1a5184705e300e83546c0c4 Author: Hengyu Liang Date: Tue Sep 29 12:41:35 2026 -0400 ata: libata-scsi: do not lose CHECK CONDITION for failed ATAPI commands 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 commit 3ae37eafd36694bb2d3227f60ac98fbf602470a2 Author: Pablo Neira Ayuso Date: Wed Sep 23 20:46:18 2026 +0200 netfilter: flowtable: restore ieee80211 forward path Before commit 871df5007eda ("netfilter: flowtable: bail out if forward path cannot be discovered"), there was a fallback to set up a forward path in case .ndo_fill_forward_path fails or DEV_PATH_MTK_WDMA was used. Such fallback was used by commit d787a3e38f01 ("mac80211: add support for .ndo_fill_forward_path"). One possibility is to handle DEV_PATH_MTK_WDMA from the flowtable forward path discovery. However, this is only used internally by drivers to retrieve mtk_wdma information to set up hardware offload. Felix decided to use the .fill_forward_path interface for this purpose due to the lack of a better interface at that time. Add a new DEV_PATH_IEEE80211 path which is offered if the new ieee80211 flag is set on in the struct net_device_path_ctx to restore the flowtable with a ieee80211 netdevice. Handle this new DEV_PATH_IEEE80211 path just like DEV_PATH_ETHERNET and DEV_PATH_DSA, ie. this is the last netdevice in the stack. This new ieee80211 flag is implicitly unset for mtk_ppe and airoha which call dev_fill_forward_path() to retrieve a DEV_PATH_MTK_WDMA path. Fixes: 871df5007eda ("netfilter: flowtable: bail out if forward path cannot be discovered") Signed-off-by: Pablo Neira Ayuso commit 7c549fb7eecd01fdba7c0d12c01da876ef8a3214 Author: Pablo Neira Ayuso Date: Wed Sep 23 10:53:02 2026 +0200 netfilter: flowtable: generalize pending status bit Rename NF_FLOW_HW_PENDING to NF_FLOW_PENDING and use it to inhibit the flowtable GC worker until pending hw offload work has been completed. Apparently, nf_flow_offload_stats() can schedule work to retrieve stats while the flow is being removed by GC. And this bit can also be used in a follow up patch to disable GC until the flow has been fully added in both directions. Revert the reordering done in commit d644b23afe1e ("netfilter: flowtable: publish HW_DEAD after worker is done") to prevent a race between GC and hw offload handler. Fixes: 2c8897953f3b ("netfilter: flowtable: Add pending bit for offload work") Signed-off-by: Pablo Neira Ayuso commit 16d464013ec2267b00a83f4bfbb97b3ecc63bfa7 Author: Fernando Fernandez Mancera Date: Tue Sep 22 21:18:52 2026 +0200 netfilter: bpf: reject invalid NAT manipulation types As bpf_ct_set_nat_info() is not validating the NAT manipulation type a wrong value can be passed directly to nf_nat_setup_info(). This triggers the WARN_ON() at nf_nat_setup_info() and if panic_on_warn isn't set, then IPS_SRC_NAT_DONE is set without adding nat_bysource and conntrack cleanup tries to unlink an uninitialized hlist node. Fix this by checking that NAT manipulation type is correct before calling nf_nat_setup_info(). In addition, if the WARN_ON is hit, return NF_DROP instead of continuing with the processing to avoid similar situations in the future. Reported-by: VEGA Fixes: 0fabd2aa199f ("net: netfilter: add bpf_ct_set_nat_info kfunc helper") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso commit 86b6471e690c67d4c5a1892993f34e080f1eae9d Author: Weiming Shi Date: Mon Sep 21 10:08:22 2026 +0800 netfilter: nft_set_rbtree: skip transaction elements during GC Since nft_set_commit_update() runs set commit callbacks before processing NEWSETELEM transactions, nft_rbtree_gc_scan() can observe elements added by the transaction being committed. The scan records an interval end in rbe_end without checking the element's transaction state. A later, unrelated expired start then moves both elements to the expired list. The synchronous GC queue can free the new end element before the transaction subsequently activates it, causing a use-after-free. Only consider elements that are fully active in both generations. This keeps transaction-state elements out of the GC scan and preserves interval pairing across skipped elements. KASAN reports: BUG: KASAN: slab-use-after-free in nft_setelem_activate nft_setelem_activate net/netfilter/nf_tables_api.c:7047 nf_tables_commit net/netfilter/nf_tables_api.c:11137 Allocated by task 130: nft_set_elem_init net/netfilter/nf_tables_api.c:6794 nft_add_set_elem net/netfilter/nf_tables_api.c:7523 Freed by task 130: nft_trans_gc_trans_free net/netfilter/nf_tables_api.c:10506 rcu_core kernel/rcu/tree.c:2919 Fixes: 1e3b9e1c77fe ("netfilter: nf_tables: call set ops .commit when building new ruleset blob") Reported-by: Assisted-by: LLM Signed-off-by: Weiming Shi Signed-off-by: Pablo Neira Ayuso commit f96e91748f6304668fe647e686d199d7207d36f1 Author: Julian Anastasov Date: Sat Sep 19 21:07:33 2026 +0300 ipvs: filter some flags received in the backup server While the IPVS SYNC protocol is not secure by design we can still protect the backup server from messages that can wreak havoc. This commit addresses problems from received connection flags or their combinations. We now drop messages as follows: 1. the NO_CPORT+TEMPLATE combination allows lookups for normal connections to hit template which can break in many ways. While the master does not sync connections with NO_CPORT flag, i.e. before they are established, we still accept NO_CPORT without TEMPLATE. 2. ONE_PACKET: it is not sent by master, so we do not expect it in backup. Before now it was ignored by IP_VS_CONN_F_BACKUP_MASK for protocol v1 while protocol v0 created connections that are not hashed and dropped immediately. Better to apply the IP_VS_CONN_F_BACKUP_MASK also to the flags from v0 messages for consistency with v1. Fixes: 87375ab47cd0 ("[IPVS]: ip_vs_ftp breaks connections using persistence") Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso commit 616cf5c06934364ab1002b420ebe975850b4b208 Author: Julian Anastasov Date: Sat Sep 19 21:07:32 2026 +0300 ipvs: do not create invisible templates The IP_VS_CONN_F_ONE_PACKET flag was implemented for normal connections. When conn template inherits this flag from dest->conn_flags it will not be hashed. As result, we will create new template for every new normal connection. Fix it to allow one template to be used by many normal connections. Fixes: 26ec037f9841 ("IPVS: one-packet scheduling") Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260916231652.127456-1-pablo%40netfilter.org Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso commit 2a3c3de660f96865f303fd25f1285f2ffbfd521d Author: Zhiling Zou Date: Thu Sep 10 13:08:32 2026 +0300 ipvs: bound LBLCR and LBLC cache growth ip_vs_lblcr_new() and ip_vs_lblc_new() create cache entries for every previously unseen destination address. The table max_size only tells the periodic collector to reclaim entries after the cache has already exceeded the limit. It does not reclaim entries that the attacker continues to use. Reject new cache entries once either table reaches max_size * 3 / 2. The extra headroom lets the periodic collector catch up while the existing scheduler fallback continues to use the selected destination when cache creation fails. New traffic therefore stays serviceable without growing the tables further. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Julian Anastasov Signed-off-by: Zhiling Zou Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso commit bdac17779f46817f60103baf09f0370546c3f023 Author: Julian Anastasov Date: Thu Sep 10 13:08:31 2026 +0300 ipvs: fix missing counter decrement in lblc LBLC may delete cache entries for destinations that are removed or overloaded and replace them with available ones. But ip_vs_lblc_new() forgets to decrement the tbl->entries counter after calling ip_vs_lblc_del(). This can lead to increased shrinking of the cache with every new garbage collection. Fixes: 2f3d771a35fe ("ipvs: do not use dest after ip_vs_dest_put in LBLC") Link: https://sashiko.dev/#/patchset/0bdd5abe9968ded7ca2b9cb6844ba83d94cc8d53.1787318053.git.zhilinz%40nebusec.ai Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso commit 747928b5d4ff8c8de55138a54c13980e4bb88578 Author: Aohan Mei Date: Thu Sep 10 16:33:26 2026 +0800 netfilter: nft_flow_offload: drop flowtable reference on init error path nft_flow_offload_init() bumps the flowtable use count with nft_use_inc() before calling nf_ct_netns_get(). When the latter fails, the error is returned as-is and the reference is leaked. The upper layers do not balance it either: nf_tables_newexpr() clears expr->ops when the expression init callback fails, so the nft_expr_more() iteration in nft_rule_expr_deactivate() and nf_tables_rule_destroy() stops right before the failed expression and its ->destroy callback, which would drop the reference, never runs. Each failed rule addition therefore leaks one flowtable reference and the flowtable can no longer be removed: NFT_MSG_DELFLOWTABLE keeps reporting -EBUSY even though no rule references it. Save the nf_ct_netns_get() return value and undo the nft_use_inc() when it fails, restoring the inc/dec pairing within nft_flow_offload_init() itself. Fixes: a3c90f7a2323 ("netfilter: nf_tables: flow offload expression") Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Assisted-by: CodeBuddy:Kimi-K3 Signed-off-by: Aohan Mei Signed-off-by: Pablo Neira Ayuso commit 2e7ea988a03273f7add64218fbaf28d96c963062 Merge: 0d2c49915bc3ae 81fe707ae58e67 Author: David S. Miller Date: Wed Sep 30 08:02:40 2026 +0100 Merge branch 'tcp-old-acks' tcp: correct timestamp echo for accepted old ACKs Linux can acknowledge newly received data while echoing an outdated TCP timestamp. This happens when a reordered packet fills a receive gap but carries an older acknowledgment for traffic in the other direction. If the sender uses this echo to measure round-trip time after a long idle period, the stale timestamp can inflate its estimate and slow its sending. Changes in v2, following Eric Dumazet's review: - Remove the redundant SYN_RECV condition and unused flag accumulation. - Replace the log-parsing wrapper with a plain packetdrill test that checks the timestamp echo directly, using the existing selftest runner. - Rebase on net fc6d80eb5044. v1: https://lore.kernel.org/netdev/20260921222609.50824-4-jeffjo@openai.com/ In this example, S sends the reordered data and R is the Linux receiver being patched. All packets shown belong to the same TCP connection, with overlapping requests in both directions. Each illustrated request fits in one TCP packet; request/response names describe application messages, while ACK numbers acknowledge TCP bytes. The numbers are illustrative: TS and echo use S's millisecond clock, and byte numbers are relative to the first post-idle byte in each direction. ACK=N acknowledges bytes before N. Before idle: S -> R: sender request 1, TS=999 R -> S: response to sender request 1, echo=999 S -> R: TCP ACK, TS=1000 (R saves timestamp 1000) ... 300 seconds idle ... After idle (byte ranges include both ends): S -> R: sender request 2, bytes 1-17, ACK=1, TS=301000 (delayed in the network) R -> S: receiver request 1, bytes 1-17, ACK=1 (initiated by R while sender request 2 is still in flight) S -> R: sender request 3, bytes 18-34, ACK=18, TS=301005 (arrives before sender request 2) R -> S: TCP ACK=1, SACK for sender request 3, echo=1000 S -> R: original sender request 2 arrives, still ACK=1, TS=301000 R -> S: TCP ACK=35, echo=1000 (bug) or echo=301000 (fixed) R initiates receiver request 1 while sender request 2 is still in flight; its ACK=1 means it has not received sender request 2. S receives R's request before sending sender request 3, so that packet carries ACK=18. Sender request 3 reaches R first, making sender request 2's ACK=1 old. The earlier ACK with SACK correctly echoes 1000 while the gap is open. The bug is retaining 1000 in ACK=35 after the gap closes, instead of echoing sender request 2's timestamp, 301000. If S falls back to timestamp-based RTT measurement for ACK=35, subtracting echo=1000 from its current timestamp (about 301000) produces a roughly 300-second RTT sample, mistakenly counting the idle period. The inflated smoothed RTT lowers the sender's calculated pacing rate and, when pacing is enforced, unnecessarily delays outgoing packets and slows the transfer. Patch 1 refreshes the saved timestamp while preserving existing validation. Patch 2 checks that the ACK closing the receive gap echoes timestamp 301000, in IPv4, IPv6 and IPv4-mapped IPv6. It requires packetdrill's merged TSecr verification fix, commit 83f72d3f9085, linked below. Once CI uses a packetdrill version containing that fix, the timestamp assertion will reject the stale echo on an unfixed kernel and pass with this kernel fix. Older packetdrill versions ignore the comparison and incorrectly pass both. https://github.com/google/packetdrill/commit/83f72d3f9085d0e26eb4d206fe4d7cfab5b6d872 V1 passed 68 focused/control cases on normal and KASAN/UBSAN/lockdep ARM64 kernels, with no new diagnostics from W=1 allyesconfig/allmodconfig builds or Sparse. V2 passed the same checks with equivalent results. Earlier C-socket repro on net 46bc52d13594: after 300 seconds idle, with controlled reordering, retransmission and fq pacing, a 1 MiB transfer takes 22.02 seconds without the fix versus 0.38 seconds with it (one run per arm). AI assistance: Codex generated and revised the fix, reproducers, selftest, analysis and patch messages. The user directed the investigation, asked for real-socket and upstream-kernel comparisons, and requested broader testing. A separate Codex reviewer challenged the v1 code and evidence. Sparse supplied static analysis. Signed-off-by: David S. Miller Jeff Jo (2): tcp: refresh TS.Recent for accepted old ACKs selftests: net: check timestamp echo after an old ACK net/ipv4/tcp_input.c | 6 +++++ .../net/packetdrill/tcp_old_ack_ts.pkt | 22 +++++++++++++++++++ 2 files changed, 28 insertions(+) create mode 100644 tools/testing/selftests/net/packetdrill/tcp_old_ack_ts.pkt base-commit: fc6d80eb504458d6416b75a94188b268c95c6533 commit 81fe707ae58e67e5a029a9778c4b0c1b478bcb97 Author: Jeff Jo Date: Thu Sep 24 15:44:59 2026 -0700 selftests: net: check timestamp echo after an old ACK Add a regression test for a gap-filling packet whose acknowledgment has become old. Linux first sends data to the peer. Deliver two peer data packets out of order: the later packet acknowledges Linux's data, while the delayed packet still carries the earlier acknowledgment. Require the ACK that closes the receive gap to echo the delayed packet's timestamp, 301000. Without the fix, Linux accepts the data but still echoes the previously saved timestamp, 1000. Also check that the application can read all 34 bytes. Use a large jump in peer timestamps to represent the idle interval, with no real wait, loss or retransmission. The test directly checks the outgoing timestamp echo. It requires packetdrill's merged TSecr verification fix (linked below); older tools incorrectly pass on an unfixed kernel. Use the existing packetdrill selftest runner for IPv4, IPv6 and IPv4-mapped IPv6. Link: https://github.com/google/packetdrill/commit/83f72d3f9085d0e26eb4d206fe4d7cfab5b6d872 Assisted-by: LLM Signed-off-by: Jeff Jo Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller commit 1b92780ae4fc3be64f05d97ed8833c445e73b0cf Author: Jeff Jo Date: Thu Sep 24 15:44:58 2026 -0700 tcp: refresh TS.Recent for accepted old ACKs A TCP packet can carry new data while acknowledging traffic in the opposite direction. With overlapping traffic in both directions, a delayed packet's acknowledgment can be older than one Linux has already accepted, even when that packet fills a gap in the received data. Linux accepts the data, but tcp_ack() takes the old_ack path and skips updating TS.Recent, the timestamp saved for outgoing acknowledgments. The reply therefore echoes an older timestamp. If the sender uses this echo to measure round-trip time after a long idle period, its estimate includes the idle time and can reduce its sending rate. Update TS.Recent in old_ack using tcp_replace_ts_recent(), before SACK processing can trigger a transmission. This reuses the existing timestamp and sequence checks, including PAWS protection against old duplicate packets. ACK validation already rejects old ACKs in SYN_RECV before this path, so no additional state check is needed. Echoing the timestamp of the packet that fills the receive gap follows RFC 7323 section 4.3. In a socket reproduction with 300 seconds idle, controlled reordering and retransmission to exercise timestamp-based RTT sampling, the sender's smoothed round-trip time was 37.5 seconds without the fix and 15.5 ms with it. Fixes: 12fb3dd9dc3c ("tcp: call tcp_replace_ts_recent() from tcp_ack()") Assisted-by: LLM sparse Signed-off-by: Jeff Jo Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller commit 551c722f40809618230001baccf219193e22fc5a Merge: a243ede718463c 055ef5ce9f67a6 Author: Linus Torvalds Date: Tue Sep 29 18:54:21 2026 -0700 Merge tag 'rtc-7.3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux Pull RTC fixes from Alexandre Belloni: "Mostly small issues found using AI. The efi change is to avoid a regression on some platforms Subsystem: - fix a possible information leak Drivers: - efi: restore alarm support with runtime capability probe" * tag 'rtc-7.3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: rtc: spear: initialize IRQ state before requesting alarm IRQ rtc: mpfs: fix unchecked devm_clk_get() error pointer in probe() rtc: ac100: Fix clock provider use-after-free on probe failure rtc: ac100: Assign .num before accessing .hws rtc: efi: restore alarm support with runtime capability probe rtc: dev: zero-initialize struct rtc_wkalrm to prevent information leak commit 0d2c49915bc3aea4521cda5e4d42f24f63b94585 Author: Quentin Freimanis Date: Sun Sep 27 21:45:42 2026 -0700 net: sparx5: skip ptp deinit if init was skipped sparx5_ptp_init() returns early on the base lan969x variants because they do not have the SPX5_FEATURE_PTP flag. It also returns early when no "ptp" interrupt is described. Unbinding the driver then causes a NULL pointer dereference when cleaning up uninitialized tx_skbs queues: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: skb_queue_purge_reason+0x68/0x120 (P) sparx5_ptp_deinit+0x64/0xc0 mchp_sparx5_remove+0x38/0x70 platform_remove+0x20/0x30 device_remove+0x4c/0x80 Before per-port tx_skbs were added, a NULL dereference would have happened when calling ptp_clock_unregister() on the never-registered PTP clocks. Fix by returning early in sparx5_ptp_deinit() if PTP is not used. Fixes: 0933bd04047c ("net: sparx5: Add support for ptp clocks") Signed-off-by: Quentin Freimanis Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20260928044542.29287-1-quentin@q-lab.dev Signed-off-by: Jakub Kicinski commit 20f3599d85b416fd292a199364cb1248dcd9c780 Author: Yongzhao Chen Date: Sun Sep 27 17:51:36 2026 +0200 net: phy: qcom: at803x: Fix IPQ5018 short-cable DAC values When "qcom,dac-preset-short-cable" is set, ipq5018_config_init() programs the MDAC (MMD1 0x8100) and EDAC (debug 0x4380) fields. Both fields occupy bits 15:8 (IPQ5018_PHY_DAC_MASK), but the value 0x10 is passed unshifted as the set argument of phy_modify_mmd() and at803x_debug_reg_mask(). Neither helper shifts or masks that argument, so both fields are cleared to 0x00 instead of being set to 0x10, and bit 4 of the low byte, which is outside the field, is set. Use FIELD_PREP() to place the value in the field. This matches the vendor SDK, which clears bits 15:8 and ORs in the value shifted left by 8. On a Redmi AX5400 board, where the IPQ5018 internal PHY connects to a QCA8337 switch PHY without a cable, MDAC and EDAC read 0x6868 and 0x7800 before the write. With this change they read back 0x1068 and 0x1000, with the low byte preserved. Without it, the same writes would leave 0x0078 and 0x0010. No in-tree DTS sets this property yet, but it is documented in qca,ar803x.yaml and used by several IPQ5018 boards in OpenWrt. Fixes: d46502279a11 ("net: phy: qcom: at803x: Add Qualcomm IPQ5018 Internal PHY support") Signed-off-by: Yongzhao Chen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260927155136.2489-1-yongzhao.derek@gmail.com Signed-off-by: Jakub Kicinski commit 6f0c2c4f5e7143eba75153ecc8af3a03f7b6a98b Author: Sandeep Haemoon Date: Thu Sep 24 23:51:37 2026 +0300 net: ethernet: mtk_eth_soc: allocate dummy netdev sooner The RX rings and the shared NAPI are carried by an internal "dummy" netdev (eth->dummy_dev). mtk_probe() creates that dummy device, and adds the shared tx/rx NAPI to it, only after the MAC netdevs have been registered. That order has been there since the MT7623 support was added and leaves a window in which the netdevs are visible to the network core before the shared NAPI and the dummy device exist. If anything brings the first netdev up during that window (e.g. netifd opening the WAN link the instant the interface is registered), the first-open path runs without them. On NETSYS v2 and later SoCs mtk_rx_alloc() -> __xdp_rxq_info_reg() then dereferences eth->dummy_dev == NULL: WARNING: CPU: ... Missing net_device from driver in net/core/xdp.c and mtk_open() fails with -ENODEV. On NETSYS v1 SoCs (MT7621/MT7622/MT7623/MT7629) there is no page pool, so the same open instead calls napi_enable() on a napi_struct that netif_napi_add() has not initialised yet and dereferences a NULL napi->dev. Allocate the dummy netdev and add the shared tx/rx NAPI to it before the register_netdev() loop. Both the dummy-allocation failure and a register_netdev() failure now unwind through mtk_unreg_dev(), which unregisters the net_device notifiers and the netdevs registered so far, stopping a concurrently-opened netdev (ndo_stop) and its NAPI before the dummy carrier is freed. A netdev that opened during the window can also have queued the frame-engine reset worker (via the tx watchdog or phylink), so the probe error path now cancels eth->pending_work before freeing the shared state, as mtk_cleanup() already does on remove. Fixes: 656e705243fd ("net-next: mediatek: add support for MT7623 ethernet") Signed-off-by: Sandeep Haemoon Reviewed-by: Simon Horman Link: https://patch.msgid.link/patch-e52c13380b0768fec63af04c80e4b487@loljews.com Signed-off-by: Jakub Kicinski commit 5f0764cb1c81a9712bce605d38efe6d844a70b29 Author: Willem de Bruijn Date: Sat Sep 26 10:04:54 2026 -0400 net: extend IPv6 exthdr detection of tunneled packets Commit c4336a07eb6b ("net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback") split skb_gso_has_extension_hdr() into mutually exclusive branches on skb->encapsulation. This did not yet address all paths: 1. With skb->encapsulation set, the outer header is not checked. IPv6 tunnels such as ip6_gre and ip6_tunnel add an outer Destination Options header by default (encap_limit). Their GSO packets skip software GSO, then skb_csum_hwoffload_help() sees the outer extension header and calls skb_checksum_help() on the GSO skb, which warns and drops it. 2. Tunnels over IPv6 without an outer transport header, such as ip6_tunnel, leave skb->transport_header at the inner transport header. skb_network_header_len() then spans the outer IPv6, tunnel and inner IP headers, a false positive. 3. UDP tunnels without an inner network header, such as SCTP-in-UDP or PSP, have no inner IPv6 header to check. Decide on the outer header alone. 4. Directly dereferencing inner_ip_hdr(skb)->version without skb_header_pointer() is unsafe. Instead, check ipv6_ext_hdr(nexthdr) on the outer IPv6 header and, if set, on the inner IPv6 header. Read the headers with skb_header_pointer(). Keep the skb_network_header_len() check when !skb->encapsulation to also catch encapsulated packets without skb->encapsulation (e.g., virtio). Use the same helper in skb_csum_hwoffload_help(). Its open coded test has the false positive of (2) and ignores the inner header. Background: checksum offload of tunneled packets invariants: Non-GSO skb: - If the inner packet is CHECKSUM_PARTIAL, Local Checksum Offload computes the outer checksum in software and the device offloads only the inner L4 checksum. - If the inner packet is CHECKSUM_NONE (e.g., SCTP-in-UDP, ESP-in-UDP, Remote Checksum Offload), the device offloads the outer UDP or GRE checksum instead. GSO skb: - A device with NETIF_F_GSO_UDP_TUNNEL_CSUM or NETIF_F_GSO_GRE_CSUM computes both inner and outer checksums per segment. The outer checksum is seeded with only the pseudo-header checksum. A NETIF_F_IPV6_CSUM device must parse through the outer headers to reach the inner ones. Fixes: c4336a07eb6b ("net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback") Cc: stable@vger.kernel.org Signed-off-by: Willem de Bruijn Link: https://patch.msgid.link/20260926140506.2335137-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski commit ea4d4b5dddb5121e64f56fd8e0720bd8b447b63d Author: Jamal Hadi Salim Date: Mon Sep 28 08:46:16 2026 -0400 net: cap skb->queue_mapping when the tx queue is picked skbedit can set skb->queue_mapping and raise the per-CPU skip_txqueue flag so __dev_queue_xmit() honours the mapping. __dev_queue_xmit() cleared the flag before sch_handle_egress() and only read it afterwards, so the flag was not confined to the xmit that set it: a nested xmit (mirred redirect or mirror, or a drop after skbedit) could set the flag and the outer xmit would consume it for an skb that never went through skbedit. A forwarded packet still carries the ingress NIC's rx_queue + 1 in skb->queue_mapping, so the outer device then indexes its tx queue state with that stale value. Taprio's child array q->qdiscs[] is sized to the device's queue count, so taprio_enqueue() indexes past its allocation and dereferences the result as a struct Qdisc *. We (ab)use the skb->nf_skip_egress which means "skip netfilter egress for this packet" to tag to "am I in tc egress?". Despite the overload I dont see it as a conflict since the marker is set only around the single sch_handle_egress() call and ingress path is guarded by tc_at_ingress. I will send a followup(net-next) patch once this hits net-next to rename the skb->nf_skip_egress bit/flag to skb->skip_egress Arm the flag only from the egress classifier that can use it: raise skip_txqueue from tcf_skbedit_act() only when it runs inside sch_handle_egress(), thanks to skb->nf_skip_egress. An egress qdisc classifier runs in q->enqueue(), after the tx queue has been picked, so a mapping it sets cannot affect the current packet; arming the flag there only pollutes it for a later xmit. Then own the flag for the xmit frame the egress hook runs in: save the incoming value and clear it just before sch_handle_egress(), and restore it after the hook - on the consumed (drop) path, or, in the same call that reads it, on the surviving path. The save and the restores stay inside the egress_needed_key static branch, so a packet pays for them only when egress hooks are active (2f1e85b1aee4). Store the value netdev_cap_txqueue() selected back into skb->queue_mapping in netdev_tx_queue_mapping(), as netdev_core_pick_tx() already does, so the skip_txqueue path never hands a later reader on the xmit path a mapping the device cannot serve. A store made still later in the same frame, by a tc BPF program attached to a transmit qdisc, is outside this path and is not re-capped; a separate followup will resolve that path. netdev_xmit_skip_txqueue() returns the previous flag value so the save-and-clear is one call, and a no-op stub is provided when CONFIG_NET_EGRESS is disabled. skb->nf_skip_egress is compiled under CONFIG_NET_EGRESS rather than CONFIG_NETFILTER_SKIP_EGRESS, so skb_at_tc_egress() is valid whenever the egress path is built. A local user in a network namespace can redirect a packet from a device with more TX queues to one with fewer after setting a mapping valid only on the larger device. That reaches these reads and, under KASAN, faults with "slab-out-of-bounds in taprio_enqueue". Conditions to recreate the bug: the report's own trigger is a local user with CAP_NET_ADMIN in a network namespace, so no eBPF program is needed. With CONFIG_NET_SCH_TAPRIO=y, CONFIG_NET_ACT_SKBEDIT=y, CONFIG_NET_ACT_MIRRED=y, CONFIG_NET_CLS_MATCHALL=y, CONFIG_NET_SCH_PRIO=y and KASAN enabled, create qa (3 queues), qb (2 queues) and qc (1 queue) as dummy devices; put a taprio root on qb (num_tc 1, queues 2@0) and clsact on all three; then add an egress matchall filter on every device. On qa: "action skbedit queue_mapping 2 pipe action mirred egress redirect dev qb". On qb: "action mirred egress mirror dev qc". On qc: "action skbedit queue_mapping 0 pipe". Send one packet out qa. qc's skbedit sets the flag while qb's outer xmit is in flight; without the fix qb consumes it and reads its two-entry taprio child array with the forwarded packet's stale mapping. A qc whose skbedit is instead installed in a transmit-qdisc classifier (a matchall filter on the qc root qdisc) reaches the same code path the same way without the fix. Testing: on a KASAN build with panic_on_warn=1 the unfixed kernel panics with "BUG: KASAN: slab-out-of-bounds in taprio_enqueue", a read 0 bytes past a 16-byte taprio_init() allocation, for the clsact-setter and the transmit-qdisc-classifier reproducers and for a clsact skbedit-then-tc-BPF store; the fixed kernel runs all three with no report, and the BPF store variant additionally shows the expected "selects TX queue" clamp notice from the write-back. Fixes: 2f1e85b1aee4 ("net: sched: use queue_mapping to pick tx queue") Reported-by: Zero Day Initiative Link: https://lore.kernel.org/netdev/CANn89iLwYx8nCVf0pCEk_MmEiyC6kQaMwCQT9WkQVeeNzNQHqQ@mail.gmail.com/ Link: https://lore.kernel.org/netdev/179008581937.2160803.7117814290574262942@kernel.org/ Link: https://lore.kernel.org/netdev/179033713973.2160803.4914570693994398206@kernel.org/ Link: https://lore.kernel.org/netdev/20260925180407.63647514@kernel.org/ Link: https://lore.kernel.org/netdev/CANn89i+k-mZKDQVtvws_MEXeuMTAdaCcOXFZE-RfhcGTu90sjA@mail.gmail.com/ Suggested-by: Eric Dumazet Suggested-by: Jakub Kicinski Tested-by: hybris Signed-off-by: Jamal Hadi Salim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/QDISC-9R8V.v4.20260928081529@mojatatu.com Signed-off-by: Jakub Kicinski commit cfb3293c4573289f11f913611f530ea6b1926d67 Author: Vladimir Murzin Date: Tue Sep 22 11:37:56 2026 +0100 usb: mtu3: Fix double dereference in TP_printk Paul reported kernel splat: [ 0.000000] TRACE EVENT ERROR: Event mtu3_gadget_ep_set_halt has double dereference in TP_printk: &REC->gpd_ring->dma [ 0.000000] ------------[ cut here ]------------ [ 0.000000] Event mtu3_gadget_ep_set_halt has double dereference in TP_printk: &REC->gpd_ring->dma [ 0.000000] WARNING: kernel/trace/trace_events.c:420 at test_double_dereference+0x144/0x14c, CPU#0: swapper/0/0 [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.3.0-rc1 #15247 PREEMPT [ 0.000000] Hardware name: linux,dummy-virt (DT) [ 0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.000000] pc : test_double_dereference+0x144/0x14c [ 0.000000] lr : test_double_dereference+0x144/0x14c [ 0.000000] sp : ffffc80aa7633bf0 [ 0.000000] x29: ffffc80aa7633bf0 x28: ffffc80aa7c0f047 x27: 000508b58019388f [ 0.000000] x26: 0000000000000003 x25: 0000000000000007 x24: ffffc80aa5fceff8 [ 0.000000] x23: ffffc80aa7c0f05a x22: ffffc80aa64edfe8 x21: ffffc80aa7c0fce8 [ 0.000000] x20: ffffc80aa7c0f047 x19: 0000000000000013 x18: 0000000000000001 [ 0.000000] x17: 6572656420656c62 x16: 756f642073616820 x15: 746c61685f746573 [ 0.000000] x14: 0000000000000000 x13: ffff000139d90000 x12: 0000000000000045 [ 0.000000] x11: 00000000000000cf x10: ffff00013f546428 x9 : ffff000139d90000 [ 0.000000] x8 : 3fffffffffffc000 x7 : 0000000000000001 x6 : 0000000000000001 [ 0.000000] x5 : ffff00013f4e6440 x4 : 0000000000000000 x3 : 0000000000000000 [ 0.000000] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffc80aa764a700 [ 0.000000] Call trace: [ 0.000000] test_double_dereference+0x144/0x14c (P) [ 0.000000] trace_event_raw_init+0x37c/0x5d8 [ 0.000000] event_init+0x34/0xc0 [ 0.000000] trace_event_init+0xec/0x588 [ 0.000000] trace_init+0x24/0x6e0 [ 0.000000] start_kernel+0x4a0/0x8ec [ 0.000000] __primary_switched+0x88/0x90 [ 0.000000] irq event stamp: 0 [ 0.000000] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 0.000000] hardirqs last disabled at (0): [<0000000000000000>] 0x0 [ 0.000000] softirqs last enabled at (0): [<0000000000000000>] 0x0 [ 0.000000] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] TRACE EVENT ERROR: Event mtu3_gadget_ep_disable has double dereference in TP_printk: &REC->gpd_ring->dma [ 0.000000] TRACE EVENT ERROR: Event mtu3_gadget_ep_enable has double dereference in TP_printk: &REC->gpd_ring->dma Which also observed by Mark and myself. The splat it result of new check introduced by b5cc230af5e5 ("tracing: Warn when an event dereferences a pointer in TP_printk()") which correctly catches issue with %pad dereferencing the address saved in the ring buffer. TP_fast_assign() logic gets executed when the tracepoint is triggered, however the TP_printk() is executed when the user reads the trace buffer which could be seconds, minutes, hours, days, even months later and nothing guarantee that __entry->gpd_ring pointer will still be pointing to what it was when it was recorded. Fix the issue by capturing immediate value of gpd_ring.dma when trace point is triggered. Reported-by: Paul E. McKenney Tested-by: Mark Rutland Reviewed-by: Steven Rostedt Signed-off-by: Vladimir Murzin Signed-off-by: Paul E. McKenney commit 19419faf58dfe5bcc8a9e60e622976c5f8e3ddc1 Author: Nicolai Buchwitz Date: Mon Sep 28 12:56:41 2026 +0200 net: bcmgenet: fix NULL dereference in set_coalesce before first open The Rx ring priv and index are only set in bcmgenet_init_rx_ring(), which runs at open. Setting the Rx coalescing parameters on an interface that was never opened, e.g. "ethtool -C eth0 rx-usecs 50", dereferences a NULL ring->priv. The oops happens with RTNL held, so networking stays stuck until a reboot: Unable to handle kernel paging request at virtual address 0000000000002788 pc : bcmgenet_set_rx_coalesce.isra.0+0x10/0x88 lr : bcmgenet_set_coalesce+0xe8/0x180 Call trace: bcmgenet_set_rx_coalesce.isra.0+0x10/0x88 (P) __ethnl_set_coalesce.isra.0+0x490/0x570 ethnl_set_coalesce+0x48/0xc0 ethnl_default_set_doit+0xf4/0x230 genl_family_rcv_msg_doit+0xe8/0x160 genl_rcv_msg+0x220/0x2a0 netlink_rcv_skb+0x68/0x140 genl_rcv+0x40/0x60 netlink_unicast+0x338/0x3c0 netlink_sendmsg+0x19c/0x3f8 __sock_sendmsg+0x64/0xc0 __sys_sendto+0x124/0x198 __arm64_sys_sendto+0x30/0x48 Set priv and index at probe. Writing the registers while the interface is down is harmless because open resets the MAC and bcmgenet_init_rx_coalesce() reapplies the stored values. It was observed on a Raspberry Pi CM4, but should apply to all other genet devices. Fixes: 9f4ca05827a2 ("net: bcmgenet: Add support for adaptive RX coalescing") Signed-off-by: Nicolai Buchwitz Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260928105642.856210-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski commit 8b9993437429c66d11430ae61ffa5937a6abb4ae Author: Yoshihisa Yamamoto Date: Thu Sep 24 10:36:57 2026 +0000 net: pcs: rzn1-miic: Clear MIIC protection state before unprotect sequence On RZ/T2H and RZ/N1D MIIC, writing 0x0000 to the MIIC protection register clears the protection state machine. The initial protection state cannot be assumed to be constant, as it may be influenced by previous activity before the driver takes ownership of the hardware. Clear the protection state before issuing the unprotect sequence so that register access always starts from a known state, regardless of any previous activity. Fixes: 7dc54d3b8d91 ("net: pcs: add Renesas MII converter driver") Signed-off-by: Yoshihisa Yamamoto Reviewed-by: Lad Prabhakar Link: https://patch.msgid.link/TYCPR01MB74815955A10817B64BD6FB93A4812@TYCPR01MB7481.jpnprd01.prod.outlook.com Signed-off-by: Jakub Kicinski commit 38b7c470691dc28e5b42b45949cbc024cca3ac4e Merge: 2cf81fc9505b14 1221246d3bd08d Author: Jakub Kicinski Date: Tue Sep 29 17:11:34 2026 -0700 Merge branch 'fix-udp-splice-checksum-alignment-across-fragments' Alireza Asgari via says: ==================== Fix UDP splice checksum alignment across fragments When skb_splice_from_iter() appends several pipe fragments, it updates skb->len only after the loop. The software-checksum helper nevertheless uses that unchanged length as the checksum position for each fragment. An odd number of bytes already appended during the call therefore gives later fragments the wrong checksum alignment. A standalone reproducer primes a UDP socket with sendto(MSG_MORE), splices distinct pipe buffers, then uncorks the datagram. The send succeeds, but the receiver drops the packet and increments its checksum-error counter. Patch 1 passes the actual cumulative offset to the checksum helper without changing the final length update or partial-progress handling. Patch 2 adds a loopback selftest covering IPv4, IPv6, IPv4-mapped destinations, connected and unconnected sockets, prefixes and fragment boundaries. ==================== Link: https://patch.msgid.link/20260924-fix-udp-splice-checksum-v1-0-fe61d65447a8@asgari.net Signed-off-by: Jakub Kicinski commit 1221246d3bd08d8b5228777e1a9b3361ca946e64 Author: Alireza Asgari Date: Thu Sep 24 13:00:25 2026 +0000 selftests: net: cover UDP splice checksum fragment alignment Exercise software UDP checksums when splice() transfers multiple pipe fragments into a corked datagram. Use separate source pipes so short writes cannot merge, and use odd fragment lengths to expose checksum-position errors between fragments. Cover IPv4, IPv6 and IPv4-mapped destinations, connected and unconnected sockets, resident prefixes, even and odd fragment lengths, and a fragment starting near a page boundary. Ordinary sends provide a control. Check the complete payload and reject extra datagrams after a successful send. Keep receive waits bounded and skip unavailable address families or pipe capacities. The test uses only loopback sockets with ephemeral ports and has no dependency on the application that exposed the regression. Signed-off-by: Alireza Asgari Link: https://patch.msgid.link/20260924-fix-udp-splice-checksum-v1-2-fe61d65447a8@asgari.net Signed-off-by: Jakub Kicinski commit febec6a7076499d16b37f556724a942633a270a6 Author: Alireza Asgari Date: Thu Sep 24 13:00:24 2026 +0000 net: fix checksum offsets in skb_splice_from_iter() skb_splice_from_iter() appends multiple page fragments before updating skb->len. However, skb_splice_csum_page() uses that unchanged length as the offset for every fragment checksum. If bytes already appended during the call have an odd total length, a later fragment's checksum is combined with the wrong parity. For example, prime a UDP socket with sendto(MSG_MORE) and splice two distinct pipe buffers containing "abc" and "DEFGH". Uncorking reports success, but the receiver discards the packet for a bad checksum. This also affects IPv6 and fragments beginning near a page boundary. Pass the initial skb length plus the bytes already spliced to the checksum helper. Keep the existing final length update and partial-progress error handling unchanged. CHECKSUM_PARTIAL does not use this helper and remains unaffected. Fixes: 2e910b95329c ("net: Add a function to splice pages into an skbuff for MSG_SPLICE_PAGES") Cc: stable@vger.kernel.org Signed-off-by: Alireza Asgari Link: https://patch.msgid.link/20260924-fix-udp-splice-checksum-v1-1-fe61d65447a8@asgari.net Signed-off-by: Jakub Kicinski commit e0a6249190402a28f1e2925a81acf573157d55ef Author: Masami Hiramatsu (Google) Date: Tue Sep 29 09:19:12 2026 +0900 fprobe: Use guard(rcu_sched_notrace) and check rcu_is_watching() unregister_fprobe() and unregister_fprobe_async() (used by BPF kprobe-multi) rely on standard RCU grace periods (synchronize_rcu() and call_rcu()) to wait until in-flight fprobe handlers complete before freeing the fprobe. However, if an fprobe handler executes while RCU is not watching (such as in the idle loop or nohz_full extended quiescent states), standard RCU does not track preemption-disabled sections. Consequently, synchronize_rcu() does not wait for those executions, which can lead to a use-after-free if the fprobe is freed immediately after unregistration. Ensure handlers exit early when !rcu_is_watching(). Furthermore, fprobe_fgraph_entry() and fprobe_ftrace_entry() previously used guard(rcu)() and rcu_read_lock(), which invoke lockdep on every hit under CONFIG_PROVE_LOCKING. This adds overhead and can cause lockdep recursion if probed functions interact with lockdep. Since rhltable_lookup() and rhl_for_each_entry_rcu() use rcu_dereference_all_check() (which checks rcu_read_lock_any_held()), holding preemption disabled via rcu_read_lock_sched_notrace() is fully valid and sufficient so long as rcu_is_watching() is true. Define and use guard(rcu_sched_notrace)() across fprobe_ftrace_entry(), fprobe_fgraph_entry(), and fprobe_return(). This eliminates fast-path rcu_read_lock() and lockdep overhead while guaranteeing safe grace period synchronization. Link: https://lore.kernel.org/all/179064115227.394389.16910234241400391996.stgit@devnote2/ Reported-by: Sashiko Closes: https://sashiko.dev/#/bug/linux-e46bcd68-4a56-4f19-a255-e3772980e5e3 Fixes: 657b594b2084 ("fprobe: Fix unregister_fprobe() to wait for RCU grace period") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Paul E. McKenney commit 2cf81fc9505b148b1b70068303ea6ea4b1212403 Author: Ilkka Lappeteläinen Date: Fri Sep 25 15:48:29 2026 +0300 net/packet: prevent TX_RING byte count overflow tpacket_snd() drains every SEND_REQUEST frame in a TX ring and adds each valid packet length to the signed int len_sum. Userspace can recycle completed frames concurrently, so a single blocking send call is not bounded by the ring size. After enough successful transmissions len_sum wraps into the negative range. In particular, 65536 65535-byte frames followed by a 65007-byte frame produce 0xfffffdef, or -EIOCBQUEUED. sock_sendmsg_nosec() treats that as an impossible return and triggers a BUG. On systems configured to panic on oops, a CAP_NET_RAW holder can panic the host kernel. Stop before the next frame would make the byte count exceed INT_MAX. The positive short count leaves that frame pending for a later send call. A two-thread TPACKET_V2 reproducer triggered the BUG on an arm64 build of Linux 7.3-rc4. With this change, the same reproducer returned the expected positive short count without an oops. Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap") Cc: stable@vger.kernel.org Signed-off-by: Ilkka Lappeteläinen Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260925124829.6595-1-ilkka.lappetelainen@gmail.com Signed-off-by: Jakub Kicinski commit 226154ea87952ad7141ce2dcf52a6c2edd71b8fe Author: Mohamad Raizudeen Date: Sat Sep 26 20:29:03 2026 +0530 crypto: x86/aes-gcm - fix always true check for last AAD segment In gcm_process_assoc(), a segment that is not the last one must have its length rounded down to a multiple of 16 bytes, as required by the assembly. The check for a non-last segment is `if (unlikely(assoclen)) /* Not the last segment yet? */` where assoclen is the number of AAD bytes remaining after the current segment. Since the conversion to the new scatterwalk API, assoclen is decremented at the end of the loop body rather than the beginning, so it still includes the current segment when the check executes, making the check always true. As a result the last segment was rounded down as well, causing some avoidable extra work: an additional memcpy into the temporary buffer and an additional call into the assembly after the loop. The GCM authentication tag is unaffected either way, so the self-tests pass and this went unnoticed. It is purely an efficiency issue rather than a correctness one. Fix this by moving the assoclen decrement back to the beginning of the loop body. Fixes: e9787deff49e ("crypto: x86/aes-gcm - use the new scatterwalk functions") Cc: stable@vger.kernel.org Suggested-by: Eric Biggers Signed-off-by: Mohamad Raizudeen Link: https://patch.msgid.link/20260926145903.6061-1-raizudeen.kerneldev@gmail.com Signed-off-by: Eric Biggers commit 28fa9af353bed2bb738c46e31f9b7d0347b759d1 Author: Karl Mehltretter Date: Sat Sep 19 16:40:27 2026 +0200 hrtimer: Use the mask to clear TIF_HRTIMER_REARM from the exit work hrtimer_rearm_deferred_user_irq() removes the rearm bit from the local copy of the TIF work with: *tif_work &= ~TIF_HRTIMER_REARM; TIF_HRTIMER_REARM is the bit number (12), not the mask. That clears TIF_NOTIFY_SIGNAL (bit 2) and TIF_MEMDIE (bit 3) from the copy and leaves bit 12 set. So the function never returns true, and the copy handed to exit_to_user_mode_loop() lacks TIF_NOTIFY_SIGNAL. If that was the only work for the loop, the task returns to user space with the task work still pending. hrtimer_interrupt() sets TIF_HRTIMER_REARM every time, so the next tick repeats that. Task work queued with TWA_SIGNAL from a hrtimer callback stays pending until the task does a syscall, takes an interrupt without deferred rearm or has to reschedule. A task which polls the io_uring completion ring in user space sees a timeout completion after 30ms (median) instead of 70us. 2 CPU QEMU guest, HZ=1000. Use the mask. Fixes: 15dd3a948855 ("hrtimer: Push reprogramming timers into the interrupt return path") Signed-off-by: Karl Mehltretter Signed-off-by: Thomas Gleixner Assisted-by: LLM Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260919144027.70250-1-kmehltretter@gmail.com commit a243ede718463c7b481878656f1ff32a0ce0fd54 Merge: b004c4b1c4180f 1c1a342aceec79 Author: Linus Torvalds Date: Tue Sep 29 13:45:18 2026 -0700 Merge tag 'mtd/fixes-for-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD fixes from Miquel Raynal: "The most important set of fixes are around the handling of the QE bit in SPI NAND. There are also a couple of behavioral fixes (mutex issue in SPI-NOR, spurious bitflips on vf610_nfc, OOB bytes count in SPI NAND and cfi_cmdset stack usage). The rest is mostly AI fuzzing results" * tag 'mtd/fixes-for-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: spinand: Do not update the QE bit on devices without one mtd: spi-nor: core: Fix mutex leak in spi_nor_rww_start_exclusive() mtd: rawnand: cadence: Initialize IRQ state before requesting IRQ mtd: rawnand: vf610_nfc: fix false bitflips on reads of erased pages mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of OOB mtd: spinand: fix zero oobavail when no ECC engine is used mtd: spinand: fix NULL pointer dereference with no ECC engine mtd: mtd_intel_dg: reset poll counter for each erase mtd: cfi_cmdset_0001: shrink do_write_buffer() stack frame mtd: core: call _get_device() with the master MTD mtd: core: avoid double-free of OTP NVMEM device mtd: spinand: Enable QE on all dies mtd: block2mtd: Fix divide error when erase_size is zero commit 015fb29a748342a186f37b602ac70017098c8251 Author: Surendran Kanagaraj Date: Fri Sep 18 00:07:31 2026 +0000 tpm: Disable TPM on null key name mismatch The null key name check exists to protect against TPM reset attacks, so a mismatch should stop the device from serving further requests. Currently it does not disable the chip when it finds a mismatch. The mismatch is logged: tpm tpm0: null key integrity check failed but the chip keeps serving commands: / # tpm2_getcap -c properties-fixed TPM_PT_FAMILY_INDICATOR: as UINT32: 0x08322e3000 as string: "2.0" ... tpm2_load_null() where the null key name check is run sets the chip as disabled only if the rc is non zero. When the mismatch is seen, rc is zero at that point and it returns success. The other issue is that the caller expects the null key handle to be populated when the function returns 0 which it does here without writing the handle and proceeds assuming the null key handle is valid. During the test, I noticed that tpm2_start_auth_session() uses the uninitialized stack value as the key handle since tpm2_load_null() returns 0 despite the integrity failure and proceeds with TPM2_CC_START_AUTH_SESS with this value as salt key handle. Set rc to -ENODEV on the mismatch. The error path then disables the chip and returns the correct code to the caller. Tested in QEMU with swtpm and CONFIG_TCG_TPM2_HMAC=y by making TPM2_CC_CONTEXT_LOAD fail with TPM2_RC_INTEGRITY and changing the name of the re-created null key. The chip is now disabled on the mismatch. Fixes: cc7d8594342a ("tpm: Rollback tpm2_load_null()") Fixes: 423893fcbe7e ("tpm: Disable TPM on tpm2_create_primary() failure") Cc: stable@vger.kernel.org # v6.12+ Assisted-by: LLM Signed-off-by: Surendran Kanagaraj Link: https://lore.kernel.org/r/20260918000731.48657-1-surenkj@amazon.com Reviewed-by: Gunnar Kudrjavets Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 9b522400bf5c082feb9a0037a053ea822a2c7e4d Author: Jiangshan Yi Date: Thu Sep 3 11:58:37 2026 +0800 tpm: fix off-by-four bounds check in tpm2_get_random() When the response carries the TPM2_ST_SESSIONS tag, tpm2_get_random() skips the 4-byte parameter size field before locating the random data, but the bounds check still validates the response length against TPM_HEADER_SIZE. A truncated response can pass the check and make memcpy() read up to 4 bytes past the response end, so stale buffer contents end up in the caller's random bytes. Fix this by checking the response length against 'offset', which already includes the skipped parameter size field. Cc: stable@vger.kernel.org # v6.12+ Fixes: 1b6d7f9eb150 ("tpm: add session encryption protection to tpm2_get_random()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260902074839.417419-1-yijiangshan%40kylinos.cn Signed-off-by: Jiangshan Yi Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260903035837.219284-1-yijiangshan@kylinos.cn Signed-off-by: Jarkko Sakkinen commit 1e2f9a611b334ce6ed1dc4a9e1587c7a11d2be30 Author: Jiangshan Yi Date: Wed Sep 2 15:48:39 2026 +0800 tpm: Fix auth session leak in tpm2_get_random() error path When tpm_buf_fill_hmac_session() fails in tpm2_get_random(), the error path returns without calling tpm2_end_auth_session(), leaking the auth session. All other error paths in the function handle this correctly. Fixes: 3d9e043dab0a ("tpm-buf: Memory-safe allocations") Cc: stable@vger.kernel.orga # v6.12+ Signed-off-by: Jiangshan Yi Link: https://lore.kernel.org/r/20260902074839.417419-1-yijiangshan@kylinos.cn Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 1a70f0b71826fb764e8490dda55bb1b853e0d1de Author: Jiangshan Yi Date: Tue Sep 1 17:30:49 2026 +0300 tpm: Fix heap buffer overflow in tpm_transmit_cmd() struct tpm_buf now uses an embedded flexible array for data, which is 6 bytes shorter than TPM_BUFSIZE due to the struct header. But tpm_transmit_cmd() still passes PAGE_SIZE to tpm_transmit(), and after clamping to TPM_BUFSIZE in tpm_try_transmit(), chip->ops->recv() can write past the end of data[] by 6 bytes. Pass buf->capacity to tpm_transmit() instead. Fixes: 3d9e043dab0a ("tpm-buf: Memory-safe allocations") Signed-off-by: Jiangshan Yi Link: https://lore.kernel.org/r/20260901062850.379870-1-yijiangshan@kylinos.cn Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 684b413b5483f57c890c171b9400076a0143b918 Author: Niklas Cassel Date: Fri Sep 18 16:06:42 2026 +0200 virtio_blk: set the zone write granularity virtblk_read_zoned_limits() reads the write granularity that the device reports in virtio_blk_zoned_characteristics and assigns it to the physical block size and to io_min, but never to the limit that is named after it. queue_limits.zone_write_granularity is left at zero, so blk_validate_zoned_limits() raises it to the logical block size: if (lim->zone_write_granularity < lim->logical_block_size) lim->zone_write_granularity = lim->logical_block_size; A device that reports a granularity coarser than its logical block size, which is what the field exists to express, therefore has it silently reduced. A 512e host managed disk passed through to a guest reports a logical block size of 512 and a write granularity of 4096, and the guest ends up with a zone write granularity of 512. bio_split_alignment() returns lim->zone_write_granularity if it is non-zero and bio_split_io_at() may split a bio with as per bio_split_alignment(). This can real to the write getting rejected by the host drive, as the write is not aligned to the physical block size. zonefs also takes its block size from bdev_zone_write_granularity(), so it would incorrectly use 512 on a disk that requires 4096. sd_zbc_read_zones() sets the limit from the physical block size for the same reason. NVMe ZNS and null_blk leave it unset, but the fallback gives the right answer for them, as their write granularity is the logical block size. virtio carries a separate value that may exceed it. Set the zone write granularity from the value that the device reports. Fixes: 95bfec41bd3d ("virtio-blk: add support for zoned block devices") Signed-off-by: Niklas Cassel Reviewed-by: Stefan Hajnoczi Link: https://patch.msgid.link/20260918140641.2031075-2-cassel@kernel.org Signed-off-by: Jens Axboe commit b004c4b1c4180fc7f2326de4ac941d5edfe16076 Merge: 6f8319e3e9a44d f050c3e61d2a1a Author: Linus Torvalds Date: Tue Sep 29 11:30:52 2026 -0700 Merge tag 'arc-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fix from Vineet Gupta - cmpxchg snafu spotted by Bradley and other misc fixes * tag 'arc-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: arch_cmpxchg_relaxed to use size of pointed type not pointer arc: kernel: Fix clk reference leak in show_cpuinfo() arc: remove unused profile.h includes ARC: cleanup dead ARC_CANT_LLSC option in Kconfig commit afb4334fb52c7b416bbc9c4b166f6806509f734b Author: Fuad Tabba Date: Tue Sep 29 10:00:31 2026 +0100 KVM: arm64: selftests: Check a feature hidden in an ID register is UNDEF Userspace can hide a feature from a guest by clearing its field in a writable ID register, and KVM then makes the feature's instructions UNDEFINED in the guest by trapping or disabling them. No selftest checks that. Add a test that runs the instruction of each of TLBI OS, MOPS, TCR2_EL1 and FPMR once with its field as advertised and once with it cleared, and expects an UNDEF only when cleared. A feature the vCPU doesn't advertise is skipped, as is hidden TLBI OS on a CPU with neither FGT nor FEAT_EVT2, where KVM can't trap it. Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260929090031.3829185-5-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 04447b95c62bef2b3591486c66244c49591a3dbd Author: Fuad Tabba Date: Tue Sep 29 10:00:30 2026 +0100 KVM: arm64: Use the host's HCR_EL2 for non-protected VMs in pKVM For each vCPU, pKVM's EL2 builds its own HCR_EL2 and takes only TWI, TWE and VSE from the host's value on each entry. For a non-protected VM it has fallen behind the host's: on a CPU with MTE the guest can read GMID_EL1, on one with FEAT_EVT2 but no FGT it can execute a TLBI OS its ID registers hide, an interrupt injected without a vGIC (VI, VF) never arrives, and set/way emulation loses the TVM trap it relies on. For a non-protected VM, also take the bits the host varies with the VM's configuration or at runtime: VI, VF, TVM, TID2, TID4, TID5 and TTLBOS. They only pend interrupts for, or add traps to, a VM the host controls. The traps exit to the host, which handles them as it does without pKVM. The bits that change what EL2 does on entry and exit (E2H, RW, API/APK) or depend only on the CPU (TEA, TERR, FWB) stay EL2's. A protected VM still takes only TWI, TWE and VSE. EL2 now sets TID2 or TID4 only for a protected VM, and never sets ATA, as the host rejects KVM_CAP_ARM_MTE in pKVM. Fixes: b56680de9c648 ("KVM: arm64: Initialize trap register values in hyp in pKVM") Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260929090031.3829185-4-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 80ae56184b57176b908cd6a7ececf274a7e4b3c7 Author: Fuad Tabba Date: Tue Sep 29 10:00:29 2026 +0100 KVM: arm64: Clear HCR_EL2.RW for 32-bit non-protected vCPUs pKVM keeps its own copy of each vCPU's HCR_EL2 at EL2, initialised with RW set unconditionally. Nothing stops userspace from creating a non-protected AArch32 VM, and with RW set, entering one of its vCPUs is an illegal exception return: KVM_RUN fails with KVM_EXIT_FAIL_ENTRY. Clear RW for a vCPU that is AArch32 at EL1, when the CPU has AArch32 EL1. On a CPU without it, RW stays set and the entry still fails, rather than EL2 switching *32_EL2 registers that are UNDEFINED there. The host already rejects such a vCPU, but EL2 takes the vCPU's features from the host and doesn't rely on that. Fixes: b56680de9c648 ("KVM: arm64: Initialize trap register values in hyp in pKVM") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260929090031.3829185-3-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 4bdd2b3a708c1feb701cb8b62feb8ad2fd77bb07 Author: Fuad Tabba Date: Tue Sep 29 10:00:28 2026 +0100 KVM: arm64: Apply the fine-grained UNDEFs without FEAT_FGT FGUs don't actually require hardware support, so don't gate fgt trap config insertion on FGT. This is the only action required to allow FGUs always, as kvm_calculate_traps() already computes the FGU bits with or without FEAT_FGT. This also fixes a spurious WARN when a TLBI OS is run on a guest in vEL1 without FEAT_TLBIOS on non FEAT_FGT hardware. In this configuration the course-grained HCR_EL2.TTLBOS trap reaches the handler handle_tlbi_el1(), which expects an EL1 TLBI only from vEL2. With FGUs enabled the UNDEF will be injected without needing the specific handler. Fixes: f5a5a406b4b8b ("KVM: arm64: Propagate and handle Fine-Grained UNDEF bits") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260929090031.3829185-2-fuad.tabba@linux.dev [oliver: Take Wei-Lin's suggested changelog] Signed-off-by: Oliver Upton commit 751f4641560be8568dcc5af400c0e55a283abf51 Author: Marc Zyngier Date: Tue Sep 29 10:35:47 2026 +0100 KVM: arm64: vgic-its: Fix MOVALL handling of source redistributor The MOVALL command moves the pending state of all LPIs targeting a given redistributor to another one. However, we seem to have lost the filtering on the source RD, which means we move all LPIs to the target. Not quite what the spec mandates. Hack update_affinity() to take an optional source vcpu that is used as a filter when non-NULL, restoring the filtering that was performed by vgic_copy_lpi_list() back in the days. Fixes: 11f4f8f3e6e06 ("KVM: arm64: vgic-its: Walk LPI xarray in vgic_its_cmd_handle_movall()") Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260929093548.3598547-7-maz@kernel.org Signed-off-by: Oliver Upton commit 19bc5d79ece613f242b5ec03921a3b465321bfed Author: Marc Zyngier Date: Tue Sep 29 10:35:45 2026 +0100 KVM: arm64: vgic: Take a refcount on IRQs referenced by last_lr_irq Referencing the last interrupt inserted in an LR is rather fragile, as this interrupt can vanish if a concurrently unmapped LPI. Solve this by bumping up the refcount on the interrupt when populating last_lr_irq, and drop it at vgic_prune_ap_list() time, when LPIs are being reclaimed. Fixes: 6da5e537f5afe ("KVM: arm64: vgic: Pick EOIcount deactivations from AP-list tail") Reported-by: Yuchao Zhang Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260929093548.3598547-5-maz@kernel.org Signed-off-by: Oliver Upton commit e079ef0b1c40c7a4a1be0c1ac5dbff95685c3beb Author: Marc Zyngier Date: Tue Sep 29 10:35:44 2026 +0100 KVM: arm64: vgic: Allow last_lr_irq to be NULL when LRs are not overflowing last_lr_irq is always populated when there is any interrupt populated in the AP list. Not only this is not necessary (it is only useful when we completely fill the LRs), but this is in the way of further fixes. Make sure last_lr_irq is kept to NULL when we LRs are not completely full. Fixes: 6da5e537f5afe ("KVM: arm64: vgic: Pick EOIcount deactivations from AP-list tail") Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260929093548.3598547-4-maz@kernel.org Signed-off-by: Oliver Upton commit 86ef0f58bdecdedb3a1240971c56d71b7e4ce3fc Author: Iaroslav Voitovych Date: Thu Sep 24 19:11:58 2026 +0200 Bluetooth: MGMT: Fix status of pending commands flushed on power off 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 commit a154f7b9f197b3d5e41fa3ad62083f5aa93b1fe8 Author: Takashi Iwai Date: Tue Sep 29 16:41:26 2026 +0200 ALSA: usb-audio: Apply IGNORE_CTL_ERROR quirk to all Audient devices Faaris reported a problem with Audient EVO4 device and it turned out to be a regression by the recent fix commit 87a6f2fa6e6c ("ALSA: usb-audio: Propagate write errors in generic mixer put callbacks"). It exhibited that the hardware gives errors at accessing the mixer unit 10 on certain channels, and the change above made it a fatal error. We had already a quirk for Audient iD14 to work around such errors from the mixer controls, and we can simply apply the same for EVO4. OTOH, it's highly possible that other Audient devices suffer from the same issue; they must be using similar firmware, after all. So, in this patch, we apply the quirk generically to all devices with the vendor ID Audient (2708), instead. Ignoring the control error isn't usually less critical than overreaction to the firmware misbehavior. Fixes: 87a6f2fa6e6c ("ALSA: usb-audio: Propagate write errors in generic mixer put callbacks") Reported-and-tested-by: Faaris Ansari Closes: https://lore.kernel.org/CANBVYRCL=8QdLxGg4S6qrahrFtwJxhv-aSGpW7-1S=+iOe4ZGA@mail.gmail.com Cc: Link: https://patch.msgid.link/20260929144132.1521617-1-tiwai@suse.de Signed-off-by: Takashi Iwai commit b5c4823cf3e49b3419a3bc8c6715101e1ac6cc59 Author: Takashi Iwai Date: Tue Sep 29 14:29:25 2026 +0200 ALSA: usb-audio: Apply boot quirk for Behringer models generically Jan reported that a few Behringer devices became broken since the recent optimization to avoid usb_string() call at probe time at the commit b364a0d23cae ("ALSA: usb-audio: Use strings in struct usb_dev for manufacturer & co"). Interestingly, the devices seem requiring the explicit descriptor read at probing time, and the optimization above dropped it. There is already a boot quirk for another model, Behringer CM1A (1397:1234), that adds a device descriptor read, and this seems working for them, too. As the quirk is safe and cheap, just apply the same boot quirk to all Behringer devices for avoiding the pitfall again. Fixes: b364a0d23cae ("ALSA: usb-audio: Use strings in struct usb_dev for manufacturer & co") Reported-by: Jan Lentfer Closes: https://lore.kernel.org/e7087d42-5e74-4d85-b1c5-b11eff235d41@web.de Link: https://patch.msgid.link/20260929122938.1471867-1-tiwai@suse.de Signed-off-by: Takashi Iwai commit 1465494e8d07426fa41c0021530cccb2a1ac38fa Author: Sai Teja Aluvala Date: Tue Sep 29 11:42:33 2026 +0530 Bluetooth: btintel_pcie: Add shared HW reset for clean start 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 commit ac022970e9fb0a5f7e7d1f6c8e104c1ed924dd1c Author: Mikhail Gavrilov Date: Tue Sep 29 17:22:26 2026 +0500 Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex An RFCOMM connect() issued while a BR/EDR link is being authenticated makes lockdep report a circular dependency, and the reported cycle is a real AB/BA between rfcomm_mutex and hdev->lock. rfcomm_security_cfm() is called from the HCI event path, which already holds hdev->lock: hci_rx_work() hci_event_packet() hci_cc_read_enc_key_size() [hdev->lock] hci_encrypt_cfm() [hci_cb_list_lock] rfcomm_security_cfm() [rfcomm_mutex] while an RFCOMM connect() from userspace takes the same two locks the other way round: rfcomm_sock_connect() rfcomm_dlc_open() [rfcomm_mutex] __rfcomm_dlc_open() rfcomm_session_create() kernel_connect() l2cap_sock_connect() l2cap_chan_connect() [hdev->lock] WARNING: possible circular locking dependency detected kworker/u131:1/1128 is trying to acquire lock: rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm] but task is already holding lock: hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0 Chain exists of: rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock hci_auth_complete_evt() and hci_encrypt_change_evt() reach the callback the same way. Both orders have to be seen in the same boot, which is why a BR/EDR connection alone is not enough to show it: a session set up by the remote side is created by rfcomm_accept_connection() in krfcommd, which calls kernel_accept() and never takes hdev->lock under rfcomm_mutex. Connecting a device that authenticates and encrypts the link and then calling connect() on an RFCOMM socket towards any address - the connect does not have to succeed, the order is recorded before the page timeout - reports it every time. Only the session socket has to be connected with the lock held, and it does not: nothing else can see the socket before it is put on the session list. So connect it first and take rfcomm_mutex afterwards, which removes the rfcomm_mutex -> hdev->lock order for good, rather than keeping the HCI event path out of rfcomm_mutex. rfcomm_session_create() becomes rfcomm_session_connect(), which returns the connected socket without touching the session list, and rfcomm_dlc_open() adds the session once it holds the lock again. If another opener added a session for the same pair while this socket was connecting, that session is used and this socket is dropped. __rfcomm_dlc_open() now takes the session it should use, and its state check runs after the lock is re-acquired, so a DLC that was opened or closed in the meantime is still handled. Over an existing ACL link the connection can complete before the session reaches the list, and the wakeup from the socket callback is then lost, so krfcommd is woken once the session is visible. Connecting without the lock opens a window in which the socket can be closed. The DLC is not on a session yet, so rfcomm_dlc_close() finds nothing to do and returns without touching it, and rfcomm_dlc_open() would then attach a DLC whose owner is gone. rfcomm_dlc_close() now marks such a DLC with RFCOMM_CLOSED, and rfcomm_dlc_open() checks the mark once it holds rfcomm_mutex again and drops the socket instead of attaching the DLC. The mark is cleared when an open starts, so a DLC that is reused is not affected. This covers both callers of rfcomm_dlc_open(), the socket and the tty layer. Fixes: 759c185d0bbd ("Bluetooth: RFCOMM: serialize security confirmation handling") Suggested-by: Pauli Virtanen Reported-by: Pauli Virtanen Closes: https://lore.kernel.org/linux-bluetooth/5e76a95e934e451e7006db28827c2d64af5a88be.camel@iki.fi/ Reported-by: syzbot+74071deb72339c215b2e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-bluetooth/6a92fadc.08e933ee.dbf97.008f.GAE@google.com/ Reported-by: Jiaming Zhang Closes: https://lore.kernel.org/all/CANypQFabseTuRiyz2pGkc_Qj0moGDnY7KEp1qdTOqkw6gAL3hw@mail.gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Mikhail Gavrilov Tested-by: syzbot+74071deb72339c215b2e@syzkaller.appspotmail.com Signed-off-by: Luiz Augusto von Dentz commit baa53af641c9e3644e717b8dfd1b95a55a0c111b Author: Ravindra Date: Tue Sep 29 12:26:41 2026 +0530 Bluetooth: btintel_pcie: fix TX descriptor bounds check 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 commit 540f55de8c9f79c83f13e44910955faf82b0d79c Merge: 137d6ccf0ec8c4 2cc67425a97eea Author: Greg Kroah-Hartman Date: Tue Sep 29 15:16:34 2026 +0200 Merge tag 'icc-7.3-rc5' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-linus Georgi writes: interconnect fix for v7.3-rc This contains a revert that resolves a boot failure and instability on some Snapdragon X Elite machines (based on Hamoa and Purwa). - Revert "interconnect: qcom: x1e80100: enable QoS configuration" Signed-off-by: Georgi Djakov * tag 'icc-7.3-rc5' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/djakov/icc: Revert "interconnect: qcom: x1e80100: enable QoS configuration" commit b2047b8cadadccb1c9269ce756c399cd9aef2c82 Author: Liviu Nicoara Date: Tue Sep 29 07:57:55 2026 -0400 ASoC: codecs: lpass-wsa-macro: rewrite the interpolator volume after enabling clocks Commit 902f497a1ff5 ("ASoC: codecs: lpass-wsa-macro: remove useless gain read/write sequence") removed the read and write of the digital volume register in wsa_macro_enable_interpolator(), on the grounds that writing back the value just read does nothing. The comment above it, "apply gain after int clk is enabled", was left in place. On the Dell XPS 13 9345 (X1E80100, four WSA8845 amplifiers on two WSA macros) the write does something: a volume change made while the path is idle does not take effect when playback starts. Lowering the digital volume from 81 to 63 with nothing playing, then playing a test tone, gave about the same level as before the change. With the rewrite restored, lowering it from 81 to 69 while idle played audibly quieter, and restoring 81 while idle brought the level back. Changes made during playback take effect with or without the rewrite. The register already holds the new value when this happens. Without the rewrite, after an idle change from 69 to 81, playback stayed at the old level while the register, read from the hardware through /dev/mem, held the new one (0xfd). Writing that same value back through /dev/mem brought the level up at once. This is the behaviour described in commit 46188db080bd ("ASoC: codecs: lpass-wsa-macro: fix compander volume hack"): "the volume registers still need to be written after enabling clocks in order for any prior updates to take effect." The value read comes from the register cache, so the write pushes the last requested volume to the hardware once its clock runs. Restore the rewrite in the interpolator's POST_PMU event only. The mix path event removed later in the same series is not brought back. Fixes: 902f497a1ff5 ("ASoC: codecs: lpass-wsa-macro: remove useless gain read/write sequence") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Liviu Nicoara Reviewed-by: Johan Hovold Link: https://patch.msgid.link/20260929115755.6096-1-lnicoara@thinkoid.org Signed-off-by: Mark Brown commit a92193c91e8839fe5fc209616ea95465ae4b919d Author: Jens Axboe Date: Tue Sep 29 06:52:17 2026 -0600 io_uring: fix task_work add use-after-free with SQPOLL For SQPOLL, the sqpoll thread runs task_work off its own list and doesn't need to be told about it, so it can pop and complete a request as soon as mpscq_push() has published it. If that was the last request holding the ring alive, io_ring_exit_work() then frees the ctx, stops the thread, and with it the tctx, while io_req_normal_work_add() is still looking at both after the push: BUG: KASAN: slab-use-after-free in io_req_normal_work_add+0x439/0x510 Read of size 4 at addr ff11000000ca0000 by task repro/55 (...) BUG: KASAN: slab-use-after-free in queue_work_on+0x25/0x70 Write of size 8 at addr ff11000000c3bd00 by task repro/55 Hold an RCU read lock across the add, like io_req_local_work_add() already does, and have io_ring_exit_work() wait for a grace period for SQPOLL rings as well before freeing the ctx. Reported-by: Jérémy Jean Link: https://lore.kernel.org/io-uring/20260924205056.3759980-2-Jeremy.Jean@oss.cyber.gouv.fr/ Fixes: af5d68f8892f ("io_uring/sqpoll: manage task_work privately") Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe commit aa0a37b5024d921e96ac4f8f487c8bfbf1f1a582 Author: Raj Ojha Date: Fri Sep 25 00:59:55 2026 +0530 memstick: core: wait for request completion before freeing card 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 commit 54518e0e827f4ca9229ae657022c60bf60f5c1bf Author: Jamal Hadi Salim Date: Sat Sep 26 14:03:28 2026 -0400 net/sched: sch_codel: match the no-drop threshold to the packet size commit 6439461f1618 ("net/sched: sch_codel: clamp default mtu to avoid disabling CoDel") clamped q->params.mtu to [256, 1 << 20]. The value is the CoDel no-drop threshold (codel_impl.h "*backlog <= params->mtu"), so on a link whose maximum transmitted packet size is below 256 the floor extends CoDel's minimum-backlog exemption beyond one packet and delays drop or mark eligibility by several small packets. Keep the upper bound that guards the original overflow (psched_mtu() wrapping to ~2 GiB on a huge-MTU device) but drop the 256 floor, so the threshold tracks the real device packet size. Conditions to recreate the bug: attach a codel qdisc on a link whose MTU plus hard_header_len is below 256 (e.g. a CAN interface). At that MTU the no-drop threshold must equal the device MTU plus its hard-header length; before this patch it was forced to 256. Requires CAP_NET_ADMIN in a user namespace. Fixes: 6439461f1618 ("net/sched: sch_codel: clamp default mtu to avoid disabling CoDel") Reported-by: Sashiko (nipa) Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260819143136.57350-1-jhs@mojatatu.com Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-34MS.v1.20260925165535@mojatatu.com.2 Signed-off-by: Paolo Abeni commit d031465acc362866f27e4f8f79cfecf1037fe2e5 Author: Jamal Hadi Salim Date: Sat Sep 26 14:03:27 2026 -0400 net/sched: fq_codel: match the no-drop threshold to the packet size commit d9ebd8f9aa8b ("net/sched: fq_codel: clamp default quantum and mtu") clamped both q->quantum and q->cparams.mtu to [256, FQ_CODEL_QUANTUM_MAX]. The two fields mean different things: quantum is a DRR credit that wants the 256 floor, but cparams.mtu is the CoDel no-drop threshold (codel_impl.h "*backlog <= params->mtu"). On a link whose maximum transmitted packet size is below 256, the floor extends CoDel's minimum-backlog exemption beyond one packet and delays drop or mark eligibility by several small packets. Split the clamp. quantum keeps [256, FQ_CODEL_QUANTUM_MAX]; cparams.mtu tracks psched_mtu() (the device MTU plus its hard-header length) with only the upper bound that guards the original overflow (psched_mtu() wrapping to ~2 GiB on a huge-MTU device). Conditions to recreate the bug: attach an fq_codel qdisc on a link whose MTU plus hard_header_len is below 256 (e.g. a CAN interface). At that MTU the no-drop threshold must equal the device MTU plus its hard-header length; before this patch it was forced to 256. Basic Testing done: with dev->mtu=100 and hard_header_len=14, a return probe on fq_codel_init() observed cparams.mtu change from 256 to 114 Fixes: d9ebd8f9aa8b ("net/sched: fq_codel: clamp default quantum and mtu") Reported-by: Sashiko (nipa) Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260819143136.57350-1-jhs@mojatatu.com Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-34MS.v1.20260925165535@mojatatu.com Signed-off-by: Paolo Abeni commit 0923198be4ae714b46350f742cb19ccd75bfeafa Author: Sagar Taunk Date: Fri Sep 25 08:55:04 2026 +0000 rust: net: netlink: validate attribute length before casting to `c_int` `put()` trusted an unchecked `as` cast from `usize` to `c_int`. When the length exceeds `i32::MAX` that cast wraps around to a negative value. This ultimately resulted in a kernel panic when the reinterpreted value via `__nla_reserve()` and `skb_put()` became enormous. Validate payload and header both fit together in a `u16`, rejecting any payload that wouldn't leave room for `NLA_HDRLEN`. Fixes: 5eaa5fbb6e6c ("rust: netlink: add raw netlink abstraction") Reviewed-by: Alice Ryhl Reviewed-by: Alexandre Courbot Reviewed-by: Carlos Llamas Reviewed-by: Gary Guo Signed-off-by: Sagar Taunk Link: https://patch.msgid.link/20260925085449.22553-1-sagartaunk@proton.me Signed-off-by: Paolo Abeni commit f341dc4d934a69ffbe6c21e3609ee725790188f1 Author: Rafael J. Wysocki Date: Mon Sep 21 21:12:00 2026 +0200 cpufreq: intel_pstate: Fix max_freq fallback in cpufreq_update_pressure() After commit d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq"), cpufreq pressure appears in the CPU load balancer unexpectedly in some cases in which it was not present before, leading to confusion and uncertainty. Clearly, the scheduler assumes that cpufreq pressure will not be set unless the capacity reference frequency of the CPU is known, and the commit mentioned above violates that assumption. However, in some cases the capacity reference frequency of the CPU is in fact known even though arch_scale_freq_ref() returns 0 and in those cases it should be possible to set cpufreq pressure as appropriate. For this purpose, introduce a new cpufreq driver callback returning the CPU capacity reference frequency, .scale_freq_ref(), and make cpufreq_update_pressure() invoke it, if present, instead of falling back to cpuinfo.max_freq unconditionally. Add that callback to the intel_pstate driver and make it return 0 unless the scale-invariant capacity of the given CPU has been explicitly set, in which cases its reference frequency is always cpuinfo.max_freq. Fixes: d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq") Reported-by: Jianyong Wu Closes: https://lore.kernel.org/linux-pm/20260915065747.1671965-1-wujianyong@hygon.cn/ Tested-by: Jianyong Wu Signed-off-by: Rafael J. Wysocki Tested-by: Ricardo Neri # Intel hybrid parts Tested-by: Chen Yu [ rjw: Add READ_ONCE() around a capacity_perf read ] Link: https://patch.msgid.link/12975163.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki commit f8932b2c0c9ae6fb577bcc05a2080c8498f91c0d Author: Hannu Varjoranta Date: Fri Sep 25 14:52:37 2026 +0300 gve: DQO: accept TSO packets with non-protocol gso_type bits Since commit 014c607f86ab ("gve: add support for UDP GSO for DQO format"), gve_prep_tso() matches shinfo->gso_type exactly. gso_type is a bitmask, though: SKB_GSO_DODGY is set on every GSO packet that comes from tun/tap, packet sockets or other untrusted sources, and SKB_GSO_TCP_ECN and SKB_GSO_TCP_FIXEDID can be set as well. Such packets hit the default case, gve_tx_add_skb_dqo() fails and gve_try_tx_skb() drops them, counting them in tx_dropped. These packets do reach the driver: tcp_gso_segment() passes DODGY skbs through unsegmented to devices that support TSO, after recomputing gso_segs, so drivers must tolerate the bit. This breaks virtual machines behind a tap on GCE instances using the DQO queue formats. Every TSO packet forwarded from a guest (gso_type SKB_GSO_TCPV4 | SKB_GSO_DODGY) is dropped, and guest uploads slow to a crawl of retransmissions or stall entirely, while the host's own TSO traffic (gso_type SKB_GSO_TCPV4) is unaffected. On an n4 instance (DQO-QPL) with a Cloud Hypervisor guest, a 64 MB upload from the guest went from a 60 s timeout at ~0.9 MB/s to 0.19 s with this change, with tx_dropped no longer increasing. Host TCP with ECN is hit as well: gve advertises NETIF_F_TSO_ECN, so a TSO packet carrying CWR has SKB_GSO_TCP_ECN set and is dropped too. Restore the bitmask test that commit 1b9f75634441 ("gve: ignore nonrelevant GSO type bits when processing TSO headers") introduced for the same problem, keeping the UDP GSO support. While here, reload shinfo after skb_cow_head(). If the head was cloned, pskb_expand_head() moves skb_shared_info to the new head, and the pointer cached at function entry can then refer to memory that another clone frees. Fixes: 014c607f86ab ("gve: add support for UDP GSO for DQO format") Signed-off-by: Hannu Varjoranta Reviewed-by: Eric Dumazet Reviewed-by: Ankit Garg Reviewed-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260925115237.56465-1-hannu@varjosoft.com Signed-off-by: Paolo Abeni commit 006c8b834aed8b02bd8fb9fb05e9e7ead37d1763 Author: Zihan Xi Date: Thu Sep 24 05:15:21 2026 +0000 net: gso: limit recursive IP-in-IP segmentation IP-in-IP GSO can re-enter inet_gso_segment() or ipv6_gso_segment() for each nested IP header. encap_level tracks header bytes, not callback depth, so a deep chain can exhaust the kernel stack. Making inet_gso_segment() stackable introduced unbounded IPv4 nesting; IPIP GSO/TSO later made the path reachable. The IPv6 stackable path was introduced separately and uses the same guard. Count IPv4 and IPv6 GSO handler entries in skb_gso_cb, initialized once per top-level GSO operation and preserved across GRE/UDP context changes. Use the existing IP_TUNNEL_RECURSION_LIMIT for both handlers. The first five entries pass, and the sixth returns -EINVAL before dispatching another GSO callback. Fixes: 3347c9602955 ("ipv4: gso: make inet_gso_segment() stackable") Cc: stable@vger.kernel.org Reported-by: Vega Closes: https://lore.kernel.org/all/cover.1790157745.git.zihanx@nebusec.ai/ Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260924051521.32568-2-zihanx@nebusec.ai Signed-off-by: Paolo Abeni commit 0eee030c2c09c7a44be778de5f451d9e7a2f09c1 Author: Muhtasham Nawr al-Mahmud Date: Thu Sep 24 20:45:12 2026 +0600 ALSA: hda/realtek: Fix speakers on ASUS PM3406CHA The ASUS ExpertBook PM3406CHA uses an ALC256 codec with subsystem ID 1043:1664. On Linux boot, the internal speakers are silent even though playback is routed to the codec and the speaker pin is configured for output. The codec starts with coefficient 0x10 set to 0x1d20. Writing 0x7f20 to coefficient 0x10 immediately restores internal speaker output. This was reproduced on the affected hardware from a fresh boot using hda-verb. Reducing a larger initialization sequence showed that this coefficient write alone is sufficient; no GPIO, EAPD, pin-control, or other coefficient changes are required. After applying the coefficient in userspace, speaker output also remains functional across suspend and resume. Add a machine-specific HDA fixup that writes the required coefficient. The fixup has been compile-tested, but could not be boot-tested because the affected hardware is no longer available. Closes: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/2162718 Signed-off-by: Muhtasham Nawr al-Mahmud Link: https://patch.msgid.link/20260924144512.3989-1-muhtaseem2005@gmail.com Signed-off-by: Takashi Iwai commit 763183f76d6bc093fa603377862d6739cb7ccad6 Author: Zhang Heng Date: Tue Sep 29 17:11:09 2026 +0800 ALSA: hda/realtek: Add quirk for HP Pavilion AiO 24 speaker Add ALC225_FIXUP_HP_AIO_SPK to enable the internal speaker on HP Pavilion AiO 24 (103c:85ba). Link: https://bugzilla.kernel.org/show_bug.cgi?id=221691 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260929091109.400313-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai commit 0f17d2e3dd9cda3ee6d94033d5e5489af168920d Author: Xuanqiang Luo Date: Thu Sep 24 13:52:52 2026 +0800 pfcp: fix socket lifetime on netdevice registration failure pfcp_newlink() creates the UDP socket before register_netdevice(). If registration fails after pfcp_dev_init() succeeds, the core calls pfcp_dev_uninit(), which releases the socket and clears pfcp->sk. The newlink error path then releases it again, causing a NULL pointer dereference. This was observed with failslab fault injection: FAULT_INJECTION: forcing a failure. kobject: kobject_add_internal failed for pfcp0 (error: -12 parent: net) BUG: KASAN: null-ptr-deref in udp_tunnel_sock_release+0x1c/0x50 Read of size 8 at addr 0000000000000120 by task ip/1037 Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x468/0x5cc kasan_report+0xa4/0xf0 __asan_load8+0x7c/0xd0 udp_tunnel_sock_release+0x1c/0x50 pfcp_newlink+0x128/0x184 rtnl_newlink+0x848/0xe44 rtnetlink_rcv_msg+0x468/0x514 netlink_rcv_skb+0xc0/0x1f0 rtnetlink_rcv+0x18/0x24 netlink_unicast+0x4b8/0x558 netlink_sendmsg+0x2b8/0x584 ... Return from pfcp_del_sock() if pfcp->sk is NULL. Fixes: 76c8764ef36a5 ("pfcp: add PFCP module") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260924055252.33488-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni commit fdd6553e1e53b0421d89c7469c8a36d2eadb1115 Author: Zhan Xusheng Date: Mon Sep 28 10:02:05 2026 +0800 time/jiffies: Saturate in mult_hz() instead of wrapping Return ULONG_MAX for values that don't fit an unsigned long. proc_int_u2k_conv_uop() now correctly rejects a result above INT_MAX. This is the erroneous behaviour that is being fixed. The input has to exceed ULONG_MAX / HZ for the product to wrap, so the value below is specific to CONFIG_HZ=1000: # echo 18446744073709552 > /proc/sys/net/ipv4/tcp_keepalive_time # cat /proc/sys/net/ipv4/tcp_keepalive_time 0 That value is now rejected with an error. The original bound ("*u_ptr > INT_MAX / HZ") was removed in commit 2dc164a48e6f ("sysctl: Create converter functions with two new macros"). Fixes: 2dc164a48e6f ("sysctl: Create converter functions with two new macros") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Signed-off-by: Joel Granados commit e955f14fa8467d70aaeea5830b4d1773d5b25500 Author: Zhan Xusheng Date: Mon Sep 28 10:02:04 2026 +0800 sysctl: Negate before converting in the int read path proc_int_k2u_conv_kop() reports the sign through *negp and the magnitude through *u_ptr, but for a negative value it hands the sign-extended int to the converter and negates the result: *u_ptr = k_ptr_op ? -k_ptr_op((ulong)val) : -(ulong)val; With div_hz() and CONFIG_HZ=1000 a stored -1000 becomes (ulong)-1000 / 1000 == 18446744073709550, and negating that wraps: # echo -1 > /proc/sys/net/ipv4/tcp_fin_timeout # cat /proc/sys/net/ipv4/tcp_fin_timeout -18428297329635842066 The magnitude is HZ dependent but the wrap is not: the negation happens after the division at every CONFIG_HZ. Take the magnitude first and convert that, which is what the open-coded version did before commit 2dc164a48e6f ("sysctl: Create converter functions with two new macros") folded it into a macro. The k_ptr_op == NULL branch was already correct. All three int converters that pass a k_ptr_op are affected: proc_dointvec_jiffies(), proc_dointvec_userhz_jiffies() and proc_dointvec_ms_jiffies(). Fixes: 2dc164a48e6f ("sysctl: Create converter functions with two new macros") Cc: stable@vger.kernel.org Reviewed-by: Bradley Morgan Signed-off-by: Zhan Xusheng Signed-off-by: Joel Granados commit 564b7e8e09ec9b47921dc11de0de05da358335d9 Merge: ab39974240a0cf d5288c519bbd0d Author: Alexei Starovoitov Date: Tue Sep 29 05:54:17 2026 +0000 Merge branch 'bpf-fix-use-after-free-of-progs-detached-from-busy-trampolines' Florent Revest says: ==================== bpf: Fix use-after-free of progs detached from busy trampolines A task running in a trampoline image can call a prog that was detached and freed in the meantime, when it slept in a sleepable prog before reaching the detached one or was preempted right before calling it. Patch 1 handles the preempted case with an RCU tasks grace period, patch 2 handles the sleeping case by patching detached progs out of the images that still call them and patch 3 adds a selftest for the sleeping case. Since v3, only the nop of the prog that is detached is patched, in every image that isn't freed yet, like v2 did. Progs that stay attached keep running for the tasks that are in old images, ip_after_call is gone and the call to the original function is never skipped. On riscv and loongarch a jump of any range takes several instructions, and as bpf-ci and Alexei pointed out, a task preempted in the middle of such a patch site could resume into half of the new sequence. v5 makes the skip sites a single instruction there, patched to a jal / b through a new arch_bpf_trampoline_skip() hook, like their jump labels. I could only test these two under qemu. Tested on x86_64 under KVM and on arm64, s390x, powerpc64le, riscv64 and loongarch64 under qemu TCG, all with KASAN: the new selftest crashes the unpatched kernel and passes with the series on every one of them, along with trampoline_count, fentry/fexit, fentry_fexit, modify_return and lsm_cgroup (and the full test_progs on x86_64). On x86_64, 18 fsession progs with cookies on an 11 argument function still fit in the image. Same on bpf-next, where patch 2 has trivial context conflicts in the x86 and arm64 JITs. Changes since v4 (https://lore.kernel.org/bpf/20260925100342.481242-1-florent.revest@linux.dev/): - riscv, loongarch: single instruction skip sites, patched through arch_bpf_trampoline_skip(), loongarch keeps its limit of 38 (bpf-ci, Alexei) - arm64: say in bpf_arch_text_poke() why patching out a detached prog needs no synchronization (bpf-ci) - Comment fixes (bpf-ci) - Cc the arch maintainers and lists Changes since v3 (https://lore.kernel.org/bpf/20260924170543.1017048-1-florent.revest@linux.dev/): - Only patch the nop of the prog that is detached, in all the images that aren't freed yet, like v2 did, and explain why a list of images is needed (Alexei, bpf-ci) - Lower BPF_MAX_TRAMP_LINKS to 36 on x86, the worst case no longer fit in a page with the nops (bpf-ci, Alexei) - selftest: wait for the detached progs to really be freed before releasing the task, the grace period of patch 1 made the previous wait too short (bpf-ci). Detach two progs one after the other, so that the second detach has to reach an image that isn't the current one anymore - Keep a single comment block in bpf_tramp_image_put() (bpf-ci) Changes since v2 (https://lore.kernel.org/bpf/20260912095924.866254-1-florent.revest@linux.dev/): - Patch all the nops in bpf_tramp_image_put() instead of the detached prog's nop at detach time, drop the image list, the trampoline backpointer and ip_after_call (Alexei) - Wait for an RCU tasks grace period before freeing progs that were linked to a trampoline, for tasks preempted right before the enter helper (Junseo, sashiko) - Initialize the jit ctx in loongarch's arch_bpf_trampoline_size() and the dummy image in every arch_bpf_trampoline_size() (bpf-ci) - selftest: move the userfaultfd helper to testing_helpers.c and share it with bpf_mod_race, comment fixes (bpf-ci), add a subtest where the original function runs between the sleeping prog and the detached one Changes since v1 (https://lore.kernel.org/bpf/20260819122252.1782790-1-florent.revest@linux.dev/): - Patch nops in front of detached progs instead of taking prog references from the image (Alexei) - Lower BPF_MAX_TRAMP_LINKS on arm64, loongarch and powerpc so the image still fits in a page - Explain that the sleepable case doesn't depend on CONFIG_PREEMPTION (Kumar, Alexei) - Add a selftest (Jiri, Alexei) - Add Sechang's Reported-by (Junseo, Kumar) - Drop Leon's and Kumar's acks since the code changed entirely Florent Revest (Anthropic) (3): bpf: Wait for an RCU tasks grace period before freeing trampoline progs bpf: Skip detached progs in trampoline images that are still in use selftests/bpf: Detach a trampoline prog while a task sleeps before it arch/arm64/net/bpf_jit_comp.c | 37 ++-- arch/loongarch/net/bpf_jit.c | 60 ++++-- arch/powerpc/net/bpf_jit_comp.c | 45 +++-- arch/riscv/net/bpf_jit_comp64.c | 56 ++++-- arch/s390/net/bpf_jit_comp.c | 46 +++-- arch/x86/net/bpf_jit_comp.c | 26 ++- include/linux/bpf.h | 45 ++++- kernel/bpf/syscall.c | 19 +- kernel/bpf/trampoline.c | 85 ++++++-- .../selftests/bpf/prog_tests/bpf_mod_race.c | 34 +--- .../bpf/prog_tests/tramp_prog_detach.c | 188 ++++++++++++++++++ .../selftests/bpf/progs/tramp_prog_detach.c | 56 ++++++ tools/testing/selftests/bpf/testing_helpers.c | 28 +++ tools/testing/selftests/bpf/testing_helpers.h | 2 + 14 files changed, 572 insertions(+), 155 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/tramp_prog_detach.c create mode 100644 tools/testing/selftests/bpf/progs/tramp_prog_detach.c base-commit: ab39974240a0cff765f3bb9cce81d8001ffdb144 ==================== Link: https://patch.msgid.link/20260926135605.1217928-1-florent.revest@linux.dev Signed-off-by: Alexei Starovoitov commit d5288c519bbd0df9dff9f8dce2a8ce24e2ca9c8a Author: Florent Revest (Anthropic) Date: Sat Sep 26 13:56:00 2026 +0000 selftests/bpf: Detach a trampoline prog while a task sleeps before it Add a test for the use-after-free fixed by the previous commit. A sleepable prog on bpf_fentry_test1() blocks a task on a userfaultfd page, like bpf_mod_race does, while the two progs that run after it in the same trampoline are detached and freed one after the other, which the test knows from their .bss maps going away. After the first detach the task is in an image that isn't the trampoline's current one anymore. The task is then released and must not call into the freed progs. This is done with fentry progs, with fexit progs, where the task is already past the original function, and with a task sleeping in a fentry prog while fexit progs are detached, where the original function must still be called. bpf_mod_race's userfaultfd helper moves to testing_helpers.c so that both tests can use it. Without the fix, on a kernel with KASAN: BUG: KASAN: vmalloc-out-of-bounds in __bpf_prog_enter_recur+0xed/0x1e0 Read of size 8 at addr ffa0000000144040 by task test_progs/171 CPU: 6 UID: 0 PID: 171 Comm: test_progs Tainted: G OE 7.2.0+ #1 PREEMPT(full) Call Trace: __bpf_prog_enter_recur+0xed/0x1e0 bpf_trampoline_6442545468+0x72/0xe3 bpf_fentry_test1+0x9/0x20 bpf_prog_test_run_tracing+0x183/0x3e0 __sys_bpf+0xd3f/0x38f0 ... Signed-off-by: Florent Revest (Anthropic) Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260926135605.1217928-4-florent.revest@linux.dev commit 17637e1a581a22466ac3620a91e099683ff9cc6f Author: Florent Revest (Anthropic) Date: Sat Sep 26 13:55:59 2026 +0000 bpf: Skip detached progs in trampoline images that are still in use bpf_tramp_image_put() makes sure a trampoline image is not freed while a task may still be running in it, but nothing similar is done for the progs called by that image. Detach drops the last prog reference right away and the prog is freed after grace periods, on the basis that a task still in the traced function skips the fexit progs once the nop at ip_after_call is patched to a jump. That leaves out a task sleeping in a sleepable prog that runs before the detached one, which no grace period waits for: CPU 0 CPU 1 in image I, sleeping in prog S detach P from I's trampoline -> new image, bpf_tramp_image_put(I) bpf_prog_put(P), last ref grace periods, P freed back from S __bpf_prog_enter(P) call P->bpf_func If S and P are fexit progs the task is already past the patched jump, and fentry only images don't have one. On x86 this is an int3 in poisoned bpf_prog_pack memory: Oops: int3: 0000 [#1] SMP NOPTI CPU: 18 UID: 0 PID: 94573 Comm: x169 Not tainted 6.18.44 #1 PREEMPT(lazy) RIP: 0010:0xffffffffc0601d8d Call Trace: ? bpf_trampoline_6442515411+0x1a4/0x21b bpf_lsm_bprm_committed_creds+0x5/0x10 security_bprm_committed_creds+0x5f/0x70 begin_new_exec+0x2d6/0x410 ... We hit this in production when progs attached through trampolines got detached while their hooks were busy, and it was independently found with a fuzzer and KASAN. Have the JITs emit a patchable nop in front of each prog call sequence and record it in the image. When a prog is detached, patch its nop to a jump over the call sequence. Progs that stay attached keep running for the tasks that are in the image, and ip_after_call isn't needed anymore. The task can be in any image that isn't freed yet, not only in the current one. It sleeps in image I1 that calls S, P and Q, then P is detached and the trampoline moves to image I2, then Q is detached and its call is still in I1. So the trampoline keeps a list of its images until they are freed, and detaching a prog patches its nop in all of them. Images hold a reference on the trampoline for that long. On riscv and loongarch a jump of any range takes several instructions, and a task preempted in the middle of them could resume into half of the new sequence. The nop is a single instruction there, patched to a near branch through arch_bpf_trampoline_skip(). With the extra nops, BPF_MAX_TRAMP_LINKS progs no longer fit in a page on x86 and arm64 (and already didn't on powerpc), so lower the limit there like s390 does. Fixes: e21aa341785c ("bpf: Fix fexit trampoline.") Reported-by: Sechang Lim Suggested-by: Alexei Starovoitov Signed-off-by: Florent Revest (Anthropic) Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260926135605.1217928-3-florent.revest@linux.dev Closes: https://lore.kernel.org/bpf/20260815071927.147049-1-zirajs7@gmail.com/ commit 0fb5751a6e411b1b466c06e50021818d9391df98 Author: Florent Revest (Anthropic) Date: Sat Sep 26 13:55:58 2026 +0000 bpf: Wait for an RCU tasks grace period before freeing trampoline progs When a prog is detached from a trampoline, it is freed after an RCU grace period, or an RCU tasks trace one if it is sleepable. This covers the tasks that are running the prog, since the prog's enter helper takes the matching read lock before the prog is called. On a preemptible kernel, it doesn't cover a task that was preempted in the trampoline just before the enter helper. That task holds no lock yet, and it calls the prog after it was freed: BUG: KASAN: vmalloc-out-of-bounds in __bpf_prog_enter_recur+0x3a5/0x3f0 Read of size 8 at addr ffffc90000055040 by task candidate/110 CPU: 1 UID: 0 PID: 110 Comm: candidate Not tainted 7.3.0-rc2-00014-g15071f2a1263-dirty #2 PREEMPT(full) Call Trace: __bpf_prog_enter_recur+0x3a5/0x3f0 bpf_trampoline_6442509193+0x37/0xf1 __x64_sys_futex+0x9/0x410 do_syscall_64+0xb0/0x530 ... Wait for an RCU tasks grace period before the existing one when freeing a prog that was linked to a trampoline. An RCU tasks grace period only ends once the tasks that were preempted have run again, and bpf_tramp_image_put() already relies on it to free the image. It doesn't wait for tasks that sleep in the trampoline, the next commit takes care of those. Only progs that were linked to a trampoline can be called this way, so bpf_trampoline_add_prog() marks them and other progs are still freed as before. Fixes: e21aa341785c ("bpf: Fix fexit trampoline.") Reported-by: Junseo Lim Signed-off-by: Florent Revest (Anthropic) Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260926135605.1217928-2-florent.revest@linux.dev Closes: https://lore.kernel.org/bpf/aqdrwVpanH3WGurX@omen-arch/ commit 27a868b40e7d18e4be57d2bbbeac7581fd1219db Author: Preston Lam Date: Mon Sep 28 19:16:21 2026 -0400 ALSA: hda/realtek: Add mute LED quirk for HP Laptop 15-fd2xxx The HP Laptop 15-fd2xxx (PCI SSID 103c:8e43, Realtek ALC236) has a speaker mute LED on the F5 key and a microphone mute LED on the F8 key. Neither lights up, because the model has no quirk entry and only the generic HP vendor fallback (ALC269_FIXUP_HP_MUTE_LED) is applied. Probing the codec with hda-verb showed how the LEDs are wired: - mute LED: COEF index 0x07, bit 0, on NID 0x20 (set = LED on) - mic mute LED: codec GPIO0, active low (driven low = LED on) Driving GPIO1 and GPIO2 did not light the mute LED. This wiring is exactly what the existing ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO fixup implements (COEF 0x07 bit 0 for the mute LED, GPIO0 with inverted polarity for the micmute LED), so use it for this model. The sibling HP Laptop 15-fd0xxx (103c:8dd7) already uses the same fixup. Tested on this machine running Ubuntu 7.0.0-34-generic (SOF driver, the quirk built into snd-hda-codec-alc269 from Ubuntu's 7.0.0-34.34 source tree): the hda::mute and hda::micmute LEDs are created, follow the Master mute state and the Dmic0 capture switch respectively, and the F5 and F8 keys toggle them correctly. Muting the microphone also silences the capture stream. The LEDs also kept the correct state across an s2idle suspend/resume cycle (speaker muted in one run, microphone in another) and still responded to mute changes afterwards; long suspends were not tested. The desktop session was SwayFX (wlroots) with PipeWire, which only changes the mute state through the normal mixer controls; no other desktop was tried. Not tested on a mainline kernel tree directly; the change is only the quirk table entry. AI assistance: this patch, the hardware analysis behind it (probing the codec with hda-verb and choosing the existing fixup) and this commit message were written by Claude Code (Anthropic, model claude-sonnet-5-5). The submitter ran the privileged commands and reboots and reported the LED behavior; Claude Code ran the tests and read the kernel logs. Assisted-by: Claude:claude-sonnet-5-5 Signed-off-by: Preston Lam Link: https://patch.msgid.link/20260928231621.1672704-1-plamlam99@gmail.com Signed-off-by: Takashi Iwai commit 6f8319e3e9a44dd537d17f41565a8453c560a581 Merge: 72d3fcf802c45d 976d5e0ddac885 Author: Linus Torvalds Date: Mon Sep 28 20:11:31 2026 -0700 Merge tag 'mm-hotfixes-stable-2026-09-27-19-12' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull MM fixes from Andrew Morton: - Fix module loading incorrectly returning success after alloc_tag codetag setup failed - Restore MADV_COLLAPSE semantics for shmem so forced collapse ignores the shmem THP/mTHP sysfs settings - Make alloc_tag UAPI structure padding explicit - Fix DAMON schemes unexpectedly stopping after quotas are disabled through the online parameter update interface - Fix a false SW_TAGS KASAN invalid-access report when freeing vmapped task stacks - Split the MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION MAINTAINERS entry into separate MIGRATION and NUMA PLACEMENT entries - Move memory tiering maintenance under NUMA PLACEMENT - Add Gregory Price as a NUMA PLACEMENT co-maintainer - Add Heming Zhao as an ocfs2 reviewer - Fix mmap_prepare() state being copied onto a merged VMA rather than only onto a newly allocated VMA * tag 'mm-hotfixes-stable-2026-09-27-19-12' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/vma: predicate setting mmap_prepare VMA fields on new vma alloc MAINTAINERS: add Heming Zhao as ocfs2 reviewer MAINTAINERS: make Gregory a co-maintainer of MEMORY MANAGEMENT - NUMA PLACEMENT MAINTAINERS: move memory tiering under MEMORY MANAGEMENT - NUMA PLACEMENT MAINTAINERS: split up MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION kasan: unpoison task stack below watermark only in generic mode mm/damon/core: don't skip damos_adjust_quota() while esz is not zero alloc_tag: avoid implicit padding in uapi mm: shmem: ignore sysfs configs for shmem forced collapse module: fix lost error code from codetag_load_module() commit 37e02c42a00be692c06343e11779aadc45f45971 Author: Eric Dumazet Date: Fri Sep 25 13:52:43 2026 +0000 net: restrict SO_RESERVE_MEM to TCP sockets and cap max value Commit 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") and commit d00c8ee31729 ("net: fix possible NULL deref in sock_reserve_memory") only checked sk_has_account(sk), which is true for both TCP and UDP sockets. However, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only supported by TCP: - On UDP sockets, sk->sk_forward_alloc is protected by sk->sk_receive_queue.lock, whereas sock_reserve_memory() and sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt sk_forward_alloc and memcg accounting. - udp_rmem_release() reclaims excess sk_forward_alloc without accounting for sk_unused_reserved_mem(sk). Restrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now. Supporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and honoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in a future net-next series if needed. In addition, reject val > SZ_1G with -EINVAL in sk_setsockopt(SO_RESERVE_MEM). Without an upper bound, values near INT_MAX cause sk_mem_pages(delta) and (pages << PAGE_SHIFT) to overflow 32-bit signed int, corrupting sk->sk_forward_alloc and sk->sk_reserved_mem. Using a page-aligned cap (SZ_1G) ensures that the page-rounded sk->sk_reserved_mem reported by getsockopt(SO_RESERVE_MEM) can always be passed back to setsockopt(SO_RESERVE_MEM). Fixes: 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") Reported-by: Cai Xinchen Closes: https://lore.kernel.org/netdev/5a88421d-10ef-4fca-9acb-85a27a3c1173@huawei.com/ Signed-off-by: Eric Dumazet Reviewed-by: Wei Wang Link: https://patch.msgid.link/20260925135244.3715196-2-edumazet@google.com Signed-off-by: Jakub Kicinski commit 036778a4fad19b54b73ae229a1901665aa8750a2 Author: Nicolai Buchwitz Date: Fri Sep 25 15:52:36 2026 +0200 net: ethtool: let tsconfig reach a PHY-only timestamp provider TSCONFIG_GET and TSCONFIG_SET reject a device that implements neither hwtstamp NDO, even when its PHY can serve the request. The ioctls they meant to replace handle it, so the two interfaces disagree on the same hardware and user space has to pick one. Accept the default timestamping PHY and an already installed provider on both sides. On the set side the test moves into ethnl_set_tsconfig() as the validate callback runs without rtnl. On the get side it stays ahead of ethnl_ops_begin(), so a device that can serve nothing keeps failing with EOPNOTSUPP and a dump still skips it rather than stopping there. A netdev provider needs ndo_hwtstamp_set to be programmed at all, so don't pick that source without it, and test for ndo_hwtstamp_get before calling it. Fixes: 6e9e2eed4f39 ("net: ethtool: Add support for tsconfig command to get/set hwtstamp config") Signed-off-by: Nicolai Buchwitz Reviewed-by: Maxime Chevallier Reviewed-by: Kory Maincent Link: https://patch.msgid.link/20260925135237.3432266-3-nb@tipi-net.de Signed-off-by: Jakub Kicinski commit 8ae3f4067ba4ae3a15581392f6dac422e3d3def0 Author: Andrea Mayer Date: Fri Sep 25 15:38:07 2026 +0200 seg6: ensure packet data is writable before modifying SRH and IPv6 DA advance_nextseg() modifies the SRH Segments Left field and the IPv6 destination address without ensuring the packet data is writable. seg6_next_csid_advance_arg() has the same problem when it advances the NEXT-C-SID argument in the destination address. The skb may be cloned, for example by an AF_PACKET socket receiving on the ingress device. advance_nextseg() and seg6_next_csid_advance_arg() then write into the packet data shared with the clone. A read from that socket can return the modified packet instead of the received one. The simplified path below shows this for advance_nextseg(): __netif_receive_skb_one_core __netif_receive_skb_core deliver_skb [orig: users=2, cloned=0] packet_rcv skb_clone clone queued to the AF_PACKET socket consume_skb(orig) [orig: users=1, cloned=1] ipv6_rcv ip6_rcv_core skb_share_check: no-op [orig: users=1] [...] input_action_end_core advance_nextseg writes into the data shared with the clone Call skb_ensure_writable() in advance_nextseg() and in seg6_next_csid_advance_arg() before they modify the packet data. skb_ensure_writable() may reallocate skb->head, which invalidates the pointers into the packet data taken before the call. advance_nextseg() now returns a valid SRH pointer, or NULL if skb_ensure_writable() fails. seg6_next_csid_advance_arg() takes the pointer to the destination address from the skb after skb_ensure_writable(). On failure, the callers drop the packet with SKB_DROP_REASON_NOMEM. Fixes: 140f04c33bbc ("ipv6: sr: implement several seg6local actions") Fixes: 848f3c0d4769 ("seg6: add NEXT-C-SID support for SRv6 End behavior") Signed-off-by: Andrea Mayer Link: https://patch.msgid.link/20260925133807.32-1-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski commit 88095728511e0df9c89528944f5a1762ad298983 Author: Lorenzo Bianconi Date: Wed Sep 23 11:14:28 2026 +0200 net: stmmac: fix rx Scatter-Gather support When a received frame is larger than dma_buf_sz, the DMA scatters it across multiple RX descriptors (rx Scatter-Gather). The secondary RX buffer (sec_page) was only allocated and programmed when split-header (SPH) was active, so for regular frames buffer2 was neither allocated nor backed by a valid mapping. As soon as an incoming frame overflowed buffer1, the DMA wrote the overflow into the unmapped secondary-buffer address, triggering an SMMU translation fault on IOMMU-based platforms: arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x7f0011, cbfrsynra=0x1c90, cb=11 arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0x1c90 arm-smmu 15000000.iommu: FSYNR0 = 007f0011 [S1CBNDX=127 WNR PLVL=1] Enable scatter-gather for non-SPH frames on cores that can program an independent secondary RX buffer (GMAC4/XGMAC): allocate and mark buffer2 as valid in stmmac_init_rx_buffers() and stmmac_rx_refill(), and account for it in the buffer length computation. Legacy cores have no set_sec_addr op, so they keep buffer2 disabled. Since buffer2 is handed to the DMA at page offset 0, the page pool sync window is widened to cover both buffers in every mode: offset is set to 0 and max_len to dma_buf_sz + stmmac_rx_offset(). The FCS can straddle the buffer1/buffer2 boundary and a descriptor boundary, so it is now stripped from the tail of the assembled frame with pskb_trim() instead of from a single buffer, avoiding an unsigned underflow for frames that overflow a buffer by 1..3 bytes. For single-buffer frames the XDP program must not see the FCS, so it is removed from the XDP buffer before the program runs. Native XDP currently only supports single-buffer (linear) frames. An oversized frame accepted by the MAC (jumbo enabled) is received via buffer2; the XDP program only sees buffer1, so on a TX/REDIRECT verdict the frame is forwarded truncated. XDP multi-buffer support to handle this case is planned as a follow-up. AF_XDP zero-copy RX is not covered by this change: a ZC queue still programs buffer2 at DMA address 0 (and XGMAC has no buffer2-valid bit), so an oversized frame overflowing buffer1 can still trigger the same SMMU translation fault. Handling is planned as a follow-up. Fixes: 88ebe2cf7f3f ("net: stmmac: Rework stmmac_rx()") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260923-stmmac-rx-sg-fix-v3-1-ed26fea7180d@oss.qualcomm.com Signed-off-by: Jakub Kicinski commit bdea4980182e3badac74f04df6c07492b91c569e Author: Mina Almasry Date: Fri Sep 25 14:41:11 2026 +0000 net: page_pool: fix use-after-free in page_pool_recycle_ring_bulk() With CONFIG_PAGE_POOL_STATS=y, page_pool_recycle_ring_bulk() updates the recycle stats after dropping the producer lock. If it just recycled the last inflight netmems of a pool being destroyed, page_pool_release() can pass its producer-lock barrier and free the pool before recycle_stat_add() runs. Commit fcc680a647ba7 ("page_pool: allow mixing PPs within one bulk") moved this stat update after the unlock. Commit 271683bb2cf32 ("page_pool: Fix use-after-free in page_pool_recycle_in_ring") later added the barrier, but only fixed page_pool_recycle_in_ring(). Move the update back under the lock. Fixes: fcc680a647ba7 ("page_pool: allow mixing PPs within one bulk") Link: https://lore.kernel.org/r/179028939171.2160803.706522228583664641@kernel.org Cc: Kaifeng Wang Cc: Dong Chenchen Signed-off-by: Mina Almasry Reviewed-by: Simon Horman Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260925144127.1445667-1-almasrymina@google.com Signed-off-by: Jakub Kicinski commit 512ccd3d0e91e791fb37442aa0a2599aca19783d Author: Jérémy Jean Date: Thu Sep 24 20:21:05 2026 +0000 tipc: prevent GCM nonce reuse on peer key changes TIPC can encrypt traffic between nodes using a different transmit key for each node. In this mode, the AES-GCM nonce for a packet sent to a known peer consists of a 32-bit prefix (a per-key salt XOR the peer's address) followed by a 64-bit counter. That counter is stored in the peer's RX crypto object. When the peer reports a change in which key it uses to receive packets, TIPC resets this counter. The sender can still be using the same TX key and salt, so subsequent packets reuse earlier nonces. This nonce reuse breaks confidentiality and exposes GCM's authentication key. This makes forgeries trivial: an attacker can exploit CTR malleability to alter captured ciphertexts and use the recovered authentication key to compute a valid tag for the modified ciphertext, under the same key and nonce. Use the TX key's existing aead->seqno counter instead. All encryptions using that key object share the same atomic counter, so concurrent encryptions get distinct nonce counter values. The counter survives key activation and peer reconnection, and peer key-status reports cannot reset it. This prevents those transitions from causing nonce reuse while the same TX key remains installed. The nonce format is unchanged, and receivers do not require consecutive counter values, so sharing the counter across peers remains compatible with existing receivers. A pre-existing check still invokes key revocation in the unlikely event that the counter wraps to zero. Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Signed-off-by: Jérémy Jean Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260924202105.3722778-1-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Jakub Kicinski commit fb9b529be016d032860773955a0575908819e7b9 Merge: 382cf976898733 cdef07f3002f70 Author: Jakub Kicinski Date: Mon Sep 28 18:20:24 2026 -0700 Merge branch 'octeontx2-misc-fixes-for-rvu-drivers' Subrat Pandey says: ==================== octeontx2: Misc fixes for RVU drivers A few independent fixes for the Marvell OcteonTX2 (RVU AF/PF) drivers: - Fix aura/CQ BPID assignment under CONFIG_DCB, which assumed queue_to_pfc_map was always allocated (not true for SDP VFs). - Fix the SC resource cleanup loop that iterated over secy.max instead of sc.max. ==================== Link: https://patch.msgid.link/20260922102149.2078168-1-subratp@marvell.com Signed-off-by: Jakub Kicinski commit cdef07f3002f708a345392ee28d0d9bfac8383a1 Author: Baha Mesleh Date: Tue Sep 22 15:51:49 2026 +0530 octeontx2-af: mcs: Fix SC resource cleanup loop The SC resource cleanup and statistics loops were incorrectly iterating over secy.max instead of sc.max, so the highest SC id could be left allocated across teardown or FLR. Use sc.max as the loop bound. Fixes: cfc14181d497 ("octeontx2-af: cn10k: mcs: Manage the MCS block hardware resources") Signed-off-by: Baha Mesleh Signed-off-by: Subrat Pandey Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260922102149.2078168-3-subratp@marvell.com Signed-off-by: Jakub Kicinski commit 056994563935e049093f100efaad7e63ad113814 Author: Geetha sowjanya Date: Tue Sep 22 15:51:48 2026 +0530 octeontx2-pf: Fix aura BPID assignment when CONFIG_DCB is enabled Previously, BPID assignment under CONFIG_DCB assumed `queue_to_pfc_map` was always initialized. For SDP VFs this leads to invalid memory access as it was not initialized. This patch adds a NULL check for `queue_to_pfc_map` before dereferencing it. Also, simplifies the logic by always assigning a default BPID first, then conditionally overriding it if CONFIG_DCB is enabled and the map exists. Fixes: 184fb40f731b ("octeontx2-pf: Avoid adding dcbnl_ops for LBK and SDP vf") Signed-off-by: Geetha sowjanya Signed-off-by: Subrat Pandey Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260922102149.2078168-2-subratp@marvell.com Signed-off-by: Jakub Kicinski commit 382cf9768987331f6576c97bfb44d9434e3555f6 Merge: 04c824940d5287 848a7a91c7f036 Author: Jakub Kicinski Date: Mon Sep 28 17:54:53 2026 -0700 Merge tag 'for-net-2026-09-28' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: Core: - hci_core: Serialize ACL scheduling with channel deletion - hci_core: Serialize SCO and ISO scheduling with teardown - hci_core: Serialize fragmented ISO packet queueing - hci_core: Fix inquiry cache timestamps on 64-bit systems - hci_core: free the HCI ID if naming fails - hci_conn: Lock parent access during enhanced SCO setup - hci_sync: Fix inquiry cache use-after-free - hci_sync: don't drain cmd_sync backlog on unregister - RFCOMM: Fix initial port reference race - SMP: Serialize SMP remote OOB data access Drivers: - btintel: fix buffer over-read in btintel_hw_error() - btintel: validate DDC record lengths - btintel_pcie: fix plen overflow in btintel_pcie_recv_frame() - btintel_pcie: reject oversized TX packets in send_frame() * tag 'for-net-2026-09-28' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: hci_core: Serialize SCO and ISO scheduling with teardown Bluetooth: hci_core: Serialize ACL scheduling with channel deletion Bluetooth: Serialize SMP remote OOB data access Bluetooth: RFCOMM: Fix initial port reference race Bluetooth: hci_sync: Fix inquiry cache use-after-free Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister Bluetooth: hci_core: Serialize fragmented ISO packet queueing Bluetooth: hci_conn: Lock parent access during enhanced SCO setup Bluetooth: btintel: validate DDC record lengths Bluetooth: hci_core: free the HCI ID if naming fails Bluetooth: hci_core: Fix inquiry cache timestamps on 64-bit systems Bluetooth: btintel_pcie: reject oversized TX packets in send_frame() Bluetooth: btintel_pcie: fix plen overflow in btintel_pcie_recv_frame() Bluetooth: btintel: fix buffer over-read in btintel_hw_error() ==================== Link: https://patch.msgid.link/20260928152919.942973-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski commit 04c824940d52871c49866a4ac67b504146f7cf35 Author: Anirudh Virdi Date: Thu Sep 24 12:12:44 2026 +0530 net/mlx5: Fix slab-out-of-bounds when handling team device events The mlx5_handle_changeupper_event() and mlx5_handle_changeinfodata_event() functions check for LAG masters (which includes both bonding and team devices) but only call bonding-specific APIs. When processing team device events, calling bond_slave_get_rcu() and bond_is_slave_inactive() on team_port structures causes KASAN to detect an out-of-bounds memory access since team_port is smaller than bond slave. Fix this by wrapping the bond-specific API calls with a check for bonding devices. This allows the function to still process LAG events for both bonding and teams but only calls bond-specific functions when dealing with actual bonding devices. For mlx5_handle_changeinfodata_event(), keep the explicit bond check as mlx5 doesn't handle state information for team ports anyway. Tested with Mellanox ConnectX-5 on Linux 7.2.0-rc6: - Bonding: PASS (no regressions) - Team device: PASS (no KASAN errors) Fixes: 54493a08e21f ("net/mlx5: Lag, record inactive state of bond device") Suggested-by: Mark Bloch Signed-off-by: Anirudh Virdi Reviewed-by: Mark Bloch Link: https://patch.msgid.link/20260924064244.94045-1-avirdi@redhat.com Signed-off-by: Jakub Kicinski commit 0456d187c006be73d376969a65eeb5f300a5ebf6 Merge: 6b2462f07cb74c 242935adfeb096 Author: Jakub Kicinski Date: Mon Sep 28 17:06:42 2026 -0700 Merge branch 'net-systemport-collection-of-fixes' Florian Fainelli says: ==================== net: systemport: Collection of fixes ==================== Link: https://patch.msgid.link/20260922232440.598918-1-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski commit 242935adfeb096f09b29fb2cfcf12f9eb2911fc6 Author: Florian Fainelli Date: Tue Sep 22 16:24:35 2026 -0700 net: systemport: Fix RUNT MIB counter register offset calculation In UniMAC hardware, there is a 0xC byte gap between the RX MIB counters and the TX MIB counters, and a second 0xC byte gap between the TX MIB counters and the RX RUNT MIB counters. In bcm_sysport_update_mib_counters(), 'offset' was only set to UMAC_MIB_STAT_OFFSET (0xC) for all non-RX counters, omitting the second 0xC gap for BCM_SYSPORT_STAT_RUNT counters. As a result, all 4 RUNT MIB counters were read from unmapped gap register space. Fix this by setting offset to 2 * UMAC_MIB_STAT_OFFSET (0x18) when reading BCM_SYSPORT_STAT_RUNT counters. Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260922232440.598918-6-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski commit eb7b84af0ec5c71b4920e999611b466b3784496c Author: Florian Fainelli Date: Tue Sep 22 16:24:31 2026 -0700 net: systemport: Fix buffer overflow in bcm_sysport_get_stats() When running on SYSTEMPORT Lite, certain statistics are unsupported and skipped during bcm_sysport_get_stats(). The variable 'j' tracks the compacted index into the destination data buffer, whereas 'i' iterates over all elements in bcm_sysport_gstrings_stats. Because the buffer allocated by ethtool is sized only according to bcm_sysport_get_sset_count(), storing values at data[i] instead of data[j] writes past the allocated array bounds, leading to memory corruption. Fix this by writing to data[j] instead of data[i]. Fixes: 10377ba7673d ("net: systemport: Support 64bit statistics") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260922232440.598918-2-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski commit 6b2462f07cb74cd0a5cb868b36c09e9f51f56d3f Author: Christian Melendez Date: Tue Sep 22 23:14:39 2026 +0200 MAINTAINERS: add missing entry for b53.rst Documentation/networking/dsa/b53.rst is not covered by the BROADCOM B53/SF2 ETHERNET SWITCH DRIVER entry. Signed-off-by: Christian Melendez Link: https://patch.msgid.link/20260922211439.369917-2-chrismelnu@gmail.com Signed-off-by: Jakub Kicinski commit 3e292c56bf5e338efcda7f9bfa603180855cd1be Author: Julien Stephan Date: Fri Aug 28 14:10:47 2026 +0200 drm/mediatek: mtk_hdmi_v2: fix VID_DOWNSAMPLE_CONFIG register offset According to the datasheet, VID_DOWNSAMPLE_CONFIG is at offset 0x8f0; 0x8d0 is the VID_CSC_COEFF_0 register. Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188") Signed-off-by: Julien Stephan Reviewed-by: Louis-Alexis Eyraud Reviewed-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260828-mtk-hdmi-v2-fix-register-offset-v1-1-118ad5d7ebe3@baylibre.com/ Signed-off-by: Chun-Kuang Hu commit bce7698e2e6565bb765bd0522337f29f5f312624 Author: Haojie Li Date: Tue Aug 25 18:08:45 2026 +0800 drm/mediatek: Add missing IS_ERR check for ovl_adaptor platform device platform_device_register_data() can fail and return an ERR_PTR, but the return value is used without checking, leading to an invalid pointer being stored in ddp_comp[].dev and passed to component_match_add() and mtk_ddp_comp_init(), which could result in a kernel crash. Add an IS_ERR() check to jump to the error handling path on failure. Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195") Cc: stable@vger.kernel.org Signed-off-by: Haojie Li Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260825100845.438893-1-lihaojie@kylinos.cn/ Signed-off-by: Chun-Kuang Hu commit 973ea70393e885e540f714904e51bc6cac80e3d7 Author: Sean Christopherson Date: Mon Sep 28 08:46:44 2026 -0700 KVM: SEV: Do cache maintenance on the source VM *before* clearing SEV state Explicitly flush caches after intra-host migration before clearing "SEV active" on the source VM, as doing cache maintenance afterwards creates a tiny window where memory reclaim could return memory to the host without performing a cache flush, e.g. as pointed out by Sashiko: CPU1 in sev_migrate_from(): src->active = false; CPU2 running concurrent unmap: Since active is false, the automatic cache flush in sev_guest_memory_reclaimed is skipped. The host frees and reallocates the page. CPU1 in sev_migrate_from(): sev_writeback_caches(src_kvm); Executes a hardware cache flush (wbnoinvd), which writes the guest's old dirty ciphertext over the new page owner's data. Fixes: 93de2a6a4b91 ("KVM: SEV: Do cache maintenance on the source VM during intra-host migration") Cc: stable@vger.kernel.org Reported-by: Sashiko Bot Closes: https://lore.kernel.org/all/20260923165304.1662E1F000FF@smtp.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260928154644.2559454-3-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 8abbc76120a74bfba1851bd97528099d715e45c6 Author: Sean Christopherson Date: Mon Sep 28 08:46:43 2026 -0700 KVM: SEV: Nullify "have run CPUs" mask pointer when freeing it Nullify have_run_cpus when freeing the mask, particularly in the error path of __sev_guest_init(), so that KVM doesn't have to subtly use sev->active to track whether or not the mask has been freed. As pointed out by Sashiko, blindly freeing the mask in sev_vm_destroy() results in a double-free if the mask is freed if __sev_guest_init() fails. Throw the logic in a helper as nullifying the pointer is frustratingly difficult and weird due to have_run_cpus being a single-entry array when CPUMASK_OFFSTACK=n. Deliberately don't use CPUMASK_VAR_NULL, as it's not directly assignable when the cpumask is on-stack, e.g. requires using a local variable and a memcpy(), which is beyond ridiculous. Furthermore, while clearing the on-stack bitmask is an unnecessary and arguably unwanted side effect, KVM absolutely relies on '0' being the "null" value given that the struct is zero-allocated. Opportunistically add an alloc() helper to pair with free(); there are just enough call sites to make doing so worthwhile. Fixes: 12c1f6e03f94 ("KVM: SEV: Free have_run_cpus during VM destruction even if VM is no longer SEV") Cc: stable@vger.kernel.org Reported-by: Sashiko Bot Closes: https://lore.kernel.org/all/20260923165349.CAAF01F000FF@smtp.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260928154644.2559454-2-seanjc@google.com> Signed-off-by: Paolo Bonzini commit b0bc51910f0391fea09c0a1d32352fec2acb2686 Author: Sean Christopherson Date: Thu Aug 13 15:36:10 2026 -0700 KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12 Signed-off-by: Sean Christopherson Message-ID: <20260813223610.2043560-7-seanjc@google.com> Signed-off-by: Paolo Bonzini commit b630929bcc4c867c9abc8cd5a0ebee3bb5ce5dcd Author: Sean Christopherson Date: Sat Sep 26 02:04:03 2026 -0400 KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt Signed-off-by: Sean Christopherson Message-ID: <20260813223610.2043560-6-seanjc@google.com> Signed-off-by: Paolo Bonzini commit a661c34fe693c8f9ef29b45ee71cfa1fe593502b Author: Nick Desaulniers Date: Fri Aug 21 15:45:42 2026 -0700 {x86,um}/uapi/ptrace: Guard register offset macros with __ASSEMBLER__ or __FRAME_OFFSETS The register offset macros in are guarded by `defined(__ASSEMBLER__) || defined(__FRAME_OFFSETS)` for 64-bit, but were left unguarded for 32-bit. This causes havoc for userspace that happens to use identifiers colliding with these short macro names (e.g., EBX, ECX, EAX, DS, ES, FS, GS, CS, SS). Without this guard, userspace is forced to be super extra careful with include ordering to minimize the chance of collision. Wrap both the 32-bit and 64-bit register definitions under `#if defined(__ASSEMBLER__) || defined(__FRAME_OFFSETS)`, and ensure User-Mode Linux (UML) defines `__FRAME_OFFSETS` for 32-bit as well. Closes: https://github.com/llvm/llvm-project/issues/217413 Assisted-by: LLM Signed-off-by: Nick Desaulniers Signed-off-by: Borislav Petkov (AMD) Acked-by: Oleg Nesterov Acked-by: Johannes Berg Tested-by: Elliott Hughes Link: https://patch.msgid.link/20260821-ptrace_uapi-v1-1-3de8638a29f2@google.com commit 980db94e3eeefdd8a1c46f86412c33a7f7806f51 Author: Pavankumar Kondeti Date: Mon Sep 28 09:18:56 2026 +0530 workqueue: Fix NULL current_pwq deref in chained work check 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 commit 19fc4240358be2a25ce8e0a49a2819588ed61c5d Author: Shawn Guo Date: Sun Sep 27 09:09:13 2026 +0800 pinctrl: qcom: spmi-gpio: make direction changes exclusive Neither direction callback clears the opposite buffer: .direction_output() only packs PIN_CONFIG_LEVEL and .direction_input() only packs PIN_CONFIG_INPUT_ENABLE. As pmic_gpio_populate() seeds input_enabled and output_enabled from MODE_CTL, a pad left in DIGITAL_INPUT[_OUTPUT] by the bootloader ends up in DIGITAL_INPUT_OUTPUT whichever direction is requested. That leaves an input still driving the line, and makes pmic_gpio_get_direction() report an output as an input, which breaks consumers that read the direction back: reg-fixed-voltage regulator-wcn-core-vm-1p35: setup of GPIO (default) failed: -1 reg-fixed-voltage regulator-wcn-core-vm-1p35: error -EPERM: can't get GPIO Pack the opposite buffer's PIN_CONFIG_*_ENABLE along with the requested direction, so MODE_CTL becomes DIGITAL_INPUT or DIGITAL_OUTPUT, never both. pmic_gpio_config_set() writes the registers once after walking all configs, so this stays a single write. An open-drain or open-source output is the exception: it only drives one rail, so pmic_gpio_get() needs the input buffer to sample the line rather than return the value last written. Program the input buffer from pad->buffer_type, which gpiolib has already updated via PIN_CONFIG_DRIVE_OPEN_DRAIN, and key pmic_gpio_get_direction() off output_enabled so such pads still read back as outputs. Genuinely bidirectional pads can still be described that way through pinconf; the gpiolib callbacks now mean what gpiolib says they mean. Fixes: 263447532463 ("pinctrl: qcom: spmi-gpio: implement .get_direction()") Assisted-by: LLM Reviewed-by: Linus Walleij Signed-off-by: Shawn Guo Link: https://patch.msgid.link/20260927010913.1212600-1-shengchao.guo@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit 8157cd417d72137ba0bd4c8c8355a67223f1ad95 Merge: c6c159fcdb4e9a 72d3fcf802c45d Author: Bartosz Golaszewski Date: Mon Sep 28 19:15:10 2026 +0200 Merge tag 'v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into pinctrl-qcom/for-current Linux 7.3-rc5 commit 816fb1590a4c8cf8d05cd076057616be02e276f0 Author: Aldo Ariel Panzardo Date: Sat Sep 26 18:21:45 2026 -0300 Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata() 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 commit d35a535d3e3e71f92a051d94e415f43612c4edfc Author: Tejun Heo Date: Wed Sep 23 12:39:20 2026 -1000 sched_ext: Fix CPU hotplug hang when a dying CPU's tasks sit in the BPF scheduler A CPU going down has to empty its own rq. Its hotplug thread waits in sched_cpu_wait_empty() until nothing else is left, and the only thing that wakes it is balance_push(), which runs from __schedule() on the dying CPU and pushes off the migratable tasks the CPU picks. sched_ext breaks this. A task sitting on a user DSQ or held by the BPF scheduler is still counted on its rq, but an inactive CPU no longer calls ops.dispatch() and can't pull the task back. The dying CPU goes idle with the task still counted, and one of two things happens: - Another CPU consumes the task. The rq empties without a __schedule() on the dying CPU, so the hotplug thread is never woken and cpu_down() hangs holding cpu_hotplug_lock. - The task is affine only to the dying CPU. Nothing can move it, and the offline stalls until the watchdog ejects the BPF scheduler. When the rq goes offline, re-enqueue every task on it that isn't already on the local DSQ. An enqueue on an offline rq lands on the local DSQ, so the dying CPU itself picks the tasks and balance_push() pushes them off, the same as for the other sched classes. From then on no sched_ext path on another CPU can pull a task off the rq. ops.dispatch() currently stops as soon as the CPU goes inactive, and CPU hotplug then waits for an RCU grace period before taking the rq offline. A BPF-held task affine only to the dying CPU and preempted inside an RCU read-side critical section would block that grace period, and the rq would never go offline. Test SCX_RQ_ONLINE directly so that ops.dispatch() keeps running until the rq goes offline. Only the dying CPU's own hotplug thread clears the flag during teardown, and task_can_run_on_remote_rq() still keeps other rqs' tasks off the CPU. Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Fixes: 991ef53a4832 ("sched_ext: Make scx_rq_online() also test cpu_active() in addition to SCX_RQ_ONLINE") Cc: stable@vger.kernel.org # v6.12+ Reported-by: Alap Mohan Reported-by: Joonwoo Park Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit 0a01e1df137fd7e51f045a5e97d40f42fb58ae0c Author: Jose Ignacio Tornos Martinez Date: Mon Jun 15 20:00:00 2026 +0200 ice: skip unnecessary VF reset when setting trust Similar to the i40e fix, ice_set_vf_trust() unconditionally calls ice_reset_vf() when the trust setting changes. While the delay is smaller than i40e, this reset is still unnecessary in most cases. When granting trust, no reset is needed - we can just set the capability flag to allow privileged operations. When revoking trust, we only need to reset (conservative approach) if the VF has actually configured advanced features that require cleanup (MAC LLDP filters, promiscuous mode). For VFs in a clean state, we can safely change the trust setting without the disruptive reset. When we do reset, we maintain the original ice pattern that has been reliable in production: cleanup LLDP filters first, then set vf->trusted, then reset. This ensures the privilege capability bit is handled correctly during reset rebuild. When we don't reset, we manually handle the capability flag via helper function, eliminating the delay. Signed-off-by: Jose Ignacio Tornos Martinez Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen commit 436729a56dd4dac611d10b569c5359d2cf705b19 Author: Jose Ignacio Tornos Martinez Date: Mon Jun 22 15:58:24 2026 +0200 iavf: send MAC change request synchronously After commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations"), iavf_set_mac() is called with the netdev instance lock already held. The function queues a MAC address change request via iavf_replace_primary_mac() and then waits for completion. However, in the current flow, the actual virtchnl message is sent by the watchdog task, which also needs to acquire the netdev lock to run. Additionally, the adminq_task which processes virtchnl responses also needs the netdev lock. This creates a deadlock scenario: 1. iavf_set_mac() holds netdev lock and waits for MAC change 2. Watchdog needs netdev lock to send the request -> blocked 3. Even if request is sent, adminq_task needs netdev lock to process PF response -> blocked 4. MAC change times out after 2.5 seconds 5. iavf_set_mac() returns -EAGAIN This particularly affects VFs during bonding setup when multiple VFs are enslaved in quick succession. Fix by implementing a synchronous MAC change operation similar to the approach used in commit fdadbf6e84c4 ("iavf: fix incorrect reset handling in callbacks"). The solution: 1. Send the virtchnl ADD_ETH_ADDR message directly (not via watchdog) 2. Poll the admin queue hardware directly for responses 3. Process all received messages (including non-MAC messages) 4. Return when MAC change completes or times out A new generic function iavf_poll_virtchnl_response() is introduced that can be reused for any future synchronous virtchnl operations. It takes a callback to check completion, allowing flexible condition checking. This allows the operation to complete synchronously while holding netdev_lock, without relying on watchdog or adminq_task. The function can sleep for up to 2.5 seconds polling hardware, but this is acceptable since netdev_lock is per-device and only serializes operations on the same interface. To support this, change iavf_add_ether_addrs() to return an error code instead of void, allowing callers to detect failures. Additionally, export iavf_mac_add_reject() to enable proper rollback on local failures (timeouts, send errors) - PF rejections are already handled automatically by iavf_virtchnl_completion(). Remove vc_waitqueue entirely because iavf_set_mac was the only waiter on this waitqueue and after the changes it is not needed. Fixes: ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations") cc: stable@vger.kernel.org Signed-off-by: Jose Ignacio Tornos Martinez Reviewed-by: Przemek Kitszel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen commit 74bbbc9359a592e3c0736b289c00489c1afa928c Author: Jose Ignacio Tornos Martinez Date: Tue Apr 28 17:26:44 2026 +0200 i40e: skip unnecessary VF reset when setting trust The current implementation triggers a VF reset when changing the trust setting, causing a ~10 second delay during bonding setup. In all the cases, the reset causes a ~10 second delay during which: - VF must reinitialize completely - Any in-progress operations (like bonding enslave) fail with timeouts - VF is unavailable When granting trust, no reset is needed - we can just set the capability flag to allow privileged operations. When revoking trust, we only need to reset (conservative approach) if the VF has actually configured advanced features that require cleanup (ADQ/cloud filters, promiscuous mode). For VFs in a clean state, we can safely change the trust setting without the disruptive reset. When we don't reset, we manually handle capability flag via helper function, eliminating the delay. Signed-off-by: Jose Ignacio Tornos Martinez Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen commit 29ee8cf18a21b02cd0b2e35f741b61cd1fe3e14e Author: Guangshuo Li Date: Wed Sep 16 00:13:10 2026 +0800 mmc: cavium-thunderx: destroy slot platform devices on remove 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 commit 0f4d4424fc1d651ec3fa63a0a8060ba9087eb0ec Author: Guangshuo Li Date: Tue Sep 15 23:57:24 2026 +0800 mmc: cavium-octeon: destroy slot platform devices on remove 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 commit 9d1afbf60ed53c5b051cd124153e0ae3078c8b93 Author: Maxim Skokov Date: Tue Sep 15 10:00:46 2026 +0300 Bluetooth: RFCOMM: free the skb when the DLC has no owner 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 commit e1c6c10a6a70a69e29b04fcc1ebe4b9bcbc7a49a Author: Guangshuo Li Date: Wed Sep 16 00:19:47 2026 +0800 mmc: sdhci-sprd: disable runtime PM on remove 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 commit b38af5386a74416e898955443f2e26547b358cb2 Author: Yibo Tan Date: Tue Sep 15 22:44:57 2026 +0800 mmc: mtk-sd: Cancel request timeout work on remove 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 commit e3ee38c1bc0b11a8d3e63dce7050759b61864286 Author: Mikhail Gavrilov Date: Thu Sep 24 03:31:16 2026 +0500 x86/mm: Drop unnecessary PMD page copy when freeing On a box with a discrete GPU, lockdep reports a possible deadlock as soon as kswapd shrinks the TTM page pool. The immediate cause is an x86 commit that added an mmap_read_lock() to kernel page protection munging code. The huge vmap code holds the same lock over a GFP_KERNEL allocation, which is a no-no now that reclaim can take it. That allocation is in a page table *free* path and ends up being for dubious purposes[1]. Basically, it tries to avoid hardware setting Accessed=1 in page table entries that are unreachable by the hardware, a non-issue. Remove the PMD copy. Detach the original PMD page at the PUD, flush the mid-level caches, and free the PTE tables straight from the detached PMD page. With no allocation left, the locking issue is gone. Lockdep splat/analysis: WARNING: possible circular locking dependency detected 7.3.0-rc3-f6e7b42bf05b+ #183 Tainted: G U ------------------------------------------------------ kswapd0/269 is trying to acquire lock: ((init_mm).mmap_lock){++++}-{4:4}, at: change_page_attr_set_clr+0x29a/0x4a0 but task is already holding lock: (pool_shrink_rwsem){.+.+}-{4:4}, at: ttm_pool_shrink+0xb2/0x330 [ttm] Chain exists of: (init_mm).mmap_lock --> fs_reclaim --> pool_shrink_rwsem The cycle is built from three edges: 1) pool_shrink_rwsem -> (init_mm).mmap_lock The TTM shrinker restores the caching attribute of every page it frees, while holding pool_shrink_rwsem: ttm_pool_shrink() -> ttm_pool_dispose_list() -> ttm_pool_free_page() -> set_pages_wb() -> change_page_attr_set_clr() [ init_mm mmap read lock ] 2) fs_reclaim -> pool_shrink_rwsem The same shrinker, called from reclaim. 3) (init_mm).mmap_lock -> fs_reclaim ioremap() installing a huge PUD mapping over an existing PMD table: ioremap_page_range() -> vmap_range_noflush() -> vmap_try_huge_pud() [ init_mm mmap read lock ] -> pud_free_pmd_page() -> __get_free_page(GFP_KERNEL) [ enters reclaim ] [ dhansen: Lots of changelog munging/trimming and merged comments from my version of the fix. ] Fixes: d5d8b8662e6e ("x86/mm/pat: Acquire init_mm read lock on attribute changes to avoid UAF") Suggested-by: Pedro Falcato Signed-off-by: Mikhail Gavrilov Signed-off-by: Dave Hansen Reviewed-by: Pedro Falcato Link: https://lore.kernel.org/20260916062222.27347-1-mikhail.v.gavrilov@gmail.com Link: https://lore.kernel.org/all/e11449f0-d9ad-4d1b-ab21-2be7d71fe335@intel.com/ [1] Link: https://patch.msgid.link/20260923223116.20090-1-mikhail.v.gavrilov@gmail.com Cc: stable@vger.kernel.org commit de0be324fcb97a49caad131c23ad33265dd4b0b8 Author: Zhang Heng Date: Mon Sep 28 16:39:25 2026 +0800 ASoC: amd: acp-config: Add ACP70 DMI quirk for ASUS UM5406GA Add ASUS Zenbook S14 UM5406GA (Strix Point, ACP 7.0) to acp70_acpi_flag_override_table so that the broken BIOS acp-audio-config-flag is ignored and the default SoundWire enumeration path is used. Without this, no ASoC machine driver matches and internal speakers/mic fail to probe. Reported-by: Jannick Tobler Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222009 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260928083925.266471-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown commit 848a7a91c7f03675d3bd8db6f7721cbf9cb50e21 Author: Chengfeng Ye Date: Sun Sep 27 01:04:03 2026 +0800 Bluetooth: hci_core: Serialize SCO and ISO scheduling with teardown hci_low_sent() selects a connection under RCU but drops the read lock before calculating its quota and returning it to the scheduler. The connection is then used without lifetime protection by hci_sched_iso() and hci_sched_sco(). After the TX worker drops the RCU read lock, hci_abort_conn_sync() on hdev->req_workqueue can remove the connection from the hash, complete synchronize_rcu(), purge its queues and release it. The TX worker on hdev->workqueue can then access the freed connection in hci_quote_sent() or while dequeuing packets and updating conn->sent. KASAN reported: BUG: KASAN: slab-use-after-free in hci_low_sent+0x730/0x840 Workqueue: hci0 hci_tx_work Call Trace: hci_low_sent+0x730/0x840 hci_sched_iso+0x25e/0x4d0 hci_tx_work+0x239/0xcb0 Allocated by task 93: __hci_conn_add+0x16f/0x1b40 hci_bind_bis+0x782/0x17b0 hci_connect_bis+0xa0/0x510 iso_sock_connect+0x589/0x1050 Freed by task 88: kfree+0x131/0x3c0 device_release+0xc8/0x240 kobject_put+0x14d/0x280 hci_conn_del+0x55a/0xe80 hci_disconnect_sync+0x156/0x180 hci_abort_conn_sync+0x3e7/0x940 hci_cmd_sync_work+0x13c/0x290 Hold hci_dev_lock() across connection selection and transmission in both SCO and ISO scheduling, serializing them with connection teardown. This also prevents queuing completion timestamps after the connection queues have been purged. Extending RCU across transmission would be unsafe because the transmit path can sleep. Keep the ISO timeout check outside the mutex since hci_link_tx_to() takes it itself. The preceding channel fix already holds this mutex in the ACL and LE schedulers, which call the SCO scheduler between packets. Move the SCO body to __hci_sched_sco(), assert that its caller holds the mutex, and use it directly from these locked paths. Keep a locking hci_sched_sco() wrapper for the direct calls from hci_tx_work(). This avoids recursively acquiring the device mutex while preserving the scheduling order. Remove the obsolete claim that connection removal disables TX. Fixes: bf4c63252490 ("Bluetooth: convert conn hash to RCU") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz commit f4845ab191a4f686a5da481fbba90ed73bb693b0 Author: Chengfeng Ye Date: Sun Sep 27 01:04:02 2026 +0800 Bluetooth: hci_core: Serialize ACL scheduling with channel deletion hci_chan_sent() selects a channel under RCU but drops the read lock before accessing chan->conn and returning the channel. The ACL and LE schedulers then use its packet queue and update its transmit counters without any protection against channel deletion. After TX selects a channel and releases RCU, a disconnect command timeout on the separate request workqueue can run hci_conn_failed() and l2cap_conn_del(). hci_chan_del() can then unlink the channel, complete synchronize_rcu(), purge its queue and free it before TX resumes. This causes use-after-free both in hci_chan_sent() and in its callers. KASAN reported: BUG: KASAN: slab-use-after-free in hci_chan_sent+0x892/0x9b0 Workqueue: hci0 hci_tx_work Call Trace: hci_chan_sent+0x892/0x9b0 hci_tx_work+0x5e6/0xb70 Allocated by task 91: hci_chan_create+0xe3/0x350 l2cap_conn_add.part.0+0x12/0xa30 l2cap_chan_connect+0x110d/0x1b60 l2cap_sock_connect+0x310/0x530 Freed by task 99: hci_chan_del+0x11f/0x170 l2cap_conn_del+0x4f1/0x800 l2cap_connect_cfm+0x88c/0xd30 hci_conn_failed+0x150/0x250 hci_abort_conn_sync+0x3e3/0x800 hci_cmd_sync_run+0x7e/0xc0 hci_abort_conn+0x105/0x1f0 disconnect_sync+0x157/0x290 hci_cmd_sync_work+0x13c/0x290 Hold the existing device mutex across channel selection and transmission in both schedulers to serialize them with channel teardown. Keep timeout handling outside the critical sections because hci_link_tx_to() acquires the same mutex. This also permits the transmit path to sleep, unlike extending the RCU read-side critical section across packet submission. Fixes: 3eff45eaf817 ("Bluetooth: convert tx_task to workqueue") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz commit 81a2345f1984f0b36d3226571bc196316a01b648 Author: Chengfeng Ye Date: Sun Sep 27 14:42:50 2026 +0800 Bluetooth: Serialize SMP remote OOB data access build_pairing_cmd() looks up remote OOB data and copies its contents without holding hdev->lock, which serializes the list's writers. After SMP finds an entry, a concurrent management Remove Remote OOB Data command can unlink and free it before SMP reads its present flag or copies its random and confirmation values. Removal can also invalidate an entry while the lookup is still traversing the list. KASAN reported: BUG: KASAN: slab-use-after-free in build_pairing_cmd+0x948/0x9b0 Call Trace: build_pairing_cmd+0x948/0x9b0 smp_recv_cb+0x459f/0x8110 l2cap_recv_frame+0xf14/0x9190 l2cap_recv_acldata+0xa64/0xd40 hci_rx_work+0x4ca/0x730 Allocated by task 87: hci_add_remote_oob_data+0x11d/0x530 add_remote_oob_data+0x282/0x400 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 93: hci_remote_oob_data_clear+0x108/0x1c0 remove_remote_oob_data+0x198/0x220 hci_sock_sendmsg+0x1033/0x1ea0 Taking hdev->lock in build_pairing_cmd() would recurse for callers that already hold it and invert the device-to-L2CAP lock order on the receive path. Add a per-device remote_oob_lock instead, held across the SMP lookup and copies and by the add, remove and clear helpers. Cover initialization and in-place updates as well, so SMP cannot read partially initialized or updated OOB values. Release the mutex on allocation failure, preserving the existing error return. The new critical sections acquire no device, connection or channel locks. Writers retain their existing hdev->lock protection, which continues to serialize the other readers without changing their locking or behavior. Link: https://lore.kernel.org/r/00660cd3-7d71-13a4-f617-229e6defb701@gmail.com Fixes: 02b05bd8b0a6 ("Bluetooth: Set SMP OOB flag if OOB data is available") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz commit 2d696c1ed3468dcb62578a3911e687110d463520 Author: Chengfeng Ye Date: Sun Sep 27 01:27:23 2026 +0800 Bluetooth: RFCOMM: Fix initial port reference race For RFCOMM_RELEASE_ONHUP devices, rfcomm_tty_install() and __rfcomm_release_dev() both use RFCOMM_TTY_OWNED to decide who drops the initial tty_port reference. The release path tests the bit separately from the install path setting it, so both can drop that reference. The synchronous hangup does not prevent this race: port->tty is not assigned until tty_port_open(), after installation. The following interleaving is possible: 1. Install and release each obtain a reference with rfcomm_dev_get(). 2. Release observes RFCOMM_TTY_OWNED clear. 3. Install sets RFCOMM_TTY_OWNED and drops the initial reference. 4. Release drops the same initial reference again. 5. TTY cleanup drops its reference and frees the device. 6. Release performs its final tty_port_put() on the freed port. KASAN reported: BUG: KASAN: slab-use-after-free in tty_port_put+0x22/0x190 Write of size 4 at addr ffff8881001d3d5c by task poc/92 Call Trace: tty_port_put+0x22/0x190 rfcomm_dev_ioctl+0x1d4/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 88: rfcomm_dev_ioctl+0x8f6/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0 Freed by task 65: kfree+0x131/0x3c0 rfcomm_dev_destruct+0x23b/0x2f0 release_one_tty+0xc1/0x370 process_one_work+0x661/0x1090 Use test_and_set_bit() in both paths so that only the caller that changes RFCOMM_TTY_OWNED from clear to set drops the initial reference. Each path keeps its own lookup reference until release or TTY cleanup, preserving the existing callback ordering and error handling. Fixes: 80ea73378af4 ("Bluetooth: Fix unreleased rfcomm_dev reference") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz commit 8ed67535fdff40ca652bcd4ac7da68d11d01bd34 Author: Chengfeng Ye Date: Sun Sep 27 01:28:31 2026 +0800 Bluetooth: hci_sync: Fix inquiry cache use-after-free The sync command worker holds hdev->req_lock, but inquiry-cache updates and flushes use hdev->lock. Both hci_acl_create_conn_sync() and hci_stop_discovery_sync() look up entries and read their fields without taking hdev->lock. After either lookup returns, a concurrent HCIINQUIRY ioctl can acquire hdev->lock and flush the cache, freeing the entry. The worker then reads the freed entry while preparing a create-connection or remote-name-cancel command. The list traversal also races with cache updates and removal. KASAN reported these accesses: BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5f1/0x650 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_acl_create_conn_sync+0x5f1/0x650 hci_cmd_sync_work+0x13c/0x290 Allocated by task 90: hci_inquiry_cache_update+0x3e6/0x7d0 hci_inquiry_result_evt+0x3cb/0x560 Freed by task 93: hci_inquiry_cache_flush+0x111/0x2b0 hci_inquiry+0x2f2/0x780 hci_sock_ioctl+0x269/0x5f0 BUG: KASAN: slab-use-after-free in hci_stop_discovery_sync+0x3b1/0x3c0 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_stop_discovery_sync+0x3b1/0x3c0 hci_cmd_sync_work+0x173/0x300 Allocated by task 86: hci_inquiry_cache_update+0x483/0x940 hci_inquiry_result_evt+0x3cb/0x560 Freed by task 91: hci_inquiry_cache_flush+0x13e/0x2f0 hci_inquiry+0x2f2/0x780 hci_sock_ioctl+0x269/0x5f0 Hold hdev->lock across each lookup and all reads from its result. Copy the remote address before unlocking so discovery cancellation does not retain a cache entry pointer. Release the lock before sending synchronous HCI commands, since their completion handlers may need the same lock. Fixes: cf75ad8b41d2 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED") Fixes: 45340097ce6e ("Bluetooth: hci_conn: Only do ACL connections sequentially") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz commit b1f24c1ab52345e810c42a1a81286cb5a7c92252 Author: Nguyen Ngoc Thang Date: Sun Sep 27 22:18:02 2026 +0700 Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister hci_unregister_dev() disables cmd_work and cmd_timer, then calls hci_cmd_sync_clear(), whose cancel_work_sync() waits for hci_cmd_sync_work() to return. That worker dequeues and runs every entry on cmd_sync_work_list. With cmd_work disabled nothing reaches the controller, so each queued HCI command waits the full HCI_CMD_TIMEOUT (2s). The backlog has no bound. Userspace can keep queuing MGMT commands such as MGMT_OP_GET_CLOCK_INFO against a controller that doesn't answer. Closing /dev/vhci then blocks in vhci_release() for backlog * 2s: INFO: task syz-executor:5749 blocked for more than 143 seconds. cancel_work_sync hci_cmd_sync_clear hci_unregister_dev vhci_release In a local reproduction the backlog held more than 5000 entries, which comes to hours of hang. Stop the worker from taking new entries once HCI_UNREGISTER is set, and wake any request still waiting with -ENODEV before cancelling the work. The entries left over are destroyed with -ECANCELED by the existing sweep in hci_cmd_sync_clear(). They stay on the list until the work has stopped, so hci_cmd_sync_dequeue() and friends still see them. A callback already running may still issue another command, which delays unregister by at most one timeout per remaining command, not by the whole backlog. Fixes: 008ee9eb8a11 ("Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work") Reported-by: syzbot+217e3f1283cafe80586e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=217e3f1283cafe80586e Signed-off-by: Nguyen Ngoc Thang Signed-off-by: Luiz Augusto von Dentz commit 1a572db43c057566771b485598ad2e66cb390821 Author: Chengfeng Ye Date: Sun Sep 27 01:29:35 2026 +0800 Bluetooth: hci_core: Serialize fragmented ISO packet queueing The fragmented path in hci_queue_iso() calls __skb_queue_tail() without holding conn->data_q.lock. The socket lock serializes senders, but the transmit worker can concurrently remove packets from this queue using skb_dequeue(). After an insertion saves the old tail pointer, hci_sched_iso() can dequeue that packet and pass it to the driver. The driver can free the packet before the insertion resumes and writes to the old tail's next pointer, causing a use-after-free. Concurrent updates can also corrupt the queue. KASAN reported: BUG: KASAN: slab-use-after-free in hci_send_iso+0xc7d/0xe10 Call Trace: hci_send_iso+0xc7d/0xe10 iso_sock_sendmsg+0x710/0x900 __sys_sendto+0x34a/0x3a0 Allocated by task 86: __alloc_skb+0xdd/0x820 alloc_skb_with_frags+0x7e/0x770 sock_alloc_send_pskb+0x67a/0x820 bt_skb_sendmsg.constprop.0+0xc0/0x6c0 iso_sock_sendmsg+0x44e/0x900 Freed by task 90: kmem_cache_free+0xcb/0x3d0 vhci_read+0x33f/0x4d0 vfs_read+0x177/0xa20 Hold the queue lock across the entire fragment batch, as hci_queue_acl() does, to serialize insertion against dequeue while preserving fragment ordering. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz commit 024e05f73a4c1263d031614bc36700ec135eecb4 Author: Chengfeng Ye Date: Sun Sep 27 19:04:50 2026 +0800 Bluetooth: hci_conn: Lock parent access during enhanced SCO setup Bluetooth: hci_conn: Lock parent access during enhanced SCO setup hci_enhanced_setup_sync() runs on the request workqueue without the hci_dev_lock held by its caller when setup was queued. Its CVSD capability check and find_next_esco_param() dereference conn->parent while the receive workqueue can unlink and release that parent. The following interleaving can cause a use-after-free: hci_enhanced_setup_sync() hci_disconn_complete_evt() load conn->parent hci_dev_lock() hci_conn_del(ACL parent) unlink SCO child drop link's parent reference clear child->parent release ACL parent bt_link_release() kfree(parent) hci_dev_unlock() read parent->features[0][3] The reference held for the queued SCO child does not keep its ACL parent alive after unlinking. Commit 42de40abe25d ("Bluetooth: hci_conn: fix the SCO setup context lifetime") protects the child stored in the queued context, but leaves these parent accesses unprotected. With a 40 ms diagnostic delay after loading conn->parent, an instrumented kernel based on fd179f8a05be, which already contains 42de40abe25d, reported: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0xda5/0xdf0 Read of size 1 at addr ffff888102204047 by task kworker/u17:0/93 Call Trace: hci_enhanced_setup_sync+0xda5/0xdf0 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x6b4/0x10e0 Allocated by task 92: __hci_conn_add+0x304/0x1df0 hci_connect_acl+0x349/0x3e0 hci_connect_sco+0x3b/0x9a0 sco_sock_connect+0x475/0xca0 Freed by task 94: kfree+0x121/0x3c0 bt_link_release+0x79/0xa0 device_release+0xc8/0x240 kobject_put+0x14d/0x280 hci_conn_del+0x524/0xe30 hci_disconn_complete_evt+0x403/0x8c0 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 The accessed address is 71 bytes into the freed ACL parent, at its features[0][3] byte; the queued SCO child is a different object. The diagnostic preserves the loaded parent across the delay, matching the unmodified compiled capability check, and does not change the parent references or teardown path. Hold hci_dev_lock() across the codec switch, including every call to find_next_esco_param(), and release it on all selection errors. Keep configure_datapath_sync() outside the critical section because it waits for HCI events. Preserve parameter selection and existing return values. Fixes: e07a06b4eb41 ("Bluetooth: Convert SCO configure_datapath to hci_sync") Cc: stable@vger.kernel.org Assisted-by: GPT-6-Astra Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz commit e78a9fb7a40c55ec2a70ae39903dde4f898af2ef Author: Ian Forbes Date: Wed Sep 16 14:01:44 2026 -0500 drm/vmwgfx: Add blend mode property This stops the log spamming introduced by the referenced fixes commit. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Signed-off-by: Ian Forbes Reviewed-by: Zack Rusin Signed-off-by: Zack Rusin Link: https://patch.msgid.link/20260916190144.2080777-1-ian.forbes@broadcom.com commit 21bc51cb89ced74d6645a138cc2f21184bc75094 Author: Zack Rusin Date: Sun Aug 9 16:45:15 2026 -0400 drm/vmwgfx: validate pitch coming from userspace 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 commit 3a3d93070c5ec8b8049d57025987ba313420bda9 Author: lollipopkit Date: Sun Sep 27 15:42:06 2026 +0800 io_uring/cmd_net: end TX_TIMESTAMP multishot when the CQ is full SOCKET_URING_OP_TX_TIMESTAMP arms an EPOLLERR apoll multishot and, on each error queue edge, posts one 32 byte aux CQE per timestamp skb. Aux CQEs have no overflow backing, so io_uring_cmd_post_mshot_cqe32() fails once the CQ ring is full. The loop then stops, splices the unprocessed skbs back onto sk_error_queue and returns -EAGAIN. -EAGAIN is IOU_RETRY, so the request goes idle until the next poll event. io_arm_apoll() forces EPOLLET and draining the CQ does not re-run the command, so the spliced-back timestamps stay queued until an unrelated later timestamp produces a new edge. End the multishot when a CQE cannot be posted, as multishot poll and recv already do. There is no partial result to report, so complete with -ENOBUFS: no CQ space is left for the timestamp CQEs. This command does not use provided buffers, so the value cannot be confused with a buffer ring running empty. The terminal CQE still reaches userspace because request completions can go to the overflow list. The application sees a CQE without IORING_CQE_F_MORE, which it already has to handle, and the first issue of the re-armed request delivers the queued timestamps. A timestamp that cannot be extracted keeps its current behaviour. This was found with LLM assistance while reviewing io_uring multishot handlers for the pattern behind a RECV_ZC stall reported earlier (see Link), and confirmed with a reproducer on v7.3-rc2 and an A/B run of this patch. Fixes: 9e4ed359b8ef ("io_uring/netcmd: add tx timestamping cmd support") Link: https://lore.kernel.org/all/010001a0cd914529-23df2f94-bbe0-49cd-ae5d-05922356fa12-000000@email.amazonses.com/ Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-6-sol Assisted-by: Claude:claude-opus-5-5 Signed-off-by: lollipopkit Reviewed-by: Pavel Begunkov Link: https://patch.msgid.link/20260927074206.65427-1-a@lolli.tech Signed-off-by: Jens Axboe commit 98ad5b63f5041dc354a6e694f4a9436f74e0681b Author: Junyuan Feng Date: Wed Sep 23 09:20:44 2026 +0000 io_uring/zcrx: requeue multishot receives stopped by a local resource A multishot RECV_ZC can go idle with unread TCP data when a receiver-local resource runs out. An empty copy-fallback niov freelist returns -ENOMEM; a full CQ returns -ENOSPC. After partial progress the stop reason is lost: io_zcrx_copy_chunk() and io_zcrx_recv_skb() report the copied bytes, and tcp_read_sock() drops an error from a later call once earlier data was consumed. The edge-triggered request is then not requeued, so it cannot consume the remaining data until another socket event arrives. Record in io_zcrx_recv_skb() when a walk stops before consuming the length it was offered, and requeue if the pass still returned data. The failed chunk is first on the next pass. The resource is usually still exhausted by then, so that pass fails at once and ends the request with an error CQE, which the application must handle by re-arming. The request does not spin, and the stall becomes a visible error. Keep the existing skb limit and SOCK_DONE handling. Fixes: 11ed914bbf94 ("io_uring/zcrx: add io_recvzc request") Fixes: bc57c7d36c4c ("io_uring/zcrx: add copy fallback") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-6-sol Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Junyuan Feng Reviewed-by: Pavel Begunkov Link: https://patch.msgid.link/010001a0cd914529-23df2f94-bbe0-49cd-ae5d-05922356fa12-000000@email.amazonses.com Signed-off-by: Jens Axboe commit 72207463f7a4a6818a88f4ef57802b42da534301 Author: Marcin Bernatowicz Date: Fri Sep 18 13:01:30 2026 +0200 drm/xe/pf: Keep VF LMEM BAR size low if no VFs enabled When VFs are enabled on dGFX the driver resizes the PF VF_LMEM_BAR to fit the requested layout. After VFs are disabled the PF VF BAR size is left as-is. On platforms with tight MMIO apertures a subsequent unplug/rescan followed by another enable may fail with: "VF BAR …: can't assign; no space" because the PCI core reserves address space based on the (now large) VF template, often multiplied by totalvfs. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5937 Fixes: 94eae6ee4c2d ("drm/xe/pf: Set VF LMEM BAR size") Signed-off-by: Marcin Bernatowicz Cc: Michał Wajdeczko Cc: Michał Winiarski Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260918110130.700332-1-marcin.bernatowicz@linux.intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit 0646547a67d25c407f5a4ac71b4eefe8b941202b) Signed-off-by: Rodrigo Vivi commit 74dae5f33c0c64d3ca12710bfd845721d73fe2e5 Author: Michal Wajdeczko Date: Fri Sep 11 20:23:06 2026 +0200 drm/xe/pf: Refactor VF LMEM BAR resize helper function Improve and move diagnostics messages to the helper function to keep the caller function tidy. Signed-off-by: Michal Wajdeczko Reviewed-by: Michał Winiarski Link: https://patch.msgid.link/20260911182306.14973-1-michal.wajdeczko@intel.com (cherry picked from commit 10628c52a3732a10426499a3d462cc2e6bc371ae) Signed-off-by: Rodrigo Vivi commit f090e7ff26fe08be4cd57e0950872ede4af5351a Author: Bartosz Brom Date: Mon Sep 28 15:43:35 2026 +0200 ALSA: hda/realtek: Add mute LED quirks for HP Pavilion 15-eh3174nw and HP Laptop 15-dw1xxx The HP Pavilion 15-eh3174nw with an ALC287 codec requires the ALC287_FIXUP_HP_GPIO_LED fixup for its mute LED to work correctly. Add subsystem ID 0x103c:0x8bc7 to the quirk table to apply the existing fixup. Tested on an HP Pavilion 15-eh3174nw; the mute LED now follows the speaker mute state. The HP Laptop 15-dw1xxx with an ALC236 codec requires the ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO fixup for its mute LED to work correctly. Add subsystem ID 0x103c:0x85f1 to the quirk table to apply the existing fixup. Tested on an HP Laptop 15-dw1xxx; the mute LED now follows the speaker mute state. Signed-off-by: Bartosz Brom Link: https://patch.msgid.link/20260928134335.1875-1-bartosz.brom06@gmail.com Signed-off-by: Takashi Iwai commit 102cf5919986412422a92c8cf35616827592dcbf Merge: d431e03d831c04 4a5e49ba0abb8b Author: Jens Axboe Date: Mon Sep 28 07:47:39 2026 -0600 Merge tag 'nvme-7.3-2026-09-25' of git://git.infradead.org/nvme into block-7.3 Pull NVMe fixes from Keith: "- Fix use-after-free of the command effects log on multipath heads - Fix target namespace disable race with in-flight I/O and attribute changes - Fix out-of-bounds write in in-band authentication - Fix out-of-bounds reads parsing SGL segments and ANA logs - Fix zoned limits on multipath heads when the zone info query fails - Fix reservation preempt and abort matching against a nil host id - Fix lockdep key lifetime by reverting the per-socket dynamic keys and delaying socket reclassification past the TLS handshake - Fix controller reset and delete races that trigger spurious warnings - Add a dma pool alignment quirk for the Micron 4100AT - Preserve the target namespace device path on allocation failure - Fix -Wformat-security build warnings" * tag 'nvme-7.3-2026-09-25' of git://git.infradead.org/nvme: nvme-multipath: set BLK_FEAT_ZONED only after the zone info is known nvme: fix command effects log lifetime for multipath heads nvmet: don't allow I/O admission after percpu ns reference is killed nvmet: defer setting ns->enabled to false in nvmet_ns_disable() nvmet: copy the hostid into the ctrl before creating PR pc_refs nvmet-auth: fix out-of-bounds write in nvmet_auth_challenge() nvmet: pci-epf: reject too-short SGL segments nvme-multipath: fix underflow in ANA log bounds checks nvme: work around all -Wformat-security warnings nvme: work around -Wformat-security warning nvme: do not reset controllers in NVME_CTRL_NEW state nvme-tcp: delay nvme_tcp_reclassify_socket() Revert "nvme-tcp: lockdep: use dynamic lockdep keys per socket instance" nvmet: preserve device path on allocation failure nvme-fc: do not warn on controller removal race nvme-pci: add NVME_QUIRK_DMAPOOL_ALIGN_512 for Micron 4100AT commit 4c66c423593e26273ea0d644906ed007630c6f6d Author: Shawn Lin Date: Mon Sep 21 14:52:52 2026 +0800 pmdomain: rockchip: don't ignore clock lookup errors on attach 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 commit d8b3847770661b7109146e6479eeadcdab9cecf0 Author: Shawn Lin Date: Mon Sep 21 14:52:51 2026 +0800 pmdomain: rockchip: fix clock leak on domain probe failure 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 commit 4c0d69d677cf5b0065ebbb3ceb8ba66fddbec630 Author: Shawn Lin Date: Mon Sep 21 14:52:50 2026 +0800 pmdomain: rockchip: propagate subdomain add errors 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 commit c26d18964a9352e83cb5fdd7b327d9a2566abddf Author: Charles Keepax Date: Mon Sep 28 11:56:10 2026 +0100 ASoC: Intel: Add quirk to block match table for Lenovo Yoga Slim 7 A variant of the Lenovo Yoga Slim 7 exists on Lunar Lake that doesn't have a physical jack socket. Cirrus codecs still use match tables on LNL but the match table makes no distinction between a system with or without a jack. This leads to the system failing probe as the jack in the topology file is not matched by a DAI link as the machine driver is constructed. Add a new quirk to block using match tables for specific devices, and rely on function topologies which can handle this difference seamlessly. This is slightly preferred over moving everything to function topologies due to the lower chance of causing regressions on other systems. Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260928105610.242687-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown commit c748c42abb9b549fc79c41ea55e1f220eadb60ec Author: Krish Gulati Date: Mon Sep 21 18:47:03 2026 +0530 ALSA: hda/realtek: Add mute LED quirk for HP Victus 15-fb2xxx The HP Victus 15-fb2xxx (PCI SSID 103c:8c2f) with the ALC245 codec does not turn on the mute LED when audio is muted. Add a quirk entry to enable it. Reported-by: erph.briones27@gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=221946 Signed-off-by: Krish Gulati Tested-by: Raphael Briones Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260921131728.8999-1-krishgulati7@gmail.com commit 0d90a929836344f1d3b39f22f08ccecc62378a59 Author: Zhang Heng Date: Mon Sep 21 20:44:50 2026 +0800 ALSA: hda/realtek: Add quirk for Acer Nitro AN515-45 The Acer Nitro AN515-45 requires ALC2XX_FIXUP_HEADSET_MIC to make the headset microphone work properly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221925 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260921124450.639601-2-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai commit 4322ac247f4ce7932edbd46aa37f3dae62cde424 Author: Zhang Heng Date: Mon Sep 21 20:44:49 2026 +0800 ALSA: hda/realtek: Add quirk for Lenovo ThinkBook G8+ Fix Bass Speaker volume control on Lenovo ThinkBook G8+ by adding quirk 17aa:38dc with ALC285_FIXUP_SPEAKER2_TO_DAC1. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221799 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260921124450.639601-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai commit 608c0c8947f03069b651ace54538a115f5b23123 Author: Kailang Yang Date: Thu Sep 17 14:53:26 2026 +0800 ALSA: hda/realtek - Add headset mode for Dell Pro QC1255 It lost its headset microphone functionality, and this patch will restore it. Fixes: 97272a5704bf ("ALSA: hda/realtek - Fixed Headphone noise issue for Dell QCM1255") Signed-off-by: Kailang Yang Link: https://lore.kernel.org/3c251e40a2944ae4ae479e4c2e4e63a4@realtek.com Signed-off-by: Takashi Iwai commit 89365897f4210979966aa808d7b013edf4080558 Author: Aaron Kling Date: Sat Sep 26 02:24:19 2026 -0500 ALSA: hda/tegra: Re-enable SDO workaround for Tegra194 This workaround was originally added for Tegra194, but no longer gets applied for it. Commit 615d43540043 ("ALSA: hda/tegra: fix tegra-hda on tegra30 soc") changed the guard to tegra30-hda, which worked because all affected archs had the fallback compatible. However, commit 7f0ea5acfc19 ("arm64: tegra: Use correct compatible string for Tegra194 HDA") removed the fallback compatible for Tegra194, causing this to break. Fixes: 7f0ea5acfc19 ("arm64: tegra: Use correct compatible string for Tegra194 HDA") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Aaron Kling Link: https://patch.msgid.link/20260926-tegra194-hda-sdo-v1-1-f7a636a07a58@gmail.com Signed-off-by: Takashi Iwai commit ca51771c8efde5df05476ac98dd1b2af4e2b149f Author: Zimeng Li Date: Sun Sep 27 09:09:11 2026 +0800 ASoC: qcom: lpass-cpu: use DAI table index for playback constraints The DAI ID is a hardware port ID and is not necessarily the index of the corresponding entry in variant->dai_driver. When configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01, the probe code currently uses dai_id to index variant->dai_driver. This is incorrect for platforms where DAI IDs are sparse. For example, the IPQ806x MI2S DAI has ID 4 while it is the only entry in the DAI driver table. If that DAI is configured for QUAD01 and probe reaches this branch, the code writes beyond that single entry via dai_driver[4] instead of updating the DAI being processed. Use the loop index i when updating the current DAI's playback channel constraints, while retaining dai_id for indexing the hardware-port specific playback SD-line mode array. This fixes the incorrect DAI table access for platforms where the DAI ID does not match its position in the driver table. Fixes: c223f41c1a52 ("ASoC: qcom: Add four speaker support on MI2S secondary") Cc: stable@vger.kernel.org Signed-off-by: Zimeng Li Assisted-by: LLM-assisted source analysis Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260927010911.51980-1-me@lizi.moe Signed-off-by: Mark Brown commit 0b7bd20f6379bc5e431fd74d866390f5b5b63f3c Author: Nguyen Ngoc Thang Date: Sat Sep 26 00:07:17 2026 +0700 ALSA: caiaq: unregister the input device when probe fails setup_card() registers the input device, whose name and phys point into struct snd_usb_caiaqdev, and then goes on to snd_card_register() and snd_usb_caiaq_control_init(). If either fails, snd_probe() calls snd_card_free(), which frees the device state but leaves the input device registered: card_free() only clears the pointer, and the input device is unregistered from snd_disconnect() alone. Reading its "uevent" attribute afterwards dereferences freed memory: BUG: KASAN: slab-use-after-free in string+0x4a9/0x4f0 Read of size 1 at addr ffff8880208f5043 by task caiaq/4967 add_uevent_var+0x183/0x3a0 input_dev_uevent+0x162/0x900 dev_uevent+0x2f1/0x870 uevent_show+0x1ca/0x3a0 ... Unregister the input device on the probe error path, as snd_disconnect() does. snd_usb_caiaq_input_disconnect() is a no-op when no input device was registered. Reproduced with a raw-gadget Audio Kontrol 1 and a temporary hack that makes snd_usb_caiaq_control_init() fail. Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Cc: stable@vger.kernel.org Reported-by: syzbot+2a123f6269da57ffefaa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2a123f6269da57ffefaa Signed-off-by: Nguyen Ngoc Thang Link: https://patch.msgid.link/20260925170717.22462-1-ngocthang2710.1999@gmail.com Signed-off-by: Takashi Iwai commit 7b457ae8cf711831f19d20963f5ed2fdf4842d3a Author: Tomasz Bojanowski Date: Wed Sep 23 20:49:57 2026 +0200 ALSA: usb-audio: Add mixer mapping for MSI MAG B850M MORTAR WIFI The USB audio device 0db0:cc78 (Realtek ALC4080) on the MSI MAG B850M MORTAR WIFI motherboard exposes all playback controls as "PCM", which makes it hard to tell the outputs apart. Its mixer layout matches the one of the MSI MPG X570S Carbon Max Wifi (units 29, 30 and 32), so reuse msi_mpg_x570s_carbon_max_wifi_alc4080_map for this device too. With the mapping applied, the controls show up as "Speaker", "Front Headphone" and "IEC958". Tested with a patched snd-usb-audio module on a 7.2.7 kernel. Signed-off-by: Tomasz Bojanowski Link: https://patch.msgid.link/20260923184957.6687-1-tomasz@bojanowski.me Signed-off-by: Takashi Iwai commit 2a8ee6897302ca12ff39e8eb180503956797c60c Author: Yu-Hsiang Tseng Date: Wed Sep 23 22:13:44 2026 +0800 ALSA: hda/realtek: Fix silent speaker on Higole F9B The Higole F9B is an Alder Lake-N mini PC with a 7" touchscreen and an ALC269VC codec (subsystem ID 0x10ec111e). Its DMI strings are all "Default string", so the SSID is the only way to identify it. The internal speaker is silent out of the box. The generic parser assigns DAC 0x03 to the speaker pin 0x14 and DAC 0x02 to the headphone pin 0x15, but the speaker only reproduces what DAC 0x02 plays, whatever its connection selection says. Checked one path at a time, only the gain of DAC 0x02 and the mute of pin 0x14 change what comes out of the speaker. User space only knows the path it was told the speaker uses, so selecting the speaker turns the path that actually reaches it all the way down. Route both 0x14 and 0x15 through mixer 0x0c (DAC 0x02), which is what ALC290_FIXUP_MONO_SPEAKERS already does. Tested on the device: the speaker plays. Cc: Assisted-by: LLM Signed-off-by: Yu-Hsiang Tseng Link: https://patch.msgid.link/20260923141344.1543158-1-asas1asas200@gmail.com Signed-off-by: Takashi Iwai commit cfc0a117d773eb585ca7e87d20c50d1c415058e5 Author: Zhang Heng Date: Wed Sep 23 20:16:40 2026 +0800 ALSA: hda/realtek: Fix square wave output on ASUS Strix G615LR ASUS ROG Strix G16 G615LR (PCI SSID 1043:3f20) outputs a loud full-scale square wave from internal speakers since the TAS2781 amplifier driver started loading. The quirk was using ALC287_FIXUP_TXNW2781_I2C which chains to the ThinkPad headset jack fixup, but this is an ASUS device that should use ALC287_FIXUP_TXNW2781_I2C_ASUS which chains to ALC294_FIXUP_ASUS_SPK for proper EAPD and pin configuration. Fixes: f7cede182c96 ("ALSA: hda/realtek: Add Asus quirk for TAS amplifiers") Cc: stable@vger.kernel.org Cc: Baojun Xu Cc: Antheas Kapenekakis Reported-by: Aleksei Arsenev Link: https://bugzilla.kernel.org/show_bug.cgi?id=222045 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260923121640.272509-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai commit a01a223bd685be42e908d970de32eeb3646097f3 Author: Tarun Noonemunthala Date: Wed Sep 23 15:10:14 2026 +0530 ALSA: hda/realtek: Add quirk for HP ENVY 13-aq1xxx The HP ENVY Laptop 13-aq1xxx (PCI SSID 103c:86ad) uses an ALC285 codec with two speaker pairs: front (pin 0x14) and bottom (pin 0x17). The BIOS leaves pin 0x14 as [N/A] ("not connected"), so the generic parser never enables the front pair and only the bottom speakers are audible. The vendor driver (RTKVHD64.sys) programs that pin with the value 0x90170150 and runs the HP amplifier initialization, which is already implemented in the driver as ALC285_FIXUP_HP_GPIO_AMP_INIT. Add a board fixup that applies the pin configuration for 0x14 and chains to the existing amplifier init fixup. The pin value was recovered from the vendor driver's own configuration data. The patch and this changelog were prepared with an AI coding assistant (see the Assisted-by tag below); the change was reviewed and tested by the submitter on the affected machine. Tested on an HP ENVY 13-aq1xxx by rebuilding snd-hda-codec-alc269 from the Fedora 7.1.10 source and loading it: the codec now reports "line_outs=2 (0x14/0x17)", pin 0x14 comes up as an output (Pin-ctls 0x40) with its amplifier unmuted, and both speaker pairs play. Assisted-by: OpenCode:deepseek-v4.1-flash checkpatch Signed-off-by: Tarun Noonemunthala Link: https://patch.msgid.link/20260923094014.58867-1-ntarun2000@gmail.com Signed-off-by: Takashi Iwai commit d49f8d9680ee3f7f4e0339467cf0a244158c1adb Author: Roman Bolotov Date: Wed Sep 23 09:45:27 2026 +0300 ALSA: usb-audio: Add quirk flag for ASUS SupremeFX Hi-Fi The ASUS SupremeFX Hi-Fi (0b05:1826, 0b05:1827) does not survive USB autosuspend. After a suspend/resume cycle the firmware degrades: HID probes begin to fail and the descriptors it returns become corrupted, until the device stops responding entirely and needs a physical power cycle to recover. Add QUIRK_FLAG_DISABLE_AUTOSUSPEND for both product IDs. Verified on 7.2.6 through the quirk_flags module parameter, with no code change, and with the local udev rules that had been forcing power/control commented out, so the parameter was the only mechanism in play. Both IDs were passed as 0b05:1827:disable_autosuspend;0b05:1826:disable_autosuspend The device then stayed awake across 2.5 hours (runtime_suspended_time remained 0), survived a system suspend/resume cycle, and continued to work afterwards with no failed probes and no power cycle needed. Signed-off-by: Roman Bolotov Link: https://patch.msgid.link/20260923064527.434441-1-hadros@ikeepitoblique.com Signed-off-by: Takashi Iwai commit 3867e38b2d4b844d89076f988c7b9741c87a9858 Author: KIM MinWoo Date: Wed Sep 23 10:37:56 2026 +0900 ALSA: hda/realtek: Add quirk for Lenovo ThinkBook 16p Gen 3 ARH (21EK) The ThinkBook 16p Gen 3 ARH (SSID 17aa:3871) has a TI TAS2563 amplifier device on I2C, exposed by ACPI as INT8866, the same arrangement as the Yoga 7 14ARB7 (SSID 17aa:3870). Without a quirk, the codec falls back to the vendor-wide Lenovo quirk (ALC269_FIXUP_LENOVO_XPAD_ACPI), the amplifier is never bound, and the internal speakers stay silent while the headphone output works. Reuse the Yoga 7 14ARB7 fixup, which binds the INT8866 device as a side codec. ALC287_FIXUP_TAS2781_I2C does not work on this machine because it looks for a TIAS2781 device. Assisted-by: LLM Signed-off-by: KIM MinWoo Link: https://patch.msgid.link/20260923013756.106033-1-phrimm136@gmail.com Signed-off-by: Takashi Iwai commit 775aa96c310d59f3d15a6e5a9bd1796fd1ba95ec Author: Luis Banha Date: Tue Sep 22 00:01:05 2026 +0100 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-ec1xxx The mute LED on the HP Pavilion Gaming Laptop 15-ec1xxx (103c:87b2) does not work automatically. Add the ALC285_FIXUP_HP_MUTE_LED quirk to fix this behavior. Signed-off-by: Luis Banha Link: https://patch.msgid.link/20260921230105.16844-1-luisbanha26@gmail.com Signed-off-by: Takashi Iwai commit 786fb6b3f513937f712db5a9ba6a12cbc6982ba9 Author: Hernan Ganzo Date: Mon Sep 21 21:55:38 2026 +0100 ALSA: hda/realtek: Limit internal mic boost on HP Pavilion 15 (103c:2164) The HP Pavilion 15 with the ALC3227 codec (SSID 103c:2164) exposes the full four-step internal mic boost on pin 0x12: nsteps=3 with stepsize=0x2f, that is 0, 12, 24 and 36 dB. Combined with the ADC capture gain of +30 dB the analogue cascade reaches 66 dB, and the internal microphone clips on the ambient noise of a quiet room; the upper two steps are unusable at any useful input level. This is the defect class ALC269_FIXUP_LIMIT_INT_MIC_BOOST exists for. The machine matches no SSID quirk and falls through to the pin table, which selects ALC269_FIXUP_HP_MUTE_LED_MIC1 through a pin signature shared with several other HP models. Add an SSID entry instead, using ALC269_FIXUP_LIMIT_INT_MIC_BOOST_MUTE_LED: the existing fixup that applies alc269_fixup_limit_int_mic_boost() and chains to the same mute LED fixup, as already done for 103c:218b. The boost becomes 0 or 12 dB and the LED handling is unchanged. Tested on the affected machine by selecting the same fixup through the model string (snd-hda-intel.model), which bypasses the SSID and pin tables, with the driver confirming the selection: snd_hda_codec_alc269 hdaudioC1D0: ALC3227: picked fixup limit-mic-boost (model specified) With that, Internal Mic Boost reports Limits 0 - 1 (0 or 12 dB) instead of 0 - 3 (0 to 36 dB), so alc269_fixup_limit_int_mic_boost() clamps this codec's internal mic pin as intended. Note that /proc/asound/card1/codec#0 keeps printing the unclamped hardware caps (nsteps=0x03): that file reads codec parameters uncached by design, while the fixup overrides the driver's cached parameter that the control is built from. This does not by itself make the default capture volume sane -- the remaining 12 dB on top of the +30 dB ADC gain is still hotter than this machine's usable operating point. It removes the two unusable steps from the hardware range, which is what a quirk of this class can do. Signed-off-by: Hernan Ganzo Link: https://patch.msgid.link/20260921205538.41192-1-gp@sneemgp.com Signed-off-by: Takashi Iwai commit d24b03248ac6f02fb87feff6beec0b5b1da5dafd Author: Achilles Zhang Date: Mon Sep 21 10:43:43 2026 +0800 ALSA: usb-audio: Add native DSD quirk for HiBy FC4 The HiBy FC4 with USB ID 32bb:0004 advertises its native DSD stream as UAC2 RAW_DATA with a 4-byte, 32-bit subslot. Without a quirk snd-usb-audio leaves this alternate setting as SNDRV_PCM_FORMAT_SPECIAL, so userspace cannot select a native DSD format. Mark the device with QUIRK_FLAG_DSD_RAW so the existing generic raw DSD handling exposes the stream as DSD_U32_BE. Tested on an FC4 at DSD256. With the quirk the playback alternate setting changes from SPECIAL to DSD_U32_BE and reports DOP=0, bitrev=0; native DSD256 playback works correctly. Signed-off-by: Achilles Zhang Link: https://patch.msgid.link/20260921024344.391912-1-bnqzzdf@gmail.com Signed-off-by: Takashi Iwai commit f4b506f735e3c24c4fd4d3a60239e0b1b241600e Author: Matt Barr Date: Mon Sep 21 17:48:12 2026 -0400 ALSA: hda/realtek: Drop Yoga Pro 9 16IAH10 PCI SSID quirk The PCI SSID quirk added for the Lenovo Yoga Pro 9 16IAH10 (PCI SSID 17aa:3846, codec SSID 17aa:3920) also matches every other machine that shares PCI SSID 17aa:3846. snd_hda_pick_fixup() tries all PCI SSID entries before it falls back to the codec SSID, so those machines now get ALC287_FIXUP_YOGA9_SPEAKER2_TO_DAC1 and never reach their own codec-SSID quirk. The Lenovo Legion Pro 7 16IRX8H (product 82WQ) is one such machine: PCI SSID 17aa:3846, codec SSID 17aa:3884. Before this quirk it picked ALC287_FIXUP_TAS2781_I2C via the 17aa:3884 codec SSID fallback and bound its TAS2781 amplifier. With it, the codec never binds the amplifier and the internal speakers are silent: snd_hda_codec_alc269 hdaudioC0D0: ALC287: picked fixup for PCI SSID 17aa:3846 versus, on a kernel without the quirk: snd_hda_codec_alc269 hdaudioC0D0: ALC287: picked fixup for codec SSID 17aa:3884 snd_hda_codec_alc269 hdaudioC0D0: bound i2c-TIAS2781:00 (ops tas2781_hda_comp_ops ...) Drop the PCI SSID entry. The Yoga Pro 9 16IAH10 has the same amplifier as the Yoga S990-16 (codec SSID 17aa:3920), so it still gets a fixup through the codec SSID fallback, using the existing 17aa:3920 entry. Switch that entry from ALC287_FIXUP_TXNW2781_I2C to ALC287_FIXUP_YOGA9_SPEAKER2_TO_DAC1, which applies the DAC routing fix and then chains to ALC287_FIXUP_TXNW2781_I2C, so the amplifier setup is unchanged. Fixes: 41d60cbfde10 ("ALSA: hda/realtek: Fix bass speaker DAC routing for Lenovo Yoga Pro 9 16IAH10") Link: https://bugzilla.kernel.org/show_bug.cgi?id=220540 Suggested-by: Zhang Heng Signed-off-by: Matt Barr Link: https://patch.msgid.link/20260921214812.22139-1-matthewjaybarr@gmail.com Signed-off-by: Takashi Iwai commit 61b0a5a114fa4552892da5c0ff2f42e63bf08c6b Author: Xiang Mei Date: Fri Sep 18 16:40:14 2026 -0700 ALSA: line6: reject oversized playback packets Each playback URB is handed a slice of out.buffer that is exactly LINE6_ISO_PACKETS * max_packet_size_out bytes, sized from the OUT endpoint, but the number of bytes written into that slice is never compared against it. submit_audio_out_urb() takes the frame count from prev_fsize, which audio_in_callback() derived from the *IN* endpoint's received packet length, and rescales it with the playback frame size; when prev_fsize is still zero it synthesizes a length from the sample rate instead. On a device declaring a large IN wMaxPacketSize and a small OUT wMaxPacketSize, the resulting memcpy(), or the memset() when the playback stream is idle, runs past its slice and, as the reproducer below shows, beyond the allocation. usb_submit_urb() is not a backstop. max_packet_size_out comes from usb_maxpacket(), which returns only the low 11 bits of wMaxPacketSize, while USB core validates a high-speed isochronous length against that base scaled by usb_endpoint_maxp_mult(). A length of up to three times the allocated slice is therefore accepted, and even a rejected URB is only rejected after the write. Reject a packet that does not fit the slice the driver allocated for it. Clamping it instead would silently shorten the capture-derived rate feedback and desynchronize the two streams. BUG: KASAN: slab-out-of-bounds in submit_audio_out_urb (sound/usb/line6/playback.c:229) Write of size 1024 at addr ffff888100bbd400 by task kworker/1:2/5002 Workqueue: events line6_startup_work Call Trace: __asan_memcpy (mm/kasan/shadow.c:106) submit_audio_out_urb (sound/usb/line6/playback.c:229) line6_submit_audio_out_all_urbs (sound/usb/line6/playback.c:291) line6_stream_start (sound/usb/line6/pcm.c:194) line6_pcm_acquire (sound/usb/line6/pcm.c:337) line6_startup_work (sound/usb/line6/driver.c:728) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address belongs to the object at ffff888100bbd400 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes inside of allocated 256-byte region [ffff888100bbd400, ffff888100bbd500) Cc: stable@vger.kernel.org Fixes: 7a0f55aeeb8f ("ALSA: line6: Support assymetrical in/out configurations") Reported-by: Assisted-by: LLM Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260918234014.1318325-1-xmei5@asu.edu Signed-off-by: Takashi Iwai commit 86f86e6fdedc33c5b8d38b9208b350f8accf57ee Author: Xiang Mei Date: Fri Sep 18 15:57:53 2026 -0700 ALSA: ua101: reject mismatched capture/playback packet sizes detect_usb_format() cross-checks bSubframeSize, bBitResolution and tSamFreq between the capture and playback interfaces, but never relates the two endpoints' wMaxPacketSize and bNrChannels. Each playback URB gets a buffer of ua->playback.max_packet_bytes, while the number of bytes written into it is derived from the capture stream: capture_urb_complete() computes frames from the received capture packet and capture.frame_bytes, and start_usb_playback() and playback_work() multiply that by playback.frame_bytes. A device declaring a large capture wMaxPacketSize with few capture channels and a small playback wMaxPacketSize with many playback channels therefore memset()s and memcpy()s past the end of the playback buffer, in open() of the PCM node the driver registers during probe. usb_submit_urb() rejects the over-long iso_frame_desc[0].length with -EMSGSIZE, but only after the write. Reject such descriptors at probe time. Genuine UA-101/UA-1000 hardware declares proportional packet sizes and is unaffected. BUG: KASAN: slab-out-of-bounds in start_usb_playback (sound/usb/misc/ua101.c:586) Write of size 2048 at addr ffff8881098f3c00 by task exploit/5021 Call Trace: __asan_memset (mm/kasan/shadow.c:84) start_usb_playback (sound/usb/misc/ua101.c:586) playback_pcm_open (sound/usb/misc/ua101.c:679) snd_pcm_open_substream (sound/core/pcm_native.c:2829) snd_pcm_open (sound/core/pcm_native.c:2865 sound/core/pcm_native.c:2932) snd_pcm_playback_open (sound/core/pcm_native.c:2891) snd_open (sound/core/sound.c:166) chrdev_open (fs/char_dev.c:411) do_dentry_open (fs/open.c:996) vfs_open (fs/open.c:1101) path_openat (fs/namei.c:4837 fs/namei.c:5000) do_file_open (fs/namei.c:5029) do_sys_openat2 (fs/open.c:1417) __x64_sys_openat (fs/open.c:1423 fs/open.c:1439 fs/open.c:1434) do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address belongs to the object at ffff8881098f3c00 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 0 bytes inside of allocated 168-byte region [ffff8881098f3c00, ffff8881098f3ca8) Cc: stable@vger.kernel.org Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support") Reported-by: Assisted-by: LLM Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260918225753.1278505-1-xmei5@asu.edu Signed-off-by: Takashi Iwai commit ae0f12706433995336784a0966d42d2f7f7b5dac Author: Zhang Heng Date: Fri Sep 18 19:03:01 2026 +0800 ALSA: hda/realtek: Add quirk for Acer Nitro ANV16-41 The Acer Nitro ANV16-41 requires the ALC2XX_FIXUP_HEADSET_MIC quirk to make the headset microphone work properly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221953 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260918110301.664172-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai commit e0cb0570d0ebce6f452ab492e8743f6f7eb2558e Author: Jianyu Zhou <997536907@qq.com> Date: Thu Sep 17 14:58:29 2026 +0800 ALSA: hda/realtek: Add quirk for IPASON SmartBook S1 From 2adfedabfdd9f5ec800462b1f1c0859a198e63aa Mon Sep 17 00:00:00 2001 From: Jianyu Zhou <997536907@qq.com> Date: Thu, 17 Sep 2026 14:34:46 +0800 Subject: [PATCH v2] ALSA: hda/realtek: Add quirk for IPASON SmartBook S1 The internal speaker of the IPASON SmartBook S1 (an Emdoor ODM laptop) stays silent under Linux, while the Bluetooth audio and the headset output work fine. The same machine plays sound under Windows with the vendor driver, so the hardware and the amplifier are known good. The BIOS reports the pin default of the actual internal speaker pin (NID 0x1b) as 0x411111f0, i.e. the default association 0xf, which means "unconnected". The pin parser therefore drops that node already at the pin-configuration time, hence no mixer control is ever created for it and the pin is never driven, no matter how the output pin 0x14 is set up. Enabling 0x1b makes the speaker work immediately. The existing ALC256_FIXUP_HONOR_MRB_XXX_M1020_AUDIO quirk makes the speaker work, too, but it additionally rewrites the pins 0x14, 0x19 and 0x1a with Honor-specific values, which creates a bogus "Dock Mic" device that does not exist on this hardware. Add a minimal fixup that only enables 0x1b as the internal speaker. Touching 0x14 is not needed: with the pin configuration overridden at runtime, both keeping its BIOS value (0x90170110) and disabling it (0x411111f0) leave the speaker working, so 0x1b alone decides the output. Codec: Realtek ALC256 (0x10ec0256), SSID 0x2782:0x0206 BIOS pincfg: 0x14 0x90170110 0x18 0x411111f0 0x19 0x02a19040 0x1a 0x411111f0 0x1b 0x411111f0 0x1d 0x4067b945 0x1e 0x411111f0 0x21 0x02214020 Tested on 7.2.0-1-MANJARO and 6.18.45-1-MANJARO, with both the SOF and the legacy HDA driver paths. Signed-off-by: Jianyu Zhou <997536907@qq.com> Link: https://patch.msgid.link/tencent_3AB9214FB134949B31E9C471BC3669117F05@qq.com Signed-off-by: Takashi Iwai commit 395e9f2967a7ac6898026e8f136c369805dc2fd9 Author: Kurt Lieber Date: Thu Sep 24 12:26:37 2026 +0000 thunderbolt: Disable CL states for the Anker Prime TB5 dock The Anker Prime TB5 dock identifies itself in the DROM as 01ea:83b5. Its router config space is an Intel Barlow Ridge 80G hub (8087:5786). The upstream lane adapter advertises CL0s, CL1, and CL2. With CLx left enabled, TMU uni-directional LowRes setup fails with -ENOTCONN, the USB3 and DisplayPort tunnels are aborted, and the router reconnects in a loop. Loading thunderbolt with clx=0 keeps the link up on this machine. Match the DROM id together with the Barlow Ridge hub id and disable CL states for this dock only. QUIRK_NO_CLX takes the same early-out as the module parameter, without disabling CLx for every other router. Closes: https://lore.kernel.org/linux-usb/SJ0PR15MB4696D491504DB667AA8E0617A3812@SJ0PR15MB4696.namprd15.prod.outlook.com/ Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Kurt Lieber Signed-off-by: Mika Westerberg commit c034e8a46e4cb703018fe7e10fe5a3a974d6a7c3 Author: Mitul Golani Date: Thu Sep 17 13:13:22 2026 +0530 drm/i915/vrr: Disable DC balance by default Disable VRR DC balance by default due to timing issues observed on some panel/TCON combinations. Keep the module parameter to enable DC balance during debugging and to isolate DC balance effects from underlying VRR/display timing issues. --v2: - Make enable_dc_balance a bool and keep it disabled by default; fix the parameter type/value mismatch and correct the description (Chaitanya Kumar Borah, Jani Nikula) - Explain in the commit message why the feature is gated and why a module parameter is used (Jani Nikula) --v3: - Commit message update (Jani Nikula) Fixes: 555819270707 ("drm/i915/vrr: Enable DC Balance") Cc: # v7.0+ Signed-off-by: Mitul Golani Reviewed-by: Ankit Nautiyal Signed-off-by: Ankit Nautiyal Link: https://patch.msgid.link/20260917074322.2606738-1-mitulkumar.ajitkumar.golani@intel.com (cherry picked from commit d1ef78f0581e856c4238c751e9ae2884ce58c275) Signed-off-by: Jani Nikula commit 6f63e919fe1e335b8abcb3a28bfd4804a98d875a Author: Cen Zhang (Microsoft) Date: Thu Sep 24 22:44:08 2026 -0400 wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue() ieee80211_monitor_select_queue() validates the skb length using skb->len before dereferencing pointers into skb->data to access the 802.11 header. However, skb->len includes data in both the linear head buffer and non-linear fragments/pages. When AF_PACKET sends a packet large enough to become non-linear, the 802.11 header at skb->data + len_rthdr may extend past the linear head buffer even though skb->len appears sufficient. This leads to a slab-out-of-bounds read when accessing hdr->frame_control, as the kernel reads beyond the allocated skb head buffer: BUG: KASAN: slab-out-of-bounds in ieee80211_monitor_select_queue+0x1ed/0x220 syzbot has hit the same issues. Fix this by checking skb_headlen(skb) (which gives the length of the linear data region) instead of skb->len before dereferencing skb->data pointers. This ensures the required bytes are actually present in the linear portion of the skb. Apply the same fix to ieee80211_validate_radiotap_len() which has the same class of bug: it uses skb->len to validate accesses to skb->data, and to the corresponding checks in ieee80211_monitor_start_xmit(): for drivers advertising NETIF_F_SG the skb is not linearized before ndo_start_xmit, so the 802.11 header can be read past the linear buffer there as well. Fixes: cf0277e714a0 ("mac80211: fix skb buffering issue") Fixes: 9b8a74e3482f ("[MAC80211]: Improve sanity checks on injected packets") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: syzbot+610e40369bc02181bad0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=610e40369bc02181bad0 Reported-by: syzbot+878643e0580bc580f883@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=878643e0580bc580f883 Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: Francis Perron Link: https://patch.msgid.link/20260925024408.32143-1-cenzhang@linux.microsoft.com Signed-off-by: Johannes Berg commit 56e236759f0a8dc910c2ae7cd3c161f298ee5794 Author: Ruide Cao Date: Wed Sep 23 02:02:23 2026 +0800 wifi: mac80211: reject invalid 320 MHz CSA bandwidth The HT/VHT channel definition validator can receive a 320 MHz bandwidth indication from a received CSA frame on a non-6 GHz link. It warns for this unsupported width but continues with an uninitialized vht_operation.chan_width, which is then read by ieee80211_chandef_vht_oper(). With panic_on_warn enabled, this lets a received frame panic the kernel. Reject the channel definition before entering the VHT operation conversion. This preserves the existing CSA fallback while avoiding both the warning and the uninitialized read. Fixes: 21c3f8f95554 ("wifi: mac80211: refactor STA CSA parsing flows") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Ruide Cao Signed-off-by: Ren Wei Link: https://patch.msgid.link/bd68e360e06135c750397cb6be003a01a834a179.1787222001.git.vega.cover-letter@nebusec.ai Signed-off-by: Johannes Berg commit 4febc02cd02f021f2b6d0768332be643ef14a12d Author: Felix Fietkau Date: Sat Sep 26 14:02:16 2026 +0200 wifi: mac80211: set info->band for 802.3 encap offload frames Unlike the 802.11 TX paths, ieee80211_8023_xmit() does not set info->band from the channel context on non-MLD interfaces. It stays at 0, so ieee80211_get_tx_rates() uses the wrong band for these frames. Set it the same way as ieee80211_build_hdr(): drop the frame if there is no channel context, and leave the band at 0 on MLD interfaces. Reported-by: Andrea Pesaresi Fixes: 50ff477a8639 ("mac80211: add 802.11 encapsulation offloading support") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260926120216.4054712-1-nbd@nbd.name Signed-off-by: Johannes Berg commit ff82fc3a4a1d417dee1229681cc5285986edb1fa Author: Ridham Khurana Date: Wed Sep 23 11:39:02 2026 +0000 gpio: xilinx: fix runtime PM leak on request error path 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 commit 01c83795d50ccdb441f60e89ff50767cb2f6045a Author: Felix Gu Date: Sat Mar 21 03:12:11 2026 +0800 drm/bridge: th1520-dw-hdmi: Fix remove() callback This driver stores struct th1520_hdmi * in platform drvdata, but th1520_dw_hdmi_remove() was reading it back as struct dw_hdmi * and passing it to dw_hdmi_remove(), so teardown runs on the wrong pointer. Retrieve struct th1520_hdmi * from platform drvdata and pass hdmi->dw_hdmi to dw_hdmi_remove(). Fixes: 96f30ee0fb9d ("drm/bridge: add a driver for T-Head TH1520 HDMI controller") Signed-off-by: Felix Gu Reviewed-by: Dmitry Baryshkov Cc: stable@vger.kernel.org Signed-off-by: Icenowy Zheng Link: https://patch.msgid.link/20260321-th1520-v1-2-ec877197770d@gmail.com commit add916cfcec5b71cb242db85b91b2437be7390cf Author: Felix Gu Date: Sat Mar 21 03:12:10 2026 +0800 drm/bridge: th1520-dw-hdmi: Fix error check on dw_hdmi_probe() return value The error check after calling dw_hdmi_probe() was incorrectly checking the struct pointer hdmi instead of the probe result hdmi->dw_hdmi. Fix this by checking the correct variable. Fixes: 96f30ee0fb9d ("drm/bridge: add a driver for T-Head TH1520 HDMI controller") Signed-off-by: Felix Gu Reviewed-by: Dmitry Baryshkov Cc: stable@vger.kernel.org Signed-off-by: Icenowy Zheng Link: https://patch.msgid.link/20260321-th1520-v1-1-ec877197770d@gmail.com commit a215720959c5450b3699e243904b39c3f8f68888 Author: David Heidelberg Date: Sat Sep 26 22:26:47 2026 +0200 Input: s6sy761 - fix resume ordering and restore sensing System suspend powers the controller off and resume powers it back on, but the resume path enables the interrupt before s6sy761_power_on() checks the boot. The firmware raises its boot-complete event on the interrupt line, the threaded handler consumes it, s6sy761_power_on() then reads an empty event and resume fails with -ENODEV, skipping the touch function setup: s6sy761 2-0048: PM: dpm_run_callback(): s6sy761_resume [s6sy761] returns -19 Power the chip on first and only then unmask the interrupt. Once resume completes the boot handshake the chip comes back with sensing off, as at probe where input_open() turns it on, so the touchscreen stays dead after resume. Send SENSE_ON again when the input device is open. Tested on a Pixel 3 XL over several s2idle cycles: resume succeeds and the touch function and sense status match the pre-suspend state. Assisted-by: LLM Cc: stable@vger.kernel.org Fixes: 0145a7141e59 ("Input: add support for the Samsung S6SY761 touchscreen") Signed-off-by: David Heidelberg Link: https://patch.msgid.link/20260926-s6sy761-suspend-v2-1-8f00a96ee6e8@ixit.cz Signed-off-by: Dmitry Torokhov commit f0fd8993082ca229faa3f9844f1c9fe182eca20b Author: Raphaël Larocque Date: Sat Sep 26 20:58:10 2026 -0400 Input: synaptics - limit T440p InterTouch quirk to LEN0036 The ThinkPad L440 also uses board id 2722, but does not have the SMBus initialization problem seen on the T440p. On the L440, the SMBus companion becomes available shortly after psmouse probes, allowing the touchpad to use SMBus/RMI4 normally. The T440p's quirk is currently applied to all Synaptics touchpads with board id 2722, unnecessarily disabling SMBus InterTouch on the L440, as reported by Daniel Salmun. Restrict the quirk to PNP ID LEN0036, which identifies the T440p, so that other devices sharing board id 2722 retain their normal SMBus/RMI4 operation. Reported-by: Daniel Salmun Link: https://lore.kernel.org/all/20260925230039.236786-1-salmundani@gmail.com/ Fixes: 26eb3d92c7a4 ("Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)") Cc: stable@vger.kernel.org Signed-off-by: Raphaël Larocque Link: https://patch.msgid.link/20260927005810.85971-1-rlarocque@disroot.org Signed-off-by: Dmitry Torokhov commit d2457a7e2727dc747a61a50d65c2f259afce8c45 Author: Laurent Wandrebeck Date: Tue Sep 22 10:50:32 2026 +0200 x86/mm: Don't apply va_align to hugetlb mappings on AMD F15h get_align_mask() returns huge_page_mask_align() for hugetlbfs, but get_align_bits() adds va_align.bits regardless, so vm_unmapped_area() returns an address off the huge page boundary and __unmap_hugepage_range() hits BUG_ON(start & ~huge_page_mask(h)) at teardown. This can be triggered on Carrizo and FX-8370E, both hstates. Pass the file to get_align_bits() and skip the randomisation for hugetlbfs. [ bp: Massage commit message. ] Fixes: 1317a5e7f7b1 ("arch/x86: teach arch_get_unmapped_area_vmflags to handle hugetlb mappings") Suggested-by: Dave Hansen Acked-by: Dave Hansen Signed-off-by: Laurent Wandrebeck Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org # 6.13+ Link: https://patch.msgid.link/20260922085032.46144-1-l.wandrebeck@quelquesmots.fr commit 840d8acc87925deb3c75566fde9ca81d2f47f98c Author: Abdurrahman Hussain Date: Thu Sep 24 17:10:37 2026 -0700 i2c: xiic: don't clobber msg->len to signal block-read completion At the end of a SMBus block read the BNB handler force-set tx_msg->len = 1 to push xiic_tx_space() to zero so the STATE_DONE branch would fire. Two problems: 1. tx_msg and rx_msg alias the same i2c_msg struct during a receive (see xiic_start_recv), so overwriting tx_msg->len also changes rx_msg->len. The i2c core's i2c_smbus_check_pec() then reads the PEC from the wrong offset -- buf[0] instead of buf[rxmsg_len + 1] -- and either mis-validates or returns -EBADMSG. 2. xiic_start_recv sets tx_pos = msg->len (typically 2 when PEC is enabled). xiic_tx_space() is unsigned msg->len - tx_pos, so setting msg->len = 1 with tx_pos = 2 underflows to 0xFFFFFFFF and xiic_tx_space() never compares equal to 0 -- the STATE_DONE check falls through to STATE_ERROR, giving -EIO. Instead, advance tx_pos up to msg->len. That drives tx_space to 0 without touching msg->len, preserving the buffer length that xiic_smbus_block_read_setup() already grew to cover the length byte, the payload and the optional PEC byte. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Signed-off-by: Abdurrahman Hussain Cc: # v6.3+ Acked-by: Michal Simek Reviewed-by: Shubhrajyoti Datta Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260924-i2c-xiic-v7-3-df7e752332ef@nexthop.ai commit e6fe3ea04f0113fe4d47c03d76e03805a4768ca7 Author: Abdurrahman Hussain Date: Thu Sep 24 17:10:36 2026 -0700 i2c: xiic: defer RX_FULL until all trailing bytes are in FIFO For the normal path of xiic_smbus_block_read_setup() -- the trailing bytes all fit in one Rx FIFO fill -- RFD was programmed two below the byte count, which fires the RX_FULL interrupt while the last byte is still in flight. xiic_read_rx() then lands in its bytes_rem == 1 branch and sets NACK on a byte still on the wire, truncating the read. Without PEC this is harmless: the truncated byte is the dummy one the caller never looks at. With PEC enabled it is the PEC byte itself, and i2c_smbus_check_pec() fails the transfer with -EBADMSG. Raise the threshold by one so RX_FULL fires only once every remaining byte is already buffered. That routes the drain through xiic_read_rx()'s bytes_rem == 0 path, which reads everything out and emits the stop cleanly. The only change for the non-PEC case is that the controller waits one extra byte-time before servicing the interrupt. rfd_set stays inside the 4 bits of XIIC_RFD_REG_OFFSET: this branch is only reached when rxmsg_len + pec_len <= IIC_RX_FIFO_DEPTH, so the value is at most IIC_RX_FIFO_DEPTH - 1. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Signed-off-by: Abdurrahman Hussain Cc: # v6.3+ Acked-by: Michal Simek Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260924-i2c-xiic-v7-2-df7e752332ef@nexthop.ai commit b7e6df2f52ed5c02838832f53c171a5645f9b376 Author: Abdurrahman Hussain Date: Thu Sep 24 17:10:35 2026 -0700 i2c: xiic: preserve PEC byte length in SMBus block read setup xiic_smbus_block_read_setup() recalculates i2c->rx_msg->len based on the length byte returned by the device, but historically clobbered the PEC byte expectation the SMBus core had baked into msg->len. That dropped the PEC byte from the caller's buffer on the normal and chunked receive-fifo branches. Compute pec_len up-front as (i2c->rx_msg->len - 1) -- the trailing bytes the caller has already accounted for beyond the length byte, 1 when the SMBus core enabled PEC, and possibly more for an I2C_M_RECV_LEN request coming from i2c-dev -- and add it to the new length in every branch: - chunked: the trailing bytes do not fit in the Rx FIFO, so drain in chunks. The guard becomes (rxmsg_len + pec_len > IIC_RX_FIFO_DEPTH) rather than rxmsg_len alone, both because pec_len bytes also have to fit and because it is what bounds rfd_set in the else branch below to the 4 bits of XIIC_RFD_REG_OFFSET. - padded (1 + rxmsg_len + pec_len < SMBUS_BLOCK_READ_MIN_LEN): the hardware needs at least 3 bytes on the bus to exit the read cleanly (the second byte is already being clocked in by the time the ISR reads the length byte and is too late to NACK), so we still pad rx_msg->len up to SMBUS_BLOCK_READ_MIN_LEN. The dummy trailing byte that gets drained must then be trimmed off before handing the message back to the SMBus core; otherwise i2c_smbus_check_pec() reads buf[len-1] (= dummy) instead of the real PEC byte at buf[1] and rejects every clean zero-length block read with -EBADMSG. Record the true valid byte count in a new field i2c->smbus_actual_len and trim rx_msg->len down to it in xiic_smbus_trim_len(), called from both completion sites that clear rx_msg: xiic_process()'s RX_FULL branch and xiic_recv_atomic(), which drains the FIFO with interrupts off. smbus_actual_len is per-receive state, so xiic_start_recv() clears it before every receive. Only the padded branch ever sets it, and a block read aborted by arbitration loss or a TX error never reaches the completion site, so without that clear a stale value would trim the length of an unrelated later read. The condition is expressed in total bytes rather than the old "(rxmsg_len == 1) || (rxmsg_len == 0)" so that a request carrying more than one trailing byte does not get padded: padding records a length the drain never reaches, which would hand the caller a byte that was never received. - normal: all trailing bytes fit in one FIFO fill. rfd_set gains pec_len for the same reason the length does. Because the padded branch above has already taken every case with fewer than SMBUS_BLOCK_READ_MIN_LEN total bytes, rxmsg_len + pec_len is at least 2 here and the subtraction cannot underflow the u8. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Signed-off-by: Abdurrahman Hussain Cc: # v6.3+ Acked-by: Michal Simek Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260924-i2c-xiic-v7-1-df7e752332ef@nexthop.ai commit 5f43a2d35d5e748c09a50a98fc766dc95bb3a6bd Author: Guangshuo Li Date: Sun Sep 13 13:35:32 2026 +0800 EDAC/versalnet: Drop remote processor handle refcount on driver removal mc_probe() acquires a reference to the remote processor with rproc_get_by_phandle(), but mc_remove() does not release the reference. rproc_shutdown() only balances the power reference acquired by rproc_boot(); it does not drop the device reference acquired by rproc_get_by_phandle(). As a result, successful driver removal leaves the remoteproc reference unbalanced. Call rproc_put() during removal to release the reference acquired in mc_probe(). [ bp: Massage commit message. ] Fixes: d5fe2fec6c40d ("EDAC: Add a driver for the AMD Versal NET DDR controller") Signed-off-by: Guangshuo Li Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Radhey Shyam Pandey Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260913053532.1324671-1-lgs201920130244@gmail.com commit 72d3fcf802c45d00b300f25b848a93c3a2bd7c7e Author: Linus Torvalds Date: Sun Sep 27 13:55:01 2026 -0700 Linux 7.3-rc5 commit a442c8a89fb9c531f9d6ab86120c31decd778d51 Author: Florian Westphal Date: Fri Sep 4 20:03:07 2026 +0200 netfilter: ipset: do not update comments from kernel-side adds 'Fixes' commit stopped calling ip_set_init_comment() for hash types from kernel-side-adds (xtables .. -j SET). ip_set_init_comment() says: "The kadt functions don't use the comment extensions in any way." But bitmap set type calls the function from kadt cb too. While this appears to be safe (serialized via the set spinlock), it seems better to not call the init function either, least of all to keep behaviour consistent. ip_set_list calls ip_set_init_comment() only from uadt cb, it can be kept as-is. This was triggered by yet another LLM review, hinting that the existing rcu_dereference_protected() cannot be downgraded to only check if the nfnl mutex is held. Fixes: f30415929be8 ("netfilter: ipset: do not update comments from kernel-side hash adds") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso commit d266640c6c760c9bc215bf5a3ece122ca488b6f5 Merge: 64d34cef2a3233 77be3641f3e3a5 Author: Linus Torvalds Date: Sun Sep 27 09:57:03 2026 -0700 Merge tag 'driver-core-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core fix from Danilo Krummrich: - Suppress spurious "debugfs is not initialized yet" boot warnings when the caller passes an error parent to debugfs file creation; callers propagating an earlier failure should not trigger the warning * tag 'driver-core-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: debugfs: don't warn about uninitialized debugfs for an error parent commit 64d34cef2a32331fedabf25ea8fa8a30128af9f7 Merge: 104484baf74842 cb97bf3d4f9145 Author: Linus Torvalds Date: Sun Sep 27 09:26:10 2026 -0700 Merge tag 'i2c-fixes-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull i2c fix from Andi Shyti: - qcom-geni: select the correct source clock table entry * tag 'i2c-fixes-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: i2c: qcom-geni: Fix hardcoded clock index in SE_GENI_CLK_SEL commit 104484baf7484266fa0cb8b26362b105cf2d6a10 Merge: b1fa457bddf009 db6365ced4d585 Author: Linus Torvalds Date: Sun Sep 27 08:55:24 2026 -0700 Merge tag 'wq-for-7.3-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq Pull workqueue fix from Tejun Heo: - Fix a NULL dereference in the flush dependency check when a worker flushes outside a work item, such as from the OOM path during worker creation * tag 'wq-for-7.3-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: Fix NULL current_pwq deref in flush dependency check commit b1fa457bddf009907b023bc0c09ba4eca3191a8e Merge: 7cdf91542e1ed0 31c88350b7dd15 Author: Linus Torvalds Date: Sun Sep 27 08:51:45 2026 -0700 Merge tag 'cgroup-for-7.3-rc4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fix from Tejun Heo: - A cpuset partition could claim CPUs an ancestor partition already held exclusively. Restore the rejection an earlier change had turned into a warning. * tag 'cgroup-for-7.3-rc4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup/cpuset: Return PERR_NOCPUS in remote_partition_enable() on subpartitions_cpus conflict commit 7cdf91542e1ed03aa8f5ab029702b3abde5be6d5 Merge: efb44d93a620c2 94480606a677de Author: Linus Torvalds Date: Sun Sep 27 08:50:25 2026 -0700 Merge tag 'sched_ext-for-7.3-rc4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext Pull sched_ext fix from Tejun Heo: - The CPU topology helper for BPF schedulers took no buffer size, so its structure couldn't grow without breaking schedulers built against the older layout. Add a size argument. * tag 'sched_ext-for-7.3-rc4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: Add a size argument to scx_bpf_cid_topo() so struct scx_cid_topo can grow commit efb44d93a620c294c049db37c810c8ab7ee1122d Merge: 673dab7eac1618 b8d1d5b63a8ef5 Author: Linus Torvalds Date: Sun Sep 27 08:44:12 2026 -0700 Merge tag 'x86-urgent-2026-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: - Fix preemption bugs in the SVSM vTPM guest implementation (Melody Wang) - Fix MCE-triggered hardware debug register corruption on task migration (Masami Hiramatsu) * tag 'x86-urgent-2026-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mce: Fix hardware debug register corruption on task migration x86/sev: Make vTPM SVSM calls preemption-safe commit 673dab7eac1618b6622bbee9eb2aaa47817631e3 Merge: 5ccda18d1ba2ec a0bb6fac53fa7c Author: Linus Torvalds Date: Sun Sep 27 08:24:16 2026 -0700 Merge tag 'sched-urgent-2026-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Ingo Molnar: - Fix LLC mis-scheduling bugs (Tim Chen, Lu Wang) - Fix cache-grouping related scheduling statistics UAF bugs (Tim Chen) - Skip kernel threads for cache aware scheduling to rubustify the code (Chen Yu) - Refresh LLC capacity across CPU hotplug, to fix capacity underestimation bug (Davi Chaves Azevedo) - Account PSI IRQ time to the execution context, not the scheduling context, to fix proxy scheduling accounting bug (Zhan Xusheng) * tag 'sched-urgent-2026-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/core: Account PSI IRQ time to the execution context, not the scheduling context sched/cache: Refresh LLC capacity across CPU hotplug, to fix capacity underestimation bug sched/cache: Skip kernel threads for cache aware scheduling to rubustify the code sched/cache: Introduce task_struct->sched_cache_grp to fix UAF sched/cache: Decouple sched_cache_group from mm to fix UAF sched/cache: Honor migrate_llc_task semantics in active load balance, to fix LLC mis-scheduling bug sched/cache: Keep nr_pref_llc_running in the runnable domain, to fix LLC mis-scheduling bug commit 5ccda18d1ba2ecf436102a211baf1fbd5d81703f Merge: fd179f8a05be3c 24b620729e53d9 Author: Linus Torvalds Date: Sun Sep 27 08:15:58 2026 -0700 Merge tag 'perf-urgent-2026-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf events fixes from Ingo Molnar: - Fixes for KVM guest PEBS virtualization (Sean Christopherson) - Fixes for various Intel PMUs related to PEBS data-source (Dapeng Mi) - Fix Intel Panther Cove event scheduling constraints (Dapeng Mi) - Fix Intel DMR/NVL OMR extra registers event scheduling (Dapeng Mi) - Rename two confusingly named PMU attributes (Dapeng Mi) - Fix a refcount leak in attach_perf_ctx_data() (Namhyung Kim) - Fix NULL pointer dereference crash in __perf_pmu_sched_task() (Puranjay Mohan) - Fix CPU-wide event scheduling (Puranjay Mohan) - Fix x86 LBR branch entry generation (Puranjay Mohan) * tag 'perf-urgent-2026-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/core: Fill branch entries with a single assignment perf/core: Run sched_task() for PMUs with only CPU-wide events perf/core: Fix NULL pmu_ctx passed to pmu->sched_task() perf/core: Fix a refcount leak in attach_perf_ctx_data() perf/x86/intel: Rename NVL offcore_rsp attribute to offmodule_rsp perf/x86/intel: Rename DMR offcore_rsp attribute to offmodule_rsp perf/x86/intel: Fix precise OMR event scheduling for DMR/NVL perf/x86/intel: Constrain Panther Cove UOPS_DISPATCHED events to PMCs 0-3 perf/x86/intel: Delete dead NVL PEBS data-source initcall perf/x86/intel: Fix Panther Cove PEBS data-source snoop states perf/x86/intel: Remove incorrect Panther Cove PEBS data-source constraints perf/x86/intel: Remove incorrect LionCove PEBS data-source constraints perf/x86/intel: Update arw_latency_data() mem-op direction handling perf/x86/intel: Fix DKT PEBS load/store direction for latency events, to fix sample classification perf/x86/intel: Fix CMT PEBS load/store direction for latency events, to fix sample classification perf/x86/intel: Fix GRT PEBS load/store direction for latency events, to fix sample classification perf/x86/intel: Make @data a mandatory param for intel_guest_get_msrs() perf/x86/intel: Don't pointlessly context switch DS_AREA (and PEBS config) if PEBS is unused perf/x86/intel: Don't write PEBS_ENABLED on host<=>guest xfers if CPU has PEBS isolation, to fix stuck PEBS_ENABLED perf/x86/intel: Ensure KVM guest PEBS path doesn't set unwanted PERF_GLOBAL_CTRL bits commit db6365ced4d5855e321f772b240c0e473bcfcdd5 Author: Pavankumar Kondeti Date: Fri Sep 25 15:25:12 2026 +0530 workqueue: Fix NULL current_pwq deref in flush dependency check check_flush_dependency() uses current_wq_worker() to determine whether the caller is a workqueue worker and then dereferences worker->current_pwq to test whether the current workqueue is WQ_MEM_RECLAIM. current_wq_worker() only means that %current has PF_WQ_WORKER set. A kworker can reach check_flush_dependency() while it is not executing a work item. One such path is worker_thread() acting as the pool manager, where create_worker() does GFP_KERNEL allocation and the allocation path invokes the OOM notifier. In that state worker->current_pwq is NULL because current_pwq is set only by process_one_work() and cleared again after the work function returns. [ 416.760634][ T375] Call trace: [ 416.760638][ T375] check_flush_dependency+0x80/0x120 (P) [ 416.760648][ T375] __flush_work+0x98/0x224 [ 416.760657][ T375] flush_work+0x30/0x44 [ 416.760665][ T375] ... [ 416.760710][ T375] blocking_notifier_call_chain+0x58/0xa0 [ 416.760719][ T375] out_of_memory+0xb4/0x458 [ 416.760730][ T375] __alloc_pages_may_oom+0x11c/0x1a8 [ 416.760739][ T375] __alloc_pages_slowpath+0x314/0x46c [ 416.760746][ T375] __alloc_frozen_pages_noprof+0x110/0x1a4 [ 416.760753][ T375] new_slab+0x12c/0x484 [ 416.760759][ T375] ___slab_alloc+0x7a8/0xc7c [ 416.760765][ T375] __slab_alloc+0x74/0xd8 [ 416.760772][ T375] __kmalloc_cache_node_noprof+0x2ac/0x304 [ 416.760779][ T375] alloc_worker+0x28/0x60 [ 416.760785][ T375] create_worker+0x4c/0x20c [ 416.760790][ T375] worker_thread+0xe8/0x2b8 [ 416.760796][ T375] kthread+0x1a8/0x200 [ 416.760805][ T375] ret_from_fork+0x10/0x20 Guard the WQ_MEM_RECLAIM-worker warning with worker->current_pwq. If the kworker is not currently executing a work item, there is no current workqueue to diagnose with that warning. The PF_MEMALLOC warning is left unchanged so explicit reclaim context flushing a !WQ_MEM_RECLAIM target is still reported. Fixes: fca839c00a12 ("workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Pavankumar Kondeti Signed-off-by: Tejun Heo commit 976d5e0ddac885b0219252f004f6c561c344df9d Author: Lorenzo Stoakes (ARM) Date: Wed Sep 23 18:45:41 2026 +0100 mm/vma: predicate setting mmap_prepare VMA fields on new vma alloc It only makes sense to manipulate VMA fields if a new VMA was allocated, rather than merged. VMA merging does not compare vm_ops or vm_private_data, so a merged VMA keeps its own, which is also what the legacy f_op->mmap path does since it never touches an existing VMA. Currently, these fields will get overwritten by whatever state is established in the mmap_prepare hook, and if the VMA was merged, vm_ops->mapped will not have been called, so this could destructively clear existing state without replacing it with anything valid. There is an implicit requirement that vm_private_data and vm_ops are fungible across VMAs which means that losing the 'new' state is fine. However in this case the 'old' state is being overwritten by potentially invalid 'new' state, so this must be rectified. Additionally constify have_mmap_prepare while here. All existing in-tree users either derive state from the file or are unmergeable due to VMA flags, so this has no direct impact. Link: https://lore.kernel.org/20260923-fix-mmap-prepare-overwrite-v1-1-3b3f1bfcdf5e@kernel.org Fixes: c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file callback") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Reviewed-by: Suren Baghdasaryan Reviewed-by: Gregory Price (Meta) Acked-by: Zi Yan Acked-by: Vlastimil Babka (SUSE) Cc: Liam R. Howlett Cc: Jann Horn Cc: Pedro Falcato Cc: commit 6cc8f549f6888e36036ab14d84a8ec46b4a393c0 Author: Joseph Qi Date: Wed Sep 23 08:39:20 2026 +0800 MAINTAINERS: add Heming Zhao as ocfs2 reviewer Heming Zhao has contributed ocfs2 a lot recent years, both as a author and reviewer. So add him as ocfs2 reviewer. Link: https://lore.kernel.org/20260923003920.2382398-1-joseph.qi@linux.alibaba.com Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Acked-by: Mark Fasheh Cc: Heming Zhao Cc: Joel Becker commit b3f0c1a4e41f356c3126a676ad55c0f6881e7514 Author: David Hildenbrand (Arm) Date: Fri Sep 18 18:34:26 2026 +0200 MAINTAINERS: make Gregory a co-maintainer of MEMORY MANAGEMENT - NUMA PLACEMENT Gregory is extremely familiar with NUMA placement handling and volunteer to help co-maintain the numa placement bits. So add him as a co-maintainer. Link: https://lore.kernel.org/20260918-maintainers-mempolicy-v1-3-9a94cac6d135@kernel.org Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Acked-by: Lorenzo Stoakes (ARM) Acked-by: Gregory Price (Meta) Acked-by: Zi Yan Reviewed-by: Joshua Hahn Acked-by: SJ Park Acked-by: Vlastimil Babka (SUSE) Cc: Alistair Popple Cc: Byungchul Park Cc: "Huang, Ying" Cc: Liam R. Howlett Cc: Matthew Brost Cc: Michal Hocko Cc: Mike Rapoport Cc: Rakie Kim Cc: Suren Baghdasaryan commit 4050a73a90f456887dc35d5bbfa4f4790eb5c2cf Author: David Hildenbrand (Arm) Date: Fri Sep 18 18:34:25 2026 +0200 MAINTAINERS: move memory tiering under MEMORY MANAGEMENT - NUMA PLACEMENT NUMA PLACEMENT is a better place for memory tiering. My best guess is that existing MISC reviewers are not that interested in memory tiering, so don't carry any over. Link: https://lore.kernel.org/20260918-maintainers-mempolicy-v1-2-9a94cac6d135@kernel.org Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Acked-by: Lorenzo Stoakes (ARM) Acked-by: Zi Yan Reviewed-by: Joshua Hahn Reviewed-byt: SJ Park Acked-by: Vlastimil Babka (SUSE) Cc: Alistair Popple Cc: Byungchul Park Cc: Gregory Price Cc: "Huang, Ying" Cc: Liam R. Howlett Cc: Matthew Brost Cc: Michal Hocko Cc: Mike Rapoport Cc: Rakie Kim Cc: Suren Baghdasaryan commit 711d886fe76e28854814759f51ee175e279ef8c7 Author: David Hildenbrand (Arm) Date: Fri Sep 18 18:34:24 2026 +0200 MAINTAINERS: split up MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION Patch series "MAINTAINERS: rework MEMORY MANAGEMENT - MEMORY POLICY". Let's rework MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION. As I can use some maintenance help in that area, add Gregory as a new co-maintainer for the split out MEMORY MANAGEMENT - NUMA PLACEMENT section. This patch (of 3): Let's split it up into MIGRATION and NUMA PLACEMENT. The latter is a better fitting description for mempolicy.c. Make a best guess about which pieces existing reviewers are interested in. Move the split sections to keep alphabetical order. Link: https://lore.kernel.org/20260918-maintainers-mempolicy-v1-1-9a94cac6d135@kernel.org Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Acked-by: Lorenzo Stoakes (ARM) Acked-by: Zi Yan Reviewed-by: Joshua Hahn Reviewed-by: SJ Park Acked-by: Vlastimil Babka (SUSE) Cc: Alistair Popple Cc: Byungchul Park Cc: Gregory Price Cc: "Huang, Ying" Cc: Liam R. Howlett Cc: Matthew Brost Cc: Michal Hocko Cc: Mike Rapoport Cc: Rakie Kim Cc: Suren Baghdasaryan commit 22ab0647764c38924669673634ae333578d77768 Author: Andrey Ryabinin Date: Wed Sep 16 19:51:13 2026 +0200 kasan: unpoison task stack below watermark only in generic mode CPU resume and BPF exception handling can discard stack frames without running their compiler-generated epilogues. Generic KASAN needs kasan_unpoison_task_stack_below() to clear the redzones left behind by those frames before the stack is reused. CONFIG_KASAN_STACK also enables this helper for SW_TAGS. The helper derives the stack base from an untagged stack pointer, so kasan_unpoison() writes KASAN_TAG_KERNEL (0xff) into the shadow for [base, watermark). For a vmapped task stack, vm_area->addr still carries the original random allocation tag. This creates a tag mismatch at the stack base even if that memory has never held an instrumented stack object. When the task exits and its stack is not cached, thread_stack_free_rcu() passes vm_area->addr to vfree(). In RCU callback context this reaches vfree_atomic(), whose llist_add() writes to the allocation base through the tagged pointer and triggers a false KASAN invalid-access report: BUG: KASAN: invalid-access in vfree_atomic+0x90/0x150 Write of size 8 at addr c2ffffc0a8f70000 by task rcuop/7/75 Pointer tag: [c2], memory tag: [ff] Call trace: __hwasan_store8_noabort+0xe8/0xf8 vfree_atomic+0x90/0x150 vfree+0x220/0x298 thread_stack_free_rcu+0x3c/0x4c rcu_do_batch+0x308/0xaf0 rcu_nocb_cb_kthread+0x33c/0x708 The deferred-free path started using the tagged vm_area->addr in commit 449e0b4ed5a1 ("fork: clean-up naming of vm_stack/vm_struct variables in vmap stacks code"). Previously it freed the untagged pointer derived from tsk->stack, so the write was never tag-checked. SW_TAGS does not need the blanket shadow reset to make subsequent stack accesses valid: untagged kernel pointers have the match-all 0xff tag, and the compiler initializes the shadow tags of instrumented stack objects before use. Return early unless CONFIG_KASAN_GENERIC is enabled. Keep the mode check in the common helper so it covers both resume and bpf_throw(). Link: https://lore.kernel.org/20260916175113.1327454-1-ryabinin.a.a@gmail.com Fixes: 449e0b4ed5a1 ("fork: clean-up naming of vm_stack/vm_struct variables in vmap stacks code") Signed-off-by: Andrey Ryabinin Signed-off-by: Andrew Morton Reported-by: Shaobo Huang Closes: https://lore.kernel.org/all/20260806123020.90869-1-huangshaobo3@xiaomi.com/ Assisted-by: LLM Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: David Hildenbrand Cc: Dmitry Vyukov Cc: Lorenzo Stoakes Cc: Vincenzo Frascino Cc: commit 52ae167ce16609c7e6fffef588b3c2c26de2db19 Author: SJ Park Date: Wed Sep 16 06:50:19 2026 -0700 mm/damon/core: don't skip damos_adjust_quota() while esz is not zero DAMOS could unexpectedly stop working when a user disables quota using the online parameters commit feature. Fix it by correcting a wrong quota unset check in damos_adjust_quota(). DAMON users could disable all quotas by unsetting time and size quotas, and removing all quota goals. The intention of disabling quotas would be making DAMOS run at full speed. When such quota disabled setup is detected, damos_adjust_quota() skips all its work. The skipped works include effective size quota (damos_quota->esz) updates and charged quota amount (damos_quota->charged_sz) resets. The intention is to avoid doing unnecessary work when quotas are disabled. However, users could do the setup while effective size quota is non-zero, by doing the disabling with the online DAMON parameters commit feature. In this case, because the effective size quota exists, DAMOS will keep working with the quota until it is fully charged. After the effective quota is fully charged, the charged quota amount (damos_quota->charged_sz) cannot be reset because damos_adjust_quota() skips it. Then, DAMOS stops working until the quota is newly set or DAMON is entirely restarted. The problem happens because damos_adjust_quota() assumes the user setup for disabling quota immediately disabled it. In reality, the quota is still working until the effective size quota is also updated to zero. Other logic for catching that uses damos_quota_is_set(), which understands the fact and therefore checks the effective size quota in addition to the user setup. Fix the issue by using damos_quota_is_set() in damos_adjust_quota() to determine if its works should be skipped. The user impact is a non-deterministic and unexpected DAMOS stop behavior. That is, users would disable quotas using the online parameters commit feature, expecting DAMOS will run at full speed. However, depending on the timing, the setup can be updated while the effective size quota is non-zero. Due to the above mentioned internal mechanism, DAMOS stops working instead of running at full speed. It is unexpected behavior. It is also non-deterministic because sometimes the setup is done when the effective size quota is zero, depending on the timing. It doesn't cause critical issues like crashes or leaks. Users can simply set a reasonable quota again, or restart DAMON. But definitely it is an unexpected and non-deterministic behavior that makes it difficult to reliably use. Also investigating the root cause of the behavior would be quite difficult. Link: https://lore.kernel.org/20260916135020.86483-1-sj@kernel.org Fixes: da87878010e5 ("mm/damon/sysfs: support online inputs update") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Reviewed-by: Kunwu Chan Cc: # 5.19.x commit 347c6ed8cf7768883252e106994de62c7947f0a0 Author: Arnd Bergmann Date: Tue Sep 15 22:23:47 2026 +0200 alloc_tag: avoid implicit padding in uapi The implied padding causes a harmless warning when testing the uapi headers with -Wpadded that could in theory indicate incompatibilities or data leaks: ./usr/include/linux/alloc_tag.h:41:1: error: padding struct size to alignment boundary with 7 bytes [-Werror=padded] The code here is fine, but it's better to make the padding explicit and avoid the warning here. Link: https://lore.kernel.org/20260916065830.1619425-1-arnd@kernel.org Link: https://lore.kernel.org/20260915202404.3568029-1-arnd@kernel.org Fixes: 1d581ab2348c ("alloc_tag: add ioctl to /proc/allocinfo") Signed-off-by: Arnd Bergmann Signed-off-by: Andrew Morton Acked-by: Suren Baghdasaryan Acked-by: SJ Park Acked-by: Hao Ge commit 72c3d682c165b836b54a3d07a01f72e39c47022c Author: Baolin Wang Date: Mon Sep 14 10:12:41 2026 +0800 mm: shmem: ignore sysfs configs for shmem forced collapse According to Documentation/mm/transhuge.rst, MADV_COLLAPSE is expected to ignore any THP or mTHP interface settings. However, after commit 26c7d8413aaf ("mm: thp: support "THPeligible" semantics for mTHP with anonymous shmem"), performing MADV_COLLAPSE on shmem will depend on /sys/.../hugepages-2048kB/shmem_enabled being set to "inherit" (although that is the default), which can cause MADV_COLLAPSE to fail unexpectedly. This could cause a userspace-visible performance regression. Fix this by returning the result of shmem_huge_global_enabled() directly when MADV_COLLAPSE is requested, allowing PMD-order collapse while ignoring shmem THP/mTHP settings. Link: https://lore.kernel.org/063f655b4d6c4234f3aa27ed6ecab10283ecb880.1789351825.git.baolin.wang@linux.alibaba.com Fixes: 26c7d8413aaf ("mm: thp: support "THPeligible" semantics for mTHP with anonymous shmem") Signed-off-by: Baolin Wang Signed-off-by: Andrew Morton Reported-by: Kiryl Shutsemau (Meta) Closes: https://lore.kernel.org/all/20260908125105.1510704-7-kirill@shutemov.name/ Reviewed-by: Kiryl Shutsemau (Meta) Acked-by: Zi Yan Reviewed-by: Lance Yang Reviewed-by: Barry Song Acked-by: Qi Zheng Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Cc: Dev Jain Cc: Hugh Dickins Cc: Liam R. Howlett Cc: Ryan Roberts Cc: commit c79cf15eb35a4c703bf18f8c33c47e80dd660f8e Author: Hao Ge Date: Thu Aug 27 11:05:03 2026 +0800 module: fix lost error code from codetag_load_module() If codetag_load_module() fails, err is not set to reflect the failure and load_module() returns 0 after the module has been torn down. Also, if the module is a livepatch, mod->klp_info allocated by copy_module_elf() leaks on this error path. Free it via a new livepatch_cleanup label. Link: https://lore.kernel.org/20260827030503.49171-1-hao.ge@linux.dev Fixes: 044d2aee6c57 ("alloc_tag: handle module codetag load errors as module load failures") Signed-off-by: Hao Ge Signed-off-by: Andrew Morton Reported-by: Sashiko Suggested-by: Petr Pavlu Reviewed-by: Bradley Morgan Cc: Aaron Tomlin Cc: Luis Chamberalin Cc: Sami Tolvanen Cc: Suren Baghdasaryan Cc: commit 94480606a677deb68d5622cf0ded88626514b3f2 Author: Tejun Heo Date: Sat Sep 26 09:23:02 2026 -1000 sched_ext: Add a size argument to scx_bpf_cid_topo() so struct scx_cid_topo can grow scx_bpf_cid_topo() copies struct scx_cid_topo into a buffer the BPF program sized from its own vmlinux.h while the verifier sizes the write from the running kernel's BTF. The struct may grow and each growth then breaks every scheduler built against the older layout, rejected at load or written past its buffer. This is the usual hole for a struct handed to BPF, closed elsewhere with a size argument, and it was missed here. Take the buffer size, copy the smaller of it and the kernel's struct and set the rest to -1. Accesses to the copy are CO-RE relocated, so the struct can grow by appending fields, which its comment now states. The kfunc changes in place: the cid interface is still being finalized and no released scheduler uses the current form. Fixes: e9b55af47edf ("sched_ext: Add topological CPU IDs (cids)") Cc: stable@vger.kernel.org # v7.2+ Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit 7d5a36a5490d496e17823085fbe7ec6c0a7bf43d Author: Rounak Das Date: Sat Sep 26 17:38:46 2026 +0530 EDAC/altera: Fix device node reference leaks in the SDMMC ECC setup Under altr_portb_setup() and socfpga_init_sdmmc_ecc(), of_find_compatible_node() was being used to look up the sdmmc-ecc node. This node wasn't being dropped using of_node_put(). altr_portb_setup() did not drop its reference under its success path or on any error path. socfpga_init_sdmmc_ecc() did an early return thereby skipping the common exit label and thus leaking the reference. Add the missing of_node_put() calls in altr_portb_setup(), and route socfpga_init_sdmmc_ecc()'s success path through the common exit label. Fixes: 911049845d70 ("EDAC, altera: Add Arria10 SD-MMC EDAC support") Fixes: 788586efd116 ("EDAC/altera: Initialize peripheral FIFOs in probe()") Closes: https://sashiko.dev/#/patchset/20260708091135.94114-1-rounakdas2025%40gmail.com Signed-off-by: Rounak Das Signed-off-by: Borislav Petkov (AMD) Acked-by: Dinh Nguyen Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260926120846.35716-1-rounakdas2025@gmail.com commit fd179f8a05be3ccae366b9b96e176b51fbe54aab Merge: fddfc3ec31799a 113dcdfadf30ea Author: Linus Torvalds Date: Sat Sep 26 11:14:35 2026 -0700 Merge tag 'ata-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fixes from Niklas Cassel: - Extend the quirk "no LPM on ATI" quirk, that is currently only applied for Samsung drives, to include AMD controllers as well. The AMD AHCI controllers are newer versions of the ATI AHCI controllers, and these controllers still have LPM issues with Samsung drives - LPM works with drives from other vendors (me) - Fix errors in the libata.force parameter documentation (me) - Verify the sense data descriptor lengths for ATA PASS-THROUGH command, so that a malicious device cannot write past the buffer length (Matthias) - Mention the libata for-next branch in MAINTAINERS such that the git ls-remote command done by get_maintainer.pl --self-test=scm can verify it (Matthias) * tag 'ata-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: MAINTAINERS: name the libata/linux for-next branch ata: libata-scsi: bound the ATA passthru sense descriptor writes ata: libata: Correct libata.force parameter documentation ata: libata-core: Extend Samsung LPM quirk to AMD controllers commit 31c88350b7dd1522792f726f79607f31bb55c50f Author: Hui Peng Date: Thu Sep 24 04:27:27 2026 +0000 cgroup/cpuset: Return PERR_NOCPUS in remote_partition_enable() on subpartitions_cpus conflict When a remote partition is created underneath an existing local partition via a non-partition (PRS_MEMBER) intermediate cgroup, update_prstate() sees parent->partition_root_state == PRS_MEMBER and calls remote_partition_enable(). Commit 86888c7bd117 ("cgroup/cpuset: Add warnings to catch inconsistency in exclusive CPUs") replaced the cpumask_intersects(tmp->new_cpus, subpartitions_cpus) error check in remote_partition_enable() with WARN_ON_ONCE(). As a result, remote_partition_enable() emits a warning and proceeds to enable the remote partition on CPUs that are already owned by the ancestor local partition in subpartitions_cpus. This can be reproduced on Linux 7.3.0-rc3 with: mkdir -p /tmp/cg1 mount -t cgroup2 none /tmp/cg1 echo "+cpuset" > /tmp/cg1/cgroup.subtree_control mkdir /tmp/cg1/A echo 1 > /tmp/cg1/A/cpuset.cpus echo 1 > /tmp/cg1/A/cpuset.cpus.exclusive echo root > /tmp/cg1/A/cpuset.cpus.partition echo "+cpuset" > /tmp/cg1/A/cgroup.subtree_control mkdir /tmp/cg1/A/B echo 1 > /tmp/cg1/A/B/cpuset.cpus echo 1 > /tmp/cg1/A/B/cpuset.cpus.exclusive echo "+cpuset" > /tmp/cg1/A/B/cgroup.subtree_control mkdir /tmp/cg1/A/B/D echo 1 > /tmp/cg1/A/B/D/cpuset.cpus echo 1 > /tmp/cg1/A/B/D/cpuset.cpus.exclusive echo root > /tmp/cg1/A/B/D/cpuset.cpus.partition which triggers: WARNING: kernel/cgroup/cpuset.c:1594 at remote_partition_enable+0x1c1/0x300 and leaves both /tmp/cg1/A and /tmp/cg1/A/B/D as active root partitions claiming exclusive CPU 1. Fix this by returning PERR_NOCPUS when tmp->new_cpus intersects subpartitions_cpus in remote_partition_enable(), matching the error code used by remote_cpus_update() for the same subpartitions_cpus conflict, and add a regression test case to tools/testing/selftests/cgroup/test_cpuset_prs.sh. Tested in QEMU on Linux 7.3.0-rc3 using the reproducer above and tools/testing/selftests/cgroup/test_cpuset_prs.sh. Fixes: 86888c7bd117 ("cgroup/cpuset: Add warnings to catch inconsistency in exclusive CPUs") Suggested-by: Guopeng Zhang Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Hui Peng Reviewed-by: Waiman Long Signed-off-by: Tejun Heo commit fddfc3ec31799a932bb92f1b8a84cb3d1f963be9 Merge: efb27d47677397 4fde4482251234 Author: Linus Torvalds Date: Sat Sep 26 09:59:59 2026 -0700 Merge tag 'pci-v7.3-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fixes from Bjorn Helgaas: - Make BAR resize work even for devices where no upstream bridge is visible to the OS, which fixes an amdgpu regression on SolidRun HoneyComb, which doesn't expose Root Ports to the OS (Liz Fong-Jones) - Omit bus properties in dynamic OF nodes when a bridge has no subordinate bus, which fixes early boot hangs caused by NULL pointer dereferences with CONFIG_PCI_DYNAMIC_OF_NODES enabled (Angel J) - Disable enhanced atomics on AMD NBIO 7.7 and 7.11 to avoid silent data corruption on 64-bit DMAs (Mario Limonciello) * tag 'pci-v7.3-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: x86/PCI: Disable enhanced atomics on AMD NBIO 7.7 and 7.11 PCI: of_property: Omit bus properties without a subordinate bus PCI: Fix BAR resize for devices on a root bus commit efb27d47677397961c9017c0f8f469eb25a15d68 Merge: eff8d2791c0863 5bfa9f1a9dcb6e Author: Linus Torvalds Date: Sat Sep 26 08:36:29 2026 -0700 Merge tag 'probes-fixes-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull probe fixes from Masami Hiramatsu: - kprobes: Fix permanent hang when flushing the kprobe optimizer Fix a deadlock when disabling kprobe optimization via sysctl or debugfs where flushers hung waiting for optimizer_completion. Replaced the completion with an optimizer_passes counter and wait_var_event_mutex() under kprobe_mutex so concurrent flushers can wait and wake up safely. - fprobe: Terminate the fgraph_data list when the reservation is not filled Fix an issue where unused shadow stack data left uninitialized by fprobe_fgraph_entry() was misparsed as stale fprobe headers on return. Explicitly write a zero word to terminate the list and update read_fprobe_header() to handle the zeroed slot properly. - ftracetest: Fix unique symbol check in kprobe_non_uniq_symbol.tc Fix false test failures in kprobe_non_uniq_symbol.tc on architectures like s390 where a symbol exists once in core kernel but also in modules. Anchor the /proc/kallsyms search regex to the end of the line so that module symbols are not incorrectly counted. * tag 'probes-fixes-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: kprobes: Fix permanent hang when flushing the kprobe optimizer fprobe: Terminate the fgraph_data list when the reservation is not filled selftests/ftrace: Fix unique symbol check in kprobe_non_uniq_symbol.tc commit eff8d2791c086388ba5bae36385afd9bc6f0507e Merge: 6812ce4e4379ff c2f24f140c2ee6 Author: Linus Torvalds Date: Sat Sep 26 08:26:12 2026 -0700 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull kvm fixes from Paolo Bonzini: "Arm: - Invalidate the ITS translation cache when the guest changes the base address of the ITS tables (Fuad Tabba) - Skip saving ITS devices with device IDs that are out-of-bounds rather than failing the entire ITS save ioctl (Fuad Tabba) - Close race between VM teardown and invalidations of nested MMUs when handling MMU operations that are allowed to block (Lorenzo Stoakes) - Various fixes for the handling of the host's untrusted SVE configuration in pKVM (Fuad Tabba) - Make sure that empty SMCCC ranges based at 0 are rejected by the kvm_smccc_set_filter() (Karl Mehltretter) - Revoke the host mapping for pKVM's private stack pages, along with a new sanity check that all mappings in the hyp's private VA range have been correctly marked as hyp-owned (Fuad Tabba) - Lifetime fixes for the array of shadow stage-2 MMUs, ensuring that concurrent vCPU initialization cannot relocate in-use MMUs. Defer the freeing of shadow stage-2 MMUs to the point that no other users (e.g. MMU notifier) could reference them (Marc Zyngier) - Drop useless WARN when rejecting an unsupported ioctl for pKVM (Fuad Tabba) - Fix the steal_time selftest to install correctly-sized mappings for non-4K hosts (Sebastian Ott) - Correct mapping of fine-grained trap for GCSPOPX instruction (Mark Brown) - Fix KVM_BUG_ON() due to missing handling of DBGBXVR from 32-bit guests (Karl Mehltretter) RISC-V: - Synchronize hrtimer during VCPU teardown - Fix the conversion between vsip and hvip values - Serialize IMSIC attributes with vCPU migration - Release unused page after MMU invalidation - Propagate interrupted G-stage faults to KVM user-space as EINTR - Fix nested acceleration hfence entry update order - Fix sdata leak and stale snapshot_addr in snapshot_set_shmem - Preserve firmware counter value across PMU counter stop/start - Report PMU snapshot write failure to the guest - Fix perf-backed counter accounting across PMU stop and read - Correctly propagate error of a hart status SBI call s390: - Ensure that accesses through kvm_arch_set_irq_inatomic mark as dirty the pages that contain indicator and summary bits - Fix compile warning for kvm_s390_update_cmma_dirty() - Fix incorrect propagation of ENOENT from _gaccess_shadow_fault() to userspace - Move s390_kvm_mmu_commit_memory_region() into s390_kvm_mmu_prepare_memory_region() so that it can fail instead of WARN - Add missing srcu in kvm_s390_set_irq_state() - Fix potential races in storage functions - Fix race in _destroy_pages_crste() - Fix issues in the handling of KVM interrupt and page resources, when a queue that is assigned to a mediated device (mdev) is removed from the host's AP configuration - Fix loop condition in uv_find_secrets - Prevent potential out-of-bounds read x86: - Fix a brown paper bag bug where KVM would incorrectly treat Intel PMU MSRs as valid on AMD - Fix a regression in the hardware disable selftest where it checked the wrong macro when detecting glibc support (breaks at least musl) - Never clear KVM_REQ_VM_DEAD so that dead VMs stay dead, which is especially important for KVM_BUG_ON() flows, which often guard more dangerous bugs - Re-pend GET_NESTED_STATE_PAGES if getting the pages fails, to fix a bug where KVM would let userspace run a broken setup with stale vmcs12 pages - Fix a class of bugs where KVM would fail to fill kvm_run exit fields if getting nested pages failed - Treat reserved entries in the memory attributes xarray as "no attributes", to fix false positives when checking for mixed attributes - Fix memcg accounting for the memory attributes xarray (the xarray library subtly requires the xarray to be configured for accounting upfront; the gfp flags taken at runtime are used only rarely) - Don't pre-reserve xarray entries when storing empty attributes, as storing NULL must not require memory allocation (KVM and other subsystems heavily rely on this behavior) - Fix a memory leak and a cache maintenance issue related to doing intra-host migration on an SEV guest" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (54 commits) KVM: SEV: Do cache maintenance on the source VM during intra-host migration KVM: SEV: Free have_run_cpus during VM destruction even if VM is no longer SEV KVM: Don't pre-reserve xarray entries when storing empty/NULL attributes KVM: Ensure memory attributes xarray nodes are accounted to the caller's memcg KVM: Don't treat reserved xarray entries as having memory attributes KVM: x86: Fill kvm_run exit fields in common get_nested_state_pages() error paths KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails KVM: arm64: Fix AArch32 DBGBXVR handling KVM: arm64: Fix FGT mapping for HFGITR_EL2.nGCSEPP KVM: selftests: fix steal_time for arm64 with host page size > 4K KVM: arm64: Don't WARN on an unknown VM ioctl in protected mode KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction KVM: arm64: nv: Fix life cycle of the nested_mmus array KVM: arm64: Check every private mapping is hyp-owned at pKVM init KVM: arm64: Move the private VA allocation cursor to __io_map_next KVM: arm64: Match hyp text by physical address in fix_host_ownership() KVM: arm64: Transfer the hyp stack pages out of the host stage-2 KVM: arm64: selftests: Test empty SMCCC filter range at base 0 KVM: arm64: Return -EINVAL for an empty SMCCC filter range at base 0 KVM: arm64: Derive GUEST_HAS_SVE from the SVE feature bit at EL2 ... commit b816da5d5df1461446a0a5f3fe2b4948a659a790 Author: Wentao Liang Date: Wed Sep 16 15:40:15 2026 +0000 drm/vc4: Fix firmware reference leak in vc4_drm_bind() 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 commit b4698e50d4601f43d21759203be5b0b3c123e383 Merge: 762a6411a5a7aa 7fbcc793f76e0f Author: Christian Brauner Date: Sat Sep 26 15:47:54 2026 +0200 Merge patch series "mount: a few additional bugfixes" Christian Brauner says: Here's a set of additional mount fixes that fell out of my recent look at the mount code: - Fix a UAF in mnt_change_mountpoint(). - Fix a UAF in statmount(). - FIX a UAF and various associated bugs in clone_mnt() - Prevent copying an unmounted mount tree. - Avoid pointless work in mount_setattr(). - Refuse fspick() on kernel internal superblocks. - Simplify dissolve_on_fput() and unshare(). * patches from https://patch.msgid.link/20260926-work-mount-fixes-2-v1-0-f357abf3d17b@kernel.org: selftests/filesystems: check that a dead mount's overmount isn't followed selftests/filesystems: check that an unmounted mount tree isn't walked namespace: drop the file's reference first in dissolve_on_fput() fs: put the old fs_struct before the old namespaces in unshare() fs: refuse fspick() on internal superblocks namespace: check the target before walking it in do_mount_setattr() namespace: don't copy an unmounted mount tree namespace: don't inherit MNT_UMOUNT in clone_mnt() statmount: read the parent of an unmounted mount under mount_lock namespace: reset the old parent's ->overmount in mnt_change_mountpoint() Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-0-f357abf3d17b@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 7fbcc793f76e0f3bf78f7e41bde634107233714f Author: Christian Brauner Date: Sat Sep 26 15:44:33 2026 +0200 selftests/filesystems: check that a dead mount's overmount isn't followed Add overmount_reparent_test: - a mount that a file descriptor keeps alive after propagate_umount() reparented its overmount and unmounted it must not be walked into the freed overmount by move_mount(MOVE_MOUNT_BENEATH) Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-10-f357abf3d17b@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 07617913d09a5c3df9b294bd7d84f0fd40d80bdb Author: Christian Brauner Date: Sat Sep 26 15:44:32 2026 +0200 selftests/filesystems: check that an unmounted mount tree isn't walked Add unmounted_tree_test: - a detached nsfs or pidfs bind mount that a file descriptor keeps alive can't be copied recursively, a copy of the mount itself and a copy of a mounted one still work - a detached tree with a child that was vacated behind it can't be copied recursively either - a copy of a detached bind mount is an ordinary mount: unlinking its mountpoint from another mount namespace unmounts it - mount_setattr() refuses to change the propagation of a detached tree and still allows it for the root of an anonymous mount namespace Every case runs in a user and mount namespace of its own. Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-9-f357abf3d17b@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 7253a6ff640df85fdccabe7e3dd38cce38e0a7b4 Author: Christian Brauner Date: Sat Sep 26 15:44:31 2026 +0200 namespace: drop the file's reference first in dissolve_on_fput() A detached mount tree is held alive by a file. dissolve_on_fput() unmounts the detached tree attached to that file. Currently dissolve_on_fput() leaves the file's reference to the root of the tree to the caller. So either __fput(), open_detached_copy(), or fsmount() drop the mount. That's backwards. The reference keeps the tree around and is dropped when the tree is already gone. Instead, let dissolve_on_fput() the mount and drop it after umount_tree() with namespace_sem still held. After umount_tree() the mntput() is never the last reference and so the root gets unmounted before its children. Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-8-f357abf3d17b@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 57088a37b2e4d194a2ae5027134b780a36acd900 Author: Christian Brauner Date: Sat Sep 26 15:44:30 2026 +0200 fs: put the old fs_struct before the old namespaces in unshare() unshare(CLONE_NEWNS) always copies the fs_struct and copy_mnt_ns() points root and pwd of that copy into the new mount namespace. The old fs_struct pins the old root and pwd until ksys_unshare() frees it at the end and switch_task_namespaces() will already put the old mount namespace before. This causes pointless work in user namespaces because the copied mounts are locked and stay connected. Switch and free the fs_struct before switching the namespaces. The old root and pwd are wasted while their mount namespace is still alive which also keeps both puts on the mntput() fast path. setns() already does this right as it updates root and pwd before the namespaces are switched. Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-7-f357abf3d17b@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 02587a4af82adccaef8e3b3624b4e7f1c401632d Author: Christian Brauner Date: Sat Sep 26 15:44:29 2026 +0200 fs: refuse fspick() on internal superblocks 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) commit 08f4288a37ef4b3d19b4a9599ec3048219cac828 Author: Christian Brauner Date: Sat Sep 26 15:44:28 2026 +0200 namespace: check the target before walking it in do_mount_setattr() 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) commit 8bacbf6be959973b28b691713a872c12eae69eec Author: Christian Brauner Date: Sat Sep 26 15:44:27 2026 +0200 namespace: don't copy an unmounted mount tree 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) commit e2c6d326216642011da318b9edfd5d57ebd5a56f Author: Christian Brauner Date: Sat Sep 26 15:44:26 2026 +0200 namespace: don't inherit MNT_UMOUNT in clone_mnt() 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) commit bb46094057520304073130920c223451c2a694a7 Author: Christian Brauner Date: Sat Sep 26 15:44:25 2026 +0200 statmount: read the parent of an unmounted mount under mount_lock statmount_mnt_basic() reads the ids of the parent through m->mnt_parent with namespace_sem held for reading. That's fine for a mount that is in a namespace. Everything above it is pinned by that namespace. STATMOUNT_BY_FD also accepts a file descriptor on a mount that has been unmounted on purpose and that only the file descriptor keeps alive. If that mount stayed attached to its parent when it was unmounted the parent is unmounted as well and nothing pins it for the child. The final mntput() unmounts the children under mount_lock alone and frees the parent afterwards. Concurrently, statmount_mnt_basic() reads m->mnt_parent twice while that can happen and can easily dereference a mount that's already gone. Read the parent of an unmounted mount under mount_lock. The parent can't be put while it is held and both ids come from the same mount. A mounted mount's parent is pinned by the namespace and a mount can't leave its namespace while namespace_sem is held, so the common case takes no global lock. Fixes: 0e5032237ee5 ("statmount: accept fd as a parameter") Cc: stable@vger.kernel.org # v7.0+ Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-2-f357abf3d17b@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 476ef286a7a5db8bda51325dc0c45887b4d99d9a Author: Christian Brauner Date: Sat Sep 26 15:44:24 2026 +0200 namespace: reset the old parent's ->overmount in mnt_change_mountpoint() __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) commit 2f00ba93cc285092cd3b7ffebbc9abb6004f55e7 Author: Sean Christopherson Date: Thu Aug 13 15:36:08 2026 -0700 KVM: selftests: Verify that L0's TPR doesn't get clobbered Signed-off-by: Sean Christopherson Message-ID: <20260813223610.2043560-5-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 0c19bc0ef11d8ea7f929a3ec3ce549cfe0781859 Author: Sean Christopherson Date: Thu Aug 13 15:36:07 2026 -0700 KVM: selftests: Run the nested x2APIC with and without APICv being inhibited in L2 Signed-off-by: Sean Christopherson Message-ID: <20260813223610.2043560-4-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 8916c7a87455370b25523d5b1b9015b5244d18c8 Author: Sean Christopherson Date: Fri Jul 10 09:20:52 2026 -0700 KVM: selftests: Add x2APIC MSR test for inhibiting APICv while nested Add a selftest to verify that KVM intercepts x2APIC MSR accesses for L1 after APICv is inhibited while L2 is active. This is a regression test for an AVIC bug where KVM would skip updating x2APIC MSR intercepts while L2 is active, thus giving L1 access to a wide swath of L0's x2APIC surface. Signed-off-by: Sean Christopherson Message-ID: <20260710162052.2188574-3-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 2abb25273c82061dd4670690c81c319c03740bf6 Author: Sean Christopherson Date: Thu Aug 13 14:44:03 2026 -0700 KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are modified Force a refresh of the vmcs02 MSR bitmap during nested VM-Enter if the runtime eVMCS controls (pin, primary, secondary, etc.) are being updated. If L1 isn't intercepting TPR writes, runs L2 with TPR virtualization, and then runs the same L2 with TPR virtualization disabled, KVM will fail to refresh msr_bitmap02 and leave TPR in passthrough mode even though TPR virtualization is disabled. I.e. failure to refresh the bitmap lets L2 (or L1 by proxy) read and write L0's TPR. Fixes: 502d2bf5f2fd ("KVM: nVMX: Implement Enlightened MSR Bitmap feature") Cc: stable@vger.kernel.org Reviewed-by: Vitaly Kuznetsov Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini commit 9e06bbb9ade7cdf28d4a3b5b14e5812881c8df85 Author: Sean Christopherson Date: Wed Aug 26 12:58:33 2026 -0700 KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted Use the MSR permission bitmap of the active VMCB instead of assuming that KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02 if and only if L1 wants to intercept MSR accesses, i.e. if and only if KVM needs to merge msprm01 with msrpm12. Don't bother tracking the virtual address of the bitmap that's being used, as __va() is cheap on x86, and caching the virtual address would introduce yet another source of potentially stale information. Fixes: b2ac58f90540 ("KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Signed-off-by: Sean Christopherson Message-ID: <20260826195833.844526-1-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 73392706d0e0f3aff299321de41d73abe3f53d9d Author: Sean Christopherson Date: Fri Sep 4 10:06:42 2026 -0700 KVM: SVM: Sync guest's PERF_CNTR_GLOBAL_CTL from h/w only on successful VMRUN Don't (re)read PERF_CNTR_GLOBAL_CTL from hardware on a failed VMRUN, as the purpose of the read is to synchronize KVM's cache with any writes done by the guest, and the guest can't possibly have modified the MSR if it never got a chance to run. Signed-off-by: Sean Christopherson Message-ID: <20260904170642.3291466-5-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 64c5b15af71ba3c26b2088bdbb0bbab3dbe58e2c Author: Sean Christopherson Date: Fri Sep 4 10:06:41 2026 -0700 KVM: SVM: Don't mark ASID fields as dirty when setting control.tlb_ctl Don't mark the ASID as dirty in the VMCB when requesting a TLB flush via control.tlb_ctl. Per "15.15.3 VMCB Clean Field" of the July 2026, Revision 3.45 version of the APM: The following are explicitly not cached and not represented by Clean bits: * TLB_Control Fixes: 7e8e6eed75e2 ("KVM: SVM: Move asid to vcpu_svm") Suggested-by: Yosry Ahmed Signed-off-by: Sean Christopherson Message-ID: <20260904170642.3291466-4-seanjc@google.com> Signed-off-by: Paolo Bonzini commit e27fc915c8f575ab5630e27d97465c2077d4b9d1 Author: Sean Christopherson Date: Fri Sep 4 10:06:40 2026 -0700 KVM: SVM: Update control fields on #VMEXIT if and only if VMRUN succeeded Leave control.erap_ctl and control.clean as-is in the VMCS if VMRUN fails, because as per AMD: there's no explicit architectural guarantee about the behavior in the presence of VMRUN failures. So the best thing to do would be to assume that if VMRUN fails, the actions requested in the control fields may not have been performed. Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260904170642.3291466-3-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 60d93c27859fb3ec5b5a689e24de303f166477d0 Author: Sean Christopherson Date: Fri Sep 4 10:06:39 2026 -0700 KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN, as empirical testing shows that the CPU performs the requested TLB flush if and only if VMRUN is successful, i.e. clearing TLB control on a failed VMRUN effectively drops a TLB flush. Explicitly track the need to flush all ASIDs on a per-CPU basis, as the ASID reuse condition is tied to the pCPU, not to the vCPU. As a bonus, this also obviates the need to avoid clobbering FLUSH_ALL_ASID with TLB_CONTROL_FLUSH_ASID, e.g. in svm_flush_tlb_asid(). Deliberately don't bother saving/restoring the "old" tlb_ctl on failure, in quotes because it's not exactly the old tlb_ctl, it's the tlb_ctl from after pre_svm_run(), but before updating tlb_ctl for flush_all_asids. If VMRUN fails and TLB_CONTROL_FLUSH_ALL_ASID is forced, then the next successful run of the VMCB *may* unnecessarily flush all ASIDs, which strictly speaking could result in noisy neighbor issues. However, the fact that new_asid() is already guest-triggerable, because of KVM's flawed behavior of clearing the ASID on emulated INIT, means that a guest can already trigger a flush of all ASIDs at roughly the same rate. And once KVM stops clobbering the ASID on emulated INIT, *or* assigns a static ASID to each vCPU, this flaw goes away. Fixes: 38e5e92fe8c0 ("KVM: SVM: Implement Flush-By-Asid feature") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Suggested-by: Yosry Ahmed Cc: Tom Lendacky Cc: Jim Mattson Signed-off-by: Sean Christopherson Message-ID: <20260904170642.3291466-2-seanjc@google.com> Signed-off-by: Paolo Bonzini commit b6249c1d5665098c8bf12f8d3e4712bf04c775bc Author: Sean Christopherson Date: Fri Sep 25 16:42:56 2026 -0700 KVM: x86/mmu: Bail from shadow walks if the root is invalid or a dummy When walking shadow page tables, immediately terminate the walk if the root is a "dummy" root, i.e. a root whose top-level page table is backed by the zero page, but otherwise doesn't exist. If memslot creation races with a stage-2 page fault (EPT violation or #NPF) from L2, then if the stars align, KVM will attempt to walk shadow page tables using the zero page and hit a NULL pointer deref. BUG: kernel NULL pointer dereference, address: 0000000000000021 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 30 UID: 1000 PID: 941 Comm: qemu Not tainted 7.2.0-rc2-1b731e5ded48-next-vm #1741 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:__kvm_mmu_invalidate_addr+0xea/0x210 [kvm] Call Trace: kvm_mmu_invalidate_addr+0x92/0xe0 [kvm] __kvm_inject_emulated_page_fault+0x67/0x80 [kvm] ept_page_fault+0x160/0x850 [kvm] kvm_mmu_do_page_fault+0x102/0x1f0 [kvm] kvm_mmu_page_fault+0x8e/0x6b0 [kvm] vmx_handle_exit+0x163/0x640 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x960/0x2120 [kvm] kvm_vcpu_ioctl+0x2c7/0x970 [kvm] __x64_sys_ioctl+0x90/0xd0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f606d0b53bb Opportunistically harden the shadow walks against fully invalid roots, but WARN, as all callers are expected/required to pre-check for a valid root. Don't WARN in the dummy root case as the whole point of using a dummy root is to provide a root that's valid enough to enter the guest, i.e. it should Just Work for all flows except those that *need* to know about dummy roots. Alternatively, KVM could allocate a dedicated page and associated shadow page structure for the dummy root, which is very tempting as it such an approach should be more resilient against unexpected behavior. But that would be a much larger and thus riskier change than simply terminating walks of dummy roots. Fixes: 0e3223d8d00a ("KVM: x86/mmu: Use dummy root, backed by zero page, for !visible guest roots") Reported-by: Gabriel Schneider Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260925234256.2384816-1-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 41e005e2c5126ccb906d6374b3b97fcb223f7f8f Author: Sean Christopherson Date: Mon Sep 21 10:44:45 2026 -0700 KVM: WARN if vCPU creation is in-progress when locking all vCPUs Now that KVM holds kvm->lock for the entirety of vCPU creation, from when created_vcpus is incremented until the new vCPU is fully onlined, WARN if the impossible happens and KVM somehow sees a discrepancy between the number of vCPUs "created" and "onlined". Signed-off-by: Sean Christopherson Tested-by: Jean-Christophe Guillain Tested-by: Naveen N Rao (AMD) Message-ID: <20260921174445.911676-8-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 700f8d24436c45cb3cc8956f35c90a1b6a6487c2 Author: Sean Christopherson Date: Mon Sep 21 10:44:44 2026 -0700 Revert "KVM: Check for duplicate vcpu_id as early as possible" Now that KVM uses kvm_get_vcpu_by_id() to check for an existing vCPU ID before doing any meaningful work, which was made possible by holding kvm->lock for the entirety of vCPU creation, revert the now-redundant "early" vCPU ID tracking. The claims about the impact of kvm->vcpu_ids on the memory footprint were a wee bit wrong: the worst case scenario isn't 256 bytes per VM, it's 256 "unsigned longs" per VM, i.e. 2048 bytes per VM. Increasing the size of "struct kvm" by 2048 nearly doubled the total size on many architectures, and tripped x86's KVM_SANITY_CHECK_VM_STRUCT_SIZE, which was added to detect this *exact* scenario, where a single change significantly increased the size of "struct kvm". I.e. attempting to build KVM with CONFIG_DEBUG_KERNEL=n fails on x86 (the build failures got missed because all build bots apparently test only CONFIG_DEBUG_KERNEL=y kernels, and maintainers' test flows were similarly lacking). This reverts commit 97d65b544f48b2ee49f6aea32145e3e7969955dc. Fixes: 97d65b544f48 ("KVM: Check for duplicate vcpu_id as early as possible") Reported-by: Jean-Christophe Guillain Closes: https://lore.kernel.org/all/56a4bc35ee605588b7cc36c8e45c12b5f3b506cb.camel@guillain.net Reported-by: Paweł S Closes: https://lore.kernel.org/all/CABD%3DWFOS4j4hDv%2BpW-eEM9HAM2q2GY_iYdAG%2BqvYcUEinUrcQQ@mail.gmail.com Tested-by: Jean-Christophe Guillain Signed-off-by: Sean Christopherson Tested-by: Naveen N Rao (AMD) Message-ID: <20260921174445.911676-7-seanjc@google.com> Signed-off-by: Paolo Bonzini commit c5866d42f7116ab609e3ab6b4b699282e8287e3f Author: Sean Christopherson Date: Mon Sep 21 10:44:43 2026 -0700 KVM: Move check for existing vCPU ID to the top of vCPU creation Now that kvm->lock is held for the entirety of vCPU creation, check for a conflicting vCPU ID at the begnning of vCPU creation, before the arch precreate() hook is invoked. This will allow reverting commit 97d65b544f48 ("KVM: Check for duplicate vcpu_id as early as possible"). For now, keep the redundant vcpu_ids tracking as a sanity check. No functional change intended (absent KVM bugs, checking vcpu_ids and walking kvm_get_vcpu_by_id() should yield the same result). Signed-off-by: Sean Christopherson Tested-by: Jean-Christophe Guillain Tested-by: Naveen N Rao (AMD) Message-ID: <20260921174445.911676-6-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 6418b715d5a24fa952e8c4baa587dd812dd4765b Author: Sean Christopherson Date: Mon Sep 21 10:44:42 2026 -0700 KVM: Protect all of kvm_vm_ioctl_create_vcpu() with kvm->lock When creating a vCPU, don't drop kvm->lock to when doing the bulk of actual vCPU creation, as allowing multiple vCPUs to be created in parallel adds significant complexity in KVM (as evidenced by the many related bugs), and all known VMMs fully serialize vCPU creation. Remove all manually locking of kvm->lock from kvm_arch_vcpu_{post,}create() for obvious reasons. For many years, "everyone" has assumed that dropping kvm->lock was done for performance reasons optimization, e.g. to allow userspace to create all vCPUs concurrently for latency purposes. But as above, no known VMM does that. Looking at the history of this code, before commit 11ec28047118 ("KVM: Convert vm lock to a mutex"), kvm->lock was a spinlock. I.e. KVM *had* to drop kvm->lock when doing the bulk of vCPU creation, otherwise KVM couldn't do normal memory allocations. When kvm->lock got turned into a mutex for unrelated reasons, no one took advantage updated of the change to simplify vCPU creation. And 19 years later, everyone just assumed that KVM continued to deal with the complexity for performance reasons. Furthermore, naively parallelizing vCPU creation in userspace is likely a net negative due to the overheads of task creation. Unless a VMM carefully avoids the extra overhead related to parallelization, e.g. spawns each vCPU's thread before creating the vCPU, creating vCPUs concurrently is a net *negative* up until about ~64 vCPUs, after which the times are a wash. The absolute speed of light _is_ faster if KVM doesn't hold kvm-lock, but at vCPU counts of ~16 or less, it's probably in the noise when considering total VM creation time, as the added latency is less than 1ms up until 16 or so vCPUs. On top of all that, KVM has had a *lot* of fatal bugs (most often found by syzkaller) related to vCPUs being created while trying to do per-VM operations (basically, see every flow that locks all vCPUs). I.e. the parallel vCPU creation "support" is actively harmful as the only "use case" is for misbehaving userspace to exploit KVM bugs. Serializing vCPU creation will allow reverting commit 97d65b544f48 ("KVM: Check for duplicate vcpu_id as early as possible"), which had "minor" math error: the worst case scenario isn't "256 bytes per VM", it's "256 unsigned longs per VM", i.e. 2048 bytes per VM, which doubles the size of each VM and pushes several architectures into order-1 allocations. Signed-off-by: Sean Christopherson Tested-by: Jean-Christophe Guillain Tested-by: Naveen N Rao (AMD) Message-ID: <20260921174445.911676-5-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 10f4082b754f18ed82f94d47f0e959ef80038895 Author: Sean Christopherson Date: Mon Sep 21 10:44:41 2026 -0700 KVM: RISC-V: Use kvm_is_vcpu_creation_in_progress() instead of open-coded equivalent Use kvm_is_vcpu_creation_in_progress() instead of an open-coded equivalent during AIA initialization. Unlike similar vGIC code in arm64, the relevant RISC-V code runs under kvm->lock, i.e. can use the standard API without hitting lockdep false positive. No functional change intended. Signed-off-by: Sean Christopherson Tested-by: Jean-Christophe Guillain Tested-by: Naveen N Rao (AMD) Message-ID: <20260921174445.911676-4-seanjc@google.com> Signed-off-by: Paolo Bonzini commit e3995b05e95d03953954dd60ba803ebfa7755253 Author: Sean Christopherson Date: Mon Sep 21 10:44:40 2026 -0700 KVM: arm64: vgic: Rely on vCPU creation check in "trylock all vCPUs" Now that KVM's APIs for locking all vCPUs return -EBUSY if vCPU creation is in-progress, drop the manual check for the same from vGIC creation, and update the comments accordingly. Note, while KVM arm64 guards many vGIC operations with its arch-specific config_lock, holding kvm->lock is sufficient to guarantee a stable result for "is vCPU creation in-progress". So, no functional change intended. Note #2, the open coded check in vgic_init() is racy when called without kvm->lock held, e.g. via vgic_lazy_init(). I.e. that check needs to stay open coded to avoid triggering a lockdep assert. Whether or not the race is "fine" is a problem for a different day. Signed-off-by: Sean Christopherson Tested-by: Jean-Christophe Guillain Tested-by: Naveen N Rao (AMD) Message-ID: <20260921174445.911676-3-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 8264c0d73f07f6c3e6768d5a41b56c621f912a37 Author: Sean Christopherson Date: Mon Sep 21 10:44:39 2026 -0700 KVM: Reject attempts to lock all vCPUs if vCPU creation is in-progress Reject locking of all vCPUs if vCPU creation is in-progress, i.e. if the number of "created" vCPUs doesn't match the number of "onlined" vCPUs. It's simply not possible to guarantee that KVM has truly locked all vCPUs if one or more vCPUs are actively being created. Holding kvm->lock does prevent in-flight vCPUs from being fully onlined, but it's infeasible for common KVM to know whether or not that provides sufficient protection. In practice, this is likely a minor bug fix for the ARM and RISC-V usage of kvm_trylock_all_vcpus(), and a glorified nop for everything else. E.g. ARM's kvm_timer_vcpu_init() can race kvm_vm_ioctl_set_counter_offset() with respect to observing KVM_ARCH_FLAG_VM_COUNTER_OFFSET. Opportunistically drop x86's existing manual checks on vCPU creation being in-progress as all of x86's checks immediately precede or follow locking of all vCPUs. Leave arm64 and RISC-V alone for the moment, as their checks aren't as obviously redundant/equivalent. Signed-off-by: Sean Christopherson Tested-by: Jean-Christophe Guillain Tested-by: Naveen N Rao (AMD) Message-ID: <20260921174445.911676-2-seanjc@google.com> Signed-off-by: Paolo Bonzini commit c2f24f140c2ee6c00775c2a93c6ac931acec2b60 Merge: 93de2a6a4b91b7 119e9db233ad0f Author: Paolo Bonzini Date: Sat Sep 26 00:40:07 2026 -0400 Merge tag 'kvm-x86-fixes-7.3-rc5' of https://github.com/kvm-x86/linux into HEAD KVM fixes for 7.3-rcN - Fix a brown paper bag bug where KVM would incorrectly treat Intel PMU MSRs as valid on AMD. - Fix a regression in the hardware disable selftest where it checked the wrong macro when detecting glibc support (breaks at least musl). - Never clear KVM_REQ_VM_DEAD so that dead VMs stay dead, which is especially important for KVM_BUG_ON() flows, which often guard more dangerous bugs. - Re-pend GET_NESTED_STATE_PAGES if getting the pages fails, to fix a bug where KVM would let userspace run a broken setup with stale vmcs12 pages. - Fix a class of bugs where KVM would fail to fill kvm_run exit fields if getting nested pages failed. - Treat reserved entries in the memory attributes xarray as "no attributes", to fix false positives when checking for mixed attributes. - Fix memcg accounting for the memory attributes xarray (the xarray library subtly requires the xarray to be configured for accounting upfront; the gfp flags taken at runtime are used only rarely). - Don't pre-reserve xarray entries when storing empty attributes, as storing NULL must not require memory allocation (KVM and other subsystems heavily rely on this behavior). commit 93de2a6a4b91b72607136dd656edf03fb399d27f Author: Sean Christopherson Date: Wed Sep 23 09:37:21 2026 -0700 KVM: SEV: Do cache maintenance on the source VM during intra-host migration Manually perform cache maintenance on the source VM during intra-host migration to ensure no stale data is left in CPU caches after the VM is destroyed. Because the source VM is "converted" to a non-SEV VM, KVM's memory reclaim flows won't trigger cache maintenance, e.g. when all guest memory is reclaimed in response to detaching from the mmu_notifier. Note, relying on the destination VM to do cache maintenance isn't an option as KVM doesn't require identical guest memory configurations, i.e. the source VM may have access to memory that the destination VM does not. Enforcing equivalent memory configurations is infeasible, as it would require a *deep* comparison of memslots, e.g. to verify that not only are the memslot identical, but what the memslots point at is also identical. Fixes: b56639318bb2 ("KVM: SEV: Add support for SEV intra host migration") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Signed-off-by: Sean Christopherson Message-ID: <20260923163721.1584779-3-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 12c1f6e03f944e399bd2c88441dca5dc702b95a5 Author: Sean Christopherson Date: Wed Sep 23 09:37:20 2026 -0700 KVM: SEV: Free have_run_cpus during VM destruction even if VM is no longer SEV Unconditionally free SEV's "have run CPUs" cpumask in the VM destroy path, i.e. even for what appear to be non-SEV VMs, as an SEV VM becomes a non-SEV VM if its state is intra-host migrated. Alternatively, the mask could be freed in sev_migrate_from() when "converting" the source VM, but that gets annoying because ideally KVM would nullify the mask to guard against UAF, and nullifying the mask would need be conditioned on CPUMASK_OFFSTACK=y. Freeing the mask during sev_migrate_from() is also not robust against other KVM bugs, though that's kind of a moot point since any such bugs would show up even if sev->active is never set. I.e. KVM must get that side of things correct. But, that's not a great reason to add more code just to make things marginally less robust. Fixes: 6f38f8c57464 ("KVM: SVM: Flush cache only on CPUs running SEV guest") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Signed-off-by: Sean Christopherson Message-ID: <20260923163721.1584779-2-seanjc@google.com> Signed-off-by: Paolo Bonzini commit 85de8b3a5eaa23d153aff4c7c83dddbc949064c9 Author: Runyu Xiao Date: Thu Sep 10 17:24:05 2026 +0800 scsi: qedi: Initialize callback state before registration 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) commit 02a3178319639f650428164d4d003de4dc03e326 Author: Naomi Chu Date: Wed Sep 9 17:10:45 2026 +0800 scsi: ufs: core: Hold a clock reference across the probe Clock gating becomes possible as soon as ufshcd_init_clk_gating() has run, and from that point on the probe keeps accessing host registers without ever taking a clock reference. This has been safe only because of the state check in __ufshcd_release(): gate_work is not queued unless hba->ufshcd_state is UFSHCD_STATE_OPERATIONAL, and the promotion to that state used to happen after the last register access of the probe, at the end of ufshcd_probe_hba(). That is fragile: it only works while the promotion happens after the register accesses. Commit a390e6677f41 ("scsi: ufs: core: Expand the ufshcd_device_init(hba, true) call") changed that ordering by moving the promotion into ufshcd_init(), which schedules ufshcd_async_scan() afterwards. ufshcd_probe_hba() therefore now runs with the state already promoted, and it accesses host registers without holding a clock reference: - On hosts with UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH it calls ufshcd_hba_stop() and ufshcd_hba_enable() before ufshcd_device_init() sets the state back to UFSHCD_STATE_RESET, and both read REG_CONTROLLER_ENABLE, so gated clocks stall there instead of just losing a write. - It ends with an ufshcd_configure_auto_hibern8() write, which its other callers do take a clock reference for. Take a clock reference as soon as clock gating has been initialised and keep it until the probe is over. It then does not matter who drops a clock reference while the probe is running, and the register accesses of the probe no longer depend on hba->ufshcd_state. The reference is dropped by ufshcd_async_scan() once the scan has finished, or by the new out_release label if the probe fails after it was taken. Fixes: a390e6677f41 ("scsi: ufs: core: Expand the ufshcd_device_init(hba, true) call") Signed-off-by: Naomi Chu Reviewed-by: Peter Wang Link: https://patch.msgid.link/20260909091045.1134956-1-naomi.chu@mediatek.com Signed-off-by: Martin K. Petersen (Oracle) commit eef3b67f9c6782127163b631c9043011a68016e2 Author: Dinh Nguyen Date: Fri Sep 11 07:06:27 2026 -0500 EDAC/altera: Fix use-after-free in error paths In both altr_edac_a10_device_add() and altr_portb_setup(), the error path freed the dci structure before releasing the devres group. Since the managed single and double bit IRQ handlers use altdev(dci->pvt_info) as their data, an IRQ firing between freeing dci and unregistering the IRQs could dereference the freed memory. Release the devres group first so the managed IRQs are unregistered before the dci structure is freed. Fixes: 911049845d70 ("EDAC, altera: Add Arria10 SD-MMC EDAC support") Fixes: 588cb03ea208 ("EDAC, altera: Add Arria10 L2 Cache ECC handling") Closes: https://sashiko.dev/#/patchset/20260719211238.589402-1-rosenp%40gmail.com Assisted-by: LLM Signed-off-by: Dinh Nguyen Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org ## 6.18+ Link: https://patch.msgid.link/20260911120627.2634225-5-dinguyen@kernel.org commit 3e4a10a4718e3d963ee4d6c5f26bc5ad57c1d2b1 Author: Dinh Nguyen Date: Fri Sep 11 07:06:26 2026 -0500 EDAC/altera: Fix memory leak on dci allocation failure Sashiko reports: "If devres_open_group() fails, the function returns -ENOMEM without freeing the dci structure allocated earlier with edac_device_alloc_ctl_info()." Free the dci structure if devres_open_group() fails. Fixes: c3eea1942a16 ("EDAC, altera: Add Altera L2 cache and OCRAM support") Signed-off-by: Dinh Nguyen Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260911120627.2634225-4-dinguyen@kernel.org commit b62a264163ca51bee04785c581344751812395df Author: Dinh Nguyen Date: Fri Sep 11 07:06:25 2026 -0500 EDAC/altera: Drop __init from ECC setup paths for re-probe safety Sashiko reports: "Does suppressing sysfs unbinding fully prevent the execution of freed __init memory? If altr_sysmgr_regmap_lookup_by_phandle() returns -EPROBE_DEFER, the probe is deferred until after __init memory is freed." The a10 EDAC .setup callbacks (sdmmc, ethernet, nand, dma, usb, qspi) and their helpers (altr_init_a10_ecc_device_type, altr_init_a10_ecc_block) were marked __init. These run from the probe path, which may execute after init memory is freed -- e.g. a probe deferred via -EPROBE_DEFER that only succeeds once a late/module dependency appears, or a manual unbind/rebind. Calling __init code then dereferences freed memory. Remove __init so these functions remain valid at runtime. Fixes: 788586efd116 ("EDAC/altera: Initialize peripheral FIFOs in probe()") Assisted-by: LLM Signed-off-by: Dinh Nguyen Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260911120627.2634225-3-dinguyen@kernel.org commit 19a4f1a6ed00286d70229f4fd5f690cc2fb033dc Author: Dinh Nguyen Date: Fri Sep 11 07:06:24 2026 -0500 EDAC/altera: Do not allow driver unbinding The driver must remain bound; unbinding and re-binding it would erase active system memory. Remove the .remove functions because they will not ever get used. Fixes: 588cb03ea208 ("EDAC, altera: Add Arria10 L2 Cache ECC handling") Signed-off-by: Dinh Nguyen Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260911120627.2634225-2-dinguyen@kernel.org commit a7bfaba4823e3c165bb2004c74eff7c096672bc7 Author: Qishuai Liu Date: Wed Sep 23 13:20:48 2026 +0000 ipv6: fix prefix route expiry in modify_prefix_route() modify_prefix_route() is given the lifetime in clock_t relative to now, but fib6_set_expires() wants an absolute jiffies value. So when a permanent address is changed to a finite valid_lft, the prefix route ends up already expired and GC removes it. Steps to reproduce: ip link add dummy9 type dummy ip link set dummy9 up ip -6 addr add 2001:db8:9::1/64 dev dummy9 ip -6 addr change 2001:db8:9::1/64 dev dummy9 valid_lft 3600 preferred_lft 3600 ip -6 route show dev dummy9 # expires is negative Fixes: 8308f3ff1753 ("net/ipv6: Add support for specifying metric of connected routes") Signed-off-by: Qishuai Liu Reviewed-by: Hangbin Liu Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260923132048.3272878-1-lqs@lqs.me Signed-off-by: Jakub Kicinski commit 0e7fe2b0ca45343b53345edc174898b448ccdaa4 Author: Nicolai Buchwitz Date: Thu Sep 24 12:19:21 2026 +0200 net: bcmgenet: allocate RX buffers as page fragments Since the page_pool conversion every RX buffer is a whole page and the skb truesize is the page, although the hardware writes at most 2 KiB of it. On 64 KiB pages a packet therefore counts 65792 bytes against the socket buffer where it used to count 2752. As a result a UDP socket with the default buffer starts to drop after three packets, and the RX rings pin 16 MiB for 512 KiB of buffers. Fix this and allocate the buffers as page fragments, so the truesize is what a packet occupies. 4 KiB pages stay one buffer per page. Sync each buffer in the refill path, as page_pool can only sync a whole page on recycle. On 4 KiB pages that is twice what the hardware wrote. Fixes: 7bc054c2d4ed ("net: bcmgenet: convert RX path to page_pool") Reported-by: Karl Mehltretter Closes: https://lore.kernel.org/all/20260924065839.56793-1-kmehltretter@gmail.com/ Signed-off-by: Nicolai Buchwitz Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260924101922.2675127-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski commit 0bb8eab29b55045281a4963d4557f2776cdf8cfa Author: Jamal Hadi Salim Date: Thu Sep 24 04:32:49 2026 -0400 net/sched: cls_api: reclaim an empty proto on the error path Two racing tc filter add requests on the same chain/prio of an unlocked classifier both run change() on the shared proto and both can fail: the winner's tcf_chain_tp_delete_empty() attempt gives up because the loser's handle is still in the idr, and the loser's error path drops only its own reference without a second reclamation attempt. The empty proto stays linked in the chain, holding the chain reference, a block reference and the classifier module reference until the chain or block is torn down. Reclaim the proto on the error path of any failed request that holds a proto reference. The reclamation is emptiness-gated: tcf_chain_tp_delete_empty() unlinks the proto only when delete_empty() admits it is empty, so a live shared proto is never unlinked. A proto the request created is reclaimed unconditionally - it is the only owner, so marking it for deletion is safe even without a delete_empty callback. Classifiers without one (the check marks the proto unconditionally) are rtnl-serialized, so the raced window this guard closes cannot arise for them. This is a follow-up to commit d4e359b3608a ("net/sched: cls_api: fix teardown of an adopted proto on insert-race loss"), which stopped the loser of the insert race from unlinking the winner's live proto but left the empty-proto residual in place. Conditions to recreate: - CONFIG_NET_CLS_FLOWER=y; veth pair - tc qdisc add dev veth0 ingress - two concurrent `tc filter add dev veth0 ingress protocol ip pref 1 flower skip_sw ... action drop` (both fail in fl_hw_replace_filter after publishing their handle in the idr); repeat in a loop - an empty flower tp stays linked after both requests fail; visible as a bare `filter protocol ip pref 1 flower chain 0` header in `tc filter show` with no filter entries - CAP_NET_ADMIN (namespace-local via unshare -Urn suffices) Fixes: 8b64678e0af8 ("net: sched: refactor tp insert/delete for concurrent execution") Reported-by: Sashiko (nipa) Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260805134049.927864-1-victor@mojatatu.com Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-JCOT.v1.20260910090924@mojatatu.com Signed-off-by: Jakub Kicinski commit aadf655e8ea9a8ffa24bb8d69f504572e8d18181 Author: Binbin Deng <18983559317@163.com> Date: Tue Sep 22 21:19:19 2026 +0800 net/mctp: publish the mctp_dev only after it is initialised mctp_add_dev() links the new mctp_dev into dev->mctp_ptr before mdev->dev is assigned, so a reader that picks the device up in that window dereferences a net_device pointer that is still NULL: KASAN: null-ptr-deref in range [0x00000000000000b0-0x00000000000000b7] Call Trace: ? __pfx_mctp_sendmsg (./include/linux/sockptr.h:49) ? __pfx_mctp_dst_output (net/mctp/route.c:41) ? selinux_socket_sendmsg (security/selinux/hooks.c:5278) ____sys_sendmsg (net/socket.c:775 (discriminator 1) net/socket.c:790 (discriminator 1) net/socket.c:2684 (discriminator 1)) ? __pfx_____sys_sendmsg (net/socket.c:1131) ? __pfx_copy_msghdr_from_user (net/socket.c:2590) ? update_cfs_rq_load_avg (kernel/sched/fair.c:5478) ___sys_sendmsg (net/socket.c:2738) ? __pfx____sys_sendmsg (net/socket.c:2625) ? perf_event_task_tick (./include/linux/rcupdate.h:838) ? sched_tick (kernel/sched/core.c:5818) ? clockevents_program_event (kernel/time/clockevents.c:372) ? fdget (./include/linux/rcupdate.h:873 fs/file.c:1100) __sys_sendmsg (net/socket.c:2770) ? __pfx___sys_sendmsg (net/socket.c:2751) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fix by publishing only once the object is fully initialised: __mctp_dev_get() runs under rcu_read_lock() only and hands this object to readers as soon as mctp_ptr is assigned, so they must never observe mdev->dev == NULL. Fixes: 583be982d934 ("mctp: Add device handling and netlink interface") Signed-off-by: Binbin Deng <18983559317@163.com> Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/729830b8.130.1a0c945579d.Coremail.18983559317@163.com Signed-off-by: Jakub Kicinski commit 6812ce4e4379ffc99c52401ec28f0d7ffbc36206 Merge: 75467f60a3d14f a9ed3aa9b87ee4 Author: Linus Torvalds Date: Fri Sep 25 16:00:18 2026 -0700 Merge tag 'drm-fixes-2026-09-26' of https://gitlab.freedesktop.org/drm/kernel Pull drm fixes from Dave Airlie: "While most of this is AI inspired fixes for error handling paths, leaks and use after frees, there are some normal things. nouveau has probably the biggest changes with some fixes to stabilise runtime suspend/resume on 570 firmware which regressed after we moved from 535, there are some fixes to stackframe issues seen with amdgpu, and otherwise the usual bunch of i915/xe/amdgpu fixes, and some virtio-gpu fixes. Hopefully it will start to quiten down a bit from here. client: - fix restore of partially initialized client i915: - Fix incorrect RCU teardown order leading to endless loop - Fix DP MST TU and FEC handling for disconnected streams - Fix selective fetch disable, again - Fix export namespace for kunit helpers - Workaround eDP flicker on a specific laptop model xe: - CRI throttle reasons report - TLB invalidation at wedge - SVM eviction and VM close - Display corruption on LNL on Xen PV - W/a fix and addition amdgpu: - Display ref count fix - Userq fixes - VCN 4, 5 reset fixes - Fixes for various error paths - Stack frame size fixes for various combinations of compilers and configs amdkfd: - Possible UAF fix nouveau: - runtime suspend/resume fixes for newer firmware - rcu free the scheduler - fix VRAM pinning - fix double free - fix reference leaks - fix runtime PM leak - fix cursor list usage problems - fix HDMI config rejection without SCDC virtio: - fix a bunch of object/memory leaks in failure paths - add pixel blend mode property to cursor plane - revert prime buffers import - sync shmem backing on guest transfers imagination: - propogate map failures properly - fix page count in map interface - clamp freelist reconstruction requests ivpu: - use separate flag for job timeout bridge: - samsung-dsim: fix TE GPIO lifetime for host attach" * tag 'drm-fixes-2026-09-26' of https://gitlab.freedesktop.org/drm/kernel: (60 commits) drm/amd/display: Bump frame warning limit for all builds of dml drm/imagination: clamp freelist reconstruction requests drm/imagination: Fix page count for page table for map() interface drm/imagination: Propagate map failures correctly from pvr_mmu_map_sgl() drm/amd/display: Bump frame warning limit for clang builds of dml drm/amd/display: Relax DML frame limit with UBSAN drm/amdgpu: Fix runtime PM leak in amdgpu_debugfs_test_ib_show() drm/amdgpu: Fix last_update fence leak in amdgpu_vm_init() drm/amdgpu: Fix acpi device leak in amdgpu_acpi_enumerate_xcc() drm/amdgpu: Fix vmid_wait fence leak in amdgpu_ring_init() drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping drm/amdgpu/vcn4.0.3: fix video_timeout unit mismatch in jpeg reset wait drm/amdgpu/vcn5.0.1: fix video_timeout unit mismatch in jpeg reset wait drm/amdgpu/userq: fix double jiffies conversion in hang detect timeout drm/amdgpu: move userq fence wait out of signalling section drm/amd/display: Fix dc stream excess put in dm_update_crtc_state() drm/xe: Add wa_14025941587 to xe2, xe3 and xe3p platforms drm/xe: harden adjust_idledly() against divide-by-zero and overflow drm/xe: Limit sg segment size to PAGE_SIZE on Xen PV drm/i915: fix incorrect RCU teardown order ... commit 75467f60a3d14f08f86f2b353298d2826382ff23 Merge: 049380360ca6f4 2776e9c28513a1 Author: Linus Torvalds Date: Fri Sep 25 15:55:03 2026 -0700 Merge tag 'ipe-pr-20260925' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe Pull IPE fixes from Fan Wu: "Two fixes for use-after-free issues found by recent LLM-assisted code analysis. - move successful policy load auditing under the new policy directory's inode lock, preventing a concurrent policy deletion from freeing the policy while it is still being audited - protect the dm-verity root hash with RCU, preventing policy evaluation from racing with root hash replacement during preresume" * tag 'ipe-pr-20260925' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe: ipe: protect the dm-verity root hash with RCU ipe: fix use-after-free when auditing a newly loaded policy commit a9ed3aa9b87ee41e8ab3ff471b1331c154767e45 Merge: 0f50dab8b4265e 45585c3aa28585 Author: Dave Airlie Date: Sat Sep 26 07:57:59 2026 +1000 Merge tag 'drm-misc-fixes-2026-09-24' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A number of fixes: - bridge: - samsung-dsim: fix GPIO lifetime - client: Null pointer dereference fix - imagination: error handling fix, page handling fix - nouveau: fix reference leaks, double-frees, out-of-bounds accesses, use-after-frees, don't reject config without SCDC, a number of workarounds - virtio: fix memory leak, reference leaks, null pointer dereference, add pixel blend mode, cache coherency fix Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patch.msgid.link/arU22zzqUGDEco1y@houat commit 049380360ca6f4cc22ac2f67fe95b98967c887f0 Merge: f14572c203d574 42d1221d321e55 Author: Linus Torvalds Date: Fri Sep 25 14:41:52 2026 -0700 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Mostly small driver fixes. The biggest fix is the one to the block zone handling which might trip for real or virtual hardware if the number of zones is > 2^32" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: megaraid_sas: Protect megasas_get_ctrl_info() in megasas_resume() scsi: sd_zbc: Reject disks with too many zones scsi: block: Fix zones_cond out-of-bounds write on zone report scsi: leapraid: Avoid -Wformat-security warning scsi: devinfo: Add BLIST_SKIP_IO_HINTS for EMC Symmetrix scsi: libiscsi_tcp: Check the data direction of a Data-In PDU scsi: ufs: pltfrm: Add quirk for R-Car S4 lacking lanes-per-direction scsi: ufs: core: Keep internal commands dispatchable during error handling commit 2776e9c28513a1c855a94792b292cbcc533418c8 Author: Fan Wu Date: Tue Sep 22 20:13:49 2026 -0700 ipe: protect the dm-verity root hash with RCU ipe_bdev_setintegrity() frees the old root hash when dm-verity publishes a new one on ->preresume, while policy evaluation can still be dereferencing it. Protect the root hash with RCU. The evaluation path already runs under rcu_read_lock(). Fixes: e155858dd995 ("ipe: add support for dm-verity as a trust provider") Cc: stable@vger.kernel.org Assisted-by: LLM [FW: remove model name according to latest guideline] Signed-off-by: Fan Wu commit 9814077275eca36ebf8d510d2f076d235ff9f51a Author: Fan Wu Date: Tue Sep 22 20:13:48 2026 -0700 ipe: fix use-after-free when auditing a newly loaded policy new_policy() audits the policy after ipe_new_policyfs_node() publishes it and drops the new directory's inode lock. A concurrent delete can free the policy while ipe_audit_policy_load() is still using it. Audit the successful load under that lock. Fixes: f44554b5067b ("audit,ipe: add IPE auditing support") Cc: stable@vger.kernel.org Assisted-by: LLM [FW: remove model name according to latest guideline] Signed-off-by: Fan Wu commit f14572c203d57492e1d4e5d7851a3b143e083b82 Merge: aa98230e410f0e e66cf1625ec4a3 Author: Linus Torvalds Date: Fri Sep 25 13:30:04 2026 -0700 Merge tag 'cifs-fixes-7.3-rc5' of https://git.manguebit.org/linux Pull smb client fixes from Paulo Alcantara: - Fix leaked server handles and dropped errors in the SMB2 compound create path: a parsing error reported as success, an earlier CREATE left open when a later command fails, the cached directory open losing the FID needed for cleanup, and SMB2_open() not closing the handle after a create-context parse failure - Fix out-of-bounds reads when parsing create contexts from a malicious server: bound each context by its Next field, parse the lease and QFid contexts from their declared offsets and validate the POSIX create context length - Fix a double credit decrement, and its warning, when a compound send fails and triggers a reconnect; found by syzbot - Fix a dentry and server handle leak in cifs_atomic_open() when an O_CREAT open resolves to a symlink or other non-regular inode - Use GFP_KERNEL in the DFS get_targets() path - Minor update to the POSIX extension specification references * tag 'cifs-fixes-7.3-rc5' of https://git.manguebit.org/linux: smb: client: use finish_no_open() for non-regular inodes smb: client: use GFP_KERNEL in get_targets() smb: client: update POSIX extension specification references smb: client: preserve create-context parsing errors smb: client: close completed creates on compound wait errors smb: client: clean up failed cached directory opens smb: client: close handle after create-context parsing failure smb: client: validate POSIX create context length smb: client: fix create context out-of-bounds reads smb: client: delete compound mids on send failure before unlock commit aa650d87a498844060eecb1d336f4d46f4d1b0b3 Author: Jérémy Jean Date: Tue Sep 22 20:27:35 2026 +0000 audit: fix exe mark UAF in kill_rules() kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry->rule.exe before removing the rule from the RCU-visible filter lists. After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free. KASAN reports: BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0 Unlink the published rules from the RCU-visible lists and retain them on tree->rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait. Cc: stable@vger.kernel.org Fixes: 34d99af52ad4 ("audit: implement audit by executable") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Ricardo Robaina Tested-by: Ricardo Robaina Reviewed-by: Bradley Morgan Signed-off-by: Paul Moore commit 1ca924044bf0de879a1648be93a56939652267d3 Author: Christian Göttsche Date: Wed Sep 23 12:13:23 2026 +0200 selinux: fix data race on AVC latest_notif 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 commit aa98230e410f0ed212b6788c46b1e4d49e0ff7ca Merge: a2ff1b626e1c9e b78b728e21c32e Author: Linus Torvalds Date: Fri Sep 25 11:12:06 2026 -0700 Merge tag 'vfs-7.3-rc5.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: - Revert "put_mnt_ns(): leave mounts connected". This allows the creation of reference count cycles in a very trivial way. We can't bring this in until we have fixed the underlying cause - vfs: Don't create the private nullfs instance for kthreads under namespace_sem to avoid false lockdeps complaints - binfmt_misc: - Copy the name into a stack buffer and look up the copy in bpf_binprm_select_interp() - bpf_binprm_set_interp() and bpf_binprm_set_interp_arg(): Check the private copy instead so the string that gets staged is the kstring that was checked - netfs: - Make netfs_read_gaps() use separate sink folios rather than one reused sink folio to discard unwanted data so that cifs checksum checking sees all the data that was fetched - Trim reads down to i_size so afs symlinks read correctly from the cache - Wrap the direct mempool ->alloc() calls the GFP_KERNEL paths make in alloc_hooks() via a new mempool_alloc_noreserve() helper - iov_iter: Use iov_iter_alignment() for the start and length check added to iov_iter_extract_bvecs() this cycle. It used iter_iov_addr() and iter_iov_len() which are only valid for ITER_UBUF and ITER_IOVEC iterators - super: Make iterate_supers_type() deletion-safe - inode: Stop evict_inodes() from rescanning the same inodes - writeback: Bound the cleanup_offline_cgwb() rescans - ntfs3: Use d_instantiate_new() in ntfs_create_inode() - ovl: Fix a use-after-free in the ovl_do_mkdir() debug print - dcache: Unpoison the inline name buffer in __d_alloc() for KMSAN - autofs: Fix a pipe file reference leak in autofs_kill_sb() - bpf: Drop the path_unlink and path_rmdir hooks from the list of hooks for which the verifier rewrites bpf_{set,remove}_dentry_xattr() to the _locked variants - squashfs: Range check the xz dictionary size before shifting by it - selftests: Add the missing eventfd, open_tree_ns, openat2 and xattr filesystems selftests to TARGETS and drop the stale openat2 entry left behind when those tests moved * tag 'vfs-7.3-rc5.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: netfs: Fix missing alloc tagging of direct mempool allocations bpf: fs/xattr: don't assume the inode is locked in path_unlink/path_rmdir autofs: fix sbi->pipe file reference leak in autofs_kill_sb() dcache: unpoison the inline name buffer in __d_alloc() ovl: fix UAF in ovl_do_mkdir() debug print super: make iterate_supers_type() deletion-safe Revert "put_mnt_ns(): leave mounts connected" Revert "selftests/filesystems: add mntns cleanup test" binfmt_misc: fix racy checks in bpf set_interp kfuncs binfmt_misc: fix OOB read in bpf_binprm_select_interp() fs: don't create the private nullfs mount under namespace_sem writeback: bound cleanup_offline_cgwb() rescans by rotating scanned inodes fs: avoid repeated scans in evict_inodes() netfs, afs: Fix symlink reading netfs: Fix netfs_read_gaps() to use separate sink folios squashfs: Add dictionary size range check to prevent shift-out-of-bounds fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot's "WARNING in do_new_mount" saga selftests/filesystems: fix missing and stale TARGETS entries block: Fix start and length check added to iov_iter_extract_bvecs() commit a2ff1b626e1c9e65c9d384cfb3da3d292025cb4b Merge: b9dbb658e2101e 883b776abe48fe Author: Linus Torvalds Date: Fri Sep 25 11:07:44 2026 -0700 Merge tag 'fs_for_v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs Pull isofs fix from Jan Kara: "A fix for reading tightly packed isofs directories" * tag 'fs_for_v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: isofs: Fix handling of directories with tight blocks commit ab39974240a0cff765f3bb9cce81d8001ffdb144 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 25 08:46:51 2026 +0200 bpf: Hold map BTF for the memory allocator destructor record bpf_ma_set_dtor() duplicates map->record so that the bpf_mem_alloc destructor can release the special fields of hash and rhash map elements once the allocator frees them for good. btf_record_dup() only acquires references on kernel and module BTF. Fields whose types live in the map BTF keep pointing into it: a kptr to a local type refers to map->btf, and a list_head or rb_root field carries a value_rec owned by the struct meta table of map->btf. That borrowed state can outlive the map. When RCU callbacks are still in flight, bpf_mem_alloc_destroy() copies the allocator and defers the final drain, together with the destructor context, to a workqueue. bpf_map_free() then frees map->record and drops the map's BTF reference as soon as map_free() returns. Once the program that loaded the BTF is gone as well, the BTF is freed while the worker still uses the duplicate. The worker dereferences it through btf_is_kernel() and btf_find_struct_meta() in bpf_obj_free_fields() when destroying elements that were freed under RCU, and through btf_is_kernel() in btf_record_free() when releasing the context itself: BUG: KASAN: slab-use-after-free in btf_is_kernel+0x19/0x30 Read of size 1 at addr ffff88811505dce8 by task kworker/u16:2/50 Workqueue: events_unbound free_mem_alloc_deferred Call Trace: btf_is_kernel+0x19/0x30 btf_record_free+0xc7/0xf0 htab_dtor_ctx_free+0x1a/0x30 free_mem_alloc_no_barrier+0x39/0x230 free_mem_alloc_deferred+0x2a/0x40 process_scheduled_works+0x5ce/0x9d0 worker_thread+0x42a/0x5e0 kthread+0x1f5/0x230 ret_from_fork+0x1dd/0x390 ret_from_fork_asm+0x1a/0x30 Allocated by task 358: __kmalloc_cache_noprof+0x287/0x510 btf_new_fd+0xf7/0x3d0 __sys_bpf+0x487/0x840 Freed by task 0: kfree+0x186/0x560 rcu_core+0x6f6/0xd40 Freeing a map that still holds more elements than the allocator's high watermark is enough to get there, because the bulk free during teardown queues the RCU callback that makes bpf_mem_alloc_destroy() defer. Non-preallocated hash maps and resizable hash maps both register the destructor and are affected alike. Keep one reference on the map BTF in the destructor context. Every non-kernel pointer in the duplicated record is either map->btf or memory owned by it, so a single reference covers kptrs, list heads, and rb roots, and mirrors what bpf_map_meta_alloc() does for the duplicated record of an inner map. Release it only after the duplicated record has been freed: the worker is preemptible and not in an RCU read-side critical section, so dropping the last reference first would let the BTF be freed while btf_record_free() still reads its fields. Fixes: 1df97a7453ee ("bpf: Register dtor for freeing special fields") Reported-by: Yuan Chen Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20260901062845.1379760-3-chenyuan_fl@163.com Link: https://patch.msgid.link/20260925064652.2261885-1-memxor@gmail.com commit b9dbb658e2101ea37ad6953eb4e2ea234dd9681a Merge: 4ba51ef66a7773 ec0d89150a9381 Author: Linus Torvalds Date: Fri Sep 25 10:11:15 2026 -0700 Merge tag 'thermal-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fix from Rafael Wysocki: "Fix a step-wise thermal governor issue that causes thermal mitigation to contiune forever after the temperature has dropped below the trip point threshold in some cases (Manaf Meethalavalappu Pallikunhi)" * tag 'thermal-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: gov_step_wise: Fix stale mitigation vote with non-zero lower bounds commit 4ba51ef66a7773c2ce4a5356e2f97f5c291463ca Merge: 547463efb935de 41112a787f9182 Author: Linus Torvalds Date: Fri Sep 25 09:47:05 2026 -0700 Merge tag 'pm-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Address a hibernation regression introduced during the 7.2 development cycle that causes the image memory preallocation to deadlock if it depends on frozen kernel threads (Florian Schmaus)" * tag 'pm-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM: hibernate: Freeze kernel threads after image preallocation commit 547463efb935dec67c476f90917a0ff4baf6d0b5 Merge: 80e466f0c8acc5 5b76268dac9686 Author: Linus Torvalds Date: Fri Sep 25 09:39:33 2026 -0700 Merge tag 's390-7.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Heiko Carstens: - Fix several bugs in PCI error recovery SCLP reporting: don't report success on skipped recovery, report errors when no pdev is associated, add missing device lock, and fix struct pci_dev reference leak in zpci_report_status() - Fix several bugs in CIO code: fix use of invalid SCHIB data, guard PMCW field accesses, check device number valid bit in PMWC before accessing other fields, and fix NULL pointer dereference in ccw_device_get_util_str() - Fix virtual vs physical address confusion in channel measurement facility code on kernels with CONFIG_RANDOMIZE_IDENTITY_BASE=y - Fix couple of bugs in s390dbf: fix copy of failed static debug areas, skip view registration on failure, and reject NULL pointer in debug_dump() - Fix sriov_numvfs attribute name in zPCI documentation - Fix typos in comments * tag 's390-7.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/cio: Fix NULL pointer dereference in ccw_device_get_util_str() s390/debug: Fix NULL pointer dereference in debug_info_copy() s390/debug: Do not register views for failed static debug areas s390/debug: Reject NULL debug info in debug_dump() s390/cmf: Fix virtual vs physical address confusion s390/pci: Don't report recovery success on skipped recovery s390/pci: Report SCLP status on error events when no pdev is associated s390/pci: Fix missing device lock in zpci_report_status() s390/pci: Fix leak of struct pci_dev reference in zpci_report_status() s390/cio: Guard PMCW field accesses with dnv check s390/cio: Check pmcw.dnv before pmcw.ena in I/O entry points s390/cio: Fix cio_update_schib() to not cache invalid schib s390/pci/docs: Fix sriov_numvfs attribute name s390: Fix typos in comments commit 80e466f0c8acc545159a1f1fcca62512bf848413 Merge: 165768bb70265b 270437f3fe6251 Author: Linus Torvalds Date: Fri Sep 25 09:35:07 2026 -0700 Merge tag 'gpio-fixes-for-v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix a regression introduced by moving GPIO hog handling into GPIOLIB core where of_node_name was used if line name property was missing on DT systems - fix kernel stack leak to user-space in error path in GPIO character device code - fix runtime PM leaks in gpio-xilinx and gpio-arizona - fix several register programming bugs in gpio-tps65219 - fix interrupt storm on resume in gpio-mvebu * tag 'gpio-fixes-for-v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: tps65219: Fix TPS65214 GPIO direction programming gpio: tps65219: Use the variant-specific direction callback gpio: tps65219: Fix GPIO input value reads gpio: zynq: fix runtime PM leak on request error path gpio: cdev: fix kernel stack leak to user-space in error path gpiolib: use of_node_name if line-name is missing gpio: mvebu: keep resume masks within the irqchip cache gpio: arizona: Fix runtime PM leak in arizona_gpio_direction_out() commit c5a8fc2abe05cf6db71f57ff0177fddc59861a1a Author: Jasper Firth Date: Fri Sep 25 23:06:25 2026 +1000 ASoC: Intel: bytcr_rt5651: Add quirk for Chuwi Hi8 with generic DMI strings Some Chuwi Hi8 tablets with model number CWI513 ship with a BIOS (American Megatrends 5.11, dated 05/21/2016) whose DMI sys_vendor and product_name are both "Default string". The tested unit is labelled just "Hi8", but its model number is the same as the existing "Chuwi Hi8 Pro (CWI513)" entry, and it needs the same quirks. That entry matches on sys_vendor "Hampoo" and product_name "X1D3_C806N", so it never applies to these units. Without its quirks the internal speaker, whose amplifier has a differential input wired across LOUT left and right, cancels to a faint distorted residual for any centred (L == R) content, and the headphone channels are swapped. Add an entry matching board_vendor "Hampoo" and board_name "Cherry Trail CR", plus the BIOS date since those two are too generic on their own. drivers/platform/x86/touchscreen_dmi.c already matches the Chuwi HiBook the same way. The quirks are those of the existing Hi8 Pro entry, except for the over-current detection scale factor: 1.0 instead of the 0.75 from BYT_RT5651_DEFAULT_QUIRKS. With 0.75 and a CTIA headset (inline mic and one button), loud speech into the mic, and headphone playback coupling onto the mic line, were reported as spurious KEY_PLAYPAUSE presses, one of them held for a whole 8 second speech window. With 1.0 the same test gave no spurious events, and 3 real button presses were reported as exactly 3 press/release pairs. Tested on a unit with the generic DMI strings, with a module built from this patch and no quirk module parameter. The quirks were applied via the new entry, the card components read "cfg-spk:1 cfg-mic:in2 cfg-hp:lrswap", and the following all work: speaker, headphone left/right order, jack and headset-mic detection, headset button, and the internal and headset mics. The problem was diagnosed with the help of an AI coding assistant, which also drafted this changelog. Assisted-by: Claude Opus 5.5 Signed-off-by: Jasper Firth Link: https://patch.msgid.link/20260925-hi8-quirk-v1-1-ffd00b0447f9@hotmail.com Signed-off-by: Mark Brown commit b78b728e21c32ec4c330b299f657fb1eb02dffc2 Author: Hao Ge Date: Wed Sep 23 14:37:59 2026 +0800 netfs: Fix missing alloc tagging of direct mempool allocations 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) commit 35d442ed1f86465e49df3119fb898f985186db13 Author: Andrea Parri Date: Tue Sep 22 16:55:30 2026 +0200 bpf: fs/xattr: don't assume the inode is locked in path_unlink/path_rmdir bpf_lsm_has_d_inode_locked() makes the verifier rewrite bpf_[set|remove]_dentry_xattr() to the _locked variants, which assume that the caller already holds the inode's i_rwsem. The path_unlink and path_rmdir hooks are listed, but security_path_unlink() and security_path_rmdir() run before vfs_unlink()/vfs_rmdir() take the victim inode's i_rwsem, so a sleepable BPF LSM program attached to either hook mutates the victim's xattrs without the lock held. Drop the two path hooks from d_inode_locked_hooks so that the verifier keeps the locking bpf_[set|remove]_dentry_xattr() variants, which take the lock themselves. Fixes: 56467292794b8 ("bpf: fs/xattr: Add BPF kfuncs to set and remove xattrs") Cc: stable@vger.kernel.org Signed-off-by: Andrea Parri Link: https://patch.msgid.link/20260922145530.369775-1-parri.andrea@gmail.com Signed-off-by: Christian Brauner (Amutable) commit 762a6411a5a7aa4119570bae590662312ccb4be3 Merge: aa5e44b29ffe4e 3f5dc09141a7bf Author: Christian Brauner Date: Fri Sep 25 17:20:36 2026 +0200 Merge patch series "mount: a few gnarly fixes" Christian Brauner says: A short while ago I received a bug report about problematic behavior in the mount code and that let me to review and model a few corner cases including reference counting. The result is the following set of fixes: - Ensure that copies of unbindable mounts remain unbindable - Ensure that MOVE_MOUNT_SET_GROUP doesn't operate on unbindable mounts so we don't create an undefined state where a mount is both unbindable and a slave mount. - Ensure that we don't silently unmount busy mounts. This is nasty because it's an old bug from v4.13 where calculation of whether a synchronous (non-MNT_DETACH) umount would succeed drifted apart from the actual codepath that did the unmount. - Ensure that we don't silently unmount busy mounts. Same class, different mechanism. There's a race between the reference count check in propagate_mount_busy() (summing up per-cpu counters) and mntget(). Fixes and test for all. No test for the mntget() race because that needs aritifical delays. And fwiw, I think I another vomitorious series in the pipes. * patches from https://patch.msgid.link/20260923-work-mount-fixes-v1-0-f424cf8d3242@kernel.org: docs: update the unmount propagation rule fs: don't let a migrating task hide its reference from do_umount() selftests/filesystems: check that a busy propagated copy blocks a synchronous umount fs: don't silently unmount busy mounts selftests/move_mount_set_group: check that an unbindable target is refused mount: refuse MOVE_MOUNT_SET_GROUP on an unbindable mount selftests/filesystems: check that a copied mount namespace keeps unbindable mount: keep a copied mount unbindable Link: https://patch.msgid.link/20260923-work-mount-fixes-v1-0-f424cf8d3242@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 3f5dc09141a7bfe286620a6869d1d70ffe32d6b8 Author: Christian Brauner Date: Wed Sep 23 14:28:00 2026 +0200 docs: update the unmount propagation rule Section 5f still describes the rule propagate_umount() used before commit f0d0ba19985d ("Rewrite of propagate_umount()"). It states that a mount that receives the unmount by propagation is left alone as soon as it has any submount. That's not true anymore. A propagated unmount unmounts a mount with sub-mounts as long as every sub-mount gets unmounted together with it. This is the case when the sub-mounts are unmounted by the same propagation. Only a sub-mount that cannot be unmounted keeps its parent mounted. The section also only describes a single mount without sub-mounts. But lazy unmounts take a tree and every mount of the tree propagates its unmount from its parent mount. Link: https://patch.msgid.link/20260923-work-mount-fixes-v1-8-f424cf8d3242@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 7eb84d54fac5002bd975d1de8fd61d57e89172ab 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() 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) commit bba9960c073dbea8eaa31e9a6b9f4224ebdb6ec8 Author: Christian Brauner Date: Wed Sep 23 14:27:58 2026 +0200 selftests/filesystems: check that a busy propagated copy blocks a synchronous umount A slave namespace moves an open_tree() copy of the shared tree beneath the propagated copy of the victim and keeps the descriptor. Check that: - umount(2) of the victim fails with EBUSY while the descriptor is open - the moved tree is still attached in the slave namespace afterwards - the umount succeeds once the descriptor is closed The test needs CAP_SYS_ADMIN and skips otherwise. Link: https://patch.msgid.link/20260923-work-mount-fixes-v1-6-f424cf8d3242@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 6857e209015f95be7a8f19a9cd5dac345b9b9859 Author: Christian Brauner Date: Wed Sep 23 14:27:57 2026 +0200 fs: don't silently unmount busy mounts 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) commit 7541865c260f9bef9fecf212ec39538a21daaf77 Author: Christian Brauner Date: Wed Sep 23 14:27:56 2026 +0200 selftests/move_mount_set_group: check that an unbindable target is refused MOVE_MOUNT_SET_GROUP must not accept an unbindable mount as the target. Cover both sources: - a slave, which used to leave the target unbindable and a slave at once - a shared mount, which used to silently drop the unbindable flag Check that the target is untouched after the refused call. Link: https://patch.msgid.link/20260923-work-mount-fixes-v1-4-f424cf8d3242@kernel.org Signed-off-by: Christian Brauner (Amutable) commit a2b42babc912e4fb428cbb42adb4f6e1e067113d Author: Christian Brauner Date: Wed Sep 23 14:27:55 2026 +0200 mount: refuse MOVE_MOUNT_SET_GROUP on an unbindable mount 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) commit 0bab6b6d77607458a25710a42c42ae2343468d2c Author: Christian Brauner Date: Wed Sep 23 14:27:54 2026 +0200 selftests/filesystems: check that a copied mount namespace keeps unbindable Make a tmpfs unbindable, copy the mount namespace and check from the copy that: - a bind of the mount fails with EINVAL - a recursive bind fails as well - open_tree(OPEN_TREE_CLONE) of it fails - mountinfo still shows it as unbindable - a copy of the copy refuses the bind too The first case runs in the original namespace so the fixture stays honest about what it set up. Link: https://patch.msgid.link/20260923-work-mount-fixes-v1-2-f424cf8d3242@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 1ab8904ae61b076d1242e1f48537698c77074b5c Author: Christian Brauner Date: Wed Sep 23 14:27:53 2026 +0200 mount: keep a copied mount unbindable 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) commit 4a5e49ba0abb8b4328d6318c9aef0c0121f95507 Author: Guixin Liu Date: Mon Sep 14 18:57:13 2026 +0800 nvme-multipath: set BLK_FEAT_ZONED only after the zone info is known The namespace head is marked zoned at allocation time based only on the command set identifier. If the zone info query reports a zero zone size, the path namespace is registered without zoned limits while the head still advertises the zoned capability with a zone size of zero, and reporting zones or writing to the head then shifts by ilog2(0). Drop the zoned feature from the head allocation and let the head limits refresh stack it in from the path namespace instead. Fixes: 28982ad73d6a ("nvme: set BLK_FEAT_ZONED for ZNS multipath disks") Fixes: 3838e80fcfb3 ("nvme: skip the zoned limits update if the zone info query failed") Cc: stable@vger.kernel.org Signed-off-by: Guixin Liu Signed-off-by: Keith Busch commit 72ece656abd4de8645a421fb482d7a11e6533a45 Author: Yao Sang Date: Tue Sep 22 15:37:30 2026 +0800 nvme: fix command effects log lifetime for multipath heads KASAN reported a use-after-free when an I/O passthrough command was sent through a multipath namespace head after the controller path that first created the head had been removed: BUG: KASAN: slab-use-after-free in nvme_command_effects+0x192/0x200 [nvme_core] Read of size 4 at addr ffff888141b14400 by task nvme/19811 nvme_command_effects+0x192/0x200 [nvme_core] nvme_cmd_allowed+0x7e/0x1b0 [nvme_core] nvme_user_cmd.constprop.0+0x1b5/0x450 [nvme_core] nvme_ns_head_chr_ioctl+0xf4/0x2a0 [nvme_core] Move the log cache to the subsystem, with one entry per command set. Both controllers and namespace heads hold subsystem references, keeping their log pointers valid until subsystem release. Fixes: be93e87e7802 ("nvme: support for multiple Command Sets Supported and Effects log pages") Reviewed-by: Christoph Hellwig Signed-off-by: Yao Sang Signed-off-by: Keith Busch commit 3fdd281e0a049a804b2512c4cb3d685e5358aee8 Author: Nilay Shroff Date: Fri Sep 18 21:57:31 2026 +0530 nvmet: don't allow I/O admission after percpu ns reference is killed nvmet_req_find_ns() uses percpu_ref_get() to obtain a reference to the namespace. However, percpu_ref_get() can acquire a reference even after the namespace reference has been killed (or marked DEAD). This is undesirable during namespace disable because nvmet_ns_disable() kills the namespace reference and then waits for all outstanding references to drain. Acquiring a new reference after the reference is killed can therefore extend the namespace drain period. Replace percpu_ref_get() in nvmet_req_find_ns() with percpu_ref_tryget_live_rcu(), which only acquires a reference while the namespace reference is still live. This handles the race where nvmet_req_find_ns() finds ns is admitting I/O (or it's live) but before it acquires the reference to ns, its reference is killed in nvmet_ns_disable(). For instance check this race: CPU0 CPU1 nvmet_req_find_ns(): nvmet_ns_disable(): xa_load() -> ns IO_LIVE == set xa_clear_mark() percpu_ref_kill() // DEAD percpu_ref_get() synchronize_rcu() | wait_for_completion() +-- succeed Replacing percpu_ref_get() with percpu_ref_tryget_live_rcu() prevents the I/O request from acquiring a namespace reference once the reference has been marked DEAD. Perform the namespace lookup and reference acquisition in nvmet_req_find_ns() within an RCU read-side critical section. nvmet_ns_disable() uses synchronize_rcu() before draining and exiting the namespace reference, ensuring that RCU readers which may be acquiring the namespace reference have completed before the reference is exited. Reviewed-by: Christoph Hellwig Signed-off-by: Nilay Shroff Signed-off-by: Keith Busch commit 42b0f5196dc2f2113368993317eccbfd1127f298 Author: Nilay Shroff Date: Fri Sep 18 21:57:30 2026 +0530 nvmet: defer setting ns->enabled to false in nvmet_ns_disable() nvmet_ns_disable() currently clears ns->enabled before draining in-flight I/O references. This allows namespace configuration to be changed while existing I/O requests can still hold a reference to the namespace. This can race with configuration of namespace attributes such as the device path, UUID, NGUID etc. These attributes can be accessed by I/O requests without holding subsys->lock and must not be modified while such requests are still using the namespace. In nvmet_ns_disable(), keep ns->enabled set while existing namespace references are being drained, so namespace configuration remains blocked until all in-flight I/O has completed. Set ns->enabled to false only after the namespace references have been drained and the namespace device has been disabled. Introduce the NVMET_NS_IO_LIVE flag, which is set after the namespace is successfully enabled in nvmet_ns_enable(). When nvmet_ns_disable() starts, clear NVMET_NS_IO_LIVE so that the I/O path stops admitting new I/O once the flag is cleared. Using test_and_clear_bit() in nvmet_ns_disable() also prevents concurrent callers from starting a second disable operation. Reviewed-by: Christoph Hellwig Signed-off-by: Nilay Shroff Signed-off-by: Keith Busch commit 5211fed41d7ec90e9ab7239dc4bffffe4d0b2b62 Author: Guixin Liu Date: Wed Sep 16 19:42:54 2026 +0800 nvmet: copy the hostid into the ctrl before creating PR pc_refs Commit 6202783184bf ("nvmet: Improve nvmet_alloc_ctrl() interface and implementation") added a second uuid_copy() of args->hostid near the end of nvmet_alloc_ctrl(), and commit 7b658153f1b8 ("nvmet: Remove duplicate uuid_copy") removed the original copy that sat before nvmet_ctrl_init_pr() instead of the new one. Since then nvmet_ctrl_init_pr() snapshots ctrl->hostid into the per-controller per-namespace reservation refs while the uuid_copy() from the connect data runs later, after the controller is published. The ctrl is allocated with kzalloc(), so every pc_ref created on this path stores the nil UUID. pc_ref->hostid has a single consumer: nvmet_pr_set_ctrl_to_abort() matches it against the preempted registrant's hostid to kill and drain the victim's in-flight I/O for Preempt and Abort. The match can never hit with the nil UUID, so whenever a namespace with reservations enabled exists before a host connects, which includes every reconnect, Preempt and Abort silently degrades into a plain Preempt: the preempting host sees success while the victim's in-flight I/O is still in the air. Copy the hostid where the rest of the connect data is consumed, before the controller is published and before nvmet_ctrl_init_pr() takes its snapshot. Fixes: 7b658153f1b8 ("nvmet: Remove duplicate uuid_copy") Cc: stable@vger.kernel.org Reviewed-by: Nilay Shroff Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Guixin Liu Signed-off-by: Keith Busch commit fa6778e030bed9841ddcdf96bc7018da9ac03562 Author: Weiming Shi Date: Sun Sep 13 01:10:11 2026 +0800 nvmet-auth: fix out-of-bounds write in nvmet_auth_challenge() nvmet_auth_challenge() receives its output buffer as a void pointer. sizeof(*d) therefore evaluates to one with GCC and undercounts the fixed challenge header by 15 bytes. A short AUTH_RECEIVE buffer can pass the check before the challenge is copied past the end of its allocation. Use the typed challenge pointer when calculating the response size. BUG: KASAN: slab-out-of-bounds in nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569) Write of size 32 by task kworker/1:1H/64 Workqueue: nvmet_tcp_wq nvmet_tcp_io_work Call Trace: nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569) nvmet_tcp_try_recv_pdu (drivers/nvme/target/tcp.c:1119 drivers/nvme/target/tcp.c:1243) nvmet_tcp_io_work (drivers/nvme/target/tcp.c:1350 drivers/nvme/target/tcp.c:1382 drivers/nvme/target/tcp.c:1445) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address is located 16 bytes inside of allocated 33-byte region [ffff888000554e80, ffff888000554ea1) Kernel panic - not syncing: KASAN: panic_on_warn set ... Cc: stable@vger.kernel.org Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Reported-by: co+77553a7fc66ac133@bugs.sh Closes: https://lore.kernel.org/all/Ah6QavQXwvshtqyUcYD1P1R7XE0ND9fB7lbV@bugs.sh/ Assisted-by: Codex:gpt-5.6 Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Weiming Shi Signed-off-by: Keith Busch commit 5d5fbfbbacd1efb13a9bf91317d4fde859ede4b9 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Tue Sep 15 12:51:23 2026 +0900 nvmet: pci-epf: reject too-short SGL segments The host controls an SGL segment's length. A nonzero length smaller than one SGL descriptor makes nr_descs zero, so nvmet_pci_epf_get_sgl_segment() reads the type byte of sgls[-1] outside the allocated buffer. If that byte contains a segment descriptor type, the function also copies the preceding 16 bytes and returns a negative descriptor count. The read was reproduced in 3/3 KASAN boots with only the host transfer mocked by a KUnit test: BUG: KASAN: slab-out-of-bounds in nvmet_pci_epf_get_sgl_segment Read of size 1 by task kunit_try_catch Call Trace: nvmet_pci_epf_get_sgl_segment nvmet_pci_epf_short_sgl_test Kernel panic - not syncing: KASAN: panic_on_warn set ... Reject segments that cannot hold one descriptor before allocating or transferring their contents. Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Christoph Hellwig Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Keith Busch commit 63fa2d9c9c37020bd2703fe2a6a38027b5abeb15 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Tue Sep 15 11:19:56 2026 +0900 nvme-multipath: fix underflow in ANA log bounds checks The number of ANA groups advertised through Identify Controller sizes the ANA log buffer. The ANA log header and group descriptors independently supply the number of groups and namespace IDs to parse. Both bounds checks subtract an untrusted object size from ana_log_size before comparing the current offset. If the object is larger than the buffer, the size_t subtraction underflows and lets the parser read beyond ana_log_buf. Check the current offset before the first subtraction and compare each object size with the remaining buffer instead. This rejects inconsistent ANA data before dereferencing a truncated group descriptor or walking an oversized namespace ID array. Fixes: 0d0b660f214d ("nvme: add ANA support") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Christoph Hellwig Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Keith Busch commit 7f4d0c359bbac4ba8691bf9b4213bf9ab07cd2a4 Author: Arnd Bergmann Date: Thu Sep 17 08:04:03 2026 +0200 nvme: work around all -Wformat-security warnings The sysfs code passes two string variables into sysfs_emit(), which is safe in this instance but causes the compiler to warn when -Wformat-security is enabled: host/sysfs.c: In function ‘cntrltype_show’: host/sysfs.c:682:9: error: format not a string literal and no format arguments [-Werror=format-security] 682 | return sysfs_emit(buf, type[ctrl->cntrltype]); Print these using a "%s" format like all other instances in the same file. Reviewed-by: Nilay Shroff Signed-off-by: Arnd Bergmann Signed-off-by: Keith Busch commit 6b8a5367e9e73a17561b8ce584ae77a43f712007 Author: Arnd Bergmann Date: Wed Sep 16 13:44:51 2026 +0200 nvme: work around -Wformat-security warning Passing a string variable into dev_set_name() causes a warning when building with -Wformat-security enabled: drivers/nvme/host/core.c: In function 'nvme_cdev_add': drivers/nvme/host/core.c:3911:9: error: format not a string literal and no format arguments [-Werror=format-security] 3911 | ret = dev_set_name(cdev_device, name); Remove the temporary strings and let dev_set_name() do the same thing internally. Fixes: 26acdaa357cd ("nvme: fix crash and memory leak during invalid cdev teardown") Reviewed-by: Nilay Shroff Reviewed-by: John Garry Reviewed-by: Damien Le Moal Signed-off-by: Arnd Bergmann Signed-off-by: Keith Busch commit c20bba234f3e1dcd81f7a2ec21ea7bf01a4cf35f Author: Maurizio Lombardi Date: Tue Sep 15 11:58:27 2026 +0200 nvme: do not reset controllers in NVME_CTRL_NEW state During NVMe controller creation, the controller is exposed to sysfs via nvme_add_ctrl() while it is still in the NVME_CTRL_NEW state. This creates a narrow race window where a userspace process can write to the reset_controller sysfs node before the initialization thread transitions the state to NVME_CTRL_CONNECTING. If a reset is triggered during this window, the state machine allows the transition from NVME_CTRL_NEW to NVME_CTRL_RESETTING, and the reset work is queued. However, the original creation thread continues its execution, subsequently moving the state to NVME_CTRL_CONNECTING and finally to NVME_CTRL_LIVE. When the delayed reset work finally executes, it attempts to tear down the controller and transition the state to NVME_CTRL_CONNECTING. Because the state is now NVME_CTRL_LIVE, this transition fails, triggering a WARN_ON in the reset work. Fix this by removing NVME_CTRL_NEW from the allowed prior states for the NVME_CTRL_RESETTING transition. Fixes: 8bfc3b4c6f9d ("nvmet: switch loopback target state to connecting when resetting") Reported-by: syzbot+4a1d521d19d6321f5aad@syzkaller.appspotmail.com Reviewed-by: Daniel Wagner Signed-off-by: Maurizio Lombardi Signed-off-by: Keith Busch commit 447a7a3026eda85ac2738cbe6ee5ab066a39dad0 Author: Eric Dumazet Date: Mon Sep 14 16:48:53 2026 +0900 nvme-tcp: delay nvme_tcp_reclassify_socket() Commit 841aee4d75f1 ("nvme-tcp: lockdep: annotate in-kernel sockets") introduced nvme_tcp_reclassify_socket() to resolve a lockdep WARN by distinguishing userspace sockets from nvme-tcp sockets. After that, TLS encryption support was introduced to nvme-tcp and it added another lock dependency on userspace socket handling by tlshd, which resulted in a new lockdep WARN. This WARN was hidden by the commit 19bdb70c77d3 ("nvme-tcp: lockdep: use dynamic lockdep keys per socket instance"). However, it turned out the commit 19bdb70c77d3 has a bug of lockdep key lifetime management, and it is to be reverted by another patch in this series. After the revert, the WARN was unveiled and observed at the blktests test case nvme/062: WARNING: possible circular locking dependency detected 7.3.0-rc2+ #455 Tainted: G W ------------------------------------------------------ tlshd/75867 is trying to acquire lock: ffffffff91ada5e0 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_cache_noprof+0x64/0x6d0 but task is already holding lock: ffff888197808258 (sk_lock-AF_INET-NVME){+.+.}-{0:0}, at: do_tcp_setsockopt+0x499/0x26a0 which lock already depends on the new lock. To fix the lockdep WARN caused by the TLS encryption support, delay the reclassification of the nvme-tcp sockets. Currently the reclassification happens before the TLS handshake starts, which pulls in the additional lock dependencies related to tlshd. Reclassify the sockets after the TLS handshake instead, to cut that dependency. Link: https://lore.kernel.org/lkml/CANn89i+wnTLC==UnXCpjsS4YxvEfhe5oK0N7fttbqr1zKyqdug@mail.gmail.com/ Reviewed-by: Nilay Shroff Signed-off-by: Eric Dumazet Signed-off-by: Shin'ichiro Kawasaki Signed-off-by: Keith Busch commit 7fc61cdab13004a5e6dff5b279918b19b62eb200 Author: Shin'ichiro Kawasaki Date: Mon Sep 14 16:48:52 2026 +0900 Revert "nvme-tcp: lockdep: use dynamic lockdep keys per socket instance" This reverts commit 19bdb70c77d3b24239a453291299b64040bdba86. The commit 19bdb70c77d3 ("nvme-tcp: lockdep: use dynamic lockdep keys per socket instance") addressed the lockdep WARN caused by the circular lock dependency among six locks: set->srcu -> sk_lock -> cpu_hotplug_lock -> fs_reclaim -> q_usage_counter -> elevator_lock -> set->srcu As its title says, the commit cut the dependency by introducing the dynamic lockdep keys per socket instance. However, as described in the Link tag URL, the commit made a wrong assumption: it assumed that __fput_sync(queue->sock->file) in nvme_tcp_free_queue() would synchronously destroy the socket. This is wrong: when in-flight packets cause delayed free of the socket, the prematurely freed lockdep key is referred to and causes another WARN. The commit is an imperfect fix. Hence revert it. To address the circular dependency among the six locks, another solution is required. It is provided by the commit 0ba6912f7e97 ("Revert "once: don't use a work queue to reset sleepable static key""). It cuts the dependency between sk_lock and cpu_hotplug_lock. This solution is simpler, and reduces the complexity in nvme-tcp. Link: https://lore.kernel.org/lkml/CANn89i+wnTLC==UnXCpjsS4YxvEfhe5oK0N7fttbqr1zKyqdug@mail.gmail.com/ Reviewed-by: Eric Dumazet Reviewed-by: Nilay Shroff Signed-off-by: Shin'ichiro Kawasaki Signed-off-by: Keith Busch commit 1c1a342aceec79528b3ba51f376eca2be5928fe7 Author: Sagnik Sasmal Date: Thu Sep 10 22:44:05 2026 +0000 mtd: spinand: Do not update the QE bit on devices without one Commit be0b86c648bf ("mtd: spinand: Gather all the bus interface steps in one single function") moved quad-enable setup into spinand_configure_chip(). The new code only determines whether quad mode is needed when SPINAND_HAS_QE_BIT is set, but calls spinand_init_quad_enable() unconditionally. This clears configuration register bit 0 on devices without a QE bit. That bit is not universally a QE bit. On the Winbond W25N02KV it is H-DIS, which disables the active-low HOLD function. Clearing H-DIS enables HOLD during single and dual I/O operations. If IO3 is not kept high, the flash can pause a command and ignore clock and data. H-DIS is not restored by the FFh reset command, allowing the incorrect state to survive an SoC warm reboot while the flash remains powered. Before the refactoring, spinand_init_quad_enable() returned without touching the configuration register on devices without SPINAND_HAS_QE_BIT. Restore that behavior by only calling the helper when the flag is set. Return zero explicitly once SSDR configuration completes, as all errors are returned immediately. This avoids returning an uninitialized value when neither optional configuration step runs. The regression was reproduced on a JioRouter JIDU6401 with an MT7986 SoC and a W25N02KV. With Linux 6.18.44, sysupgrade failed and the following warm reboot hung in BL2. With this change applied, both sysupgrade and warm reboot completed successfully. Fixes: be0b86c648bf ("mtd: spinand: Gather all the bus interface steps in one single function") Cc: stable@vger.kernel.org Suggested-by: Miquel Raynal Assisted-by: LLM Signed-off-by: Sagnik Sasmal Signed-off-by: Miquel Raynal commit aa5e44b29ffe4eaa08cc2237fd65bc2596bc023e Author: Hui Peng Date: Sat Sep 19 20:48:08 2026 +0000 autofs: fix sbi->pipe file reference leak in autofs_kill_sb() When autofs_fill_super() fails before clearing AUTOFS_SBI_CATATONIC (for example, when find_get_pid() fails on an invalid pgrp mount option, or when an fs_context is closed before mounting), deactivate_locked_super() invokes autofs_kill_sb() -> autofs_catatonic_mode(sbi). Because AUTOFS_SBI_CATATONIC is still set in sbi->flags, autofs_catatonic_mode() returns early without calling fput(sbi->pipe), permanently leaking the pipe struct file reference. Explicitly release sbi->pipe in autofs_kill_sb() if it is still non-NULL after autofs_catatonic_mode(). Fixes: ebc921ca9b92 ("autofs: copy autofs4 to autofs") Signed-off-by: Hui Peng Link: https://patch.msgid.link/20260919204808.2812930-1-benquike@gmail.com Signed-off-by: Christian Brauner (Amutable) commit 5bfa9f1a9dcb6ecb607adbc1c0226605c972935b Author: Andrea Parri Date: Thu Sep 24 11:21:39 2026 +0200 kprobes: Fix permanent hang when flushing the kprobe optimizer Writing 0 to /proc/sys/debug/kprobes-optimization while a kprobe is jump-optimized never returns. The writer sleeps in D state forever with kprobe_sysctl_mutex held, so any later read or write of that sysctl hangs as well. For example, with vfs_read+9 as an optimizable address in this build: # cd /sys/kernel/tracing # echo 'p:myprobe vfs_read+9' >> kprobe_events # echo 1 > events/kprobes/myprobe/enable # # wait until /sys/kernel/debug/kprobes/list shows [OPTIMIZED] # echo 0 > /proc/sys/debug/kprobes-optimization INFO: task sh:246 blocked for more than 10 seconds. Call Trace: __schedule+0x1176/0x4f70 schedule+0xdc/0x2c0 schedule_timeout+0x17b/0x260 wait_for_completion+0x173/0x3c0 wait_for_kprobe_optimizer_locked+0xbc/0x130 proc_kprobes_optimization_handler+0x156/0x1b0 proc_sys_call_handler+0x324/0x490 vfs_write+0x52d/0xfe0 ksys_write+0xff/0x200 do_syscall_64+0x106/0x630 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... INFO: task cat:265 is blocked on a mutex likely owned by task sh:246. wait_for_kprobe_optimizer_locked() reinitializes optimizer_completion, asks the optimizer thread to flush and sleeps in wait_for_completion(). The thread drains the (un)optimizing lists, but calls complete() only if completion_done() is true, i.e. if the completion is already done, which never happens while someone waits. disarm_all_kprobes() and kprobe_trace_self_tests_init() wait the same way. Calling complete() unconditionally would not be enough: the waiter drops kprobe_mutex while it sleeps, and nothing else serializes the sysctl handler against the debugfs "enabled" file. A second flusher that still finds the lists non-empty, e.g. because a disabled probe is queued for unoptimizing, reinitializes the completion under the first: sysctl write debugfs "enabled" write unoptimize_all_kprobes() wait_for_kprobe_optimizer_locked() init_completion(c) mutex_unlock(&kprobe_mutex) wait_for_completion(c) disarm_all_kprobes() wait_for_kprobe_optimizer_locked() init_completion(c) // c->wait is reset, the first // waiter is off the queue mutex_unlock(&kprobe_mutex) wait_for_completion(c) kprobe_optimizer() complete(c) // wakes the debugfs writer only where c is &optimizer_completion. Lining up the two writes during an optimizer pass loses the sysctl writer this way. Replace the completion with a counter of optimizer passes, bumped at the end of each pass and signalled with wake_up_var_locked(), both under kprobe_mutex. A flusher samples the count and waits with wait_var_event_mutex(), which drops kprobe_mutex only while sleeping, so a new count means a whole pass ran in the meantime. Nothing is reinitialized, so several flushers can sleep in the wait at once. Link: https://lore.kernel.org/all/20260924092142.199198-1-parri.andrea@gmail.com/ Fixes: 73c12f209462 ("kprobes: Use dedicated kthread for kprobe optimizer") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Andrea Parri Signed-off-by: Masami Hiramatsu (Google) commit 94cf5971b1d04c6382437387c4dc3836cc7a1437 Author: Fan Wu Date: Tue Sep 15 09:51:03 2026 +0000 drm/vc4: drain the hangcheck timer and works on V3D unbind 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 commit 76d8e697242e7e4e30dd08eff7c278728f9dd8e2 Author: Drif Abdelmalek Mohamed Said Date: Fri Sep 18 23:42:04 2026 +0100 dcache: unpoison the inline name buffer in __d_alloc() syzbot reported: BUG: KMSAN: uninit-value in dentry_string_cmp fs/dcache.c:291 [inline] BUG: KMSAN: uninit-value in dentry_cmp fs/dcache.c:322 [inline] BUG: KMSAN: uninit-value in __d_lookup_rcu+0x37d/0x5e0 fs/dcache.c:2522 dentry_string_cmp fs/dcache.c:291 [inline] dentry_cmp fs/dcache.c:322 [inline] __d_lookup_rcu+0x37d/0x5e0 fs/dcache.c:2522 lookup_fast+0x194/0xa40 fs/namei.c:1854 lookup_fast_for_open fs/namei.c:4545 [inline] open_last_lookups fs/namei.c:4579 [inline] path_openat+0x9ef/0x6540 fs/namei.c:4856 do_file_open+0x2aa/0x680 fs/namei.c:4888 do_sys_openat2+0x17c/0x390 fs/open.c:1395 do_sys_open fs/open.c:1401 [inline] __do_sys_openat fs/open.c:1417 [inline] __se_sys_openat fs/open.c:1412 [inline] __x64_sys_openat+0x240/0x300 fs/open.c:1412 x64_sys_call+0x2445/0x3ea0 arch/x86/include/generated/asm/syscalls_64.h:258 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15d/0x3c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: copy_name fs/dcache.c:3031 [inline] __d_move+0xd29/0x21f0 fs/dcache.c:3099 d_move+0x71/0xf0 fs/dcache.c:3147 vfs_rename+0x2619/0x2770 fs/namei.c:6085 filename_renameat2+0xa59/0x1230 fs/namei.c:6188 __do_sys_rename fs/namei.c:6232 [inline] __se_sys_rename+0xc5/0x5c0 fs/namei.c:6228 __x64_sys_rename+0x78/0xb0 fs/namei.c:6228 x64_sys_call+0x329/0x3ea0 arch/x86/include/generated/asm/syscalls_64.h:83 do_syscall_x64 arch/x86/entry/syscall_64.c:63 do_syscall_64+0x15d/0x3c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4617 [inline] slab_alloc_node mm/slub.c:4939 [inline] kmem_cache_alloc_lru_noprof+0x376/0x1230 mm/s __d_alloc+0x52/0x9f0 fs/dcache.c:1902 d_alloc+0x57/0x300 fs/dcache.c:1981 lookup_one_qstr_excl+0x19d/0x7a0 fs/namei.c:1806 __start_renaming+0x341/0x850 fs/namei.c:3888 filename_renameat2+0x625/0x1230 fs/namei.c:6163 __do_sys_rename fs/namei.c:6232 [inline] __se_sys_rename+0xc5/0x5c0 fs/namei.c:6228 __x64_sys_rename+0x78/0xb0 fs/namei.c:6228 x64_sys_call+0x329/0x3ea0 arch/x86/include/generated/asm/syscalls_64.h:83 do_syscall_x64 arch/x86/entry/syscall_64.c:63 do_syscall_64+0x15d/0x3c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The race is between a concurrent open() and rename() of the same path. __d_alloc() only stores the name itself and its terminating NUL, so the rest of the inline buffer (d_shortname, DNAME_INLINE_LEN bytes) is left uninitialized. copy_name(), called from rename(), copies that buffer as a whole, so the uninitialized tail is propagated into the dentry that is being moved. Meanwhile __d_lookup_rcu(), called from open(), is an optimistic lockless lookup: it checks d_name.hash_len first and leaves the seqcount retry to its caller, so it can end up comparing against a dentry whose name a rename is rewriting in place, using a stale (longer) length. The comparison then runs past the terminating NUL and reads bytes of the uninitialized tail, which KMSAN reports. The read is harmless by design: it stays inside the buffer, the name is still NUL-terminated, and the result is thrown away by the seqcount retry. It is not specific to KMSAN either - with CONFIG_DCACHE_WORD_ACCESS enabled the very same bytes are read by read_word_at_a_time(), which is __no_sanitize_or_inline and therefore invisible to KMSAN. KMSAN builds only see the instrumented byte-at-a-time dentry_string_cmp() because CONFIG_DCACHE_WORD_ACCESS is disabled when KMSAN is enabled on x86: commit 7cf8f44a5a1c ("x86: fs: kmsan: disable CONFIG_DCACHE_WORD_ACCESS") Zeroing the inline buffer would hide the report, but it would add a memset() to a hot allocation path just to initialize bytes that are never used as part of a name. Instead, tell KMSAN the inline buffer is initialized: kmsan_unpoison_memory() compiles to nothing unless CONFIG_KMSAN is set, and doing it at allocation time is enough for every dentry, because copy_name() and swap_names() copy the whole buffer and thus propagate its shadow. Reported-by: syzbot+7ff3adde89dd795ad4c4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7ff3adde89dd795ad4c4 Signed-off-by: Drif Abdelmalek Mohamed Said Changes in v3: - Annotate for KMSAN instead of zeroing, as suggested in review: the read is harmless, so unpoison the inline buffer in __d_alloc() with kmsan_unpoison_memory() (a no-op unless CONFIG_KMSAN) rather than adding a memset() to the dentry allocation path. - Document why only KMSAN builds report this at all: with CONFIG_DCACHE_WORD_ACCESS the same read goes through read_word_at_a_time(), which KMSAN does not instrument. - Rewrite the commit message; the previous one had several truncated lines. Link: https://patch.msgid.link/20260918224204.3056-1-drifabdelmalekmohamedsaid@gmail.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit ae146bc1abdeb4607abf2975b858c053024e8ac1 Author: Amir Goldstein Date: Mon Sep 21 12:40:13 2026 +0200 ovl: fix UAF in ovl_do_mkdir() debug print ovl_do_mkdir() prints the input dentry with %pd after vfs_mkdir(). Since commit fe497f0759e0 ("VFS: change vfs_mkdir() to unlock on failure."), vfs_mkdir() calls end_creating() on the input dentry on failure and may replace it on success, so the post-call %pd can use-after-free the dentry when CONFIG_OVERLAY_FS_DEBUG is enabled. Print the dentry before the call and only the result afterward. Reported-by: syzbot+ced26b784bf977d223dd@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ced26b784bf977d223dd Fixes: fe497f0759e0 ("VFS: change vfs_mkdir() to unlock on failure.") Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/20260921104013.40475-1-amir73il@gmail.com Signed-off-by: Christian Brauner (Amutable) commit 5dad87615c9861cfa366ca984b52f581e861df20 Author: Johan Hovold Date: Fri Sep 25 11:42:22 2026 +0200 tty: add break_wait kernel-doc Add the missing kernel-doc description for the new break_wait field in struct tty_struct. Fixes: 845a2737e0f5 ("tty: abort break signalling on hangup") Reported-by: Randy Dunlap Link: https://lore.kernel.org/20d75a7a-2e7a-484f-a267-c21db82dd922@infradead.org Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260925094222.18303-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 113dcdfadf30ea11fbbdfcd4f6ea87687655cc5b Author: Matthias Goergens Date: Fri Sep 25 13:23:29 2026 +0800 MAINTAINERS: name the libata/linux for-next branch The T: entry for LIBATA SUBSYSTEM (Serial and Parallel ATA drivers) names libata/linux without a branch. The repository's HEAD pointer points to branch master, which has no active development. Active development is on the for-next branch. Name the branch so the entry identifies where development happens. Documentation/process/submitting-patches.rst sends contributors to the T: entry to find the tree to prepare patches against, so a branch-less entry whose HEAD is already in mainline points them to the wrong branch. Reviewed-by: Damien Le Moal Signed-off-by: Matthias Goergens Link: https://lore.kernel.org/r/20260925052329.2683619-1-matthias.goergens@gmail.com Signed-off-by: Niklas Cassel commit 0f50dab8b4265e42e8719c2998c908a9d79a589e Merge: c5d1690ff144fc 15814c01ac5764 Author: Dave Airlie Date: Fri Sep 25 16:54:43 2026 +1000 Merge tag 'amd-drm-fixes-7.3-2026-09-24' of https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.3-2026-09-24: amdgpu: - Display ref count fix - Userq fixes - VCN 4, 5 reset fixes - Fixes for various error paths - Stack frame size fixes for various combinations of compilers and configs amdkfd: - Possible UAF fix Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patch.msgid.link/20260924172938.634777-1-alexander.deucher@amd.com commit 3f35b678a1d6b4c2dc773ad73623b1515cfc5bc5 Author: Benjamin Tissoires Date: Tue Sep 15 17:46:58 2026 +0200 selftest/hid: add test for negative return codes for hid_bpf_hw_request If the transport driver returns an error, we should ensure we actually get the error, not a success value. Acked-by: Jiri Kosina Signed-off-by: Benjamin Tissoires commit 3afefbfe55c2a8a0c4bdf6f4cc1f773da120027c Author: Benjamin Tissoires Date: Tue Sep 15 17:46:57 2026 +0200 HID: bpf: cast size to ssize_t when checking hid_bpf_hw_request As reported by Sashiko: If a transport driver encounters a hardware error and returns a negative error code such as -EPIPE, ret is implicitly promoted to size_t when compared against size. This causes the negative error code to evaluate as a large positive number, making the (ret > size) condition true. This silently converts the hardware error into a success return value and copies the unmodified buffer back, which could leave BPF programs operating on uninitialized or stale data. Fix this by casting size into ssize_t to return the actual negative error code. Link: https://lore.kernel.org/all/20260904130354.A79471F00A3D@smtp.kernel.org/ Fixes: 2b658c1c442e ("HID: bpf: prevent buffer overflow in hid_hw_request") Cc: stable@vger.kernel.org Acked-by: Jiri Kosina Signed-off-by: Benjamin Tissoires commit c5d1690ff144fce4b7cebe877d2ef1d1b5eb6aa2 Merge: fd0ba310f9ab6f cc319238e3f666 Author: Dave Airlie Date: Fri Sep 25 16:50:02 2026 +1000 Merge tag 'drm-xe-fixes-2026-09-24' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Fixes in: - CRI throttle reasons report (Sk) - TLB invalidation at wedge (Shuicheng) - SVM eviction and VM close (Brost) - Display corruption on LNL on Xen PV (Szymon) - W/a fix and addition (Tilak) Signed-off-by: Dave Airlie From: Rodrigo Vivi Link: https://patch.msgid.link/arUoUf9LpsJpJouN@intel.com commit f050c3e61d2a1aaece3170d459e4ce5fa2486c12 Author: Vineet Gupta Date: Wed Sep 23 15:01:38 2026 -0700 ARC: arch_cmpxchg_relaxed to use size of pointed type not pointer Bradley spotted this snafu when working on two-byte cmpxchg emulation. He originally folded this fix into his series but the fix itself uncovered a pre-existing issue, missing arch_atomic64_cmpxchg_relaxed which just needed to be wired up. Fixes: e188f3330a13 ("ARC: cmpxchg/xchg: rewrite as macros to make type safe") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609240539.AkulvjVe-lkp@intel.com/ Suggested-by: Bradley Morgan Signed-off-by: Vineet Gupta commit ad139384ecddb6f3e7e3c3c12765aafae0e39670 Author: Alexei Starovoitov Date: Thu Sep 24 18:23:53 2026 +0000 bpf: Fix overflow of jump offset in constant blinding bpf_jit_blind_insn() rewrites 'if rX op imm goto off' into: AX = imm ^ rnd AX ^= rnd if rX op AX goto off and subtracts 2 from off when the jump is backward. off is s16, so -32767 and -32768 wrap and the jump goes 32767 insns forward, past the end of the prog. The jump is inside the patch, hence bpf_adj_branches() doesn't check it. The kernel crashes when such prog runs with bpf_jit_harden=2. Return -ERANGE in such case. bpf_jit_blind_constants() fails the same way when blinding of other insns moves a jump out of range. Fixes: 4f3446bb809f ("bpf: add generic constant blinding for use in jits") Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20260924182353.277516-1-alexei.starovoitov@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit 165768bb70265b5c38cf0b73fafd75be235f8b14 Merge: ee9c669f9bf5fd c6b51091cafff9 Author: Linus Torvalds Date: Thu Sep 24 17:09:56 2026 -0700 Merge tag 'firewire-fixes-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire fix from Takashi Sakamoto: "Fix a race in the cdev layer that can cause a fw_iso_resource_auto object to transition back to a previous state. This can happen when a file descriptor is closed while the work item for the object is running. The race can leak several memory objects, including client object itself" * tag 'firewire-fixes-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: cdev: fix back-transition for iso_resource_auto client resource commit fd0ba310f9ab6faa0059d9649564ac97e67ad137 Merge: 93f51579e7df24 d2da6696e0c4e6 Author: Dave Airlie Date: Fri Sep 25 09:47:45 2026 +1000 Merge tag 'drm-intel-fixes-2026-09-24' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes drm/i915 fixes for v7.3-rc5: - Fix incorrect RCU teardown order leading to endless loop - Fix DP MST TU and FEC handling for disconnected streams - Fix selective fetch disable, again - Fix export namespace for kunit helpers - Workaround eDP flicker on a specific laptop model Signed-off-by: Dave Airlie From: Jani Nikula Link: https://patch.msgid.link/9b8ff50ad5c3ff9ca120207b1e7aa95d5a16423f@intel.com commit ee9c669f9bf5fd2c24206746ded9382fe810df89 Merge: e8dfd03a1c51c4 4409a85735cdca Author: Linus Torvalds Date: Thu Sep 24 15:04:11 2026 -0700 Merge tag 'sched_ext-for-7.3-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext Pull sched_ext fixes from Tejun Heo: - A task reenqueued while its dispatch was still completing had its queued state clobbered by the dispatcher, dropping every later dispatch of the task. Wait for the in-flight dispatch to settle first - A wakeup activation on another CPU marked the destination runqueue as mid-wakeup, stranding a pending local reenqueue. If the scheduler was unloaded first, the stale request pointed into freed memory that the next scheduler dereferenced - ops.dequeue() ran with the source dispatch queue's lock held, so a scheduler iterating that queue from the callback deadlocked the CPU - Schedulers with their own CPU ID mapping had no way to learn a task's initial CPU mask and rebuilt it themselves, which went wrong across sub-scheduler enable and re-home. Pass it to ops.enable() - A bypass dispatch event counter missed the dispatches made by the end-of-dispatch fallback and under-reported - Selftests for the dequeue locking and initial mask changes * tag 'sched_ext-for-7.3-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: Count SCX_EV_SUB_BYPASS_DISPATCH in the dispatch fallback selftests/sched_ext: Check the cmask cid-form ops.enable() receives sched_ext: Pass the initial cmask to cid-form ops.enable() selftests/sched_ext: Test that ops.dequeue() can iterate the consumed DSQ sched_ext: Don't run ops.dequeue() with a DSQ lock held sched_ext: Derive SCX_RQ_IN_WAKEUP from the core enqueue flags sched_ext: Wait for SCX_OPSS_DISPATCHING before reenqueueing a task commit e8dfd03a1c51c4e84fbf2e5ef5cd7d33cc8b7578 Merge: f2c53ea949c504 1765a153d985c2 Author: Linus Torvalds Date: Thu Sep 24 14:26:12 2026 -0700 Merge tag 'cgroup-for-7.3-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: - With local event accounting, a fork rejected by the pids controller updated pids.events without notifying its pollers - A cgroup selftest failed to compile with fortification enabled because an O_TMPFILE open lacked its mode argument * tag 'cgroup-for-7.3-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup/pids: Restore pids.events notifications in local mode selftests: cgroup: give the O_TMPFILE open in get_temp_fd() a mode commit cb97bf3d4f91453b881acaf8e9f0cc47bb40b604 Author: Viken Dadhaniya Date: Mon Sep 21 17:17:01 2026 +0530 i2c: qcom-geni: Fix hardcoded clock index in SE_GENI_CLK_SEL qcom_geni_i2c_conf() writes a hardcoded 0 to SE_GENI_CLK_SEL, which selects an index from the hardware clock performance table. This always picks the first table entry regardless of the actual source clock configuration. On platforms where the matching entry is not at index 0, the wrong source clock divider is active and the I2C bus runs at an incorrect frequency. Use geni_se_clk_freq_match() in geni_i2c_clk_map_idx() to find the performance table index for the source clock (32 MHz or 19.2 MHz). Store the resolved index in a new clk_idx field in geni_i2c_dev and write it to SE_GENI_CLK_SEL instead of the hardcoded 0. Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Signed-off-by: Viken Dadhaniya Cc: # v4.19+ Reviewed-by: Mukesh Kumar Savaliya Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260921-i2c-fix-se-clk-conf-v2-1-8b5537ceff2d@oss.qualcomm.com commit 11536ee3d3e0b1bd35b6f3f8df55a6053eb0c71d Author: Eric Dumazet Date: Wed Sep 23 08:32:03 2026 +0000 MAINTAINERS: update Eric Dumazet's email address My @google.com address is going away soon, let's switch to @kernel.org. Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260923083203.383923-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit f2c53ea949c5048f96b3dbb5a5ee7131ce4ff2de Merge: 415f2044228cc8 fc6d80eb504458 Author: Linus Torvalds Date: Thu Sep 24 11:45:33 2026 -0700 Merge tag 'net-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from Bluetooth, NFC and Netfilter. Every week in this release is record-setting for number of posted patches. It doesn't seem like we're creating any regressions with all these fixes, three 'Fixes' tags here point to 7.2 commits but none are true regression fixes. We're trying to keep the count down, nonetheless. Previous releases - regressions: - net: don't require the hwtstamp NDOs when a PHY provides timestamping - ipv6: fix dst leak for uncached routes - vrf: stop corrupting skb->csum when capturing CHECKSUM_COMPLETE packets Previous releases - always broken: - packet: use ubuf_info completion for TX_RING packets - arp: terminate device name before lookup - ipv6: do not let ipv6_find_hdr() return an offset past the packet end - udp: remove a disconnected socket from the 4-tuple hash table - sctp: discard the rest of the packet on a stale-cookie error - eth: mlx5: Bridge, fix remaining switchdev ownership gaps on merged eswitch" [ And lots of other random network driver fixes ] * tag 'net-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (189 commits) tcp: prevent collapsing skbs across boundary in rtx queue vlan: ensure sufficient headroom in vlan_dev_hard_header() net/sched: sch_teql: fix shadowed err in __teql_resolve() bridge: check llc_mac_hdr_init() return value in br_send_bpdu() llc: fix skb UAF and leaks on llc_mac_hdr_init() failure llc: reserve device headroom for allocated frames gve: DQO: reject TSO packets with an out of range MSS gve: fix TX drop when GSO MSS is too small for hw gve: DQO: fix header length used by gve_can_send_tso() for UDP GSO net: flush skb_defer_nodes in dev_cpu_dead() net: ethernet: stmmac: dwmac-rk: fix bulk clock leak when the PHY clock fails af_packet: fix integer overflow in prb_calc_retire_blk_tmo() tipc: Fix a data race on mon->peer_cnt in mon_timeout() net: phy: intel-xway: workaround 100BASE-TX Link-Up issue net/smc: fix UAF on lgr list traversal in smcr_port_err() net/rds: size a connection's path set by the transport it ends up with nfp: hold IPsec RX state under the XArray lock net: ena: fix MMIO read buffer leak on probe failure net: ena: fix PHC cleanup on probe failure net/sched: act_ct: fix helper UAF due to extensions realloc ... commit fc6d80eb504458d6416b75a94188b268c95c6533 Author: Willem de Bruijn Date: Thu Sep 24 11:44:12 2026 -0400 tcp: prevent collapsing skbs across boundary in rtx queue tcp_write_collapse_fence() sets TCP_SKB_CB(skb)->eor = 1 on tcp_write_queue_tail(sk) to prevent skbs queued after a switch to device encryption from being collapsed into earlier skbs. The fence is a no-op if all earlier data has already been transmitted when the switch happens: sk->sk_write_queue is empty. The not yet acknowledged earlier skbs wait in sk->tcp_rtx_queue with eor 0. On a subsequent retransmit or SACK shift, tcp_retrans_try_collapse() or tcp_shift_skb_data() can then merge an skb queued after the switch into one queued before it. Both users of the fence are affected: - psp: devices only encrypt skbs with skb->decrypted set. The merged skb keeps decrypted = 0 from the earlier skb, so merged data sent after psp_sock_assoc_set_tx() is retransmitted in cleartext. - tls device offload: the merged skb straddles the start marker set in tls_set_device_offload(). The software fallback (fill_sg_in() returns -EINVAL) and the mlx5, nfp and funeth drivers cannot handle such an skb and drop it. Every retransmit rebuilds the same skb, so the connection stalls. Fix this in two places, for defense in depth: 1. Fall back to tcp_rtx_queue_tail(sk) in tcp_write_collapse_fence() when tcp_write_queue_tail(sk) is NULL. 2. Check !skb_cmp_decrypted(to, from) in tcp_skb_can_collapse(), as tcp_skb_can_collapse_rx() does on receive. skb_shift(), which both collapse paths call, already has a DEBUG_NET_WARN_ON_ONCE() for this condition. Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Willem de Bruijn Reviewed-by: Eric Dumazet Reviewed-by: Daniel Zahka Link: https://patch.msgid.link/20260924154427.953800-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski commit 1078a38344a852eefafcc61c42dcc333b53c7478 Merge: 72b5b9a28b996e cd5dd68267c423 Author: Jakub Kicinski Date: Thu Sep 24 11:01:03 2026 -0700 Merge branch 'vlan-ensure-sufficient-headroom-in-vlan_dev_hard_header' Eric Dumazet says: ==================== vlan: ensure sufficient headroom in vlan_dev_hard_header() Callers that only reserve ETH_HLEN or less, or skbs allocated before dynamic device/headroom changes (such as toggling VLAN_FLAG_REORDER_HDR or bonding/team switching slaves), can reach vlan_dev_hard_header() with insufficient headroom and trigger skb_under_panic(). When vlan_dev_hard_header() returns -ENOMEM upon skb_cow_head() failure, a few callers of dev_hard_header() / llc_mac_hdr_init() had pre-existing error-handling bugs: ==================== Link: https://patch.msgid.link/20260924082951.1599377-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit cd5dd68267c4238795fadaf02b3575ca3f8a6500 Author: Eric Dumazet Date: Thu Sep 24 08:29:51 2026 +0000 vlan: ensure sufficient headroom in vlan_dev_hard_header() Callers that only reserve ETH_HLEN or less (such as llc_alloc_frame()), or skbs allocated before dynamic device/headroom changes (e.g. toggling VLAN_FLAG_REORDER_HDR or bonding/team switching slaves), can reach vlan_dev_hard_header() with insufficient headroom and trigger skb_under_panic(). Use skb_cow_head() in vlan_dev_hard_header() when VLAN_FLAG_REORDER_HDR is not set to ensure sufficient headroom for the VLAN header(s) and the underlying device hard header. Use READ_ONCE() to read dev->hard_header_len and dev->needed_headroom as they can be updated concurrently under RTNL (e.g. in vlan_transfer_features()) while vlan_dev_hard_header() runs locklessly on the transmit path. Also avoid LL_RESERVED_SPACE(dev) here so that the extra HH_DATA_MOD alignment padding does not trigger unnecessary pskb_expand_head() reallocations on inner stacked VLAN devices after the outer VLAN header has been pushed. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Zixuan Chai Closes: https://lore.kernel.org/netdev/cover.1789987105.git.petalzu987@gmail.com/ Link: https://lore.kernel.org/netdev/179022851638.2160803.1808206741379444999@kernel.org/ Cc: Hangbin Liu Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260924082951.1599377-5-edumazet@google.com Signed-off-by: Jakub Kicinski commit 907b978e82cb4c1c245fc2985bb27c5d5c88c8f6 Author: Eric Dumazet Date: Thu Sep 24 08:29:50 2026 +0000 net/sched: sch_teql: fix shadowed err in __teql_resolve() __teql_resolve() declares an inner 'int err;' inside the 'if (neigh_event_send(n, skb_res) == 0)' block, shadowing the outer 'int err = 0;'. As a result, a negative return from dev_hard_header() is written to the inner variable and __teql_resolve() still returns 0. Remove the shadowed variable and set the outer err to -EINVAL when dev_hard_header() returns a negative error. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Closes: https://lore.kernel.org/netdev/179022851638.2160803.1808206741379444999@kernel.org/ Cc: Jamal Hadi Salim Cc: Jiri Pirko Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260924082951.1599377-4-edumazet@google.com Signed-off-by: Jakub Kicinski commit ac704ff08e511c87643799c385f55ecd69b85e03 Author: Eric Dumazet Date: Thu Sep 24 08:29:49 2026 +0000 bridge: check llc_mac_hdr_init() return value in br_send_bpdu() If llc_mac_hdr_init() fails (for instance if the port device type does not support LLC or dev_hard_header() fails), br_send_bpdu() should drop the skb instead of resetting the mac header to the LLC payload and transmitting a malformed frame. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Closes: https://lore.kernel.org/netdev/179022851638.2160803.1808206741379444999@kernel.org/ Cc: Nikolay Aleksandrov Cc: Ido Schimmel Cc: bridge@lists.linux.dev Signed-off-by: Eric Dumazet Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260924082951.1599377-3-edumazet@google.com Signed-off-by: Jakub Kicinski commit 72f9dd522f8d6c5a00be9695c7bb74631eb5069e Author: Eric Dumazet Date: Thu Sep 24 08:29:48 2026 +0000 llc: fix skb UAF and leaks on llc_mac_hdr_init() failure In llc_conn_ac_resend_i_xxx_x_set_0_or_send_rr(), if llc_mac_hdr_init() fails, kfree_skb(skb) is called instead of kfree_skb(nskb). This leaks the newly allocated nskb, reads from the freed skb via LLC_I_GET_NR(pdu), and double-frees skb when llc_conn_state_process() drops its reference. In llc_sap_action_send_xid_r() and llc_sap_action_send_test_r(), nskb is leaked if llc_mac_hdr_init() returns an error. Free nskb in all three error paths. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Closes: https://lore.kernel.org/netdev/179022851638.2160803.1808206741379444999@kernel.org/ Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260924082951.1599377-2-edumazet@google.com Signed-off-by: Jakub Kicinski commit 72b5b9a28b996e09b8b5b944370c79851bb68f52 Author: Zixuan Chai Date: Thu Sep 24 09:26:05 2026 +0800 llc: reserve device headroom for allocated frames llc_alloc_frame() reserves link-layer headroom using the device type. This is insufficient for stacked Ethernet devices such as VLAN devices, where vlan_dev_hard_header() pushes a VLAN header before the lower device's Ethernet header. An LLC response on such a device can therefore underflow skb headroom in eth_header(). Use LL_RESERVED_SPACE() to account for the device's actual required headroom while preserving the existing LLC device-type check. Fixes: bf9ae5386bca ("llc: use dev_hard_header") Cc: stable@vger.kernel.org Reported-by: VEGA Signed-off-by: Zixuan Chai Signed-off-by: Ren Wei Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260924012613.2533934-1-weir@nebusec.ai Signed-off-by: Jakub Kicinski commit 488089055b61be8f7e97817d4608844f0fba2648 Merge: 83769c23fb1879 296c83b5ccc808 Author: Jakub Kicinski Date: Thu Sep 24 10:57:01 2026 -0700 Merge branch 'gve-dqo-fix-handling-of-out-of-range-tso-mss' Eric Dumazet says: ==================== gve: DQO: fix handling of out of range TSO MSS The DQO TX path assumes that the MSS of a TSO packet is within the range supported by the device, [88, 9728]. This holds for locally generated traffic, but not for packets coming from a tap or from a packet socket: virtio_net_hdr_to_skb() takes gso_size from user space and only enforces a minimum, layer 2 forwarding does not check the MTU of GSO packets, and gso_features_check() bounds skb->len and gso_segs but never gso_size. Patch 1, from Eddie Phillips, deals with the lower bound. It moves the existing test out of gve_prep_tso() into gve_features_check_dqo(), so that these packets are segmented in software instead of being dropped. Patch 2 deals with the upper bound, which is currently not checked at all. gve_tx_fill_tso_ctx_desc() stores gso_size into a 14 bits wide field, so that an MSS of 16384 silently becomes zero. Falling back to software segmentation is not an option here, because skb_segment() splits at gso_size regardless of the MTU, and would only replace an invalid TSO packet by non TSO packets larger than the 9728 bytes the device supports. These packets are dropped instead. As noted in patch 2, oversized non TSO packets can still reach the device whenever the stack segments in software. This is not specific to gve and is better fixed in the core, so a patch for __is_skb_forwardable() will be sent separately for net-next. ==================== Link: https://patch.msgid.link/20260924004252.1196328-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit 296c83b5ccc808c080865eb20fd7a477b0355bb7 Author: Eric Dumazet Date: Thu Sep 24 00:42:52 2026 +0000 gve: DQO: reject TSO packets with an out of range MSS gve_prep_tso() notes that the device requires the MSS to be <= 9728, but does not enforce it, assuming the 9K MTU enforced by the hypervisor and the 64KB limit on TSO sizes are enough. This does not hold for packets that were not generated locally. A guest behind a tap, or any packet socket user, can provide an arbitrary gso_size in virtio_net_hdr. Layer 2 forwarding does not check the MTU for GSO packets (is_skb_forwardable()), and gso_features_check() only bounds skb->len and gso_segs, never gso_size. Such a packet reaches gve_tx_fill_tso_ctx_desc(), which puts gso_size into the mss field of the TSO context descriptor. This field is 14 bits wide, so a gso_size of 16384 is silently turned into an MSS of zero. Drop these packets from gve_prep_tso(), and make sure that gve_features_check_dqo() leaves their GSO bits alone: skb_segment() splits at gso_size regardless of the MTU, so falling back to software segmentation would give the device non TSO packets bigger than the 9728 bytes it supports. Note that the device can still be given oversized non TSO packets when the stack segments in software for other reasons, for instance after TSO has been disabled with ethtool. This is a generic issue, because the MTU check is skipped for GSO packets in the forwarding path, and is addressed separately. Fixes: a57e5de476be ("gve: DQO: Add TX path") Signed-off-by: Eric Dumazet Reviewed-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260924004252.1196328-3-edumazet@google.com Signed-off-by: Jakub Kicinski commit 3b430ea6234087957b0d3cd181e3116722b59819 Author: Eddie Phillips Date: Thu Sep 24 00:42:51 2026 +0000 gve: fix TX drop when GSO MSS is too small for hw The device has a strict requirement that the minimum MSS (gso_size) for TSO/GSO packets must be at least 88 bytes. If a packet below this threshold is pushed to the hardware, it can cause hardware to silently drop the packet, leading to increased latency and retransmissions. Currently, this is validated too late in the transmit pipeline (gve_prep_tso), leading to silent drops. Fix this by moving the validation into the .ndo_features_check callback (gve_features_check_dqo). If we detect a GSO packet with a gso_size smaller than GVE_TX_MIN_TSO_MSS_DQO, we clear the GSO feature flags for this packet. Fixes: a57e5de476be ("gve: DQO: Add TX path") Signed-off-by: Eddie Phillips Signed-off-by: Eric Dumazet Reviewed-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260924004252.1196328-2-edumazet@google.com Signed-off-by: Jakub Kicinski commit 415f2044228cc8b948dc04e079aaa86a4d1aa1d3 Merge: 5fc5768c7ca928 e7e0a54300a896 Author: Linus Torvalds Date: Thu Sep 24 10:53:59 2026 -0700 Merge tag 'landlock-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux Pull Landlock fixes from Mickaël Salaün: "This mainly fixes the Landlock tracepoint support merged this cycle so that denial and rule events report the intended policy context, whether through tracefs or BTF-visible callbacks. The size of this all is mainly from propagating the corrected contract through event definitions and producers, adding new tests for the reported context, and updating the documentation. Also improve annotation and fix a GCC 16 build warning" * tag 'landlock-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux: landlock: Widen ruleset versions to 64 bits landlock: Add counted_by in landlock_domain landlock: Fix tracepoint contract documentation selftests/landlock: Test network denial context selftests/landlock: Test filesystem denial blockers landlock: Report the effective signal number landlock: Report the actual ptrace tracer landlock: Fix network denial trace context landlock: Fix rule tracepoint context landlock: Fix filesystem denial blocker reporting landlock: Fix tracepoint fixed-width type names landlock: Work around gcc-16 -Wuninitialized warning commit 83769c23fb1879edc916a526ba424285033baf2d Author: Eric Dumazet Date: Wed Sep 23 14:59:42 2026 +0000 gve: DQO: fix header length used by gve_can_send_tso() for UDP GSO gve_can_send_tso() computes how many buffers each segment of a GSO packet would span, and for this it needs the length of the headers that the device replicates in front of every segment. It unconditionally uses skb_tcp_all_headers(), which reads the doff field of the TCP header. SKB_GSO_UDP_L4 packets have no TCP header: tcp_hdrlen() then reads one byte of the UDP payload, and header_len can be anything in [0, 60] instead of the transport offset plus the eight bytes of the UDP header that gve_prep_tso() programs into the TSO context descriptor. A wrong header length shifts all the segment boundaries computed in the loop, so the number of buffers per segment can be over or under estimated. In the first case, GSO is needlessly disabled for this packet by gve_features_check_dqo() and the stack has to segment it. In the second case, the driver hands the device a packet whose segments span more than GVE_TX_MAX_DATA_DESCS buffers. Use the UDP header length for SKB_GSO_UDP_L4 packets, matching what gve_prep_tso() does. Fixes: 014c607f86ab ("gve: add support for UDP GSO for DQO format") Closes: https://lore.kernel.org/netdev/CANn89i+MS4L60sFQ49=-f-mibeveUfcrpVkD5X+Qy6SOnEpd6w@mail.gmail.com/ Signed-off-by: Eric Dumazet Cc: Ankit Garg Cc: Harshitha Ramamurthy Cc: Joshua Washington Cc: Willem de Bruijn Reviewed-by: Ankit Garg Reviewed-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260923145942.731365-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit 06e3f54e8b22040ada01a28343badf1990b4dd7d Author: Eric Dumazet Date: Wed Sep 23 13:03:18 2026 +0000 net: flush skb_defer_nodes in dev_cpu_dead() When a CPU goes offline, dev_cpu_dead() drains its softnet queues (completion_queue, output_queue, poll_list, process_queue, and input_pkt_queue), but leaves net_hotdata.skb_defer_nodes untouched. If oldcpu goes offline while holding pending skbs in its skb_defer_nodes lists (e.g. below the sysctl_skb_defer_max >> 1 IPI threshold, or if the IPI races with CPU teardown), those skbs remain stranded until oldcpu is brought back online. If any of these skbs hold page_pool fragments, page_pool_destroy() will stall indefinitely waiting for inflight pages to be returned when a netdev or driver is torn down while oldcpu is offline. Additionally, if smp_call_function_single_async() fails in kick_defer_list_purge() because the target CPU went offline, reset defer_ipi_scheduled to 0 so future IPI kicks are not blocked when the CPU comes back online. Also, if oldcpu was the last online CPU on its NUMA node, drain that node's slot across all CPUs so no skbs deferred from that node remain stranded on idle remote CPUs (or if the node itself is subsequently offlined). Finally, in skb_attempt_defer_free(), re-check cpu_online(cpu) and whether the caller migrated CPUs after llist_add(), flushing the node list if so, to close the preemption TOCTOU race against CPU/node teardown. Fixes: 68822bdf76f1 ("net: generalize skb freeing deferral to per-cpu lists") Fixes: 5628f3fe3b16 ("net: add NUMA awareness to skb_attempt_defer_free()") Closes: https://lore.kernel.org/netdev/20260916003430.3612956-1-kris.pan@intel.com/ Signed-off-by: Eric Dumazet Cc: Kris Pan Link: https://patch.msgid.link/20260923130318.607255-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit 8db67bb6a1fffa4df68fbbc22e39943aeeff9178 Author: Coia Prant Date: Wed Sep 23 20:37:13 2026 +0800 net: ethernet: stmmac: dwmac-rk: fix bulk clock leak when the PHY clock fails gmac_clk_enable() enables the bulk clocks first and then the optional PHY clock. If clk_prepare_enable() on the PHY clock fails, the function returns without rolling back the bulk clocks, and bsp_priv->clk_enabled stays false, so the later gmac_clk_enable(bsp_priv, false) becomes a no-op and the bulk clock references are leaked. Add the missing clk_bulk_disable_unprepare() on that failure path. Fixes: ea449f7fa0bf ("net: ethernet: stmmac: dwmac-rk: rework optional clock handling") Reviewed-by: Maxime Chevallier Reviewed-by: Heiko Stuebner Acked-by: Lorenzo Bianconi Signed-off-by: Coia Prant Link: https://patch.msgid.link/20260923123713.3137146-1-coiaprant@gmail.com Signed-off-by: Jakub Kicinski commit 56d82862a0a243ac14ba11b6d7b57ddc2d064b95 Author: Dairui Zhang Date: Wed Sep 23 13:01:01 2026 +0800 af_packet: fix integer overflow in prb_calc_retire_blk_tmo() prb_calc_retire_blk_tmo() computes in 32-bit int arithmetic: mbits = (blk_size_in_bytes * 8) / (1024 * 1024); If I'm reading the validation right, tp_block_size is user controlled and packet_set_ring() only rejects values that are <= 0 as int or not page aligned, so a 256MiB block goes right through (and alloc_one_pg_vec_page() even has a vzalloc fallback for it). 0x10000000 * 8 wraps to INT_MIN, and on a NIC reporting 1 Gbps (div == 1) the function ends up returning -2047. The condition is actually (8 * size) mod 2^32 >= 2^31 && div == 1, so the trigger set is [256,512), [768,1024), [1280,1536) and [1792,2048) MiB. Other sizes wrap to non-negative values and faster links divide the unsigned value back below 2^31, which is why this doesn't blow up for everyone. What makes it fatal is what happens next in init_prb_bdqc(): p1->interval_ktime = ms_to_ktime(prb_calc_retire_blk_tmo(...)); hrtimer_start(&p1->retire_blk_timer, p1->interval_ktime, HRTIMER_MODE_REL_SOFT); A negative relative timeout expires immediately. The callback unconditionally returns HRTIMER_RESTART, and hrtimer_forward() turns the negative interval into hrtimer_resolution: if (interval < hrtimer_resolution) interval = hrtimer_resolution; So the SOFT timer re-fires at the maximum rate forever, holding sk_receive_queue.lock each pass. One CPU spins in softirq until the socket is closed. Repeat with more rings and the machine is gone. The overflow itself is ancient - it was introduced together with TPACKET_V3 in f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation."). Its effect prior to f7460d2989fa ("net: af_packet: Use hrtimer to do the retire operation", v6.18) was not as clear-cut, though: the return value was stored into an unsigned short retire_blk_tov, so a negative result was truncated, and a 0-jiffy delay loop could be programmed as well. Neither is nearly as detrimental as the immediate maximum-rate spin the hrtimer conversion turned it into. (Unrelated to CVE-2019-20812 - that one was the ethtool failure path returning 0, which now returns DEFAULT_PRB_RETIRE_TOV.) Reproducer, needs CAP_NET_RAW (a --network host container has it by default) and a 1 Gbps NIC (QEMU e1000 works): int fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); bind(fd, ...); int v = TPACKET_V3; setsockopt(fd, SOL_PACKET, PACKET_VERSION, &v, sizeof(v)); struct tpacket_req3 req = { .tp_block_size = 0x10000000, .tp_block_nr = 1, .tp_frame_size = 2048, .tp_frame_nr = 0x10000000 / 2048, .tp_retire_blk_tov = 0, }; setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &req, sizeof(req)); Compute in 64 bits instead. The operands are already bounded by the existing validation, so nothing else changes. If you'd prefer a different fix, just say so and I'll respin. Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.") Cc: stable@vger.kernel.org Signed-off-by: Dairui Zhang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260923050101.1510064-1-zhangdairui@gmail.com Signed-off-by: Jakub Kicinski commit 8e1937fed6738460554ec123c64839e2445e7d53 Author: Ginger Li Date: Tue Sep 22 16:09:09 2026 +0800 tipc: Fix a data race on mon->peer_cnt in mon_timeout() mon_timeout() evaluates dom_size(mon->peer_cnt) before it takes mon->lock, while mon->peer_cnt is updated under that lock by tipc_mon_add_peer() and tipc_mon_remove_peer(). The value can therefore be stale, and the decision whether the local domain has to be recomputed can be based on an outdated member count. Read mon->peer_cnt inside the write_lock_bh(&mon->lock) protected region. Fixes: 35c55c9877f8 ("tipc: add neighbor monitoring framework") Signed-off-by: Ginger Li Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260922080909.21123-1-ginger.jzllee@gmail.com Signed-off-by: Jakub Kicinski commit b94773dc4df7026a6f29b2c65e96e88d29cdb576 Author: Alexander Sverdlin Date: Tue Sep 22 09:52:46 2026 +0200 net: phy: intel-xway: workaround 100BASE-TX Link-Up issue MaxLinear GSW12x/GSW14x Ethernet Switch Errata Sheet states: "An issue has been sporadically observed after device power-on on the first link-up attempt in 100BASE-TX mode resulting in either the link-up taking a long time, or failing to link-up altogether... Workaround: After power-on, enable Cable Diagnostic Mode for all ports and disable it..." Implement the proposed workaround unconditionally in the Intel XWAY driver (MaxLinear GSW1xx switches incorporate Intel XWAY PHYs) because the diagnostic bits have the same meaning even in older integral PHYs such as GPY111/PEF7071/PHY11G. So it's not clear how to distinguish the affected newer integrated PHYs, but the workaround should not hurt the older PHYs. Cc: stable@vger.kernel.org Fixes: 22335939ec90 ("net: dsa: add driver for MaxLinear GSW1xx switch family") Signed-off-by: Alexander Sverdlin Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260922075251.23386-1-alexander.sverdlin@siemens.com Signed-off-by: Jakub Kicinski commit 61cb282fe97b3b0ba32ca09417a693162bf4ae3f Author: Sidraya Jayagond Date: Tue Sep 22 09:31:49 2026 +0200 net/smc: fix UAF on lgr list traversal in smcr_port_err() smcr_port_err() traverses smc_lgr_list.list without holding smc_lgr_list.lock, allowing a concurrent smc_lgr_terminate_sched() to free an lgr while it is still being dereferenced. Hold smc_lgr_list.lock across the traversal. Update smc_ib_gid_check() to call smcr_port_err() after releasing the lock. Fixes: 541afa10c126 ("net/smc: add smcr_port_err() and smcr_link_down() processing") Reviewed-by: Mahanta Jambigi Signed-off-by: Sidraya Jayagond Reviewed-by: Dust Li Link: https://patch.msgid.link/20260922073149.474762-1-sidraya@linux.ibm.com Signed-off-by: Jakub Kicinski commit ba3d1f480c7a3fba963e7867ad6cc557c197acbc Author: Allison Henderson Date: Mon Sep 21 14:50:27 2026 -0700 net/rds: size a connection's path set by the transport it ends up with __rds_conn_create() computes npaths from the caller's transport before it decides whether a connection to one of the host's own addresses is to be handled by the loopback transport instead. That substitution is what an RDS/TCP socket sending to a local address gets, and after it the path init loop still runs for the TCP transport's RDS_MPATH_WORKERS paths and allocates an ordered workqueue for each, while rds_loop_conn_alloc() only ever provides transport data for path 0. rds_conn_destroy() sizes its teardown from c_trans, by then the loopback transport, so it visits path 0 only - and rds_conn_path_destroy() would skip the other paths anyway, since it returns before destroy_workqueue() for a path without transport data. kfree(c_path) then drops the last pointers to seven workqueues. That repeats for every such connection, on every netns teardown or module unload, and every distinct local destination address is a separate connection. Recompute npaths once the transport is final, so that creation and destruction agree on the set of paths. The c_path array stays sized for the caller's transport; the unused entries are freed with it. Fixes: 4716af3897e9 ("net/rds: Give each connection path its own workqueue") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260921215027.174657-1-achender@kernel.org Signed-off-by: Jakub Kicinski commit 1a983a4e14c635c40354be110cd9a1a5c94e01e6 Author: Sang-Hoon Choi Date: Tue Sep 22 03:15:59 2026 +0900 nfp: hold IPsec RX state under the XArray lock nfp_net_ipsec_rx() drops the XArray lock before taking a reference to the xfrm_state it found. The delete path can erase the entry and drop the last state reference in that interval. RX can then try to increment a zero refcount after the state has been queued for destruction. The driver queues firmware invalidation asynchronously; the delete path does not wait for the command to complete or drain pending RX processing. The XFRM garbage collector waits for an RCU grace period before freeing the state. That delays reclamation but does not make acquiring a reference from zero valid. Take the xfrm_state reference before releasing the XArray lock so xa_erase() cannot run between lookup and reference acquisition. Fixes: 57f273adbcd4 ("nfp: add framework to support ipsec offloading") Reported-by: Changyul Lee Signed-off-by: Sang-Hoon Choi Link: https://patch.msgid.link/179001455912.44752.17153022439349797877.idr-bug-92@gmail.com Signed-off-by: Jakub Kicinski commit 5b49efa1e16228921ceeae68d34defc8a4548dcb Merge: a08b39c5d5735a 9476b446886292 Author: Jakub Kicinski Date: Thu Sep 24 09:57:57 2026 -0700 Merge branch 'net-ena-fix-resource-cleanup-on-probe-failure' Guangshuo Li says: ==================== net: ena: fix resource cleanup on probe failure This series fixes two resource leaks in the ena_probe() error path after ena_device_init() has successfully initialized device resources. Patch 1 adds the missing PHC cleanup. Patch 2 adds the missing MMIO read request cleanup. ==================== Link: https://patch.msgid.link/20260921154202.471662-1-lgs201920130244@gmail.com Signed-off-by: Jakub Kicinski commit 9476b4468862927297c94c440863cd8ed1e7cc83 Author: Guangshuo Li Date: Mon Sep 21 23:42:02 2026 +0800 net: ena: fix MMIO read buffer leak on probe failure ena_device_init() initializes the MMIO read mechanism with ena_com_mmio_reg_read_request_init(), which allocates a coherent DMA buffer for MMIO read responses. The normal removal path releases this buffer through ena_com_mmio_reg_read_request_destroy(). However, if ena_probe() fails after ena_device_init() succeeds, the error path destroys the admin resources and eventually frees ena_dev without destroying the MMIO read request, leaving the coherent DMA buffer allocated. Call ena_com_mmio_reg_read_request_destroy() in the probe error path before releasing the remaining device resources. This issue was found by manual code inspection. Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260921154202.471662-3-lgs201920130244@gmail.com Signed-off-by: Jakub Kicinski commit 0958ea4355e2e9220ad4e13da3b7d94f365ed34f Author: Guangshuo Li Date: Mon Sep 21 23:42:01 2026 +0800 net: ena: fix PHC cleanup on probe failure ena_probe() initializes the PHC as part of ena_device_init(), but the probe failure path does not destroy it before freeing the PHC private data. The normal removal path calls ena_phc_destroy() through ena_destroy_device() before ena_phc_free(). However, if probe fails after ena_device_init() succeeds, the error path reaches ena_phc_free() without unregistering the PTP clock or destroying the device PHC resources. Call ena_phc_destroy() in the probe error path before freeing the PHC private data. This issue was found by manual code inspection. Cc: stable@vger.kernel.org tags and describe this as a consistency cleanup Fixes: e0ea34158ee8 ("net: ena: Add PHC support in the ENA driver") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Cc: stable Link: https://patch.msgid.link/20260921154202.471662-2-lgs201920130244@gmail.com Signed-off-by: Jakub Kicinski commit a08b39c5d5735a3bf3932c50ae2cef41857077c6 Merge: 33a61f09232bbb dad19b59da050c Author: Jakub Kicinski Date: Thu Sep 24 09:56:04 2026 -0700 Merge branch 'ovs-net-sched-fixes-for-uaf-after-conntrack-extension-realloc' Ilya Maximets says: ==================== ovs, net/sched: fixes for UAF after conntrack extension realloc One clean up change plus two fixes for the UAF on helper extension realloc x 2. First half for OVS and the second half for the similar code in act_ct. This should cover all the known cases of this problem in these two modules. ==================== Link: https://patch.msgid.link/20260921145655.3167436-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski commit dad19b59da050cb60d3f7023dac2a042a84bf0bd Author: Ilya Maximets Date: Mon Sep 21 16:55:48 2026 +0200 net/sched: act_ct: fix helper UAF due to extensions realloc While calling the helpers, a raw pointer to the extensions area is wired into expectations list: -> nf_ct_helper() -> helper->help() -> nf_ct_expect_related_report() -> nf_ct_expect_insert() -> hlist_add_head_rcu(&exp->lnode, &master_help->expectations) In case the connection is not confirmed yet, more extensions can be added afterwards with *_ext_add() calls reallocating the extension space and leaving the now invalid pointer in the expectations list that is later accessed while removing the expectation. Make sure that helpers are called at the end after all the other extensions are already added. Note that the helper rejection now leaves the mark and labels set, but that's not different from how the NAT was handled before or how the mark and the labels were handled on confirmation failure. And there are no atomicity guarantees provided by the API anyway. Fixes: a21b06e73191 ("net: sched: add helper support in act_ct") Cc: stable@vger.kernel.org Reported-by: Axel Mierczuk Signed-off-by: Ilya Maximets Reviewed-by: Xin Long Reviewed-by: Jamal Hadi Salim Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20260921145655.3167436-7-i.maximets@ovn.org Signed-off-by: Jakub Kicinski commit 00df72e39f306e2f7adb68528a5c92109da6a0a9 Author: Ilya Maximets Date: Mon Sep 21 16:55:47 2026 +0200 net/sched: act_ct: remove 'add_helper' dead code This variable can only become 'true' when the connection is not confirmed, but it is only checked when it is confirmed. So, it can be treated as being always false and just removed. Fixes: a21b06e73191 ("net: sched: add helper support in act_ct") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Reviewed-by: Xin Long Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260921145655.3167436-6-i.maximets@ovn.org Signed-off-by: Jakub Kicinski commit f85009dfcd65e5969526b0db7a49b5413746e630 Author: Ilya Maximets Date: Mon Sep 21 16:55:46 2026 +0200 net/sched: act_ct: avoid modifying shared unconfirmed ct entry In a case where skb with an unconfirmed ct entry gets cloned, we may end up processing both again but with different sets of extensions. The series of events: 1. The first clone wants to commit and runs the helpers wiring up the extension pointer into the expectation list. 2. Then it looses the confirmation keeping the entry unconfirmed. 3. Second clone now wants to commit labels or run NAT and adds the new extension for that breaking the pointer in the expectation list causing UAF on the destruction path later. While this is possible to trigger, there should be no practical network pipeline where we need to process both clones without modifications in the same zone. So, let's just reset the entry in case for some reason we got an skb with a shared one. This doesn't affect any known use cases, but avoids any potential problems with sharing and modification of the unconfirmed ct entry. Unlike openvswitch module, act_ct allows for NAT without commit. Changing that would be a uAPI break. So, act_ct needs to reset on NAT regardless of the commit flag to avoid reallocation of the extension space. This, however, doesn't really change the picture for sensible networking cases as there should be no need to run the same packet twice (before and after the clone) through conntrack without packet header or zone changes and without commit. The fixes tag points to the introduction of helpers, since that's the main UAF trigger for the sharing. Fixes: a21b06e73191 ("net: sched: add helper support in act_ct") Cc: stable@vger.kernel.org Reported-by: Axel Mierczuk Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Reviewed-by: Xin Long Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260921145655.3167436-5-i.maximets@ovn.org Signed-off-by: Jakub Kicinski commit 1a4151e6be57b098b7a5ebfbde58585e83200cdc Author: Ilya Maximets Date: Mon Sep 21 16:55:45 2026 +0200 net: openvswitch: conntrack: fix helper UAF due to extensions realloc While calling the helpers, a raw pointer to the extensions area is wired into expectations list: -> nf_ct_helper() -> helper->help() -> nf_ct_expect_related_report() -> nf_ct_expect_insert() -> hlist_add_head_rcu(&exp->lnode, &master_help->expectations) In case the connection is not confirmed yet, more extensions can be added afterwards with *_ext_add() calls reallocating the extension space and leaving the now invalid pointer in the expectations list that is later accessed while removing the expectation. Make sure that helpers are called at the end after all the other extensions are already added. Note that the helper rejection now leaves the mark and labels set, but that's not different from how the NAT was handled before or how the mark and the labels were handled on confirmation failure. And there are no atomicity guarantees provided by the API anyway. Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action") Cc: stable@vger.kernel.org Reported-by: Axel Mierczuk Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20260921145655.3167436-4-i.maximets@ovn.org Signed-off-by: Jakub Kicinski commit 5e6c14dd42a1c1fe938e573dc6c9098145b2b0c4 Author: Ilya Maximets Date: Mon Sep 21 16:55:44 2026 +0200 net: openvswitch: conntrack: remove 'add_helper' dead code This variable can only become 'true' when the connection is not confirmed, but it is only checked when it is confirmed. So, it can be treated as being always false and just removed. Fixes: 3c1860543fcc ("openvswitch: add nf_ct_is_confirmed check before assigning the helper") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20260921145655.3167436-3-i.maximets@ovn.org Signed-off-by: Jakub Kicinski commit 26b2bd70d22457556e2fa01cbf1192cb1a94d619 Author: Ilya Maximets Date: Mon Sep 21 16:55:43 2026 +0200 net: openvswitch: conntrack: avoid modifying shared unconfirmed ct entry In a case where skb with an unconfirmed ct entry gets cloned, we may end up committing both but with different sets of extensions. The series of events: 1. The first clone wants to commit and runs the helpers wiring up the extension pointer into the expectation list. 2. Then it looses the confirmation keeping the entry unconfirmed. 3. Second clone now wants to commit labels and adds the new extension for that breaking the pointer in the expectation list causing UAF on the destruction path later. While this is possible to trigger, there should be no practical network pipeline where committing both clones without modifications into the same zone is needed. So, let's just reset the entry in case for some reason we got an skb with a shared one during commit. This doesn't affect any known use cases, but avoids any potential problems with sharing and modification of the unconfirmed ct entry. The fixes tag points to the introduction of helpers, since that's the main UAF trigger for the sharing. Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action") Cc: stable@vger.kernel.org Reported-by: Axel Mierczuk Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20260921145655.3167436-2-i.maximets@ovn.org Signed-off-by: Jakub Kicinski commit 33a61f09232bbbc5db9ded09bf85f4b9b5744c04 Merge: 3173cba1170131 006208026819d5 Author: Jakub Kicinski Date: Thu Sep 24 09:50:49 2026 -0700 Merge tag 'ovpn-net-20260921' of https://github.com/OpenVPN/ovpn-net-next Antonio Quartulli says: ==================== Included fixes: * add selftest coverage for peer VPN address validation * reject multicast, broadcast and loopback peer VPN addresses, which can never identify a peer * reject MP peers left with no usable VPN address, as they can never be selected for TX * reject duplicate peer VPN addresses, which made peer lookup return an arbitrary peer * fix stale entry left in the VPN address hashtable when an address is cleared * fix torn IPv6 address read on lockless TX when the unusable local source is cleared in place * fix torn IPv6 address read on lockless TX when a new local endpoint is learned in place * fix dst cache being populated with a route resolved from an already replaced bind * fix stale route being reused after the socket mark or UDP source port changed * fix bogus validation of an unspecified local source address, which must instead be left to route source autoselection * fix IPv6 link-local peer endpoints losing their scope id when configured via netlink, breaking route lookup * tag 'ovpn-net-20260921' of https://github.com/OpenVPN/ovpn-net-next: selftests: ovpn: validate peer VPN addresses ovpn: reject invalid peer VPN addresses ovpn: reject multipeer peers without VPN addresses ovpn: reject duplicate peer VPN addresses ovpn: always unhash old VPN addresses before rehashing ovpn: replace bind when clearing stale local source ovpn: replace bind when learning local endpoint ovpn: validate peer state before caching UDP dst ovpn: track UDP socket route key for peer dst cache ovpn: skip UDP source validation for unspecified addresses ovpn: preserve IPv6 scope id for netlink peer endpoints ==================== Link: https://patch.msgid.link/20260921102215.3599702-1-antonio@openvpn.net Signed-off-by: Jakub Kicinski commit 3173cba1170131816972ed2b6185cb970ba8b747 Author: Jiawen Wu Date: Mon Sep 21 15:15:49 2026 +0800 net: libwx: fix races in Tx timestamp handling wx->ptp_tx_skb is shared between the Tx path, the PTP auxiliary worker and the timestamp cleanup paths. The WX_STATE_PTP_TX_IN_PROGRESS bit prevents multiple Tx paths from submitting timestamp requests, but does not serialize the worker against cleanup. As a result, wx_ptp_clear_tx_timestamp() can free an skb after wx_ptp_tx_hwtstamp_work() has obtained its pointer. The worker may then pass the freed skb to skb_tstamp_tx() and release the same reference again. The cleanup path may also clear the in-progress bit while the worker is still processing the old skb. This allows the Tx path to publish a new skb which the worker can subsequently overwrite with NULL, leaking its reference. Add a dedicated spinlock to protect publication and consumption of the Tx timestamp skb. Detach the skb and clear the in-progress bit while holding the lock, then deliver the timestamp and release the skb after dropping it. Use the same locked cleanup in the quiesce path, but keep the detach there free of register accesses: quiesce runs during PCIe error recovery, where MMIO is not reliable, and it deliberately did not touch the device before. The lock is taken with interrupts disabled, because netpoll can call ndo_start_xmit() with hard interrupts already off. When handling a Tx DMA mapping failure, keep the transmit path reference until after comparing the skb under the lock. This prevents skb address reuse from making the error path mistake a newer timestamp request for the failed one. Fixes: 06e75161b9d4 ("net: wangxun: Add support for PTP clock") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/6C7EC12D69217315%2B20260818074721.45536-1-jiawenwu%40trustnetic.com Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/77431AF9A0E369F3+20260921071549.1141804-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski commit a940003f44e7e441c228151dd212642152700ec8 Author: Aleksei Sviridkin Date: Mon Sep 21 01:20:44 2026 +0300 net: phylink: record the PHY only once bringup cannot fail phylink_bringup_phy() stores the PHY in pl->phydev before its last fallible step: on a MAC whose phylink ops implement LPI, phy_eee_rx_clock_stop() can fail with a real MDIO error. The callers unwind with phy_detach(), which knows nothing about pl->phydev, so a pointer to a PHY that is no longer attached outlives the failed connect. What that costs depends on how the caller got here. phylink_connect_phy() goes through phylink_attach_phy(), which refuses to attach while pl->phydev is set, turning a transient MDIO error into a permanent -EBUSY. The SFP path is worse than that: sfp_sm_probe_phy() answers the failure with phy_device_remove() and phy_device_free(), and it assigns sfp->mod_phy only past that error return, so nothing clears pl->phydev and it is left pointing at a freed phy_device that phylink_resolve() and the ethtool helpers go on reading. phylink_fwnode_phy_connect() has no such check, so a later connect overwrites the stale pointer and hides the problem. A disconnect does not: phylink_disconnect_phy() hands that pointer to phy_disconnect(), and the second phy_detach() on the same PHY drops references the first one already released. Found while making a DSA port survive a PHY whose driver arrives after the switch probes: keeping the port across a failed connect and retrying is what makes this window reachable. Publish the pointer after the last call that can fail instead of unwinding it afterwards. Nothing between the two points reads pl->phydev, and the registration that follows cannot fail: phy_request_interrupt() falls back to polling on its own. The PHY-side state keeps the order it had, so no MDIO operation moves relative to another. Fixes: 03abf2a7c654 ("net: phylink: add EEE management") Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260920222044.1752860-1-f@lex.la Signed-off-by: Jakub Kicinski commit f75f21ef36285e5f56ee0c428bd2909ee81165b9 Author: Ming Wang Date: Sun Sep 20 15:44:59 2026 +0800 net: usb: cdc_mbim: add MeiG Smart SRM821 to ZLP whitelist The MeiG Smart SRM821 5G module (0x2dee:0x4d53) crashes and drops off the USB bus when it receives a Zero Length Packet (ZLP) after sending or receiving an NTB of exactly 16384 bytes (tx_max). According to the MBIM specification, devices do not require a ZLP if the NTB size is exactly dwNtbOutMaxSize. However, the cdc_mbim driver defaults to sending ZLPs for devices not explicitly whitelisted to accommodate non-conformant hardware. This default behavior breaks the strictly conformant MeiG SRM821 module. Add this device to the ZLP conformance whitelist (cdc_mbim_info) so the driver will pad the NTB to avoid sending ZLPs, preventing the device firmware from crashing. Cc: stable@vger.kernel.org Signed-off-by: Ming Wang Link: https://patch.msgid.link/20260920074500.826121-1-wangming01@loongson.cn Signed-off-by: Jakub Kicinski commit 1765a153d985c231357145e26798f9408db10e42 Author: Guopeng Zhang Date: Thu Sep 24 17:15:36 2026 +0800 cgroup/pids: Restore pids.events notifications in local mode A fork rejected by the pids controller increments the counter reported by pids.events. When local event accounting is selected, however, pids_event() returns after notifying only events_local_file, leaving pids.events pollers asleep. On legacy hierarchies, pids.events.local does not exist. With pids_localevents, pids.events reports the same local counter. In both cases, pids.events changes without generating a notification. This can be reproduced with a pids_localevents mount: mkdir /tmp/test mount -t cgroup2 -o pids_localevents none /tmp/test mkdir /tmp/test/t echo 1 > /tmp/test/t/pids.max cat /tmp/test/t/pids.events # max 0 timeout 3 inotifywait -e modify /tmp/test/t/pids.events & sh -c 'echo $$ > /tmp/test/t/cgroup.procs; (true &)' 2>/dev/null wait cat /tmp/test/t/pids.events # max 1 Without this patch, inotifywait times out without reporting an event. Notify pids.events before returning from the local event path. Fixes: 3f26a885a068 ("cgroup/pids: Add pids.events.local") Cc: stable@vger.kernel.org # v6.11+ Signed-off-by: Guopeng Zhang Signed-off-by: Tejun Heo commit fe99bbeee5c5dbd3abc30721a8079ced59649d97 Author: Yilin Zhang Date: Thu Sep 24 12:49:00 2026 +0800 tcp: fix use-after-free of retransmit_skb_hint in tcp_send_synack() When tcp_send_synack() replaces the cloned SYN skb at the head of the retransmit queue with a copy, it frees the original with tcp_rtx_queue_unlink_and_free() and only repairs tp->highest_sack. tp->retransmit_skb_hint keeps pointing at the freed skbuff_fclone_cache object. The dangling hint is read in tcp_verify_retransmit_hint() and used as the root of the rbtree walk in tcp_xmit_retransmit_queue(). An unprivileged TFO client (sendmsg(MSG_FASTOPEN)) can arm the hint with an attacker-supplied ICMP fragmentation-needed message, after which a simultaneous open frees the armed SYN skb: BUG: KASAN: slab-use-after-free in tcp_mark_skb_lost (net/ipv4/tcp_input.c:1316) Read of size 4 at addr ffff88800604d928 by task swapper/1/0 Call Trace: tcp_mark_skb_lost (net/ipv4/tcp_input.c:1316) tcp_simple_retransmit (net/ipv4/tcp_input.c:3158) tcp_v4_err (net/ipv4/tcp_ipv4.c:587) Sync the hint to the copy. Fixes: c31b70c9968f ("tcp: Add logic to check for SYN w/ data in tcp_simple_retransmit") Reported-by: Kimi Security Team Tested-by: Weiming Shi Signed-off-by: Yilin Zhang Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/8a9dff4063a2745653b7e88ceb745d75efa16e68.1790224474.git.yilinzhang@moonshot.ai Signed-off-by: Jakub Kicinski commit 26cc0e69cce062cd3aa6fae33074684669c35a71 Author: Hui Peng Date: Mon Sep 21 05:10:01 2026 +0000 mctp: route: iterate socket tag list in mctp_lookup_prealloc_tag() When a socket transmits a packet with MCTP_TAG_PREALLOC set, mctp_lookup_prealloc_tag() iterates over the per-netns &mns->keys list and matches netid, req_tag, peer_addr, and manual_alloc, without checking whether tmp->sk == &msk->sk. This allows any MCTP socket in the same network namespace to use and consume another socket's preallocated tag. Iterate the socket's own tag list (&msk->keys via sklist) instead of the namespace-wide &mns->keys list in mctp_lookup_prealloc_tag(), ensuring that only tags allocated by msk are matched. Tested in QEMU against Linux 7.3.0-rc3 by allocating a manual tag (0x18) on socket A via SIOCMCTPALLOCTAG for peer EID 9 and sending a 4-byte message with MCTP_TAG_PREALLOC from socket B in the same network namespace. On the unfixed kernel, sendto(sock_b) using socket A's preallocated tag succeeds (ret = 4); with this patch applied, sendto(sock_b) fails with -ENOENT (errno = 2) while sendto(sock_a) succeeds (ret = 4). Fixes: 63ed1aab3d40 ("mctp: Add SIOCMCTP{ALLOC,DROP}TAG ioctls for tag control") Suggested-by: Jeremy Kerr Cc: stable@vger.kernel.org Signed-off-by: Hui Peng Link: https://patch.msgid.link/20260921051002.1656692-1-benquike@gmail.com Signed-off-by: Jakub Kicinski commit 5fc5768c7ca92895ccd1de94dc521e5a55ae7896 Merge: f49a343b305c0b 1b1dca56828f33 Author: Linus Torvalds Date: Thu Sep 24 08:25:26 2026 -0700 Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Pull bpf fixes from Alexei Starovoitov: - Fix bpf_skb_change_tail() to drop the checksum offload instead of rejecting the trim of CHECKSUM_PARTIAL skbs (Daniel Borkmann) - Add KF_PERFMON kfunc flag and require CAP_PERFMON for kfuncs that read arbitrary memory and for untrusted read-only memory reads (Daniel Borkmann) - Clear scalar delta on narrowing stack spill (Daniel Borkmann) - Set up the frame pointer for the exception callback in arm64 JIT, and zero-fill other CPUs when BPF_F_CPU update creates a per-cpu hash element (Donggeun Yoo) - Various fixes (Emil Tsalapatis): - Fix bounds check underflow for skb-backed dynptrs - Fix rx_queue_mapping context access code generation in bpf_sock - Reject packet pointer arguments to subprogs that may mutate the packet - Reject ALU instructions that see arena and non-arena operands on different code paths - Fix copied_seq double-counting on sockmap self-redirect (Geliang Tang) - Fix divide-by-zero in btf_struct_walk() on a flexible array of zero-sized elements, fix out-of-bounds read of rtt_min in sock_ops (Jiayuan Chen) - Fix bpf_sock_destroy() out-of-bounds read of sk_protocol on TIME_WAIT and request socks, and sleeping under RCU when destroying a listener with pending children (Jiayuan Chen) - Fix JEQ/JNE with immediate operand in MIPS32 JIT and missing zero extension of BSWAP 16/32 in MIPS64 JIT (Johan Almbladh) - Avoid soft lockup in htab lookup[_and_delete] batch operations on large maps (Jose Fernandez) - Various fixes (Kumar Kartikeya Dwivedi): - Verify global subprogs in each sleepability context they are called from - Make post-verification instruction rewrites killable - Preserve packet pointer displacement in regsafe() - Apply CO-RE relocations before subprogram validation, restrict CO-RE poisoning to relocatable instructions, and reject truncated ldimm64 CO-RE relocations in libbpf - Assign lock identity to callback map values - Compare stack frames in regs_exact() - Bound ownership depth through local kptrs and graph roots - Fix u32 overflow in map batch operations when the map size exceeds 4GB (Masoud Aghasi) - Fix UAF in bpf memalloc due to concurrent consumption of ttrace lists in alloc_bulk() (Pu Lehui) - Allow gotox as the terminal instruction of a program or a subprogram (Siddharth Chintamaneni) - Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL, skip unsettled links in link iterator, and reject dev-bound-only programs on other devices (Weiming Shi) - Reject non-negative stack offsets in stack_slot_obj_get_spi() (Xu Yunxiang) - Check params size before reading reserved fields in bpf_crypto_ctx_create() (Yuqi Xu) - Reject max_entries > INT_MAX in sock_map_alloc() (Zhao Gongyi) - Use a 32-bit compare in xsk_map_gen_lookup() (Zhiling Zou) - Use kvfree() in xdp_test_run_teardown() (Zhixing Chen) * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: (58 commits) selftests/bpf: Test per-cpu initialization of a BPF_F_CPU created element bpf: Zero-fill other CPUs when BPF_F_CPU creates a per-cpu hash element bpf: Fix BSWAP 32 and 16 on MIPS64 bpf: Fix immediate JMP JEQ/JNE on MIPS32 bpf: Reject dev-bound-only programs on other devices bpf, sockmap: Reject max_entries > INT_MAX in sock_map_alloc selftests/bpf: Test for mixed arena/nonarena code paths bpf: Prevent variable arena/non-arena register contents selftests/bpf: Test rejection of pkt args to mutating subprogs bpf: Reject pkt arguments in mutating subprogs selftests/bpf: Add selftests for rx_queue_mapping context access bpf: Fix bpf_sock context code generation selftests/bpf: Test dynptr slices past end of skb bpf: Fix bounds check for skb-backed dynptrs selftests/bpf: Reject iterator destruction through fp+0 bpf: Reject non-negative offsets in stack_slot_obj_get_spi() bpf: Check params size before reading reserved fields selftests/bpf: Check local object ownership depth bpf: Bound ownership depth through local kptrs and graph roots selftests/bpf: Cover frame changes in bounded loops ... commit 0b2bbfee2bcb80017d4d47e94f8dc92151dcdd6f Merge: 7c9f391ec89cb6 0d80ba0a204c6a Author: Jakub Kicinski Date: Thu Sep 24 08:16:58 2026 -0700 Merge branch 'net-dsa-mt7530-fix-two-crashes-on-driver-unbind' Aleksei Sviridkin says: ==================== net: dsa: mt7530: fix two crashes on driver unbind Unbinding the MT7530 driver from an MT7531 dereferences NULL in regulator_disable(). On a Netcraze NC-1012 (MT7981B + MT7531, 6.18.44): # echo mdio-bus:1f > /sys/bus/mdio_bus/drivers/mt7530-mdio/unbind oopses there, and the build it was found on sets CONFIG_PANIC_ON_OOPS, so the board goes down with it. Fix that and the same command gets as far as mt7530_remove_common(), which disposes interrupt mappings the switch's own regmap-irq chip still owns; the regmap-irq thread then faults in handle_nested_irq() later in the same teardown. rmmod reaches both, since mdio_module_driver() calls .remove on module exit. Patch 1 is the regulator one. mt7530_probe() requests the core and io supplies only for ID_MT7530 and mt7530_setup() enables them under the same test, but mt7530_remove() disables them unconditionally, so on an MT7621 or an MT7531 both pointers are still NULL from devm_kzalloc(). It reaches the MDIO front end only. Patch 2 is the interrupt one, and it reaches further. mt7530_remove_common() disposes the per-PHY interrupt mappings by hand from .remove, while the regmap-irq chip that owns the domain is devm-registered and its parent interrupt is only freed once .remove has returned. regmap_del_irq_chip() disposes the same mappings itself, in an order that cannot race, so the driver's call adds nothing but a window. That helper is called from both front ends, so the defect also covers the MMIO parts - MT7988, EN7581, AN7583 and EN7528 - which have no regulators and never meet the first defect at all. The order is not arbitrary. On an MT7531 the regulator fault happens in the first thing mt7530_remove() does with the switch, so execution never reaches the interrupt defect. The second only became visible once the first was fixed, which is also how both came to be found on one board. Found and verified there. Without patch 1 the unbind panics in regulator_disable(); with patch 1 alone the panic moves on to handle_nested_irq(); with both, three unbind/bind cycles run, two back to back and a third after a pause. In the two whose dmesg was captured, each unbind removes the switch from the driver directory and takes lan1 to lan4 with it, each bind brings them back, and lan1 relinks at 1Gbps/full after both binds, lan4 after the second. uptime rose from 58 to 202 seconds across the three without resetting and pstore gained no new record. The third cycle stayed unbound long enough to read the descriptors: no mt7530 line in /proc/interrupts and no irq/79, irq/80 or irq/81 directory, and the next bind reuses those three numbers - regmap-irq freeing and disposing what the driver no longer touches. The kernel under test was identified by the sha256 of its ELF notes section, read from /sys/kernel/notes on the running board and computed in advance from the flashed image. What hardware could not answer here. There is no MT7530 or MT7621 part on this bench, so the ID_MT7530 branch that patch 1 adds was checked by reading the generated code rather than by running it, and no MMIO part was available to exercise patch 2 on that front end either. One unrelated WARN remains across the unbind, from sysfs_remove_link() under dsa_user_destroy(); it is a separate DSA teardown-ordering defect and is not addressed here. v1: https://lore.kernel.org/20260914202421.2737079-1-f@lex.la ==================== Link: https://patch.msgid.link/20260918015020.2518315-1-f@lex.la Signed-off-by: Jakub Kicinski commit 0d80ba0a204c6a16bd7778b50de578dff107c0fe Author: Aleksei Sviridkin Date: Fri Sep 18 04:50:20 2026 +0300 net: dsa: mt7530: leave the MDIO IRQ mappings to regmap-irq mt7530_remove_common() disposes the per-PHY interrupt mappings from .remove, but the regmap-irq chip that owns the domain is devm-registered, so its parent interrupt is only freed once .remove has returned. The switch's own regmap-irq thread can therefore still dispatch on a mapping that is already gone: irq_find_mapping() returns 0, irq_to_desc() returns NULL and handle_nested_irq() locks desc->lock without checking it. The attached PHYs have not given those interrupts back yet either, which the kernel warns about a moment before the fault. regmap_del_irq_chip() disposes the same mappings itself, after freeing the parent interrupt and before removing the domain, so there is nothing left for the driver to do here. Until it runs the descriptors stay alive, and a late dispatch on one of them is harmless: dsa_unregister_switch() has freed the PHY handlers by then, so handle_nested_irq() finds no action and returns. Fixes: 254f6b272e3b ("dsa: mt7530: Utilize REGMAP_IRQ for interrupt handling") Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260918015020.2518315-3-f@lex.la Signed-off-by: Jakub Kicinski commit c2cdef41e0b4d8ed23a5b41e6ad4e64594e055e4 Author: Aleksei Sviridkin Date: Fri Sep 18 04:50:19 2026 +0300 net: dsa: mt7530: fix NULL dereference on unbind of MT7531 and MT7621 The core and io supplies are only requested for ID_MT7530: both the devm_regulator_get() in probe and the regulator_enable() in mt7530_setup() are guarded by the switch id, but mt7530_remove() disables them unconditionally. On an MT7621 or an MT7531 both pointers are still NULL from devm_kzalloc(), so rmmod or a sysfs unbind calls regulator_disable() on NULL. Fixes: ddda1ac116c8 ("net: dsa: mt7530: support the 7530 switch on the Mediatek MT7621 SoC") Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260918015020.2518315-2-f@lex.la Signed-off-by: Jakub Kicinski commit 1b1dca56828f33bc5e39b930ebed062e77fbe3b2 Merge: 8110ba09777873 3422808f4e9592 Author: Alexei Starovoitov Date: Thu Sep 24 14:24:52 2026 +0000 Merge branch 'bpf-fix-per-cpu-initialization-of-a-bpf_f_cpu-created-hash-element' Donggeun Yoo says: ==================== bpf: fix per-cpu initialization of a BPF_F_CPU created hash element A BPF_F_CPU update that creates a [lru_]percpu_hash element writes the named CPU's slot and leaves the others holding the recycled element's values, so a lookup of the new key returns a deleted key's per-cpu values. Patch 1 zero-fills the other CPUs. Patch 2 adds the selftest: the existing cpu_flag subtests always prime a key with BPF_F_ALL_CPUS first, so the create path is not covered today. v1: https://lore.kernel.org/bpf/20260920093153.439743-1-donggeunyoo.kernel@gmail.com/ v2: https://lore.kernel.org/bpf/20260923000801.1764758-1-donggeunyoo.kernel@gmail.com/ Changes in v3: - patch 1: key init_cpu on BPF_F_CPU rather than on onallcpus (Leon Hwang) - patch 1: re-flow the paragraph naming pcpu_copy_value() (BPF CI AI review) - patch 2: pin the thread across the delete and the create, and name a CPU other than the pinned one, so the BPF_F_NO_PREALLOC arm does not depend on staying put (BPF CI AI review) Changes in v2: - patch 1: cover the BPF_F_CPU entry condition in the block comment above pcpu_init_value() (BPF CI AI review, Alexei Starovoitov) - patch 2: skip the new subtests instead of failing them on a uniprocessor machine (Sashiko AI review) ==================== Link: https://patch.msgid.link/20260924102321.2120434-1-donggeunyoo.kernel@gmail.com Signed-off-by: Alexei Starovoitov commit 3422808f4e959266ea7790101ac90b8341f48226 Author: Donggeun Yoo Date: Thu Sep 24 19:23:21 2026 +0900 selftests/bpf: Test per-cpu initialization of a BPF_F_CPU created element The existing cpu_flag subtests always prime a key with BPF_F_ALL_CPUS before any BPF_F_CPU write, so the create path is never covered. Add a subtest that creates the element with BPF_F_CPU on a map with max_entries 1, so the key can only reuse the element the previous key released, and check that the CPUs the update did not name read back zero. Run it for PERCPU_HASH preallocated and BPF_F_NO_PREALLOC, whose per-cpu areas come from different allocators, and for LRU_PERCPU_HASH. Under BPF_F_NO_PREALLOC the reuse is only guaranteed on the cpu that ran the delete, so pin the thread across the pair, and name a cpu other than that one in map_flags. Signed-off-by: Donggeun Yoo Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260924102321.2120434-3-donggeunyoo.kernel@gmail.com commit c3a66e5f5bab3912e9f84223c5a982bf4333d5a1 Author: Donggeun Yoo Date: Thu Sep 24 19:23:20 2026 +0900 bpf: Zero-fill other CPUs when BPF_F_CPU creates a per-cpu hash element pcpu_init_value() initializes the per-cpu area of a newly created [lru_]percpu_hash element. The area is recycled, so when the value comes from a BPF program (onallcpus == false) it writes the running CPU's slot and zeroes the rest. bpf_percpu_hash_update() passes onallcpus == true, which delegates to pcpu_copy_value(). pcpu_copy_value() writes only the CPU named in map_flags when BPF_F_CPU is set, so on the create path the other slots keep the recycled element's values: update(k1, 0xdeadc0de, BPF_F_ALL_CPUS) every CPU holds 0xdeadc0de delete(k1) element back on the freelist update(k2, 0xc0ffee, BPF_F_CPU | 0) creates, writes CPU 0 only lookup(k2) CPU 0 0xc0ffee, rest 0xdeadc0de Zero-fill the other CPUs on that arm too. Fixes: c6936161fd55 ("bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu_hash and lru_percpu_hash maps") Signed-off-by: Donggeun Yoo Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260924102321.2120434-2-donggeunyoo.kernel@gmail.com commit e66cf1625ec4a3fe68346119f371def713fd0a4d Author: Namjae Jeon Date: Wed Sep 23 20:25:49 2026 +0900 smb: client: use finish_no_open() for non-regular inodes An O_CREAT open can find an existing symlink or another non-regular inode. cifs_atomic_open() calls finish_open() on it and attaches a cifsFileInfo. Symlink inodes have no CIFS release operation, so the dentry reference held by cifsFileInfo is leaked. FMODE_OPENED also prevents the VFS from following the symlink. Track whether cifs_do_create() returned an open server handle. For non-regular inodes, close the handle if present, remove the pending open, and call finish_no_open() so the VFS can continue the lookup. Do not set FMODE_CREATED unless a regular file was opened. For O_NOFOLLOW with __O_REGULAR, return -ELOOP before the VFS's -EFTYPE check. Defer closing a legacy POSIX handle on a non-regular inode until after inode lookup. This avoids closing it again if lookup fails. Fixes: d2c127197dfc ("cifs: implement i_op->atomic_open()") Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: stable@vger.kernel.org commit 7c9f391ec89cb621d7af375ace2eb9a6248e5b9d Author: Christian Lamparter Date: Mon Sep 21 18:28:17 2026 +0200 net: emac: move setting of netops to fix crash fixes the following crash on driver initialization: |BUG: Kernel NULL pointer dereference on read at 0x00000158 |Faulting instruction address: 0xc0566b40 |Oops: Kernel access of bad area, sig: 11 [#1] |BE PAGE_SIZE=4K PowerPC 44x Platform |Modules linked in: |CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: GW 7.3.0-rc3+ #1 |Tainted: [W]=WARN |Hardware name: MyBook Live APM821XX 0x12c41c83 PowerPC 44x Platform |NIP: c0566b40 LR: c05648f8 CTR: c04c1e9c |REGS: c1053a20 TRAP: 0300 Tainted: GW (7.3.0-rc3+) |MSR: 0002b000 CR: 24008808 XER: 00000000 |DEAR: 00000158 ESR: 00000000 |GPR00: c05648f8 c1053b10 c1063600 c1030000 c5ab3000 00000000 [...] |GPR08: 00000002 00000000 00000000 c1053b40 84002808 00000000 [...] |GPR16: cfffd210 00000002 c0beafcc cfffc960 00000000 c1030644 [...] |GPR24: c0beafbc c1037000 00000000 0000000a 00000000 c1030000 [...] |NIP [c0566b40] phy_link_topo_add_phy+0x2c/0x1d0 |LR [c05648f8] phy_attach_direct+0x1a4/0x368 |Call Trace: |[c1053b10] [c0811e04] klist_put+0x54/0xb4 (unreliable) |[c1053b40] [c05648f8] phy_attach_direct+0x1a4/0x368 |[c1053b70] [c0564ae8] phy_connect_direct+0x2c/0x60 |[c1053b90] [c056c7a8] of_phy_connect+0x50/0x74 |[c1053bc0] [c0572a88] emac_probe+0xd50/0x119c |[c1053c90] [c04cb770] platform_probe+0x74/0xa4 |[c1053cb0] [c04c8f08] really_probe+0x120/0x2b0 |[c1053cd0] [c04c9254] __driver_probe_device+0x1bc/0x1fc |[c1053d00] [c04c9334] driver_probe_device+0x38/0xa8 |[c1053d30] [c04c9560] __driver_attach+0xf4/0x10c |[c1053d50] [c04c6af8] bus_for_each_dev+0x68/0xd0 |[c1053d90] [c04c7c34] bus_add_driver+0xcc/0x1ec |[c1053dc0] [c04c9f6c] driver_register+0xcc/0x110 |[c1053de0] [c0aa3f40] emac_init+0x1c4/0x200 This bug showed up starting with v7.3-rc1. At the NIP in phy_link_topo_add_phy() is a netdev_need_ops_lock() check. This was added by the following commit ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") The bug shows up because at the time of_phy_connect() was called, the netdev_ops were *not yet* determined. My fix is to move the code that sets netdev_ops+commac.ops+ethtool_ops further up as emac_init_config() derives that by looking at the device-tree and sets the required dev->phy_mode accordingly. During review, the Sashiko bot's AI stated that the commac assignment became a dead store. Great catch! To keep the original behavior as-is, one mentioned option "set dev->commac.ops = &emac_commac_ops only in the non-gige case?" sounded like a great plan. So the dev->commac.ops assignment for the non-gige-case moves into the else block. This patch was tested on a WD MyBook Live (RGMII). the device now works again. Fixes: ded86da4bbb7 ("net: ethtool: relax ethnl_req_get_phydev() locking assertion") Signed-off-by: Christian Lamparter Reviewed-by: Nicolai Buchwitz Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/49cd7343bc0e507c022071f3e2b5662b053dca73.1790007431.git.chunkeey@gmail.com Signed-off-by: Paolo Abeni commit d431e03d831c043707e22311c4bdea1907166c34 Author: Arnd Bergmann Date: Tue May 19 22:30:49 2026 +0200 drbd: remove unused drbd_nl_mcgrps[] array After the rework, two files have a copy of drbd_nl_mcgrps[], but one of them has no references: drivers/block/drbd/drbd_nl_gen.c:641:42: error: 'drbd_nl_mcgrps' defined but not used [-Werror=unused-const-variable=] 641 | static const struct genl_multicast_group drbd_nl_mcgrps[] = { | ^~~~~~~~~~~~~~ At the default warning level, -Wunused-const-variables is turned off, so this has gone unnoticed. Remove the extra variable. Fixes: 8098eeb693c4 ("drbd: replace genl_magic with explicit netlink serialization") Signed-off-by: Arnd Bergmann Reviewed-by: Christoph Böhmwalder Link: https://patch.msgid.link/20260519203057.1340528-1-arnd@kernel.org Signed-off-by: Jens Axboe commit d6ec384c87cc851cfd13bb18c99ce351ccee6192 Author: Fang Xieyan Date: Mon Sep 21 20:54:41 2026 +0800 net/sched: act_ife: validate metadata length before decoding skbmark_decode(), skbprio_decode() and skbtcindex_decode() read fixed-size values from the TLV payload without validating its length. A malformed IFE frame can declare a shorter payload, causing the decoders to consume bytes beyond the declared metadata value: [TLV type=IFE_META_SKBMARK len=4] -> dlen == 0, but decode reads 4 bytes The decoder may therefore set skb metadata from unintended input. Validate the payload length before decoding and return -EINVAL for invalid lengths. Read the values with get_unaligned_be32() and get_unaligned_be16(), as TLV payloads are not guaranteed to be aligned. Teach tcf_ife_decode() to log a decoder error separately from an unknown metaid; both are counted as overlimits and decoding continues with the remaining metadata. The metadata length issue was found by an automated audit of the IFE decode path at v6.18-rc7 and reproduced with a userspace sanitizer model of the decode path. Compile-tested on x86_64 with defconfig and NET_ACT_IFE=y: act_ife.o and the three act_meta_*.o build warning-free. Fixes: 084e2f6566d2 ("Support to encoding decoding skb mark on IFE action") Fixes: 200e10f46936 ("Support to encoding decoding skb prio on IFE action") Fixes: 408fbc22ef1e ("net sched ife action: Introduce skb tcindex metadata encap decap") Assisted-by: Hawkeye:GLM-5.3-flash Assisted-by: Qoder:Qwen3.8-Max Signed-off-by: Fang Xieyan Link: https://patch.msgid.link/20260921125441.81459-1-fangxy@xiaopeng.com Signed-off-by: Paolo Abeni commit f49a343b305c0b6c19a3b50c0bbf10bcd0e2e8fd Merge: e2936d228b9634 ae2c5bf9695737 Author: Linus Torvalds Date: Thu Sep 24 06:19:09 2026 -0700 Merge tag 'pinctrl-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - Serialize the calls to pinctrl_generic_dt_nod_to_map() - Fix a typo in S4 group in the Meson driver - Fix bank width and regmap usage in the MPFS-SSIO driver - Data register output latch behavior and voltage encoding fixes in the Sunxi driver - Free the IRQ domain on the error path in the single driver - Fix some QUP1 SE2/SE3 groups and a missing OF module alias in the Qualcomm drivers - Fix up the register banks for AON (I guess always-on) pins in the Tegra238 driver * tag 'pinctrl-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: tegra238: Fix register bank for AON pin groups pinctrl: qcom: ipq5210: Publish the OF module alias pinctrl: qcom: nord: Split QUP1 SE2/SE3 into lane-pair functions pinctrl: single: free the IRQ on domain creation failure pinctrl: sunxi: A523: fix voltage withstand encoding pinctrl: sunxi: keep a shadow copy of the data register output latches pinctrl: mpfs-mssio: use correct regmap function to set bank voltage pinctrl: mpfs-mssio: fix width of unused bank voltage setting pinctrl: generic: serialise pinctrl_generic_dt_node_to_map() pinctrl: meson: Fix typo in s4 group name commit 15814c01ac57643edf1662a076d2961332f277a5 Author: Alex Deucher Date: Wed Sep 23 21:44:30 2026 -0400 drm/amd/display: Bump frame warning limit for all builds of dml Some configs with gcc are also now affected. Signed-off-by: Alex Deucher (cherry picked from commit 76b9706e7fa1a6e374703170128b1be2f590cda7) commit e2936d228b96346d474f368f1bb0172582035577 Merge: ef33dd4e0a5290 ba13f1f32d96d7 Author: Linus Torvalds Date: Thu Sep 24 06:16:19 2026 -0700 Merge tag 'fixes-2026-09-24' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/memblock Pull memblock fix from Mike Rapoport: "The rework of HugeTLB bootmem allocation forgot to add the name for a new RSV_HUGETLB flag for proper display in debugfs. Add the flag name now" * tag 'fixes-2026-09-24' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/memblock: mm: memblock: add missing HugeTLB flag name commit c2de369c5c5b8599ca10fd5ca8d11fcd845c1331 Author: Haseeb Malik Date: Mon Sep 21 16:40:30 2026 -0400 macsec: initialize SecY before registering the netdevice Creating a MACsec device with MAC offload over an LRO-capable lower device triggers a warning in rtmsg_ifinfo_build_skb() when IPv4 forwarding is enabled by default. register_netdevice() invokes inetdev_init(), which disables LRO and emits a NETDEV_FEAT_CHANGE notification. This reaches macsec_fill_info() before macsec_add_dev() initializes the SecY. key_len is still zero, so macsec_fill_info() returns -EMSGSIZE and trips the WARN_ON in rtmsg_ifinfo_build_skb(), even though the skb has enough space. Even without the warning, notifications during registration can report uninitialized SecY attributes, including the SCI. This ordering has existed since the driver was introduced. Initialize the SecY and apply the new-link attributes before registration. Move MAC address inheritance into macsec_newlink() so the SCI can also be initialized before registration-time notifications report it. Move the per-CPU statistics and metadata destination allocation into ndo_init(), and release partial allocations on failure. Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Reported-by: syzbot+f2f6312ad1b5a0bfe316@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f2f6312ad1b5a0bfe316 Suggested-by: Sabrina Dubroca Link: https://lists.openwall.net/linux-kernel/2026/08/19/552 Signed-off-by: Haseeb Malik Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260921-fix-macsec-net-v3-1-accf94f93f5e@gmail.com Signed-off-by: Paolo Abeni commit ef33dd4e0a5290b1de0e64e30e738f005289e1f2 Merge: 62f4c998b297cf 2bc6b218717b9d Author: Linus Torvalds Date: Thu Sep 24 06:08:15 2026 -0700 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: - Fix the recently merged user ABI for the Arm CMN PMU driver filtering logic so that the ordering matches the hardware spec - Fix spurious warning when attempting to read PROT_NONE mappings of /dev/mem - Allow WFxT to be disabled on the command line, which is necessary for some configurations of recent Apple SoCs - Fix EL2 fine-grained trap configuration for the CPU PMU - Fix MIDR matching when applying CPU errata workarounds in a VM * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64/boot: Disable trapping of PMZR_EL0 writes to EL2 arm64: errata: match the target implementation CPU's own MIDR arm64: Add override for WFxT arm64: io: Reject non-user protection in ioremap_prot() perf/arm-cmn: Fix multi-filter encoding commit fbb13f2483e5aff94e1829bb6dd1d0514ddcfccf Merge: 5d35f9be9b54a1 91094f9c862168 Author: Mark Brown Date: Thu Sep 24 12:45:06 2026 +0100 ASoC: SDCA: Power management fixes for the class function driver Maciej Strozek says: The first corrects the point at which the suspended flag is set during system suspend, the second balances the runtime PM reference taken in probe when one of the later probe steps fails. Link: https://patch.msgid.link/20260924095458.2683755-1-mstrozek@opensource.cirrus.com commit 91094f9c86216898ce92141c26c8fec7e97544c0 Author: Maciej Strozek Date: Thu Sep 24 10:54:58 2026 +0100 ASoC: SDCA: Add better pm_runtime error handling in func probe Add a common error path in probe that balances the runtime PM reference. Fixes: 3af1815a2f9c ("ASoC: SDCA: Add basic SDCA function driver") Signed-off-by: Maciej Strozek Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260924095458.2683755-3-mstrozek@opensource.cirrus.com Signed-off-by: Mark Brown commit b16610e3770ef22fc8fcce818db0cd955332abf4 Author: Maciej Strozek Date: Thu Sep 24 10:54:57 2026 +0100 ASoC: SDCA: Set suspended flag after resuming within system suspend drv->suspended path was executed before system suspension instead of after, move it lower to correct it. Fixes: 7a5214f769c7 ("ASoC: SDCA: Add basic system suspend support") Signed-off-by: Maciej Strozek Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260924095458.2683755-2-mstrozek@opensource.cirrus.com Signed-off-by: Mark Brown commit 58eb1b3325edac42dc6df72c80962bd53a3c8ca7 Author: Dongliang Qin Date: Tue Sep 22 11:15:45 2026 +0800 rds: ib: Clear the sg list when mapping an MR fails rds_ib_map_frmr() stores the caller's scatterlist in the MR before DMA mapping and registration can fail. On failure, __rds_rdma_map() unpins the pages and frees the scatterlist, but rds_ib_free_frmr() can still return the MR to the pool with the stale pointer set. This leaves the pool with a dangling scatterlist and can lead to local privilege escalation. KASAN detects the resulting use-after-free when the MR is later torn down: BUG: KASAN: slab-use-after-free in __rds_ib_teardown_mr Read of size 8 Call Trace: __rds_ib_teardown_mr rds_ib_unreg_frmr rds_ib_flush_mr_pool rds_ib_flush_mrs rds_free_mr rds_setsockopt Store the scatterlist in the MR only after DMA mapping succeeds. If DMA mapping fails, return directly while the MR fields remain clear; the caller keeps ownership of the scatterlist and its pinned pages. If a later registration step fails, unmap the scatterlist and clear the MR fields before returning. Fixes: 1659185fb4d0 ("RDS: IB: Support Fastreg MR (FRMR) memory registration mode") Cc: stable@vger.kernel.org Signed-off-by: Dongliang Qin Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260922031546.3874605-1-cccccccccccc777777@gmail.com Signed-off-by: Paolo Abeni commit 77b1718e39e5c9f6956fb60807326af20baf889d Author: Myeonghun Pak Date: Mon Sep 21 21:46:05 2026 -0400 bna: prevent IOC timer rearm during teardown bna: prevent IOC timer rearm during teardown bnad_pci_remove() and the probe disable_ioceth path call timer_delete_sync() for ioc_timer, sem_timer and hb_timer, but not for iocpf_timer. bnad_iocpf_timeout() then takes bnad->bna_lock after free_netdev() has freed the struct bnad. Deleting iocpf_timer last does not fix this. sem_timer and iocpf_timer rearm each other: bnad_iocpf_sem_timeout() can arm iocpf_timer, and bnad_iocpf_timeout() arms sem_timer from bfa_ioc_hw_sem_get() when the semaphore is busy. timer_delete_sync() only waits out its own callback. bnad_ioceth_disable() can time out and leave that callback live. Shut all four IOC timers down with timer_shutdown_sync() on both paths, so a later mod_timer() is ignored. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 1d32f7696286 ("bna: IOC failure auto recovery fix") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260922014605.588040-1-mhun512@gmail.com Signed-off-by: Paolo Abeni commit 3cd204d4c66fd748edb7ddb072978ae4005c400f Merge: 00efbbd40bd5fd 43e746821f5f5a Author: Paolo Abeni Date: Thu Sep 24 12:41:12 2026 +0200 Merge branch 'net-atl1c-atl1e-atl1-fix-soft-lockup-on-out-of-range-tx-consumer-index' says: ==================== net: atl1c/atl1e/atl1: fix soft lockup on out-of-range tx consumer index atl1c_clean_tx() reads a hardware-maintained tx consumer index and walks a software index towards it: while (next_to_clean != hw_next_to_clean) { ... if (++next_to_clean == tpd_ring->count) next_to_clean = 0; } next_to_clean only ever takes values in [0, tpd_ring->count). If the hardware read returns a value outside that range - seen as 0xffff while the PCIe link/MAC is resetting, e.g. during a neighboring device's reboot - the loop condition can never become false, and the NAPI thread spins forever. This produced a real soft lockup on current hardware: watchdog: BUG: soft lockup - CPU#12 stuck for 354s! [napi/eth%d-0] RIP: 0010:atl1c_clean_tx+0x142/0x2d0 [atl1c] Patch 1 fixes this in atl1c. atl1e and atl1 (atlx) share the exact same loop shape, reading their own hardware-maintained consumer index with no bounds check either, and are just as reachable from the same kind of PCIe link event. Patches 2 and 3 apply the same guard to each. ==================== Link: https://patch.msgid.link/20260921091334.3571525-1-tamas@rimpianto.com Signed-off-by: Paolo Abeni commit 43e746821f5f5afbbf68e388bf9fbe221e03bfca Author: Gajdos Tamás Date: Mon Sep 21 11:13:34 2026 +0200 net: atl1: fix soft lockup on out-of-range cmb_tpd_next_to_clean read Same issue as atl1c (see the first commit in this series, "net: atl1c: fix soft lockup on out-of-range tpd_cons read"): the hardware can report an out-of-range cmb_tpd_next_to_clean (seen as 0xffff) while the PCIe link/MAC is resetting. An out-of-range value can never be reached and the loop below would spin forever. Treat it as "nothing new to clean" instead. Fixes: f3cc28c797604f ("Add Attansic L1 ethernet driver.") Cc: stable@vger.kernel.org Signed-off-by: Gajdos Tamás Link: https://patch.msgid.link/20260921091334.3571525-4-tamas@rimpianto.com Signed-off-by: Paolo Abeni commit 374bf9e4b90f979e052332c4faca2d745c491a12 Author: Gajdos Tamás Date: Mon Sep 21 11:13:33 2026 +0200 net: atl1e: fix soft lockup on out-of-range hw_next_to_clean read Same issue as atl1c (see the first commit in this series, "net: atl1c: fix soft lockup on out-of-range tpd_cons read"): the hardware can report an out-of-range hw_next_to_clean (seen as 0xffff) while the PCIe link/MAC is resetting. An out-of-range value can never be reached and the loop below would spin forever. Treat it as "nothing new to clean" instead. Fixes: a6a5325239c202 ("atl1e: Atheros L1E Gigabit Ethernet driver") Cc: stable@vger.kernel.org Signed-off-by: Gajdos Tamás Link: https://patch.msgid.link/20260921091334.3571525-3-tamas@rimpianto.com Signed-off-by: Paolo Abeni commit 36c2009d90f2210ef92e6f4f2850e8b57b09e754 Author: Gajdos Tamás Date: Mon Sep 21 11:13:32 2026 +0200 net: atl1c: fix soft lockup on out-of-range tpd_cons read The hardware can report an out-of-range tpd_cons (seen as 0xffff) while the PCIe link/MAC is resetting. An out-of-range value can never be reached and the loop below would spin forever. To avoid a soft lockup treat it as "nothing new to clean" instead. Reproduced on two machines, same NIC (Qualcomm Atheros AR8151 v2.0, 4-port), triggered by rebooting a Mikrotik CCR2004 PCIe card that the ports are directly linked to: - Ubuntu 26.04.1 LTS, kernel 7.0.0-31-generic. The link-flap precursor, before the lockup was captured with a full trace elsewhere: atl1c 0000:05:00.0 enp5s0f0: NETDEV WATCHDOG: CPU: 4: transmit queue 2 timed out 489984 ms atl1c 0000:05:00.0: MAC state machine can't be idle since disabled for 10ms second atl1c 0000:05:00.0: atl1c: enp5s0f0 NIC Link is Up<65535 Mbps Full Duplex> 65535 (0xffff) here is the same value tpd_cons reads back once the loop below gets stuck. - Proxmox VE, kernel 7.0.14-11-pve. Same NIC/trigger, this time caught by the soft lockup watchdog with a full stack trace: watchdog: BUG: soft lockup - CPU#12 stuck for 354s! [napi/eth%d-0:329] CPU: 12 UID: 0 PID: 329 Comm: napi/eth%d-0 Tainted: P O L 7.0.14-11-pve #1 PREEMPT(lazy) RIP: 0010:atl1c_clean_tx+0x142/0x2d0 [atl1c] Call Trace: __napi_poll+0x32/0x1e0 napi_threaded_poll_loop+0x286/0x2e0 napi_threaded_poll+0xfd/0x140 kthread+0xf7/0x130 ret_from_fork+0x2da/0x3a0 ret_from_fork_asm+0x1a/0x30 Fixes: 43250ddd75a35d ("atl1c: Atheros L1C Gigabit Ethernet driver") Cc: stable@vger.kernel.org Signed-off-by: Gajdos Tamás Link: https://patch.msgid.link/20260921091334.3571525-2-tamas@rimpianto.com Signed-off-by: Paolo Abeni commit 47c73a43c1de51ed54b621d570c5cdf20549c5b7 Author: Mika Westerberg Date: Tue Sep 22 13:59:39 2026 +0300 thunderbolt: stream: Announce support for FMODE_NOWAIT Commit 42bc6935339b ("thunderbolt: stream: Support IOCB_NOWAIT in non-blocking I/O as well") added support for IOCB_NOWAIT but forgot to actually announce it as part of the file->f_mode. Add this now so users such as io_uring can actually take advantage of IOCB_NOWAIT. Fixes: 42bc6935339b ("thunderbolt: stream: Support IOCB_NOWAIT in non-blocking I/O as well") Signed-off-by: Mika Westerberg commit 00efbbd40bd5fd92c67b7cf1aab8904fa59a96f6 Author: David Dai Date: Fri Sep 18 16:11:55 2026 -0500 bonding: crypto offload enabled, non-offload slave failover, rekey failed Create a bonding device (i.e. bond0) in active-backup mode, 2 slaves. Active slave: offload capable interface (i.e. eth1), primary interface. Backup slave: non-offload capable interface(i.e. eth2). Configure strongswan service swantl.conf child SA "hw_offload = crypto" Start strongswan service IPSec Crytpo Offload is enabled on top of bond0. i.e. ip xfrm state |grep offload crypto offload parameters: dev bond0 dir out mode crypto crypto offload parameters: dev bond0 dir in mode crypto Active slave eth1 takes adavantage of IPSec Crypto Offload capability. If active slave eth1 is down for any reason (i.e. eth1 link down): ip link set down dev eth1 non-offload capable interface eth2 failover to becomes active slave. The existing SAs can continue use software IPsec after failover. Traffic still keeps going properly. However if eth1 link had not recovered yet, strongswan service does new child SA rekey, or uses swanctl command to do new child SA rekey, it will fail because active slave eth2 doesn't support crypto offload. In bond_ipsec_add_sa routine, it returns -EINVAL now, which is treated as fatal error by xfrm_dev_state_add routine in kernel xfrm. To make the non-offload active slave survive the child SA rekey, need to make bond_ipsec_add_sa routine returns -EOPNOTSUPP instead when active slave doesn't support IPsec Crypto offload, the xfrm will gracefully fallback to create new SA using Software IPsec. Network traffic can keep going. After offload capable interface eth1 link is up, becomes active slave, next time strongswan child SA rekey will create a new SA which enables crypto offload again. Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves") Signed-off-by: David Dai Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260918211155.1664493-1-zdai@linux.ibm.com Signed-off-by: Paolo Abeni commit 45585c3aa285854face65293acc95eff73063d6d Author: Pengpeng Hou Date: Sun Sep 20 11:43:29 2026 +0800 drm/imagination: clamp freelist reconstruction requests The firmware reconstruction count controls accesses to the request's fixed freelist ID array and the copy into the fixed response array. Neither access currently bounds the count to those protocol arrays. Clamp the count to the request capacity, which is shared by the response layout, and use that count consistently for reconstruction and response publication. Keep the firmware recovery exchange instead of dropping an oversized request without a response, as discussed with the firmware maintainer. The issue was found by our static-analysis tool. Fixes: 6eedddab733b ("drm/imagination: Implement free list and HWRT create and destroy ioctls") Assisted-by: gpt 5 Signed-off-by: Pengpeng Hou Reviewed-by: Alessio Belle Link: https://patch.msgid.link/20260920034329.16614-1-hppiscas@163.com Signed-off-by: Brajesh Gupta commit 0a8224058a5835297dcf4a46bbcd16f77a9fe424 Author: Brajesh Gupta Date: Tue Sep 22 09:56:56 2026 +0530 drm/imagination: Fix page count for page table for map() interface The GPU virtual start address wasn't included in the calculation for the amount of page tables required for mapping a BO object in map() interface. It resulted in map failure later due to not enough pages at L0/L1 level. Update pvr_mmu_op_context_create() interface to pass device address as well to allow correct calculation for page table memory. If L0 tables cover 2MB (0x200000), the range defined by device address 0x80001ff000 (general heap at 2MB - 4KB) and size 0x2000 (two 4KB pages) requires two L0 pages to be mapped, but without the base address a range of 0x2000 computes to a single L0 page which is not enough. Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Reviewed-by: Alexandru Dadu Reviewed-by: Alessio Belle Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260922-mmu_fix-v4-2-12f1a871456a@imgtec.com Signed-off-by: Brajesh Gupta commit 7b824c293a6b56de8285a97984c507cba56bc4c4 Author: Brajesh Gupta Date: Tue Sep 22 09:56:55 2026 +0530 drm/imagination: Propagate map failures correctly from pvr_mmu_map_sgl() Map failure from pvr_mmu_map_sgl() interface was not returned correctly to pvr_mmu_map() interface. This resulted in pvr_mmu_map() interface to continue instead of returning an error to caller. Fix it by returning a proper error code from pvr_mmu_map_sgl() interface. Call stack for crash: [ 1179.286237] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [ 1179.295067] Mem abort info: [ 1179.297877] ESR = 0x0000000096000004 [ 1179.301656] EC = 0x25: DABT (current EL), IL = 32 bits [ 1179.306987] SET = 0, FnV = 0 [ 1179.310048] EA = 0, S1PTW = 0 [ 1179.313198] FSC = 0x04: level 0 translation fault [ 1179.318096] Data abort info: [ 1179.320993] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1179.326483] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1179.331546] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1179.336895] user pgtable: 4k pages, 48-bit VAs, pgdp=000000009822a000 [ 1179.343402] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000 [ 1179.350243] Internal error: Oops: 0000000096000004 [#2] SMP [ 1179.355908] Modules linked in: powervr gpu_sched drm_shmem_helper drm_gpuvm drm_exec xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils dwc3_am62 at24 sa2ul sha512 libsha512 sha256 authenc sch_fq_codel fuse dm_mod ipv6 [ 1179.378992] CPU: 1 UID: 1000 PID: 680 Comm: deqp-vk Tainted: G D 6.17.0 #1 PREEMPT [ 1179.388120] Tainted: [D]=DIE [ 1179.390994] Hardware name: Texas Instruments AM625 SK (DT) [ 1179.396467] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1179.403415] pc : pvr_mmu_op_context_unmap_curr_page+0x6c/0x134 [powervr] [ 1179.410140] lr : pvr_mmu_op_context_unmap_curr_page+0x58/0x134 [powervr] [ 1179.416848] sp : ffff8000839ab8c0 [ 1179.420153] x29: ffff8000839ab8c0 x28: 0000000000000001 x27: 000000008f386000 [ 1179.427283] x26: ffff000016d1df98 x25: 0000000000247000 x24: 00000000000001e6 [ 1179.434413] x23: 0000000000000002 x22: 000000000000ffff x21: 0000000000000247 [ 1179.441540] x20: 0000000000000245 x19: ffff000016d1df60 x18: 0000000000000002 [ 1179.448668] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 1179.455793] x14: 0000000000060810 x13: ffff80007fffffff x12: ffff000004190480 [ 1179.462921] x11: ffff8000853f7000 x10: ffff8000811ae000 x9 : ffff0000041900b8 [ 1179.470051] x8 : 0000000000000000 x7 : 00000000990c4001 x6 : 0000000000000007 [ 1179.477177] x5 : ffff000016d1df60 x4 : 0000000000000000 x3 : ffff00000a7d8000 [ 1179.484306] x2 : 00000000000001ff x1 : 0000000000000000 x0 : 0000000000000000 [ 1179.491433] Call trace: [ 1179.493872] pvr_mmu_op_context_unmap_curr_page+0x6c/0x134 [powervr] (P) [ 1179.500582] pvr_mmu_map+0x31c/0x388 [powervr] [ 1179.505027] pvr_vm_gpuva_map+0x40/0x88 [powervr] [ 1179.509732] __drm_gpuvm_sm_map+0x250/0x44c [drm_gpuvm] [ 1179.514952] drm_gpuvm_sm_map+0x48/0x5c [drm_gpuvm] [ 1179.519822] pvr_vm_bind_op_exec+0x64/0x70 [powervr] [ 1179.524785] pvr_vm_map+0x1f8/0x2a8 [powervr] [ 1179.529142] pvr_ioctl_vm_map+0x12c/0x188 [powervr] [ 1179.534018] drm_ioctl_kernel+0xb8/0x128 [ 1179.537941] drm_ioctl+0x21c/0x4ec [ 1179.541337] __arm64_sys_ioctl+0xac/0x108 [ 1179.545344] invoke_syscall+0x44/0x100 [ 1179.549091] el0_svc_common.constprop.0+0x40/0xe0 [ 1179.553790] do_el0_svc+0x1c/0x28 [ 1179.557106] el0_svc+0x34/0xf0 [ 1179.560159] el0t_64_sync_handler+0xd0/0xe4 [ 1179.564334] el0t_64_sync+0x198/0x19c [ 1179.567996] Code: 54000300 35000360 f9402261 79409a62 (f9400421) [ 1179.574081] ---[ end trace 0000000000000000 ]--- Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Reviewed-by: Alexandru Dadu Reviewed-by: Alessio Belle Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260922-mmu_fix-v4-1-12f1a871456a@imgtec.com Signed-off-by: Brajesh Gupta commit 3872cc6b92940af0f73c6f9a45d65300492d648d Author: Oleg Keri Date: Wed Sep 23 14:56:04 2026 +0200 arm64: topology: fix arch_freq_get_on_cpu() overflow above 4.19 GHz arch_freq_get_on_cpu() computes the product of the frequency scale and the reference frequency as a u64, but assigns it to an unsigned int before shifting it back down: freq = scale * arch_scale_freq_ref(cpu); freq >>= SCHED_CAPACITY_SHIFT; The product is truncated to 32 bits before the shift, so the result wraps once arch_scale_freq_ref() exceeds 2^32 / SCHED_CAPACITY_SCALE, i.e. 4194304 kHz. On a Snapdragon X2 Elite (Glymur) laptop, whose boost OPP is 4723200 kHz, cpuinfo_avg_freq reports 524283 kHz instead of ~4723200 kHz while the CPU demonstrably runs at the boost frequency: a fixed workload completes in 1.72 s at the 4723200 kHz OPP versus 2.01 s at 4032000 kHz, matching the 1.171 frequency ratio. Shift the u64 product and narrow only at the return. Fixes: 16d1e27475f6 ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu") Reviewed-by: Dietmar Eggemann Signed-off-by: Oleg Keri Signed-off-by: Will Deacon commit e47a1958e12abc3a17b5231a4f21c8f1bf662e08 Author: Yuqi Xu Date: Sat Sep 19 16:45:27 2026 +0800 net: ipconfig: bound DHCP option construction ic_dhcp_init_options() appends the hostname (option 12), vendor-class (option 60) and client-ID (option 61) options into the fixed 312-byte bootp_pkt.exten[] buffer. Only the client-ID branch checked the remaining space; the hostname and vendor-class writes were unbounded. A 64-byte hostname together with the maximum 252-byte dhcpclass= identifier needs 18 + (2 + 64) + (2 + 252) = 338 of the 312 available bytes even before the terminating END marker, so the vendor-class memcpy runs past the end of exten[]. With CONFIG_FORTIFY_SOURCE this is reported as a field-spanning write and, when the kernel is booted with panic_on_warn=1, aborts boot with a panic. Route the optional options through a common helper that makes sure the option, its 2-byte header and the END marker all fit and drops an option that would not. Configurations with short options keep sending exactly the same bytes as before. Fixes: 130c0f47fdf9 ("ipconfig: send host-name in DHCP requests") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Reviewed-by: Simon Horman Link: https://patch.msgid.link/7808dfbfa2162dfd0b19f59aff5742d6e0db2abb.1789798023.git.xuyuqiabc@gmail.com Signed-off-by: Paolo Abeni commit 1fef81669147d63eb8c5d3627d54eadc21173a0b Author: Andrea Parri Date: Wed Sep 23 16:36:32 2026 +0200 arm64: mm: Fix the break-before-make flush range for erratum 2645198 modify_prot_start_ptes() performs the break-before-make TLB invalidation required by erratum 2645198 with __flush_tlb_range(), whose third argument is the end address of the range. It passes nr * PAGE_SIZE instead of addr + nr * PAGE_SIZE, so __do_flush_tlb_range() computes the page count as (nr * PAGE_SIZE - addr) >> PAGE_SHIFT. For addr > nr * PAGE_SIZE that subtraction underflows, the page count exceeds the batching limit and the flush degenerates to flush_tlb_mm(), so a single-page mprotect broadcasts an ASID-wide invalidation and a full-range mmu notifier call. For addr <= nr * PAGE_SIZE only [addr, nr * PAGE_SIZE) is invalidated, and when the cleared batch starts below nr * PAGE_SIZE the tail is left in the TLB. The workaround then no longer covers the whole batch, and for addr == nr * PAGE_SIZE the flush is empty. On affected Cortex-A715 CPUs, this can corrupt ESR_ELx and FAR_ELx on the next instruction abort caused by a permission fault. Pass addr + nr * PAGE_SIZE as the end address. Fixes: 7efa1cd5f89b5 ("arm64: add batched versions of ptep_modify_prot_start/commit") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Andrea Parri Reviewed-by: Dev Jain Signed-off-by: Will Deacon commit a0bb6fac53fa7cf1cadb487b43d4c9276a6b82e3 Author: Zhan Xusheng Date: Fri Sep 18 21:29:15 2026 +0800 sched/core: Account PSI IRQ time to the execution context, not the scheduling context psi_account_irqtime() has two callers which share rq->psi_irq_time, and they disagree about the context: __schedule() passes the outgoing rq->curr, sched_tick() passes rq->donor. Under proxy execution the donor is blocked on a mutex while rq->curr burns the CPU. The tick charges PSI_IRQ_FULL to the donor's cgroup and advances the timestamp, so the call from __schedule() then finds delta <= 0 and charges nothing. The delta is not counted twice, it lands on the wrong cgroup. Pass rq->curr, which is what the call read before commit af0c8b2bf67b ("sched: Split scheduler and execution contexts") renamed 'curr' to 'donor' across sched_tick(). Without CONFIG_SCHED_PROXY_EXEC the two rq members are a union, so this only changes anything where that option is set, and it depends on EXPERT. Fixes: af0c8b2bf67b ("sched: Split scheduler and execution contexts") Signed-off-by: Zhan Xusheng Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20260918132915.1236312-1-zhanxusheng@xiaomi.com commit af2fb3ee6679b517e2fdbd3ba16ec276a8b74312 Author: Harry Yoo (Meta) Date: Tue Sep 22 12:56:43 2026 +0100 mm/slab: do not wake up kswapd in __kfree_rcu_sheaf() Since kfree_rcu() can be called under pi_lock (a raw spinlock in the scheduler), kfree_rcu() itself should never allocate memory with __GFP_KSWAPD_RECLAIM as waking up kswapd ends up acquiring pi_lock, which leads to a deadlock. Reproducing the issue even intentionally was not straightforward. The set_cpus_allowed_force() path that is called under pi_lock is exercised very rarely, and competing tasks that allocate memory will most likely wake kswapd up. Therefore the existence of the deadlock was verified with a modified kernel that has a lockdep map for waking up kswapd: ====================================================== WARNING: possible circular locking dependency detected 7.2.0-rc1-slab-for-next+ #10 Not tainted ------------------------------------------------------ git/6660 is trying to acquire lock: ffff8e524533c550 (&p->pi_lock){-.-.}-{2:2}, at: _raw_spin_lock_irqsave+0x12/0x20 but task is already holding lock: ffff8e57bffff1a0 (&pgdat->kswapd_wait){....}-{3:3}, at: _raw_spin_lock_irqsave+0x12/0x20 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&pgdat->kswapd_wait){....}-{3:3}: __lock_acquire+0x5a4/0xc50 lock_acquire.part.0+0xb7/0x240 lock_acquire+0x70/0x170 __raw_spin_lock_irqsave+0x44/0x80 _raw_spin_lock_irqsave+0x12/0x20 __wake_up_common_lock+0x31/0xa0 __wake_up+0x20/0x40 kswapd_wakeup_wake+0x7e/0x110 wakeup_kswapd+0x295/0x320 wake_all_kswapds+0xac/0x1a0 __alloc_pages_slowpath.constprop.0+0x282/0xf80 __alloc_frozen_pages_noprof+0x32a/0x360 alloc_slab_page+0x2e/0x160 allocate_slab+0x82/0x420 new_slab+0x52/0xb0 refill_objects+0x13d/0x190 refill_sheaf+0x5d/0xd0 __pcs_replace_empty_main+0x230/0xb10 [...] -> #1 (kswapd_wakeup){-.-.}-{0:0}: __lock_acquire+0x5a4/0xc50 lock_sync.part.0+0x75/0x100 lock_sync+0x36/0x70 might_wakeup_kswapd+0x61/0xa0 __kfree_rcu_sheaf+0x33/0xd90 kvfree_call_rcu+0x1d4/0x3b0 set_cpus_allowed_force+0x163/0x220 cpuset_cpus_allowed_fallback+0x18b/0x240 select_fallback_rq+0x1e6/0x250 [...] -> #0 (&p->pi_lock){-.-.}-{2:2}: check_prev_add+0xe6/0xe00 validate_chain+0x51e/0x6e0 __lock_acquire+0x5a4/0xc50 lock_acquire.part.0+0xb7/0x240 lock_acquire+0x70/0x170 __raw_spin_lock_irqsave+0x44/0x80 _raw_spin_lock_irqsave+0x12/0x20 try_to_wake_up+0x77/0xa90 default_wake_function+0x27/0x60 autoremove_wake_function+0x23/0xb0 __wake_up_common+0xb8/0x170 __wake_up_common_lock+0x51/0xa0 __wake_up+0x20/0x40 kswapd_wakeup_wake+0x7e/0x110 wakeup_kswapd+0x295/0x320 wake_all_kswapds+0xac/0x1a0 __alloc_pages_slowpath.constprop.0+0x282/0xf80 __alloc_frozen_pages_noprof+0x32a/0x360 alloc_slab_page+0x2e/0x160 allocate_slab+0x82/0x420 new_slab+0x52/0xb0 refill_objects+0x13d/0x190 refill_sheaf+0x5d/0xd0 __pcs_replace_empty_main+0x230/0xb10 [...] other info that might help us debug this: Chain exists of: &p->pi_lock --> kswapd_wakeup --> &pgdat->kswapd_wait Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&pgdat->kswapd_wait); lock(kswapd_wakeup); lock(&pgdat->kswapd_wait); lock(&p->pi_lock); *** DEADLOCK *** 3 locks held by git/6660: #0: ffff8e519f0e9e20 (&type->i_mutex_dir_key#6){++++}-{4:4}, at: lookup_slow+0x2d/0x60 #1: ffffffff8a31c460 (kswapd_wakeup){-.-.}-{0:0}, at: kswapd_wakeup_wake+0x4d/0x110 #2: ffff8e57bffff1a0 (&pgdat->kswapd_wait){....}-{3:3}, at: _raw_spin_lock_irqsave+0x12/0x20 [...] Fix this by always avoiding waking up kswapd in __kfree_rcu_sheaf(). Note that there are two paths that might wake up kswapd: 1) __kfree_rcu_sheaf() // __GFP_KSWAPD_RECLAIM might wake up kswapd -> alloc_empty_sheaf(GFP_NOWAIT) 2) __kfree_rcu_sheaf() // Let's say __kfree_rcu_sheaf() doesn't pass GFP_NOWAIT -> alloc_empty_sheaf(__GFP_NOWARN) -> kmalloc_flags() -> slab_alloc_node() -> alloc_from_pcs() -> __pcs_replace_empty_main() // Free a sheaf in an allocation path when the sheaf becomes empty // and refilling the sheaf fails -> free_empty_sheaf() -> slab_free() -> free_to_pcs() -> __pcs_replace_full_main() // However free path always assumes it's safe to wake up kswapd -> alloc_empty_sheaf(GFP_NOWAIT) Drop __GFP_KSWAPD_RECLAIM in both cases. Note that the kfree_rcu() is not the only user of free_to_pcs() path, but it should be fixed as it can be invoked under pi_lock. Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260831-b4-kfree_rcu_hotfix-v1-1-4f0fb882638b%40kernel.org Fixes: ec66e0d59952 ("slab: add sheaf support for batching kfree_rcu() operations") Link: https://lore.kernel.org/linux-mm/20260831143500.x-saxdAs@linutronix.de Assisted-by: LLM # dicovery and verification Signed-off-by: Harry Yoo (Meta) Link: https://patch.msgid.link/20260922-kfree-rcu-dont-wakeup-kswapd-v1-1-42d7e2636f9e@kernel.org Signed-off-by: Vlastimil Babka (SUSE) commit 90c2e97ff8245092039ab7ab7492b34427412c9b Merge: 4da3b7b8b50f3e b61732f47316d4 Author: Jakub Kicinski Date: Wed Sep 23 19:45:33 2026 -0700 Merge tag 'nfc-7.3-rc5' of https://codeberg.org/linux-nfc/linux David Heidelberg says: ==================== NFC fixes for net 7.3-rc5 * tag 'nfc-7.3-rc5' of https://codeberg.org/linux-nfc/linux: nfc: pn533: fix OOB read in pn533_acr122_is_rx_frame_valid() nfc: llcp: fix slab-out-of-bounds reads when logging service names nfc: llcp: fix WKS SAP hijacking via prefix match in nfc_llcp_wks_sap() nfc: llcp: fix -ENOMEM on connect with zero-length service name nfc: st21nfca: validate ISO15693 inventory length nfc: fix use-after-free in nfc_get_local_general_bytes nfc: trf7970a: power down on startup RX gain failure nfc: llcp: fix sdreq TLV list leak on parse/alloc/send failure nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc() nfc: virtual_ncidev: Add missing ioctl compat handler selftests/nci: Fix out-of-bounds store on thread join selftests: nci: Fix uninitialized family ID on missing attribute nfc: llcp: Fix race condition in accept_queue lifecycle selftests: nci: Correct pthread_create return value check nfc: port100: reject frames whose declared length exceeds the received data nfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm() nfc: st21nfca: validate received frame size nfc: nfcmrvl: validate helper command length before pull ==================== Link: https://patch.msgid.link/adeaccc1-cc04-4bb9-a28a-61a61d75ba14@ixit.cz Signed-off-by: Jakub Kicinski commit 4da3b7b8b50f3e2fde54a4c18a82a8e3f6223910 Author: Norbert Szetei Date: Mon Sep 21 17:03:57 2026 +0200 net: xps: reject an out of range traffic class Only the entries below dev->num_tc are valid in dev->tc_to_txq[], and dev->prio_tc_map[] may only name classes below it. netdev_set_num_tc() lowers dev->num_tc without touching either array. netdev_txq_to_tc() walks all TC_MAX_QUEUE slots and netdev_get_prio_tc_map() returns the entry as it stands, so a leftover entry is handed out as a traffic class >= dev->num_tc. Taking that class from netdev_txq_to_tc(), __netif_set_xps_queue() rejects only a negative one and indexes an XPS map sized for dev->num_tc classes: tci = j * num_tc + tc; RCU_INIT_POINTER(new_dev_maps->attr_map[tci], map); attr_map[] holds nr_ids * num_tc entries and j runs over the ids named in the mask, so a class that is not below num_tc pushes tci past the end of the map for the last ids and the store overruns it. Any caller that lowers num_tc leaves such entries behind, and mqprio_destroy() tears down with netdev_set_num_tc(dev, 0) rather than netdev_reset_tc(). After mqprio with 8 classes then 1, tc_to_txq[1..7] still describe txq 1..7. The splat is from an XPS write to txq 2 on a veth with 8 rx queues: attr_map[] has 8 * 1 entries, tci = j + 2, and j == 6 stores one past the end of the 88-byte map: BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue (net/core/dev.c:2954) Write of size 8 at addr ffff88813016bc58 by task xps_oob/634 __netif_set_xps_queue (net/core/dev.c:2954) xps_rxqs_store (net/core/net-sysfs.c:1880) netdev_queue_attr_store (net/core/net-sysfs.c:1390) Allocated by task 634: __kmalloc_noprof (mm/slub.c:5439) __netif_set_xps_queue (net/core/dev.c:2937) The buggy address is located 0 bytes to the right of allocated 88-byte region [ffff88813016bc00, ffff88813016bc58) Reject a class the map has no room for. Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes") Signed-off-by: Norbert Szetei Link: https://patch.msgid.link/162DD16F-54C6-444A-9E09-0B8CB3D591F2@doyensec.com Signed-off-by: Jakub Kicinski commit 481506a756dcd828ef42391cb08f38d8d96d38fc Author: Sanghyun Park Date: Fri Sep 18 12:26:58 2026 +0900 vxlan: use one headroom snapshot for neighbour replies vxlan_na_create() samples LL_RESERVED_SPACE() to size the reply skb and then samples it again to reserve headroom. A concurrent vxlan_changelink() can update needed_headroom between the two reads, creating a TOCTOU race. The second value can exceed the allocation and make the Ethernet header write out of bounds. The race is reproducible on the unpatched kernel. It occurred when vxlan_na_create() generated a neighbour reply while vxlan_changelink() changed the link headroom. KASAN caught a four-byte write two bytes beyond a 704-byte skbuff_small_head allocation. Snapshot the headroom once and use that value for both allocation and reservation. Fixes: 4b29dba9c085 ("vxlan: fix nonfunctional neigh_reduce()") Signed-off-by: Sanghyun Park Link: https://patch.msgid.link/20260918032842.502409-2-sanghyun.park.cnu@gmail.com Signed-off-by: Jakub Kicinski commit 0f2fd31f63c65c409bd336af3a42d478a9207c1f Author: Gilberto Conde Date: Mon Sep 21 10:34:26 2026 +0100 net: usb: qmi_wwan: add Quectel EG120K-EA Add support for the Quectel EG120K-EA LTE Cat.12 module (USB ID 2c7c:030b). Its QMI interface (interface 4) uses class/subclass/protocol ff/ff/ff like the other recent Quectel modules, so match it the same way. The product ID is shared with the EM060K, which the option driver already knows and uses to claim the serial interfaces. Without a qmi_wwan entry the data interface is left unbound. Tested on a GL.iNet GL-X2000, where the module is soldered down and enumerates at SuperSpeed: cdc-wdm0 and wwan0 appear and ModemManager brings up a data session. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2c7c ProdID=030b Rev= 5.04 S: Manufacturer=Quectel S: Product=EG120K-EA S: SerialNumber=45546267 C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#=12 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=89(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms Signed-off-by: Gilberto Conde Link: https://patch.msgid.link/20260921093426.2870266-1-gilbertorconde@gmail.com Signed-off-by: Jakub Kicinski commit a3f315be9d30eeb6938d11fa17fd4b32d52f7c42 Author: Xuanqiang Luo Date: Mon Sep 21 11:18:59 2026 +0800 ip_gre: Reject enabling collect metadata through changelink ipgre_netlink_parms() can enable collect_md on an existing GRE, GRETAP or ERSPAN device. Unlike newlink, changelink does not enforce metadata tunnel uniqueness. Converting a non-metadata device can therefore replace the metadata receive entry for another device of the same type in the same netns. Deleting either device then clears the shared entry, breaking metadata receive lookup for the surviving device. If parameter validation fails after collect_md is set, deleting the modified device can also clear an entry it never owned. Reject enabling metadata mode in both changelink callbacks before any encapsulation or tunnel parameters are modified. Allow requests that repeat the metadata attribute on an existing metadata device. Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.") Signed-off-by: Xuanqiang Luo Reviewed-by: Ido Schimmel Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260921031859.9283-1-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski commit 4bdee8060d1e4581624e68fbd369b1afb14df4bc Author: Myeonghun Pak Date: Mon Sep 21 20:09:14 2026 -0400 net: airoha: npu: cancel wdt_work after releasing the WDT IRQ airoha_npu_remove() calls cancel_work_sync() on each core's wdt_work, but the watchdog IRQ that queues it is requested with devm_request_irq() and is freed only after .remove() returns. airoha_npu_wdt_handler() can therefore schedule_work() again once the cancel has returned. struct airoha_npu, which contains the work, is devm_kzalloc()'d and is freed in that same unwind, so the late work dereferences freed memory. Register the work with devm_work_autocancel() before devm_request_irq() and drop .remove(). Devres runs in reverse order, so the IRQ is freed before cancel_work_sync(), including when probe fails. A cancel left in .remove() cannot get that order. Initializing the work first also stops a pending watchdog interrupt from queuing an uninitialized work item. Probe currently calls INIT_WORK() only after devm_request_irq(). This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 23290c7bc190 ("net: airoha: Introduce Airoha NPU support") Cc: stable@vger.kernel.org # 6.15+ Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260922000914.542068-1-mhun512@gmail.com Signed-off-by: Jakub Kicinski commit fc05ea1b941148d6d72f8cefa64e11e7119bae8b Merge: 87cd6b717e4069 d64e277b955be4 Author: Jakub Kicinski Date: Wed Sep 23 19:07:06 2026 -0700 Merge branch 'net-bcmgenet-collection-of-bug-fixes' Florian Fainelli says: ==================== net: bcmgenet: Collection of bug fixes This patch series contains a collection of bug fixes found during a LLM-assisted coding session. ==================== Link: https://patch.msgid.link/20260921220021.281418-1-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski commit d64e277b955be4506931802837499b62c8f3968a Author: Florian Fainelli Date: Mon Sep 21 15:00:21 2026 -0700 net: bcmgenet: mask DMA_TIMEOUT_MASK when reading DMA_RING0_TIMEOUT bcmgenet_get_coalesce() reads DMA_RING0_TIMEOUT to calculate rx_coalesce_usecs without masking out bits outside DMA_TIMEOUT_MASK (16 bits). If upper bits are non-zero or contain status/flags, the computed value of rx_coalesce_usecs returned to userspace via ethtool becomes corrupted. Mask the register read with DMA_TIMEOUT_MASK before computing the timeout in microseconds. Fixes: 4a29645bfe6c ("net: bcmgenet: Implement RX coalescing control knobs") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260921220021.281418-6-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski commit 273941c85fc2632cd3e56ddff737b9245de7697d Author: Florian Fainelli Date: Mon Sep 21 15:00:20 2026 -0700 net: bcmgenet: validate Ethernet address in bcmgenet_set_mac_addr bcmgenet_set_mac_addr() did not check whether the provided MAC address is a valid Ethernet address before applying it. Userspace could configure an invalid address (such as all zeroes or a multicast address) while the interface is down. Add a call to is_valid_ether_addr() and return -EADDRNOTAVAIL if the MAC address is not valid. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260921220021.281418-5-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski commit cbbc1aee7776c7fa1d89e6cb963a23e58c495dca Author: Florian Fainelli Date: Mon Sep 21 15:00:19 2026 -0700 net: bcmgenet: do not skip WoL power up on GENET V1 bcmgenet_power_up() had an early check for bcmgenet_has_ext(priv) before dispatching by power mode. GENET V1 does not have the EXT block (unlike GENET V2+), which causes bcmgenet_power_up() to immediately return 0. As a consequence, when waking up from GENET_POWER_WOL_MAGIC on GENET V1, bcmgenet_wol_power_up_cfg() is never invoked to disable the WoL clock, clear wake event masks, and restore normal PHY and MAC operations. Move the bcmgenet_has_ext() checks to the GENET_POWER_PASSIVE and GENET_POWER_CABLE_SENSE cases where the EXT registers are actually accessed, allowing GENET_POWER_WOL_MAGIC cleanup to execute on all hardware versions. Fixes: c3ae64ae0c08 ("net: bcmgenet: handle GENET_POWER_WOL_MAGIC") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260921220021.281418-4-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski commit 3aeaa609fda19c09d5298c9fedaaa3b6229601b5 Author: Florian Fainelli Date: Mon Sep 21 15:00:18 2026 -0700 net: bcmgenet: initialize u64 stats seq counter for all queues bcmgenet_gstrings_stats statically defines ethtool statistics for queues 0 through GENET_MAX_MQ_CNT (4). However, bcmgenet_probe() only initialized the u64_stats_sync seq counter up to priv->hw_params->rx_queues and priv->hw_params->tx_queues. Since priv->hw_params->rx_queues is 0 across all hardware versions (and priv->hw_params->tx_queues is 0 on GENET V1), rings 1..4 have uninitialized u64_stats_sync structures. When ethtool -S is run on 32-bit kernels, bcmgenet_get_ethtool_stats() reads stats from rx_rings[1..4], causing lockdep warnings due to the uninitialized sequence counters. Initialize the sequence counters for all GENET_MAX_MQ_CNT + 1 queues. Fixes: ffc2c8c4a714 ("net: bcmgenet: Initialize u64 stats seq counter") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260921220021.281418-3-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski commit 0e2bec77ea62895416600c90588f593516572bca Author: Florian Fainelli Date: Mon Sep 21 15:00:17 2026 -0700 net: bcmgenet: fix 64-bit RTNL stats reading in ethtool on 32-bit systems When bcmgenet was converted to 64-bit statistics, STAT_RTNL members were switched to point into struct rtnl_link_stats64, whose fields are 64-bit (__u64) regardless of architecture. However, bcmgenet_get_ethtool_stats() retained a legacy check: if (sizeof(unsigned long) != sizeof(u32) && s->stat_sizeof == sizeof(unsigned long)) On 32-bit systems, sizeof(unsigned long) == sizeof(u32), causing this condition to evaluate to false. As a result, 64-bit RTNL stats fields were read via *(u32 *)p. On 32-bit Big-Endian systems (such as MIPS BE), this reads the high 32 bits and returns 0 until the counter exceeds 4GB; on 32-bit Little-Endian systems (such as 32-bit ARM), the value is truncated to 32 bits. Fix this by checking if s->stat_sizeof == sizeof(u64) so 64-bit fields are always read as 64-bit values. Fixes: 59aa6e3072aa ("net: bcmgenet: switch to use 64bit statistics") Reviewed-by: Nicolai Buchwitz Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20260921220021.281418-2-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski commit 87cd6b717e4069dca34e0866e57eaeb44d3b173e Author: Yuya Kusakabe Date: Tue Sep 22 05:49:56 2026 +0900 net: ipv6: keep room for the mac header in dst_dev_overhead() The seg6, ioam6 and rpl lwtunnels size their skb_cow_head() request as the length they are about to push plus dst_dev_overhead(), then push the new headers and rebuild the mac header below them with skb_mac_header_rebuild(). That rebuild needs skb->mac_len of headroom, but dst_dev_overhead() leaves LL_RESERVED_SPACE() of the egress device, 16 bytes for plain Ethernet. Where the mac header is longer than that, as it is on ingress through a VLAN device with reorder_hdr off, the rebuild runs out of room: skb_set_mac_header(skb, -skb->mac_len) computes a negative offset, stores it unchecked in the u16 skb->mac_header, and the memmove that follows writes skb->mac_len bytes about 64 KB past skb->head. Forwarding plain ping6 traffic through such a device reproduces it on all five seg6 encapsulation modes and on the rpl and ioam6 inline paths; skb->mac_header comes back as 65534 on a 704-byte head. Return the larger of the two. The helper already returns skb->mac_len when it has no dst, so this only makes the other branch agree, and it covers every caller rather than each call site in turn. Fixes: 40475b63761a ("net: ipv6: seg6_iptunnel: mitigate 2-realloc issue") Fixes: dce525185bc9 ("net: ipv6: ioam6_iptunnel: mitigate 2-realloc issue") Fixes: 985ec6f5e623 ("net: ipv6: rpl_iptunnel: mitigate 2-realloc issue") Suggested-by: Andrea Mayer Signed-off-by: Yuya Kusakabe Reviewed-by: Justin Iurman Reviewed-by: Gabriel Goller Reviewed-by: Eric Dumazet Reviewed-by: Andrea Mayer Link: https://patch.msgid.link/20260922-seg6-maclen-headroom-v3-1-7b2f982ef79d@gmail.com Signed-off-by: Jakub Kicinski commit 0a7822e34a0bfde31b194ac3da3253e5032b44cc Author: Lorenzo Bianconi Date: Mon Sep 21 16:46:18 2026 +0200 net: stmmac: clear stale buf->page after recycling on skb build failure In stmmac_rx(), when napi_build_skb() fails the descriptor page is recycled back to the page pool with page_pool_recycle_direct(), but buf->page is left pointing at the recycled page, unlike every other consumption site in the function which clears the pointer after handing the page away. With the stale pointer stmmac_rx_refill() skips the replacement allocation and programs the already-recycled page back into the RX descriptor. Clear buf->page on the napi_build_skb() failure path to keep the buffer lifecycle consistent with the other consumption sites. Fixes: df542f669307 ("net: stmmac: Switch to zero-copy in non-XDP RX path") Signed-off-by: Lorenzo Bianconi Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260921-stmmac-fix-napi-build-skb-error-v1-1-3d54bf6d9bb6@oss.qualcomm.com Signed-off-by: Jakub Kicinski commit 4eb3f195ef08c5acaed87958297e41cc49588dde Author: Ivan Delalande Date: Fri Sep 18 15:47:15 2026 -0700 tg3: use random MAC address when tg3_get_device_address fails Some of the tg3 NICs we use (BCM57762) reset the SRAM MAC address to the placeholder address on link flaps, tg3_chip_reset, etc. We've typically fixed it from userspace, but since e4c00ba7274b ("tg3: replace placeholder MAC address with device property") was merged, tg3 just fails probe as we don't have a way to get it through the generic device_get_mac_address infrastructure as fallback on our systems. Make the driver assign a random address in this condition instead of being fatal for probe. Set deferred_probe_reason through dev_warn_probe if the address isn't yet available from the provider. Fixes: e4c00ba7274b ("tg3: replace placeholder MAC address with device property") Suggested-by: Jakub Kicinski Link: https://lore.kernel.org/netdev/20260909191751.651aa5c4@kernel.org/ Signed-off-by: Ivan Delalande Link: https://patch.msgid.link/20260918224715.GA654128@visor Signed-off-by: Jakub Kicinski commit d8b6529e80bcb4fb8177121404cbb3377acaebd2 Author: Zijie Huang Date: Mon Sep 21 01:36:19 2026 +0800 net: arp: terminate device name before lookup The ARP ioctl copies a user-provided struct arpreq into a stack object. Its arp_dev field may contain IFNAMSIZ bytes without a NUL terminator. Such input is passed to dev_get_by_name_rcu() or __dev_get_by_name(), where strcmp() can read past the end of the stack object when a matching alternative interface name exists. Terminate the field before the lookup to prevent the out-of-bounds read. Fixes: 36fbf1e52bd3 ("net: rtnetlink: add linkprop commands to add and delete alternative ifnames") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zijie Huang Signed-off-by: Ren Wei Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/fabf02a70787d17299e4b3153eadffaf20d154b3.1789910973.git.milkory@outlook.com Signed-off-by: Jakub Kicinski commit 8110ba09777873443db286b3cbb89b0e6311c554 Author: Johan Almbladh Date: Wed Sep 23 12:51:58 2026 +0200 bpf: Fix BSWAP 32 and 16 on MIPS64 The 16/32-bit byteswap implementations for MIPS64r1 and earlier do not have an explicit zero extension afterwards. The input is first sign-extended to 64 bits, and the byteswap sequence can then leave the result sign-extended depending on the value of the low bits. Add the missing zero-extension. Found with test_bpf on MIPS64r1 emulated by QEMU. Fixes: fbc802de6b10 ("mips, bpf: Add new eBPF JIT for 64-bit MIPS") Signed-off-by: Johan Almbladh Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260923105158.3514342-2-johan.almbladh@anyfinetworks.com commit db762fd96be225bd06161c9631160c755d891693 Author: Johan Almbladh Date: Wed Sep 23 12:51:57 2026 +0200 bpf: Fix immediate JMP JEQ/JNE on MIPS32 An addu instruction was emitted instead of addiu, causing the immediate value 1 to be interpreted as register $at. This made the comparison result invalid when the immediate operand was negative. Note that $at is mapped to BPF_REG_AX, which is used for constant blinding. Fix the instruction to use the immediate form. Found with test_bpf on MIPS32r1 emulated by QEMU. Fixes: eb63cfcd2ee8 ("mips, bpf: Add eBPF JIT for 32-bit MIPS") Signed-off-by: Johan Almbladh Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260923105158.3514342-1-johan.almbladh@anyfinetworks.com commit 89a8a1eef2d441b7825a6c0116ce817235a7ffe6 Author: Jonas Jelonek Date: Fri Sep 18 21:19:55 2026 +0000 net: mdio: realtek-rtl9300: fix RTL931x C22 extended page selection The RTL931x indirect access engine has a separate nine-bit extended page field. The driver leaves it at zero, and otto_emdio_run_cmd() therefore programs extended page zero for every Clause 22 transaction. This overrides page selection made through PHY register 30, causing accesses to private PHY pages to hit extended page zero instead. Set the field to its 0x1ff "do not change" value for RTL931x Clause 22 reads and writes. This preserves extended page selection made through PHY register 30 and restores access to its private register pages. Fixes: 5ebdcac59aff ("net: mdio: realtek-rtl9300: Add support for RTL931x") Signed-off-by: Jonas Jelonek Acked-by: Markus Stockhausen Link: https://patch.msgid.link/20260918211955.3955777-1-jonas@jonasjelonek.de Signed-off-by: Jakub Kicinski commit d22609f3d13fc5baacd92c222731b03c593401db Author: Hui Peng Date: Mon Sep 21 04:59:20 2026 +0000 fou: reject omitted FOU_ATTR_IPPROTO on FOU_ENCAP_DIRECT Commit 7a9bc9e3f423 ("fou: Don't allow 0 for FOU_ATTR_IPPROTO.") added NLA_POLICY_MIN(NLA_U8, 1) to fou_nl_policy[FOU_ATTR_IPPROTO], which rejects an explicitly supplied FOU_ATTR_IPPROTO == 0 attribute with -ERANGE. However, FOU_ATTR_IPPROTO is an optional netlink attribute. When a user sends FOU_CMD_ADD with FOU_ATTR_TYPE set to FOU_ENCAP_DIRECT and omits FOU_ATTR_IPPROTO entirely, nla_policy validation succeeds and parse_nl_config() leaves cfg->protocol as 0 (from memset(cfg, 0, sizeof(*cfg))). fou_create() then creates a FOU_ENCAP_DIRECT socket with fou->protocol == 0. In fou_udp_recv(), returning -fou->protocol to udp_queue_rcv_one_skb() triggers IP protocol resubmission when fou->protocol > 0, whereas returning 0 tells the UDP tunnel layer that the skb was consumed without freeing it. When fou->protocol == 0, every packet received on the socket returns 0 from fou_udp_recv() and leaks the sk_buff. Reject FOU_ENCAP_DIRECT when !cfg->protocol in fou_create() so that creating a direct encapsulation port without FOU_ATTR_IPPROTO fails with -EINVAL while leaving FOU_CMD_DEL and FOU_CMD_GET (which share parse_nl_config()) unaffected. Tested in QEMU against Linux 7.3.0-rc3 by sending a FOU_CMD_ADD Generic Netlink request with FOU_ATTR_PORT = 5555 and FOU_ATTR_TYPE = FOU_ENCAP_DIRECT while omitting FOU_ATTR_IPPROTO. On the unfixed kernel, FOU_CMD_ADD succeeds (err = 0), FOU_CMD_GET reports fou->type = 1 and fou->protocol = 0, and sending 4000 UDP packets to 127.0.0.1:5555 leaks all 4000 sk_buffs (SUnreclaim in /proc/meminfo grows from 41456 kB to 59008 kB, +17552 kB); with this patch applied, FOU_CMD_ADD is rejected with -EINVAL (-22). Fixes: 23461551c006 ("fou: Support for foo-over-udp RX path") Fixes: 7a9bc9e3f423 ("fou: Don't allow 0 for FOU_ATTR_IPPROTO.") Cc: stable@vger.kernel.org Signed-off-by: Hui Peng Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260921045920.1613098-1-benquike@gmail.com Signed-off-by: Jakub Kicinski commit 6b491af01aa5c0633a580e3b11bc7277adc903b2 Author: Nicolo Giuliani Date: Mon Sep 21 05:56:29 2026 +0200 net: dsa: mv88e6xxx: 88E6191X and 88E6193X have no PTP The 88E6191X and 88E6193X are 6393 family devices that share mv88e6393x_ops with the 88E6393X and are marked as ptp_support. Marvell's UMSD driver describes both as parts without AVB (88E6193X: "BGA package - No AVB, No Routing, No Cut-through"), and the register access confirms it on an 88E6193X: the whole indirect AVB register space behind Global 2 registers 0x16 and 0x17 reads zero, for every port, block and address, with the 6390 and with the 6352 command encoding. Writes to the TAI registers, including the clock period register and the TAI global configuration register, read back as zero. Since commit 7e3c18097a70 ("net: dsa: mv88e6xxx: read cycle counter period from hardware") the PTP setup reads the TAI clock period, so the switch fails to probe: mv88e6xxx ...: unexpected cycle counter period of 0 ps Add mv88e6191x_ops, a copy of mv88e6393x_ops without avb_ops and ptp_ops, use it for the 88E6191X and the 88E6193X and stop setting ptp_support for them. The 88E6393X is unchanged. Tested on an 88E6193X (Sophos XGS 107w): the switch probes and the ports work. I do not have an 88E6191X, it is changed because UMSD describes it the same way. Fixes: de776d0d316f ("net: dsa: mv88e6xxx: add support for mv88e6393x family") Suggested-by: Andrew Lunn Signed-off-by: Nicolo Giuliani Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260921-send-net-v2-1-031ad720f140@studio.unibo.it Signed-off-by: Jakub Kicinski commit 2d959c75c27f90e9ec489d18ce5ee6b852ad4741 Author: Hui Peng Date: Mon Sep 21 04:40:25 2026 +0000 ipv6: sr: enforce exact attribute length for SEG6_ATTR_DST In seg6_genl_policy, SEG6_ATTR_DST is defined with .type = NLA_BINARY and .len = sizeof(struct in6_addr). For NLA_BINARY, .len only enforces the maximum payload length and permits shorter payloads (e.g., 0 bytes). When seg6_genl_set_tunsrc() copies sizeof(struct in6_addr) bytes via kmemdup(val, sizeof(*val), GFP_KERNEL), a short SEG6_ATTR_DST attribute triggers a 16-byte out-of-bounds read past skb->tail into uninitialized skb->head memory, which is stored in sdata->tun_src and leaked back to userspace via SEG6_CMD_GET_TUNSRC. Switch SEG6_ATTR_DST in seg6_genl_policy to NLA_POLICY_EXACT_LEN(sizeof(struct in6_addr)) so that generic netlink validation rejects any attribute whose length is not exactly sizeof(struct in6_addr) with -ERANGE. Tested in QEMU against Linux 7.3.0-rc3 by sending a SEG6_CMD_SET_TUNSRC Generic Netlink message with a 0-byte SEG6_ATTR_DST attribute followed by SEG6_CMD_GET_TUNSRC. On the unfixed kernel, SEG6_CMD_SET_TUNSRC succeeds (err = 0) and SEG6_CMD_GET_TUNSRC leaks 16 bytes of uninitialized kernel heap memory (tun_src = 836a61ecc4d25a1042a8d60411cfb378); with this patch applied, SEG6_CMD_SET_TUNSRC is rejected by netlink policy validation with -ERANGE (-34) and tun_src remains zeroed. Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6") Cc: stable@vger.kernel.org Signed-off-by: Hui Peng Reviewed-by: Hangbin Liu Reviewed-by: Justin Iurman Reviewed-by: Andrea Mayer Link: https://patch.msgid.link/20260921044025.1535982-1-benquike@gmail.com Signed-off-by: Jakub Kicinski commit ab7aa05c06ae340e5c7530bb78fa8d23794e460b Author: Ido Schimmel Date: Tue Sep 22 16:12:39 2026 +0300 vrf: Stop corrupting skb->csum when capturing CHECKSUM_COMPLETE packets The VRF device is an Ethernet device but it can have non-Ethernet ports such as IP tunnels. Before the cited commit, capturing packets from such ports on the VRF device resulted in these packets being detected as malformed since they lack an Ethernet header. The cited commit fixed it by pushing a dummy Ethernet header to such packets before the capture and pulling it afterwards. In the case of CHECKSUM_COMPLETE packets it also updated skb->csum with the checksum of the dummy Ethernet header. This is wrong as skb->csum should not include the checksum of the Ethernet header ("checksum of the _whole_ packet as seen by netif_rx()"). This also means that L4 protocols receive a corrupted skb->csum and potentially drop the packet, as is the case with UDP packets whose checksum was completed by software. Fix by removing the unnecessary call to skb_postpush_rcsum(). Fixes: 048939088220 ("vrf: add mac header for tunneled packets when sniffer is attached") Reported-by: Stefano Sasso Closes: https://lore.kernel.org/netdev/CALtE316UtL3x7LL6uxfXzx8rW6AbzYPeDOb478hqJCr_-dj=Wg@mail.gmail.com/ Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Reviewed-by: Eric Dumazet Reviewed-by: Andrea Mayer Link: https://patch.msgid.link/20260922131239.2509494-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski commit 3b4e0b0c008a8c1b474730248cd5b873026c74bd Author: Shihuang Liu Date: Sat Sep 19 21:36:04 2026 +0800 net: skbuff: fix pull-bound underflow in skb_checksum_setup_ipv6() skb_maybe_pull_tail() subtracts skb_headlen(skb) from the unsigned max argument and passes the result to __pskb_pull_tail() as a signed int. The function does not ensure that max is at least skb_headlen(skb). This can happen while parsing IPv6 extension headers when an skb already has a linear area larger than MAX_IPV6_HDR_LEN. Once the parser needs data beyond the linear area, max - skb_headlen(skb) wraps and is converted to a negative delta. __pskb_pull_tail() then passes that negative length to skb_copy_bits(), where it can become a very large copy length. Pass the requested length itself as the pull bound at the three extension-header call sites, so the delta can no longer go negative. Fixes: 1431fb31ecba ("xen-netback: fix fragment detection in checksum setup") Suggested-by: Eric Dumazet Signed-off-by: Shihuang Liu Link: https://patch.msgid.link/20260919133604.50948-1-shlomojune6@gmail.com Signed-off-by: Jakub Kicinski commit 7104a370714346b667712913dc16abf14bbc97ed Author: Jakub Kicinski Date: Mon Sep 21 16:18:56 2026 -0700 veth: manage XDP program pointers during channel resize veth_set_channels() tears down XDP resources for removed RX queues without clearing rq->xdp_prog. If the program is then detached or replaced, those queues keep the old pointer after bpf_prog_put(). A later channel increase can re-enable NAPI and run the freed program. BUG: unable to handle page fault for address: ffffc90000256048 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: veth_xdp_rcv_skb (include/linux/filter.h:779 include/net/xdp.h:696 drivers/net/veth.c:820) Call Trace: veth_xdp_rcv (drivers/net/veth.c:941) veth_poll (drivers/net/veth.c:986) __napi_poll (net/core/dev.c:7787) net_rx_action (net/core/dev.c:7850 net/core/dev.c:8007) handle_softirqs (kernel/softirq.c:645) Kernel panic - not syncing: Fatal exception in interrupt Fixes: 4752eeb3d891 ("veth: implement support for set_channel ethtool op") Signed-off-by: Weiming Shi Acked-by: Stanislav Fomichev Reviewed-by: Jiayuan Chen Reviewed-by: Jason Xing Link: https://patch.msgid.link/20260921231856.1798630-1-kuba@kernel.org Signed-off-by: Jakub Kicinski commit 7e87508b5c4d81210d0a736ed01962e52f5c4c56 Author: Nicolai Buchwitz Date: Tue Sep 22 15:06:38 2026 +0200 net: bcmgenet: stop Tx NAPI before disabling the queues bcmgenet_netif_stop() and the Wake-on-LAN branch of bcmgenet_suspend() both disable the Tx queues first and stop Tx NAPI several steps later. A completion in flight calls netif_tx_wake_queue() in between, and nothing stops the queue again, so a transmit can reach the rings after they have been freed. Close is safe because dev_deactivate_many() stops the qdisc first. bcmgenet_suspend() does not, so stop Tx NAPI before the queues on both paths. KASAN on a Raspberry Pi CM4, driven from an MTU change because suspend freezes user space before the callback runs: BUG: KASAN: use-after-free in bcmgenet_xmit+0x17f8/0x2258 Write of size 8 at addr ffffff8055844a68 by task ksoftirqd/0/14 bcmgenet_xmit+0x17f8/0x2258 dev_hard_start_xmit+0x13c/0x588 sch_direct_xmit+0x108/0x340 __dev_queue_xmit+0x1190/0x3848 Fixes: 254f3239dd07 ("net: bcmgenet: revise suspend/resume") Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260922130639.1660797-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski commit fdfec06ac1eb5cdbc18d556c70a7b26837208218 Author: Nicolai Buchwitz Date: Tue Sep 22 09:31:40 2026 +0200 MAINTAINERS: add Nicolai Buchwitz as GENET maintainer I have been contributing to and reviewing the GENET driver for a while now. Florian asked if I would like to formalize this commitment, so add myself as a maintainer. Signed-off-by: Nicolai Buchwitz Acked-by: Florian Fainelli Acked-by: Justin Chen Link: https://patch.msgid.link/20260922073140.1471858-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski commit ab1404ac81154a89fb61ac50ae9a04cd8d4834dc Author: Fourie Zhang Date: Sun Sep 20 19:08:43 2026 +0800 net: bridge: mdb: restart port group walk after deletion br_mdb_flush_pgs() keeps a pointer-to-pointer cursor while walking mp->ports. br_multicast_del_pg() can re-enter the same MDB entry through br_multicast_sg_del_exclude_ports() and unlink other port groups. If the cursor points into one of those groups, the next iteration dereferences a stale cursor and can leave mp->ports pointing at freed memory. A following RTM_GETMDB exposes the dangling pointer: BUG: KASAN: slab-use-after-free in br_mdb_dump Read of size 8 br_mdb_dump rtnl_mdb_dump rtnl_dumpit netlink_dump Reset the cursor to mp->ports after every deletion. The deletion removes at least the selected group, so the restarted walk always makes progress. Fixes: a6acb535afb2 ("bridge: mdb: Add MDB bulk deletion support") Cc: stable@vger.kernel.org Signed-off-by: Fourie Zhang Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260920110852.60293-1-fouriezhang@tencent.com Signed-off-by: Jakub Kicinski commit cfa165cbfbed9d0f4bbc22fef4309f595a3ab187 Author: Victor Nogueira Date: Sun Sep 20 14:07:01 2026 -0300 net/sched: act_gate: budget the per-entry list in get_fill_size tcf_gate_get_fill_size returns only the TCA_GATE_PARMS size, but tcf_gate_dump also emits three 64-bit timestamps, the clock id, flags, priority and the variable-length TCA_GATE_ENTRY_LIST nest. The per-entry nest is unbounded: parse_gate_list places no cap on the number of sched-entries, so a gate with many entries can push the real dump well past the skb that tca_get_fill allocates from this size. RTM_NEWACTION then fails the add-notify with -EINVAL while the action is already committed to the IDR, and a subsequent RTM_GETACTION on the installed gate also returns -EINVAL because its dump no longer fits. Fix this by accounting for the missing fields in tcf_gate_get_fill_size along with all elements in the entries list. Note that sizing the reply from the action lets an oversized gate install cleanly for the first time: with the input unbounded by parse_gate_list, the sized skb can now grow well above NLMSG_GOODSIZE per netlink request (a transient GFP_KERNEL allocation reachable only with namespace-local CAP_NET_ADMIN). Overload from a malicious netns admin is hardening material, not net, per the discussion at https://lore.kernel.org/netdev/20260914191108.55a1a4f1@kernel.org/; a follow-up patch for net-next will cap the sched-entry count. Fixes: 4e76e75d6aba ("net sched actions: calculate add/delete event message size") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824153903.4143642-1-victor@mojatatu.com Tested-by: hybris Co-developed-by: Jamal Hadi Salim Signed-off-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/QDISC-3BLH.v1.20260914203033@mojatatu.com Signed-off-by: Jakub Kicinski commit 62f4c998b297cf233997a2b4cd6fc2d2df0319c9 Merge: fe2ec83746e501 94b7e3a7e871ae Author: Linus Torvalds Date: Wed Sep 23 14:15:03 2026 -0700 Merge tag 'parisc-for-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc architecture fixes from Helge Deller: - Increase kernel stack to 32kB on 64-bit kernel to avoid crashes - Parse early parameters in setup_arch() to enable huge page settings - Replace open-coded binary search with bsearch() in unwind code - Remove unused header * tag 'parisc-for-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Increase kernel stack size to 32kb parisc: parse early parameters in setup_arch() parisc: remove unused header parisc: unwind: Replace open-coded binary search with bsearch() commit b61732f47316d45f27706db7812950145d3327b5 Author: Deepanshu Kartikey Date: Wed Sep 23 09:26:27 2026 +0530 nfc: pn533: fix OOB read in pn533_acr122_is_rx_frame_valid() frame->ccid.datalen is read directly from the USB response frame and used, unchecked, as an index into frame->data[]. A malicious or malfunctioning device can set this field to an arbitrary value, causing the driver to read far outside the received buffer. Bound ccid.datalen against the maximum possible ACR122 frame size before using it. This replaces the existing datalen == 0 check, since datalen < 2 already covers that case and additionally rejects datalen == 1, which would still underflow the "datalen - 2" offset used below. Fixes: 9815c7cf22da ("NFC: pn533: Separate physical layer from the core implementation") Reported-by: syzbot+1853daab1a47603d4678@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1853daab1a47603d4678 Tested-by: syzbot+1853daab1a47603d4678@syzkaller.appspotmail.com Assisted-by: LLM Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260923035627.6210-1-kartikey406@gmail.com Signed-off-by: David Heidelberg commit 7dcf371a35632f035baf77bcf2c129165f772ce4 Author: Ömer Mete Kaya Date: Tue Sep 8 19:18:01 2026 +0300 nfc: llcp: fix slab-out-of-bounds reads when logging service names nfc_llcp_wks_sap() and nfc_llcp_build_sdreq_tlv() pass non-null- terminated strings to pr_debug() using the %s format specifier. The buffers are allocated via kmemdup() or come from netlink attributes and are not guaranteed to be null-terminated, causing __dynamic_pr_debug() to read beyond the allocated region: KASAN: slab-out-of-bounds Read in __dynamic_pr_debug Fix both call sites by using %.*s with the explicit length to limit the output to the actual length of the string. Fixes: d9b8d8e19b07 ("NFC: llcp: Service Name Lookup netlink interface") Reported-by: syzbot+1e3df0852e82c21ca418@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1e3df0852e82c21ca418 Signed-off-by: Ömer Mete Kaya Link: https://patch.msgid.link/20260908161952.731468-1-omermetekaya0@gmail.com Signed-off-by: David Heidelberg commit 408cff6bd60636df201274d320edfdfde9ed41db Author: Ömer Mete Kaya Date: Wed Sep 9 15:14:31 2026 +0300 nfc: llcp: fix WKS SAP hijacking via prefix match in nfc_llcp_wks_sap() nfc_llcp_wks_sap() compares only service_name_len bytes, so a short service_name like "u" matches longer WKS strings like "urn:nfc:sn:snep". Fix by requiring exact length match before strncmp(). Fixes: d646960f7986 ("NFC: Initial LLCP support") Signed-off-by: Ömer Mete Kaya Link: https://patch.msgid.link/20260909121437.33744-1-omermetekaya0@gmail.com Signed-off-by: David Heidelberg commit c04981e42d94f39c1dba965cc462a046e946a6c5 Author: Ömer Mete Kaya Date: Wed Sep 9 15:16:22 2026 +0300 nfc: llcp: fix -ENOMEM on connect with zero-length service name When service_name_len is 0, kmemdup() returns ZERO_SIZE_PTR which passes the NULL check, causing nfc_llcp_send_connect() to attempt building a zero-length service name TLV and fail with -ENOMEM. Fix by setting service_name to NULL directly when service_name_len is 0. Fixes: d646960f7986 ("NFC: Initial LLCP support") Signed-off-by: Ömer Mete Kaya Link: https://patch.msgid.link/20260909122029.34081-1-omermetekaya0@gmail.com Signed-off-by: David Heidelberg commit 7f2ea5ed588c03d481f0301e6c3d4240132383fb Author: Pengpeng Hou Date: Sun Aug 30 21:29:58 2026 +0800 nfc: st21nfca: validate ISO15693 inventory length The ISO15693 inventory helper removes a two-byte prefix without checking that it exists, then accepts a one-byte remainder before reading data[1] as the DSFID. Require the prefix and at least two remaining bytes before copying the UID data and reading the DSFID. Fixes: 7974728094d3 ("NFC: st21nfca: Add ISO15693 Reader/Writer support") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260830132958.6397-1-pengpeng@iscas.ac.cn Signed-off-by: David Heidelberg commit dcab71a7011918f6fdba7adcec02d217dcb84b8d Author: Luxiao Xu Date: Wed Sep 9 13:19:24 2026 +0800 nfc: fix use-after-free in nfc_get_local_general_bytes Commit 6709d4b7bc2e ("net: nfc: Fix use-after-free caused by nfc_llcp_find_local") attempted to fix a use-after-free (UAF) issue by invoking nfc_llcp_local_put(local) after accessing local->gb. However, if the reference count drops to zero, local is freed immediately, leading to a use-after-free when callers access the returned pointer. Alternative approaches using dynamic allocation (e.g. kmemdup) introduced memory leaks because callers consistently treat the returned pointer as borrowed memory. Fix this properly by refactoring nfc_llcp_general_bytes() and nfc_get_local_general_bytes() to accept a caller-provided output buffer (out_gb) and its maximum length (gb_max_len). The general bytes are safely copied into out_gb before calling nfc_llcp_local_put(local), ensuring safe lifetime management without ownership transfer complications. Update all callers across drivers (microread, pn533, pn544, st21nfca, digital_dep, and nci) to provide their own destination buffers and pass them to nfc_get_local_general_bytes(). Fixes: 6709d4b7bc2e ("net: nfc: Fix use-after-free caused by nfc_llcp_find_local") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Reviewed-by: Simon Horman Link: https://patch.msgid.link/3cbaac3bee23f8ff3a3284ed32d347696eb1d208.1788841683.git.rakukuip@gmail.com Signed-off-by: David Heidelberg commit d2acbde7e67df44efa8f0963462d1192e7694ffc Author: Myeonghun Pak Date: Sun Sep 13 00:26:25 2026 -0400 nfc: trf7970a: power down on startup RX gain failure trf7970a_startup() powers up the device before applying the optional RX gain reduction. If the register read or write fails, it returns without undoing that power-up. Probe's unwind only drops the separate regulator references acquired by probe, leaving the additional VIN enable from startup unbalanced. The system resume caller also has no power-down on this error. Call trf7970a_power_down() before returning the RX gain error to deassert the enable GPIOs, release the startup VIN reference and restore the powered-off state. Runtime PM has not been enabled yet, so the full shutdown helper is not appropriate here. Preserve the original SPI error. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 5d69351820ea ("NFC: trf7970a: Create device-tree parameter for RX gain reduction") Cc: stable@vger.kernel.org Assisted-by: OpenAI:GPT-5.6 Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Paul Geurts Link: https://patch.msgid.link/20260913042625.31296-1-mhun512@gmail.com Signed-off-by: David Heidelberg commit 66f4300206b82b0b143ef0d9be90cd8d29f23a47 Author: Cong Nguyen Date: Mon Sep 14 19:11:29 2026 +0700 nfc: llcp: fix sdreq TLV list leak on parse/alloc/send failure nfc_genl_llc_sdreq() builds a list of TLV nodes while walking nested netlink attrs, but 3 error paths (nested-attr parse failure, TLV alloc ENOMEM, nfc_llcp_send_snl_sdreq() failure) all skip freeing what was already queued. Route them through a new free_list label, mirroring the SDRES path in the same file which already does this. Harmless on the success path too -- send_snl_sdreq() drains the list as it moves nodes, so it's already empty by the time free_list runs. Fixes: d9b8d8e19b07 ("NFC: llcp: Service Name Lookup netlink interface") Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260914121129.2098606-1-congnt264@gmail.com Signed-off-by: David Heidelberg commit 273f9d667cde649f8de9d72b1303cc2f4b658c50 Author: Aamir Ahmed Date: Tue Sep 15 19:54:27 2026 +0100 nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc() nfc_llcp_recv_hdlc() reads the sequence byte skb->data[2], via nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs -- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb tailroom. The byte becomes N(R)/N(S); a peer can already set those with a well-formed PDU, so this is acting on uninitialised memory, not new peer control. Guard the read with pskb_may_pull(), as commit 95674f506c63 ("nfc: llcp: reject PDUs shorter than the LLCP header") did for the two-byte header, so the sequence byte is present and linear before it is read. RR and RNR PDUs are LLCP_HEADER_SIZE + LLCP_SEQUENCE_SIZE bytes and an I PDU is longer, so no valid frame is rejected; a truncated PDU is malformed, so return without a DM reply. Fixes: d646960f7986 ("NFC: Initial LLCP support") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Aamir Ahmed Reviewed-by: Simon Horman Link: https://patch.msgid.link/AS8P251MB0001789BBF04B72745C7D96BC8BA2@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: David Heidelberg commit 51814683e28fc64eceb415962376956c3cfc75a7 Author: Chris Gellermann Date: Fri Sep 4 18:42:52 2026 +0200 nfc: virtual_ncidev: Add missing ioctl compat handler The compat handler for ioctls to the virtual nci device is missing. So, nci-specific ioctls of a compat task return with -1 and errno set to ENOTTY. Add a handler. The handling of an ioctl() call of a compat task to get the index of virtual nci device (IOCTL_GET_NCIDEV_IDX) lands in the default case of the ioctl compat handler (see fs/ioctl.c): COMPAT_SYSCALL_DEFINE3(ioctl, ...) { ... default: error = do_vfs_ioctl(fd_file(f), fd, cmd, ...); if (error != -ENOIOCTLCMD) break; if (fd_file(f)->f_op->compat_ioctl) error = fd_file(f)->f_op->compat_ioctl(fd_file(f), cmd, arg); if (error == -ENOIOCTLCMD) error = -ENOTTY; ... } There, do_vfs_ioctl() returns -ENOIOCTLCMD and compat_ioctl is not set for virtual_ncidev_fops, i.e. f_op->compat_ioctl == NULL. So, the ioctl() syscall returns with -1 and errno set to ENOTTY to the compat task. To fix this, use the compat_ptr_ioctl helper for compat handling here. It shall be used for ioctls that "either ignore the argument or pass a pointer to a compatible data type". The driver's sole ioctl takes a user void pointer and copies nfc_dev->idx to it, a 4-byte integer across all ABIs. This issue has been found by running the nci_dev kernel selftest as rv64 binary on top of a CHERI kernel, where the ioctl() ends up in the ioctl compat handler, similar to a 32-bit application on top of a 64-bit kernel. Fixes: e624e6c3e777 ("nfc: Add a virtual nci device driver") Signed-off-by: Chris Gellermann Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260904164252.18351-1-christian.gellermann@codasip.com Signed-off-by: David Heidelberg commit 6be581aeffc215bfc77939cd59902b0dbc4af23e Author: Chris Gellermann Date: Fri Sep 4 11:59:15 2026 +0200 selftests/nci: Fix out-of-bounds store on thread join The NCI test collects the exit status of its helper threads by passing the address of an int to pthread_join(): int status; ... pthread_join(thread_t, (void **) &status); pthread_join() stores a void pointer to the memory location. On 64-bit systems, a void pointer is wider than an int, so the store overruns the 4 bytes of space allocated on the stack for the integer and corrupts the adjacent stack. On our CHERI system, this caused a fault due to a capability bounds violation. Fix this by introducing a helper that joins a thread through a void pointer and converts the result back to an integer, which is what the helper threads return. While here, also fix the logic in disconnect_tag() if the helper thread creation failed. Previously, it would have joined a thread that was never created when pthread_create() failed. Fixes: f595cf1242f3 ("selftests: Add nci suite") Signed-off-by: Chris Gellermann Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260904095915.3372241-1-christian.gellermann@codasip.com Signed-off-by: David Heidelberg commit eda518d2cdb6074a0bcdfa06af291616bcb5c421 Author: Chaithanya Lagisetty Date: Tue Sep 1 07:06:18 2026 +0000 selftests: nci: Fix uninitialized family ID on missing attribute get_family_id() walks the generic netlink CTRL_CMD_GETFAMILY reply looking for the CTRL_ATTR_FAMILY_ID attribute and returns the parsed value in the local variable "id". If the reply does not carry that attribute, the parsing loop never assigns "id" and the function returns an indeterminate stack value, which the caller stores in self->fid and uses for subsequent netlink requests. Initialize "id" to 0 so a missing attribute yields a deterministic (invalid) family ID instead of a garbage value. Fixes: f595cf1242f3 ("selftests: Add nci suite") Signed-off-by: Chaithanya Lagisetty Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260901070618.3299012-1-nagachaithanya9911@gmail.com Signed-off-by: David Heidelberg commit c3eef2f988a3db9690369d7cef9a3344dd9788d3 Author: Lee Jones Date: Wed Sep 2 12:30:31 2026 +0000 nfc: llcp: Fix race condition in accept_queue lifecycle In nfc_llcp_socket_release(), sockets and listener accept queues are walked under the local sockets rwlock and bh_lock_sock(). However, bh_lock_sock() does not synchronise against process-context lock_sock() held by nfc_llcp_accept_dequeue() during accept(). Because socket_release() does not check sock_owned_by_user(), both paths can concurrently unlink and release the same child socket, resulting in use-after-free or a NULL pointer dereference of child->parent in nfc_llcp_accept_unlink(). Fix this synchronisation race by having nfc_llcp_socket_release() use process-context lock_sock() instead of bh_lock_sock(): 1. Pop sockets from the local sockets list under the write lock using nfc_llcp_sock_list_pop() so lock_sock() can be acquired without holding the rwlock. 2. Because lock_sock() can sleep, defer the final release of the nfc_llcp_local structure to a workqueue (release_work). This avoids a sleeping-in-atomic bug when the last local reference is dropped from softirq context. Additionally, hold a single device reference on local from registration until final destruction. 3. In nfc_llcp_local_get(), use kref_get_unless_zero() to prevent resurrecting a local object whose teardown has been scheduled. 4. In llcp_sock_accept(), verify that the listener socket state is still LLCP_LISTEN after waking from schedule_timeout() to prevent hangs if the listener is closed concurrently. 5. When unlinking unaccepted child sockets during listener release, unlink them from local->sockets, call sock_orphan(), and drop their initial sk_alloc creation reference via sock_put(). 6. Make nfc_llcp_accept_unlink() idempotent by guarding parent access with a NULL check. Fixes: 50b78b2a6500 ("NFC: Fix sleeping in atomic when releasing socket") Signed-off-by: Lee Jones Link: https://patch.msgid.link/20260902123033.1169067-1-lee@kernel.org Signed-off-by: David Heidelberg commit 3d8afc5243ea2ee803d98e69eb4a01748167ac1b Author: Lei Zhu Date: Wed Jul 29 15:24:26 2026 +0800 selftests: nci: Correct pthread_create return value check The pthread_create() functions returns 0 on success and a positive value on failure. Modify the return value check to correctly detect failure cases. Fixes: 72696bd8a09d ("selftests: nci: Extract the start/stop discovery function") Signed-off-by: Lei Zhu Link: https://patch.msgid.link/20260729072426.303484-1-zhulei_szu@163.com Signed-off-by: David Heidelberg commit 092c6a605cbd6414ef499834c2e0da69c2c3388e Author: Doruk Tan Ozturk Date: Sat Jul 11 14:36:51 2026 +0200 nfc: port100: reject frames whose declared length exceeds the received data port100_recv_response() passes the URB transfer buffer to port100_rx_frame_is_valid(), which checksums le16_to_cpu(frame->datalen) bytes of frame->data. datalen is a 16-bit field supplied by the device and is never checked against the number of bytes actually received (urb->actual_length), so a device reporting a datalen larger than the received frame makes port100_data_checksum() read out of bounds past the transfer buffer. Reject a response whose declared frame size does not fit the received length before validating it. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested. Fixes: 562d4d59b8a1 ("NFC: Sony Port-100 Series driver") Cc: stable@vger.kernel.org Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260711123651.32595-1-doruk@0sec.ai Signed-off-by: David Heidelberg commit bf1460acdf8cf5a07c819f59785d40f20d113099 Author: Aldo Ariel Panzardo Date: Thu Jul 16 20:26:57 2026 -0300 nfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm() nfc_llcp_recv_dm() handles DM(NOBOUND)/DM(REJ) for a socket that is still linked on local->connecting_sockets: it looks the socket up with nfc_llcp_connecting_sock_get(), sets sk->sk_state = LLCP_CLOSED and returns, without taking the socket lock and without unlinking the socket from the connecting_sockets list. llcp_sock_release() selects the list to unlink from by sk_state: a socket in LLCP_CONNECTING is unlinked from connecting_sockets, otherwise from the sockets list. Because recv_dm left the socket physically on connecting_sockets but in the LLCP_CLOSED state, release() takes the else branch and calls nfc_llcp_sock_unlink(&local->sockets, sk). That runs sk_del_node_init() while holding sockets.lock, i.e. it removes the socket from the connecting_sockets hlist under the wrong lock. A concurrent connect() linking another socket onto connecting_sockets under connecting_sockets.lock then mutates the same hlist unserialized, which corrupts the list and desyncs the sk_add_node()/sk_del_node_init() sock_hold()/__sock_put() pairing. An unprivileged local process holding LLCP sockets, with the DM supplied by the remote peer over an established LLCP link, can drive this to leak kernel sockets without bound (the mis-decrement goes through the non-freeing __sock_put() path, so the object is never released), leading to memory exhaustion / DoS. This is the same class of bug that was fixed in the sibling handler nfc_llcp_recv_cc() by commit b493ea2765cc ("nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()"); recv_dm did not receive the equivalent fix. Fix it the same way: take lock_sock(), re-check that the socket is still hashed (release() may have won the race), and for the NOBOUND/REJ case unlink it from connecting_sockets before moving it to LLCP_CLOSED. The unlink drops the connecting_sockets membership reference via sk_del_node_init(), leaving the socket unhashed, so the later nfc_llcp_sock_unlink() in llcp_sock_release() becomes a no-op and no double put occurs. Fixes: a69f32af86e3 ("NFC: Socket linked list") Signed-off-by: Aldo Ariel Panzardo Link: https://patch.msgid.link/20260716232657.203145-1-qwe.aldo@gmail.com Signed-off-by: David Heidelberg commit a653c01ce447f10c36b901646888c0330363af4f Author: Pengpeng Hou Date: Wed Jul 15 16:44:05 2026 +0800 nfc: st21nfca: validate received frame size st21nfca_hci_i2c_repack() trims a received frame at its EOF marker before removing byte stuffing. It then assumes the truncated frame contains the LLC header and two CRC bytes, and it unconditionally reads the byte after an escape marker. A malformed frame can place EOF immediately after the start marker or can end its data portion with an escape marker. The former leaves too few bytes for check_crc(), while the latter makes the unstuffing loop read past the current skb length. Require the minimum framing bytes both before and after unstuffing. Use separate input and output cursors while removing byte stuffing, and reject an escape marker without its encoded byte. This keeps malformed frames within the received frame boundary before CRC processing. Fixes: 3096e25a3e40 ("NFC: st21nfca: Fix incorrect byte stuffing revocation") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260715084405.41546-1-pengpeng@iscas.ac.cn Signed-off-by: David Heidelberg commit 686f942332b1667f13f3b8d6a2f50bcfbf42e277 Author: Pengpeng Hou Date: Wed Jul 15 16:43:25 2026 +0800 nfc: nfcmrvl: validate helper command length before pull The firmware download receive path removes the NCI data header and reads the helper command before validating the remaining packet length. A short frame can therefore reach the data access before the malformed packet is rejected. Validate the complete helper command length before stripping the NCI data header. Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260715084325.40276-1-pengpeng@iscas.ac.cn Signed-off-by: David Heidelberg commit 18779dd84515db093fedb4ebaf0998c9b165a5fb Author: Ivan Lipski Date: Fri Aug 21 00:04:53 2026 -0400 drm/amd/display: Bump frame warning limit for clang builds of dml [Why&How] When building the DML files with clang without any sanitizer or LTO, the following -Wframe-larger-than errors break the build under CONFIG_WERROR: display_mode_vba_30.c: error: stack frame size (2512) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' display_mode_vba_31.c: error: stack frame size (2416) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' display_mode_vba_314.c: error: stack frame size (2392) exceeds limit (2048) in 'dml314_ModeSupportAndSystemConfigurationFull' Clang consistently spills more than gcc, pushing the frame past the 2048 byte limit. Apply an existing approach of increasing the warn stack size to the non-sanitizer path so plain clang builds use a 3072 byte limit. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5642 Signed-off-by: Ivan Lipski Signed-off-by: Alex Deucher (cherry picked from commit 21711b6e66bb7b41b1aec67b2d99aafe768c8fcb) Cc: stable@vger.kernel.org commit 0fd5e9ddf362b1253b3c94b858371f90400e5c4a Author: Alex Hung Date: Wed Sep 23 11:31:18 2026 -0600 drm/amd/display: Relax DML frame limit with UBSAN [WHY] UBSAN instrumentation adds checks and handler calls and increases stack usage in the large DML calculation functions, similar to KASAN and KCSAN. With UBSAN enabled these files exceed the default -Wframe-larger-than limit and fail to build when -Werror is in effect. Reproduced with LLVM (make LLVM=1, clang 19.1.1), CONFIG_UBSAN=y, CONFIG_GCOV_PROFILE_ALL=y and CONFIG_DRM_AMDGPU_WERROR=y on x86_64. [HOW] Include CONFIG_UBSAN in the sanitizer check that selects the higher per-file frame warning limit in the dml and dml2_0 Makefiles. Suggested-by: Leo Li Assisted-by: Copilot:Claude-Opus-5.5 Signed-off-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit ebf8b0fd8508b744f85a8eee82b745b1d3502dd0) Cc: stable@vger.kernel.org commit 2b86ab1bd6673c525adda88819d7658ba9e784ec Author: Wentao Liang Date: Wed Sep 16 09:58:05 2026 +0000 drm/amdgpu: Fix runtime PM leak in amdgpu_debugfs_test_ib_show() amdgpu_debugfs_test_ib_show() resumes the device with pm_runtime_get_sync() before taking the reset domain semaphore with down_write_killable(). If the write lock acquisition is interrupted, the function returns without calling pm_runtime_put_autosuspend(), leaking the runtime PM reference acquired for the device and keeping the GPU awake. Drop the runtime PM reference on the interrupted down_write_killable() error path before returning. Fixes: 6049db43d6dd ("drm/amdgpu: change reset lock from mutex to rw_semaphore") Signed-off-by: Wentao Liang Signed-off-by: Alex Deucher (cherry picked from commit ec30a576c2d4c0364549e6c04218f50704ef56c8) Cc: stable@vger.kernel.org commit b4f7b4459b1b155e4c4977a6482b5df2cf08758c Author: Wentao Liang Date: Wed Sep 16 09:55:36 2026 +0000 drm/amdgpu: Fix last_update fence leak in amdgpu_vm_init() amdgpu_vm_init() initializes vm->last_update, vm->last_unlocked and vm->last_tlb_flush with references to the stub fence taken via dma_fence_get_stub(). The error label at the end of the function releases the last_unlocked and last_tlb_flush references with dma_fence_put(), but the reference stored in vm->last_update is never dropped, so whenever the page table root creation, the reservation of the root BO or the PASID registration fails, the stub fence reference leaks. Drop the vm->last_update reference together with the other stub fence references on the error path. Fixes: 187916e6ed9d ("drm/amdgpu: install stub fence into potential unused fence pointers") Signed-off-by: Wentao Liang Signed-off-by: Alex Deucher (cherry picked from commit e7979c84fc05a176bdf855ee664871b1648404c9) Cc: stable@vger.kernel.org commit a997baa61179b450bd55c4810c7ccfed3b753a54 Author: Wentao Liang Date: Wed Sep 16 09:54:32 2026 +0000 drm/amdgpu: Fix acpi device leak in amdgpu_acpi_enumerate_xcc() amdgpu_acpi_enumerate_xcc() looks up each XCC ACPI device with acpi_dev_get_first_match_dev(), which takes a reference to the device. The reference is dropped with acpi_dev_put() after the XCC info is initialized, but if the kzalloc_obj() allocation of the XCC info fails the function returns -ENOMEM without releasing the reference, leaking the last reference to the ACPI device. Drop the ACPI device reference on the allocation failure path before returning. Fixes: 4d5275ab0b18 ("drm/amdgpu: Add parsing of acpi xcc objects") Reviewed-by: Lijo Lazar Signed-off-by: Wentao Liang Signed-off-by: Alex Deucher (cherry picked from commit 9211ef48b31ec66999cf55e04d0cbc60cd855fd5) Cc: stable@vger.kernel.org commit aea841bc62a76242396610d22d8ff40c13065f64 Author: Wentao Liang Date: Wed Sep 16 10:01:39 2026 +0000 drm/amdgpu: Fix vmid_wait fence leak in amdgpu_ring_init() amdgpu_ring_init() initializes ring->vmid_wait with a reference to the stub fence taken via dma_fence_get_stub(). When a later step of the initialization fails, e.g. amdgpu_fence_driver_init_ring(), a writeback slot allocation or the ring buffer allocation, the function returns an error without releasing the stub fence reference and the reference is leaked if the ring is torn down without amdgpu_ring_fini(). Move the stub fence assignment to the end of the initialization, right before the ring is registered with the GPU scheduler, where no further failure is possible. The stub fence is only consumed by command submission handling in amdgpu_ids.c once the ring is up and running, so nothing reads it during the error-prone part of the initialization. Fixes: 48e9fbd1a284 ("drm/amdgpu: initialize the vmid_wait with the stub fence") Signed-off-by: Wentao Liang Signed-off-by: Alex Deucher (cherry picked from commit f2b96986851203e9c50ca0d13aaa3581ca3e8ebd) Cc: stable@vger.kernel.org commit c3a31087b1c8df679b653c1a09d9abe5ff7ec8ef Author: Asad Kamal Date: Fri Aug 28 15:59:21 2026 +0800 drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping kfd_dev_mapping caches the address_space of the first /dev/kfd opener so that the GPU reset path can call unmap_mapping_range() to zap all userspace mappings of doorbell and MMIO ranges. This design has two bugs that both manifest under SRIOV with multiple containers: 1. Use-after-free / rwsem deadlock. The cached pointer refers to an inode owned by the first opener's container. When that container exits and its inode is released, kfd_dev_mapping becomes a dangling pointer. A subsequent GPU reset dereferences it inside unmap_mapping_range(), which takes i_mmap_rwsem on the freed inode, causing a hard hang observable as an uninterruptible rwsem wait. 2. Multi-container gap. Only the first opener's address_space is cached; VMAs created by later openers live in a different address_space and are never reached by unmap_mapping_range(). After a GPU reset those stale mappings keep doorbell and MMIO pages accessible to guest userspace with no GPU behind them, risking PCIe transaction timeouts and NMI panics. Fix both bugs with the same approach used by DRM core (drm_drv.c): create a private pseudo-filesystem at module init time and allocate one anonymous inode from it. In kfd_open() redirect every opener's file->f_mapping to that inode's address_space. The inode is module-owned, lives exactly as long as the amdgpu module, and collects VMAs from all openers in one address_space. A single unmap_mapping_range() call in the reset path then correctly reaches every container's mappings with no dangling pointer risk. The hang manifests as an NMI backtrace on the GPU reset workqueue stuck spinning in rwsem_down_read_slowpath() with a corrupted i_mmap_rwsem: Workqueue: amdgpu-reset-dev xgpu_ai_mailbox_flr_work [amdgpu] Call Trace: kvm_wait+0x1f/0x40 __pv_queued_spin_lock_slowpath+0x31d/0x3a0 _raw_spin_lock_irq+0x51/0x80 rwsem_down_read_slowpath+0xb3/0x550 down_read+0x48/0xd0 unmap_mapping_range+0x71/0x140 kfd_dev_unmap_mapping_range+0x5b/0x140 [amdgpu] amdgpu_amdkfd_clear_kfd_mapping+0xd8/0x190 [amdgpu] amdgpu_device_gpu_recover+0x232/0x450 [amdgpu] xgpu_ai_mailbox_flr_work+0xb5/0xc0 [amdgpu] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 Fixes: 70cadefcc616 ("drm/amdgpu: unmap all user mappings of framebuffer and doorbell before mode1 reset") Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher (cherry picked from commit 1128b4a52de1572e87431de837fd9850cb99542c) Cc: stable@vger.kernel.org commit 6b13ddbf5bb8deec337f9b4887f579097a953f6a Author: Sunil Khatri Date: Thu Sep 17 18:56:45 2026 +0530 drm/amdgpu/vcn4.0.3: fix video_timeout unit mismatch in jpeg reset wait vcn_v4_0_3_reset_jpeg_pre_helper() passes adev->video_timeout directly to amdgpu_fence_wait_polling(), whose timeout parameter is documented and implemented in usecs (busy-wait loop decrementing by udelay(2)). adev->video_timeout is set in jiffies by amdgpu_device_get_job_timeout_settings(), via msecs_to_jiffies(). Passing it unconverted means the intended ~2s wait for outstanding JPEG fences to complete before the JPEG queue is torn down actually lasts only a couple of microseconds (HZ jiffies interpreted as usecs), so pending jobs are almost never given a real chance to finish before the reset path forces completion in the following helper. Convert the jiffies value to usecs with jiffies_to_usecs() before passing it to amdgpu_fence_wait_polling(). Fixes: d25c67fd9d6f ("drm/amdgpu/vcn4.0.3: rework reset handling") Cc: Jesse.Zhang Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Sunil Khatri Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 5feabbd673c10ebee22b880e4d812f08974d2ef7) Cc: stable@vger.kernel.org commit f952ed353a27b46c86c9525a39b7a642850b8139 Author: Sunil Khatri Date: Thu Sep 17 18:56:45 2026 +0530 drm/amdgpu/vcn5.0.1: fix video_timeout unit mismatch in jpeg reset wait vcn_v5_0_1_reset_jpeg_pre_helper() passes adev->video_timeout directly to amdgpu_fence_wait_polling(), whose timeout parameter is documented and implemented in usecs (busy-wait loop decrementing by udelay(2)). adev->video_timeout is set in jiffies by amdgpu_device_get_job_timeout_settings(), via msecs_to_jiffies(). Passing it unconverted means the intended ~2s wait for outstanding JPEG fences to complete before the JPEG queue is torn down actually lasts only a couple of microseconds (HZ jiffies interpreted as usecs), so pending jobs are almost never given a real chance to finish before the reset path forces completion in the following helper. Convert the jiffies value to usecs with jiffies_to_usecs() before passing it to amdgpu_fence_wait_polling(). Fixes: fab47d2db5ca ("drm/amdgpu/vcn5.0.1: rework reset handling") Cc: Jesse.Zhang Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Sunil Khatri Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit b8334fec8b90ebffcaa01001a23edca9f29a05e9) Cc: stable@vger.kernel.org commit cd195f1616b2bb5fb7765465326c4d5d64a620a0 Author: Sunil Khatri Date: Thu Sep 17 18:56:45 2026 +0530 drm/amdgpu/userq: fix double jiffies conversion in hang detect timeout Function amdgpu_userq_start_hang_detect_work() calls msecs_to_jiffies() on adev->gfx_timeout/compute_timeout/sdma_timeout before arming hang_detect_work. These timeout values already hold jiffies values from amdgpu_device_get_job_timeout_settings() at device init. This silently shrinks the real hang-detect deadline to (2 * HZ) ms instead of the intended timeout. e.g. 500ms instead of the 2000ms default on a CONFIG_HZ=250 kernel, only coincidentally correct at HZ=1000. The shortened window is easily exceeded by ordinary fence-completion latency, causing hang_detect_work to fire and trigger a per-queue or full GPU reset for queues that are not actually hung. Pass the jiffies value directly to queue_delayed_work() instead of converting it a second time. Fixes: fc3336be9c62 ("drm/amd/amdgpu: Add independent hang detect work for user queue fence") Signed-off-by: Sunil Khatri Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 13d44ca033cb74756c2aef0ade54a75cdf2f6271) Cc: stable@vger.kernel.org commit 3022bdfe3e6d776e9273d6892f7c193138ca0666 Author: Prike Liang Date: Fri Jul 31 11:44:37 2026 +0800 drm/amdgpu: move userq fence wait out of signalling section The eviction fence suspend worker waits for every pending userq fence from inside a dma_fence_begin_signalling() critical section. Waiting on another DMA fence while responsible for signalling one violates the cross-driver fence contract and is reported by lockdep as a dma_fence_map dependency. Move the wait before dma_fence_begin_signalling(). Keep userq_mutex held so queue lifetime remains stable while inspecting last_fence. Fixes: fc61df151617 ("drm/amdgpu: annotate eviction fence signaling path") Signed-off-by: Prike Liang Reviewed-by: Vitaly Prosyak Signed-off-by: Alex Deucher (cherry picked from commit 3bd4fbc5ed89621340b5cd249869092691a9c81f) Cc: stable@vger.kernel.org commit c5fd4eaad50d620c7e09ac2082b2fb55ee54170e Author: Wentao Liang Date: Wed Sep 16 09:49:56 2026 +0000 drm/amd/display: Fix dc stream excess put in dm_update_crtc_state() In dm_update_crtc_state(), when a modeset is required the newly created stream is stored in dm_new_crtc_state->stream and an extra reference is taken with dc_stream_retain(). The reference returned by create_validate_stream_for_sink() is released as an extra reference at the skip_modeset label, leaving the stream owned by the new CRTC state. If amdgpu_dm_check_crtc_color_mgmt() fails afterwards, the code jumps to the fail label which releases new_stream again. Since the extra reference was already released at skip_modeset, this drops the reference owned by dm_new_crtc_state->stream and the stream is released while the atomic state still points to it, leading to a premature free of the dc stream. Set new_stream to NULL after releasing the extra reference at the skip_modeset label so that a later goto fail cannot release the reference owned by the new CRTC state. Fixes: 7cd4b70091a5 ("drm/amd/display: Rework CRTC color management") Signed-off-by: Wentao Liang Signed-off-by: Alex Deucher (cherry picked from commit 102a47065a62dc8f6bbbb47cf082a2934282eb08) Cc: stable@vger.kernel.org commit 80320b278fea07ffcda3f57b67b61658e0a4e1ca Author: Matthias Goergens Date: Thu Sep 24 01:52:03 2026 +0800 ata: libata-scsi: bound the ATA passthru sense descriptor writes When an ATA PASS-THROUGH command to an ATAPI device fails, the sense buffer holds the device's REQUEST SENSE reply, and ata_scsi_set_passthru_sense_fields() trusts its additional length byte, sb[7], when adding the ATA Status Return descriptor. A faulty or malicious device can use that to make the kernel read and write past the 96-byte buffer in three ways: - scsi_sense_desc_find() is passed sb[7] + 8 as the buffer length, so its clamp against sb[7] does nothing and the walk runs off the end. - A type-9 descriptor found near the end is filled in unchecked. - A new descriptor at sb[8 + len] needs len + 22 bytes, not len + 14, so len 75..82 writes up to 8 bytes past the end. Reproduced with KASAN under qemu, with the emulated ATAPI REQUEST SENSE reply patched: BUG: KASAN: slab-out-of-bounds in scsi_sense_desc_find+0x1a5/0x210 BUG: KASAN: slab-out-of-bounds in ata_scsi_qc_complete+0x1a15/0x1a50 Both are gone with this patch, and a valid descriptor is still filled in. Fixes: 97981926224a ("ata: libata-scsi: Do not overwrite valid sense data when CK_COND=1") Cc: stable@vger.kernel.org Reviewed-by: Damien Le Moal Signed-off-by: Matthias Goergens Link: https://lore.kernel.org/r/20260923175203.1576825-1-matthias.goergens@gmail.com Signed-off-by: Niklas Cassel commit 4fde448225123442c5796f54b7a4400e2d3cbaf6 Author: Mario Limonciello Date: Tue Sep 8 14:05:59 2026 -0500 x86/PCI: Disable enhanced atomics on AMD NBIO 7.7 and 7.11 Multiple users report data corruption during 64-bit DMA transfers on systems with AMD NBIO 7.7 and 7.11 controllers. This occurs when BIOS enables AMD "enhanced atomic operations" on PCIe Root Ports. When enhanced atomics are enabled, any 64-bit DMA access may be corrupted. Disable enhanced atomics using SMN for NBIO 7.7 and 7.11 based models. Reported-by: Mikael Etienne Closes: https://lore.kernel.org/178789300872.392066.15963676631650361573@gmail.com/ Reported-by: Arthur Husband Closes: https://lore.kernel.org/20260406222335.379935-1-artmoty@gmail.com/ Reported-by: Alvin Lim Closes: https://lore.kernel.org/20260621100844.1224301-1-alvinwylim@gmail.com/ Signed-off-by: Mario Limonciello [bhelgaas: commit log, s/IOVA/DMA/ in comment] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Cc: David Laight Cc: John Smith Cc: Lennert Buytenhek Cc: Niklas Cassel Cc: Roland Waltersson Link: https://patch.msgid.link/20260908190600.226485-2-mario.limonciello@amd.com commit b8d1d5b63a8ef532038eebd9d97d406860385668 Author: Masami Hiramatsu (Google) Date: Tue Sep 22 13:24:55 2026 +0900 x86/mce: Fix hardware debug register corruption on task migration In exc_machine_check_user(), local_db_save() and local_db_restore() are invoked in the outer entry stubs (DEFINE_IDTENTRY_MCE_USER, DEFINE_FREDENTRY_MCE, and DEFINE_IDTENTRY_RAW), surrounding exc_machine_check_user(). However, exc_machine_check_user() calls irqentry_exit_to_user_mode(), which handles pending thread work and may schedule() if TIF_NEED_RESCHED is set. If the task migrates to another CPU during schedule(), local_db_restore() runs on the new CPU with the dr7 state saved from the old CPU. This corrupts the new CPU's DR7 hardware debug register and leaves the old CPU's DR7 disabled. In short, local_db_save() and local_db_restore() pair must be run on the same CPU. To fix this, move local_db_save() and local_db_restore() inside exc_machine_check_user() and exc_machine_check_kernel(). In exc_machine_check_user(), DR7 is saved and restored strictly around do_machine_check() to avoid schedule() during migration. In exc_machine_check_kernel(), local_db_save() is called at the entry point to prevent early memory accesses from triggering nested #DB exceptions, and restored on all exits. Fixes: cd840e424f27 ("x86/entry, mce: Disallow #DB during #MC") Assisted-by: LLM Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Borislav Petkov (AMD) Acked-by: Peter Zijlstra (Intel) Cc: Link: https://patch.msgid.link/179005109564.388919.3937970081044095776.stgit@devnote2 commit 4409a85735cdca5c4c400c0dad1feee091872eee Author: Liang Luo Date: Wed Sep 23 19:07:37 2026 +0800 sched_ext: Count SCX_EV_SUB_BYPASS_DISPATCH in the dispatch fallback When a descendant scheduler enters bypass mode, its tasks are parked in the bypass DSQs of the nearest non-bypassing ancestor, which is then responsible for running them. On behalf of such a non-bypassing host, scx_dispatch_sched() consumes those bypass DSQs from two places: the attempt made every SCX_BYPASS_HOST_NTH dispatches, and the end-of-dispatch fallback that keeps the CPU from going idle while bypassed descendants still have tasks queued. The former increments SCX_EV_SUB_BYPASS_DISPATCH but the latter does not, even though both perform the same scx_consume_dispatch_q() on the same bypass DSQ. The descendant bypass dispatches done by the fallback are therefore missing from the counter exposed via sysfs, scx_dump_state() and the scx_bpf_events() kfunc, which under-reports the actual number of such dispatches. Add the missing __scx_add_event() so the fallback counts them too. When @sch itself is bypassing, scx_dispatch_sched() takes the earlier self-bypass branch and returns before reaching these host paths; that mode is accounted for by SCX_EV_BYPASS_DISPATCH at enqueue time and is intentionally left unchanged. Fixes: 025b1bd41965 ("sched_ext: Implement hierarchical bypass mode") Signed-off-by: Liang Luo Signed-off-by: Tejun Heo commit 883b776abe48fed8ef615f4ff7e91113a6c4dffb Author: Jan Kara Date: Tue Sep 22 12:41:02 2026 +0200 isofs: Fix handling of directories with tight blocks Thomas has reported that after commit b2eb2e288604 ("isofs: Drop support of directory entries straddling blocks") some isofs images of Fedora miss some entries in some directories. The problem is triggered when directory entries are packed in a block in such a way that they exactly fit the block (which BTW mkisofs doesn't do so I didn't catch this bug when testing with my images). Fix readdir and lookup code to properly transition to the next block when directory block is tightly packed. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2535353 Reported-by: Thomas Schmitt Reported-by: Matthias Goergens Fixes: b2eb2e288604 ("isofs: Drop support of directory entries straddling blocks") Reviewed-by: Thomas Schmitt Signed-off-by: Jan Kara commit a1cdd72371270640bd357bd3e3b2ec0be17c9536 Author: Even Xu Date: Tue Sep 22 10:46:38 2026 +0800 HID: Intel-thc-hid: Intel-quickspi: Fix buffer overflow The input buffers are used to store complete HID-over-SPI packets, including their protocol headers. However, their sizes are currently calculated from the payload length only. Allocate enough space for both the payload and the packet header to prevent a buffer overflow when the payload reaches its maximum size. Signed-off-by: Even Xu Signed-off-by: Jiri Kosina commit 5e5c3b9db1c5910d6a9175c97b76a95566e4dc32 Author: Even Xu Date: Tue Sep 22 10:46:37 2026 +0800 HID: Intel-thc-hid: Intel-quicki2c: Fix buffer overflow The input and output buffers are used to store complete HID-over-I2C packets, including their protocol headers. However, their sizes are currently calculated from the payload length only. Allocate enough space for both the payload and the packet header to prevent a buffer overflow when the payload reaches its maximum size. Signed-off-by: Even Xu Signed-off-by: Jiri Kosina commit 53f7f7955a684e820bdd6bd6792c45c4b434f637 Author: Tomasz Pakuła Date: Tue Sep 22 15:17:58 2026 +0200 HID: universal-pidff: Add support for Turtle Beach VelocityOne Race Add usb VID and device PID to hid-ids.h Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina commit 5b76268dac968612f7283d59b539036de955b7d9 Author: Vineeth Vijayan Date: Tue Sep 22 22:48:39 2026 +0200 s390/cio: Fix NULL pointer dereference in ccw_device_get_util_str() The channel path registry entry associated with a CHPID may be removed while the subchannel's PMCW still references that CHPID. In this case, chpid_to_chp() can return NULL, leading to a NULL pointer dereference. Add the missing NULL check before dereferencing the returned pointer. Fixes: 199652309a4d ("s390/cio: add helper to query utility strings per given ccw device") Cc: stable@vger.kernel.org Signed-off-by: Vineeth Vijayan Reviewed-by: Peter Oberparleiter Signed-off-by: Heiko Carstens commit 270437f3fe62516f16482742a7762a075e7a9457 Author: Karl Mehltretter Date: Sat Sep 19 19:11:00 2026 +0200 gpio: tps65219: Fix TPS65214 GPIO direction programming GPIO_LINE_DIRECTION_OUT and GPIO_LINE_DIRECTION_IN have the values 0 and 1, respectively, while the TPS65214 GPIO_CONFIG field is BIT(1). regmap_update_bits() masks the supplied value, so passing either direction value clears the field and selects input mode. Translate the GPIO direction to the register encoding used by tps65214_gpio_get_direction(), setting GPIO_CONFIG for output and clearing it for input. Fixes: 1b6ab07c0c80 ("gpio: tps65219: Add support for TI TPS65214 PMIC") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260919171100.90430-4-kmehltretter@gmail.com Signed-off-by: Bartosz Golaszewski commit 93cf8cedeaaa05714f709b539cfb976e0b80c830 Author: Karl Mehltretter Date: Sat Sep 19 19:10:59 2026 +0200 gpio: tps65219: Use the variant-specific direction callback The TPS65214 template installs its own get_direction callback because its direction bit is in GENERAL_CONFIG. The shared get and direction callbacks nevertheless call tps65219_gpio_get_direction() directly and interpret the unrelated TPS65219 MFP bit. On TPS65214 this can reject reads from an input and skip the change from input to output. Call the callback selected by the gpio_chip template instead. Fixes: 1b6ab07c0c80 ("gpio: tps65219: Add support for TI TPS65214 PMIC") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260919171100.90430-3-kmehltretter@gmail.com Signed-off-by: Bartosz Golaszewski commit 4cbe530c0233c7413aaaeb029a4f32dd6aadacbb Author: Karl Mehltretter Date: Sat Sep 19 19:10:58 2026 +0200 gpio: tps65219: Fix GPIO input value reads TPS65219_MFP_GPIO_STATUS_MASK is already BIT(4). Passing it to BIT() again tests bit 16, which cannot be set in the 8-bit MFP_CTRL register, so GPIO0 is always reported low when configured as an input. Test the register value with the mask directly. Fixes: 57e30e00bd5b ("gpio: tps65219: add GPIO support for TPS65219 PMIC") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Jonathan Cormier Link: https://patch.msgid.link/20260919171100.90430-2-kmehltretter@gmail.com Signed-off-by: Bartosz Golaszewski commit c9c15d4d8956df8c564f7c210e4dc5b9b820d97a Author: Sai Teja Aluvala Date: Tue Sep 22 18:33:11 2026 +0530 Bluetooth: btintel: validate DDC record lengths Parse DDC record lengths in unsigned storage so 0xFF does not wrap. Reject records smaller than the mandatory three-byte header, records exceeding U8_MAX, and records exceeding remaining firmware bytes before issuing Intel_Write_DDC. This issue was reported by Claude Mythos. Fixes: 145f2368c5fd ("Bluetooth: btintel: Add Device Configuration support") Signed-off-by: Sai Teja Aluvala Signed-off-by: Luiz Augusto von Dentz commit d1ac915fb4184faad1b62148be50f317de7c24b5 Author: Sang-Hoon Choi Date: Tue Sep 22 03:49:28 2026 +0900 Bluetooth: hci_core: free the HCI ID if naming fails hci_register_dev() allocates an ID before calling dev_set_name(). If naming fails, it returns without releasing that ID. The device has not been registered and hdev->id has not been assigned, so the normal unregister path cannot release it. Free the allocated ID before returning the naming error. Fixes: dcda165706b9 ("Bluetooth: hci_core: Fix build warnings") Reported-by: Changyul Lee Assisted-by: LLM Signed-off-by: Sang-Hoon Choi Reported-by: Changyul Lee Signed-off-by: Luiz Augusto von Dentz commit 74847177eca5638827ab74cdf77f0b10fc40ca6c Author: Linmao Li Date: Tue Sep 22 10:01:41 2026 +0800 Bluetooth: hci_core: Fix inquiry cache timestamps on 64-bit systems On 64-bit systems, outgoing BR/EDR connections always fall back to page scan repetition mode R2 with no clock offset once the system has been up for more than five minutes, even when inquiry found the peer only seconds earlier. This lengthens paging and can increase the risk of a Page Timeout. The inquiry cache stores jiffies in __u32 timestamps, but its age helpers subtract them from unsigned long jiffies. INITIAL_JIFFIES casts -300 * HZ through unsigned int, so jiffies crosses 2^32 five minutes after boot on 64-bit systems. Assigning it to __u32 then drops the upper 32 bits. In one trace, a 7.6-second-old entry (HZ=1000) was reported as 2^32 + 7620 ticks old and rejected by hci_acl_create_conn_sync(). hci_inquiry() is affected by the same truncation when checking the whole cache. 32-bit systems are unaffected because unsigned long is 32 bits wide there. Use unsigned long for both timestamps so they have the same width as jiffies on 32-bit and 64-bit systems, and update the debugfs format specifier accordingly. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li Signed-off-by: Luiz Augusto von Dentz commit f771f96557a4d953a7e4d045870547271e36e819 Author: Chandrashekar Devegowda Date: Tue Sep 22 12:10:22 2026 +0530 Bluetooth: btintel_pcie: reject oversized TX packets in send_frame() btintel_pcie_send_frame() eventually copies skb->data into a fixed BTINTEL_PCIE_BUFFER_SIZE (4096) DMA buffer via memcpy() in btintel_pcie_prepare_tx(), with a 4-byte PCIe type header prepended. A user-space process with HCI_CHANNEL_USER access can inject an oversized packet and overflow the buffer. Reject packets larger than BTINTEL_PCIE_BUFFER_SIZE - BTINTEL_PCIE_HCI_TYPE_LEN on entry. Fixes: 6e65a09f9275 ("Bluetooth: btintel_pcie: Add *setup* function to download firmware") Cc: stable@vger.kernel.org Signed-off-by: Chandrashekar Devegowda Signed-off-by: Luiz Augusto von Dentz commit 7dbeb6935ac331b0cba6c41cabd8e9d02d5f64ea Author: Chandrashekar Devegowda Date: Tue Sep 22 12:10:21 2026 +0530 Bluetooth: btintel_pcie: fix plen overflow in btintel_pcie_recv_frame() plen is u16 and computed as HDR_SIZE + dlen. For ACL/ISO frames dlen is a 16-bit field, so a value >= 0xFFFC wraps the sum, bypassing the "skb->len < plen" check and letting skb_trim() truncate the packet. Widen plen to u32 so the addition cannot wrap. Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Cc: stable@vger.kernel.org Signed-off-by: Chandrashekar Devegowda Signed-off-by: Luiz Augusto von Dentz commit 40eb4b18ad167b63644c27fa67a7400ba050379a Author: Chandrashekar Devegowda Date: Tue Sep 22 12:10:20 2026 +0530 Bluetooth: btintel: fix buffer over-read in btintel_hw_error() The "Exception info %s" print uses skb->data + 1, but the 12-byte payload is not guaranteed to be NUL-terminated and can be read past its end. Bound the print with "%.*s" and skb->len - 1. Fixes: 973bb97e5aee ("Bluetooth: btintel: Add generic function for handling hardware errors") Cc: stable@vger.kernel.org Signed-off-by: Chandrashekar Devegowda Signed-off-by: Luiz Augusto von Dentz commit 5acb2dace582f061aab5e14c399ac9480315f44b Author: Aldo Ariel Panzardo Date: Wed Sep 23 08:58:47 2026 -0300 HID: multitouch: stop the release timer from being rearmed on remove mt_remove() quiesces the sticky-finger timer before stopping the hardware: timer_delete_sync(&td->release_timer); sysfs_remove_group(&hdev->dev.kobj, &mt_attribute_group); hid_hw_stop(hdev); timer_delete_sync() waits for a running callback and dequeues the timer, but it does not stop the timer from being armed again. The transport is still delivering reports at that point, and the report path rearms it: if (app->quirks & MT_QUIRK_STICKY_FINGERS) { if (td->mt_io_flags & MT_IO_SLOTS_MASK) mod_timer(&td->release_timer, jiffies + msecs_to_jiffies(100)); A report that arrives after timer_delete_sync() has returned therefore leaves the timer queued. td is allocated with devm_kzalloc() against hdev->dev, so it is freed when the driver is unbound, after mt_remove() returns. When the timer fires afterwards, mt_expired_timeout() dereferences the freed td: struct mt_device *td = timer_container_of(td, t, release_timer); struct hid_device *hdev = td->hdev; if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags)) Simply moving the teardown after hid_hw_stop() does not fix this on its own, because mt_expired_timeout() calls mt_release_contacts(), which walks hdev->inputs; the timer still has to be quiesced before hid_hw_stop() tears the input devices down. Use timer_shutdown_sync() instead, which additionally makes any later mod_timer() a no-op, so neither ordering constraint has to be traded off against the other. This is the final-teardown pattern the function was introduced for, and hid-wiimote already uses it for the same reason. Fixes: 4f4001bc76fd ("HID: multitouch: fix rare Win 8 cases when the touch up event gets missing") Cc: stable@vger.kernel.org Reported-by: Sashiko AI review Closes: https://sashiko.dev/#/patchset/20260723224211.613112-1-you@example.com?part=1 Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Benjamin Tissoires Signed-off-by: Benjamin Tissoires commit 2bc6b218717b9d08f466f88209251d54bc09b207 Author: Fuad Tabba Date: Tue Sep 22 19:14:30 2026 +0100 arm64/boot: Disable trapping of PMZR_EL0 writes to EL2 __init_el2_fgt2() writes one mask to both HDFGRTR2_EL2 and HDFGWTR2_EL2. PMZR_EL0 is write-only, so its trap bit, nPMZR_EL0, exists only in HDFGWTR2_EL2 and is therefore never set: a PMZR_EL0 write from the host traps to EL2, where the nVHE hypervisor has no handler and BUG()s. The kernel never writes PMZR_EL0, but kernel.perf_user_access=1 has the PMU driver set PMUSERENR_EL0.UEN for a task with a user-read event, so a write from EL0 reaches the trap and takes the host down without a panic message. Accumulate the HDFGWTR2_EL2 bits separately, as __init_el2_fgt() already does for HDFGWTR_EL2, and set nPMZR_EL0 with the other FEAT_PMUv3p9 bits. Fixes: 858c7bfcb35e1 ("arm64/boot: Enable EL2 requirements for FEAT_PMUv3p9") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Reviewed-by: Anshuman Khandual Reviewed-by: Oliver Upton Signed-off-by: Will Deacon commit 2de1066dc859036f35fefd52483b2f3712462971 Author: Konrad Dybcio Date: Wed Aug 19 18:46:47 2026 +0200 serial: qcom-geni: keep registered console runtime active Commit aee1f94dab13 ("serial: qcom-geni: remove .pm callback, use runtime PM in startup/shutdown") moved runtime PM references from the serial-core PM callback to the port startup and shutdown callbacks. The serial core used to leave the console port powered after registration, but after the callback was removed the temporary probe reference is always released. Console writes are not tied to an open TTY and can run from contexts which cannot resume the device, so a runtime-suspended console can stall. This was observed on a Qualcomm X1E80100 CRD device, as the boot console became flakey across boots. Acquire a runtime PM reference when the console is set up and release it through the console exit callback. This keeps the device active only while the console is registered and balances the reference when the console is disabled or re-enabled through sysfs. Fixes: aee1f94dab13 ("serial: qcom-geni: remove .pm callback, use runtime PM in startup/shutdown") Assisted-by: LLM Signed-off-by: Konrad Dybcio Reviewed-by: Abel Vesa Tested-by: David Heidelberg # OnePlus 6T (sdm845) Link: https://patch.msgid.link/20260819-topic-geni_console_poweredoff-v1-1-7f7bb3aad8da@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 3098c989bd38edff871d798acd7f1d1b269f7edd Author: Abel Vesa Date: Fri Aug 28 17:32:17 2026 +0300 serial: qcom-geni: Fix unbalanced runtime PM resume for no_console_suspend When no_console_suspend is set for the serial console, the system suspend callback skips pm_runtime_force_suspend() to keep the console active. The resume callback still unconditionally calls pm_runtime_force_resume(), which triggers an "Unbalanced pm_runtime_enable!" warning. Only force resume when the suspend callback force suspended the device. Fixes: d0cd9c8d0fd5 ("serial: qcom-geni: add force suspend/resume to system sleep callbacks") Signed-off-by: Abel Vesa Reviewed-by: Praveen Talari Tested-by: David Heidelberg # OnePlus 6T (sdm845) Link: https://patch.msgid.link/20260828-serial-qcom-geni-fix-unbalanced-rpm-resume-v1-1-af3e5aef17a6@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit a8e8cf9bf446b65449c7bc39ad84956c347d5f9c Author: Arnd Bergmann Date: Tue Sep 15 22:04:11 2026 +0200 serial: qcom-geni: avoid unused-function warning The qcom_geni_serial_poll_rx_fifo_locked() function is only used for console support, but defined outside of the #ifdef block: drivers/tty/serial/qcom_geni_serial.c:918:13: error: 'qcom_geni_serial_poll_rx_fifo_locked' defined but not used [-Werror=unused-function] 918 | static void qcom_geni_serial_poll_rx_fifo_locked(struct uart_port *uport) Move the function definition to a more appropriate place that avoids the warning. Fixes: 8200871327d1 ("serial: qcom-geni: Keep FIFO RX active during console TX") Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260915200435.3524505-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2579cbe68005f46fc7f8f95364f6b101b07b9d1c Author: Rohinthan P Date: Wed Sep 23 12:50:50 2026 +0530 media: em28xx: use video_unregister_device for radio_dev Commit 7c8bf63b7937 ("media: em28xx: use vb2_video_unregister_device") converted device unregistrations in em28xx to use vb2_video_unregister_device() instead of video_unregister_device(). However, radio devices do not have an associated videobuf2 queue (v4l2->radio_dev.queue is NULL). Calling vb2_video_unregister_device() on a radio device triggers a WARNING in vb2_video_unregister_device(): !vdev->queue WARNING: drivers/media/common/videobuf2/videobuf2-v4l2.c:1264 at vb2_video_unregister_device+0x1f8/0x200 Call Trace: em28xx_v4l2_init+0x1c39/0x3150 drivers/media/usb/em28xx/em28xx-video.c:3085 As documented in vb2_video_unregister_device(), video_unregister_device() should be used instead when vdev->queue is NULL. Revert to calling video_unregister_device() for v4l2->radio_dev in both em28xx_v4l2_fini() and the em28xx_v4l2_init() error unwind path. Fixes: 7c8bf63b7937 ("media: em28xx: use vb2_video_unregister_device") Reported-by: syzbot+f26bc23e42eeb548dee1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f26bc23e42eeb548dee1 Signed-off-by: Rohinthan P Signed-off-by: Hans Verkuil commit 51c2db3ef0cb89a49ab7f47a40efd5d5b074ce8d Author: Ming Qian Date: Mon Sep 21 19:03:34 2026 +0900 pmdomain: imx8m-blk-ctrl: Serialize power on/off across sibling domains 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 commit 9d2c70986bb7838c1c441a93bda415eecb52f3dd Author: Keith Busch Date: Tue Sep 22 10:27:11 2026 -0700 blk-mq: allow cached requests to be used for flush operations The cached request lookups reject a request whose op_is_flush() state does not match the incoming operation. That check is from when rq->elv and rq->flush shared a union, so a request could not be both a scheduler request and carry flush state. Commit be4c427809b0 ("blk-mq: use the I/O scheduler for writes from the flush state machine") made them separate members of struct request. A cached request now gets its scheduler state when it is claimed by an operation, so one claimed for a flush is set up exactly as a freshly allocated request. Drop the check so a cached batch can mix flush and non-flush operations. Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260922172711.1573186-2-kbusch@meta.com Signed-off-by: Jens Axboe commit ab6c756f28c741d704a7c3e04814bfc3adf6f818 Author: Keith Busch Date: Tue Sep 22 10:27:10 2026 -0700 blk-mq: set RQF_USE_SCHED when the operation is known The cached requests are allocated for one operation but can be handed out for another. A passthrough command has RQF_USE_SCHED cleared, so using those flags for a subsequent read/write bio will insert it into the scheduler without ->prepare_request() and frees it without ->finish_request(). For kyber, this leaks the domain token acquired at dispatch and stalls the queue. Don't set RQF_USE_SCHED based on the first operation the batch happened to be allocated for. Instead, set it after the request is claimed by an operation. Introduce a helper function, blk_mq_rq_late_init() for this, and absorb blk_mq_rq_time_init() since the two run together. Fixes: 4b6a5d9cea91 ("block: enable batched allocation for blk_mq_alloc_request()") Link: https://lore.kernel.org/linux-block/20260916151655.2588-1-15815827059@163.com/ Reported-by: Henry Hu Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260922172711.1573186-1-kbusch@meta.com Signed-off-by: Jens Axboe commit a3bdf68feecc57af5c11fb599f860ac9790ffad9 Author: Yao Kai Date: Wed Sep 23 09:43:10 2026 +0800 io_uring: initialize task context before running the BPF loop Submitting SQEs through an io_uring BPF loop can trigger a NULL pointer dereference in io_submit_sqes(), as shown by the following arm64 report: [ 2049.380301] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 2049.388788] pc : io_submit_sqes+0x48/0x6c4 [ 2049.389153] lr : bpf_io_uring_submit_sqes+0x10/0x1c [ 2049.396310] Call trace: [ 2049.396531] io_submit_sqes+0x48/0x6c4 (P) [ 2049.396893] bpf_io_uring_submit_sqes+0x10/0x1c [ 2049.397293] bpf_prog_1a2a95cb199202b5+0x3c/0x68 [ 2049.397699] bpf__io_uring_bpf_ops_loop_step+0x5c/0x94 [ 2049.398149] io_run_loop+0x70/0x2e4 [ 2049.398461] __arm64_sys_io_uring_enter+0xf0/0x710 [ 2049.398882] invoke_syscall+0x54/0x10c [ 2049.399414] el0_svc_common.constprop.0+0x40/0xe0 [ 2049.399829] do_el0_svc+0x1c/0x28 [ 2049.400125] el0_svc+0x38/0x1d0 [ 2049.400409] el0t_64_sync_handler+0xa0/0xe4 [ 2049.400779] el0t_64_sync+0x198/0x19c io_uring_enter() dispatches to io_run_loop() before reaching the normal submission path's io_uring_add_tctx_node() call. The loop only checks whether the caller is allowed to run task work; it does not initialize current->io_uring or associate the task with the ring. A BPF call to bpf_io_uring_submit_sqes() then reaches io_get_task_refs(), which assumes that current->io_uring is valid. A ring created with IORING_SETUP_R_DISABLED, IORING_SETUP_SINGLE_ISSUER and IORING_SETUP_DEFER_TASKRUN can be enabled by a different task that has never used io_uring. Enabling the ring makes that task the submitter without allocating its io_uring task context. Its first BPF-driven submission of a pending SQE can therefore cause a kernel Oops. Call io_uring_add_tctx_node() in io_run_loop() before invoking the loop and propagate any initialization error. Do this before acquiring uring_lock, since task context setup may acquire the same mutex. This also establishes the task-to-ring association used for cancellation. Fixes: 033af2b3eb19 ("io_uring: introduce callback driven main loop") Signed-off-by: Yao Kai Link: https://patch.msgid.link/20260923014310.591292-1-yaokai34@huawei.com Signed-off-by: Jens Axboe commit 2a42e6fe1293f2e2d579c9fe5bbab056dd8b880e Author: Yang Xiuwei Date: Wed Sep 23 17:37:32 2026 +0800 block: reject polled dio with user integrity metadata IOCB_HAS_METADATA leaves iocb->private as a uio_meta, while iocb_bio_iopoll() expects a bio. Since 2729a60bbfb9, metadata I/O always uses __blkdev_direct_IO(), which never publishes the bio for polling, so IOPOLL calls bio_poll() on the uio_meta. Reproducer: io_uring IOPOLL plus a PI attribute on an integrity device (scsi_debug dif=1 dix=1). KASAN reports: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000004 KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:bio_poll+0x9d/0x4b0 Call Trace: iocb_bio_iopoll+0x5b/0x80 io_uring_classic_poll+0xf3/0x140 io_do_iopoll+0x4e3/0xc00 io_iopoll_check+0x275/0x560 __do_sys_io_uring_enter+0x2e5/0x720 Return -EOPNOTSUPP when HIPRI is combined with user metadata. Fixes: 2729a60bbfb9 ("block: don't silently ignore metadata for sync read/write") Assisted-by: LLM Signed-off-by: Yang Xiuwei Link: https://patch.msgid.link/20260923093732.1504291-1-yangxiuwei@kylinos.cn Signed-off-by: Jens Axboe commit 63ef71d1474b5417b5b2dec700cd251c44a570d9 Author: Viken Dadhaniya Date: Tue Sep 15 18:56:28 2026 +0530 tty: serial: qcom_geni_serial: Keep console RX functional after deep idle At baud rates up to 115200, the serial console uses only a 1 kBps keepalive vote for the GENI_TO_CORE ("qup-core") ICC path. This vote keeps the path active but does not request a QUP Core 2X clock rate. When the CPU enters a deeper idle state, the missing Core clock vote can leave the console RX path unresponsive. Use the 19.2 MHz Core 2X vote at low baud rates, while retaining the 50 MHz vote at higher baud rates, so that console RX remains functional after deep idle transitions. Fixes: 7cf563b2c846 ("tty: serial: qcom_geni_serial: Add interconnect support") Cc: stable@kernel.org Reviewed-by: Konrad Dybcio Signed-off-by: Viken Dadhaniya Link: https://patch.msgid.link/20260915-correct-icc-bandwidth-vote-constants-v2-2-f78eb611204e@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 1cd9b1be5a9c56fd69e3f555b200a1844f9b873e Author: Viken Dadhaniya Date: Tue Sep 15 18:56:27 2026 +0530 soc: qcom: geni-se: Correct QUP Core ICC vote constants The GENI_TO_CORE ("qup-core") ICC vote selects the QUP Core 2X clock rate. The CORE_2X_*_MHZ constants are expressed in Bps, but their values are several orders of magnitude too small. For example, the 50 MHz threshold is represented by 2500 rather than 25000000 Bps. As a result, clients using these constants can severely under-vote the QUP Core clock. Correct the constants to their intended Bps thresholds so that the ICC provider selects the corresponding QUP Core 2X clock rate. Drop the unused definitions. Fixes: 58ffbba6a399 ("soc: qcom: geni: Support for ICC voting") Cc: stable@kernel.org Signed-off-by: Viken Dadhaniya Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260915-correct-icc-bandwidth-vote-constants-v2-1-f78eb611204e@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 189b9dc8c96ec9486482f27c1372b04a7152175e Author: Fan Wu Date: Wed Sep 9 08:40:02 2026 +0000 serial: 8250_bcm7271: fix use-after-free in brcmuart_remove() brcmuart_handle_irq() starts priv->hrt to work around a receive-timeout quirk of the 8250 core when hardware flow control is enabled; the timer callback brcmuart_hrtimer_func() dereferences priv. brcmuart_remove() cancels the hrtimer before it unregisters the port, so a receive-timeout interrupt that arrives in between re-arms the timer. After devm frees priv, the callback runs on freed memory. Unregister the port before cancelling the hrtimer. serial8250_unregister_port() shuts the port down and frees its IRQ, so brcmuart_handle_irq() can no longer restart the timer, and the final hrtimer_cancel() drains any timer that was armed before or during the unregister. This issue was found by an in-house static analysis tool. Fixes: 41a469482de2 ("serial: 8250: Add new 8250-core based Broadcom STB driver") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260909084002.686911-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 9d8955281d9229a899e2041659a59b389027b711 Author: Wentao Liang Date: Thu Sep 17 15:58:34 2026 +0000 serial: vt8500: Fix clock reference leak in vt8500_serial_probe() of_clk_get() returns a clock with a reference that has to be released with clk_put(). If clk_prepare_enable() fails the function returns without doing so, leaking the reference. Add the missing clk_put() on that error path. Fixes: 12faa35ae5cb ("serial: vt8500: UART uses gated clock rather than 24Mhz reference") Cc: stable@kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917155834.2161361-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit ef3134cd0d4831ae2137aee2883987859b80b2c6 Author: Wentao Liang Date: Thu Sep 17 15:55:23 2026 +0000 kgdboc: Fix tty driver reference leak in configure_kgdboc() tty_find_polling_driver() returns the tty driver with an extra reference taken by tty_driver_kref_get(). configure_kgdboc() stores it in kgdb_tty_driver but the reference is never dropped: it is leaked when kgdb_register_io_module() fails, when the configuration is cleared, and on every reconfigure. Release the reference both when unconfiguring and on the error path. Fixes: 7d7b93c1452f ("tty: kref the tty driver object") Cc: stable@kernel.org Signed-off-by: Wentao Liang Reviewed-by: Douglas Anderson Link: https://patch.msgid.link/20260917155523.2161202-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 98401cf912fe8a081ef8e500c421b6d957b55a99 Author: Wentao Liang Date: Thu Sep 17 15:56:50 2026 +0000 serial: ma35d1: Fix clock reference leak in ma35d1serial_probe() of_clk_get() returns a clock with a reference that has to be released with clk_put(). ma35d1serial_probe() never does that, so the reference is leaked on the probe error paths and also when the port is removed. Release it on the error paths and in ma35d1serial_remove(). Fixes: 930cbf92db01 ("tty: serial: Add Nuvoton ma35d1 serial driver support") Cc: stable@kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917155650.2161274-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 499485a67fbacf4d9afbdb43522388c64f853428 Author: Ruslan Valiyev Date: Wed Aug 26 10:46:54 2026 +0200 serial: core: fix NULL pointer dereference in serial_core_unregister_port() port->port_dev is NULL when no port device is installed: it is cleared on teardown, and never set if registration failed before serial_core_port_device_add(). serial_core_unregister_port() passes it straight to serial_core_get_ctrl_dev(), which dereferences it: KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047] RIP: serial_core_unregister_port Call Trace: serial8250_unregister_port serial8250_remove unbind_store Return early when there is no port device, and read port->port_dev under port_mutex. Also clear port->port_dev on the serial_core_register_port() error path, where the port device has already been removed. Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM") Reported-by: syzbot+9f57c1b2792029198fcf@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9f57c1b2792029198fcf Cc: stable@kernel.org Assisted-by: Claude:claude-opus-5 Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Ruslan Valiyev Link: https://syzkaller.appspot.com/bug?extid=9f57c1b2792029198fcf Link: https://lore.kernel.org/all/20260826073237.1377668-1-linuxoid@gmail.com/ Reviewed-by: Tony Lindgren Link: https://patch.msgid.link/20260826084654.1392851-1-linuxoid@gmail.com Signed-off-by: Greg Kroah-Hartman commit 73f3e6ca7a6a7c952977c7c94f1c6dddebcafa34 Author: Kendall Willis Date: Tue Aug 25 17:06:07 2026 -0500 serial: 8250_omap: fix wake irq cleared during suspend The wake irq was cleared in shutdown(), which runs during the suspend sequence, making it impossible to wake the system via UART. Move wake irq setup to probe() and teardown to remove() so the irq remains armed during suspend when the UART is a wakeup source. Cc: stable@kernel.org Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Signed-off-by: Kendall Willis Reviewed-by: Tony Lindgren Link: https://patch.msgid.link/20260825-uart-wakeirq-fix-v2-1-0b9fba03d9b6@ti.com Signed-off-by: Greg Kroah-Hartman commit 03b49c991abb8d021ca6fe51cd173447236b0552 Author: Joshua Rogers Date: Mon Aug 3 16:10:55 2026 +0200 tty: vcc: hold port lock when clearing tty pointer in vcc_cleanup vcc_cleanup() sets port->tty to NULL without holding port->lock, racing with vcc_event() LDC callbacks that read port->tty under port->lock and then use tty->port. This can cause a use-after-free when the callback dereferences tty->port after cleanup has already destroyed and freed it. Assisted-by: AISLE:Snapshot Cc: stable Signed-off-by: Joshua Rogers Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20260803-aisle-tty-vcc-v2-2-a50bc9b15193@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 1f71f565e3585da1098ff19ca3c24687dab59185 Author: Joshua Rogers Date: Mon Aug 3 16:10:54 2026 +0200 tty: vcc: zero-initialize control packet in vcc_send_ctl() The stack-allocated struct vio_vcc pkt was partially initialized, leaving the tag.stype_env field uninitialized before being sent via ldc_write(), potentially leaking kernel stack data to the LDC peer. Assisted-by: AISLE:Snapshot Cc: stable Signed-off-by: Joshua Rogers Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20260803-aisle-tty-vcc-v2-1-a50bc9b15193@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit e62e601cfd3c842633afca6f864866d03fe1556f Author: Maciej W. Rozycki Date: Thu Aug 6 11:54:34 2026 +0100 MAINTAINERS: Add self for the sb1250-duart serial driver I wrote this driver and seem to have been the main remaining user now. Signed-off-by: Maciej W. Rozycki Reviewed-by: Philippe Mathieu-Daudé Link: https://patch.msgid.link/alpine.DEB.2.21.2608060423110.55540@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit 615f35fd5aee169cc4881a8594f2fa234a4d0bb8 Author: Johan Hovold Date: Fri Sep 11 11:01:32 2026 +0200 tty: amiserial: fix broken TIOCMIWAIT A change replacing interruptible_sleep_on() inadvertently broke the TIOCMIWAIT implementation which now immediately returns -EIO (unless there is a racing modem status update). Replace the old hangup (and signal) detection with a check for the TTY_IO_ERROR flag which is set on hangup. Fixes: 591cee0a3563 ("tty/amiserial: avoid interruptible_sleep_on") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/20260910132029.D80801F00898@smtp.kernel.org Cc: stable@kernel.org # 3.14 Cc: Arnd Bergmann Signed-off-by: Johan Hovold Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20260911090132.723531-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit eb35b73e133686e5b999eb7130c4e3d22fe03089 Author: Johan Hovold Date: Thu Sep 10 15:08:16 2026 +0200 serial: abort TIOCMIWAIT on hangup Add the missing hangup check to the TIOCMIWAIT wait loop to avoid going back to sleep (indefinitely) after being woken on hangup. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/r/20260904115542.E20D11F00A3D@smtp.kernel.org Cc: stable@kernel.org Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260910130816.642699-5-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 40adffec8c0090533dfaa863ced7901b60bbf1dc Author: Johan Hovold Date: Thu Sep 10 15:08:15 2026 +0200 serial: fix TIOCMIWAIT race The task state must be updated before checking the wakeup condition to avoid missing a racing modem status update. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/r/20260904115542.E20D11F00A3D@smtp.kernel.org Cc: stable@kernel.org Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260910130816.642699-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8ca59f7baee7c72cf7729950b4ab2e7f910c9549 Author: Johan Hovold Date: Thu Sep 10 15:08:14 2026 +0200 serial: fix ioctl hangup race The tty ioctls can race with hangup and end up calling into a tty driver for a device that is already gone or powered down. Add the missing checks to make sure the port has not been hung up before accessing the hardware to avoid issues like kernel panic due to unclocked accesses. Note that TIOCGSERIAL, TIOCGICOUNT do not access hardware and are therefore not affected by the race. Also note that the initialised check in uart_set_ldisc() added by commit 2f70e49ed860 ("serial_core: Check for port state when tty is in error state") should have been done under the port lock to avoid racing with uart_do_autoconfig(). Fixes: 04f378b198da ("tty: BKL pushdown") Cc: stable@kernel.org # 2.6.26 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260910130816.642699-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit f658e6bcd00a4eafaa9c98c0b7483cc2c5dac539 Author: Johan Hovold Date: Thu Sep 10 15:08:13 2026 +0200 serial: revert guards in uart_wait_modem_status() Mixing scope-based and regular cleanup is discouraged and uart_port_deref() used by uart_wait_modem_status() falls in the latter category. Revert the guard conversion in preparation for fixing a hangup race. Fixes: 56609c050051 ("serial: serial_core: use guard()s") Cc: stable@kernel.org # 6.18 Cc: Jiri Slaby (SUSE) Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260910130816.642699-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit b48820de8c1a596c5b99775524dfce73c6576c5d Author: Johan Hovold Date: Thu Sep 10 14:51:14 2026 +0200 tty: port: fix tty_port_tty_vhangup() race Drivers rely on tty_port_tty_vhangup() to synchronously hang up their ports before tearing down resources as part of deregistration (e.g. on physical disconnect). If tty_port_tty_vhangup() races with another hangup it may however return before the port has been shut down. This is in turn can lead to use-after-free and NULL-pointer dereferences in racing ioctls (including a synchronous hangup) and in processing of racing asynchronous hangups (carrier loss). Add the missing serialisation to tty_port_tty_vhangup() and tty_port_hangup() so that the former does not return until the port has been shut down also when there is a racing hangup. Note that serial core does not use tty_port_hangup(), but it already holds the port mutex when clearing port->tty and shutting down the port in uart_hangup(). Fixes: 7ca0ff9ab321 ("tty: Add a full port_close function") Cc: stable@kernel.org # 2.6.32: 2b5eac0f8c6e: tty: introduce and use tty_port_tty_vhangup() helper Cc: stable@kernel.org # 2.6.32 Reported-by: syzbot+5fabc1ae99ff40690d84@syzkaller.appspotmail.com Link: https://lore.kernel.org/6a944641.4d659fcc.734b4.003c.GAE@google.com Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260910125114.640880-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 56964f6a31238fb41d5830bb42520c5b10ff7d8f Author: Johan Hovold Date: Tue Sep 8 10:40:00 2026 +0200 tty: tty_port: restore TTY_IO_ERROR on activation failure Make sure to restore the TTY_IO_ERROR flag if activation fails to prevent I/O attempts on a port that is gone or powered down. This specifically avoids issues like kernel panic due to unclocked accesses or NULL-pointer dereferences when accessing powered down or deregistered ports when a TTY ioctl races with hangup and open. Note that the flag is set again in tty_port_close() but not restoring it on activation failure leaves a window where drivers fail to handle the ioctl-hangup race. Fixes: a9a37ec33a1b ("tty: tty_port: Move the IO_ERROR clear") Cc: stable # 2.6.33 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260908084000.218528-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 845a2737e0f5ffe5ca8d38de556012b0c9472cdd Author: Johan Hovold Date: Thu Sep 3 18:37:36 2026 +0200 tty: abort break signalling on hangup The break ioctls can race with hangup and end up calling into a tty driver for a device that is already gone or powered down. Drivers must handle this race, but TCSBRK and TCSBRKP should still be aborted to avoid calling back into the driver after a user-controlled timeout (possibly even after the tty has been reopened). Note that drivers should disable any break state on shutdown so just return on hangup (calling break_ctl() again is racy and will most likely fail for drivers handling the race). Fixes: f34d7a5b7010 ("tty: The big operations rework") Cc: stable Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260903163736.1499280-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 5b114bfc1dfd88f9d50822d532f7f1fce0f7388a Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Mon Aug 3 22:45:56 2026 +0800 tty: vt: fix memory leak in vc_allocate() If the screen buffer allocation fails in vc_allocate(), the error handling path jumps to `err_free`. However, this path fails to release the unicode screen map attached to `vc->uni_pagedict_loc`. During the early stages of vc_allocate(), the unicode screen map is either newly allocated via con_set_default_unimap() or shares the default unicode map from a previously initialized console (which increments its refcount). If the subsequent kzalloc() for the screen buffer fails, the err_free path frees the vc structure but leaves the attached uni_pagedict with an elevated refcount. This results in an unreferenced object memory leak, as the reference to the dictionary is lost and its refcount can never reach zero. This issue was discovered by DevGen (an automated virtual device modeling fuzzer based on Syzkaller). During fuzzing with kernel fault injection (failslab) enabled, the fuzzer forcefully failed the kzalloc() for the screen buffer, exposing this error-handling path leak. Fix this by checking *vc->uni_pagedict_loc and calling con_free_unimap(vc) in the err_free path before kfree(vc). This safely decrements the refcount and releases the dictionary memory if this was the last reference. The explicit check is added to maintain consistency with other callers. Fixes: 34902b7f2754 ("tty: vt, get rid of weird source code flow") Cc: stable Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Link: https://patch.msgid.link/20260803144556.163856-1-25181214217@stu.xidian.edu.cn Signed-off-by: Greg Kroah-Hartman commit 24b620729e53d978b3e425f55bc66efd3bab1f59 Author: Puranjay Mohan Date: Mon Aug 10 06:35:36 2026 -0700 perf/core: Fill branch entries with a single assignment perf_clear_branch_entry_bitfields() clears the bitfields of struct perf_branch_entry one by one and leaves from/to alone, since callers overwrite those straight away. The list has to be kept in sync with the struct by hand and has already fallen behind: new_type and priv were added to perf_branch_entry and never added here. Only BRBE writes those two, and neither for every record. brbe_set_perf_entry_type() leaves new_type alone for a branch type it does not recognise, and priv is not set for source-only records. arm_pmuv3.c allocates the per-CPU branch stack with kmalloc(), so such a record reaches userspace with whatever the slot held: uninitialised kmalloc() data on the first pass over the buffer, the previous record's values after that. Nothing under arch/x86/events/ writes either field, so only arm64 is affected. Assign the whole entry at each site instead. Everything not named is then zero, and there is no list to keep in sync. The bitfields add up to exactly 64 bits, so the struct has no padding to leave undefined. perf_clear_branch_entry_bitfields() has no callers left, so remove it. perf_entry_from_brbe_regset() assigns an empty literal instead, since it fills from/to conditionally. PERF_BR_SPEC_NA is 0, so dropping the explicit spec assignment changes nothing. Fixes: b190bc4ac9e6 ("perf: Extend branch type classification") Fixes: 5402d25aa571 ("perf: Capture branch privilege information") Suggested-by: Peter Zijlstra Signed-off-by: Puranjay Mohan Signed-off-by: Peter Zijlstra (Intel) Tested-by: Yifan Wu Link: https://patch.msgid.link/20260810133540.1947118-4-puranjay@kernel.org commit 3d8d74100954a3b17e5c5e37adfe14e16b1db103 Author: Puranjay Mohan Date: Mon Aug 10 06:35:35 2026 -0700 perf/core: Run sched_task() for PMUs with only CPU-wide events perf_pmu_sched_task() returns early when cpuctx->task_ctx is set and leaves the work to perf_ctx_sched_task_cb(), which only walks ctx->pmu_ctx_list. A PMU whose events are all CPU-wide is not on that list, so nothing calls its sched_task(). With perf record -b -e cycles -a -- ls armv8pmu_sched_task() is skipped on every switch to a task that has a perf context but no event on that PMU, and BRBE records leak across the task boundary. intel_pmu_lbr_add() calls perf_sched_cb_inc() unconditionally too, so LBR records leak the same way on x86. Drop the early return and skip only the CPCs that perf_ctx_sched_task_cb() handles. That one needs a gate of its own to make the split exact: it tests cpc->sched_cb_usage, which perf_sched_cb_inc() sets per CPU for every branch stack user, so a task with an event for that PMU pinned to another CPU would be handled twice. On x86 the second __intel_pmu_lbr_restore() finds lbr_stack_state == LBR_NONE and calls intel_pmu_lbr_reset(), throwing away the callstack the first one restored. cpc->task_epc is set only while a task context is scheduled in, and there is one epc per PMU on ctx->pmu_ctx_list, so the two gates are inverses. For the CPCs perf_pmu_sched_task() picks up, the callback now runs outside the perf_ctx_disable() and perf_ctx_enable() pair in perf_event_context_sched_in(). __perf_pmu_sched_task() disables the PMU around the call itself. Fixes: bd2756811766 ("perf: Rewrite core context handling") Signed-off-by: Puranjay Mohan Signed-off-by: Peter Zijlstra (Intel) Tested-by: Yifan Wu Link: https://patch.msgid.link/20260810133540.1947118-3-puranjay@kernel.org Cc: stable@vger.kernel.org commit 36bb85cf36cab15fb611cb44b78a5df06e4e69a2 Author: Puranjay Mohan Date: Mon Aug 10 06:35:34 2026 -0700 perf/core: Fix NULL pmu_ctx passed to pmu->sched_task() perf_pmu_sched_task() returns early when cpuctx->task_ctx is set, and cpc->task_epc is only non-NULL while a task context is scheduled in on this CPU. __perf_pmu_sched_task() therefore always passes NULL: Unable to handle kernel NULL pointer dereference at virtual address 00 pc : armv8pmu_sched_task+0x14/0x50 Call trace: armv8pmu_sched_task+0x14/0x50 (P) perf_pmu_sched_task+0xac/0x108 __perf_event_task_sched_out+0x6c/0xe0 Pass &cpc->epc instead, the CPU-wide context for this PMU, which the function already dereferences a few lines up to find pmu. armv8pmu_sched_task() is the only in-tree implementation that dereferences the argument, and it only reads ->pmu, so the oops needs BRBE, added in v6.17. Fixes: bd2756811766 ("perf: Rewrite core context handling") Signed-off-by: Puranjay Mohan Signed-off-by: Peter Zijlstra (Intel) Tested-by: Yifan Wu Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260810133540.1947118-2-puranjay@kernel.org commit cca4980630b3c7a85f53cb43c6018184ce5d4e37 Author: Namhyung Kim Date: Sun Sep 20 16:16:39 2026 -0700 perf/core: Fix a refcount leak in attach_perf_ctx_data() The attach_perf_ctx_data() can race on global and !global cases. The global case is protected by global_ctx_data_rwsem and shares a single reference count using perf_ctx_data.global field. But when it races with !global case, it may miss to set the global field and result in a reference count leak. CPU1 CPU2 ---------------------------------------------------------------- attach_task_ctx_data(.global=1) attach_task_ctx_data(.global=0) cd1 = alloc_perf_ctx_data(); cd2 = alloc_perf_ctx_data(); // { .global = 0, .refcount = 1 }; try_cmpxchg(); // success, // task->perf_ctx_data = cd2 try_cmpxhg(); // fail; old = cd2 refcount_inc_not_zero(&old->refcount); // success // old.refcount = 2 free_perf_ctx_data(cd1); Then later detach_global_ctx_data() will see the data but it's not marked as global, so it won't call detach_task_ctx_data(). Fixes: 506e64e710ff ("perf: attach/detach PMU specific data") Assisted-by: Sashiko.dev:Gemini-3.1-pro Signed-off-by: Namhyung Kim Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260920231639.11910-1-namhyung@kernel.org commit 11ea5a63d30ad6d305b1c22301cd99ff45a98c8d Author: Daniel Starke Date: Wed Aug 26 08:30:26 2026 +0200 tty: n_gsm: fix missing modem controls after DLCI open in convergence layer type 2 The current implementation only updates the virtual V.24 control signals after DLCI open in basic option mode. In advanced option mode with convergence layer type 2 an empty data frame needs to be transmitted to inform the peer about the initial virtual V.24 control signals. Not doing so has two unwanted side effects: 1. hardware flow control status is unclear (initial CTS line is unknown) 2. DLCI user presence is not transmitted (initial DTR line is unknown) Applications waiting on these lines can not start after a DLCI has been opened until the first data frame has been transmitted. Fix this by using gsm_modem_update() thoroughly which handles basic and advanced option mode correctly. Add a flag in gsm_modem_update() and the delegated gsm_modem_upd_via_msc() to control whether waiting for the MSC command response is possible. Remove obsolete gsm_modem_send_initial_msc(). Fixes: 3cf0b3c243e5 ("tty: n_gsm: Don't block input queue by waiting MSC") Cc: stable Signed-off-by: Daniel Starke Link: https://patch.msgid.link/20260826063026.2472-1-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit e9438ab5328a177c9c0e5df87eb92a7162841e98 Author: Ridham Khurana Date: Tue Sep 22 09:20:58 2026 +0000 gpio: zynq: fix runtime PM leak on request error path pm_runtime_get_sync() leaves the usage counter incremented even when it fails, and zynq_gpio_request() returns the error without dropping it. gpiolib does not call ->free() when ->request() fails, so zynq_gpio_free(), which holds the only matching pm_runtime_put(), never runs. The reference is leaked and the controller can no longer runtime-suspend, so its clock stays enabled. Switch to pm_runtime_resume_and_get(), which only increments the usage counter on success. Fixes: 3242ba117e9b ("gpio: Add driver for Zynq GPIO controller") Cc: stable@vger.kernel.org Signed-off-by: Ridham Khurana Link: https://patch.msgid.link/20260922092102.1053513-1-khurana.ridham222@gmail.com Signed-off-by: Bartosz Golaszewski commit 3fabd8ec206bd48a45ef77aed170d25b322ad9a2 Author: Benjamin Tissoires Date: Wed Sep 23 10:06:58 2026 +0200 Revert "HID: logitech: add Bolt receiver support for Logitech HID++ devices" This reverts commit 022eb347ff3a48281e7e69c3addcb11bf24afa53. Introducing Bolt as a DJ receiver created a lot of troubles for users with their scroll wheel going crazy. This is because we have 2 issues: - Bolt doesn't say which device sends which event, so having 2 mice connected on the same receiver means one will be normal and the other deadly slow or deadly fast - userspace also tinker with those settings, meaning that users are not happy with the new default settings. The end result is that the feature is not ready for a final kernel, and the sensible thing to do is to revert the patch and revisit it in a later kernel if we can work around the 2 issues I've mentioned above. Link: https://lore.kernel.org/all/DL68726HJQCD.7PCDT9IGHUB1@rcpassos.me/ Link: https://lore.kernel.org/all/20260920094508.39682-1-roman.stingler@gmail.com/ Link: https://lore.kernel.org/all/20260904034843.1340846-1-rafael@rcpassos.me Link: https://lore.kernel.org/all/20260922-feature-bolt-fix-v1-0-63b0fa8da0d3@gmail.com Signed-off-by: Benjamin Tissoires commit 057e5e07420c753f248f9ce148040ab6dcf8359f Author: Peng Fan Date: Wed Sep 16 23:23:33 2026 +0800 iommu/dma: skip swiotlb bounce for DMA_ATTR_MMIO in iommu_dma_map_phys MMIO resources mapped via dma_map_resource() carry DMA_ATTR_MMIO. These never need swiotlb bounce buffering, but the current code enters the swiotlb path when the physical address is not page-aligned, then rejects the mapping because MMIO cannot be bounced. Move the DMA_ATTR_MMIO check before the swiotlb block so the entire bounce path is skipped for MMIO, falling through directly to __iommu_dma_map() which creates the IOVA mapping. Fixes: f9374de14c0e8 ("iommu/dma: implement DMA_ATTR_MMIO for iommu_dma_(un)map_phys()") Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Peng Fan Acked-by: Robin Murphy Link: https://lore.kernel.org/r/20260916-iommu-dma-fix-v1-1-a59a0c45ec5b@nxp.com Signed-off-by: Marek Szyprowski commit 2d2a2d7aa98741b58f54cacc99b52024e4d865f9 Author: Christian Brauner Date: Wed Sep 9 21:30:34 2026 +0200 super: make iterate_supers_type() deletion-safe iterate_supers_type() drops sb_lock while invoking the callback and keeps only a passive reference to the current superblock. That reference keeps the object allocated, but does not keep its s_instances node linked. After the iterator releases s_umount, final teardown can unlink the current s_instances node. The iterator then advances through a reinitialized node. With the current hlist it stops without visiting the remaining superblocks. The unlink moved from generic_shutdown_super() to kill_super_notify(), but the cursor lifetime has been unsafe since the helper was introduced. The CIFS DFS lookup can consequently miss a matching superblock and return -EINVAL. Move removal from fs_supers to put_super(), alongside removal from super_blocks, so a passive reference keeps both list nodes linked. Keep the filesystem module reference until then, since unlinking s_instances may touch type->fs_supers. Make sget_fc() skip SB_DEAD superblocks before invoking test(), and set SB_DEAD under sb_lock to serialize with those callbacks. This allows kernfs to free its private information after kill_anon_super() returns. Keep matching SB_DYING superblocks until SB_DEAD is set so concurrent mounts still wait for teardown before retrying. Fixes: 43e15cdbefea ("new helper: iterate_supers_type()") Reported-by: Karl Mehltretter Closes: https://lore.kernel.org/r/20260903013336.92081-1-kmehltretter@gmail.com Suggested-by: Jan Kara Cc: stable@vger.kernel.org Tested-by: Karl Mehltretter [kmehltretter: supplied the commit message] Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260909193034.7467-1-kmehltretter@gmail.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit 1feb5d39b05afd902ed9fc902ec5b15be03a4bdb Author: Bartosz Golaszewski Date: Tue Sep 22 10:52:28 2026 +0200 gpio: cdev: fix kernel stack leak to user-space in error path If we fail to acquire the GPIO chip guard in gpio_desc_to_lineinfo(), we return immediately before zeroing the info struct we'll end up passing to the user-space later in lineinfo_get_v1(). This may leak the kernel stack contents. Make gpio_desc_to_lineinfo() return int so that the -ENODEV returned on failure to acquire the guard can be propagated to the callers. While not strictly necessary: move the memset() before trying to acquire the SRCU read lock too for good measure. Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260912123529.7951-1-tzungbi%40kernel.org?part=3 Reviewed-by: Kent Gibson Link: https://patch.msgid.link/20260922-gpio-cdev-stack-leak-fixes-v3-1-7a0c7a4299d5@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit fabd3242122872f260cc0a2df9100fe5d6194916 Merge: f615c80a5d3e16 2e2142a35d809c Author: Christian Brauner Date: Wed Sep 23 09:05:56 2026 +0200 Merge patch series "Revert "put_mnt_ns(): leave mounts connected"" Christian Brauner says: Keeping every mount of a dying namespace attached to its parent changes who owns it. An attached but unmounted mount is owned by its parent: the parent's final mntput() is what drops the child's reference and takes its superblock down. Before that commit only the namespace root was in that position and every other mount dropped its own reference in namespace_unlock(). That ownership rule turns any reference from a child's superblock back to one of its ancestors into a cycle. The obvious case is a loop device: unshare -m sh -c 'mount -o loop /var/tmp/img /var/tmp/mp' mount(8) opens the image from inside the new namespace, so the loop device's backing file pins that namespace's copy of the root mount. When the namespace dies the loop mount stays attached to that copy and is owned by it. The copy can't reach zero because the backing file holds it. The backing file is only put once the ext4 superblock releases the block device and autoclear runs, and that needs the loop mount to go first. Nothing breaks the cycle. The superblock, the loop device and, since the root copy keeps all of its children. systemd-sysext sets up its loop devices in a private mount namespace and relies on autoclear when that namespace goes away, which is how this was found. Anything that holds a file on an ancestor from a mounted filesystem has the same problem. That includes ecryptfs lower paths, erofs file-backed mounts, fuse passthrough backing files. That's a bigger fix and not an -rc change. Revert. * patches from https://patch.msgid.link/20260917-work-put_mnt_ns-revert-v1-0-34d9b8679e68@kernel.org: Revert "put_mnt_ns(): leave mounts connected" Revert "selftests/filesystems: add mntns cleanup test" Link: https://patch.msgid.link/20260917-work-put_mnt_ns-revert-v1-0-34d9b8679e68@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 2e2142a35d809c3cc726d3b39e7aeee98d9ab71c Author: Christian Brauner Date: Thu Sep 17 13:49:04 2026 +0200 Revert "put_mnt_ns(): leave mounts connected" This reverts commit 0342482a4d15358fe6931606caf58968de5d1d38. Keeping every mount of a dying namespace attached to its parent changes who owns it. An attached but unmounted mount is owned by its parent: the parent's final mntput() is what drops the child's reference and takes its superblock down. Before that commit only the namespace root was in that position and every other mount dropped its own reference in namespace_unlock(). That ownership rule turns any reference from a child's superblock back to one of its ancestors into a cycle. The obvious case is a loop device: unshare -m sh -c 'mount -o loop /var/tmp/img /var/tmp/mp' mount(8) opens the image from inside the new namespace, so the loop device's backing file pins that namespace's copy of the root mount. When the namespace dies the loop mount stays attached to that copy and is owned by it. The copy can't reach zero because the backing file holds it. The backing file is only put once the ext4 superblock releases the block device and autoclear runs, and that needs the loop mount to go first. Nothing breaks the cycle. The superblock, the loop device and, since the root copy keeps all of its children. systemd-sysext sets up its loop devices in a private mount namespace and relies on autoclear when that namespace goes away, which is how this was found. Anything that holds a file on an ancestor from a mounted filesystem has the same problem. That includes ecryptfs lower paths, erofs file-backed mounts, fuse passthrough backing files. That's a bigger fix and not an -rc change. Revert. Fixes: 0342482a4d15 ("put_mnt_ns(): leave mounts connected") Reported-by: Michael Vogt Link: https://gist.github.com/mvo5/63ef46482349f3b1c3957d463a0c9c6f Link: https://patch.msgid.link/20260917-work-put_mnt_ns-revert-v1-2-34d9b8679e68@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 76ebb69da677d2a4c5e59bf758b6424d511f5684 Author: Christian Brauner Date: Thu Sep 17 13:49:03 2026 +0200 Revert "selftests/filesystems: add mntns cleanup test" This reverts commit 3452eecbcc954ef859b7d19309c121a78d6d0e31. The test checks that the mounts of a destroyed mount namespace stay connected. The commit that made them stay connected is reverted next because it leaks superblocks and loop devices, so drop the test with it. Link: https://patch.msgid.link/20260917-work-put_mnt_ns-revert-v1-1-34d9b8679e68@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 6db1ce73e9853f533eb7f413f14ba00f8ec6f80d Author: Weiming Shi Date: Sun Sep 20 21:23:04 2026 +0800 bpf: Reject dev-bound-only programs on other devices __bpf_offload_dev_match() falls back to comparing offdev pointers after an exact netdev mismatch. Bound-only programs normally have NULL offdevs, so unrelated netdevs compare equal. A bound-only program on an offload-registered netdev can instead inherit a real offdev and match a sibling port. With CAP_BPF and CAP_NET_ADMIN, a caller can use bpf(BPF_LINK_CREATE) with a different target ifindex to run metadata kfuncs specialized for the bound driver on the target driver's xdp_buff. Running a veth-bound program on tun reads beyond tun's bare stack xdp_buff as a veth_xdp_buff. Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:veth_xdp_rx_timestamp (drivers/net/veth.c:1673) Call Trace: ... tun_build_skb (drivers/net/tun.c:1739) tun_get_user (drivers/net/tun.c:1856) tun_chr_write_iter (drivers/net/tun.c:2091) vfs_write (fs/read_write.c:595 fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt Restrict non-offloaded programs to exact netdev matches and retain the shared-offdev fallback only for genuinely offloaded multi-port programs. Fixes: 2b3486bc2d23 ("bpf: Introduce device-bound XDP programs") Reported-by: Signed-off-by: Weiming Shi Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20260917161335.1020405-2-bestswngs@gmail.com/ Link: https://patch.msgid.link/20260920132303.4109240-3-bestswngs@gmail.com commit 9c572a83037a7dcd653ba3a9cc468c16b857d0c9 Author: Bernard Ladenthin Date: Fri Sep 18 15:39:37 2026 +0200 net/sched: fix potential stack infoleak in em_text_dump() em_text_dump() allocates struct tcf_em_text on the stack without zeroing it. strscpy() writes the algorithm name and a NUL terminator into conf.algo[], leaving the remaining bytes uninitialised. nla_put_nohdr() then copies the full struct to the netlink response. KMSAN on Linux 7.2-rc6 reports two kernel-infoleak splats from this path, one triggered via "tc filter show" and one via a raw RTM_GETTFILTER dump: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x1c9/0x2620 nla_put_nohdr+0x83/0x130 em_text_dump+0x291/0x550 Local variable conf created at: em_text_dump+0x5d/0x550 Bytes 168-179 of 199 are uninitialized I am not certain whether this constitutes a real security problem in practice: the test was conducted in a controlled KMSAN environment and the leaked stack bytes may or may not carry sensitive data on actual production kernels. I am reporting it because KMSAN flagged it as a kernel-infoleak and the fix is straightforward. I can provide a userspace reproducer on request. The original code used strncpy() which zero-pads to the destination size. Commit b04202d6065c ("net/sched: replace strncpy with strscpy") replaced it with strscpy(), which does not pad, creating this condition. Zero-initialising the struct closes it. Fixes: b04202d6065c ("net/sched: replace strncpy with strscpy") Link: https://lore.kernel.org/netdev/20250327143733.187438-1-richard120310@gmail.com/ Assisted-by: Claude:claude-sonnet-4-6 [KMSAN] Signed-off-by: Bernard Ladenthin Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260918133953.12494-1-bernard.ladenthin@gmail.com Signed-off-by: Jakub Kicinski commit 0160953d8eec75c3c55562158c46442ff1fd410b Author: Björn Töpel Date: Fri Sep 18 13:46:40 2026 +0200 eth: fbnic: Avoid rounding zero ring sizes roundup_pow_of_two() is undefined for zero. ethtool permits a zero ring size to reach the driver, where the minimum-size check should reject it. Leave zero unchanged while rounding nonzero ring sizes. The minimum-size check then rejects zero deterministically without changing the established behavior for other values. Fixes: 6cbf18a05c06 ("eth: fbnic: support ring size configuration") Reported-by: Sashiko Link: https://lore.kernel.org/netdev/178971206933.22033.236948278674126701@kernel.org/ Suggested-by: Alexander Duyck Signed-off-by: Björn Töpel Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260918114641.1281172-1-bjorn@kernel.org Signed-off-by: Jakub Kicinski commit f764634137842b98440931b63b046a0c685c9163 Merge: 73b3fc67a493e9 c4ac6e94eb9423 Author: Jakub Kicinski Date: Tue Sep 22 18:51:19 2026 -0700 Merge branch 'net-stmmac-more-selftest-related-fixes' Maxime Chevallier says: ==================== net: stmmac: More selftest-related fixes This is V4 of stmmac selftest fixes, addressing Sashiko's issues over the MTU patch. This lead to the introduction of a new one. The dev_add_pack races have been addressed, however the double-vlan issue stayed there. Ovidiu is actively working on it, let's wait for his work to land before fixing that. This is another round of stmmac selftest fixes, mostly about the selftests themselves but a few things were discovered w.r.t MTU and buffer size handling, see patch 5 anf 6. After this is merged, I consider the selftests to be now reliable enough to run them nightly on every stmmac series that's sent, and I'll be requiring clean selftests for new glue drivers. Since V3, the testing farm grew ! I've been running this on : - Altera CycloneV (dwmac-socfpga, dwmac1000 IP, v3.70a) - NXP imx8mp (dwmac-imx, dwmac4, v5.10a) - Allwinner H2S (dwmac-sun8i, dwmac1000) - Amlogic S905X3 (dwmac-meson8b, dwmac1000, v3.70a) - STM32mp157a (dwmac-stm32, dwmac4, v4.20a) - SiFive JH7110 (dwmac-starfive, dwmac4, v5.20) - Motorcomm YT8061 (PCIe, dwmac-motorcomm, dwmac4) - Qualcomm IPQ8064 (dwmac-ipq806x, dwmac1000) - Altera AgileX5 (dwmac-socfpga, dwxgmac2 !) (NEW) - Generic dwmac1000 (Loongson 2K0300, dwmac 3.70a) (NEW) - Rockchip RK3566 (dwmac-rk, dwmac4) (NEW) It's becoming cumbersome to list the test results here, they can be found, updated daily, here : https://minimaxwell.github.io/stmmac-ci/ ==================== Link: https://patch.msgid.link/20260917215339.2022523-1-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit c4ac6e94eb9423126bda907a7f2933284f7450ff Author: Maxime Chevallier Date: Thu Sep 17 23:53:38 2026 +0200 net: stmmac: selftests: Account for alignment shift on dwmac1000 for Jumbo test On dwmac1000, we currently only support single-descriptor frames. The Jumbo test started failing when NET_IP_ALIGN was added to align the IP header, as this tests tries to send the biggest possible frame. On dwmac1000 the DMA transfer is aligned on 4-bytes, so adding a 2-byte shift at the start-of-buffer address means it takes a whole extra 4-byte DMA burst to receive the Jumbo packet, causing it to spill over the next descriptor. This doesn't seem to happen on dwmac4 and xgmac that appear to correctly handle unaligned xfers (only tested on dwmac4) Let's account for that in the Jumbo test, reduce the size of our big packet by the align size. Fixes: 23680bf5f8c6 ("net: stmmac: restore NET_IP_ALIGN in the RX DMA offset") Reviewed-by: Nicolai Buchwitz Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260917215339.2022523-8-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit b8a26d46c0a4254f8bfe143681adb9d18d020299 Author: Maxime Chevallier Date: Thu Sep 17 23:53:37 2026 +0200 net: stmmac: size the RX buffers from the frame length, not the MTU When picking the buffsize to use based on the MTU, we shouldn't check only the MTU value, but also : - ETH_HLEN for the L2 header, - up to 2 VLAN tags, - the FCS, The default bufsize is 1536 bytes, which is enough to contain all the above so this hasn't surfaced before, but the addition of NET_IP_ALIGN to the start of buffer address tripped the Jumbo selftest, leading to this discovery. With that, we don't need the '>=' checks on the buffer len, we can use more consistent comparison operators in stmmac_set_bfsize. Fixes: 286a83721720 ("stmmac: add CHAINED descriptor mode support (V4)") Reviewed-by: Nicolai Buchwitz Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260917215339.2022523-7-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit b42e7012773a0e81e97a2dda6ef907f5147a6658 Author: Maxime Chevallier Date: Thu Sep 17 23:53:36 2026 +0200 net: stmmac: dwmac4: Use the correct bufzise when the len is exactly 8K DMA bufsize selection isn't made on the MTU but the actual frame length, so including the L2 header. On DWMAC4, if the len is exactly BUF_SIZE_8KiB, the next larger size is incorrectly selected. Lets fix the comparison and while at it, rename the parameter from len to mtu. Fixes: c3efed5ad1b0 ("net: stmmac: Enable dwmac4 jumbo frame more than 8KiB"). Signed-off-by: Maxime Chevallier Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260917215339.2022523-6-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit 960db6f65788c21249ea04a947d5c01e38d19294 Author: Maxime Chevallier Date: Thu Sep 17 23:53:35 2026 +0200 net: stmmac: selftests: Capture all packets for vlan checks While we use vlan_vid_add to trigger the tag filtering machinery in the driver, there's no netdev associated to the VLAN. This causes the skb to arrive with empty skb->vlan_tci fields, as the packet is marked OTHERHOST in __netif_receive_skb_core(), and we fail our validation. Let's use the proxy mechanism introduced for DSA, that registers a ETH_P_ALL packet handler that runs earlier, before the vlan netdev lookup, then filters for the correct ethertype before passing an skb clone to our validation function. As we may receive external frames with the right tag from the outside, let's move the address check in the vlan validation function earlier. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Reviewed-by: Nicolai Buchwitz Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260917215339.2022523-5-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit ba804b23d76d278ee475b8427fa7c5623ce5e270 Author: Maxime Chevallier Date: Thu Sep 17 23:53:34 2026 +0200 net: stmmac: selftests: Check the dev->features for S-TAG offload testing The S-TAG offload insertion incorrectly checks the dvlan (double vlan) DMA cap, which is different than S-TAG support. Use NETIF_F_HW_VLAN_STAG_TX to check if the feature is supported instead. Note that this flag isn't set in stmmac yet, but contrary to ARP offload, this is a feature that has a chance to get there eventually so let's leave the selftest here for now. It'll report -EOPNOTSUPP in the meantime. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Reviewed-by: Nicolai Buchwitz Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260917215339.2022523-4-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit c8c1795aa8106293020a836d01e127e98f442925 Author: Maxime Chevallier Date: Thu Sep 17 23:53:33 2026 +0200 net: stmmac: selftests: Validate EEE based on the actual LPI timer value The EEE selftest is a 2-step test : - It validates that we enter in LPI mode with the irq_tx_path_in_lpi_mode_n counter - It then validates that we exit LPI when sending a frame, with the irq_tx_path_exit_lpi_mode_n counter. The current state of the test lacks 2 main things : - We don't know exactly when was the previous frame sent (it's from the previous selftest) - The timeout is hardcoded, while the LPI is entered after a user-configurable delay. On top of that, the timeout loop uses a pre-decrement iterator (--retries) that actually only iterate nine times, so 900ms while the default LPI value is 1 second. Let's therefore make it more deterministic : - Send a frame at the beginning of the test - Wait for more than the lpi timer value, we timeout after about twice the value, - Then send another frame, and verify that we do go out of LPI, also with a timeout. As LPI timer can get pretty high, bail out if LPI timer is over 5 seconds. Note that the test's goal isn't to validate the LPI timer value itself, only that we enter/leave LPI mode. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Reviewed-by: Nicolai Buchwitz Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260917215339.2022523-3-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit d68acbf93531abdb5b02b21994cd4c15a3c95b42 Author: Maxime Chevallier Date: Thu Sep 17 23:53:32 2026 +0200 net: stmmac: selftests: Support running selftests on DSA conduits Most stmmac selftests rely on dev_add_pack() to add custom handlers, that validate the packets sent to ourselves through MAC loopback. However, when the stmmac-driven interface is a DSA CPU conduit, all frames that are received have ETH_P_XDSA as a protocol, even though they don't actually contain any tag as they come from the loopback and not the switch. This will prevent any incoming packet to match our packet handlers. Let's register a ETH_P_ALL packet handler when we detect that we're a DSA conduit, and use a proxy packet handler to filter the h_proto. As this allows external frames to be received through our .func(), the packet handler is added after the dev->addr field is populated in our selftest attributes. Note that we may still receive incoming packets from the switch, but these frames shouldn't interfere with the very specific frames used for selftests, and stmmac selftests in general aren't safe against external traffic interferences. This was validated on a WPQ864 devkit for IPQ8064, that has the SoC connected to a QCA8k switch. The ARP offload's packet handler is left alone, this feature is just not implemented in stmmac and due for removal. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Reviewed-by: Nicolai Buchwitz Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260917215339.2022523-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit 73b3fc67a493e9b9a8e94a38839f6638d12fe7a6 Author: Mina Almasry Date: Mon Sep 21 19:54:12 2026 +0000 net: devmem: document that bind-tx is unprivileged by design Unlike bind-rx, which configures shared NIC RX queues to steer incoming traffic into the caller's dmabuf and requires CAP_NET_ADMIN (uns-admin-perm), bind-tx only DMA-maps the caller's dmabuf so the caller can transmit from it on their own sockets without affecting other traffic or device configuration. Add a comment in netdev.yaml and above netdev_nl_bind_tx_doit() to make it explicit that NETDEV_CMD_BIND_TX is unprivileged by design. Signed-off-by: Mina Almasry Acked-by: Stanislav Fomichev Acked-by: Daniel Borkmann Link: https://patch.msgid.link/20260921195545.493253-1-almasrymina@google.com Signed-off-by: Jakub Kicinski commit cae23ae3f7887a1cf8a75da38edcebeef695040f Author: Xin Long Date: Mon Sep 21 14:03:45 2026 -0400 sctp: hold asoc or transport before mod_timer() in timer handlers Take the association or transport reference before rearming a timer in the timer handlers. The existing code calls mod_timer() before taking the reference needed by the rearmed timer without holding the sock lock. This creates a race with timer cleanup: if the timer is deleted after mod_timer() returns but before the reference is taken, the cleanup path can drop the timer's reference and destroy the transport or association. The timer handler then takes a reference on the already freed object and eventually drops it, causing a refcount underflow. Hold the object before mod_timer() and drop the reference if mod_timer() reports that the timer was already pending in timer handlers. Apply the same ordering to the proto-unreachable path, which can rearm a transport timer outside the timer handlers without holding the sock lock. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Tangxin Xie Signed-off-by: Xin Long Link: https://patch.msgid.link/c31b5e3ee2b7274e804f5eba2f21e2412e7eef7a.1790013825.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski commit 6836807c5f685f83975e45c77c937eb5e79da31e Merge: 4498467a8af06c 9518405613863d Author: Jakub Kicinski Date: Tue Sep 22 18:33:03 2026 -0700 Merge branch 'packet-fix-packet_tx_ring-data-corruption-on-skb_orphan' Willem de Bruijn says: ==================== packet: fix PACKET_TX_RING data corruption on skb_orphan When transmitting packets via PACKET_TX_RING, tpacket_snd links user ring buffer pages as skb frags and releases the slot on skb->destructor (tpacket_destruct_skb). skb_orphan() invokes the destructor while the skb is still alive. This marks the slot as TP_STATUS_AVAILABLE prematurely, allowing userspace to overwrite the slot and causing data corruption. This series fixes the issue by switching PACKET_TX_RING to standard ubuf_info zerocopy completion, ensuring ring slots are released only after all payload references are freed or copied. Virtio-net needs a separate solution, because deferring the release can cause deadlock in its !use_napi mode. - Patch 1 addresses the virtio-net special case. - Patch 2 converts tpacket_snd to standard ubuf_info completion Patch 1 must be applied, and backported, before patch 2. Both carry the same Fixes tag for that reason. v1: https://lore.kernel.org/netdev/20260914214229.1674102-1-willemdebruijn.kernel@gmail.com/ ==================== Link: https://patch.msgid.link/20260919004748.1463985-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski commit 9518405613863d0bf0700927a21367f5942cf058 Author: Willem de Bruijn Date: Fri Sep 18 20:47:29 2026 -0400 packet: use ubuf_info completion for TX_RING packets tpacket_snd sends skbs with frags pointing into its ring slots. Slots are released when skb->destructor is called. A call to skb_orphan calls skb->destructor before the skb is freed. This can cause the slot to be reused while still linked into the skb. Switch to standard zerocopy completion (ubuf_info) so the slot is only released once all references to the payload are freed or copied. Restore skb->destructor to standard sock_wfree. The ubuf_info completion callback can be called with a NULL skb, but only from net_zcopy_put and related API, used by zerocopy implementations that hold their own reference on the uarg, such as MSG_ZEROCOPY. This uarg is only ever completed from skb_zcopy_clear, so skb is always set. To prevent userspace from aliasing in-flight state on shared ring slots, allocate tpacket_uarg per packet, rather than per slot. This adds a small allocation to the transmit path. Use standard kmalloc to allow backporting to stable kernels. The uarg holds an sk_wmem_alloc reference, rather than an sk_refcnt reference. packet_free_tx_ring waits on sk_wmem_alloc before freeing the ring pages. Always allocate vec->deferred for tx_ring so page-backed rings also wait on sk_wmem_alloc when skb_copy_ubufs drops page refs before calling tpacket_ubuf_complete. Drop the tx_ring.pg_vec test that tpacket_destruct_skb performed before accessing the slot. The sk_wmem_alloc reference now guarantees that the slot is valid. The test is also not sufficient by itself, as it reads pg_vec without pg_vec_lock, so it can race with packet_set_ring. As a result a slot is released when its payload is copied, which can be before transmission (e.g., in skb_orphan_frags_rx). If copied before skb_tx_timestamp() is called, no slot timestamp is recorded, similar to when skb_orphan() was called early in the datapath before this patch. Revert the now unused previous skb_zcopy_.._nouarg infra. Depends on commit 992cc9f94ca9 ("net/packet: defer vmalloc TX_RING free until skbs finish"). Reported-by: Katherine Leaver Reported-by: Bjoern Doebel Closes: https://lore.kernel.org/netdev/20260909085542.3370986-1-doebel@amazon.de/ Fixes: 5cd8d46ea156 ("packet: copy user buffers before orphan or clone") Cc: stable@vger.kernel.org Signed-off-by: Willem de Bruijn Link: https://patch.msgid.link/20260919004748.1463985-3-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski commit 07e1a9408b6c2f9d0cfb757b67dabb52da7a32b2 Author: Willem de Bruijn Date: Fri Sep 18 20:47:28 2026 -0400 virtio_net: copy zerocopy frags in start_xmit without NAPI Virtio-net without NAPI frees completed skbs lazily on the next start_xmit. Senders waiting for in-flight zerocopy buffers can deadlock if they cannot transmit more packets, as then no completed packets will be freed. When !use_napi, virtio-net already calls skb_orphan to avoid waiting up for transmitted skbs to be freed. For zerocopy packets that require deep copying on orphan (i.e. those that do not set SKBFL_DONT_ORPHAN, such as PACKET_TX_RING), call skb_orphan_frags before orphaning to release the buffers. This fixes the tpacket_snd slot reuse bug on skb_orphan for virtio-net, and prevents PACKET_TX_RING from running out of slots. This fix also touches vhost_net zerocopy packets, which also do not set SKBFL_DONT_ORPHAN. This is fine: vhost_net packets only encounter virtio-net in nested virtualization, and only if napi_tx is explicitly disabled (it has been default-enabled since Linux 4.12). In that rare case, copying the frags is desirable anyway to prevent holding guest descriptors pinned across unbounded intervals. This is a prerequisite for the next patch, which converts PACKET_TX_RING to standard zerocopy completion. Without this patch first, a bounded ring sender can stall indefinitely behind a virtio-net virtqueue that cannot reclaim. Fixes: 5cd8d46ea156 ("packet: copy user buffers before orphan or clone") Cc: stable@vger.kernel.org Cc: mst@redhat.com Cc: jasowangio@gmail.com Signed-off-by: Willem de Bruijn Link: https://patch.msgid.link/20260919004748.1463985-2-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski commit 4498467a8af06cfa3d71cb04bd7c4170dec8f449 Author: Aohan Mei Date: Mon Sep 21 17:37:04 2026 +0800 sctp: discard the rest of the packet on a stale-cookie error When an association is in COOKIE-ECHOED state and the peer sends a bundled [ERROR(Stale Cookie)][DATA] packet from one of its non-primary addresses, processing the ERROR chunk takes the non-fatal stale-cookie retry path sctp_sf_do_5_2_6_stale(), which queues SCTP_CMD_DEL_NON_PRIMARY while keeping the association alive. sctp_cmd_del_non_primary() removes every non-primary transport - including the very transport this packet arrived on, which is still referenced by the receive lookup and shared by all chunks of the packet via chunk->transport. sctp_assoc_rm_peer() does redirect asoc->peer.last_data_from away from the removed transport, but right afterwards the bundled DATA chunk makes sctp_assoc_bh_rcv() re-register asoc->peer.last_data_from = chunk->transport unconditionally, undoing the redirection with the just-removed transport. Once the packet is done, the receive reference is dropped and the transport is RCU-freed, while the surviving association keeps the dangling last_data_from. A later FWD-TSN (or the delayed SACK timer) makes sctp_gen_sack() dereference it (->param_flags and friends), and sctp_make_sack()/sctp_outq_select_transport() may write to the freed object and link it into the live transport list. This is a use-after-free triggerable by any malicious SCTP peer (or a local unprivileged user acting as one) with no capabilities required: BUG: KASAN: slab-use-after-free in sctp_do_sm+0x498a/0x5660 Read of size 4 at addr ffff88800e1e356c by task poc/115 Call Trace: sctp_do_sm <- sctp_assoc_bh_rcv <- sctp_inq_push <- sctp_rcv <- ip_protocol_deliver_rcu <- ip_rcv Allocated: sctp_transport_new <- sctp_assoc_add_peer <- sctp_process_init (INIT-ACK processing) Freed: kfree <- sctp_transport_destroy_rcu <- rcu_core (call_rcu queued by sctp_transport_put at end of sctp_rcv) The buggy address is located 364 bytes inside of freed 1024-byte region [ffff88800e1e3400, ffff88800e1e3800), cache kmalloc-1k Note that commit 03a9d10ecf71 ("sctp: drop a chunk if its transport was removed") only covers the window between the receive lookup and the chunk processing (e.g. an ASCONF DEL-IP racing the socket backlog); here the transport is removed *while* the packet is being processed, by an earlier chunk of the same packet, so the drop in sctp_inq_push() does not reach this path. Verified with the bundled [ERROR(Stale Cookie)][DATA] + FWD-TSN reproducer: the KASAN report above still fires with that commit applied, and is gone with this patch on top. Fix it by discarding the rest of the packet on this path, as suggested by Xin. After the stale-cookie ERROR has sent the association back to COOKIE-WAIT and removed the non-primary transports, the remaining chunks of the packet can only run against the restarted handshake while referencing the removed arrival transport through chunk->transport: besides the last_data_from registration above, sctp_cmd_setup_t2() and the sctp_make_*() reply builders would also copy that pointer into association-lifetime state that sctp_assoc_rm_peer() has already sanitized. Let the peer retransmit them, in line with what sctp_inq_push() does for chunks whose transport was removed before processing. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Xin Long Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Signed-off-by: Aohan Mei Acked-by: Xin Long Link: https://patch.msgid.link/20260921093707.1432184-1-ljp1205831794@gmail.com Signed-off-by: Jakub Kicinski commit 031fe051abb3c1f36c2ba6346931fcdb3cddaeae Author: Fredric Cover Date: Tue Sep 22 10:37:59 2026 -0700 smb: client: use GFP_KERNEL in get_targets() Currently, get_targets() uses GFP_ATOMIC to allocate the cache target iterator and to duplicate t->name. The callers of get_targets() are in a sleepable context; therefore, switch to GFP_KERNEL to reduce risk of failure and reduce pressure on emergency pools in low-memory scenarios. Signed-off-by: Fredric Cover Signed-off-by: Paulo Alcantara commit a1259e92e1e892f009bbebf23e1207b02e2d5708 Author: ZhangGuoDong Date: Mon Sep 21 09:41:28 2026 +0800 smb: client: update POSIX extension specification references The POSIX extension specifications have now been published: https://smb3posix.org/ Suggested-by: Paulo Alcantara Reviewed-by: ChenXiaoSong Signed-off-by: ZhangGuoDong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 0bf6bb567f0edaa771e7dd208ef98da50e6a4485 Author: Wentao Liang Date: Thu Sep 17 11:31:31 2026 +0000 net/mlx5: Fix rev_entry reference leak in mlx5_tc_ct_shared_counter_get() When the reverse entry is found but its counter is already being released, refcount_inc_not_zero() fails and the reference taken by mlx5_tc_ct_entry_get() is never dropped before falling through to create_counter. Drop it so the reverse entry is not kept alive forever by a shared counter lookup that did not use it. Fixes: 1edae2335adf ("net/mlx5e: CT: Use the same counter for both directions") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260917113131.2149024-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski commit 1c34493df92146304e63cc51b9ca60fca847dd43 Merge: 17741334d00bf5 2e51097c982b7b Author: Jakub Kicinski Date: Tue Sep 22 18:09:23 2026 -0700 Merge branch 'net-mlx5-bridge-fix-remaining-switchdev-ownership-gaps-on-merged-eswitch' Bernardo Soares says: ==================== net/mlx5: Bridge, fix remaining switchdev ownership gaps on merged eswitch ==================== Link: https://patch.msgid.link/20260918095931.29792-1-bsoares.it@gmail.com Signed-off-by: Jakub Kicinski commit 2e51097c982b7b22382fda3202ba29f0ea33e8c0 Author: Bernardo Soares Date: Fri Sep 18 10:59:31 2026 +0100 net/mlx5: Bridge, don't fail unlink of untracked/unsupported peer ports mlx5_esw_bridge_vport_unlink() returns -EINVAL when the port isn't tracked by this instance's br_offloads. This is reachable on a sibling instance that registered its notifier after the port was already enslaved: it never saw the NETDEV_CHANGEUPPER link event, so peer_link() never created a peer port for it, but it does see the later unlink event and fails. Return 0 instead, and give mlx5_esw_bridge_vport_peer_unlink() the same merged_eswitch capability guard peer_link() already has, since without it peer_link() likewise never creates a port to unlink. This also matters beyond the -EINVAL itself: mlx5_esw_bridge_switchdev_port_event() runs on the per-netns netdev_chain, and notifier_from_errno(-EINVAL) sets NOTIFY_STOP_MASK, which call_netdevice_notifiers_info() checks to stop calling further listeners on that chain - so the old -EINVAL silently dropped the event for any listener registered later on the same chain, even though none of it was visible to user space since __netdev_upper_dev_unlink() discards the return value. Fixes: c358ea1741bc ("net/mlx5: Bridge, allow merged eswitch connectivity") Signed-off-by: Bernardo Soares Reviewed-by: Mark Bloch Link: https://patch.msgid.link/20260918095931.29792-3-bsoares.it@gmail.com Signed-off-by: Jakub Kicinski commit 35e6f970f553954d92ba20afa885139a8e7dd0d7 Author: Bernardo Soares Date: Fri Sep 18 10:59:30 2026 +0100 net/mlx5: Bridge, don't fail switchdev events of sibling eswitch ports mlx5 registers the bridge offload switchdev notifiers once per eswitch instance, but the notifier chains are global, so every instance sees every event and must filter out the ones that aren't its own. The existing filter, mlx5_esw_bridge_dev_same_hw(), only checks that the event netdevice sits on the same HCA - intentional for merged eswitch, where one bridge can span representors of several eswitches on one HCA - but same-HCA doesn't mean the instance actually has that port: peer ports are only created reactively from NETDEV_CHANGEUPPER, so an instance brought up after a sibling PF's port was already enslaved has none. The port object and attribute handlers claim the event anyway once same-HW passes, then fail the port lookup and return -EINVAL, which gets reported to user space even though the owning instance already handled it (e.g. "bridge vlan add ... RTNETLINK answers: Invalid argument"). Fix by filtering on the tracked port instead. The same gap exists in the generic recursive lower-device walk used by attribute changes on a bridge with more than one representor enslaved directly: mlx5_esw_bridge_lower_rep_vport_num_vhca_id_get() is entered with the bridge master netdevice, falls through to its generic netdev_for_each_lower_dev() loop, and returns as soon as the recursion into any one lower device yields a non-NULL rep - the underlying base case, mlx5_esw_bridge_rep_vport_num_vhca_id_get(), only checks mlx5_esw_bridge_dev_same_hw(), not ownership by the calling instance's br_offloads. mlx5_esw_bridge_lag_rep_get(), used for the LAG-master case, already filters on mlx5_esw_bridge_dev_same_esw() per candidate and so cannot select a sibling's rep; it is not the source of this bug. On a merged-eswitch HCA with a bridge spanning representors of more than one eswitch instance directly, the walk can return a sibling's rep instead of continuing to the one the calling instance actually owns, so the attribute change fails the same way as above. Fix by checking mlx5_esw_bridge_port_exists() at the point each rep is picked, same as the previous fix did for the notifier filter. Fixes: c358ea1741bc ("net/mlx5: Bridge, allow merged eswitch connectivity") Signed-off-by: Bernardo Soares Cc: Vlad Buslov Cc: Saeed Mahameed Reviewed-by: Mark Bloch Link: https://patch.msgid.link/20260918095931.29792-2-bsoares.it@gmail.com Signed-off-by: Jakub Kicinski commit c6b51091cafff9ce6c03c1416aa13864d17ab97c Author: Takashi Sakamoto Date: Tue Sep 22 22:26:39 2026 +0900 firewire: cdev: fix back-transition for iso_resource_auto client resource The todo member of iso_resource_auto structure represents the state of the client resource and normally transitions in the following order: ISO_RES_AUTO_ALLOC -> ISO_RES_AUTO_REALLOC -> ISO_RES_AUTO_DEALLOC However, concurrent access from the work item and the file descriptor release function can cause the state to transition backwards from ISO_RES_AUTO_DEALLOC to ISO_RES_AUTO_REALLOC. Prevent the back-transition by checking the current state before updating it in the work item. Fixes: fcabbf40fae5 ("firewire: core: move allocation/reallocation paths into specific branch after isoc resource management in cdev") Link: https://lore.kernel.org/r/20260922132639.191593-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto commit 814a81c842bd88f6bd8a4ce550d560df071a5d03 Author: Zhao Gongyi Date: Thu Sep 17 20:10:16 2026 +0800 bpf, sockmap: Reject max_entries > INT_MAX in sock_map_alloc sock_map_alloc() only rejects max_entries == 0 and otherwise allows any u32 value. sock_map_free() then walks the sks[] array with a signed int iterator: int i; for (i = 0; i < stab->map.max_entries; i++) struct sock **psk = &stab->sks[i]; When a SOCKMAP is created with max_entries = 0xffffffff (UINT_MAX), the allocation of 32 GiB can succeed on large-memory hosts. During free the counter reaches 0x80000000, wraps to INT_MIN, is sign-extended by movslq and turned into a ~16 GiB negative offset from stab->sks, pointing far below the allocation. The faulting access is an xchg() write in sock_map_free(). Without KASAN, the same out-of-bounds write can fault on an unmapped vmalloc page or corrupt an unrelated allocation if that vmalloc address is populated. On a KASAN kernel with CONFIG_KASAN_VMALLOC=y, the shadow check for that address hits an unmapped shadow page and oopses first: BUG: unable to handle page fault for address: fffff521b59c5a00 RIP: 0010:kasan_check_range+0x107/0x190 Call Trace: sock_map_free+0x93/0x190 map_create+0x68d/0xb30 __sys_bpf+0x21e/0x2e70 Vmcore confirmed stab->map.max_entries == 0xffffffff, stab->sks == 0xffffc911ace2d000, and the faulting address sks + (s64)INT_MIN * 8 exactly at 0xffffc90dace2d000. The same buggy path is reached on the normal close()/bpf_map_free_deferred() path whenever such a map is destroyed. sock_map_alloc() used to bound its allocation size through bpf_map_charge_init(), but the bound was dropped when rlimit-based memory accounting was removed. Reject max_entries > INT_MAX at creation time so the signed iterator in sock_map_free() never sees a value that would overflow. Triggered by syzkaller and reproduced on both a 6.6-based KASAN kernel and the upstream v7.3-rc2 kernel. Fixes: 0d2c4f964050 ("bpf: Eliminate rlimit-based memory accounting for sockmap and sockhash maps") Signed-off-by: Zhao Gongyi Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260917121016.48171-1-zhaogongyi@bytedance.com commit cc319238e3f6668f867beb381ce93727c69b7317 Author: Tangudu Tilak Tirumalesh Date: Wed Sep 16 15:35:45 2026 +0530 drm/xe: Add wa_14025941587 to xe2, xe3 and xe3p platforms Avoid programming the IDLEDLY timer to less than 5 microseconds. Apply wa_14025941587 to Graphics Versions 20.01 to 35.11 and Media Versions 13.01 to 35.03 v2: Use xe_rtp_match_not_sriov_vf, move to local variable Remove warn and other knits - Matt R v3: Add verbose comment - Tejas v4: Restore IDLE_DLY register on engine reset. Add it to GUC save-restore list. -Vivek v5: Extend WA to Media Versions 13.01 to 35.03 - Vinay v6: Avoid clearing inhibit switch - Bala Refactor code accordingly by adding idle_reg_val. v7: Rebased with the divide-by-zero/overflow guards living in a separate hardening patch. v8: Preserve the Wa_16023105232 floor (DIV_ROUND_DOWN_ULL) and the maxcnt == 0 guard from the hardening patch. Round up (DIV_ROUND_UP_ULL) the Wa_14025941587 minimum conversion instead, so the tick-quantized delay cannot round back below 5 us. v9: Evaluate the Wa_16023105232 xe_gt_WARN_ON() against the value read from hardware instead of the Wa_14025941587-bumped value, so it no longer fires on the driver's own floor. Re-check the rounded-up tick value against maxcnt and floor it if tick quantization pushed it back to/above maxcnt, logging via xe_gt_dbg since this is the driver's own value, not a hardware anomaly. Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Tangudu Tilak Tirumalesh Reviewed-by: Vinay Belgaumkar Link: https://patch.msgid.link/20260916100545.779894-3-tilak.tirumalesh.tangudu@intel.com Signed-off-by: Matt Roper (cherry picked from commit 9453c528fc909076468ff10df1c2e334ca5a9b00) Signed-off-by: Rodrigo Vivi commit a9e86dd9de4f933b69f5cca6293fd4c8919224ec Author: Emil Tsalapatis Date: Tue Sep 22 17:20:25 2026 +0000 selftests/bpf: Test for mixed arena/nonarena code paths Add a selftest to confirm the verifier rejects ALU operations that return arena or non-arena results depending on code path. Signed-off-by: Emil Tsalapatis Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260922172028.6269-9-emil@etsalapatis.com commit f85f5917aa2fbd861c72ea71ecb14a2fa915c3f6 Author: Emil Tsalapatis Date: Tue Sep 22 17:20:24 2026 +0000 bpf: Prevent variable arena/non-arena register contents The verifier marks ALU instructions that include at least one arena operand with needs_zext: These instructions are fixed up after verification to be ALU32 instructions to ensure that the result is a valid offset into an arena. However, different code paths may provide two non-arena 64-bit arguments to the same instruction. The result of the operation in that code path is wrong, since it is now unexpectedly truncated to 32 bits and zero-extended. Add logic to the verifier to ensure every instruction either always has at least one PTR_TO_ARENA argument, or never does. Since needs_zext already tracks the first scenario, add a prevent_zext field in bpf_insn_aux to track the latter. Reject instructions that use arena arguments and have prevent_zext set, or do not have arena arguments and have needs_zext set. Fixes: 6082b6c328b5 ("bpf: Recognize addr_space_cast instruction in the verifier.") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Emil Tsalapatis Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260922172028.6269-8-emil@etsalapatis.com commit 1ed69a54d31848618131aaf3311a78adbe78ced0 Author: Emil Tsalapatis Date: Tue Sep 22 17:20:23 2026 +0000 selftests/bpf: Test rejection of pkt args to mutating subprogs Add a selftests that ensures that PTR_TO_PACKET arguments can only be passed to subprogs that will never adjust the underlying packet memory, and are rejected otherwise. Signed-off-by: Emil Tsalapatis Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260922172028.6269-7-emil@etsalapatis.com commit a6c1edfbe240e4377038a0e1d233ad81fde9a21b Author: Emil Tsalapatis Date: Tue Sep 22 17:20:22 2026 +0000 bpf: Reject pkt arguments in mutating subprogs The verifier tracks changes in how PTR_TO_PACKET registers' bounds are modified across subprog boundaries. PTR_TO_PACKET registers are actually passed as PTR_TO_MEM, which is assumed valid for the entire call. This is not the case with packet memory, where a pskb_* call may invalidate its memory region. Reject BPF code that passes PTR_TO_PACKET pointers to subprogs that may mutate a packet. We cannot pass the pointer as a true PTR_TO_PACKET because we would also need to somehow pass the PTR_TO_PACKET_META or PTR_TO_PACKET_END to the subprog. Since we cannot avoid representing the pointer in the subprog as PTR_TO_MEM, only permit it if the subprog is guaranteed not to mutate the packet. Fixes: 80f281664f5a ("bpf: Support pointers in global func args") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Emil Tsalapatis Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260922172028.6269-6-emil@etsalapatis.com commit dec0c209a6808fe6de2e4787538e02786a16a4ef Author: Emil Tsalapatis Date: Tue Sep 22 17:20:21 2026 +0000 selftests/bpf: Add selftests for rx_queue_mapping context access Add tests to ensure the verifier properly tracks the 0 bit state and width of the rx_queue_mapping field read from struct sock. Signed-off-by: Emil Tsalapatis Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260922172028.6269-5-emil@etsalapatis.com commit 4a4852376e3a2727ea40e61143d6d7c22bb6dfad Author: Emil Tsalapatis Date: Tue Sep 22 17:20:20 2026 +0000 bpf: Fix bpf_sock context code generation Currently, the ctx access code reads the rx_queue_mapping field with either a 4-byte or 2-byte load. The rest of the bits in the register are marked known zero by the verifier. However, the emitted ctx access code places in the register on certain the special value (-1) using BPF_MOV_IMM64, which gets sign-extended to turn on all the bits in the register. By shifting this value right, the program ends up with a value at runtime above what the verifier assumes is possible. Fix this by ensuring the read value is as wide as the assumed size. Use MOV32 instructions instead of MOV64 instructions to keep the upper bits zero as assumed by the verifier. Also properly report the size of the destination variable (the bpf_sock field, 4 bytes) instead of the source (the socket field, 2 bytes). Fixes: c3c16f2ea6d2 ("bpf: Add rx_queue_mapping to bpf_sock") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Emil Tsalapatis Signed-off-by: Alexei Starovoitov Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260922172028.6269-4-emil@etsalapatis.com commit 4fd72eb9f1c939ce33bb714c6f745a125ac5f40c Author: Emil Tsalapatis Date: Tue Sep 22 17:20:19 2026 +0000 selftests/bpf: Test dynptr slices past end of skb Add a selftest to ensure dynptr slices cannot include past the end of the linear area of an skb. Signed-off-by: Emil Tsalapatis Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260922172028.6269-3-emil@etsalapatis.com commit ed6eec97b534979dcf28b40c389cee57bd6561d4 Author: Emil Tsalapatis Date: Tue Sep 22 17:20:18 2026 +0000 bpf: Fix bounds check for skb-backed dynptrs The skb_pointer_if_linear() function checks whether a memory region of length len starting at offset off into the skb is in the linear area, and returns a pointer to the region if so. The check currently subtracts between skb_headlen and offset of the check, and since skb_headlen is unsigned the subtraction can underflow. This causes the bounds check to spuriously pass and generate an arbitrary pointer of the form *(skb->data + off). The only user of this helper is currently skb-backed BPF dynptr code. Returning the wrong pointer leads to the dynptr erroneously being backed with invalid memory. Ensure the subtraction cannot underflow, and fail the check if it would. Use u64 arithmetic to also prevent overflow when calculating (skb_headlen(skb) - off) since off is unsigned. Fixes: 6f5a630d7c57 ("bpf, net: Introduce skb_pointer_if_linear().") Reported-by: Nicholas Carlini Signed-off-by: Emil Tsalapatis Signed-off-by: Alexei Starovoitov Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260922172028.6269-2-emil@etsalapatis.com commit ec0d89150a9381d591344a9f6f5428655c227a7f Author: Manaf Meethalavalappu Pallikunhi Date: Tue Sep 22 17:49:02 2026 +0530 thermal: gov_step_wise: Fix stale mitigation vote with non-zero lower bounds When two or more thermal zones bind to a common cooling device and one zone uses a non-zero instance->lower value, there is a bug where the instance holds a stale mitigation vote even after its trip is cleared. Problem scenario: - thermal-zone1: Trip at 50°C, cooling-map with lower=0 - thermal-zone2: Trip at 55°C, cooling-map with lower=2 - Both zones share the same cooling device (e.g., CPU) Issue flow: 1. Both trips trigger, zone1 requests state 5, zone2 also mitigates 2. Zone2 trip clears (temp < 53°C due to hysteresis) 3. When throttle=false and trend=THERMAL_TREND_DROPPING: - Current code checks: if (cur_state <= instance->lower) return THERMAL_NO_TARGET - Since cur_state (5) > instance->lower (2), it returns instance->lower (2) - This is the BUG where it returns instance->lower even though trip is cleared 4. Zone2's passive polling stops (tz->passive reaches 0) - no more updates for zone2 5. Zone2's stale vote of 2 persists indefinitely 6. Even when zone1 wants to reduce cooling to state, the cooling device cannot go below state 2 due to zone2's stale vote When a trip is cleared (throttle == false), always return THERMAL_NO_TARGET instead of instance->lower. Remove the unnecessary check comparing cur_state with instance->lower. Since passive polling is already deactivated when the trip is cleared, the instance should always be deactivated regardless of its current cooling state. This ensures that instances with non-zero lower bounds do not retain stale mitigation votes after their trips are cleared. Fixes: 042a3d80f118 ("thermal: core: Move passive polling management to the core") Signed-off-by: Manaf Meethalavalappu Pallikunhi Link: https://patch.msgid.link/20260922-step_wise_multi_zone_stale_vote_fix-v1-1-789f68dab229@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki commit 41112a787f9182c7f2d27122817861e3f22ef928 Author: Florian Schmaus Date: Sun Sep 20 16:35:25 2026 +0200 PM: hibernate: Freeze kernel threads after image preallocation Commit 783c81098445 ("PM: hibernate: call preallocate_image() after freeze prepare") moved hibernate_preallocate_memory() after dpm_prepare() so that device drivers have the opportunity to release pinned/unswappable memory during their ->prepare() callback before memory is preallocated for the snapshot image. However, that commit also placed hibernate_preallocate_memory() after freeze_kernel_threads(). While it was assumed during review that swap I/O submitted via submit_bio() is synchronous and would not depend on frozen kernel threads, this does not hold in practice. Calling hibernate_preallocate_memory() with kernel threads frozen leads to intermittent deadlocks during hibernation. Inside hibernate_preallocate_memory(), shrink_all_memory() is invoked with .may_writepage = 1 and .may_swap = 1 to aggressively reclaim and swap out pages. Any writeback or swap I/O that relies on freezable kernel threads, block device helpers, or WQ_FREEZABLE workqueues (such as those in storage drivers, device mapper, or filesystems) deadlocks waiting on tasks that are stuck in the refrigerator. Fix this by reordering hibernation_snapshot(): 1. Call dpm_prepare(PMSG_FREEZE) first, allowing device drivers to release pinned resources while kernel threads are still active. 2. Call hibernate_preallocate_memory() second, performing page reclaim and swapout while storage layers, workqueues, and kernel threads are alive. 3. Call freeze_kernel_threads() third, only after all memory preallocation and swap I/O have completed. Additionally, restore the call to swsusp_free() in the cleanup path so that preallocated image memory is properly freed if freeze_kernel_threads() fails or if TEST_FREEZER is enabled. Fixes: 783c81098445 ("PM: hibernate: call preallocate_image() after freeze prepare") Signed-off-by: Florian Schmaus Reviewed-by: Mario Limonciello (AMD) Tested-by: Matthew Leach Reviewed-by: Matthew Leach Link: https://patch.msgid.link/20260920-fix-hibernation-v1-1-f9940c2d7d7f@geekplace.eu Signed-off-by: Rafael J. Wysocki commit e7e0a54300a896e731dffd3e2e8dae5631d6243d Author: Mickaël Salaün Date: Tue Sep 22 15:26:14 2026 +0200 landlock: Widen ruleset versions to 64 bits Tracepoint consumers use a ruleset ID and version to identify the successful landlock_add_rule(2) call prefix used to create a domain. LANDLOCK_MAX_NUM_RULES bounds distinct stored rules, not successful calls: re-adding already-present rights for an object or port succeeds without increasing num_rules. Because every successful call increments the version, these calls can wrap the 32-bit counter and give different prefixes the same trace identity. Widen the counter and its trace fields to 64 bits so the counter cannot wrap in practice, while preserving the successful-call semantics. Saturating would alias all subsequent histories, while rejecting a call at the limit would change otherwise valid syscall behavior solely for trace metadata. Cc: Günther Noack Cc: Steven Rostedt Fixes: 63747c94774d ("landlock: Add landlock_add_rule_fs and landlock_add_rule_net tracepoints") Reviewed-by: Günther Noack Link: https://patch.msgid.link/20260922132615.1025945-1-mic@digikod.net Signed-off-by: Mickaël Salaün commit bd3a19800dd1ba1ba9a4c307d9dfe50eac443c01 Author: Tingmao Wang Date: Sun Feb 8 23:54:48 2026 +0000 landlock: Add counted_by in landlock_domain For a domain, this array stores the access masks for each layer (of which there are num_layers of them). This annotation serves as useful documentation. Signed-off-by: Tingmao Wang Reviewed-by: Günther Noack Link: https://patch.msgid.link/20260208235449.1124354-1-m@maowtm.org [mic: Rebase on the ruleset/domain split, and update commit message] Signed-off-by: Mickaël Salaün commit fe2ec83746e501645709761605c2464a44fd2929 Merge: 34e34736ea9a68 b6f69097c8271c Author: Linus Torvalds Date: Tue Sep 22 10:30:17 2026 -0700 Merge tag 'hid-for-linus-2026092202' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - new device IDs/quirks (Logitech G502X, Elecom M-XT4DRBK, Steelseries Arctis 7, Asus Rog Z13 Folio, Lenovo Yoga Slim Gen 11) - fixes for various code issues found by LLMs * tag 'hid-for-linus-2026092202' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: selftests/hid: add unnumbered variant to the hid_bpf tests HID: bpf: fix __hid_bpf_hw_check_params report length selftests/hid: add define for commonly used buf size HID: amd_sfh: Validate PCI BAR size before mapping HID: elecom: fix bus type for M-XGL20DLBK HID: elecom: Add support for ELECOM M-XT4DRBK (018E) HID: corsair-void: Fix firmware event packet description HID: i2c-hid: Add i2c-hid-quirk-bad-input-size quirk for 0911:5288 device HID: hid-oxp: use cancel_delayed_work_sync() in remove HID: i2c-hid: add reset quirk for Lenovo Yoga Slim 7x Gen 11 keyboard HID: roccat: fix locking in roccat_connect() and roccat_disconnect() HID: steelseries: Add support for Arctis 7 (2018) HID: logitech-hidpp: Add support for G502 X Lightspeed USB mouse HID: fix semantic patch and improve its performance HID: alps: fix use-after-free on input2 registration failure HID: alps: unregister DualPoint Stick input device on remove HID: winwing: fix use-after-free in force feedback teardown HID: multitouch: Add report ID mismatch quirk for ASUS ROG Z13 Folio HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce() HID: quirks: add ALWAYS_POLL quirk for SDINNOVATION gaming keyboard commit 34e34736ea9a685664f57586f6e293aaff308858 Merge: c4e9f74da4389a 9db31edf92dde1 Author: Linus Torvalds Date: Tue Sep 22 10:12:54 2026 -0700 Merge tag 'rproc-v7.3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull remoteproc fixes from Bjorn Andersson: "Fix unbalanced handover IRQ on attach and the overwriting of the shutdown return value in the Qualcomm PAS remoteproc driver. Correct the conditions in the Qualcomm modem remoteproc driver for which secure services to require after the move to 'PAS service'. Ensure that the correct addresses are passed to iommu_unmap() as Qualcomm ADSP carveout are torn down" * tag 'rproc-v7.3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: remoteproc: qcom_q6v5_pas: Fix error masking in qcom_pas_stop() remoteproc: qcom_q6v5_adsp: Fix iommu_unmap() usage remoteproc: qcom_q6v5_mss: Don't require PAS for memory protection remoteproc: qcom: q6v5_pas: Don't enable handover IRQ on attach commit c4e9f74da4389a6b3e505d329d99232915a6b9cd Merge: a52a93358ac2be 10396a2d6d41d5 Author: Linus Torvalds Date: Tue Sep 22 10:10:08 2026 -0700 Merge tag 'v7.3-p5' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "This fixes an hmac hashing bug on s390" * tag 'v7.3-p5' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: s390/hmac - Generate intermediate CV for API partial block handling commit a52a93358ac2bef65f15e0069cd410a2b59ae03b Merge: f0100363d8c374 692dd08e03f4a5 Author: Linus Torvalds Date: Tue Sep 22 10:03:33 2026 -0700 Merge tag 'mm-hotfixes-stable-2026-09-21-17-08' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull MM fixes from Andrew Morton: "14 hotfixes. 10 are cc:stable. 11 are for MM. Five DAMON fixes: one fixes an arm64 contpte bug where DAMON can write past the end of a page-table page, resulting in memory corruption and possible crashes. Two hugetlb fixes: one fixes an mremap() address calculation bug which can panic x86-64. There's also a missing anon_vma publication barrier which can result in hung tasks, and a writeback fix to keep long cgroup writeback drains from delaying Tasks-RCU grace periods. The remainder are smaller fixes and maintenance changes" * tag 'mm-hotfixes-stable-2026-09-21-17-08' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: MAINTAINERS: update Xu Xin's email writeback: report a Tasks-RCU quiescent state per cgwb drain pass mm/damon/core: reset invalid quota->charge_target_from MAINTAINERS: add Baoquan and Baolin as MGLRU reviewers mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish mm/hugetlb: preserve mremap address delta when skipping page tables mm/damon/core: fix unconditionally skip last region mm/damon/vaddr: avoid hw-driven pte updates during damon_hugetlb_mkold() mm/damon/core: allow esz to be set to zero mm/damon/ops-common: use a page-aligned address in damon_ptep_mkold() ocfs2: make ocfs2_calc_xattr_init() return void mailmap: update Haowen Bai's email address selftests/cgroup: account for zswap shrinker writeback mm/hugetlb: do not dissolve gigantic pages without runtime support commit 90f467577ebc28c5bc4ba2f0f1b83a4419fb0740 Author: Tangudu Tilak Tirumalesh Date: Wed Sep 16 15:35:44 2026 +0530 drm/xe: harden adjust_idledly() against divide-by-zero and overflow adjust_idledly() has several corner-case issues flagged during review: 1. If xe_gt_clock_init() failed to recognise the crystal clock, gt->info.timestamp_base is 0, which makes idledly_units_ps also 0. The subsequent DIV_ROUND_CLOSEST(..., idledly_units_ps) is then a divide-by-zero and panics the kernel. 2. The tick-to-ns conversions are done in u32: idledly * idledly_units_ps, (maxcnt - 1) * 1000 Both overflow u32 before DIV_ROUND_CLOSEST() sees them. 3. If IDLE_WAIT_TIME reads back as 0, maxcnt evaluates to 0 and the maxcnt - 1 clamp wraps to 0xFFFFFFFF in u32. 4. The register only stores whole ticks, so the clamped ns value has to be converted to ticks and back. DIV_ROUND_CLOSEST() can round that conversion up past maxcnt: maxcnt = 640 ns, one tick = 666664 ps clamp: maxcnt - 1 = 639 ns ns -> ticks: 639000 / 666664 = 0.958 -> rounds to 1 tick tick -> ns: 1 * 666664 / 1000 = 667 ns 667 ns is programmed into RING_IDLEDLY, but 667 >= maxcnt (640), so xe_gt_WARN_ON() fires again on every subsequent init. Return early if timestamp_base is 0 (the unknown-crystal path). Do the conversions in u64 via the *_ULL() helpers so they cannot wrap. Clamp with a floor (DIV_ROUND_DOWN_ULL) so the programmed delay stays strictly below maxcnt, and guard the maxcnt == 0 case with a zero delay while still writing RING_IDLEDLY so INHIBIT_SWITCH_UNTIL_PREEMPTED is cleared. v2: Drop the redundant warn on the timestamp_base == 0 path; xe_gt_clock_init() already warns on an unrecognised crystal clock. Keep the early return to avoid the divide-by-zero. - Vinay v3: Field-mask the RING_IDLEDLY write with REG_FIELD_PREP(IDLE_DELAY, ...) instead of writing the raw tick count, which could clobber INHIBIT_SWITCH_UNTIL_PREEMPTED and reserved bits. Split the inhibit-switch clear from the maxcnt clamp so a set inhibit bit no longer forces a needless delay overwrite when the delay itself is already valid. Use gt_to_xe(gt) instead of gt_to_xe(hwe->gt). Fixes: d2de4410a88f ("drm/xe: Apply Wa_16023105232") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Tangudu Tilak Tirumalesh Reviewed-by: Vinay Belgaumkar Link: https://patch.msgid.link/20260916100545.779894-2-tilak.tirumalesh.tangudu@intel.com Signed-off-by: Matt Roper (cherry picked from commit d864065ea25e9d12897c175de9176ce46677e176) Signed-off-by: Rodrigo Vivi commit 141008dec73521ccf64878517460cec8b3297251 Author: Szymon Acedański Date: Wed Sep 16 19:30:30 2026 +0200 drm/xe: Limit sg segment size to PAGE_SIZE on Xen PV Fix display corruption on Xen PV dom0, where DMA buffers are not guaranteed machine-contiguous, in which case bounce buffering kicks in, breaking xe's memory coherency assumptions. Apply the same workaround i915 carries in i915_sg_segment_size() since commit 78a07fe777c4 ("drm/i915: stop abusing swiotlb_max_segment"). Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reported-by: Marek Marczykowski-Górecki Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8382 Link: https://lore.kernel.org/xen-devel/aYtznP_tT6xNPwf-@mail-itl/ Link: https://lore.kernel.org/all/20221020110308.1582518-1-hch@lst.de/ # i915 counterpart Cc: Christoph Hellwig Cc: Robert Beckett Cc: stable@vger.kernel.org # v6.8+ Signed-off-by: Szymon Acedański Reviewed-by: Thomas Hellström Signed-off-by: Thomas Hellström Link: https://patch.msgid.link/20260916173030.3223833-1-accek@invisiblethingslab.com (cherry picked from commit 77f704158f099b952681f207478a22d5b8218edb) Signed-off-by: Rodrigo Vivi commit 119e9db233ad0f4cbd4cfb9f9385a7bca378b37d Author: Zeng Chi Date: Mon Sep 21 18:24:42 2026 +0800 KVM: Don't pre-reserve xarray entries when storing empty/NULL attributes Skip the xarray reservation loop when clearing all memory attributes, as storing NULL only erases the entry and never needs to allocate, so no reservation (and no cleanup of a failed one) is required in that case. Suggested-by: Sean Christopherson Cc: David Ballesteros Signed-off-by: Zeng Chi Link: https://patch.msgid.link/20260921102442.1232375-1-zeng_chi911@163.com [sean: split to separate patch] Signed-off-by: Sean Christopherson commit 382e5d514b6f35bdda2ab9044b4eed23d2ec4254 Author: David Ballesteros Date: Tue Sep 15 17:53:57 2026 +0000 KVM: Ensure memory attributes xarray nodes are accounted to the caller's memcg Explicitly instantiate the memory attributes xarray with XA_FLAGS_ACCOUNT to ensure that all allocations are accounted to the memcg. Frustratingly, memory allocations done in the "fastpath" do not honor the passed in gfp, even for an explicit xa_reserve(). Only the rare, slow path __xas_nomem() honors the original gfp. E.g. xa_reserve(..., GFP_KERNEL_ACCOUNT) | -> ... | -> __xa_cmpxchg_raw() | -> xas_store() <== does not take @gfp | -> xas_create() | -> xas_alloc() The bug was confirmed by observing that a process in a cgroup limited to 256 MiB grew radix_tree_node slab by ~512 MiB while its memory.current stayed near 0. Fixes: 5a475554db1e ("KVM: Introduce per-page memory attributes") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:claude-opus-5 Signed-off-by: David Ballesteros Link: https://patch.msgid.link/20260915175335.138547-4-davimaba.v@proton.me [sean: rewrite changelog, tag for stable] Signed-off-by: Sean Christopherson commit 277d3623d99a4fc2623bfb7d191b649ca380605d Author: Zeng Chi Date: Mon Sep 21 18:24:42 2026 +0800 KVM: Don't treat reserved xarray entries as having memory attributes kvm_vm_set_mem_attributes() reserves an xarray entry for every gfn in the range before storing the new attributes, so that the store loop can't fail partway through. If one of the reservations fails, e.g. with -ENOMEM, the entries that were already reserved are left in the array. That is harmless as far as xa_reserve() is concerned, as the reserved entries read back as NULL via xa_load(), but it confuses the "does this range have no attributes at all" check: if (!attrs) return !xas_find(&xas, end - 1); A reserved entry is XA_ZERO_ENTRY, not NULL, and xas_find() returns it as present. So a leftover reservation makes KVM report that a fully shared range has attributes even though kvm_get_memory_attributes() returns none for every gfn in the range. On x86, the next time mixed-attribute tracking is recomputed for the range (memslot creation, or a later attribute change that straddles the 2MiB page), hugepage_has_attrs() treats a fully shared 2MiB range as mixed and refuses to map it with a hugepage, until userspace happens to set attributes on the range again. Drop the shortcut and handle the !attrs case in the per-index loop, using xas_next_entry() to find the next non-NULL entry. xas_next_entry() is essentially an optimized xas_find(), so the effective change is that the !attrs lookup now goes through xas_retry() like the attrs != 0 case, i.e. reserved entries are skipped and retry entries restart the walk. Don't check the index when no entry is found, as the xarray leaves the xas index in a bogus state in that case; no entry simply means the rest of the range has no attributes. KVM never stores a non-NULL entry with a value of zero (clearing stores NULL), but such an entry would be returned by xas_next_entry() and trip the index check, so WARN if one is ever seen. Fixes: 5a475554db1e ("KVM: Introduce per-page memory attributes") Cc: stable@vger.kernel.org Suggested-by: Sean Christopherson Cc: David Ballesteros Signed-off-by: Zeng Chi Link: https://patch.msgid.link/20260921102442.1232375-1-zeng_chi911@163.com [sean: expand comment to elaborate on xarray APIs, split optimization out] Signed-off-by: Sean Christopherson commit c1214f293d77c6e425a379f90d09bdb4815993a8 Author: Sean Christopherson Date: Mon Sep 21 14:16:08 2026 -0700 KVM: x86: Fill kvm_run exit fields in common get_nested_state_pages() error paths Fill kvm_run with "internal error, emulation" in the common error handling paths for getting nested state pages, as requiring each check to manually fill kvm_run is error prone and requires a non-trivial amount of copy+paste. Specifically, both SVM and VMX fail to fill kvm_run if load_pdptrs() fails, and SVM fails to fill kvm_run if kvm_hv_verify_vp_assist() fails. If those flows fail, the *best* case scenario is that KVM will exit to userspace with KVM_EXIT_UNKNOWN. The worst case scenario is that KVM exits with a stale exit_reason and confuses userspace. Note, SVM never exits to userspace if something goes sideways when dealing with vmcb12 assets while emulating VMRUN, i.e. lack of SVM-specific code is not a bug. Fixes: 0f85722341b0 ("KVM: nVMX: delay loading of PDPTRs to KVM_REQ_GET_NESTED_STATE_PAGES") Fixes: 232f75d3b4b5 ("KVM: nSVM: call nested_svm_load_cr3 on nested state load") Fixes: 3f4a812edf5c ("KVM: nSVM: hyper-v: Enable L2 TLB flush") Cc: stable@vger.kernel.org Reported-by: Jinwoo Lee Closes: https://lore.kernel.org/all/20260813043932.3214460-1-rkskek9254@gmail.com Reported-by: Stefan Teodorescu Link: https://patch.msgid.link/20260921211608.1030158-3-seanjc@google.com Signed-off-by: Sean Christopherson commit 10180a277549339020b08000206092c07e0bff5a Author: Sean Christopherson Date: Mon Sep 21 14:16:07 2026 -0700 KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails Re-pend GET_NESTED_STATE_PAGES before exiting to userspace if getting the nested pages fails in the KVM_RUN path. If userspace re-runs the vCPU, and vmcs02 holds valid PFNs from the *previous* run of L2, then KVM could re-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page. Note, both SVM and VMX (as of commit 11722439fb20 ("KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit") ensure the request is cleared on VM-Exit (including the "forced" case), i.e. there is no risk of double-mapping due to emulated VMLAUNCH/VMRESUME/VMRUN *and* the request trying to map the nested pages. Fixes: 671ddc700fd0 ("KVM: nVMX: Don't leak L1 MMIO regions to L2") Cc: stable@vger.kernel.org Reported-by: Jinwoo Lee Closes: https://lore.kernel.org/all/20260813043932.3214460-1-rkskek9254@gmail.com Reported-by: Stefan Teodorescu Link: https://patch.msgid.link/20260921211608.1030158-2-seanjc@google.com Signed-off-by: Sean Christopherson commit 17741334d00bf5ebd37f8c1c36bc9c146a351deb Author: Wentao Liang Date: Thu Sep 17 11:58:11 2026 +0000 net: usb: lan78xx: Fix URB reference leak in lan78xx_submit_deferred_urbs() usb_get_from_anchor() hands over a reference to the URB, which the caller must release. lan78xx_submit_deferred_urbs() never does, so every deferred Tx URB keeps an extra reference: the counter grows on each suspend/resume cycle and the URBs are never freed when the buffers are released. Drop the reference after submitting, and on the path that drops the packet instead of submitting it. Fixes: 5f4cc6e25148 ("lan78xx: Fix race conditions in suspend/resume handling") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917115811.2150119-1-vulab@iscas.ac.cn Signed-off-by: Paolo Abeni commit 9892d71cf0ce3ff3d4fed2d9a3968fd4feb1c918 Author: Coia Prant Date: Sun Sep 20 01:20:21 2026 +0800 net: pcs: xpcs: fix clock reference leak on xpcs_init_clks failure xpcs_init_clks() takes references with clk_bulk_get_optional() and then enables them with clk_bulk_prepare_enable(). If the enable step fails, the function returns without dropping the references. xpcs_create() handles the failure through out_free_data, which calls xpcs_free_data() but never xpcs_clear_clks(), so the clk references are leaked. Add the missing clk_bulk_put() on the enable failure path. The prepare/enable side is already rolled back by clk_bulk_prepare_enable() itself. Fixes: f6bb3e9d98c2 ("net: pcs: xpcs: Add Synopsys DW xPCS platform device driver") Signed-off-by: Coia Prant Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260919172021.2336748-1-coiaprant@gmail.com Signed-off-by: Paolo Abeni commit 5d35f9be9b54a1b8f7df85ec5261557e43a999bb Author: Zhang Heng Date: Tue Sep 22 20:30:29 2026 +0800 ASoC: amd: acp: Add DMI quirk for Lenovo Yoga Pro 7 14ASP9 The Lenovo Yoga Pro 7 14ASP9 (83HN) has no digital microphone on the ACP PDM interface; all internal mics are wired to the Realtek ALC287 codec. Add 83HN to acp70_acpi_flag_override_table to prevent the legacy ACP driver from binding and exposing a non-functional PDM capture device, consistent with the sibling 83W5/83V9 entries. Reported-by: Mikail Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221886 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260922123029.534152-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown commit a87529034b9c3c3f3bb71c33e2d6d94658e06383 Author: Jakub Kicinski Date: Fri Sep 18 15:29:49 2026 -0700 selftests: net: nl_nlctrl: check the op ids in the policy map Validate that the op map in the policy dump is correct. Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260918222949.4190284-2-kuba@kernel.org Signed-off-by: Paolo Abeni commit 261e8a37ecbaf462cdf9c336d2b2f5056088401a Author: Jakub Kicinski Date: Fri Sep 18 15:29:48 2026 -0700 genetlink: report the real command id for dump-only ops in policy dumps The op-to-policy map a CTRL_CMD_GETPOLICY dump returns is the only way for userspace to find out which policy index belongs to which command. ctrl_dumppolicy_put_op() tags the nest with doit->cmd, but an op which only has a dumpit has no doit and every path which fills the split ops in zeroes it out, so those entries all claim to be command 0. nlctrl's own CTRL_CMD_GETPOLICY and NETDEV_CMD_QSTATS_GET are both in that group: [{'family-id': 16, 'op-policy': {'do': 0, 'dump': 0, 'op-id': 3}}, {'family-id': 16, 'op-policy': {'dump': 1, 'op-id': 0}}, ctrl_fill_info() gets this right - it uses the iterator's cmd for CTRL_ATTR_OP_ID - so the two introspection interfaces of the same family contradict each other today. Pass the command in rather than reconstructing it from doit->cmd | dumpit->cmd inside the helper, both callers already have it. Fixes: 26588edbef60 ("genetlink: support split policies in ctrl_dumppolicy_put_op()") Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260918222949.4190284-1-kuba@kernel.org Signed-off-by: Paolo Abeni commit 23d42b9a3bcd55b17d3b371544fedc708c2397e9 Author: Théo Lebrun Date: Fri Sep 18 21:53:52 2026 +0200 net: macb: fix dma_alloc_coherent() leak on macb_alloc() error paths Fix 3 leaks in macb_alloc() error paths: - Tx buffer allocated but crossing a 4G boundary: Tx leaked. - Rx buffer allocation fails: Tx leaked. - Rx buffer allocated but crossing a 4G boundary: Tx & Rx leaked. This is because our error handling calls macb_free(bp) which in turn frees the buffers stored in bp->queues[0], but nothing has been stored in there. Fix by storing allocated buffers into bp->queues[0] ASAP. Fixes: 78d901897b3c ("net: macb: single dma_alloc_coherent() for DMA descriptors") Cc: stable@vger.kernel.org Signed-off-by: Théo Lebrun Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260918-macb-alloc-leak-v1-1-aba9a3d4f6e3@bootlin.com Signed-off-by: Paolo Abeni commit 999e8295bc41d6ce45b8e54f88150efa96f3f01e Author: Wentao Liang Date: Thu Sep 17 11:08:28 2026 +0000 net: hisilicon: hns_dsaf_mac: fix mdio device leak in hns_mac_register_phy() hns_dsaf_find_platform_device() returns the mdio platform device with its reference count incremented. hns_mac_register_phy() never drops that reference, so the mdio device can not be released. Release the reference on both the deferred probe and the normal path. Fixes: 1d1afa2ebf82 ("net: hns: register phy device in each mac initial sequence") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260917110828.2148390-1-vulab@iscas.ac.cn Signed-off-by: Paolo Abeni commit 2445e83a434a1964e574f792bd4b8e921cb9d54d Merge: 7f93ca31f7fd9b aeaca27c1db310 Author: Johannes Berg Date: Tue Sep 22 13:11:56 2026 +0200 Merge tag 'ath-current-20260921' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git update for v7.3-rc5 In ath9k, harden the firmware interface and correctly handle a flood of large frames. In ath11k, fix an accounting error that eventually prevents clients from connecting. ================== Signed-off-by: Johannes Berg commit ac4334522e4ba4a3b6710dd5d4cc98092824b8ca Author: bui duc phuc Date: Fri Sep 18 11:28:04 2026 +0700 net: ethernet: ti: netcp: fix pm_runtime usage counter leak on error pm_runtime_get_sync() leaves the runtime PM usage counter incremented even when it fails, but the error path in netcp_probe() does not call pm_runtime_put_noidle() to balance it, leaking a reference each time resume fails. Use pm_runtime_resume_and_get() instead, which automatically drops the usage counter on failure, fixing the leak. Fixes: 84640e27f230 ("net: netcp: Add Keystone NetCP core ethernet driver") Signed-off-by: bui duc phuc Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260918042804.13101-1-phucduc.bui@gmail.com Signed-off-by: Paolo Abeni commit 2d14720beb58870b15a52b236c3ab0be0e06e915 Author: Muhammad Bilal Date: Sun Sep 20 00:19:37 2026 +0500 net: spacemit: clear TX descriptor on fragment mapping failure emac_tx_mem_map() writes TX_DESC_0_OWN into the ring descriptor for every slot beyond old_head as soon as that slot's memset()'d local copy is committed with "*tx_desc_addr = tx_desc", i.e. before the buffers for that slot have necessarily all been mapped successfully. If emac_tx_map_frag() then fails on a later fragment, the err_free_skb path calls emac_free_tx_buf() to unmap and drop the skb, but leaves the already-written descriptor memory untouched, and tx_ring->head is never advanced past old_head (the "tx_ring->head = head" store is skipped by the goto). So a slot between old_head and the rolled-back head can be left with TX_DESC_0_OWN set and buffer_addr_{1,2} pointing at DMA mappings that emac_free_tx_buf() just tore down, while software considers that slot free again. The next successful emac_tx_mem_map() call only rebuilds old_head itself; if the DMA engine auto-advances into the following descriptor once it finishes old_head's packet, it will fetch that stale, already-unmapped address. emac_tx_clean_desc() already treats emac_free_tx_buf() and clearing the descriptor as a pair when reclaiming completed descriptors; do the same in the mapping failure path. Fixes: bfec6d7f2001 ("net: spacemit: Add K1 Ethernet MAC") Signed-off-by: Muhammad Bilal Reviewed-by: Vivian Wang Reviewed-by: Troy Mitchell Link: https://patch.msgid.link/20260919191937.271202-1-meatuni001@gmail.com Signed-off-by: Paolo Abeni commit 012bfcd5a51082d5a65f096dfb9ca652b5267965 Author: Mikhail Zaslonko Date: Wed Sep 16 18:06:26 2026 +0200 s390/debug: Fix NULL pointer dereference in debug_info_copy() When debug_register_static() fails, it clears areas, active_pages and active_entries but leaves the area bounds unchanged. Copying such an area, either by opening its view file or via debug_dump(), makes debug_info_copy() dereference the NULL pointers. Skip the copy loop when the source has no areas. Closes: https://lore.kernel.org/r/20260903132123.12F271F00A3F@smtp.kernel.org Fixes: d72541f94512 ("s390/debug: add early tracing support") Signed-off-by: Mikhail Zaslonko Reviewed-by: Peter Oberparleiter Acked-by: Heiko Carstens Signed-off-by: Heiko Carstens commit a644f09b2090ad22a13fbcf9d141084f573108ef Author: Wentao Liang Date: Thu Sep 17 11:01:35 2026 +0000 fsl/fman: Fix clk reference leak in read_dts_node() of_clk_get() returns a clock with its reference count incremented, but read_dts_node() only uses it to read the rate and never calls clk_put(). The clock is not stored anywhere, so the reference cannot be released later either. Release the clock once its rate has been read, which also covers the error path taken when the rate is zero. Fixes: 414fd46e7762 ("fsl/fman: Add FMan support") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260917110135.2148068-1-vulab@iscas.ac.cn Signed-off-by: Paolo Abeni commit 6eda8938a790f65bd24fcfaae7b40ad4613fb7a2 Author: Cezary Rojewski Date: Fri Sep 18 13:17:45 2026 +0200 ASoC: codecs: rt274: Fix format setting for 44100 rate As per specification, Sample Base Rate (bit 14) shall be set to 1 for 44.1 kHz. Fixes: c7e79b2b2d2d ("ASoC: rt274: add rt274 codec driver") Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260918111745.3589393-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown commit d30fba93ebfc11e4604a7fcc73fdf28684191dde Author: Cezary Rojewski Date: Fri Sep 18 13:17:44 2026 +0200 ASoC: codecs: rt286: Revert delay value for jack setup Fat fingered the change when reorganizing the jack-detect initialization. Equivalent changes for rt274 and rt298: Commit a43b4394bb35 ("ASoC: codecs: rt274: Always init jack_detect_work") Commit 1eb73102da28 ("ASoC: codecs: rt298: Reorganize jack detect handling") carry no update to the delay value. >From user perspective, no difference has been observed between 1250 and 50 values on Intel's SkyLake, KabyLake and AmberLake configurations. Fixes: 3082afe097cc ("ASoC: codecs: rt286: Reorganize jack detect handling") Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260918111745.3589393-1-cezary.rojewski@intel.com Signed-off-by: Mark Brown commit 28e29992b034acffc9342df216c06097825ce610 Author: Mikhail Zaslonko Date: Fri Sep 18 17:13:51 2026 +0200 s390/debug: Do not register views for failed static debug areas __REGISTER_STATIC_DEBUG_INFO() calls debug_register_view() unconditionally, even when debug_register_static() has failed. In that case _debug_register() was never reached and id->debugfs_root_entry is still NULL, so debugfs_create_file() places the view file in the debugfs root directory. For sclp_err this leaves a /sys/kernel/debug/hex_ascii file with nothing to indicate which debug log it belongs to. debug_register_static() is not exported and the macro is its only caller, so let it return an error code and skip the view registration when it fails. No debugfs files are created for such an area then. Reproduce by booting with s390dbf=sclp_err::100000000. The sclp_err registration fails, no s390dbf/sclp_err/ directory is created, and a hex_ascii file appears in the debugfs root instead. Fixes: d72541f94512 ("s390/debug: add early tracing support") Signed-off-by: Mikhail Zaslonko Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens commit 4467df89dbca6a3e9dbc343a315324bb192603d6 Author: Mikhail Zaslonko Date: Wed Sep 16 18:53:30 2026 +0200 s390/debug: Reject NULL debug info in debug_dump() debug_dump() passes id on to debug_info_copy(), which dereferences in->name unchecked. debug_unregister(), debug_set_size() and debug_register_view() guard against a NULL id but debug_dump() does not. Nothing reaches this today, but add the check for consistency. Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260910110147.96E851F000FF@smtp.kernel.org/ Signed-off-by: Mikhail Zaslonko Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens commit f4d04425e66af2ecee9d1a49ae0484436f3c2fd1 Author: Peter Oberparleiter Date: Mon Sep 21 15:16:48 2026 +0200 s390/cmf: Fix virtual vs physical address confusion The measurement block address is an absolute address. Define the associated schib_config and schib fields as dma64_t to enable automatic detection of incorrect assignments. Also add the missing virt_to_dma64() translation. Without this fix, a wrong address will be used by firmware when storing extended format channel measurement data on kernels built with CONFIG_RANDOMIZE_IDENTITY_BASE=y. Fixes: 14edd0d73bfe ("s390/cmf: fix virtual vs physical address confusion") Cc: stable@vger.kernel.org Signed-off-by: Peter Oberparleiter Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens commit 3a43be7a1fd06a35cf9e621b88283b3b6e7d281c Author: Niklas Schnelle Date: Wed Sep 16 17:14:13 2026 +0200 s390/pci: Don't report recovery success on skipped recovery When a PCI device is already in the permanent failure state, recovery is skipped, but the SCLP recovery report still shows success. Fix this by changing the status string to explicitly state that recovery was skipped due to permanent failure. Cc: stable@vger.kernel.org Fixes: 4ec6054e7321 ("s390/pci: Report PCI error recovery results via SCLP") Signed-off-by: Niklas Schnelle Reviewed-by: Benjamin Block Reviewed-by: Farhan Ali Signed-off-by: Heiko Carstens commit a1120bea9bc8ea9d9ab2f9904a63b9a228bf2ffc Author: Niklas Schnelle Date: Wed Sep 16 17:14:12 2026 +0200 s390/pci: Report SCLP status on error events when no pdev is associated With commit 4ec6054e7321 ("s390/pci: Report PCI error recovery results via SCLP") SCLP reports are generated when recovery is performed in response to an error event. If such an error event arrives but no pdev is currently associated with the zdev, e.g. because it was removed or not yet probed, no report is generated. Fix this by generating a report specific to an error event for a zdev without an associated pdev. Cc: stable@vger.kernel.org Fixes: 4ec6054e7321 ("s390/pci: Report PCI error recovery results via SCLP") Signed-off-by: Niklas Schnelle Reviewed-by: Benjamin Block Reviewed-by: Farhan Ali Signed-off-by: Heiko Carstens commit 0261aef4b15efcee2860ab857e5cb05e9bfa47b0 Author: Niklas Schnelle Date: Wed Sep 16 17:14:11 2026 +0200 s390/pci: Fix missing device lock in zpci_report_status() When pdev is non-NULL, zpci_report_status() accesses the device's driver. To get a consistent state matching the recovery, the device lock needs to be held. Do so by expanding the existing device lock critical section. The lock only needs to be held when the pdev is non-NULL, so extract the pdev-specific reporting into a helper function which also adds a lockdep assertion to detect calls without the device lock held. Cc: stable@vger.kernel.org Fixes: 4ec6054e7321 ("s390/pci: Report PCI error recovery results via SCLP") Signed-off-by: Niklas Schnelle Reviewed-by: Benjamin Block Reviewed-by: Farhan Ali Signed-off-by: Heiko Carstens commit 09b7040a1b79f4f61cdad6d9af972e045bb7c498 Author: Niklas Schnelle Date: Wed Sep 16 17:14:10 2026 +0200 s390/pci: Fix leak of struct pci_dev reference in zpci_report_status() In zpci_report_status(), a reference to the pdev associated with the zdev being reported about is acquired using pci_get_slot(). This reference needs to be dropped with pci_dev_put(), but this call is missing, thus leaking the reference. On subsequent hot unplug, this will cause the struct pci_dev to not be released, leaking memory and preventing reattach. At the same time, the only existing caller already holds a pdev reference. So instead of reacquiring and then dropping another reference, simply pass the existing pdev pointer to zpci_report_status(). This gets rid of the need for pci_get_slot() as well as the zdev->zbus check. Cc: stable@vger.kernel.org Fixes: 4ec6054e7321 ("s390/pci: Report PCI error recovery results via SCLP") Signed-off-by: Niklas Schnelle Reviewed-by: Benjamin Block Reviewed-by: Farhan Ali Signed-off-by: Heiko Carstens commit d4d9ccbad527af115b8e83a7a2b74785c0e8dfea Author: Dapeng Mi Date: Thu Sep 17 09:52:34 2026 +0800 perf/x86/intel: Rename NVL offcore_rsp attribute to offmodule_rsp NVL introduces Offmodule Response events in place of the legacy Offcore Response events, but it still exposes the inherited offcore_rsp PMU attribute for programming the corresponding MSR data. Rename the NVL PMU attribute to offmodule_rsp so the sysfs interface matches the underlying event name and avoids user & tooling confusion. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20260917015234.981153-13-dapeng1.mi@linux.intel.com commit 0102c8c7fdfc4bd700971daff2b94470f4eafae4 Author: Dapeng Mi Date: Thu Sep 17 09:52:33 2026 +0800 perf/x86/intel: Rename DMR offcore_rsp attribute to offmodule_rsp DMR introduces Offmodule Response events in place of the legacy Offcore Response events, but it still exposes the inherited offcore_rsp PMU attribute for programming the corresponding MSR data. Rename the DMR PMU attribute to offmodule_rsp so the sysfs interface matches the underlying event name and avoids user & tooling confusion. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20260917015234.981153-12-dapeng1.mi@linux.intel.com commit ff1621adfdd7cfb73f2ccdd3856cd3462ac98ac5 Author: Dapeng Mi Date: Thu Sep 17 09:52:32 2026 +0800 perf/x86/intel: Fix precise OMR event scheduling for DMR/NVL The latest perfmon event database introduces below precise OMR event support for DMR/NVL: - MEM_LOAD_L2_MISS_RETIRED.* (event 0xd6) - MEM_STORE_L2_MISS_RETIRED.* (event 0x4f) These events use the same OMR MSRs as the existing OMR events, but they are not listed in intel_pnc_extra_regs[]. As a result, perf cannot assign the required OMR extra registers when scheduling them. Add the new precise OMR events to intel_pnc_extra_regs[] so they can be scheduled with the correct OMR MSRs. MEM_LOAD_L2_MISS_RETIRED.* remains limited to GP counters 0-3, while MEM_STORE_L2_MISS_RETIRED.* is available on all GP counters. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20260917015234.981153-11-dapeng1.mi@linux.intel.com commit 04a7ef3b7aa3af34202285043e3423a2e3983595 Author: Dapeng Mi Date: Thu Sep 17 09:52:31 2026 +0800 perf/x86/intel: Constrain Panther Cove UOPS_DISPATCHED events to PMCs 0-3 Per the latest Panther Cove event definitions, the following events are only supported on PMCs 0-3: - UOPS_DISPATCHED.INT_EU_ALL (0x1b2) - UOPS_DISPATCHED.ALU (0x2b2) Add explicit event constraints for these two events so scheduling does not place them on unsupported counters. Fixes: d345b6bb8860 ("perf/x86/intel: Add core PMU support for DMR") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: # v7.0+ Link: https://patch.msgid.link/20260917015234.981153-10-dapeng1.mi@linux.intel.com commit 858b37ca19d3f695f7fa94cd14be5a856fd8e7d7 Author: Dapeng Mi Date: Thu Sep 17 09:52:30 2026 +0800 perf/x86/intel: Delete dead NVL PEBS data-source initcall Nova Lake now uses the OMR data-source table for PEBS data-source decoding and no longer depends on the legacy static pebs_data_source[] mapping. Remove the dead intel_pmu_pebs_data_source_lnl() initialization call for NVL. Fixes: c847a208f43b ("perf/x86/intel: Add core PMU support for Novalake") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20260917015234.981153-9-dapeng1.mi@linux.intel.com commit 0ac5d6ca2c3b7d047963b67dccef17902dc6c017 Author: Dapeng Mi Date: Thu Sep 17 09:52:29 2026 +0800 perf/x86/intel: Fix Panther Cove PEBS data-source snoop states For Panther Cove, the snoop states for the data source encodings "Prefetch Promotion" and "Cross Core Prefetch Promotion" should be SNOOP_NONE instead of SNOOP_MISS. Fix the incorrect snooping states for Panther Cove. Fixes: d2bdcde9626c ("perf/x86/intel: Add support for PEBS memory auxiliary info field in DMR") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: # v7.0+ Link: https://patch.msgid.link/20260917015234.981153-8-dapeng1.mi@linux.intel.com commit 9f93d33ad65af9853974c1ec4ba1f937e8ba1376 Author: Dapeng Mi Date: Thu Sep 17 09:52:28 2026 +0800 perf/x86/intel: Remove incorrect Panther Cove PEBS data-source constraints Same issue exists on Panther Cove, PEBS data source is valid only for these events: - MEM_TRANS_RETIRED.LOAD_LATENCY (0x1cd) - MEM_TRANS_RETIRED.STORE_SAMPLE (0x2cd) The perfmon database (https://github.com/intel/perfmon) previously tagged additional memory events such as MEM_INST_RETIRED.STLB_MISS_LOADS with L1_Hit_Indication, implying PEBS data-source support, which is incorrect. The database has since been fixed, but intel_pnc_pebs_event_constraints[] still follows the old definition and marks those events as data-source capable. As a result, get_data_src() may decode data-source information for events that do not provide valid PEBS data-source data and mislead users. Remove those non-data-source memory events from the Pather Cove PEBS constraint table so matching falls back to the regular non-PEBS constraints, which already provide the same counter constraints. Also update pnc_latency_data() to decode LOAD/STORE flags explicitly when setting memory operation direction, for consistency with other *_latency_data() helpers. Fixes: d345b6bb8860 ("perf/x86/intel: Add core PMU support for DMR") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: # v7.0+ Link: https://patch.msgid.link/20260917015234.981153-7-dapeng1.mi@linux.intel.com commit 7c944595cc43a664019edc22505b6d6f6039be5e Author: Dapeng Mi Date: Thu Sep 17 09:52:27 2026 +0800 perf/x86/intel: Remove incorrect LionCove PEBS data-source constraints On Lion Cove, PEBS data source is valid only for these events: - MEM_TRANS_RETIRED.LOAD_LATENCY (0x1cd) - MEM_TRANS_RETIRED.STORE_SAMPLE (0x2cd) The perfmon database (https://github.com/intel/perfmon) previously tagged additional memory events such as MEM_INST_RETIRED.STLB_MISS_LOADS with L1_Hit_Indication, implying PEBS data-source support, which is incorrect. The database has since been fixed, but intel_lnc_pebs_event_constraints[] still follows the old definition and marks those events as data-source capable. As a result, get_data_src() may decode data-source information for events that do not provide valid PEBS data-source data and mislead users. Remove those non-data-source memory events from the Lion Cove PEBS constraint table so matching falls back to the regular non-PEBS constraints, which already provide the same counter constraints. Also update lnc_latency_data() to decode LOAD/STORE flags explicitly when setting memory operation direction, for consistency with other *_latency_data() helpers. Fixes: a932aa0e868f ("perf/x86: Add Lunar Lake and Arrow Lake support") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: Link: https://patch.msgid.link/20260917015234.981153-6-dapeng1.mi@linux.intel.com commit 335b0642812ee0f2b7798b634ce507b8b7c9fe0c Author: Dapeng Mi Date: Thu Sep 17 09:52:26 2026 +0800 perf/x86/intel: Update arw_latency_data() mem-op direction handling Align arw_latency_data() with other *_latency_data() helpers by explicitly decoding LOAD/STORE event flags when setting the sampled memory operation direction. This keeps the latency data path behavior consistent across platforms and avoids relying on implicit direction inference. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20260917015234.981153-5-dapeng1.mi@linux.intel.com commit d2da6696e0c4e60414706e607029d0bb0330c67e Author: Christian König Date: Thu Sep 3 13:36:21 2026 +0200 drm/i915: fix incorrect RCU teardown order i915_gem_busy_ioctl uses dma_resv_for_each_fence_unlocked() to iterate over the fences in an GEM object without holding a reference but only the RCU read side lock. What can happen here is that the GEM object is destroyed concurrently while i915_gem_busy_ioctl is still running. This won't free the GEM objects memory, but still drops all the dma_fence references. Now when dma_resv_for_each_fence_unlocked() sees a destroyed dma_fence it assumes that a new fence list was installed and re-starts the loop. But in the case of a destroyed GEM object a new fence list is never installed, only the old one freed and therefore the iteration never finishes resulting in an endless loop. The solution is to drop the fence references only after the RCU grace period. The fixes tag is not necessary the patch introducing the problem, but the one making it so worse that we need to address it. This problem was pointed out by Sashiko-bot. Signed-off-by: Christian König Fixes: 912ff2ebd695 ("drm/i915: use the new iterator in i915_gem_busy_ioctl v2") CC: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260903113621.54660-1-christian.koenig@amd.com (cherry picked from commit 5113479556025093bf8133bb2dcaa33be2d50921) Signed-off-by: Jani Nikula commit bb2635be7646a6a9e40a27becb936fe3cdcccf8d Author: Jani Nikula Date: Tue Sep 15 19:06:20 2026 +0300 drm/i915/dp: use EXPORT_SYMBOL_IF_KUNIT() for kunit helpers Use EXPORT_SYMBOL_IF_KUNIT() instead of the regular EXPORT_SYMBOL() to export the symbols to the kunit namespace. Otherwise, the symbols get exported for all the kernel to see, and the corresponding MODULE_IMPORT_NS("EXPORTED_FOR_KUNIT_TESTING") in the tests is meaningless. Fixes: 2eb9982ff179 ("drm/i915/kunit: Export link training and caps funcs for testing") Cc: Imre Deak Reviewed-by: Imre Deak Link: https://patch.msgid.link/20260915160620.779372-1-jani.nikula@intel.com Signed-off-by: Jani Nikula (cherry picked from commit 4ffdb772716e4279d63dfaaadf965da73e799aeb) commit a443e0b8d647c1401b110d9f919d8c6cb8607260 Author: Imre Deak Date: Mon Sep 7 20:44:13 2026 +0300 drm/i915/dp_mst: Fix configuring TUs for a disconnected stream During an atomic commit after all the MST stream CRTC state is computed the driver ensures that the sum of TUs of all the streams on a given MST topology link is within limits (63 for 8b10 and 64 for 128b132b). For a disconnected stream the DRM MST core's BW verification doesn't ensure this, because the topology state it uses for this is destroyed as soon as the stream (i.e. MST connector/port) is disconnected. The driver should keep the link state valid even for such disconnected streams, as userspace may disable them one-by-one only in a deferred way. Ensure the link's sum of TUs stays within limits in this case by simply reusing the maximum link BPP limit from the stream's (i.e. CRTC's) old state. The disconnection can happen either via the whole topology getting disconnected or via only the given stream's port getting disconnected. Check for both of these conditions separately, as a connector gets unregistered after a link disconnect event only in a deferred way. Cc: stable@vger.kernel.org # v6.10+ Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16073 Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16384 Reviewed-by: Luca Coelho Signed-off-by: Imre Deak Link: https://patch.msgid.link/20260907174413.741851-2-imre.deak@intel.com (cherry picked from commit ee00f8fbb2b202002ab90834e02e9ba372773a36) Signed-off-by: Jani Nikula commit acbe9a3b60b9a6ace8ef11fe898f586251c84592 Author: Imre Deak Date: Mon Sep 7 20:44:12 2026 +0300 drm/i915/dp_mst: Fix configuring FEC for a disconnected stream During an atomic commit after all the MST stream CRTC state is computed the driver ensures that the FEC is configured the same way (enabled or disabled) for all the streams on a given MST topology's link. drm_dp_mst_port_downstream_of_parent() used to determine if a stream is downstream of an MST port will return false if the whole topology is disconnected, since in that case it can't verify that the port/ parent_port passed to it is in the given MST topology. This is a problem during the above FEC configuration check, since intel_dp_mst_check_dsc_change()->get_pipes_downstream_of_mst_ports() will not return all the stream CRTCs/pipes for the topology as expected. Since passing parent_port==NULL to get_pipes_downstream_of_mst_port() is meant to return all the streams for the given topology (i.e. mst_mgr) skip checking if an MST port is downstream of a parent port in this case. This fixes a problem where the FEC configuration check explained above failed to ensure that all streams' FEC is configured the same way if the topology was disconnected, leading to a FEC state mismatch error. Cc: stable@vger.kernel.org # v6.10+ Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16073 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16384 Reviewed-by: Luca Coelho Signed-off-by: Imre Deak Link: https://patch.msgid.link/20260907174413.741851-1-imre.deak@intel.com (cherry picked from commit 270681fbffbba2b6ccf5b7e3c34b8b563b36167f) Signed-off-by: Jani Nikula commit 8302c5f475fa5a4ed36a7d32c7b965023d5d7066 Author: Dapeng Mi Date: Thu Sep 17 09:52:25 2026 +0800 perf/x86/intel: Fix DKT PEBS load/store direction for latency events, to fix sample classification Same bug exists on Darkmont as on Gracemont: intel_dkt_pebs_event_constraints[] applies LAT_CONSTRAINT constraints to MEM_UOPS_RETIRED.{LOAD,STORE}_LATENCY, but does not set explicit LOAD/STORE flags for those events. The PEBS latency path (pebs_latency_data(), via cmt_latency_data) uses the event flags to determine memory operation direction. Without an explicit STORE flag, samples from MEM_UOPS_RETIRED.STORE_LATENCY can be misclassified as LOADs. Set explicit LOAD/STORE flags in intel_dkt_pebs_event_constraints[] for: - MEM_UOPS_RETIRED.LOAD_LATENCY - MEM_UOPS_RETIRED.STORE_LATENCY This fixes incorrect STORE sample classification. Additionally remove INTEL_HYBRID_LAT_CONSTRAINT() since no one uses it anymore. Fixes: 65fd435095bb ("perf/x86/intel: Update event constraints for PTL") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: # v7.2+ Link: https://patch.msgid.link/20260917015234.981153-4-dapeng1.mi@linux.intel.com commit 5271d81f99dd01d983d439930eb056952485e15e Author: Ankit Nautiyal Date: Mon Sep 7 09:15:55 2026 +0530 drm/i915/quirks: Limit eDP rate to HBR2 on HP Pavilion Plus 14-ew1 The eDP panel on the HP Pavilion Plus Laptop 14-ew1xxx advertises HBR3 while leaving the TPS4 support bit clear. The output however flickers, once link is trained with HBR3. Until commit 8c9006283e4b ("Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"") such sinks were capped at HBR2 by the TPS4 check which incidentally kept this panel stable. That check was reverted because other panels legitimately need HBR3 without advertising TPS4, and the per-machine QUIRK_EDP_LIMIT_RATE_HBR2 was introduced to handle the affected machines instead. Add the machine to the list of devices that need the QUIRK_EDP_LIMIT_RATE_HBR2. Fixes: 8c9006283e4b ("Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"") Reported-by: Annoy Cc Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16743 Cc: # v6.18+ Tested-by: Annoy Cc Signed-off-by: Ankit Nautiyal Reviewed-by: Nemesa Garg Link: https://patch.msgid.link/20260907034555.2753846-1-ankit.k.nautiyal@intel.com (cherry picked from commit 550b703fdbb2a2022faa75b4b11ab135241afbd9) Signed-off-by: Jani Nikula commit 2777ec9852277a06ae68fee0c4f1a32783e4a999 Author: Nemesa Garg Date: Wed Sep 9 16:33:32 2026 +0530 drm/i915/psr: Clear stale sel fetch enable bits on sel fetch disable Selective fetch is dropped while pipe CRC is active, and the planes keep their SEL_FETCH_PLANE_CTL / SEL_FETCH_CUR_CTL enable bit set in hardware over that. A plane disabled while selective fetch is off never gets the bit cleared, as the disable path is guarded by enable_psr2_sel_fetch. Once selective fetch comes back the hardware resumes fetching for a plane that is no longer enabled and keeps its DDB range reserved. Clear the bits as selective fetch is turned off instead. Atomic check has both the old and the new crtc state, so record the transition there and let the plane and cursor arm paths write the registers to 0 for that commit. v2: Drop the old_crtc_state->hw.active check. [Jouni] Fixes: b1f5279b5981 ("drm/i915/psr: Move plane sel fetch configuration into plane source files") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8739 Assisted-by: Copilot:Claude-Opus-5 Signed-off-by: Nemesa Garg Reviewed-by: Jouni Högander Signed-off-by: Suraj Kandpal Link: https://patch.msgid.link/20260909110332.3528029-3-nemesa.garg@intel.com (cherry picked from commit a4c0e7f80429eda6990960971aebd4e4b9533cc6) Signed-off-by: Jani Nikula commit e961d6db42d1f1b66c81438969a648f08573bd9c Author: Dapeng Mi Date: Thu Sep 17 09:52:24 2026 +0800 perf/x86/intel: Fix CMT PEBS load/store direction for latency events, to fix sample classification The same bug exists on Crestmont as on Gracemont: intel_cmt_pebs_event_constraints[] applies LAT_CONSTRAINT constraints to MEM_UOPS_RETIRED.{LOAD,STORE}_LATENCY, but does not set explicit LOAD/STORE flags for those events. The PEBS latency path (pebs_latency_data(), via cmt_latency_data) uses the event flags to determine memory operation direction. Without an explicit STORE flag, samples from MEM_UOPS_RETIRED.STORE_LATENCY can be misclassified as LOADs. Set explicit LOAD/STORE flags in intel_cmt_pebs_event_constraints[] for: - MEM_UOPS_RETIRED.LOAD_LATENCY - MEM_UOPS_RETIRED.STORE_LATENCY This fixes incorrect STORE sample classification. Fixes: e99fb45436ea ("perf/x86/intel: Update event constraints and cache_extra_regsfor MTL") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: # v7.2+ Link: https://patch.msgid.link/20260917015234.981153-3-dapeng1.mi@linux.intel.com commit 89dc568e8c0be60e05e5fcd0b528c79077d7b84b Author: Dapeng Mi Date: Thu Sep 17 09:52:23 2026 +0800 perf/x86/intel: Fix GRT PEBS load/store direction for latency events, to fix sample classification On Gracemont, intel_grt_pebs_event_constraints[] applies LAT_CONSTRAINT constraints to MEM_UOPS_RETIRED.{LOAD,STORE}_LATENCY, but does not set explicit LOAD/STORE flags for those events. The PEBS latency path (pebs_latency_data(), via __grt_latency_data()) uses the event flags to determine memory operation direction. Without an explicit STORE flag, samples from MEM_UOPS_RETIRED.STORE_LATENCY can be misclassified as LOADs. Set explicit LOAD/STORE flags in intel_grt_pebs_event_constraints[] for: - MEM_UOPS_RETIRED.LOAD_LATENCY - MEM_UOPS_RETIRED.STORE_LATENCY Also update __grt_latency_data() to explicitly interpret these flags when assigning the sampled memory operation direction. This fixes incorrect STORE sample classification. Fixes: 39a41278f041 ("perf/x86/intel: Fix PEBS memory access info encoding for ADL") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: # v7.2+ Link: https://patch.msgid.link/20260917015234.981153-2-dapeng1.mi@linux.intel.com commit a92e1a412c53dc0d9ad639e7abf8b3fc70a5b6ad Author: Myeonghun Pak Date: Thu Sep 17 14:33:36 2026 -0400 tg3: clean up PHYLIB resources on probe failure tg3_get_invariants() can register an MDIO bus and connect a PHY for USE_PHYLIB devices. If tg3_init_one() later fails, its common error path releases the mappings and netdev without undoing those PHYLIB resources. Disconnect the PHY and unregister the MDIO bus before the remaining teardown. Guard PHY cleanup with USE_PHYLIB to match tg3_phy_init(), and call tg3_mdio_fini() unconditionally to match tg3_mdio_init(). The existing IS_CONNECTED and MDIOBUS_INITED flags make both helpers safe when initialization only completed partially. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 158d7abdae85 ("tg3: Add mdio bus registration") Assisted-by: OpenAI:GPT-5.6 Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260917183336.36239-1-mhun512@gmail.com Signed-off-by: Paolo Abeni commit a391618e1d563f099e4c2a704f45d08329ccdf7c Author: Sean Christopherson Date: Mon Sep 21 12:14:12 2026 -0700 perf/x86/intel: Make @data a mandatory param for intel_guest_get_msrs() Drop "support" for passing a NULL @data/@kvm_pmu param when getting guest MSRs. KVM, the only in-tree user, unconditionally passes a non-NULL pointer, and carrying code that suggests @data may be NULL is confusing, e.g. incorrectly implies that there are scenarios where KVM doesn't pass a PMU context. Fixes: 8183a538cd95 ("KVM: x86/pmu: Add IA32_DS_AREA MSR emulation to support guest DS") Signed-off-by: Sean Christopherson Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Jim Mattson Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260921191418.950933-5-seanjc@google.com commit d06260e99eb93d2942b7af4ccd789eb8a6c829d3 Author: Sean Christopherson Date: Mon Sep 21 12:14:11 2026 -0700 perf/x86/intel: Don't pointlessly context switch DS_AREA (and PEBS config) if PEBS is unused When filling the list of MSRs to be loaded by KVM on VM-Enter and VM-Exit, load the guest values for DS_AREA and (conditionally) MSR_PEBS_DATA_CFG if and only if PEBS will be active in the guest, i.e. only if a PEBS record may be generated while running the guest. As shown by the !pebs_ept path, it's perfectly safe to run with the host's DS_AREA, so long as PEBS-enabled counters are disabled via PERF_GLOBAL_CTRL. Omitting DS_AREA and MSR_PEBS_DATA_CFG when PEBS is unused saves two MSR writes per MSR on each VMX transition, i.e. eliminates two/four pointless MSR writes on each VMX roundtrip when PEBS isn't being used by the guest. Fixes: c59a1f106f5c ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for extended PEBS") Signed-off-by: Sean Christopherson Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Jim Mattson Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260921191418.950933-4-seanjc@google.com commit 4b64dbdc5861477f148e13d1ed127e7fe7182e4f Author: Sean Christopherson Date: Mon Sep 21 12:14:10 2026 -0700 perf/x86/intel: Don't write PEBS_ENABLED on host<=>guest xfers if CPU has PEBS isolation, to fix stuck PEBS_ENABLED When filling the list of MSRs to be loaded by KVM on VM-Enter and VM-Exit, *never* insert an entry for PEBS_ENABLED if the CPU properly isolates PEBS events, in which case disabling counters via PERF_GLOBAL_CTRL is sufficient to prevent unwanted PEBS events in the guest (or host). Because perf loads PEBS_ENABLE with the unfiltered cpu_hw_events.pebs_enabled, i.e. with both host and guest masks, there is no need to load different values for the guest versus host, perf+KVM can and should simply control which counters are enabled/disabled via PERF_GLOBAL_CTRL. Avoiding touching PEBS_ENABLED "fixes" a bug where PEBS_ENABLED can end up with "stuck" bits if a PEBS event is throttled between generating the list and actually entering the guest (Intel CPUs can't arbtitrarily block NMIs). Fixes in quotes because leaving PEBS_ENABLED as-is doesn't fix the underlying problem of perf (via PMIs) being able to modify state after the perf<=>KVM handoff. But not writing PEBS_ENABLED is desirable no matter what, as stating the obvious, leaving PEBS_ENABLED as-is avoids three MSR writes on every VMX transition: one each on entry/exit, and one more explicit WRMSR to zero PEBS_ENABLED before VM-Entry (KVM assumes the only reason PEBS_ENABLED is in the load list is if the CPU lacks PEBS isolation and thus needs a quiescent period). Opportunistically add comments to (better) explain the rules for generating the set of PEBS counters that will be active while the guest is running, along with a FIXME for the suspected hack-a-fix where perf disables guest PEBS if _any_ PEBS event is configured to count in the host (commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarily in two rare situations") doesn't explain the motivation, at all). Fixes: c59a1f106f5c ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for extended PEBS") Signed-off-by: Sean Christopherson Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260921191418.950933-3-seanjc@google.com commit cec38d5c098a350dcf084d345025136ade7e6d1e Author: Sean Christopherson Date: Mon Sep 21 12:14:09 2026 -0700 perf/x86/intel: Ensure KVM guest PEBS path doesn't set unwanted PERF_GLOBAL_CTRL bits When reinstating PEBS counters into PERF_GLOBAL_CTRL for a KVM guest, mask the value with perf's desired/original PERF_GLOBAL_CTRL value to ensure KVM doesn't unintentionally set reserved bits in PERF_GLOBAL_CTRL. E.g. if the guest's PEBS_ENABLE value had bit 63, "Enable Precise Store", set, then using the raw guest PEBS value would propagate bit 63 to the guest's PERF_GLOBAL_CTRL value (which thankfully would be a failed VM-Entry, not a VMX Abort). The only reason this bug isn't reachable is because KVM doesn't support "Enable Precise Store" (which is probably a KVM bug?), i.e. bit 63 can't be set in kvm_pmu->pebs_enable and thus not in arr[pebs_enable].guest. In other words, this _should_ be a glorified NOP in the current code base. Fixes: c59a1f106f5c ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for extended PEBS") Signed-off-by: Sean Christopherson Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260921191418.950933-2-seanjc@google.com commit 177a59665d8a71c663a8f82a5d7f2ff9a8a2ac2e Merge: f0b88fade64c6f 9e95b1a94c9c49 Author: Paolo Abeni Date: Tue Sep 22 10:58:19 2026 +0200 Merge branch 'udp-two-fixes-for-the-4-tuple-hash-table' Shardul Bankar says: ==================== udp: two fixes for the 4-tuple hash table Two ways a UDP socket ends up in the wrong place in the 4-tuple hash table. The patches are independent, with different Fixes: tags and no dependency between them. Patch 1: a socket that connects a second time is not relocated, so it stays filed under its first peer's hash and packets for it fall back to scoring the hash2 chain for its address and port. Patch 2: a socket bound to a specific address and port is not taken out of the table when it disconnects, because __udp_disconnect() only does that via ->rehash() or ->unhash() and neither runs for it. Both are in code shared by IPv4 and IPv6. Patch 1's cost, with N sockets sharing a port and one of them misfiled, 200k packets sent to its 4-tuple: N without with 200 1,061,652 2,093,259 pps 500 522,553 2,055,078 pps 1000 279,729 2,136,606 pps Correctly filed sockets measure ~2.1M pps throughout, so the cost scales with the number of sockets on the port, as the fallback scan does. For comparison, commit 78c91ae2c6de ("ipv4/udp: Add 4-tuple hash for connected socket") measured 290,860 pps without the table and 1,889,658 with it at 500 connected sockets. Patch 2's cost is not in throughput. Its stale entry keeps hash4_cnt raised for the life of the socket, so every packet for that address and port is sent through the 4-tuple lookup first; on IPv6 the entry is also matchable, because __udp_disconnect() does not clear sk_v6_daddr. That last one is a separate defect, which I will send on its own. Neither patch has a selftest. Nothing in tree reports which 4-tuple bucket a socket is filed under, so a test can only measure the cost indirectly. What I did instead was add pr_info() to the hash4 paths and a knob that dumps bucket occupancy, then run the same scenarios on two kernels differing only by these patches; that is where the numbers above come from. The instrumentation, the reproducers and the benchmark are at [1]. If exposing the bucket through diag would be welcome, that would make both defects testable in tree and I am glad to do it for net-next. Removing the connect(AF_UNSPEC) limitation described in 644f9108f3a5 is a side effect of patch 1 fixing the general case. I can make it narrower if you would rather that limitation stayed. Tooling, per Documentation/process/generated-content.rst: this series was developed in an assisted session with an LLM. The assistant did most of the code reading, wrote the instrumentation and reproducers behind [1], drafted these changelogs, and ran the A/B builds and the regression suites below. Every claim in these messages was checked against the source, and the IPv6 behaviour described in patch 2 was confirmed at runtime. Tested on x86-64, IPv4 and IPv6. No regressions across reuseport_bpf, reuseport_bpf_cpu, reuseport_addr_any.sh, reuseport_dualstack, udpgso_bench.sh, udpgro_bench.sh and socket. [1] https://github.com/shardulsdk-mpiric/linux/tree/udp-hash4-fix-verification To: Willem de Bruijn To: "David S. Miller" To: Eric Dumazet To: Jakub Kicinski To: Paolo Abeni To: Simon Horman To: Philo Lu To: Fred Chen To: Yubing Qiu Cc: Kuniyuki Iwashima Cc: Willem de Bruijn Cc: Cambda Zhu Cc: Janak Bhatt Cc: Kalpan Jani Cc: Shardul Bankar Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shardul Bankar ==================== Link: https://patch.msgid.link/20260917-udp_hash4_fix_v1-v1-0-718891af0d7a@mpiricsoftware.com Signed-off-by: Paolo Abeni commit 9e95b1a94c9c49b4ba722251bbca2759b9c51737 Author: Shardul Bankar Date: Thu Sep 17 14:55:33 2026 +0530 udp: remove a disconnected socket from the 4-tuple hash table A UDP socket bound to a specific address and port keeps its entry in the 4-tuple hash table after it is disconnected: sk binds to 127.0.0.1:21001 sk connects to 127.0.0.2:20001 // filed in the 4-tuple table sk disconnects, connect(AF_UNSPEC) // still filed, peer now 0.0.0.0:0 __udp_disconnect() takes a socket out of that table only as a side effect of ->rehash() or ->unhash(), and it skips ->rehash() when SOCK_BINDADDR_LOCK is set and ->unhash() when SOCK_BINDPORT_LOCK is set. commit 6996a2d2d0a6 ("udp: Unhash auto-bound connected sk from 4-tuple hash table when disconnected.") fixed the same end state for a wildcard-bound socket, by a path this one does not take. The entry is counted whether or not anything hits it. hash4_cnt on the hash2 slot stays raised for as long as the socket lives, so udp_has_hash4() keeps sending every packet for that address and port through the 4-tuple lookup first. On IPv6 it can also be hit. __udp_disconnect() does not clear sk_v6_daddr, so udp_v6_rehash() files the entry under the peer the socket was connected to with a zero dport, and inet6_match() compares that same field: a datagram from the former peer with a zero source port matches, and source port zero is accepted on receive. On IPv4 the peer is cleared, so a match would need a zero source address as well, which the routing layer rejects as martian. The stale sk_v6_daddr is a separate defect, not addressed here; removing the entry closes this path either way. The entry can also be relocated. __udp_disconnect() clears sk_bound_dev_if, so a subsequent SO_BINDTODEVICE calls ->rehash(), and because the receive address is still specific udp_lib_rehash() moves the entry instead of removing it, into the bucket that (rcv_saddr, num, 0, 0) hashes to -- a pure function of the address and port, so every socket reaching this state on one address and port collects in one bucket. The bucket cannot be chosen from outside, as udp_ehashfn() is seeded with a per-boot secret. This last one became reachable only with commit 644f9108f3a5 ("udp: Make rehash4 independent in udp_lib_rehash()"), which moved the hash4 handling out of a branch a disconnected socket does not take; the stale entry itself dates from the commit in Fixes. Take the socket out of the table before __udp_disconnect() runs, while it still matches how it was filed. This also reaches the wildcard case ahead of udp_lib_rehash()'s udp_unhash4() branch, leaving that branch unreachable from udp_disconnect(); removing it belongs in net-next. udp_disconnect() and udp_abort() are the only UDP entries into __udp_disconnect(), which is shared with raw, ping and l2tp sockets that are not struct udp_sock: ping_prot.obj_size is sizeof(struct inet_sock), so udp_hashed4() on one would read past the allocation. Fixes: 78c91ae2c6de ("ipv4/udp: Add 4-tuple hash for connected socket") Assisted-by: LLM Signed-off-by: Shardul Bankar Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260917-udp_hash4_fix_v1-v1-2-718891af0d7a@mpiricsoftware.com Signed-off-by: Paolo Abeni commit 5fd0783b99d4af98f65cd58b56ec203d1d426104 Author: Shardul Bankar Date: Thu Sep 17 14:55:32 2026 +0530 udp: relocate a connected socket in the 4-tuple hash table on re-connect A connected UDP socket that connects again to a different peer is not re-filed in the 4-tuple hash table: sk binds to 127.0.0.1:21001 sk connects to 127.0.0.2:20001 // filed under hash(sk, peer1) sk connects to 127.0.0.3:20002 // still filed under hash(sk, peer1) packet from 127.0.0.3:20002 // hash(sk, peer2) misses, so the // lookup falls back to scoring the // hash2 chain for this address // and port udp_lib_hash4() returns early when the socket is already hashed, assuming ->rehash() relocates it. ->rehash() runs from __ip{4,6}_datagram_connect() only while the receive address is unset, which a second connect never is: the first connect assigns it, whether the socket was bound to a specific address or to the wildcard. commit 644f9108f3a5 ("udp: Make rehash4 independent in udp_lib_rehash()") added that early return and named connect(AF_UNSPEC) as the way around it. That workaround does not help a socket with both SOCK_BINDADDR_LOCK and SOCK_BINDPORT_LOCK set, because __udp_disconnect() skips ->rehash() for the first and ->unhash() for the second. Delivery is correct either way. Relocate the socket when the hash it is filed under differs from the one requested, which is what commit 78c91ae2c6de ("ipv4/udp: Add 4-tuple hash for connected socket") did before the early return became unconditional. It is done here under hslot->lock, which that version did not take, to match udp_lib_rehash() and udp_lib_unhash(). hslot2 is unchanged, so hash4_cnt needs no adjustment, as in udp_lib_rehash(). A first connect is unaffected, and IPv6 shares the code. With 500 sockets on the port, a re-connected socket measured 522,553 pps without this change and 2,055,078 with it. The UDP side was noted as remaining work in [1]. Link: https://lore.kernel.org/netdev/apnHqmYZQ4yzOP4N@v4bel/ [1] Fixes: 644f9108f3a5 ("udp: Make rehash4 independent in udp_lib_rehash()") Assisted-by: LLM Signed-off-by: Shardul Bankar Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260917-udp_hash4_fix_v1-v1-1-718891af0d7a@mpiricsoftware.com Signed-off-by: Paolo Abeni commit 58a00330248154461c52a6f3bd5c01e5b67f9560 Author: Hans de Goede Date: Fri Sep 18 11:38:38 2026 +0200 power: sequencing: pcie-m2: Add Lenovo ThinkPad T14s gen6 WCN7850 subsystem PCI ids Commit a39ac4651e3b ("power: sequencing: pcie-m2: Match WCN6855 and WCN7851 UART BT variants by subdevice ID") has caused the serdev for the WCN7850 on the Lenovo ThinkPad T14s gen6 WCN7850 no longer getting created. Add a new match using the PCI subdev ids from the T14s gen6 to fix this. Fixes: a39ac4651e3b ("power: sequencing: pcie-m2: Match WCN6855 and WCN7851 UART BT variants by subdevice ID") Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20260918093838.6645-1-johannes.goede@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit 3cb0243767fd033bdce95f4f1b5882172a2f8119 Author: Davi Chaves Azevedo Date: Mon Sep 21 17:37:27 2026 -0700 sched/cache: Refresh LLC capacity across CPU hotplug, to fix capacity underestimation bug The scheduler scales LLC capacity by the fraction of cache-sharing CPUs covered by a domain: llc_bytes = cache_size * span_weight / shared_weight During CPU teardown, sched_cpu_deactivate() rebuilds scheduler domains before cacheinfo_cpu_pre_down() removes the CPU from shared_cpu_map. The new domains therefore use the old sharing weight. The later call to sched_update_llc_bytes() looks up the departing CPU's sd_llc, which has already been detached, and returns without correcting the surviving CPUs. On a Ryzen 5 7535U with twelve logical CPUs sharing a 16 MiB LLC, offlining one SMT sibling left the remaining CPUs with: llc_bytes = floor(16777216 * 11 / 12) = 15379114 bytes The correct capacity is still 16777216 bytes. On systems with active cache-aware scheduling, an underestimated capacity can cause exceed_llc_capacity() to reject aggregation for a process whose footprint would fit. Unchanged cpuset partitions sharing the physical cache can also retain stale capacity when a CPU comes online in another partition. Pass the cache-sharing mask already retained by cacheinfo to the scheduler update. Refresh every surviving CPU using its own LLC domain so that each partition receives the correct share. This also preserves the correction needed as cache-sharing maps grow during boot. Keep the existing CPU-hotplug and scheduler-domain synchronization. The update remains on the hotplug path; no steady-state scheduling operation or persistent allocation is added. Fixes: 7030513a0877 ("sched/cache: Calculate the LLC size and store it in sched_domain") Signed-off-by: Davi Chaves Azevedo Signed-off-by: Tim Chen Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Chen Yu Reviewed-by: Tim Chen Reviewed-by: K Prateek Nayak Tested-by: Chen Yu Tested-by: K Prateek Nayak Cc: # v7.2.x Link: https://patch.msgid.link/6751d93e15889e624796c74db0bfe66603d60b1b.1790035273.git.tim.c.chen@linux.intel.com commit 65efcccddc83d6a19e8a2e2a6117811e39e589bf Author: Chen Yu Date: Mon Sep 21 17:37:26 2026 -0700 sched/cache: Skip kernel threads for cache aware scheduling to rubustify the code Kernel thread should not be covered by cache aware scheduling as it borrows the statistics from the user space thread. Filter the kernel thread in account_mm_sched(). In theory a kernel thread does not have any valid cache group, so !grp should gate the kernel thread. Add the PF_KTHREAD check explicitly here for safety reasons, to guard against future modifications and to pair with task_tick_cache(). Fixes: df0d98475954 ("sched/cache: Introduce infrastructure for cache-aware load balancing") Signed-off-by: Chen Yu Signed-off-by: Tim Chen Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: # 7.2.x Link: https://patch.msgid.link/058f0c6ea7b991c177a17de347fa3157f25489a7.1790035273.git.tim.c.chen@linux.intel.com commit b636fef85bda7d1bab9c0a45067ab1508d79d946 Author: Tim Chen Date: Mon Sep 21 17:37:25 2026 -0700 sched/cache: Introduce task_struct->sched_cache_grp to fix UAF Add a sched_cache_grp pointer to task_struct so that scheduler code can access the cache group directly via the task, without going through mm->sched_cache_grp. This decouples the scheduler's hot-path accesses from the mm_struct. Each task holds its own refcount on the sched_cache_group, separate from the reference held by its mm_struct. The reference is acquired in copy_mm() (fork) and exec_mmap() (exec), and released in exit_mm(). This fixes the use-after-free when account_mm_sched() reaches the group through a task whose mm is being switched, as reported by Hyunwoo: https://lore.kernel.org/lkml/apPb-Dr4nPYuHQOK@v4bel/ Convert all scheduler code in fair.c and exit.c to use p->sched_cache_grp instead of p->mm->sched_cache_grp. Keep the fork/exec/exit reference management out of the generic mm paths: add sched_cache_fork(), sched_cache_fork_cleanup(), sched_cache_exec_mmap() and sched_cache_exit_mm() in kernel/sched/cache_sched.c (with empty stubs for !CONFIG_SCHED_CACHE), so fs/exec.c, kernel/fork.c and kernel/exit.c each call one helper instead of open-coding the refcounting under #ifdef. Also add sched_cache_group_get() and task_cache_group_get(). Fixes: df0d98475954 ("sched/cache: Introduce infrastructure for cache-aware load balancing") Closes: https://lore.kernel.org/lkml/apPb-Dr4nPYuHQOK@v4bel/ Closes: https://lore.kernel.org/all/343a7e07-7fad-4979-9c9b-82ec038c293c@linux.dev/ Reported-by: Hyunwoo Kim Reported-by: Zenghui Yu (Huawei) Co-developed-by: Chen Yu Signed-off-by: Chen Yu Signed-off-by: Tim Chen Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: #7.2.x Link: https://patch.msgid.link/ae7081dc54736bf115215f9867abb2711a7403fb.1790035273.git.tim.c.chen@linux.intel.com commit 28f9c0e0a0b94c5d3e1b634db545f6e1f94858c5 Author: Tim Chen Date: Mon Sep 21 17:37:24 2026 -0700 sched/cache: Decouple sched_cache_group from mm to fix UAF Currently the sched cache grouping is by mm and the scheduling statistics sched_cache_stat lives in the mm structure. This ties the life cycle of scheduling stats with mm. In account_mm_sched(), the scheduling stats are accessed by task->mm->sc_stat. However, a task may be switching mm on one CPU when another CPU is running account_mm_sched(), and possibly accessing the old mm that was freed. This problem was found when running tests with KASAN by Hyunwoo: https://lore.kernel.org/lkml/apPb-Dr4nPYuHQOK@v4bel/ Instead of serializing the mm access by introducing extra acquisition of rq lock in the mm free path, extract sched_cache_stat from mm_struct, rename it as sched_cache_group and manage its life cycle apart from mm_struct with its own ref counting. This allows us in the next patch access sched_cache_group directly from task, and add a refcount on sched_cache_group when a task links to it. This prevents the use after free issue when accessing stale and released old mm and its sched cache stat a task switches to a new mm while account_mm_sched() is done elsewhere. The other benefit of this restructure is in the future, the grouping of tasks to a LLC would have the flexibility to be associated with a user defined grouping, or cgroup, cookie group, numa_group or others instead of just with a single mm address space. Rename sched_cache_stat to sched_cache_group and turn it into a refcounted object allocated from mm_struct. The mm_struct now holds a pointer (sched_cache_grp) to this object instead of embedding it. Fixes: df0d98475954 ("sched/cache: Introduce infrastructure for cache-aware load balancing") Closes: https://lore.kernel.org/lkml/apPb-Dr4nPYuHQOK@v4bel/ Closes: https://lore.kernel.org/all/343a7e07-7fad-4979-9c9b-82ec038c293c@linux.dev/ Reported-by: Hyunwoo Kim Reported-by: Zenghui Yu (Huawei) Co-developed-by: Chen Yu Signed-off-by: Chen Yu Signed-off-by: Tim Chen Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: #7.2.x Link: https://patch.msgid.link/91fd1e3266707c865bc9abecfb3e17bc676712df.1790035273.git.tim.c.chen@linux.intel.com commit d6013e2465d98d524b030a81c1223882a1bb7e4c Author: Lu Wang Date: Mon Sep 21 17:37:23 2026 -0700 sched/cache: Honor migrate_llc_task semantics in active load balance, to fix LLC mis-scheduling bug Cache aware scheduling introduced the migrate_llc_task migration type to direct tasks toward their preferred LLC, but its semantics can be lost when passive load balance falls back to active load balance (ALB). This may allow ALB to select a candidate whose preferred LLC does not match the destination, moving it away from its preferred LLC. Example scenario: src_rq has two runnable tasks, p1 and p2. p1 prefers dst_rq (dst_llc), while p2 prefers src_rq (src_llc). In this case, migrate_llc_task is set because src_rq has at least one task, p1, that wants to migrate to dst_rq. In ALB, can_migrate_task() finds p2 and returns true for it, thus moving p2 out of its preferred LLC. Solution: The CPU stopper in ALB constructs a fresh lb_env that does not inherit migration_type from the passive load-balance pass. Two approaches are possible: (a) Add a new member to struct rq so ALB can inherit migrate_llc_task from the passive LB that triggered it. (b) Define a new flag LBF_ACTIVE_LB_LLC and select the stopper callback at kick time to preserve the migration semantics across the asynchronous boundary. We choose (b) because it avoids passing migration_type through the stopper, which would affect the meaning of migration_type for delayed-dequeue tasks. Fixes: e4c9a4cb244a ("sched/cache: Add migrate_llc_task migration type for cache-aware balancing") Suggested-by: Chen Yu Signed-off-by: Lu Wang Signed-off-by: Tim Chen Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Tim Chen Reviewed-by: Chen Yu Cc: # v7.2.x Link: https://patch.msgid.link/cb39f64a17fc2b76097264aaec74a2d6dfff4315.1790035273.git.tim.c.chen@linux.intel.com commit 0d6526f82c3cdefcca47f73f5fc08dc6f335eac6 Author: Tim Chen Date: Mon Sep 21 17:37:22 2026 -0700 sched/cache: Keep nr_pref_llc_running in the runnable domain, to fix LLC mis-scheduling bug alb_break_llc() decides whether to break LLC preference during active load balance. It does so by testing that every runnable fair task on the source rq prefers its LLC: env->src_rq->nr_pref_llc_running == env->src_rq->cfs.h_nr_runnable But the two counters cover different sets. nr_pref_llc_running is updated in account_llc_enqueue()/account_llc_dequeue(), next to cfs_rq->nr_queued, so it follows queued tasks. h_nr_runnable is updated in set_delayed()/ clear_delayed() and drops delay-dequeued tasks. So under DELAY_DEQUEUE, a preferring task that goes to sleep stays counted in nr_pref_llc_running while h_nr_runnable falls. The equality then breaks, alb_break_llc() returns false, and active balance is free to pull a task off its preferred LLC. Active balance only moves runnable tasks, and this is the only LLC check it consults: once the stopper runs, LBF_ACTIVE_LB skips the per-task test in can_migrate_task(). The runnable set is the one we want. Fix it on the counter side. A task should be counted in nr_pref_llc_running exactly while it is both queued on its preferred LLC (pref_llc_queued) and runnable (!sched_delayed). Define that membership once in task_pref_llc_runnable(), and adjust the counter only through pref_llc_running_inc()/pref_llc_running_dec() from the four sites that change either input: account_llc_enqueue(), account_llc_dequeue(), set_delayed() and clear_delayed(). Gating every update on the same predicate keeps the delay, wake and dequeue paths from double-counting or underflowing; see the comments at those sites for the ordering. nr_llc_running and sd->llc_counts are not touched and stay on queued semantics. Fixes: 714059f79ff0 ("sched/cache: Handle moving single tasks to/from their preferred LLC") Closes: https://lore.kernel.org/lkml/20260827135000.735138-1-zhanxusheng@xiaomi.com/ Reported-by: Zhan Xusheng Suggested-by: Chen Yu Signed-off-by: Tim Chen Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Kayra Cizmeci Cc: # v7.2.x Link: https://patch.msgid.link/06af61afedac32e6477f57feb4d658f6c411c3af.1790035273.git.tim.c.chen@linux.intel.com commit 7f93ca31f7fd9b42e7d692f59514436d448ac908 Author: Felix Fietkau Date: Wed Sep 16 11:48:32 2026 +0200 wifi: mac80211: prevent AP VLAN tx from other interfaces Since the station lookup was factored out of ieee80211_build_hdr(), ieee80211_lookup_ra_sta() uses sta_info_get_bss() for all AP and AP VLAN frames, not only for control port frames. A unicast frame sent on one interface thus matches a station of a different VLAN of the same BSS and is transmitted to it. Only match stations of the interface the frame is sent on, except for control port frames, since those may be sent for VLAN stations directly on the BSS interface. Fixes: 97ffe75791b3 ("mac80211: factor out station lookup from ieee80211_build_hdr()") Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260916094833.164219-1-nbd@nbd.name Signed-off-by: Johannes Berg commit cc45f313d85533d647ce619326302aad6f797c14 Author: Zhao Li Date: Mon Sep 14 23:28:25 2026 +0800 wifi: cfg80211: preserve hidden-group beacon IE ownership A hidden-group probe-response entry borrows its beacon IEs from the group's beacon entry. cfg80211_update_assoc_bss_entry() can pass such an entry to cfg80211_update_known_bss() when merging scan entries after a channel switch. Copying the borrowed beacon_ies into the associated entry gives the same allocation two owners. Releasing the group's beacon entry can then leave the associated entry pointing to freed IEs, which are freed again when that entry is released. Skip beacon IE replacement when the source entry belongs to a hidden group. Preserve probe-response processing, the subsequent metadata updates, and the existing rejection path for conflicting hidden beacon updates. Fixes: 0afd425b1b64 ("cfg80211: fix duplicated scan entries after channel switch") Reported-by: Yilin Zhang Closes: https://lore.kernel.org/linux-wireless/20260901080427.1983015-1-yilinzhang@moonshot.ai/ Assisted-by: Codex:gpt-6-astra Signed-off-by: Zhao Li Signed-off-by: Johannes Berg commit a10a2f80476d166fd81c361ec0319493671b694e Author: Zhao Li Date: Thu Sep 10 14:52:51 2026 +0800 wifi: mac80211: keep fallback association elements alive Associating to a non-transmitted MBSSID profile reads freed memory while determining the operating channel and applying HT capabilities. When an association response omits WMM, HT, or VHT information, ieee80211_assoc_config_link() parses the cached BSS IEs and copies the missing element pointers out of that fallback parse. For a non-transmitted MBSSID profile those pointers refer to merged-profile storage owned by the parse object, and the fallback block frees that object at its end. The copied pointers are used afterwards to determine the operating channel, configure bandwidth, and apply HT capabilities. Keep the fallback parse result alive until association setup finishes. Fixes: 5023b14cf4df ("mac80211: support profile split between elements") Cc: stable@kernel.org Assisted-by: LLM sparse kasan [reorder variable declaration] Signed-off-by: Zhao Li Signed-off-by: Johannes Berg commit e588e83e5c7a0f6d7a77dbbb58927c8c8cfd598e Author: Zhao Li Date: Thu Sep 10 14:54:02 2026 +0800 wifi: mac80211: shut down RX BA session timer on teardown Tearing down an RX BA session can leave the session timer queued on a freed tid_rx. Later timer-wheel processing and the timer callback itself then run against freed memory. An RX BAR handler can dereference tid_rx under RCU before teardown unpublishes it and stay in its read-side critical section while teardown deletes the session timer. The stale handler can then rearm the timer after timer_delete_sync() returns and before the RCU callback frees tid_rx. Use timer_shutdown_sync() so rearm attempts become ineffective once teardown starts. Keep reorder_timer unchanged: teardown marks the session removed under reorder_lock and its release path checks that state before rearming. session_timer has no equivalent guard because ieee80211_rx_h_ctrl() rearms it before taking reorder_lock. Fixes: a87f736d942c ("mac80211: use RCU for RX aggregation") Cc: stable@kernel.org # 5.15+ Assisted-by: LLM sparse kasan Signed-off-by: Zhao Li Signed-off-by: Johannes Berg commit 6bdcdb31318c10e6369cff8e5b32c37397e98091 Author: Yuqi Xu Date: Mon Sep 21 10:52:04 2026 +0800 wifi: mac80211: validate TX status rate metadata minstrel_ht_tx_status() converts the HT/VHT rate reported in a TX status into a group and rate index and uses those to index the minstrel_ht rate tables. The existing validation only checked that an entry was present and had tries recorded; it did not check that the reported MCS, spatial stream count and bandwidth are representable by the tables, so malformed metadata passed to minstrel_ht_get_stats() or minstrel_ht_ri_get_stats() could be used as an out-of-bounds index. Validate the rate metadata in the common TX status path instead of only in minstrel_ht, since the values are used by more than rate control. The legacy ieee80211_tx_rate array and the rate_info based entries are sanitized in ieee80211_tx_status_ext() and ieee80211_tx_rate_update() before any consumer runs: an entry that does not describe a valid rate for its encoding is dropped. minstrel_ht keeps the checks that depend on its own tables, i.e. the supported number of spatial streams, the MCS group size and the supported bandwidths. This does not take away the driver's responsibility to report sane values, it only prevents a single bad report from corrupting mac80211 state. No WARN_ON() is added: with panic_on_warn a driver bug would otherwise turn into a denial of service. Fixes: a5f69d94d8e2 ("mac80211: Get rid of search loop for rate group index") Fixes: 9208247d74bc ("mac80211: minstrel_ht: add basic support for VHT rates <= 3SS@80MHz") Reported-by: Vega Assisted-by: LLM Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Link: https://patch.msgid.link/607e985d71fbbe63ebfc182a37f882f04f980f7f.1789958876.git.xuyuqiabc@gmail.com Signed-off-by: Johannes Berg commit 37aba16e7943634eb3e5e2e7e850ebb38500d935 Author: John Ogness Date: Mon Sep 21 16:45:36 2026 +0206 serial: 8250: Change console_msr_work to IRQ_WORK_LAZY Change console_msr_work (defers MSR handling) to be IRQ_WORK_LAZY, thus not raising an IRQ upon irq_work queueing. The irq_work is then handled on the next kernel tick. This additional delay is acceptable because any pending MSR handling is also performed in the interrupt handler, if mctrl is queried, and during console resume. Using IRQ_WORK_LAZY has the benefit of not needing to raise an IRQ for each line of atomic console printing when modem control is active. On a side note, the Tegra20 and Tegra30 platforms can hang if an irq_work IRQ is raised while entering cpuidle states. This problem was reproducible by performing atomic printing while entering cpuidle. So this change also provides a workaround for these platforms (as long as they are not running tickless). The discussion on this topic is linked below. Link: https://lore.kernel.org/lkml/f3757a75-0ba1-4558-bf57-f19ab7e59a4c@nvidia.com Fixes: d3539347022a ("serial: 8250: Switch to nbcon console, take 2") Signed-off-by: John Ogness Reviewed-by: Petr Mladek Tested-by: Jon Hunter Link: https://patch.msgid.link/20260921143939.170314-1-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman commit c6c159fcdb4e9a678eda0831f971e4a3a488ec47 Author: Gilberto Conde Date: Mon Sep 21 10:34:19 2026 +0100 pinctrl: qcom: ipq5018: add missing pwm3 function on gpio13 GPIO13 supports the PWM3 function at mux select value 4, but the pingroup table leaves that slot empty and gpio13 is not listed in pwm3_groups. Selecting pwm3 on gpio13 is therefore rejected by the pinmux core: ipq5018-tlmm: invalid group "gpio13" for function "pwm3" The GL.iNet GL-X2000 drives its fan from PWM3 on this pin, and the vendor firmware muxes it with select value 4: gpio13 : out low func4 8mA no pull Add pwm3 to the fourth function slot of gpio13 and list gpio13 in pwm3_groups. With this the pin muxes as expected: pin 13 (GPIO_13): device 1941010.pwm function pwm3 group gpio13 Fixes: 725d1c891658 ("pinctrl: qcom: Add IPQ5018 pinctrl driver") Signed-off-by: Gilberto Conde Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260921093419.2870168-1-gilbertorconde@gmail.com Signed-off-by: Bartosz Golaszewski commit 72b782097e534ab48152dd25aaba40dda5f25f9e Author: Jakub Pawlak Date: Mon Sep 14 10:43:01 2026 +0200 accel/ivpu: Use separate flag for job timeout Use separate flag to mark a job timeout as a reason of starting context_abort_work. This allows to distinguish engine reset reason and clearly adjust reset procedure flow. The flag is cleared in ivpu_prepare_for_reset(), which every recovery and suspend path already funnels through, so that the state is clean after recovery. Cc: stable@vger.kernel.org # v7.1+ Fixes: ade00a6c903f ("accel/ivpu: Perform engine reset instead of device recovery on TDR") Signed-off-by: Jakub Pawlak Reviewed-by: Dawid Osuchowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260914084301.894028-1-karol.wachowski@linux.intel.com commit 6c43c72748fffd29dec15cd1f31e9a32949bc437 Author: Melody Wang Date: Mon Sep 14 00:57:17 2026 +0000 x86/sev: Make vTPM SVSM calls preemption-safe Two functions in the SVSM vTPM guest implementation do not disable preemption when fetching the SVSM Calling Area Address (CAA). The SVSM CAA is a per-CPU structure. When a thread is preempted and migrated to a different CPU after fetching the per-CPU CAA, the SVSM call will execute on the new CPU with the original CPU's CAA. Which is wrong. Move the CAA fetching operation inside svsm_perform_call_protocol() which disables interrupts around the SVSM call and thus runs preemption-safe. Fixes: 770de678bc28 ("x86/sev: Add SVSM vTPM probe/send_command functions") Signed-off-by: Melody Wang Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Stefano Garzarella Cc: stable@vger.kernel.org Link: https://patch.msgid.link/a5bc0d4a2c462a0089109e145c21626b244b2ff0.1789345277.git.huibo.wang@amd.com commit f0b88fade64c6fe52e15b246097d10bb115d8af3 Merge: be31fe6333f534 6d91041bb38b97 Author: Jakub Kicinski Date: Mon Sep 21 18:20:07 2026 -0700 Merge tag 'for-net-2026-09-21' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: Core: - hci_conn: fix CIS hold ownership on reuse - hci_sock: reject out-of-range OCF values - hci_sock: validate event length before filtering - L2CAP: validate frame length before control and FCS access - RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO - RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame() - ISO: release unused CIS holds after channel attach - ISO: balance the parent hold in hci_bind_bis() - SMP: reject Security Request over BR/EDR - MGMT: fix race in read_unconf_index_list() - MGMT: Dequeue pending mesh_send_sync entries on cancel - BNEP: fix out-of-bounds reads on short RX/TX frames and control fallthrough Drivers: - btintel_pcie: validate device-supplied DMA indices - btnxpuart: Fix skb leak in nxp_process_fw_dump() * tag 'for-net-2026-09-21' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame() Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO Bluetooth: btintel_pcie: validate device-supplied DMA indices Bluetooth: bnep: fix out-of-bounds reads on short RX/TX frames and control fallthrough Bluetooth: mgmt: fix race in read_unconf_index_list() Bluetooth: L2CAP: validate frame length before control and FCS access Bluetooth: ISO: balance the parent hold in hci_bind_bis() Bluetooth: hci_sock: validate event length before filtering Bluetooth: hci_sock: reject out-of-range OCF values Bluetooth: ISO: release unused CIS holds after channel attach Bluetooth: hci_conn: fix CIS hold ownership on reuse Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel Bluetooth: btnxpuart: Fix skb leak in nxp_process_fw_dump() Bluetooth: SMP: reject Security Request over BR/EDR ==================== Link: https://patch.msgid.link/20260921135807.3459373-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski commit be31fe6333f534155e6b408f1ef6d77974bb41aa Author: Kuniyuki Iwashima Date: Sun Sep 20 19:14:32 2026 +0000 ipv6: Fix dst leak for uncached routes. ip6_route_output_flags(), ip6_rt_put_flags(), and ip6_dst_check() detect an uncached route by list_empty(&rt->dst.rt_uncached), which replaced the static DST_NOCACHE flag check in commit a4c2fd7f7891 ("net: remove DST_NOCACHE flag"). When a device is unregistered, rt6_uncached_list_flush_dev() unlinks uncached routes tied to the device from rt6_uncached_list. Previously, they were moved to another list with list_move() (__list_del_entry() + list_add()), and since commit 98aa546af5e4 ("inet: remove (struct uncached_list)->quarantine"), the routes are just unlinked with list_del_init(). If list_del_init() runs concurrently, list_empty() evaluates to true; ip6_route_output_flags() calls dst_hold_safe() incorrectly and ip6_rt_put_flags() skips ip6_rt_put(), leaking dst, and thus dev tied via rt->from as well. The same race is partially fixed by commit 9a6f0c4d5796 ("dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()"). Let's check rt6->dst.rt_uncached_list instead. Note that IPv4 does not have the same issue. Fixes: 98aa546af5e4 ("inet: remove (struct uncached_list)->quarantine") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Hangbin Liu Reviewed-by: Xuanqiang Luo Reviewed-by: Ido Schimmel Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260920191558.2990636-1-kuniyu@google.com Signed-off-by: Jakub Kicinski commit 2e828035d5d736d904c238ae7ec3f77c0d6270bf Author: Zihan Xi Date: Wed Sep 16 15:29:29 2026 +0000 smb: client: preserve create-context parsing errors smb2_compound_op() saves the result from compound_send_recv() in tmp_rc. For SMB2_OP_OPEN_QUERY it then parses the CREATE contexts, but the final assignment of rc from tmp_rc discards a parsing error. A malformed create-context response can therefore be reported as successful to smb2_query_path_info(). Keep a create-context parsing error in tmp_rc so it survives per-command response processing and is returned to the caller. Fixes: b07687edee99 ("cifs: Improve SMB2+ stat() to work also without FILE_READ_ATTRIBUTES") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Tested-by: Frank Sorenson Signed-off-by: Paulo Alcantara commit 6c5c547f037bc18f0b8d0b5db5a648f8f630ce85 Author: Zihan Xi Date: Wed Sep 16 15:29:28 2026 +0000 smb: client: close completed creates on compound wait errors compound_send_recv() waits for responses in order. If a later wait is interrupted, or if a later MID fails during response synchronization, an earlier CREATE may already have opened a remote handle. The earlier mid is then released without invoking handle_cancelled_mid(), leaving the remote handle open because no FID was copied to the caller. Mark completed earlier mids as cancelled when a compound wait or MID synchronization aborts. Keep their response buffers attached while the MIDs are synchronized, and transfer them only after synchronization of the processed responses, so the release path can inspect successful CREATE responses and queue SMB2_close() after a later failure. Account for a remote open only after the close work is allocated and before it is queued, since the caller has not yet updated num_remote_opens. Mark the create+close compound used by smb2_unlink() so it is not closed again. Non-CREATE responses and compounds that already include a close keep their existing behavior. Fixes: e0bba0b85481 ("cifs: add compound_send_recv()") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Tested-by: Frank Sorenson Signed-off-by: Paulo Alcantara commit d2ff5fb93ea83034025850266b5eed391f96b825 Author: Zihan Xi Date: Wed Sep 16 15:29:27 2026 +0000 smb: client: clean up failed cached directory opens open_cached_dir() sends CREATE and QUERY_INFO as a compound request. If the CREATE succeeds but a later command returns an error, the function must retain the CREATE FID so common cleanup can issue SMB2_close(). It also must not treat a response error as a valid CREATE. Validate the CREATE response before using its fields, record the FIDs, and mark the handle open before handling errors from later compound commands. Move the -EREMCHG reconnect handling before response validation so a missing response does not hide the reconnect request. Count the handle when it is marked open; confirmed close responses decrement the counter, while existing close retry behavior remains best effort on transport failures. Fixes: b0f6df737a1c ("cifs: cache FILE_ALL_INFO for the shared root handle") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Tested-by: Frank Sorenson Signed-off-by: Paulo Alcantara commit 566820af017e81497fb5e9d3ad6e7ffe2828bc8b Author: Zihan Xi Date: Wed Sep 16 15:29:26 2026 +0000 smb: client: close handle after create-context parsing failure SMB2_open() accounts a successful CREATE response as a remote open before parsing its create contexts. If smb2_parse_contexts() rejects malformed context data, SMB2_open() returns without closing the handle, leaving the server-side handle open and num_remote_opens elevated. Close the handle after a post-CREATE context parsing failure so the error path releases the remote resource and balances the open count. Fixes: af1689a9b770 ("smb: client: fix potential OOBs in smb2_parse_contexts()") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Tested-by: Frank Sorenson Signed-off-by: Paulo Alcantara commit fa2e9900dd2a3f5a1e7ef5a8c5e8d435feedbfcc Author: Zihan Xi Date: Wed Sep 16 15:29:25 2026 +0000 smb: client: validate POSIX create context length parse_posix_ctxt() reads the fixed nlink, reparse_tag, and mode fields before checking that the POSIX create context contains them. A short context can pass the generic checks and still make these fixed-width reads run past its declared data. The current in-tree smb2_open_file() path passes a NULL posix pointer, so this handler is not reached on the ordinary open path. Still require the POSIX data to cover all three fields before reading them because the helper performs those unguarded reads. Keep the existing soft-failure behavior so malformed optional metadata does not fail the open. Fixes: 69dda3059e7a ("cifs: add SMB2_open() arg to return POSIX data") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Tested-by: Frank Sorenson Signed-off-by: Paulo Alcantara commit 67f4c1c6a1b51e203d986779299824d1c2c590a6 Author: Zihan Xi Date: Wed Sep 16 15:29:24 2026 +0000 smb: client: fix create context out-of-bounds reads smb2_parse_contexts() validates the complete create-context area but does not limit each record to its Next field before dispatching it. A malformed chain can therefore expose bytes beyond the current context to a handler. The QFid handler also used a full response-structure cast although it only reads DiskFileId. The SMB2/SMB3 lease parsers made the same layout assumption: they read LeaseState and LeaseFlags at canonical offsets rather than at DataOffset. A valid non-canonical DataOffset could therefore yield unrelated in-bounds data, while a short DataLength was still accepted. Limit each context to its Next value, reject offsets before the context header, and reject malformed chains. Bound the name range by the current context and do not dispatch a known handler when DataLength is zero. Read the QFid DiskFileId only when the context data covers that field. Parse the lease context from DataOffset and require DataLength to match the v1 or v2 lease_context size used by ksmbd. A size mismatch skips lease parsing without failing the open. Fixes: b8c32dbb0deb ("CIFS: Request SMB2.1 leases") Fixes: f047390a097e ("CIFS: Add create lease v2 context for SMB3") Fixes: 89a5bfa350fa ("smb3: optimize open to not send query file internal info") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Tested-by: Frank Sorenson Signed-off-by: Paulo Alcantara commit 10de7ed8ef4840da9ca21de4c29578657ac367db Author: Andrea Parri Date: Thu Sep 17 13:55:42 2026 +0200 net/mlx5e: fix swapped IPv6 IPsec policy masks IPv6 XFRM policies may use different source and destination prefix lengths. mlx5e_ipsec_policy_mask() builds the corresponding masks independently, but setup_fte_addr6() installs each mask in the opposite address field. When the prefix lengths differ, this makes the source match use the destination prefix and the destination match use the source prefix. The resulting hardware rule can both miss traffic covered by the policy and match traffic outside it. Install each mask in its corresponding match field. Fixes: ca7992f52c2c ("net/mlx5e: Properly match IPsec subnet addresses") Cc: stable@vger.kernel.org Signed-off-by: Andrea Parri Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260917115542.177675-1-parri.andrea@gmail.com Signed-off-by: Jakub Kicinski commit be581d6635579489eadff9cea4caee142ec6d8bc Author: Yuya Kusakabe Date: Fri Sep 18 22:49:30 2026 +0900 selftests: net: fix CONFIG_SYSCTL sort order in configs Commit 8d75c338f0bc ("sysctl: remove CONFIG_PROC_SYSCTL, it just mirrors CONFIG_SYSCTL") renamed CONFIG_PROC_SYSCTL to CONFIG_SYSCTL in place, which left the entry out of alphabetical order in the net and packetdrill configs. The netdev CI check for sorted selftest configs now fails for every patch that touches either file. Fixes: 8d75c338f0bc ("sysctl: remove CONFIG_PROC_SYSCTL, it just mirrors CONFIG_SYSCTL") Signed-off-by: Yuya Kusakabe Reviewed-by: Joel Granados Link: https://patch.msgid.link/20260918-selftests-net-config-sort-v1-1-968ea6e8c1b7@gmail.com Signed-off-by: Jakub Kicinski commit c06bde80ae7a7b595732f7cabcb92cf08db9d56a Author: Pengpeng Hou Date: Sun Sep 20 11:47:45 2026 +0800 net: usb: sr9700: include receive overhead in the length check The receive fixup subtracts the Ethernet CRC from the reported packet length, but compares that payload length against the whole remaining receive buffer. The following copy starts after the three-byte header, and the cursor advance consumes both that header and the four-byte CRC. Require the payload to fit after SR_RX_OVERHEAD before copying it or advancing to the next packet. The loop already ensures that the remaining buffer is larger than the overhead, so the subtraction is safe. The issue was found by our static-analysis tool. Fixes: c9b37458e956 ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support") Reviewed-by: Ethan Nelson-Moore Tested-by: Ethan Nelson-Moore Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260920034745.18468-1-hppiscas@163.com Signed-off-by: Jakub Kicinski commit 7cce782d8327b7291334c4a304cf3fd909a74d9d Author: Ivan Vecera Date: Thu Sep 17 16:37:36 2026 +0200 dpll: use exact lookup for reference sync pin id dpll_pin_ref_sync_state_set() looks up the reference sync pin in the pin->ref_sync_pins xarray, which is keyed by the sync pin's id (see dpll_pin_ref_sync_pair_add() using xa_insert() with ref_sync_pin->id). The pin id to operate on is supplied by userspace via DPLL_A_PIN_ID. The lookup however used xa_find() with a ULONG_MAX limit, which returns the first present entry with an index greater than or equal to the requested id, not the entry stored exactly at that id. If userspace passes an id that is not paired as a reference sync pin, but another pin with a higher id is present in the xarray, xa_find() silently returns that wrong pin and the subsequent ref_sync_set() operates on it. The request only fails when the given id is larger than every present key. Use xa_load() for an exact-key lookup instead, mirroring the deletion path in dpll_pin_ref_sync_pair_del(). Fixes: 58256a26bfb3 ("dpll: add reference sync get/set") Signed-off-by: Ivan Vecera Link: https://patch.msgid.link/20260917143736.526221-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski commit 31995571219c8ac30913d9c0dccad033fbb0b3da Author: Nicolai Buchwitz Date: Fri Sep 18 11:55:40 2026 +0200 net: don't require the hwtstamp NDOs when a PHY provides timestamping Removing the legacy ioctl fallback made both hwtstamp NDOs mandatory. A device that only timestamps in its PHY implements neither, so SIOCSHWTSTAMP fails with EOPNOTSUPP before anything looks at the PHY and PTP stops working there. The check only ever picked the legacy path. That path is gone, so drop it and test where the NDOs are actually called. SIOCGHWTSTAMP is new here, not restored. The old path went through phy_mii_ioctl(), which only handled SIOCSHWTSTAMP. Such a device now returns -ENODEV while absent instead of -EOPNOTSUPP, like the ones that do implement the NDOs. Fixes: 5062245a5a7f ("net: remove legacy way to get/set HW timestamp config") Signed-off-by: Nicolai Buchwitz Reviewed-by: Kory Maincent Link: https://patch.msgid.link/20260918095540.34286-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski commit 0346ec2f080b40d95ed05b853bb9226289e75212 Author: Kuniyuki Iwashima Date: Fri Sep 18 08:22:05 2026 +0000 ipv6: Prevent rt6_insert_exception() for dying fib6_info. Before the cited commit, fib6_nh_flush_exceptions() always set from->exception_bucket_flushed = 1 under rt6_exception_lock to prevent rt6_insert_exception() from inserting a new exception for a dying fib6_info. The flag was replaced with the FIB6_EXCEPTION_BUCKET_FLUSHED bit stored in nh->rt6i_exception_bucket. The problem is that now the bit is only set when the bucket is not NULL and fib6_nh_flush_exceptions() is called from fib6_nh_release() after fib6_ref has already reached zero. If rt6_insert_exception() is called while the target fib6_info is being removed via fib6_purge_rt(), a new exception could be created successfully because rt6_flush_exceptions() no longer sets the bit. This creates a reference cycle between the fib6_info and the exception route, leaking the fib6_info, its nexthop device, and all per-CPU routes in fib6_nh->rt6i_pcpu, which stalls netdev unregistration. [ 34.680602] unregister_netdevice: waiting for gre6 to become free. Usage count = 68 [ 44.920675] unregister_netdevice: waiting for gre6 to become free. Usage count = 68 [ 55.176582] unregister_netdevice: waiting for gre6 to become free. Usage count = 68 Let's call fib6_drop_pcpu_from() before rt6_flush_exceptions(), to set fib6_destroying before rt6_exception_lock, and check f6i->fib6_destroying in rt6_insert_exception(). Note that FIB6_EXCEPTION_BUCKET_FLUSHED logic is dead and we can clean it up in net-next. Fixes: cc5c073a693f ("ipv6: Move exception bucket to fib6_nh") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260918082209.2853582-1-kuniyu@google.com Signed-off-by: Jakub Kicinski commit d06f2ebf67ff2962fe00d687e4f0d4703eb41a12 Author: Ratheesh Kannoth Date: Wed Sep 16 07:51:11 2026 +0530 octeontx2-af: Fix memory scaling limitation in SR-IOV mode The original code used DMA_ATTR_FORCE_CONTIGUOUS, which could exhaust the CMA pool when a large number of VFs were requested. Fix this by switching to the DMA streaming API. This is equivalent on Octeon platforms, which provide full I/O coherency via the SMMU. Cc: Leon Romanovsky Fixes: 73d33dbc0723 ("octeontx2-af: Use DMA_ATTR_FORCE_CONTIGUOUS attribute in DMA alloc") Signed-off-by: Ratheesh Kannoth Reviewed-by: Leon Romanovsky Link: https://patch.msgid.link/20260916022111.1083017-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski commit 12fec40907fafe5262216e477e7b6ae74e40ab58 Merge: 1e24c4f2ee44be 70194dc37670bd Author: Jakub Kicinski Date: Mon Sep 21 15:10:28 2026 -0700 Merge tag 'nf-26-09-18' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Pablo Neira Ayuso says: ==================== Netfilter/IPVS fixes for net The following patchset contains Netfilter/IPVS fixes for net, they are: 1) Set on HW_DEAD after HW_PENDING is cleared in the flowtable offload to ensure GC does not zap it, from Jérémy Jean. 2) Hold the nfnetlink_queue mutex while removing the queue instance from the netlink notifier that handles NETLINK_URELEASE to fix a possible race with the UNBIND command. From Florian Westphal. 3) Reject route with NULL rt6i_idev in ip6t_rpfilter. From Weiming Shi. 4) Reject rtinfo->addrnr set to zero from ip6t_rt .checkentry path. This also fortifies the datapath loop as per Florian's request. From Luxiao Xu. 5) Fix checksuming in nft_synproxy for IPv6, from Karl Mehltretter. 6) Revalidate ihl before calling icmp_send() in IPVS, from Julian Anastasov. 7) Fix suspicious RCU usage splat in ctnetlink with expectations. 8) Check for expired catchall elements in the insert and deactivate path. From Aohan Mei. * tag 'nf-26-09-18' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_tables: skip expired catchall elements on insert and delete netfilter: ctnetlink: fix suspicious RCU usage in expect_iter_name ipvs: revalidate ihl before icmp_send netfilter: nft_synproxy: use the family-aware checksum helper netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read netfilter: ip6t_rpfilter: reject routes without inet6_dev netfilter: nfnetlink_queue: hold nfnl mutex in event notifier netfilter: flowtable: publish HW_DEAD after worker is done ==================== Link: https://patch.msgid.link/20260918112844.194503-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski commit 0b6e06f9501aacaa3aa555de510eef81371ded95 Merge: a11212910cf09b 8244668cbbffc8 Author: Andrii Nakryiko Date: Mon Sep 21 15:00:59 2026 -0700 Merge branch 'bpf-reject-non-negative-stack-object-offsets' Xu Yunxiang says: ==================== bpf: Reject non-negative stack object offsets Reject non-negative offsets before converting a stack object address to a stack slot index. Add a regression test for iterator destruction through fp+0. Changes in v2: - Split the kernel change and selftest as requested by Andrii. - Rebase onto bpf/master at a11212910cf09b2fe8db9afa41ef60c4f81879c5. - Keep the original code and test changes unchanged and retain Sun Jian's Reviewed-by on both parts. v1: https://lore.kernel.org/bpf/20260911084314.3481637-1-xyx2021@mail.ustc.edu.cn/ Split request: https://lore.kernel.org/bpf/CAEf4BzbYzt-Riekpc-A=MfQft9ZELwSDSE8kkQO1ZOyR3O_FAg@mail.gmail.com/ Validation on this exact candidate with a matching bpf_testmod: - W=1 verifier, full kernel/modules, changed BPF objects and test_progs builds passed. - iters: 1/97 passed; 0 skipped. - dynptr: 2/132 passed; 0 skipped. - irq: 1/33 passed; 0 skipped. - res_spin_lock: 3/14 passed; 1 skipped. - file_reader: 1/8 passed; 0 skipped. - kmem_cache_iter: 1/3 passed; 0 skipped. - dmabuf_iter: 1/4 passed; 0 skipped. No selected test failed. The VM ran with panic_on_warn and panic_on_oops; no kernel WARN, Oops or panic was found. res_spin_lock_stress skips because the VM has no hardware PMU. Annotated verifier tests check load outcomes and diagnostics. The full unfiltered suite, sanitizer configurations and architecture matrix were not run. Please queue this fix for stable after it reaches the BPF tree. ==================== Link: https://patch.msgid.link/20260920210423.345636-1-xyx2021@mail.ustc.edu.cn Signed-off-by: Andrii Nakryiko commit 8244668cbbffc8e242b2c5204a2dea20bfca096c Author: Xu Yunxiang Date: Mon Sep 21 05:04:22 2026 +0800 selftests/bpf: Reject iterator destruction through fp+0 Add a verifier regression test that initializes a numeric iterator at fp-8 and attempts to destroy it through fp+0. The verifier must reject the non-negative offset instead of treating it as the initialized stack slot. Check the offset diagnostic to ensure rejection happens at the stack object address check. The numeric iterator destroy operation is a no-op; this test checks verifier rejection and does not run the program. Signed-off-by: Xu Yunxiang Signed-off-by: Andrii Nakryiko Reviewed-by: Sun Jian Link: https://lore.kernel.org/bpf/20260920210423.345636-3-xyx2021@mail.ustc.edu.cn commit 79a9172f3ab4ad8392c5e5c8944b9b7710ade620 Author: Xu Yunxiang Date: Mon Sep 21 05:04:21 2026 +0800 bpf: Reject non-negative offsets in stack_slot_obj_get_spi() bpf_get_spi() computes (-off - 1) / BPF_REG_SIZE using C division, which truncates toward zero. For off == 0, this produces spi 0, the same index used by the valid stack slot at fp-8. stack_slot_obj_get_spi() currently checks alignment and the resulting spi bounds, but does not reject the non-negative offset itself. It can therefore validate a PTR_TO_STACK register holding fp+0 against an iterator stored at fp-8 even though the runtime receives the actual fp+0 pointer. An effectful iterator kfunc can then interpret memory outside the BPF stack as iterator state. Reject non-negative offsets before converting the offset to an spi. All valid stack objects begin at a negative offset from the frame pointer. Fixes: 06accc8779c1 ("bpf: add support for open-coded iterator loops") Signed-off-by: Xu Yunxiang Signed-off-by: Andrii Nakryiko Reviewed-by: Sun Jian Link: https://lore.kernel.org/bpf/20260920210423.345636-2-xyx2021@mail.ustc.edu.cn commit 055ef5ce9f67a6a3a1363fa663007f8196cc0fb8 Author: Runyu Xiao Date: Wed Sep 2 16:03:18 2026 +0800 rtc: spear: initialize IRQ state before requesting alarm IRQ devm_request_irq() enables the interrupt before it returns, so the handler may run while probe is still initializing the device. Initialize the MMIO address and spinlock before requesting the alarm IRQ. Fixes: 0942a71e435f ("rtc: add support for spear rtc") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260902080318.3498434-1-runyu.xiao@seu.edu.cn Signed-off-by: Alexandre Belloni commit 94b7e3a7e871ae27d4935c76959dfc61829f27f9 Author: Helge Deller Date: Sat Sep 19 22:09:20 2026 +0200 parisc: Increase kernel stack size to 32kb For 64-bit Linux kernels, increase the default kernel stack size (THREAD_SIZE_ORDER) to 32 kB, in order to avoid kernel crashes which have been triggered recently when building the debian vtk9 package with gcc 17: stackcheck: kworker/u128:0 will most likely overflow kernel stack (sp:179a83af0, stk bottom-top:179a80000-179a84000) Kernel panic - not syncing: low stack detected by irq handler - check messages CPU: 2 UID: 0 PID: 30760 Comm: kworker/u128:0 Tainted: G W 6.18.46-dirty #1 NONE Tainted: [W]=WARN Hardware name: 9000/800/rp3440 Workqueue: writeback wb_workfn (flush-259:0) Backtrace: [<000000004022f050>] show_stack+0x70/0x90 [<000000004022378c>] dump_stack_lvl+0x124/0x190 [<000000004022382c>] dump_stack+0x34/0x48 [<000000004020212c>] vpanic+0x204/0x648 [<00000000402025c4>] panic+0x54/0x58 [<0000000040232230>] do_cpu_irq_mask+0x3f8/0x440 [<0000000040227070>] intr_return+0x0/0xc Signed-off-by: Helge Deller Reported-by: John David Anglin Cc: stable@vger.kernel.org # v6.18+ commit ac41b05d15db3134e839148290d67415ee0bdb58 Author: Manush Prajwal Date: Sun Sep 6 16:44:09 2026 +0530 rtc: mpfs: fix unchecked devm_clk_get() error pointer in probe() devm_clk_get(&pdev->dev, "rtcref")'s return value was passed straight into clk_get_rate() without checking it for an error first, unlike the "rtc" clock a few lines above which is correctly checked with IS_ERR(). clk_get_rate() only guards against a NULL clk, not an error pointer: if (!clk) return 0; ... rate = clk_core_get_rate_recalc(clk->core); so if devm_clk_get() ever returns an error pointer here (for example ERR_PTR(-EPROBE_DEFER), which is the normal, expected outcome if the clkcfg clock-provider this RTC depends on has not registered its clocks yet by the time this driver probes), clk_get_rate() dereferences that error pointer instead of returning 0, crashing instead of letting probe defer. Capture the clock in the existing 'clk' local and check it with IS_ERR() before calling clk_get_rate(), matching the handling already used for the "rtc" clock in this same function. Signed-off-by: Manush Prajwal Fixes: 0b31d703598d ("rtc: Add driver for Microchip PolarFire SoC") Reviewed-by: Conor Dooley Link: https://patch.msgid.link/6a9d4b02.7d74b517.206c4c.75f8@mx.google.com Signed-off-by: Alexandre Belloni commit fcf0b58e976e83adf246b014518e49c662b96f5e Author: Aamir Ahmed Date: Sat Sep 5 21:41:52 2026 +0100 rtc: ac100: Fix clock provider use-after-free on probe failure ac100_rtc_register_clks() registers the RTC-32k clock with clk_hw_register_fixed_rate() and the clock provider with of_clk_add_hw_provider(). Neither is device managed, and both are released only from ac100_rtc_remove(). The driver core does not call remove() when probe() fails: really_probe() reaches probe_failed below the device_remove() call and goes straight to releasing the device's managed resources. ac100_rtc_probe() ends with return devm_rtc_register_device(chip->rtc); so if that fails after the clocks have been registered, the provider is left on the global of_clk_providers list holding chip->clk_data, which was allocated with devm_kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take <&ac100_rtc 1>, and the sun9i-a80 boards route osc32k through <&ac100_rtc 0>. The window is narrow, as devm_rtc_register_device() can only fail with -ENOMEM here, but the provider is left dangling whenever it does. The RTC-32k clock is leaked on the same path. Since clk_core_lookup() searches a global list that is not scoped per device, __clk_register() rejects the duplicate name with -EEXIST, so the leak also makes a later probe of the same device fail. The error path that returns -EINVAL when the ADDA 4M parent clock cannot be found leaks the RTC-32k clock in the same way. No provider has been registered at that point, so that one is a leak rather than a use-after-free. Register both with devm_clk_hw_register_fixed_rate() and devm_of_clk_add_hw_provider() so that they are released whenever the device goes away, on a failed probe as well as on unbind. Devres releases in reverse order of acquisition, so the provider is removed before chip->clk_data is freed, and the clkout children are now unregistered before their parent rather than after it. ac100_rtc_unregister_clks() and the remove callback then have nothing left to do and are removed. Fixes: d00a18a42c14 ("rtc: ac100: Add RTC driver for X-Powers AC100") Reported-by: Sashiko AI Closes: https://lore.kernel.org/linux-rtc/20260905184936.155E11F00A3A@smtp.kernel.org/ Assisted-by: LLM Signed-off-by: Aamir Ahmed Link: https://patch.msgid.link/AS8P251MB0001A489CC45A591ABBB9BDCC8B42@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Alexandre Belloni commit 6a4117eee82dd85f11bf898bf66026764011eeb6 Author: Aamir Ahmed Date: Sat Sep 5 19:38:08 2026 +0100 rtc: ac100: Assign .num before accessing .hws Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS) about the number of elements in .hws[], so that it can warn when .hws[] is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in ac100_rtc_register_clks() due to .num being assigned only after every clkout clock has been stored in .hws[]. With CONFIG_UBSAN_BOUNDS and a compiler that implements __counted_by (GCC 15.1+ or Clang 20.1+), this triggers an array-index-out-of-bounds report during probe, and with CONFIG_UBSAN_TRAP the first store traps. Initialize .num with AC100_CLKOUT_NUM, the number of elements .hws[] was allocated with, right after the allocation. That is the value the loop counter ends up at on the success path anyway, so the provider's behaviour is unchanged. Cc: stable@vger.kernel.org Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") Assisted-by: LLM Signed-off-by: Aamir Ahmed Reviewed-by: Chen-Yu Tsai Reviewed-by: Gustavo A. R. Silva Link: https://patch.msgid.link/AS8P251MB00013E724A77A355668B6CCEC8B42@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Alexandre Belloni commit b430d1f6d80c005b486f028910e1ac3c91812710 Author: Johnny.Fan Date: Mon Aug 31 22:00:14 2026 +0800 rtc: efi: restore alarm support with runtime capability probe Restore the EFI RTC alarm functionality (read_alarm/set_alarm and procfs output) that was removed by commit 18a3510bc87d ("rtc: efi: Remove wakeup functionality"). The removal was motivated by the observation that many EFI platforms lack RTC wakeup support while also omitting the RT_PROP table, causing the wakeup capability to be incorrectly advertised. While that is true, removing the feature entirely also breaks platforms where the wakeup runtime service actually works. On CIX SoCs, the RTC is an I2C device owned by firmware, and in the ACPI boot configuration the I2C bus it sits on is not exposed to the OS, so the EFI runtime services are the only way Linux can access the RTC at all. Both Linux and Windows use this same interface by design, so the RTC state is consistent across the operating systems installed on the machine, and Windows relies on the EFI wakeup services for its own RTC alarm support. With the alarm support removed from rtc-efi, Linux loses the equivalent capability entirely on these platforms: rtcwake fails for both suspend-to-RAM and power-off wakeup, as there is no other path to program the RTC alarm. This is a real product requirement that CIX customers have explicitly requested, not a hypothetical use case. To avoid exposing a broken alarm on firmware that does not implement the wakeup runtime services, probe the capability at ->probe() time by actually calling GetWakeupTime() -- if it fails, clear RTC_FEATURE_ALARM and the device behaves as before the removal. Also set RTC_FEATURE_ALARM_WAKEUP_ONLY since EFI wakeup time is a wakeup-only alarm, not a periodic/update interrupt source. Acked-by: Ard Biesheuvel Reviewed-by: Feng Tang Reviewed-by: Fugang Duan Signed-off-by: Johnny.Fan Link: https://patch.msgid.link/20260831140014.839222-1-johnny.fan@cixtech.com Signed-off-by: Alexandre Belloni commit 0ee5c5d804d592a8328a425b9274487d393d3a05 Author: Liu Dalin Date: Thu Aug 27 09:54:44 2026 +0800 rtc: dev: zero-initialize struct rtc_wkalrm to prevent information leak The struct rtc_wkalrm has padding holes after the 'pending' member. When returned to userspace via the RTC_WKALRM_RD ioctl, uninitialized kernel stack data residing in these holes may be leaked. Zero-initialize the struct at declaration to eliminate this information leak risk. Fixes smatch warnings: - drivers/rtc/dev.c:392 rtc_dev_ioctl() warn: check that 'alarm' doesn't leak information (struct has a hole after 'pending') Fixes: 36e14f5fdfdf ("rtc: rename core files") Assisted-by: smatch:2.0 [static analysis] Signed-off-by: Liu Dalin Link: https://patch.msgid.link/B28B7DE18F3A9447+20260827015444.3314227-1-liudalin@kylinsec.com.cn Signed-off-by: Alexandre Belloni commit aeaca27c1db3106967ffbb2b517d98c835f6d500 Author: Georgios Karantzas Date: Fri Sep 11 03:11:43 2026 +0300 wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE __hif_usb_tx() dequeues up to MAX_TX_AGGR_NUM (20) frames into a single tx_buf of MAX_TX_BUF_SIZE (32768) bytes, limiting the batch by record count but never by cumulative byte length. With large frames (MTU 2304), 20 aggregated frames of 2292 bytes each exceed the allocation (20 * 2296 = 45920 bytes), so the memcpy() in the loop writes up to 13152 bytes past tx_buf->buf before usb_submit_urb(). Peek the queue head and stop before copying any record that would cross MAX_TX_BUF_SIZE, then dispatch the current batch. Leftover skbs remain queued and are drained on the next URB completion. The byte bound changes the loop's exit semantics: it can now exit before i == tx_skb_cnt - 1. Stock only finalized tx_buf->len on that last index (len += offset), so an early break would submit a URB holding only the last record's length while every dequeued skb is freed on completion, silently dropping frames. Make tx_buf->len a running total and advance tx_buf->offset per record instead; the stride round_up(nskb->len + 4, 4) is identical to the stock stride when the loop runs to completion. Tested on hardware with an MTU 2304 flood: the loop stops at record 15 (len = 32144, offset = 32144, within 32768), no oversized URB is submitted, and MTU 1500 pings pass 20/20. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by: Georgios Karantzas Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260911001143.4507-1-gck.kara@gmail.com Signed-off-by: Jeff Johnson commit 93ce8ea70451e800601bc9444aa33043de15d67b Author: Pengpeng Hou Date: Fri Aug 14 15:58:37 2026 +0800 wifi: ath9k: reject short WMI command responses ath9k_wmi_rsp_callback() removes the validated WMI header and copies the number of bytes expected by the waiting command into its response buffer. A device response shorter than that expectation can therefore be read beyond the skb payload. Record -EMSGSIZE for a short response, complete the waiter, and return the stored status from the command path. This also prevents callers from consuming stale response bytes as a successful reply. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Assisted-by: LLM Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260814075837.20005-1-pengpeng@iscas.ac.cn Signed-off-by: Jeff Johnson commit 1af8dc9ca726cf53767f9c0661171396f95c146a Author: Toke Høiland-Jørgensen Date: Tue Sep 8 19:05:18 2026 +0200 wifi: ath9k: Clean up device initialisation guards The ath9k driver has a couple of guards against the RX path running until device initialisation has completed. However, they are problematic for several reasons: - They use smp_wmb() paired with a data_race() annotation, instead of the idiomatic smp_store_release()/smp_load_acquire() pair. - The guard in ath9k_wmi_event_tasklet() is weirdly late in the function. - There are two of them when there's really no reason the rx init gets to run before the whole initialisation is complete. Consolidate the guards on the single ath9k_htc_priv->initialized variable and use smp_store_release()/smp_load_acquire() to access it. Move the store into ath9k_init_device() to make sure it's set in all paths in the driver. Fixes: 24355fcb0d4c ("wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete") Fixes: b0ec7e55fce6 ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_rxep()") Signed-off-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260908170520.112946-1-toke@redhat.com Signed-off-by: Jeff Johnson commit 7e0ad05ebc72fffba2bdf2400400902d94ed7272 Author: Nicolas Escande Date: Wed Aug 12 16:58:05 2026 +0200 wifi: ath11k: reset ar->num_stations on hardware start When (multiple) hw restart occurs, we end up in a situation where we cannot accept new stations / mesh peers. This seems to be the 'num_stations' in 'struct ath11k' that did not get reset properly in this case. In ath11k_mac_op_start(), it was indeed the only accounting var that did not get reset so let's clear it too. This avoids problems like those: [1248828.088023] WARNING: CPU: 0 PID: 12281 at net/mac80211/util.c:1682 ieee80211_reconfig_stations+0x98/0xc0 [1248828.088115] Call trace: [1248828.088116] ieee80211_reconfig_stations+0x98/0xc0 (P) [1248828.088119] ieee80211_reconfig+0x774/0x1438 [1248828.088123] ieee80211_restart_work+0x10c/0x178 [1248828.088127] process_one_work+0x178/0x3c0 [1248828.088130] worker_thread+0x280/0x440 [1248828.088133] kthread+0xe0/0xf8 [1248828.088137] ret_from_fork+0x10/0x20 [1248828.088141] ---[ end trace 0000000000000000 ]--- [1248836.686604] ath11k_pci 0000:04:00.0: refusing to associate station: too many connected already (128) [1248836.686609] ath11k_pci 0000:04:00.0: Failed to add station: xx:xx:xx:xx:xx:xx for VDEV: 1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Nicolas Escande Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260812-num-station-v3-1-871d20e043f6@gmail.com Signed-off-by: Jeff Johnson commit f11a16c8200189a3752b5233092f88503969166d Author: Hui Peng Date: Sat Sep 19 20:35:19 2026 +0000 io_uring: zero big_cqe for aux CQEs on CQE32 rings io_fill_cqe_aux() only clears big_cqe if cqe32 is set, which is only the case for CQE_MIXED. On a CQE32 ring every CQE is 32b, and the extra 16b are left holding whatever was in that slot before. Clear it for CQE32 rings as well, like it was before CQE_MIXED support was added. Fixes: e26dca67fde1 ("io_uring: add support for IORING_SETUP_CQE_MIXED") Assisted-by: LLM Signed-off-by: Hui Peng Link: https://patch.msgid.link/20260919203516.2581409-1-benquike@gmail.com [axboe: split from Hui's original patch, edited commit message] Signed-off-by: Jens Axboe commit ab5853c068b1d654d7c4a535417ca3eb3e67403b Author: Hui Peng Date: Sat Sep 19 20:35:18 2026 +0000 io_uring: fix free entry check for 32b CQEs on CQE32 rings On CQE32 rings, len is in units of 32b CQEs when io_cqe_cache_refill() checks for free entries, so requiring cqe32 + 1 of them means insisting on 2 free CQEs where 1 is enough, and a ring with a single free entry needlessly goes to overflow. Check for a free CQE directly in that case, and keep the cqe32 + 1 check for CQE_MIXED where the units are 16b. Fixes: e26dca67fde1 ("io_uring: add support for IORING_SETUP_CQE_MIXED") Assisted-by: LLM Signed-off-by: Hui Peng Link: https://patch.msgid.link/20260919203516.2581409-1-benquike@gmail.com [axboe: split from Hui's original patch, edited commit message] Signed-off-by: Jens Axboe commit 2107751744287996a9bbcf40b5055a5b7fe30b5c Author: Hui Peng Date: Sat Sep 19 20:35:16 2026 +0000 io_uring: only post the dummy skip CQE on CQE_MIXED rings io_cqe_cache_refill() posts a dummy skip CQE when a 32b CQE would straddle the end of the ring, so the real one can start at offset 0. That only makes sense on CQE_MIXED rings, where slots are 16b and a 32b CQE needs two of them back to back. On a CQE32 ring every slot is already 32b, but io_fill_cqe_aux32() still passes cqe32 == true, and the dummy then gets written at cqes[off] rather than cqes[off << 1], inside another CQE. Limit the dummy to CQE_MIXED rings. Fixes: e26dca67fde1 ("io_uring: add support for IORING_SETUP_CQE_MIXED") Assisted-by: LLM Signed-off-by: Hui Peng Link: https://patch.msgid.link/20260919203516.2581409-1-benquike@gmail.com [axboe: split from Hui's original patch, edited commit message] Signed-off-by: Jens Axboe commit 50b617ba788e5c27dfc6efc90556cdcc9509028d Author: Hui Peng Date: Sat Sep 19 11:25:23 2026 +0000 io_uring/bpf_filter: mark source as COW when cloning filters io_bpf_filter_clone() shares the filter table between source and destination and marks the destination as needing a copy before it can be modified, but leaves the source as is. Registering another filter on the source then modifies the shared table in place, and the change shows up in everything that cloned it. Mark the source as COW as well. Fixes: ed82f35b926b ("io_uring: allow registration of per-task restrictions") Assisted-by: LLM Signed-off-by: Hui Peng Link: https://patch.msgid.link/20260919112523.3872581-1-benquike@gmail.com [axboe: edited patch and commit message] Signed-off-by: Jens Axboe commit ca039df94983c441fdee0e2488263fc744e8ecb6 Author: Sahil Chandna Date: Mon Sep 14 03:39:09 2026 -0700 PCI: hv: Warn when wait_for_response() waits indefinitely A guest can wait indefinitely in wait_for_response() for the host to send either a rescind message or a packet completion. If the host does not send either, the guest can remain blocked with no diagnostic indicating a reason. This was observed during a guest kernel upgrade in which the host-side application handling the PCI channel faulted, causing the guest to never receive the completion request. Add a warning in wait_for_response() when the wait exceeds a timeout so that such a hang is visible in the guest's kernel log and can be correlated with host-side state. Suggested-by: Michael Kelley Reviewed-by: Naman Jain Signed-off-by: Sahil Chandna Signed-off-by: Wei Liu commit f0100363d8c374bd8e9ea7c9ba02744f0b802ca4 Merge: 93f51579e7df24 fe2f9135df43db Author: Linus Torvalds Date: Mon Sep 21 08:22:53 2026 -0700 Merge tag 'xfs-fixes-7.3-rc5' of gitolite.kernel.org:/pub/scm/fs/xfs/xfs-linux Pull xfs fixes from Carlos Maiolino: "This mostly contain 'random' bugfixes found by LLM tools on different xfs subsystems. A few code cleanups and a NULL ptr deref on zoned support. Those 'random' bugfixes include possible buf overrus, UAFs, block leaks, etc..." * tag 'xfs-fixes-7.3-rc5' of gitolite.kernel.org:/pub/scm/fs/xfs/xfs-linux: (26 commits) xfs: fix wild memcpy access when formatting ondisk rtrefcount btree roots xfs: don't let hidden_space go negative in xfs_metafile_resv_init xfs: drop dquot flush lock when we can't find a buffer to flush xfs: fix cursor and pointer handling when recovering iunlink buckets xfs: fix blockgc group quota scanning when usrquota isn't enforced xfs: don't merge different file IO error types xfs: don't let memory failures leak blocks and kill repairs xfs: don't cross reference rmapbt with bitmaps if they're incomplete xfs: fix rtgroup repair estimations xfs: call xfs_dquot_set_prealloc_limits if we installed default rtb limits xfs: fix typos and repeated words in comments xfs: remove unused xfs_reflink_remap_range declaration xfs: remove duplicate INO1_WRITTEN check xfs: don't try to get a reference to a NULL oz in xfs_get_cached_zone xfs: check di_forkoff correctly in scrub xfs: only flag zero padding for dir3 data blocks, not dir3 block blocks xfs: fix integer overflows in xbitmap set functions xfs: use the correct reservations for rtrmap/refcount recovery xfs: don't call xfs_exchange_range_finish for a dry run xfs: check padding field in xfs_ioc_commit_range ... commit 9eda41e32263806a66835e275efdcc0c5f46bbc4 Author: Stanislaw Gruszka Date: Sat Sep 19 11:24:54 2026 +0200 wifi: cfg80211: fix RTS threshold setting for single-radio PHY Due to an incorrect old_radio_rts_threshold check, we do not set rdev->wiphy.rts_threshold for a single-radio PHY, and the threshold value is not propagated to lower layers. Cc: stable@vger.kernel.org Fixes: 264637941cf4 ("wifi: cfg80211: Add Support to Set RTS Threshold for each Radio") Signed-off-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260919092454.50266-1-stf_xl@wp.pl Signed-off-by: Johannes Berg commit 5bfd4b0b40b79781d900cb2f7da0685070f53c67 Author: Yuqi Xu Date: Sat Sep 19 16:48:12 2026 +0800 wifi: mac80211: handle empty FILS association request payload fils_encrypt_assoc_req() accepts a (Re)Association Request frame whose last element is the FILS Session element. crypt_len is then zero and aes_siv_encrypt() is called with an empty plaintext. kmemdup() returns ZERO_SIZE_PTR for a zero-length allocation, so the unconditional sg_init_one() puts an invalid page into the scatterlist. With CONFIG_DEBUG_SG this triggers a kernel BUG in sg_set_buf(); without the debug check the bogus page is handed to the crypto backend. AES-SIV is defined for empty plaintext and the S2V result is then the complete output, so handle this case before the CTR step, which has nothing to encrypt. Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Link: https://patch.msgid.link/325c048982d637a3af80d74ac5b36e9369b93f1e.1789751126.git.xuyuqiabc@gmail.com Signed-off-by: Johannes Berg commit 15fb9e3cea55fbc378261ce35a32b0f8828f0000 Author: Yuqi Xu Date: Sat Sep 19 16:46:20 2026 +0800 wifi: mac80211: minstrel_ht: validate fixed rate index The fixed_rate_idx debugfs file is a plain u32 attribute, so any value can be written to it. minstrel_ht_update_stats() then copies the value into mi->max_tp_rate[] and mi->max_prob_rate, and minstrel_ht_set_rate() uses MI_RATE_GROUP()/MI_RATE_IDX() to index minstrel_mcs_groups[] (42 entries) and mi->groups[].rates[] (10 entries) with it. Writing e.g. 65535 selects group 4095 and rate index 15, far outside both arrays. The out-of-bounds entries are dereferenced and updated as struct minstrel_rate_stats (retry counts, etc.), so the invalid index corrupts adjacent kernel memory. With CONFIG_UBSAN_BOUNDS the access is reported as an array-index-out-of-bounds in minstrel_ht_set_rate(). Only a valid group/rate pair, or U32_MAX to disable fixed rate processing, can be used safely, so reject any other value when the debugfs file is written. The file is only reachable through a root-only debugfs mount, so this is not a privilege boundary. The out-of-bounds access is still a bug that must not be reachable through a writable debugfs attribute. Fixes: 24f7580e852b ("minstrel_ht: fixed rate mode through debugfs") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Link: https://patch.msgid.link/288e6f6d30dc82ff40da502755e6666982f6b735.1789798000.git.xuyuqiabc@gmail.com Signed-off-by: Johannes Berg commit db7b86bd97b380ece8fa39cfdd7502a9fd35e56f Author: Heyang Tan Date: Fri Sep 18 16:33:49 2026 +0800 wifi: p54: validate firmware record lengths The p54 firmware parser accesses component ID and component version records without checking that their lengths cover the fields being read. A malformed record can therefore make the parser read past the record. Validate the component ID and component version record lengths before accessing their data. The descriptor record is also checked against the shortest descriptor length found in the supported firmware images. Reject descriptor values that underflow the RX offset or produce an empty RX range before updating the driver state. Assisted-by: LLM Codex Signed-off-by: Heyang Tan Tested-by: Christian Lamparter Link: https://patch.msgid.link/20260918083349.891-1-thy15333007817@163.com Signed-off-by: Johannes Berg commit ee3aadc43ea69d98f666431e787137ac0badbb85 Author: Zihan Xi Date: Fri Sep 18 05:26:51 2026 +0000 wifi: mac80211: fix mesh fast xmit path deletion UAF mesh_fast_tx_cache() stores raw mesh_path pointers. Path deletion flushes the cache and then frees the path with kfree_rcu(), but a lookup that already holds the path can insert a new cache entry after the flush. The cache then points at freed memory. Set MESH_PATH_DELETED before flushing, and skip inserting a cache entry if the path or MPP path is already deleted. Check this under the cache walk lock so it is ordered with the flush. Use WRITE_ONCE() for the deletion flag updates because the cache check reads flags without taking state_lock. Fixes: d5edb9ae8d56 ("wifi: mac80211: mesh fast xmit support") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Link: https://patch.msgid.link/1daa7a98199fe6965c2da7c42717073a6fd39a0b.1789615568.git.zihanx@nebusec.ai Signed-off-by: Johannes Berg commit 5e4f3509793b4db2c0835340224743db680e861f Author: Yuchao Zhang Date: Fri Sep 18 11:40:04 2026 +0800 wifi: mac80211: drop oversized fragments to avoid extra_len overflow In ieee80211_rx_h_defragment(), fragment payloads are accumulated into entry->extra_len as subsequent fragments arrive: entry->extra_len += rx->skb->len; When the final fragment arrives, the head fragment is dequeued, and pskb_expand_head() is called with entry->extra_len to ensure sufficient tailroom for all queued fragments before copying: if (skb_tailroom(rx->skb) < entry->extra_len) { if (unlikely(pskb_expand_head(rx->skb, 0, entry->extra_len, GFP_ATOMIC))) { ... } } while ((skb = __skb_dequeue(&entry->skb_list))) { skb_put_data(rx->skb, skb->data, skb->len); dev_kfree_skb(skb); } In commit 69f132236827 ("mac80211: shrink struct ieee80211_fragment_entry"), entry->extra_len was narrowed from unsigned int to u16 in order to reduce structure memory footprint. However, an IEEE 802.11 frame sequence can contain up to 16 fragments (frag numbers 0..15). If a sequence of large fragments arrives (e.g. from a malicious peer or rogue AP), the sum of fragment lengths can exceed 65535 bytes (for example, 15 fragments of 4400 bytes total 66000 bytes). Because extra_len is a u16, this addition overflows and wraps around modulo 65536 (e.g. 66000 wraps to 464). Consequently, pskb_expand_head() allocates only the truncated amount of tailroom (or is skipped entirely if the head fragment already has >= 464 bytes of tailroom). When skb_put_data() subsequently iterates through the queued skb list, it appends the full payload into the undersized buffer, causing skb_put() to trigger skb_over_panic() and crash the kernel in softirq context. A legitimate MSDU in IEEE 802.11 is at most 2304 bytes (or up to 7935/11454 bytes for A-MSDU, which is not fragmented), well below U16_MAX. Fix this without increasing the size of struct ieee80211_fragment_entry by checking whether adding the incoming fragment length would exceed U16_MAX. If so, purge the queued fragments and drop the frame. Fixes: 69f132236827 ("mac80211: shrink struct ieee80211_fragment_entry") Signed-off-by: Yuchao Zhang Link: https://patch.msgid.link/20260918034004.85078-2-ndaugoing@gmail.com [assign a separate drop reason] Signed-off-by: Johannes Berg commit a8b8881d0c1aff544fae190469d86db7b07f43a9 Author: Wentao Liang Date: Thu Sep 17 12:23:25 2026 +0000 wifi: wlcore: Fix runtime PM leak in wlcore_remove() pm_runtime_get_sync() keeps the runtime PM usage counter elevated even when it returns an error, so the reference taken at the beginning of wlcore_remove() has to be dropped on every exit path. When the device was not initialized the function returned early without doing so, leaking the reference. Release it with pm_runtime_put_noidle() as done on the other early error paths of this driver. Fixes: fa2648a34e73f ("wlcore: Add support for runtime PM") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917122325.2150910-1-vulab@iscas.ac.cn Signed-off-by: Johannes Berg commit 67a9e80c3ca20c9044cd6ee72cd6278dd19b5023 Author: Zhao Li Date: Wed Sep 16 19:37:35 2026 +0800 wifi: mac80211: drain PS delivery work during station teardown Removing an AP or mesh station can notify the driver and wake TXQs after the station has already been removed from the driver, and can update num_sta_ps and the power-save queues after station cleanup has purged them. sta_deliver_ps_frames() tests sta->dead only before it starts delivery. A worker that passes that test can be delayed while teardown sets sta->dead and removes the station from the driver; when it resumes it still runs the full delivery. The existing cancel_work_sync() sits near the end of __cleanup_single_sta(), after the final driver state transition and after PS accounting and queue purging, so it drains the worker only once the state it has to protect has already changed. Before commit d34ba2168a3c ("mac80211: don't delay station destruction") cleanup was deferred through the same ordered workqueue as the delivery work, which kept the two ordered. Cancel the work after setting sta->dead and before moving the driver state, and move the existing cancellation to the start of __cleanup_single_sta(). The first drain closes the driver-lifetime window; driver callbacks during the remaining state transitions can still queue drv_deliver_wk through ieee80211_sta_block_awake(), so retain the second drain at the start of __cleanup_single_sta(). That drain also covers insertion failures, which reach cleanup without setting sta->dead. Fixes: d34ba2168a3c ("mac80211: don't delay station destruction") Cc: stable@vger.kernel.org Assisted-by: LLM sparse smatch coccinelle kasan Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260916113735.31029-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg commit a5f35d4b112af1415ff06bd501c8cc26cc08aa8b Author: Zhao Li Date: Wed Sep 16 19:36:49 2026 +0800 wifi: mac80211: account proxy paths against the mesh path limit Proxy-path churn can drive the interface path counter negative and let later mesh path additions exceed MESH_MAX_MPATHS. mesh_path_free_rcu() decrements the interface mpaths counter for entries from both the mesh and proxy path tables, but mpp_path_add() never reserves a slot in that counter. Removing or expiring a proxy path therefore returns a slot that was never charged. mesh_path_add() uses the same counter to enforce MESH_MAX_MPATHS, so once it falls below the number of installed paths the limit no longer holds. Reserve the shared quota before allocating a proxy path and release it on every unsuccessful addition. Mesh and proxy paths now share one 1024-entry budget, so mpp_path_add() can return -ENOSPC at that limit. Fixes: ece1a2e7e860 ("mac80211: Remove mesh paths when an interface is removed") Cc: stable@vger.kernel.org Assisted-by: LLM sparse kasan Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260916113649.28315-3-enderaoelyther@gmail.com Signed-off-by: Johannes Berg commit 7325a44474f20c1393a1c114c6811abce6ddfaf4 Author: Zhao Li Date: Wed Sep 16 19:36:48 2026 +0800 wifi: mac80211: release mesh path quota on failed additions Repeated failed or duplicate mesh path additions can exhaust MESH_MAX_MPATHS while the path table holds fewer paths, which stops new paths to reachable destinations from being created. mesh_path_add() reserves a slot before allocating and inserting a path. If allocation fails, the function returns without releasing the slot. If the rhashtable insertion reports an error or an existing destination, the function discards its candidate but retains the reservation. No new path is installed in any of these cases. Release the reservation whenever the candidate is not installed. Fixes: ae76eef027f7 ("mac80211: return new mpath from mesh_path_add()") Fixes: 60854fd94573 ("mac80211: mesh: convert path table to rhashtable") Cc: stable@vger.kernel.org Assisted-by: LLM sparse kasan Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260916113649.28315-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg commit 9b3fcf519d370df94a56f3b272d9eddffffa5be8 Author: Palla Raghunath Date: Sat Sep 19 00:43:39 2026 +0100 dm ioctl: don't let data_start run past the buffer 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 commit 6d91041bb38b97e2feb625123cc0529d7b83a0e1 Author: Hui Peng Date: Sat Sep 19 11:25:14 2026 +0000 Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame() While rfcomm_recv_frame() verifies that skb->len is at least sizeof(*hdr) + 1 (4 bytes: 3-byte header + 1-byte FCS), an RFCOMM frame with an extended 2-byte length field (!__test_ea(hdr->len)) has a 4-byte header plus a 1-byte FCS (5 bytes minimum, sizeof(*hdr) + 2). When a 4-byte RFCOMM frame with EA == 0 arrives: 1. The initial skb->len < sizeof(*hdr) + 1 check passes (4 < 4 is false). 2. Trimming the FCS byte decrements skb->len to 3. 3. If __check_fcs() succeeds, skb_pull(skb, 4) fails (4 > 3) and returns NULL without advancing skb->data. 4. Because the return value of skb_pull() is ignored, the un-pulled 3-byte struct rfcomm_hdr remains at skb->data and is either queued as application payload via rfcomm_recv_data() or parsed as a multiplexer control command via rfcomm_recv_mcc() on DLCI 0. Fix this by extending the length check in rfcomm_recv_frame() to also require skb->len >= sizeof(*hdr) + 2 when !__test_ea(hdr->len). Fixes: b230e5bf501c ("Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame") Assisted-by: LLM Signed-off-by: Hui Peng Signed-off-by: Luiz Augusto von Dentz commit 46f8ffd0a1f1eb6cbc94946a92c11ef601e228a1 Author: Hui Peng Date: Sat Sep 19 11:25:18 2026 +0000 Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO The RFCOMM_CONNINFO getsockopt handler accepts a socket that is not connected as long as deferred setup is enabled: if (sk->sk_state != BT_CONNECTED && !rfcomm_pi(sk)->dlc->defer_setup) { err = -ENOTCONN; break; } l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk; dlc->defer_setup is set in rfcomm_sock_init() when rfcomm_connect_ind() creates a child socket for an incoming connection on a listening socket that has BT_DEFER_SETUP enabled. It is never cleared afterwards. The session, however, can go away underneath it. rfcomm_recv_disc() forces the dlc state before tearing it down: d->state = BT_CLOSED; __rfcomm_dlc_close(d, err); The RFCOMM_DEFER_SETUP early return in __rfcomm_dlc_close() only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2, so with the state already BT_CLOSED that switch does not match and the function falls through to rfcomm_dlc_unlink(), which sets d->session = NULL, while d->defer_setup stays 1. A getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) on the accepted socket after that point therefore skips the -ENOTCONN path -- sk->sk_state is BT_CLOSED, but dlc->defer_setup is still set -- and dereferences the NULL session. No race is needed: once the DISC has been processed, the dereference is unconditional. Reproduced on a KASAN kernel under QEMU with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session and sends SABM for a channel bound with BT_DEFER_SETUP, and sends DISC for that dlci after the socket has been accepted. getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) on the accepted socket then hits: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 150 Comm: init Tainted: G B 7.3.0-rc3-g5dd1818b15d9 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:rfcomm_sock_getsockopt+0x529/0x780 Call Trace: do_sock_getsockopt+0x3ad/0x7d0 __sys_getsockopt+0x10e/0x1b0 __x64_sys_getsockopt+0xc2/0x160 do_syscall_64+0xda/0x4b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f 0x10 is the offset of sock in struct rfcomm_session; rfcomm_sock_getsockopt_old() is inlined into rfcomm_sock_getsockopt(). Commit 43a556b2fd43 ("Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept") fixed the same "a remote DISC clears the session while deferred setup is still flagged" problem in rfcomm_dlc_accept(); this is the remaining instance of it, in the getsockopt path. Deferred setup only leaves a socket usable here once it has reached BT_CONNECT2, so restrict the exception to that state and check that a session is actually present before following it. Fixes: bb23c0ab8246 ("Bluetooth: Add support for deferring RFCOMM connection setup") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Hui Peng Signed-off-by: Luiz Augusto von Dentz commit 37a11129345337efd6eef8e62b03b6348cd0dd8b Author: Ravindra Date: Tue Sep 15 10:42:15 2026 +0530 Bluetooth: btintel_pcie: validate device-supplied DMA indices In btintel_pcie_msix_rx_handle(), the driver processes RX completion descriptors (urbd1) written by the PCIe device into DMA-coherent memory. urbd1->frbd_tag (a 16-bit field fully controlled by the device firmware via DMA) is used directly as an array index into rxq->bufs[] without any bounds check. rxq->bufs[] has only BTINTEL_PCIE_RX_DESCS_COUNT (64) entries, while frbd_tag can be any value 0-65535. A malicious or malfunctioning device can write an out-of-range frbd_tag, causing the driver to dereference an out-of-bounds data_buf pointer. Additionally, cr_hia is read from a DMA-shared index array also writable by the device; if the device sets cr_hia >= rxq->count, the while-loop never terminates because cr_tia is wrapped via modulo rxq->count and can never equal an out-of-range cr_hia. Add bounds validation for cr_hia and frbd_tag in the RX path, and cr_hia in the TX path. Log invalid values with bt_dev_err before returning. Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Ravindra Signed-off-by: Luiz Augusto von Dentz commit f0ca020cbb9bb7f3f4ea8ba1dfcf30a282aec91e Author: Hui Peng Date: Sat Sep 19 22:17:38 2026 +0000 Bluetooth: bnep: fix out-of-bounds reads on short RX/TX frames and control fallthrough Fix multiple out-of-bounds reads in Bluetooth BNEP frame processing: 1. In bnep_rx_frame() and bnep_ctrl_frame() (net/bluetooth/bnep/core.c), use pskb_may_pull() to verify the BNEP header, control type byte, filter count, and extension headers exist before reading them, and return 0 after handling BNEP_CONTROL instead of falling through to Ethernet frame submission when no extension headers follow. 2. In bnep_net_xmit() (net/bluetooth/bnep/netdev.c), verify skb->len >= ETH_HLEN with pskb_may_pull() before reading the 14-byte Ethernet header to prevent an out-of-bounds heap read and infoleak on short AF_PACKET TX frames. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: LLM Signed-off-by: Hui Peng Signed-off-by: Luiz Augusto von Dentz commit 75fc8a3ee5aee72f2fea3b6436170fae175f7f19 Author: Sheetal Date: Mon Sep 21 08:57:02 2026 +0000 ASoC: tegra: Fix ASRC Stream6 input threshold control The Stream6 Input Threshold control points at stream index 4, which is already used by Stream5. The threshold get and put callbacks derive the lane ID from the register offset, so the duplicate index makes Stream6 operate on lane 4 and leaves lane 5 inaccessible from userspace. Use stream index 5 for Stream6. Fixes: a2df8c2d5b36 ("ASoC: tegra: Add Tegra186 based ASRC driver") Signed-off-by: Sheetal Reviewed-by: Thierry Reding Link: https://patch.msgid.link/20260921085704.1248920-2-sheetal@nvidia.com Signed-off-by: Mark Brown commit 24a22fb3c731474b68e986af6804db450fb88617 Author: Matthew Auld Date: Fri Sep 18 14:10:35 2026 +0100 drm/xe/vm: nuke PTs only after unlinking contested VMAs In xe_vm_close_and_put(), external-BO VMAs are queued on the contested list for deferred destruction via xe_vma_destroy_unlocked(). However, xe_vm_pt_destroy() was previously invoked before processing contested VMAs, destroying vm->pt_root while those VMAs were still linked to their respective buffer objects (vm_bo->list.gpuva). If a concurrent thread evicts one of those shared buffer objects, xe_bo_trigger_rebind() holding only bo->resv walks the BO's VMAs and, in fault mode, calls xe_vm_invalidate_vma() -> xe_pt_zap_ptes(). Because vm->pt_root[tile->id] is already NULL, dereferencing pt->level causes a NULL ptr deref. Fix this by deferring xe_vm_free_scratch() and xe_vm_pt_destroy() until after all contested VMAs have been unlinked and destroyed. User is reporting hitting a NULL ptr deref in xe_pt_zap_ptes(), which could be explained by this race. Assisted-by: LLM Fixes: b06d47be7c83 ("drm/xe: Port Xe to GPUVA") Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/9290 Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: # v6.12+ Reviewed-by: Thomas Hellström Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260918131034.598078-2-matthew.auld@intel.com (cherry picked from commit c2863648959489767f08892fd6e90577d2ea0b6a) Signed-off-by: Rodrigo Vivi commit be1df8badae513e01d9575398438716cfae18655 Author: Matthew Brost Date: Thu Sep 17 13:31:58 2026 -0700 drm/xe: Keep walking on SVM eviction failure The desired behavior for SVM eviction failures, which can occur due to various uncontrollable races, is for TTM to continue walking the LRU list and look for another eviction candidate. This is expressed by returning -ENOSPC from the ->move() callback. Adjust the SVM eviction failure path because of races in ->move() to return -ENOSPC so that TTM continues searching for another buffer to evict. Fixes: 3ca608dc7561 ("drm/xe: Basic SVM BO eviction") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost Reviewed-by: Himal Prasad Ghimiray Link: https://patch.msgid.link/20260917203158.292823-1-matthew.brost@intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit 36a86c23588b8f57c9d20feb4cf5a2ab27e3baba) Signed-off-by: Rodrigo Vivi commit c7a925c84704ec431598f9411dd89c0e16ae34ae Author: Shuicheng Lin Date: Mon Sep 14 21:53:18 2026 +0000 drm/xe/tlb_inval: Treat wedged-device invalidations as complete A TLB invalidation issued on a wedged device fails with -ENOTRECOVERABLE. xe_tlb_inval_issue() squashes only -ECANCELED, so the error reaches callers that treat it as unexpected and WARN, tainting the kernel on a wedge that was deliberately caused: ggtt_invalidate_gt_tlb() drivers/gpu/drm/xe/xe_ggtt.c xe_svm_invalidate() drivers/gpu/drm/xe/xe_svm.c xe_bo_trigger_rebind() drivers/gpu/drm/xe/xe_bo.c xe_vma_userptr_do_inval() drivers/gpu/drm/xe/xe_userptr.c igt@xe_exec_reset@gt-reset-fault-injection hits the GGTT one, turning an otherwise passing run into an abort: *ERROR* SIGID=102 FATAL (-EIO) WEDGED: Device declared wedged! Tile0: GT1: Failed to invalidate GGTT (-ENOTRECOVERABLE) WARNING: drivers/gpu/drm/xe/xe_ggtt.c:588 at ggtt_invalidate_gt_tlb Workqueue: xe-guc-destroy-wq __guc_exec_queue_destroy_async [xe] ggtt_node_remove+0xe3/0x100 [xe] xe_ggtt_remove_bo+0x89/0x2c0 [xe] xe_ttm_bo_destroy+0xcb/0x330 [xe] ... xe_lrc_destroy+0x74/0x90 [xe] xe_exec_queue_fini+0x2d/0x60 [xe] -ECANCELED and -ENOTRECOVERABLE mean the same thing at this layer: the message was dropped rather than delivered, and the fence has already been signalled before the error is returned, so there is nothing left to wait for. Squash both. A wedged device is only recovered by a fresh initialisation, so the error return in xe_bo_trigger_rebind() becomes unreachable by design. v2: fix all invalidation paths. (Sashiko) Fixes: 50fa9acac26f ("drm/xe/guc: distinguish wedged from recoverable cancellation") Assisted-by: Claude:claude-opus-5 Cc: Sk Anirban Cc: Matthew Brost Signed-off-by: Shuicheng Lin Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260914215318.200603-1-shuicheng.lin@intel.com (cherry picked from commit af14e3705345cb57c53b237169873233052a5c16) Signed-off-by: Rodrigo Vivi commit ea4debcd8016f73c5dee3a29250a3d7977f015ef Author: Sk Anirban Date: Wed Sep 9 17:19:32 2026 +0530 drm/xe/gt_throttle: Report power brake as a throttle reason on CRI CRI defines bit 5 of the perf limit reasons register as a power brake (PWRBRK) indicator. Add PWRBRK_MASK and a reason_pwrbrk sysfs attribute for CRI in place of reason_ratl. Signed-off-by: Sk Anirban Fixes: 8578e6d0546c ("drm/xe/gt_throttle: Drop individual show functions") Reviewed-by: Raag Jadav Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260909114931.1039331-2-sk.anirban@intel.com (cherry picked from commit e199c851c0ab608a0ca89e7be1756a1461b41a2c) Signed-off-by: Rodrigo Vivi commit f8ebe286394c0bbb4a6dbacb182a34ab6376922d Author: Guangshuo Li Date: Wed Sep 16 15:37:36 2026 +0800 wifi: iwlegacy: 3945: free EEPROM data on remove il3945_pci_probe() calls il_eeprom_init(), which allocates memory for the EEPROM data. The probe failure paths release this allocation with il_eeprom_free(), but the remove path does not free it after a successful probe. As a result, the EEPROM data is leaked when the PCI device is removed. Free the EEPROM data in il3945_pci_remove() before releasing the mac80211 hardware structure. This issue was found by manual code inspection. Fixes: 073d3f5f1b3b ("iwlwifi: changing EEPROM layout handling") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260916073736.2952028-1-lgs201920130244@gmail.com Signed-off-by: Johannes Berg commit ce67ebe9d8629776ce38e6995ae72fb903c828db Author: Aamir Ahmed Date: Sat Sep 12 14:47:55 2026 +0100 wifi: wfx: validate MIB read length before copying to caller wfx_hif_read_mib() copies reply->length bytes from the firmware response into the caller-provided buffer without checking that reply->length does not exceed val_len. A firmware response with a length field larger than expected overruns the caller buffer and reads past the end of the reply allocation. Replace the dead -ENOMEM check with an active validation that reply->length fits within val_len before the memcpy. Fixes: f95a29d40782 ("staging: wfx: add HIF commands helpers") Assisted-by: LLM Signed-off-by: Aamir Ahmed Link: https://patch.msgid.link/AS8P251MB000155034FC391A2A54B9803C8BD2@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Johannes Berg commit 7c1611780823b76219cb1478db53dfd890c4a9a2 Author: Tianchu Chen Date: Fri Sep 4 15:23:34 2026 +0000 wifi: cw1200: fix TX padding OOB read leaking heap data to device The TX path rounds the transfer size up to the bus alignment (align_size(), up to 511 bytes for SDIO, 1 byte for SPI) but sends the padded length straight from the frame buffer, which has no room reserved for the padding. cw1200_data_write() therefore reads past the end of the frame and the bus transfer carries those bytes to the device. A bogus device can collect up to 511 bytes of kernel heap data per TX frame. The RX path does not have this problem: it allocates the skb with the aligned length (alloc_len) before reading. Compute the exact padding with the bus align_size() callback, make sure queued TX frames have tailroom for it, and zero the padding bytes before the transfer so nothing past the frame is exposed. This is not expected to change driver behavior on most cases: frame contents and transfer sizes are unchanged, only the content of the padding bytes (previously undefined stale memory, now zero), which the device never reads since the WSM header carries the real frame length. The skb expansion can only fail under memory exhaustion, in which case the frame is dropped like on the existing error paths of cw1200_tx(). Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/7982b4a7e64f74e2068790ec389ca680a081f730@linux.dev Signed-off-by: Johannes Berg commit 3412e9a800786d1dec4a58367db1cba275e7ef11 Author: Zhiling Zou Date: Mon Aug 3 12:35:10 2026 +0800 wifi: mac80211: keep paired old chanctx alive An in-place replacement keeps reciprocal replace_ctx pointers between the old WILL_BE_REPLACED chanctx and the new REPLACES_OTHER chanctx. However, the early free paths only consider assigned and reserved link users when deciding whether to free the old chanctx. That lets the old chanctx be freed too early while the replacement partner still points back to it, either when the last assigned link is released or when that link successfully reassigns to another existing context. Later unreserve and switch-finalization paths can then follow a stale replace_ctx pointer. Keep a paired old chanctx alive until the replacement pair has been torn down. Apply the same check to both __ieee80211_link_release_channel() and ieee80211_link_use_reserved_reassign(). If the replacement is later abandoned, ieee80211_link_unreserve_chanctx() already tears down the pairing before freeing the old chanctx once no users remain. Fixes: 5bcae31d9cb1 ("mac80211: implement multi-vif in-place reservations") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Link: https://patch.msgid.link/b9b582b0db3814f641648b8886bb50f9d68f93ac.1785730815.git.zhilinz@nebusec.ai Signed-off-by: Johannes Berg commit 437f3727b4fd715266c296435c116288f82666fd Author: Zhiling Zou Date: Mon Aug 3 11:28:22 2026 +0800 wifi: mac80211: count only matching reservations in reserved switch ieee80211_vif_use_reserved_switch() validates a replacement by counting assigned links on ctx->replace_ctx and treating reservations too broadly. A link can still be assigned to the old channel context while holding a reservation that belongs to a different replacement operation. That can make the current replacement appear complete too early. If another link finalizes first, the function can free the WILL_BE_REPLACED chanctx while the unmatched link and driver still use it, leading to a use-after-free in later beacon generation. Require an in-place reservation to point at the current replacement context, and require the reserved and assigned contexts to be the matching replacement pair, before counting or moving the link. Fixes: 5bcae31d9cb1 ("mac80211: implement multi-vif in-place reservations") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Link: https://patch.msgid.link/4b6c4b8648ab1920c38a40be32c0b1a2797b4ac6.1785726007.git.zhilinz@nebusec.ai Signed-off-by: Johannes Berg commit 3195e0daf590683992edb4eed32269e569e04924 Author: Ben Cressey Date: Tue Sep 15 00:39:10 2026 +0000 dm-crypt: reject the lmk IV mode with AEAD ciphers 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 commit 764b683a6180fd72c931c13fea98d383506a3475 Author: Ben Cressey Date: Tue Sep 15 00:37:35 2026 +0000 dm-integrity: fix buffer overflow in inline mode with large tag size 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 commit 88a0474d92ba102fff860db3cae9da87a0964fbf Author: Niklas Cassel Date: Fri Sep 18 14:40:33 2026 +0200 ata: libata: Correct libata.force parameter documentation Align the documented libata.force options with their implementation. The force table accepts PIO modes 0 through 6, not mode 7, and ncqati controls NCQ generally rather than only queued TRIM. The max_sec_1024 and max_sec_lba48 options only set transfer size limits. Remove the misleading claim that they can also clear them. Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260918124030.1962773-6-cassel@kernel.org Signed-off-by: Niklas Cassel commit e6bae5034ef4a61f3f062b18140d4f58c8b9a149 Author: Niklas Cassel Date: Fri Sep 18 14:40:32 2026 +0200 ata: libata-core: Extend Samsung LPM quirk to AMD controllers A Samsung SSD 870 QVO 8TB connected to an AMD 600 Series chipset SATA controller is reported to time out on STANDBY IMMEDIATE during system suspend with med_power_with_dipm enabled. The command completes when using max_performance instead. The existing Samsung LPM quirk only matches ATI controllers, leaving AMD controllers unaffected. Rename it to ATA_QUIRK_NO_LPM_ON_ATI_AND_AMD and extend the vendor check to AMD for the same Samsung SSD model patterns. Keep LPM behavior unchanged for other controller vendors, including Intel. Leave ATA_QUIRK_NO_NCQ_ON_ATI restricted to ATI, since the reported AMD issue concerns LPM rather than NCQ. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221986 Reviewed-by: Damien Le Moal Reviewed-by: Mario Limonciello (AMD) > --- Link: https://lore.kernel.org/r/20260918124030.1962773-5-cassel@kernel.org Signed-off-by: Niklas Cassel commit 4ebdb8a6231bde47d21597d5d0a193dcf85164ac Author: Vlastimil Babka (SUSE) Date: Thu Sep 17 16:38:37 2026 +0200 MAINTAINERS: update slab.git URL The slab.git tree has been moved to a new URL as part of the mm-next integration. Reflect this in MAINTAINERS as well. The old URL will stay around with historical branches and tags. Signed-off-by: Vlastimil Babka (SUSE) Reviewed-by: David Hildenbrand (Arm) Acked-by: SJ Park Link: https://patch.msgid.link/20260917-maint-slab-git-v1-1-d21a5210aec9@kernel.org Signed-off-by: Harry Yoo (Meta) commit 072b2abae978b57291d1db31a7f75e8db5f9ff85 Merge: ec2ee09cb943a0 41e81f7e3ef965 Author: Paolo Bonzini Date: Mon Sep 21 06:10:28 2026 -0400 Merge tag 'kvm-riscv-fixes-7.3-1' of https://github.com/kvm-riscv/linux into HEAD KVM/riscv fixes for 7.3, take #1 - Synchronize hrtimer during VCPU teardown - Fix the conversion between vsip and hvip values - Serialize IMSIC attributes with vCPU migration - Release unused page after MMU invalidation - Propagate interrupted G-stage faults to KVM user-space - Fix NACL hfence entry update order - Fix sdata leak and stale snapshot_addr in snapshot_set_shmem - Preserve firmware counter value across PMU counter stop/start - Report PMU snapshot write failure to the guest - Fix perf-backed counter accounting across PMU stop and read - Fix HSM hart status error propagation commit ec2ee09cb943a075c9b947a59ff7db0e3af66e75 Merge: d599822bdb66ae 6b1bca1b1ab77f Author: Paolo Bonzini Date: Mon Sep 21 06:09:47 2026 -0400 Merge tag 'kvmarm-fixes-7.3-1' of https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 changes for 7.3, take #2 - Invalidate the ITS translation cache when the guest changes the base address of the ITS tables (Fuad Tabba) - Skip saving ITS devices with device IDs that are out-of-bounds rather than failing the entire ITS save ioctl (Fuad Tabba) - Close race between VM teardown and invalidations of nested MMUs when handling MMU operations that are allowed to block (Lorenzo Stoakes) - Various fixes for the handling of the host's untrusted SVE configuration in pKVM (Fuad Tabba) - Make sure that empty SMCCC ranges based at 0 are rejected by the kvm_smccc_set_filter() (Karl Mehltretter) - Revoke the host mapping for pKVM's private stack pages, along with a new sanity check that all mappings in the hyp's private VA range have been correctly marked as hyp-owned (Fuad Tabba) - Lifetime fixes for the array of shadow stage-2 MMUs, ensuring that concurrent vCPU initialization cannot relocate in-use MMUs. Defer the freeing of shadow stage-2 MMUs to the point that no other users (e.g. MMU notifier) could reference them (Marc Zyngier) - Drop useless WARN when rejecting an unsupported ioctl for pKVM (Fuad Tabba) - Fix the steal_time selftest to install correctly-sized mappings for non-4K hosts (Sebastian Ott) - Correct mapping of fine-grained trap for GCSPOPX instruction (Mark Brown) - Fix KVM_BUG_ON() due to missing handling of DBGBXVR from 32-bit guests (Karl Mehltretter) commit e31ae4aeb049983fe3be0cf1e12c8074811a7685 Author: HyeongJun An Date: Sun Sep 20 22:53:27 2026 +0900 ASoC: wm8903: Move the DRC QR threshold to the register that holds it The DRC_THRESH_QR field is bits 7 and 6 of DRC_1, but the control sits on DRC_0. Its shift and max are right for the field, only the register is wrong. Those bits of DRC_0 belong to DRC_STARTUP_GAIN, which "DRC Startup Volume" claims as bits 10 to 6. So the two controls share bits 7 and 6. Writing either one moves the other, and the quick release threshold is never reached at all. The six fields of DRC_1 tile it exactly, so there is nowhere else the threshold could live. Point the control at DRC_1. Found by a sweep for two controls claiming the same bits of one register. No board with this codec was to hand, the register map is the driver's own wm8903.h. Fixes: f1c0a02f32f8 ("ALSA: ASoC: Add WM8903 CODEC driver") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-5 Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260920135327.3628704-1-sammiee5311@gmail.com Signed-off-by: Mark Brown commit 687cb38c4330d52d58dbf426a3eb523850052d10 Author: Dirk Gouders Date: Mon Sep 14 13:01:09 2026 +0200 selftests: ublk: fix unused_result error Commit 166b476b8dee (selftests/ublk: add shared memory zero-copy support in kublk, 2026-03-31) introduced a write(2), ignoring its return value and thus causing an error, when building. Fix this by using the common workaround "(void)!" to trick the compiler the result is being used. Signed-off-by: Dirk Gouders Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260914110145.41627-2-dirk@gouders.net Signed-off-by: Jens Axboe commit 006208026819d5e9e5ec07b3e73d95960a059327 Author: Ralf Lici Date: Fri Aug 28 15:00:10 2026 +0200 selftests: ovpn: validate peer VPN addresses Exercise peer VPN address validation through both peer creation and update. Check missing, unspecified, duplicate, multicast, broadcast, loopback, IPv4-compatible and IPv4-mapped addresses. Temporarily configure a peer with both address families to verify that either family can be cleared while the other remains configured, then restore the original addresses before running the existing traffic tests. Extend ovpn-cli peer updates with an optional VPN address and preserve peer creation errors so the negative tests can observe rejected netlink requests. Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli commit 5940f3407b78062442cb01f541ef6eed709fc380 Author: Ralf Lici Date: Fri Aug 28 15:00:09 2026 +0200 ovpn: reject invalid peer VPN addresses In MP mode, ovpn uses peer VPN addresses as lookup keys for selecting the peer that should receive outgoing tunnel packets. The netlink configuration path currently accepts address values that cannot sensibly identify a VPN peer, such as multicast, broadcast or loopback addresses. Reject invalid peer VPN addresses when creating or updating an MP peer. Keep accepting the unspecified address as the internal unset value, provided that at least one VPN address family remains configured. Fixes: 1d36a36f6d53 ("ovpn: implement peer add/get/dump/delete via netlink") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli commit 025af3a0a892514f9f27f186338ba3d44365547a Author: Ralf Lici Date: Fri Aug 28 15:00:08 2026 +0200 ovpn: reject multipeer peers without VPN addresses In MP mode, ovpn uses the peer VPN addresses to select the peer for outgoing tunnel packets. Peer creation currently requires a VPN IPv4 or IPv6 attribute, but it only checks for the presence of the attribute and not for a usable address value. This allows userspace to create an MP peer with only unspecified VPN addresses, or to update an existing peer so that both VPN address families become unspecified. Such a peer cannot be selected through the VPN address hash tables. Reject MP peer creation or update when the resulting peer would not have at least one VPN address configured. This changes such configurations from being accepted to being rejected, but they have never been usable because the peer cannot be selected through the VPN address hash tables. Fixes: 1d36a36f6d53 ("ovpn: implement peer add/get/dump/delete via netlink") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli commit d25e885b31a0f2808d936f95c9a558a8a792669b Author: Ralf Lici Date: Fri Aug 28 15:00:07 2026 +0200 ovpn: reject duplicate peer VPN addresses In MP mode, ovpn uses the peer VPN addresses as lookup keys for selecting the peer that should receive an outgoing tunnel packet. However, the netlink peer configuration path does not currently reject duplicate VPN addresses. If two peers are configured with the same VPN address, both can be inserted in the VPN address hash table and lookups return whichever peer is found first. This makes peer selection ambiguous and dependent on hash insertion order. Reject peer creation or update when the resulting VPN address is already assigned to another peer. Ignore unspecified addresses because those are not inserted in the VPN address hash tables. This changes such configurations from being accepted to being rejected, but they have never worked reliably because peer selection is ambiguous. Fixes: 1d36a36f6d53 ("ovpn: implement peer add/get/dump/delete via netlink") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli commit b43beccb3713fafada57814b0a652f4a876eb75f Author: Ralf Lici Date: Fri Aug 28 15:00:06 2026 +0200 ovpn: always unhash old VPN addresses before rehashing ovpn_peer_hash_vpn_ip updates the per-peer VPN address hash entries after userspace changes a peer VPN address. The current code removes an old hash entry only when the new address for that family is not the unspecified address. When an address is cleared to 0.0.0.0 or ::, its hash node therefore remains linked in the bucket selected by the old address. The address comparison performed during lookup prevents the old address from matching, but the table retains a stale entry until the peer is removed or another address is configured for that family. Always remove both old VPN address hash entries before conditionally adding the currently configured addresses back. This ensures that a cleared address leaves its hash node unhashed. Fixes: 1d36a36f6d53 ("ovpn: implement peer add/get/dump/delete via netlink") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli commit 7d8104988f423572df1f3347ce578037b1043f34 Author: Ralf Lici Date: Fri Aug 28 16:50:27 2026 +0200 ovpn: replace bind when clearing stale local source The UDP output fallback clears bind->local in place when the remembered source address is no longer usable. The bind is RCU-published and read locklessly by concurrent TX, so an IPv6 reader can observe a torn address. Retry the route lookup with source address autoselection without modifying the bind. After a successful lookup, revalidate the bind and route key under peer->lock, reset the dst cache, and best-effort publish a replacement bind with a wildcard local address. Do not cache the resolved dst when clearing the local source. Replacing the source invalidates all per-CPU cache entries, while dst_cache_set_ip4 and dst_cache_set_ip6 update only the current CPU slot. The current packet can still use the resolved route; if bind allocation fails, a later cache miss retries the repair. Fixes: 08857b5ec5d9 ("ovpn: implement basic TX path (UDP)") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli commit aea934a221ec6a867221e5b765f65f1857befd53 Author: Ralf Lici Date: Fri Aug 28 16:50:26 2026 +0200 ovpn: replace bind when learning local endpoint struct ovpn_bind is published through peer->bind with RCU, but local endpoint learning updates bind->local in place under peer->lock. UDP TX reads the field without that lock. In particular, a concurrent IPv6 update can therefore result in a torn address read. Use ovpn_peer_reset_sockaddr to publish a replacement bind when learning a new local endpoint, just as a remote endpoint change does. Preserve the current remote address and reset the dst cache only after the new bind has been published successfully. Track remote endpoint changes separately so that float notification and transport-address rehashing remain limited to actual peer floats. Fixes: f0281c1d3732 ("ovpn: add support for updating local or remote UDP endpoint") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli commit fa603710bdb9aea33c0d9cc2c05ed24d84f58753 Author: Ralf Lici Date: Fri Aug 28 16:50:25 2026 +0200 ovpn: validate peer state before caching UDP dst UDP route lookup runs without peer->lock while the bind is protected by RCU. The route key is snapshotted separately. Either can change while the lookup is in progress. The TX path currently checks only the route key before publishing the looked-up dst. If the bind changes but the route key does not, a dst resolved from the old endpoint can be installed in the cache after the bind replacement. Compare both the bind pointer and the route key under peer->lock before updating the cache. The RCU read-side critical section keeps the old bind alive throughout the lookup, so pointer identity is sufficient to detect a replacement. Fixes: f0281c1d3732 ("ovpn: add support for updating local or remote UDP endpoint") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli commit 7c66b7a4ae80a9309e6dc1d24b7b6b897e6348eb Author: Ralf Lici Date: Fri Aug 28 16:50:24 2026 +0200 ovpn: track UDP socket route key for peer dst cache ovpn stores the route used to transmit UDP packets in a per-peer dst cache. A cached dst is only valid for the route lookup inputs used when it was resolved. Some of those inputs are mutable while userspace still owns the UDP socket. In particular, changes to the socket mark or UDP source port do not invalidate ovpn's peer dst cache, so ovpn can keep using a route selected with an old socket route key. Replace the cached mark with a route key containing the socket-owned lookup inputs currently used by ovpn, and reset the peer dst cache when the key changes. Before storing a newly looked-up dst, recheck the route key under the peer lock so a dst resolved for stale socket state is not published. Fixes: 08857b5ec5d9 ("ovpn: implement basic TX path (UDP)") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli commit 77393b4d72dfeb764b2af2b848acc659f6fcfd0a Author: Ralf Lici Date: Fri Aug 28 16:50:23 2026 +0200 ovpn: skip UDP source validation for unspecified addresses ovpn validates the cached local UDP source address before reusing or refreshing a peer dst cache. This is only meaningful when a concrete source address is selected. For IPv6, calling ipv6_chk_addr with :: checks whether the unspecified address itself is configured on the host. A peer may legitimately have bind->local.ipv6 set to :: when no local endpoint was configured or after a stale learned address was cleared. In that case the source should be left unspecified and selected by ip6_dst_lookup_flow(). For IPv4, inet_confirm_addr(..., local = 0, ...) asks for local address autoselection rather than validating a chosen source. Skip the precheck there as well and let ip_route_output_flow select or reject the source. Only validate non-zero/non-any source addresses. Fixes: 08857b5ec5d9 ("ovpn: implement basic TX path (UDP)") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli commit 7a6d08ee0f0e30023d18779bb314db8fd9a3b6d4 Author: Ralf Lici Date: Fri Aug 28 16:50:22 2026 +0200 ovpn: preserve IPv6 scope id for netlink peer endpoints ovpn accepts OVPN_A_PEER_REMOTE_IPV6_SCOPE_ID and reports bind->remote.in6.sin6_scope_id in peer dumps, but the netlink endpoint parser never copied the attribute into the sockaddr_in6 used to create or update the peer bind. As a result, an IPv6 link-local remote endpoint configured through netlink loses its interface scope, unlike on the peer float path where ipv6_iface_scope_id populates the field. The UDPv6 output path then builds a flow with flowi6_oif set to zero and route lookup can fail or select the wrong interface. Copy the scope id when parsing non-v4-mapped IPv6 remote endpoints. The existing precheck already rejects the scope-id attribute for IPv4 and v4-mapped IPv6 remotes. Fixes: 1d36a36f6d53 ("ovpn: implement peer add/get/dump/delete via netlink") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli commit d395e1b62d9694f2e4add9122f8d473eacd374aa Author: Daniel Ortiz Date: Sat Sep 19 20:19:20 2026 -0500 ASoC: amd: yc: Add DMI quirk for Lenovo V15 G6 ARP The Lenovo V15 G6 ARP (product name 83UU) uses the ACP6x PDM interface for its internal digital microphone array. Its firmware exposes neither the AcpDmicConnected _DSD property nor the _WOV method, so acp6x_probe() falls through to the DMI check and returns -ENODEV, leaving acp_yc_mach.0 unbound and no capture device registered. Add a DMI quirk entry for this model. With it, the machine driver binds and the DMIC capture device is created: acp_yc_mach acp_yc_mach.0: Enabling ACP DMIC support via DMI card 2: acp6x [acp6x], device 0: DMIC capture dmic-hifi-0 Capture was verified working with arecord and PipeWire. Signed-off-by: Daniel Ortiz Link: https://patch.msgid.link/20260920011920.2482786-1-letargopausado@gmail.com Signed-off-by: Mark Brown commit ada667890773e033d2f40dc94176e3beb930b516 Author: Li Youhong Date: Fri Sep 4 09:49:58 2026 +0800 drm/bridge: samsung-dsim: fix TE GPIO lifetime for host attach When the Exynos DSI driver was generalized into samsung-dsim, the TE GPIO acquisition was switched from gpiod_get_optional() to devm_gpiod_get_optional() while keeping the matching gpiod_put() calls. That combination is wrong for a managed descriptor. However, dropping the puts and keeping the managed get is also wrong: samsung_dsim_register_te_irq() runs from the DSI host attach callback, and host detach/reattach can happen without destroying the device that owns the managed action. A second attach would then request the GPIO again without having released it. Switch back to a non-managed gpiod_get_optional() and keep the explicit gpiod_put() on the request_irq() error path and in samsung_dsim_unregister_te_irq(). Fixes: e7447128ca4a ("drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge") Suggested-by: Luca Ceresoli Signed-off-by: Li Youhong Reviewed-by: Luca Ceresoli Tested-by: Luca Ceresoli Link: https://patch.msgid.link/20260904014958.1572918-1-dayou5941@163.com [Luca: remove unnecessary comment] Signed-off-by: Luca Ceresoli commit 0b9828c7231e2e46b25d286da555510a79c0d6fa Merge: d54a489c8c4b62 93f51579e7df24 Author: Bartosz Golaszewski Date: Mon Sep 21 10:36:20 2026 +0200 Merge tag 'v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-current Linux 7.3-rc4 commit 495cd7f858b45d2ffa9b685bba3a8c23c1ca4dd3 Author: Lovekesh Solanki Date: Sun Sep 20 17:05:41 2026 +0530 Input: i8042 - add nomux quirk for Fujitsu LIFEBOOK U7410 On the Fujitsu LIFEBOOK U7410 the internal keyboard and touchpad die shortly after boot if i8042 multiplexing controller is probed and switched to muxed mode. These multiplexing setup commands disturb the EC emulated keyboard and atkbd reports "Spurious ACK" and "Unknown key pressed" warnings, after which both keyboard and touchpad stop delivering events. Both touchpad and keyboard work in BIOS and GRUB. Disabling multiplexer using i8042.nomux=1 makes both devices work on warm/cold boot. Add a DMI quirk to force nomux mode for this model. Reported-by: Heiko Brey Link: https://lore.kernel.org/all/89f36f3f5e4c2d07b9ff72bc0b355875c336e498.camel@gmx.de/ Signed-off-by: Lovekesh Solanki Link: https://patch.msgid.link/20260920113541.1484808-1-lovekeshsolanki00@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov commit a961417c5ae77bbb728a23d9577ecd8f4d8a4b5a Author: Lovekesh Solanki Date: Mon Sep 21 01:37:30 2026 +0530 Input: synaptics - add LEN205b entry to smbus_pnp_ids for ThinkPad T490 Lenovo ThinkPad T490 has a Synaptics Touchpad that supports SMBus/RMI4 mode, but is not listed in smbus_pnp_ids table. Add LEN205b to smbus_pnp_ids[] passlist. Reported-by: John Rosencutter Closes: https://lore.kernel.org/all/CAOGuaRh025eKcBf9P8UrvtXNp68vQ0HVF2EbNMp-kpdaC1HNpA@mail.gmail.com/ Signed-off-by: Lovekesh Solanki Link: https://patch.msgid.link/20260920200730.1836756-1-lovekeshsolanki00@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov commit 64c82e7bd9c82b0c9276297df34a3579e8658f55 Author: Slavin Liu Date: Sun Sep 13 20:51:07 2026 +0800 iio: adc: pac1934: check ACPI label duplication A label duplication failure currently reaches the terminating-byte write. Release the ACPI result and abort before accessing the missing label; earlier labels are managed by devres. Detected by static analysis and reviewed with AI-assisted source auditing. Fixes: 0fb528c8255b ("iio: adc: adding support for PAC193x") Assisted-by: LLM Signed-off-by: Slavin Liu Cc: Signed-off-by: Jonathan Cameron commit ae2c5bf969573708cd5b6bb6393631255d83c3fe Author: Prathamesh Shete Date: Wed Sep 16 06:51:32 2026 +0000 pinctrl: tegra238: Fix register bank for AON pin groups The AON pin controller has a single register region and therefore, the bank defined in the tegra238_functions[] and tegra238_aon_groups[] for the AON pin groups must be 0. However, commit 25cac7292d49 ("pinctrl: tegra: Add Tegra238 pinmux driver") incorrectly specified the bank for these pins as 1 and not 0. This means that in the tegra_pinctrl_probe() function we use an invalid index when accessing the pmx->regs[] array which causes an incorrect address to be used for accessing the pinmux registers. Fix this by correcting the bank for the AON pin groups. Fixes: 25cac7292d49 ("pinctrl: tegra: Add Tegra238 pinmux driver") Signed-off-by: Prathamesh Shete Signed-off-by: Linus Walleij commit 93f51579e7df248780214094418f205253383cc5 Author: Linus Torvalds Date: Sun Sep 20 13:48:15 2026 -0700 Linux 7.3-rc4 commit 6a5719cc3ef2e4d9857cc4ae18e6db09d59a8cc9 Author: Daniel J Blueman Date: Sun Sep 20 16:16:08 2026 +0200 net: qrtr: resend HELLO on MHI resume Since the MHI HELLO exchange was relocated, it is sent only at device registration. During a suspend-resume cycle, the firmware in WiFi cards such as WCN7850 indefinitely waits for another HELLO, triggering: ath12k_wifi7_pci 0004:01:00.0: timeout while waiting for restart complete ath12k_wifi7_pci 0004:01:00.0: failed to resume core: -110 Fix this by triggering the handshake from resume_early in the MHI transport. Validated on Qualcomm X1E-801800 on Lenovo Slim 7x across 10 suspend-resume cycles. Fixes: 544d85de4dc2 ("net: qrtr: Send HELLO message on endpoint register") Signed-off-by: Daniel J Blueman Reviewed-by: Manivannan Sadhasivam Reported-by: Jeff Johnson Link: https://lore.kernel.org/all/6257c447-788d-4362-851e-0d552bcf7c56@oss.qualcomm.com/ Tested-by: Jeff Johnson Reported-by: Vlastimil Babka (SUSE) Link: https://lore.kernel.org/all/ab1491bb-cca5-4145-ac7d-31c966abf7b4@suse.com/ Tested-by: Vlastimil Babka (SUSE) Reported-by: Takashi Iwai Link: https://lore.kernel.org/all/87a4plsg4w.wl-tiwai@suse.de/ Tested-by: Takashi Iwai Signed-off-by: Thorsten Leemhuis Signed-off-by: Linus Torvalds commit 598c1c3e895590f845e04455d5580ea28ffde666 Author: Benjamin Leggett Date: Fri Aug 14 18:20:11 2026 -0400 drm/virtio: sync shmem backing on guest-bound transfers virtio_gpu_cmd_transfer_to_host_{2d,3d}() sync the shmem backing for the device before the transfer, but nothing syncs for the CPU when a transfer runs the other way. That breaks two ways. Where the DMA layer bounces, the device writes into the bounce buffer while the guest keeps reading the original pages. Where DMA is not coherent, the device writes memory while the CPU keeps stale cache lines, because nothing reaches arch_sync_dma_for_cpu(). Either way DRM_IOCTL_VIRTGPU_TRANSFER_FROM_HOST hands back stale data. Sashiko originally found this in https://lore.kernel.org/dri-devel/20260806231002.27B4D1F000E9@smtp.kernel.org but the suggestion there to fix this with dma_sync_sgtable_for_cpu() isn't a sufficient fix, for two reasons. - The transfer is asynchronous. virtio_gpu_cmd_transfer_from_host_3d() only queues the command, so a sync there would run before the device had written anything. It belongs on completion, and ahead of any fence signalling. A waiter woken by the fence would otherwise race the sync and read the backing pages regardless. It needs its own pass over the reclaim list rather than a step inside the existing one, because virtio_gpu_fence_event_process() also signals every earlier fence in the same context, so any entry in that loop may signal an earlier entry's fence. - The transfer is also partial, carrying an offset, a level and a box. Where the mapping bounces, a sync for the CPU copies the whole mapping back, so unless the mapping is primed first the regions the device did not write come back holding whatever the bounce buffer contained, discarding data the guest owned. So the fix: Prime the mapping before queueing, tag the vbuffer, and sync for the CPU on completion before the fence is signalled. A second transfer must not snapshot the mapping while an earlier one is still in flight, or the snapshot would predate whatever the CPU wrote once the earlier fence signalled and the later sync would discard it. To mitigate this, wait for outstanding fences under the reservation before priming. Neither sync copies anything unless the mapping genuinely bounces: swiotlb_sync_single_for_cpu() and its Xen counterpart look the address up in the bounce pool and return early when it is absent. On a platform with non-coherent DMA they still perform the necessary cache maintenance. The range cannot be narrowed to the box, since for a non-blob resource virtio_gpu_transfer_from_host_ioctl() rejects a caller-supplied stride and layer_stride, leaving the layout to the host and the guest with no way to work out which bytes the device writes. A host3d guest blob does carry both, so its extent could be bounded, but the sync is left whole there too rather than special-cased: priming makes the untouched regions round-trip unchanged either way. Behaviour changes worth noting: - TRANSFER_FROM_HOST can now block, where before it returned as soon as the command was queued. Repeated readbacks of one resource serialise, and a readback can wait behind an earlier queued command that touched it, since virtio_gpu_array_add_fence() tags uploads, execbufs and plane flushes alike with DMA_RESV_USAGE_WRITE. -ERESTARTSYS was already possible here via dma_resv_lock_interruptible(). - A CPU write racing an in-flight transfer to the same resource is now lost, where before it survived and the transfer was lost instead. Priming captures the pages as of queueing, so a write landing before completion is overwritten by the sync. - TRANSFER_TO_HOST can also block now, but only while a guest-bound transfer on the same resource is outstanding, which happens only for callers that issue both without waiting. - Where a batch of completions contains a guest-bound transfer, the sync pass delays fence signalling for the whole batch. Only bounced pages are copied and the swiotlb pool bounds it. A batch with no such transfer is unaffected. Tested under QEMU on x86 with swiotlb=force and virtio-vga-gl iommu_platform=on, which forces both preconditions required to hit the original bug. Fixes: a3b815f09bb8 ("drm/virtio: add iommu support.") Reported-by: Sashiko AI review Closes: https://lore.kernel.org/dri-devel/20260806231002.27B4D1F000E9@smtp.kernel.org/ Signed-off-by: Benjamin Leggett Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260814-virtgpu-from-host-sync-v4-1-64dd736b1779@edera.io commit 6947b78df4d25bd1e86b26870b614ea54c625b1e Author: Shixiong Ou Date: Fri Aug 28 17:01:23 2026 +0800 drm/virtio: Add pixel blend mode property to cursor plane The cursor plane exposes a format with an alpha channel (DRM_FORMAT_ARGB8888) without a pixel blend mode property. Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") this triggers a warning during drm_mode_config_validate(): [ 0.649020] ------------[ cut here ]------------ [ 0.649040] [PLANE:36:plane-1] pixel format with alpha exposed but blend mode not setup [ 0.649081] WARNING: drivers/gpu/drm/drm_mode_config.c:872 at drm_mode_config_validate ...... [ 0.649761] Call trace: [ 0.649764] drm_mode_config_validate+0x398/0x558 [drm] (P) [ 0.649912] drm_dev_register+0x1cc/0x2a0 [drm] [ 0.650058] virtio_gpu_probe+0xd4/0x1c0 [virtio_gpu] [ 0.650088] virtio_dev_probe+0x1c8/0x310 ...... [ 0.650261] ---[ end trace 0000000000000000 ]--- Create the property with the only supported blend mode, DRM_MODE_BLEND_PREMULTI, which is also the property's default and matches what userspace had to assume before the property existed. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Reported-by: Ye Liu Signed-off-by: Shixiong Ou Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260828090123.784944-1-oushixiong1025@163.com commit 846b3c64fe3e77d9db20a7e3e62dbbb637c773e1 Author: Peiyang He Date: Wed Sep 9 17:11:14 2026 +0800 drm/virtio: fix NULL pointer dereference on fence allocation failure virtio_gpu_fence_alloc() can fail due to memory pressure and return NULL, but its caller like virtio_gpu_init_submit() never checks it. Later, virtio_gpu_init_submit() passes the NULL fence to virtio_gpu_fence_event_create(), which unconditionally dereferences it. Found when fuzzing the virtio driver with Syzkaller: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 1 UID: 0 PID: 9991 Comm: syz.0.121 Not tainted 7.2.0 #4 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 RIP: 0010:virtio_gpu_fence_event_create drivers/gpu/drm/virtio/virtgpu_submit.c:295 [inline] RIP: 0010:virtio_gpu_init_submit drivers/gpu/drm/virtio/virtgpu_submit.c:398 [inline] RIP: 0010:virtio_gpu_execbuffer_ioctl+0xc78/0x1aa0 drivers/gpu/drm/virtio/virtgpu_submit.c:505 Code: 85 ed 0f 85 21 09 00 00 e8 05 5a c9 fb 48 8b 44 24 10 48 8d b8 90 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9a 0d 00 00 48 8b 44 24 10 4c 89 b0 90 00 00 00 RSP: 0018:ffffc900039dfad0 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: ffffc900039dfdd8 RCX: ffffffff85f6fd3d RDX: 0000000000000012 RSI: ffffffff85f6fd4b RDI: 0000000000000090 RBP: 0000000000000000 R0virtio_gpu_virgl_process_cmd: ctrl 0x102, error 0x1203 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880132c4000 R13: 0000000000000000 R14: ffff888073b6c700 R15: 000000000000003b FS: 00007fab480b96c0(0000) GS:ffff8880eb6e9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007effbf5e55a8 CR3: 0000000048d19000 CR4: 0000000000350ef0 Call Trace: drm_ioctl_kernel+0x1f4/0x3e0 drivers/gpu/drm/drm_ioctl.c:817 drm_ioctl+0x5f4/0xc70 drivers/gpu/drm/drm_ioctl.c:914 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fab471a82bd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fab480b9018 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fab47435fa0 RCX: 00007fab471a82bd RDX: 00002000000000c0 RSI: 00000000c0406442 RDI: 0000000000000003 RBP: 00007fab480b9080 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fab47436038 R14: 00007fab47435fa0 R15: 00007ffe85ab0740 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:virtio_gpu_fence_event_create drivers/gpu/drm/virtio/virtgpu_submit.c:295 [inline] RIP: 0010:virtio_gpu_init_submit drivers/gpu/drm/virtio/virtgpu_submit.c:398 [inline] RIP: 0010:virtio_gpu_execbuffer_ioctl+0xc78/0x1aa0 drivers/gpu/drm/virtio/virtgpu_submit.c:505 Code: 85 ed 0f 85 21 09 00 00 e8 05 5a c9 fb 48 8b 44 24 10 48 8d b8 90 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9a 0d 00 00 48 8b 44 24 10 4c 89 b0 90 00 00 00 RSP: 0018:ffffc900039dfad0 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: ffffc900039dfdd8 RCX: ffffffff85f6fd3d RDX: 0000000000000012 RSI: ffffffff85f6fd4b RDI: 0000000000000090 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880132c4000 R13: 0000000000000000 R14: ffff888073b6c700 R15: 000000000000003b FS: 00007fab480b96c0(0000) GS:ffff888098ae9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f24c3759000 CR3: 0000000048d19000 CR4: 0000000000350ef0 ---------------- Code disassembly (best guess): 0: 85 ed test %ebp,%ebp 2: 0f 85 21 09 00 00 jne 0x929 8: e8 05 5a c9 fb call 0xfbc95a12 d: 48 8b 44 24 10 mov 0x10(%rsp),%rax 12: 48 8d b8 90 00 00 00 lea 0x90(%rax),%rdi 19: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax 20: fc ff df 23: 48 89 fa mov %rdi,%rdx 26: 48 c1 ea 03 shr $0x3,%rdx * 2a: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction 2e: 0f 85 9a 0d 00 00 jne 0xdce 34: 48 8b 44 24 10 mov 0x10(%rsp),%rax 39: 4c 89 b0 90 00 00 00 mov %r14,0x90(%rax) Fix by checking virtio_gpu_fence_alloc() in virtio_gpu_init_submit() and returning -ENOMEM before any later code can dereference the NULL fence. Fixes: 70d1ace56db6 ("drm/virtio: Conditionally allocate virtio_gpu_fence") Cc: stable@vger.kernel.org Signed-off-by: Peiyang He Assisted-by: Codex:gpt-5.5 Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/00EFE4BA92889B14+20260909091114.2622550-1-peiyang_he@smail.nju.edu.cn commit 1e3b08de63274d0b009e99ef51cd6a9c0c6bf08c Author: Dmitry Osipenko Date: Fri Sep 11 17:42:03 2026 +0300 Revert "drm/virtio: Allow importing prime buffers when 3D is enabled" Guest userspace may import udmabuf to vrend. Vrend doesn't support guest blobs, and thus, further 3d operations with the imported blob are failing. Typical scenario of the problem shown with mouse cursor RGBA image imported into virtio-gpu, which previously was rejected by virtio-gpu driver. Revert enabling guest blobs importing into vrend to fix the regression. Link: https://gitlab.freedesktop.org/virgl/virglrenderer/-/work_items/674 Fixes: df4dc947c46b ("drm/virtio: Allow importing prime buffers when 3D is enabled") Signed-off-by: Dmitry Osipenko Reviewed-by: Val Packett Link: https://patch.msgid.link/20260911144204.2089401-1-dmitry.osipenko@collabora.com commit 036d28db1818af2f9d80db771f5405da84d7732d Author: Junrui Luo Date: Tue Sep 15 15:39:13 2026 +0800 drm/virtio: release the GEM object on virtio_gpu_vram_create() errors virtio_gpu_vram_create() frees the object with a bare kfree(vram) on both error paths after drm_gem_private_object_init() has run, and on the second one after drm_gem_create_mmap_offset() has linked obj->vma_node into the device's VMA offset manager. The freed object stays in that interval tree, so a later lookup or insertion walks freed memory, and the dma_resv and gpuva lock are never destroyed. Call drm_gem_object_release() before kfree() on both paths. Fixes: 16845c5d5409 ("drm/virtio: implement blob resources: implement vram object") Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260915-fixes-v2-4-a0d799e4db66@outlook.com commit 24b6d5c7641412c9ebef0d4c8b888d49a0e6b880 Author: Junrui Luo Date: Tue Sep 15 15:39:12 2026 +0800 drm/virtio: fix object leaks in virtio_gpu_resource_create_blob_ioctl() virtio_gpu_resource_create_blob_ioctl() calls drm_gem_object_release() on both the virtio_gpu_resource_assign_uuid() and drm_gem_handle_create() error paths instead of dropping the reference it owns, so obj->funcs->free() never runs and the virtio_gpu_object, the resource id and the host-side resource are leaked. Use drm_gem_object_put() instead. Fixes: 897b4d1acaf5 ("drm/virtio: implement blob resources: resource create blob ioctl") Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260915-fixes-v2-3-a0d799e4db66@outlook.com commit 477bc3068fc3777b9d8ffd79e265b0dfdf2d3a6b Author: Junrui Luo Date: Tue Sep 15 15:39:11 2026 +0800 drm/virtio: fix object leak in virtio_gpu_resource_create_ioctl() virtio_gpu_resource_create_ioctl() calls drm_gem_object_release() on the drm_gem_handle_create() error path instead of dropping the reference it owns, so obj->funcs->free() never runs and the virtio_gpu_object, its pages and sg table, the resource id and the host-side resource are leaked. Use drm_gem_object_put() instead. Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support") Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260915-fixes-v2-2-a0d799e4db66@outlook.com commit 36570ef2244cc4d7563b1f0157bc0f032498638c Author: Junrui Luo Date: Tue Sep 15 15:39:10 2026 +0800 drm/virtio: fix object leak when drm_gem_handle_create() fails virtio_gpu_gem_create() owns the reference taken by virtio_gpu_object_create(). On the drm_gem_handle_create() error path it calls drm_gem_object_release() instead of dropping that reference. drm_gem_object_release() is the inverse of drm_gem_object_init() and does not touch the reference count or call obj->funcs->free(), so it is only correct as the last step of a destructor, as in virtio_gpu_cleanup_object(). Using it here leaves the bo at refcount 1 with no remaining reference, so virtio_gpu_free_object() never runs and the shmem pages, sg table and virtio_gpu_object are leaked. Since virtio_gpu_object_create() has already set bo->created, VIRTIO_GPU_CMD_RESOURCE_UNREF is not queued either, leaking the host-side resource and the resource id. drm_gem_handle_create_tail() drops the handle reference on all of its internal error paths, so the caller only has to drop its own. Use drm_gem_object_put(), matching the success path below. Fixes: dc5698e80cf7 ("Add virtio gpu driver.") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260915-fixes-v2-1-a0d799e4db66@outlook.com commit b74aad23d99b279bb34d135795f39a6d8ecdc075 Author: Peiyang He Date: Tue Sep 8 20:13:23 2026 +0800 drm/virtio: fix memory leak of fence event on execbuffer failure virtio_gpu_execbuffer_ioctl() reserves a DRM event with drm_event_reserve_init() when VIRTGPU_EXECBUF_RING_IDX selects a ring that userspace has enabled polling for. virtio_gpu_init_submit() does this before the BO handles, the command buffer, the syncobj arrays and the in-fence are processed, so every later error path runs with the event already pending, including plain argument validation failures such as an invalid bo_handle or an in-syncobj that carries no fence. On those paths, virtio_gpu_cleanup_submit() drops the out-fence without cancelling the event. The fence is freed without ever having been emitted, taking the only driver-side pointer to the event with it. Closing the DRM file does not help. drm_events_release() unlinks pending events but deliberately leaves the freeing to the driver's later drm_send_event(), which never runs for an orphaned event, so the allocation is leaked permanently. Found when fuzzing the virtio driver with Syzkaller: BUG: memory leak unreferenced object 0xffff88802c176e80 (size 96): comm "syz.1.367", pid 10561, jiffies 4294960122 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ c8 6e 17 2c 80 88 ff ff 00 00 00 00 00 00 00 00 .n.,............ backtrace (crc e1973c6b): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4597 [inline] slab_alloc_node mm/slub.c:4917 [inline] __kmalloc_cache_noprof+0x49d/0x6f0 mm/slub.c:5485 _kmalloc_noprof include/linux/slab.h:988 [inline] _kzalloc_noprof include/linux/slab.h:1309 [inline] virtio_gpu_fence_event_create drivers/gpu/drm/virtio/virtgpu_submit.c:282 [inline] virtio_gpu_init_submit drivers/gpu/drm/virtio/virtgpu_submit.c:398 [inline] virtio_gpu_execbuffer_ioctl+0xbbf/0x1aa0 drivers/gpu/drm/virtio/virtgpu_submit.c:505 drm_ioctl_kernel+0x1f4/0x3e0 drivers/gpu/drm/drm_ioctl.c:817 drm_ioctl+0x5f4/0xc70 drivers/gpu/drm/drm_ioctl.c:914 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix by cancelling and freeing the DRM event on the execbuffer error path before dropping the fence. Clear the fence's event pointer after cancellation so it does not retain a dangling pointer. Fixes: cd7f5ca33585 ("drm/virtio: implement context init: add virtio_gpu_fence_event") Cc: stable@vger.kernel.org Signed-off-by: Peiyang He Assisted-by: Codex:gpt-5.6-luna Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/D320EAB5680C1411+20260908121323.2405044-1-peiyang_he@smail.nju.edu.cn commit a10a019dd4c7c57bef6b8dda962c8881ad220af2 Merge: 60ee24f055f87c 075bc7b1d3dde5 Author: Linus Torvalds Date: Sun Sep 20 10:45:22 2026 -0700 Merge tag 'dmaengine-fix-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine Pull dmaengine fixes from Vinod Koul: - A couple of fixes in core around dma_chan_put() for kref underflow, use-after-free and waiting for rcu readers for dma devices - mmp sg length and wrong extended DRCMR base for SpacemiT K3 - hardware buffer descriptor chain fix for xilinx dma - sun6i fixes for status behaviour and dma position registers - runtime pm reference leak fix for sprd driver * tag 'dmaengine-fix-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: dmaengine: mmp_pdma: fix wrong sg length in mmp_pdma_prep_slave_sg() dmaengine: xilinx_dma: Fix hardware buffer descriptor chain after cyclic DMA dmaengine: pxa: fix double counting of the hw descriptors dmaengine: sun6i: fix undefined behaviour in sun6i_dma_tx_status dmaengine: sun6i: fix non-atomic read of DMA position registers dmaengine: xilinx_dma: Fix hardware buffer descriptor reuse order dmaengine: wait for RCU readers before releasing dma_device dmaengine: fix use-after-free in dma_chan_put() and dma_release_channel() dmaengine: Fix device kref underflow in dma_chan_put() dmaengine: add dma_device_get() helper dmaengine: sprd: Fix runtime PM reference leak in probe dmaengine: ti: k3-udma-glue: fix NULL dereference in k3_udma_glue_release_rx_chn() dmaengine: mmp_pdma: fix wrong extended DRCMR base for SpacemiT K3 commit 60ee24f055f87c74d3fccdedcb761df9253fd5c0 Merge: 0a885f68d0e90d 486a70ef848264 Author: Linus Torvalds Date: Sun Sep 20 10:43:12 2026 -0700 Merge tag 'phy-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy Pull phy fixes from Vinod Koul: - avoid atomic context delay in renesas driver - TMDS and PLL rate calculation fixes for mediatek driver * tag 'phy-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: phy: mediatek: phy-mtk-hdmi-mt8195: Fix TMDS clk bit ratio setting phy: mediatek: phy-mtk-hdmi-mt8195: Fix PLL calc divisor overflow phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic context commit 0a885f68d0e90dcef77e575b09104df7263e2aca Merge: 156fa7417fac89 aba7b41faeecb7 Author: Linus Torvalds Date: Sun Sep 20 10:22:37 2026 -0700 Merge tag 'soundwire-7.3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire Pull soundwire fixes from Vinod Koul: - Cadence: ensure work completion before clock stop - Disable ghost Realtek on Asus GX651AX * tag 'soundwire-7.3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: soundwire: cadence_master: wait and cancel cdns->work before clock stop soundwire: dmi-quirks: Disable ghost Realtek on Asus GX651AX commit 156fa7417fac89fd9dcf3a4ee88785ff90ab6411 Merge: 0a15ba6b0c3ade 63edf5a009ae36 Author: Linus Torvalds Date: Sun Sep 20 09:49:10 2026 -0700 Merge tag 'x86-urgent-2026-09-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: - Reject the loading of a potentially problematic microcode version on Intel Granite Rapids systems (Chang S. Bae) - On FRED, reconstruct the proper #GP context for rejected INT instructions, to fix a signal ABI regression (Matthew Schwartz) - Add a test for this signal ABI regression the x86 self-test suite (Matthew Schwartz) - Don't emit the new and not yet properly supported EGPR instructions (%r16-%r31) on CONFIG_X86_NATIVE_CPU=y builds (Chang S. Bae) * tag 'x86-urgent-2026-09-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/build/64: Prevent native builds from generating EGPR use selftests/x86: Check signal state for rejected software interrupts x86/fred: Reconstruct the #GP context for rejected INT instructions x86/microcode/intel: Reject problematic loading on Granite Rapids systems commit 0a15ba6b0c3adec5842d4252c3e5d2ca935e9948 Merge: fecbe78ac0e7bb c21eaa72f02fc6 Author: Linus Torvalds Date: Sun Sep 20 09:41:00 2026 -0700 Merge tag 'timers-urgent-2026-09-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer race fixes from Ingo Molnar: - Fix timer signal <-> exec() race, to prevent UAF (Thomas Gleixner) - Clean up POSIX CPU timers right after de_thread(), to prevent UAF (Hyunwoo Kim) - Fix POSIX CPU timers race between expiry and timer_settime(), to prevent UAF (Thomas Gleixner) * tag 'timers-urgent-2026-09-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: posix-cpu-timers: Prevent freeing a timer which is queued on the expiry list exec: Cleanup POSIX timers right after de_thread() signal: Prevent exec() race commit fecbe78ac0e7bb5cdae232444e649a3103d9a917 Merge: abb91eed948fcd fe3c73d7bc769e Author: Linus Torvalds Date: Sun Sep 20 09:37:27 2026 -0700 Merge tag 'sched-urgent-2026-09-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fix from Ingo Molnar: - Avoid false positive migration warning for proxy donors (Andrea Righi) * tag 'sched-urgent-2026-09-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/core: Avoid false migration warning for proxy donors commit abb91eed948fcdabc7360d57cc3d3a7fba75db67 Merge: 2f7ff5f5479b02 88aed0422f39b2 Author: Linus Torvalds Date: Sun Sep 20 09:26:22 2026 -0700 Merge tag 'perf-urgent-2026-09-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf events fixes from Ingo Molnar: - Fix crash when probing CS CALL instructions (Jinke Han) - Fix NULL pointer crash during module unload (Vinay Belgaumkar) * tag 'perf-urgent-2026-09-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Fix null pointer access in is_include_guest_event() x86/kprobes: Fix crash when probing CS CALL instructions commit 2f7ff5f5479b020df69feb7493d4012685a8fc96 Merge: bdab18633a302c 7e61560628d17e Author: Linus Torvalds Date: Sun Sep 20 08:41:19 2026 -0700 Merge tag 'objtool-urgent-2026-09-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull objtool fix from Ingo Molnar: - Fix objtool build error on systems where libopcodes is present, but development headers (binutils-dev) are not (Ulises Mendez Martinez) * tag 'objtool-urgent-2026-09-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool: Validate disassembler headers in libopcodes probe commit bdab18633a302c82b5e5d5dbc4e38b0baf9c0837 Merge: 5bf70485f96b92 b61b6f95d6722d Author: Linus Torvalds Date: Sun Sep 20 08:15:23 2026 -0700 Merge tag 'locking-urgent-2026-09-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull futex fix from Ingo Molnar: - Also allocate a default private futex hash on vfork() as well, to avoid races with (private) futex waiters (Peter Zijlstra) * tag 'locking-urgent-2026-09-20' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: futex: Also allocate private hash on vfork() commit 5bf70485f96b927d706a0db66825e4e3b2dd66fc Merge: aa211c7a5837f2 3d743adf090cd4 Author: Linus Torvalds Date: Sun Sep 20 08:08:54 2026 -0700 Merge tag 'spi-fix-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A few driver specific fixes, none of them particularly severe or unusual" * tag 'spi-fix-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: fsl-qspi: Reprogram the clock rate when the operation frequency changes spi: spi-zynqmp-gqspi: stop the controller on shutdown spi: virtio: Use the per-transfer bits per word spi: spi-qpic-snand: avoid writing QPIC_EBI2_ECC_BUF_CFG register commit aa211c7a5837f20f0995691c036a4b22d0360737 Merge: b12dd0fa481f69 7362a1553eb09a Author: Linus Torvalds Date: Sun Sep 20 07:57:47 2026 -0700 Merge tag 'i2c-fixes-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull i2c fixes from Andi Shyti: "Fixes mainly for cleanup and error handling, a good part of them around DMA resource management: - at91: ensure DMA channels are released on all exit paths - imx: fix autosuspend cleanup on remove - qcom-cci: fix device node reference leak - atr, imx, qcom-geni: set adapter slot to NULL on registration failure" * tag 'i2c-fixes-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: i2c: qcom-cci: fix device_node refcount leak in cci_probe()/cci_remove() i2c: qcom-geni: release DMA channels on probe error i2c: imx: release DMA channels on probe error i2c: at91: release DMA channels on remove and probe error i2c: atr: fix dangling adapter pointer on add failure i2c: imx: disable autosuspend on remove commit b12dd0fa481f6914f9375155865a04c3f9f9d800 Merge: 4a910e594aae61 309731e9591712 Author: Linus Torvalds Date: Sun Sep 20 07:02:34 2026 -0700 Merge tag 'input-for-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: - Fixes for evdev and input compat handling to zero-initialize on-stack absinfo and force-feedback effect structures before partial or compat copies from userspace, preventing kernel stack memory disclosure - Fixes for the Synaptics RMI4 driver to prevent an out-of-bounds read when writing multi-chunk blocks over SMBus and to avoid a NULL pointer dereference during suspend/resume when the RMI device is unbound - Fixes for the soc_button_array driver to propagate -EPROBE_DEFER on non-Bay Trail/Cherry Trail platforms (fixing broken power and volume buttons on the Microsoft Surface Pro 11) and to validate the ACPI package element count before dereferencing - A fix for the adp5588-keys driver to cache the initial GPIO hardware state before registering the gpiochip so pre-configured pin states are not clobbered by GPIO hogs during registration - A fix for the cyttsp5 touchscreen driver to clamp the device-supplied HID report size before copying into the response buffer, preventing a buffer overflow - A fix for the HP SDC serio driver to use timer_shutdown_sync() on module exit so the periodic kicker timer cannot rearm itself during teardown - A fix for the eeti_ts touchscreen driver to export its OF module alias so the module autoloads on Device Tree platforms - Updates to the xpad joystick driver adding support for the Victrix Pro BFG controller and Azeron devices, and fixing the device type classification for the PDP Marvel Xbox 360 controller - Quirks for the i8042 and atkbd drivers to keep the built-in keyboards functional on the Acer Aspire Go 15 AG15-42P and Xiaomi Redmi Book Pro 16 2026 - A quirk for the Synaptics PS/2 touchpad driver disabling SMBus InterTouch on the Lenovo ThinkPad T440p (board ID 2722) so the touchpad and TrackPoint respond immediately at boot - Other minor updates and documentation fixes, including reading the "ti,poll-period" property as u32 in tsc2007, adding the mt6572 compatible to the MediaTek keypad Device Tree binding, fixing an attribute name typo in the trackpoint sysfs ABI documentation, and documenting that no new LED codes should be added to the input subsystem * tag 'input-for-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: hp_sdc - shut down kicker timer on module exit Input: xpad - add support for Victrix Pro BFG Controller Input: tsc2007 - read "ti,poll-period" as u32 Input: trackpoint - fix the inertia attribute name in the ABI document Input: eeti_ts - publish the OF module alias Input: xpad - add support for Azeron devices Input: xpad - fix PDP Marvel Xbox 360 controller Input: document that no new LED codes should be added Input: soc_button_array - check btns_desc->package.count Input: soc_button_array - fix MS Surface Pro 11 probe failure Input: i8042 - add quirk for Acer Aspire Go 15 AG15-42P Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722) Input: cyttsp5 - clamp the HID report size before memcpy Input: zero ff_effect before compat copy in input_ff_effect_from_user Input: evdev - zero absinfo before partial copy in EVIOCSABS Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound Input: rmi_smbus - fix out-of-bounds read in rmi_smb_write_block() Input: atkbd - skip deactivate for Xiaomi Redmi Book Pro 16 2026 dt-bindings: input: mediatek,mt6779-keypad: add mt6572 Input: adp5588-keys - cache GPIO state before registering the gpiochip commit 4a910e594aae615fcc8e0f840549659e13641529 Merge: 518e5b794c06c0 78fc54b934bfb2 Author: Linus Torvalds Date: Sun Sep 20 06:50:31 2026 -0700 Merge tag 'selinux-pr-20260919' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux Pull selinux fixes from Paul Moore: - Ensure that the cached SELinux access decisions are correct - Fix the SELinux overlayfs code to properly track the top-level/user information on multiple stacked overlayfs filesystems - Fix the SELinux overlayfs code to properly enforce mprotect() access control policy on all of the different layers in multiple stacked overlayfs filesystems * tag 'selinux-pr-20260919' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux: selinux: recheck intermediate backing files on mprotect() selinux: preserve user SID across nested backing files selinux: always fill AVC decision in avc_has_perm_noaudit() commit afb1ecfeda3fc31d6300a176f4854cc62e289bf3 Author: Pengpeng Hou Date: Fri Aug 14 15:53:10 2026 +0800 ARM: configs: sama5: enable current Microchip KSZ DSA symbols The Microchip KSZ DSA family now uses NET_DSA_MICROCHIP_KSZ_COMMON for the common provider and NET_DSA_MICROCHIP_KSZ_SPI for SPI-attached switches. sama5_defconfig still enables the removed KSZ9477-specific symbols even though SAMA5 device trees contain KSZ SPI switch consumers. Replace the stale entries with the current provider symbols. Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou Fixes: 07bca160469b ("net: dsa: microchip: common menuconfig for ksz series switch") Fixes: 4658f2fe8fbc ("net: dsa: microchip: common ksz_spi_probe for ksz switches") Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/20260814075310.11613-1-pengpeng@iscas.ac.cn Signed-off-by: Claudiu Beznea commit 3fa5aa398edf94653926ad5e68b89f69490481b5 Author: Mickaël Salaün Date: Fri Sep 18 20:50:32 2026 +0200 landlock: Fix tracepoint contract documentation The tracepoint documentation claims that denial and lifecycle events expose every input needed to reproduce a verdict. Instead document how denial, ruleset, and domain events identify the denying policy, checked operation and object, and reason for denial. Direct consumers to generic tracepoints for additional operational context. State the reconstruction limits: IDs are boot-local, rule checks have no request ID, and exported records may be lost or cross-CPU reordered. Also replace the incorrect BPF_RAW_TRACEPOINT guidance with libbpf SEC("tp_btf/...") attachment and refer consumers to the event prototypes for callback argument layouts. Cc: Günther Noack Cc: Steven Rostedt Link: https://patch.msgid.link/20260918185036.608651-10-mic@digikod.net Signed-off-by: Mickaël Salaün commit c8dcb17205a689e96e2b8e46f22575a39b5b6320 Author: Mickaël Salaün Date: Fri Sep 18 20:50:31 2026 +0200 selftests/landlock: Test network denial context Network denial events now report the port from their one authoritative validated address through one signed field. Verify this value directly without inferring a source or destination role. Exercise a nonzero IPv4 TCP bind, an explicit-zero IPv4 UDP bind, a synthetic-zero IPv6 UDP autobind, and a family-only AF_UNSPEC UDP send. Require exactly one event with the exact policy blocker for each shape. The value -1 distinguishes a family-only address with no validated port from the two valid port-zero cases. Test coverage for security/landlock is 91.6% of 2625 lines according to LLVM 22. Cc: Günther Noack Cc: Steven Rostedt Link: https://patch.msgid.link/20260918185036.608651-9-mic@digikod.net [mic: Add test coverage] Signed-off-by: Mickaël Salaün commit c6dea91d846f192eb6ddbd44f5fd873035b8b285 Author: Mickaël Salaün Date: Fri Sep 18 20:50:30 2026 +0200 selftests/landlock: Test filesystem denial blockers Filesystem denial traces identify the policy change needed to allow a request, so require exact blocker values rather than merely nonempty output. Pin a READ_DIR denial to exactly one event with blockers=read_dir. Pin a REFER-only mount denial to EPERM and exactly one event with blockers=change_topology. The mount child retains CAP_SYS_ADMIN so Landlock is the only expected source of EPERM. This prevents a later capability failure from masking a Landlock regression; the trace-collecting parent remains unsandboxed. Cc: Günther Noack Cc: Steven Rostedt Link: https://patch.msgid.link/20260918185036.608651-8-mic@digikod.net Signed-off-by: Mickaël Salaün commit 0889db596a25ecde210e66fa0db70bc6a6d91f6c Author: Mickaël Salaün Date: Fri Sep 18 20:50:29 2026 +0200 landlock: Report the effective signal number The signal-scope denial callback identifies its target but not the effective signal. This loses permission-probe signal zero and makes the file-owner hook's zero sentinel ambiguous. Append an int signal argument to the typed-BPF callback. Preserve sig, including zero, in hook_task_kill(). In hook_file_send_sigiotask(), translate signum zero to SIGIO at the producer, where its meaning is known. Carry the effective signal and target domain ID in a private, stack-backed context consumed synchronously. This requires no allocation or task reference in the interrupt-capable file-owner path. Gate this context and the remaining scope-only domain IDs with CONFIG_TRACEPOINTS. Keep the tracefs record and audit output unchanged. Cc: Günther Noack Cc: Steven Rostedt Fixes: bb91730f16c0 ("landlock: Add tracepoints for ptrace and scope denials") Link: https://patch.msgid.link/20260918185036.608651-7-mic@digikod.net Signed-off-by: Mickaël Salaün commit 7ad69ac63315506e2091bf46d5c96c49f6ce439e Author: Mickaël Salaün Date: Fri Sep 18 20:50:28 2026 +0200 landlock: Report the actual ptrace tracer The ptrace denial callback identifies only the tracee. Current is the tracer during hook_ptrace_access_check(), but it is the tracee during PTRACE_TRACEME, where the parent is the actual tracer. A consumer therefore cannot infer both parties from the existing arguments. Append the actual tracer task to the typed-BPF callback: current for hook_ptrace_access_check() and parent for hook_ptrace_traceme(). Carry it with the tracee domain ID in a private ptrace context. Both hooks keep the selected tasks alive through synchronous dispatch, so no extra task reference is needed. Keep the tracefs record unchanged. The new context is available only to typed BPF, while same_exec continues to describe the tracer that owns the denying policy. Cc: Günther Noack Cc: Steven Rostedt Fixes: bb91730f16c0 ("landlock: Add tracepoints for ptrace and scope denials") Link: https://patch.msgid.link/20260918185036.608651-6-mic@digikod.net Signed-off-by: Mickaël Salaün commit 98b04ab00f0e738d69bd718228db55483a911b7a Author: Mickaël Salaün Date: Fri Sep 18 20:50:27 2026 +0200 landlock: Fix network denial trace context Network denial events report source and destination ports reconstructed from audit data. Their zero values are ambiguous, and neither identifies the complete endpoint that Landlock checked. Carry the checked sockaddr and its signed length in a private trace-only context. For an enabled event, validate the length and copy only the initialized prefix into zeroed local storage. This prevents a typed BPF program from reading uninitialized bytes while exposing the socket family, socket, address, and length. Replace the source and destination trace-record fields with one signed port derived from the checked address. A value of -1 means that no port was checked, zero is a valid port, and positive values use host endianness. Bind blockers select the bind address; connect and send blockers select the destination. Cc: Günther Noack Cc: Steven Rostedt Fixes: 01ce260f5ccf ("landlock: Add landlock_deny_access_fs and landlock_deny_access_net") Link: https://patch.msgid.link/20260918185036.608651-5-mic@digikod.net Signed-off-by: Mickaël Salaün commit 1a985d3890ed8caa428390a5682e957503f14060 Author: Mickaël Salaün Date: Fri Sep 18 20:50:26 2026 +0200 landlock: Fix rule tracepoint context Name each event after the identity it reports. Add-rule events describe UAPI rule insertion, so rename them after LANDLOCK_RULE_PATH_BENEATH and LANDLOCK_RULE_NET_PORT. Check-rule events describe matches in internal rule trees, so rename them after LANDLOCK_KEY_INODE and LANDLOCK_KEY_NET_PORT. This remains accurate if multiple UAPI rule types share one lookup and stored rule. Keep denial event names based on filesystem and network families because they describe final access decisions. Use u64 for growable access masks passed by value to add-rule and check-rule typed BTF callbacks. CO-RE can relocate pointer-reached fields, but it cannot widen a scalar callback slot declared by a BPF program. Keep native access_mask_t for internal state and trace records. For add-rule callbacks, report the normalized per-call contribution passed to landlock_insert_rule() and expose the complete validated flags value. Put the ruleset and flags first as a common invocation prefix. This distinguishes duplicate and effective-zero additions without recovering arguments from saved syscall registers. Cc: Günther Noack Cc: Steven Rostedt Fixes: 63747c94774d ("landlock: Add landlock_add_rule_fs and landlock_add_rule_net tracepoints") Fixes: 3f1f106e4c14 ("landlock: Add tracepoints for rule checking") Link: https://patch.msgid.link/20260918185036.608651-4-mic@digikod.net Signed-off-by: Mickaël Salaün commit 0de33ca344fbf983d380d78db6eeb6fe312d5a5e Author: Mickaël Salaün Date: Fri Sep 18 20:50:25 2026 +0200 landlock: Fix filesystem denial blocker reporting Filesystem topology denials are rendered with an empty blockers value because their blocker is identified by the request type instead of an access mask. Introduce the private struct landlock_blockers to carry the request type and final missing access mask to filesystem and network denial tracepoints. Copy both members into named trace-record fields, then use the type to print change_topology for topology denials while preserving symbolic access masks for ordinary denials. The request type lets typed BPF consumers distinguish topology denials from access denials. Keeping the native access mask in a pointer-reached field also lets CO-RE adjust existing programs' load width if access_mask_t grows. Cc: Günther Noack Cc: Steven Rostedt Fixes: 01ce260f5ccf ("landlock: Add landlock_deny_access_fs and landlock_deny_access_net") Link: https://patch.msgid.link/20260918185036.608651-3-mic@digikod.net Signed-off-by: Mickaël Salaün commit f71ecaece401cef287cdca12aad785fec809cb9e Author: Mickaël Salaün Date: Fri Sep 18 20:50:24 2026 +0200 landlock: Fix tracepoint fixed-width type names The new Landlock tracepoints use UAPI-prefixed __u32 and __u64 names for callback arguments and record fields, including internal IDs that are not Landlock UAPI values. Typed BPF consumers see callback typedef names through BTF. Use the kernel u32 and u64 aliases before release so the tracepoint contract does not present internal values as Landlock UAPI types. This changes BTF-visible typedef spelling but not integer widths, calling conventions, tracefs formats, or record layouts. Cc: Günther Noack Cc: Steven Rostedt Link: https://patch.msgid.link/20260918185036.608651-2-mic@digikod.net Signed-off-by: Mickaël Salaün commit c4e941bb7654bcbdfb0b6f3341dc2acfdf235c8d Author: Arnd Bergmann Date: Tue Sep 15 22:10:30 2026 +0200 landlock: Work around gcc-16 -Wuninitialized warning gcc has a bug with -ftrivial-auto-var-init=pattern that produces a warning for correct code that uses sparse bitfields: security/landlock/fs.c: In function 'is_access_to_paths_allowed.isra': security/landlock/fs.c:767:28: error: '_layer_masks_child1' is used uninitialized [-Werror=uninitialized] 767 | struct layer_masks _layer_masks_child1, _layer_masks_child2; | ^~~~~~~~~~~~~~~~~~~ security/landlock/fs.c:767:28: note: '_layer_masks_child1' declared here 767 | struct layer_masks _layer_masks_child1, _layer_masks_child2; | ^~~~~~~~~~~~~~~~~~~ security/landlock/fs.c: In function 'hook_unix_find': security/landlock/fs.c:1649:28: error: 'layer_masks' is used uninitialized [-Werror=uninitialized] 1649 | struct layer_masks layer_masks; | ^~~~~~~~~~~ security/landlock/fs.c:1649:28: note: 'layer_masks' declared here 1649 | struct layer_masks layer_masks; | ^~~~~~~~~~~ To work around this, change the definition of struct layer_mask to use an explictit padding field. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110743 Link: https://lore.kernel.org/all/20260619082133.3504146-1-arnd@kernel.org/ Fixes: a260c0055665 ("landlock: Add a place for flags to layer rules") Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260915201036.3527935-1-arnd@kernel.org [mic: Use BITS_PER_TYPE(), fix kdoc warnings, fix commit message according to v2 changes] Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün commit 7362a1553eb09a8cdf8be7e509bd5309a8342486 Author: Liu Zhenlong Date: Wed Aug 19 01:57:50 2026 +0800 i2c: qcom-cci: fix device_node refcount leak in cci_probe()/cci_remove() The of_node_put() matching of_node_get() runs after i2c_del_adapter(), whose trailing memset() zeroes adap->dev and thus adap->dev.of_node, making the put a no-op and leaking the node on every adapter removal and error cleanup. Use a devm action: the pointer is captured at registration, out of reach of that memset(), and devres runs the put once on probe failure and detach, replacing the three manual of_node_put() calls. The setup loop uses the scoped iterator form so the child node is released automatically if devm_add_action_or_reset() fails mid-loop. Suggested-by: Konrad Dybcio Fixes: 02a4a69667a2 ("i2c: qcom-cci: don't put a device tree node before i2c_add_adapter()") Assisted-by: Claude:claude-opus-5 Signed-off-by: Liu Zhenlong Cc: # v5.17+ Reviewed-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260818175750.4205-1-dragonliu2018@gmail.com commit 268aacb2e2a5c94d08e23194961234d0710c8407 Author: Shengzhuo Wei Date: Thu Aug 27 23:43:03 2026 +0800 i2c: qcom-geni: release DMA channels on probe error geni_i2c_init() grabs exclusive GPI tx/rx DMA channels when the serial engine runs in GPI mode. If i2c_add_adapter() subsequently fails, probe returns without releasing the channels, because the remove callback is not invoked after a failed probe. The adapter-registration failure path used to release the channels via its err_dma label; that release was dropped when the probe tail was restructured into geni_i2c_init(). Release the channels on the adapter-registration failure path, mirroring geni_i2c_remove(). Fixes: d8d3bb127ad1 ("i2c: qcom-geni: Isolate serial engine setup") Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Reviewed-by: Konrad Dybcio Reviewed-by: Mukesh Kumar Savaliya Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260827-i2c-dma-channel-leak-v1-3-271d4adc03a0@cherr.cc commit e9f03b9625e2eeaca357b065c92d5b14064a1583 Author: Shengzhuo Wei Date: Thu Aug 27 23:43:02 2026 +0800 i2c: imx: release DMA channels on probe error i2c_imx_dma_request() acquires exclusive tx/rx DMA channels and is optional: on errors other than -EPROBE_DEFER the driver falls back to PIO mode and probe continues. If i2c_add_numbered_adapter() then fails, probe returns through clk_notifier_unregister without releasing the channels, because the remove callback is not invoked after a failed probe. Release the channels on the probe error path, mirroring i2c_imx_remove(). Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver") Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Cc: # v3.19+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260827-i2c-dma-channel-leak-v1-2-271d4adc03a0@cherr.cc commit f7eeb1af8537b05953fb1c88ab8b59d94059a381 Author: Shengzhuo Wei Date: Thu Aug 27 23:43:01 2026 +0800 i2c: at91: release DMA channels on remove and probe error at91_twi_configure_dma() requests exclusive tx/rx DMA channels, but nothing ever releases them on driver detach, and the probe error path after the channels are acquired (i2c_add_numbered_adapter() failure) returns without releasing them either, because the remove callback is not invoked after a failed probe. Move the release into a helper, call it from the existing configure-failure path, the adapter-registration failure path, and at91_twi_remove(). Fixes: 60937b2cdbf9 ("i2c: at91: add dma support") Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Cc: # v3.8+ Acked-by: Mukesh Kumar Savaliya Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260827-i2c-dma-channel-leak-v1-1-271d4adc03a0@cherr.cc commit 8f6f8a48399f82f4a83f7b9f25b9707e0062a4f9 Author: Adarsh Das Date: Sat Sep 19 16:27:32 2026 +0530 smb: client: delete compound mids on send failure before unlock When sending a compound request fails, smb_send_rqst() kicks off a reconnect. compound_send_recv() still has those mids on pending_mid_q, but it unlocks the server without removing them first. During reconnect, cifs_abort_connection() walks pending_mid_q and runs each mid callback. With no response yet, those callbacks return credits and drop in_flight. Then compound_send_recv()'s send-error path returns the same credits again. in_flight ends up decremented twice and smb2_add_credits() WARNs. syzbot hits this during SMB2_negotiate when the socket send fails. cifs_call_async() already calls delete_mid() before unlock on send failure. Do the same for compound chains and set cancelled_mid[] so the out: path does not delete them again. Fixes: ee258d79159a ("CIFS: Move credit processing to mid callbacks for SMB3") Reported-by: syzbot+eeb58d2197d88720a228@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/6a727d22.40259c87.584f4.04ce.GAE@google.com Tested-by: syzbot+eeb58d2197d88720a228@syzkaller.appspotmail.com Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Adarsh Das Signed-off-by: Paulo Alcantara commit 1e24c4f2ee44be0eee94092b5d13cbdb4bdf0d60 Author: Jamal Hadi Salim Date: Thu Sep 17 06:57:33 2026 -0400 selftests: tc-testing: add a lateral-drift hfsc classify-walk test The classify-loop fix bounds a walk's non-descending hops, so the guard must not misfire on a legal walk that reaches its leaf through a level-drift lateral chain. Add a case that builds exactly that chain and asserts traffic still reaches the chain's own leaf. A lateral hop can only exist because a bind was legal when it was made and a later class add raised the target's level, so the setup binds each hop while the target is still a leaf and only then deepens it: bind 1:1 -> 1:2 while 1:2 is a leaf, add 1:20 under 1:2, add 1:3 and bind 1:2 -> 1:3 while 1:3 is a leaf, then add 1:30 and 1:31 under 1:3 and bind 1:3 -> 1:31. The walk root -> 1:1 -> 1:2 -> 1:3 -> 1:31 then takes two lateral hops and must reach leaf 1:31. The default class is 1:30, distinct from the asserted leaf, and the verify pattern is anchored to the 1:31 stats line, so neither a fall-through to the default nor a nonzero count on another class can satisfy the check. On the patched kernel the test passes; with the bound forced to zero the walk falls to the default and 1:31 stays idle, so the test fails. Reviewed-by: Victor Nogueira Tested-by: hybris Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-CTUU.v3.20260916184908@mojatatu.com.2 Signed-off-by: Jakub Kicinski commit 8a60ade2277e1f0e0d0578d565354e52292fa46d Author: Jamal Hadi Salim Date: Thu Sep 17 06:57:32 2026 -0400 net/sched: sch_hfsc: bound the classify inner-filter walk with a drift budget hfsc_classify() applies the "filter may only point downwards" level check only when the filter result carries no bound class. A filter created with a flowid gets res.class set once at bind time, so the check never runs for it during classification. hfsc_adjust_levels() can later raise a class's level without revalidating existing bindings, leaving two binds that were each legal at bind time pointing at each other; the classify walk then bounces between two interior classes forever with the qdisc lock held and BH disabled — a soft lockup from a single packet. The stuck walk trips the watchdog: watchdog: BUG: soft lockup - CPU#3 stuck for 13s! [ping:444] RIP: 0010:u32_classify+0x542/0x17f0 ... tcf_classify+0x66/0xa0 hfsc_enqueue+0x166/0xdf0 Bound the traversal with a budget of non-descending hops, the only way a configured walk can move without descending the class tree once levels drift after bind time. The budget is cumulative over the whole walk and is deliberately not reset on a descending hop: a chain that alternates a descent with a lateral hop would return the budget every lap and never trip. Descending hops never decrement it, so legitimately deep trees are unaffected and a terminating lateral chain still classifies normally. Drop the packet with a rate-limited warning once the budget is exhausted, mirroring the merged HTB fix. This is a follow-up to commit 729c4896ab82 ("net/sched: sch_htb: limit htb_classify inner-class filter hops"), which bounded the same classify loop on the HTB side but left the HFSC walk unbounded. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HFSC, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Build a cycle with two legal-at-bind-time flowid binds and a level drift: class X 1:1 (child of root) with leaf child 1:10; class Y 1:2 (sibling of X) with children 1:20 and 1:200; root u32 filter flowid 1:1; filter on X flowid 1:2 (legal when Y is a leaf); after Y's level rises to 2, filter on Y flowid 1:1 (legal then). Send one packet (ping on the device). Unfixed kernel: classify spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN). Fixes: a2f79227138c ("net_sched: sch_hfsc: fix classification loops") Reported-by: Sashiko (gemini + nipa) Closes: https://lore.kernel.org/netdev/QDISC-CTUU.v2.20260913192614@mojatatu.com/ Link: https://sashiko.dev/#/patchset/QDISC-CTUU.v2.20260913192614@mojatatu.com Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/QDISC-CTUU.v2.20260913192614%40mojatatu.com Reviewed-by: Victor Nogueira Tested-by: hybris Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-CTUU.v3.20260916184908@mojatatu.com Signed-off-by: Jakub Kicinski commit a11212910cf09b2fe8db9afa41ef60c4f81879c5 Author: Yuqi Xu Date: Sat Sep 19 16:45:02 2026 +0800 bpf: Check params size before reading reserved fields bpf_crypto_ctx_create() is a kfunc whose second argument is declared with the __sz annotation, so the verifier only guarantees that params__sz bytes of params are valid. The function nevertheless reads params->reserved[0] and params->reserved[1] (offsets 14 and 15) before comparing params__sz against the size of struct bpf_crypto_params, so a BPF program can pass a shorter buffer and have the kernel read past the region that was validated for it. Move the size check in front of the reserved field reads. Fixes: 3e1c6f35409f ("bpf: make common crypto API for TC/XDP programs") Reported-by: Vega Signed-off-by: Yuqi Xu Signed-off-by: Alexei Starovoitov Reviewed-by: Ren Wei Link: https://patch.msgid.link/4f3ab4b03e79017e215521743996555439bf0bb3.1789802413.git.xuyuqiabc@gmail.com commit c37fc4deee0065e444306def9c79ba22b9b0f84e Author: Naman Jain Date: Mon Sep 7 05:47:42 2026 +0000 PCI: hv: Probe vPCI buses asynchronously On Hyper-V guests each virtual PCI bus is enumerated by its own hv_pci_probe() call. The probe performs several synchronous host request/response exchanges while negotiating the protocol, querying bus relations, entering D0, and reporting allocated resources. These waits are latency-bound rather than CPU-bound. hv_pci registers as an ordinary VMBus driver, so driver_register() walks matching vPCI buses and probes them sequentially while the driver's initcall runs. On guests that expose several devices, each through its own vPCI bus, this serialization adds the host round-trip latencies to device initialization. Each bus is described by its own struct hv_pcibus_device, so independent buses can be probed concurrently. Request asynchronous probing via PROBE_PREFER_ASYNCHRONOUS, causing the driver core to schedule matching buses for asynchronous probe work. On an Azure Standard_L32s_v3 guest with five vPCI targets (four NVMe controllers and one Mellanox VF), Linux 7.2.3 was tested with one warm-up and three measured boots per variant. The median interval from the first hv_pci_probe() entry to the last return decreased from 2847.968 ms to 2786.709 ms, a 61.259 ms (2.15%) improvement. Co-developed-by: Dexuan Cui Signed-off-by: Dexuan Cui Signed-off-by: Naman Jain Reviewed-by: Sahil Chandna Signed-off-by: Wei Liu commit 12f631d5ded523b56cbd3db350b0a768a4d13d1a Author: Long Li Date: Mon Sep 14 21:31:50 2026 -0700 MAINTAINERS: remove myself from the Hyper-V entries I am no longer maintaining the Hyper-V/Azure core and drivers, or the Hyper-V synthetic video DRM driver. Signed-off-by: Long Li Signed-off-by: Wei Liu commit 874194a8de75fc2f4d1fb70c670b289b7e48f93e Author: Hardik Garg Date: Fri Sep 11 17:51:46 2026 +0000 mshv_vtl: Check per-CPU register page before mmap Register-page setup is optional for each CPU. If allocation or registration fails, mshv_vtl_configure_reg_page() warns and leaves that CPU's reg_page NULL, but initial context setup continues successfully. Meanwhile, successful setup on another CPU sets the global mshv_has_reg_page flag. mshv_vtl_fault() checks this global flag before selecting the requested CPU's register page. With mixed setup results across online CPUs, the check passes even for a CPU with no register page, reaching get_page(NULL) when userspace faults in that mapping. Check the selected per-CPU register page before taking its reference and return VM_FAULT_SIGBUS if it is absent. Fixes: 7bfe3b8ea6e3 ("Drivers: hv: Introduce mshv_vtl driver") Cc: stable@vger.kernel.org Signed-off-by: Hardik Garg Reviewed-by: Naman Jain Signed-off-by: Wei Liu commit d5e689696017dfef8cd6f4eac895e6d23fa4a7bb Author: Hemanth Selam Date: Tue Sep 15 12:31:45 2026 +0530 tools/hv: fix typo "retrive" in comment Correct "retrive" to "retrieve". Reviewed-by: Michael Kelley Signed-off-by: Hemanth Selam Signed-off-by: Wei Liu commit 7724f2364396187163a73bdda43189b9e7c1aba9 Author: Hemanth Selam Date: Tue Sep 15 12:31:44 2026 +0530 Drivers: hv: vmbus: fix typo "substract" in comment Correct "substract" to "subtract". Reviewed-by: Michael Kelley Signed-off-by: Hemanth Selam Signed-off-by: Wei Liu commit ab888242fce4f16f6c4d4c6ec53939ad36aa3b3a Author: Xiang Mei Date: Tue Sep 15 01:31:52 2026 -0700 vlan: require the MAC header to be present in __vlan_insert_inner_tag() __vlan_insert_inner_tag() only guarantees head room via skb_cow_head(), never that mac_len bytes of MAC header are present. Its ETH_HLEN wrappers - __vlan_insert_tag() under skb_vlan_push(), and vlan_insert_tag() under validate_xmit_vlan() on the generic transmit path - therefore rewrite the first 16 bytes at skb->data: a 12-byte memmove plus two 2-byte stores at +12 and +14. No caller supplies the bound, while the pop helpers use skb_ensure_writable()/pskb_may_pull(). An IFF_TUN device has hard_header_len == 0, so packet_snd() accepts a one-byte AF_PACKET/SOCK_RAW frame. The first vlan push only sets a hwaccel tag; the next - clsact "action vlan push" or bpf_skb_vlan_push() - enters the helper with skb->len still 1. The head comes from skbuff_small_head without __GFP_ZERO, so each push drags bytes from beyond skb->tail into the frame. After three the one-byte send leaves as 13 bytes carrying 11 bytes of uninitialised slab: 0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81 `------------------------------' only 0x5a was sent; the rest is slab, here the top 56 bits of a linear-map address Require the MAC header the helper rewrites to be present, so such a frame is dropped rather than transmitted. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: co+0ea1ac045375cf05@bugs.sh Signed-off-by: Xiang Mei Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260915083152.705309-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski commit 9d565b6b72fe3f41fd43636e143072848105189f Author: Aamir Ahmed Date: Tue Sep 15 00:06:58 2026 +0100 net: usb: catc: bound the RX packet length in catc_rx_done() catc_rx_done() walks a multi-packet URB, reading a two-byte length from each packet header. Its bound, pkt_len > urb->actual_length, ignores the header offset and compares against the whole transfer rather than the bytes left from pkt_start, so a crafted packet header makes skb_copy_to_linear_data() read past the buffer. A length below ETH_HLEN is also accepted, including zero, and eth_type_trans() then reads a MAC header from the uninitialised tailroom of a shorter skb. The is_f5u011 branch takes its length straight from the transfer, so a zero-length URB reaches the same path. Track the bytes remaining from the current packet, and reject a header that does not fit, a length past what is left, and a length below an Ethernet header. A transfer shorter than an Ethernet header, including a zero-length one, previously became a runt skb passed to netif_rx() and counted as received; it is now counted in rx_length_errors and ends the walk. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Aamir Ahmed Reviewed-by: Simon Horman Link: https://patch.msgid.link/AS8P251MB00015FD7716F38C345619B56C8BB2@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Jakub Kicinski commit c82b797abe668d0b668601a93ba2c0b071a63574 Author: Weiming Shi Date: Mon Sep 14 14:51:23 2026 +0800 net/sched: reject IDR error pointers when deleting actions tcf_action_delete() drops the reference held by its lookup before calling tcf_idr_delete_index() with the saved action index. An unlocked classifier can remove that action and reserve the same IDR slot with ERR_PTR(-EBUSY) in between. tcf_idr_delete_index() only checks the lookup result for NULL. It therefore treats the reservation as a tc_action and dereferences tcfa_bindcnt. A hardware execution breakpoint was used to schedule the interleaving without changing the kernel source. KASAN reported this decoded trace: BUG: KASAN: null-ptr-deref in tca_action_gd+0x5b9/0x1010 Read of size 4 at addr 0000000000000010 by task poc/150 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002 RIP: tca_action_gd+0x5c0/0x1010: arch_atomic_read at arch/x86/include/asm/atomic.h:23 raw_atomic_read at include/linux/atomic/atomic-arch-fallback.h:457 atomic_read at include/linux/atomic/atomic-instrumented.h:33 tcf_idr_delete_index at net/sched/act_api.c:766 tcf_action_delete at net/sched/act_api.c:1859 tcf_del_notify at net/sched/act_api.c:2014 tca_action_gd at net/sched/act_api.c:2064 R13: 0000000000000010 R15: fffffffffffffff0 Kernel panic - not syncing: Fatal exception R15 contains ERR_PTR(-EBUSY), and adding the tcfa_bindcnt offset produces the address in R13. With the guard applied, the same reproducer returned -ENOENT without a KASAN report or panic. Treat error pointers as absent and return -ENOENT. Fixes: 0190c1d452a9 ("net: sched: atomically check-allocate action") Cc: stable@vger.kernel.org Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260914065123.4109709-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski commit c21eaa72f02fc6e85621cbe09d303d8fb8bd39cd Author: Thomas Gleixner Date: Wed Sep 16 20:48:30 2026 +0200 posix-cpu-timers: Prevent freeing a timer which is queued on the expiry list Kijo analyzed another race in the POSIX CPU timer code: Commit bf635681c906 converted cpu_timer::firing from a tristate value to a boolean. This lost the distinction between "not owned by the firing list" and "still owned, but delivery was canceled". The resulting race is: expiry handler timer_settime() timer_delete() -------------- --------------- -------------- collect timer onto private firing list firing = true observes firing = true firing = false return TIMER_RETRY wait for handler observes firing = false finish deletion unhash and free timer resume list traversal read freed elist.next -> UAF The firing bit is clearly the wrong indicator since that commit. Check whether the timer is queued on the expiry list or not instead. If it is queued clear the firing bit to prevent signal delivery as before and return TIMER_RETRY so the caller unlocks the timer which allows the expiry code to make progress and remove it from the list. Fixes: bf635681c906 ("posix-cpu-timers: Cleanup the firing logic") Reported-by: Kijo Park Debugged-by: Kijo Park Signed-off-by: Thomas Gleixner Tested-by: Kijo Park Reviewed-by: Frederic Weisbecker Cc: stable@vger.kernel.org commit 518e5b794c06c0f0eb40df3e202274a66202c137 Merge: 40288c9206c17e 72de4807ba84da Author: Linus Torvalds Date: Sat Sep 19 13:48:20 2026 -0700 Merge tag 'for-7.3-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: "Among the regular fixes, there are two that were reported recently and have user impact: - filesystem id is now stable again on the default and common case (it broke openconnect key derivation, while this is not secure, it's still in use), the intention was to change id for the temp_fsid use case - fix detection of /dev/root and rename it after device scan, this broke booting of initramdisk-less system with grub2 as the probe needs the real device Regular fixes: - don't store compressed inline extent if the size is larger than uncompressed - in zoned mode, handle activation of zones for all supported block group profiles in case there are still free ones left - check space for a chunk item when reading sys array from superblock - allow using space reserves when removing verity items fails - fix error handling after free space tree rebuild fails - abort transaction if reflink or hole punching fails and it's not possible to update the inode - properly protect block group iteration during device replace start - error message fixups" * tag 'for-7.3-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: derive f_fsid with dev_t only when temp_fsid is active btrfs: add "/dev/root" exception for device path update btrfs: check if there is space for chunk item when validating sys chunk array btrfs: abort transaction on failure to update inode for hole punching and reflinking btrfs: clear free space tree creation state on rebuild failure btrfs: handle lack of space when cleaning up verity items btrfs: fix creation of compressed inline extents that don't save space btrfs: tree-checker: fix error message regarding free space extent items btrfs: tree-checker: print dev extent offset in error message btrfs: take commit root semaphore when iterating in mark_block_group_to_copy() btrfs: zoned: handle RAID profiles in btrfs_can_activate_zone() commit 6b1bca1b1ab77f60a62087337bfe6e2f0efb9e6d Author: Karl Mehltretter Date: Mon Aug 10 02:56:16 2026 +0200 KVM: arm64: Fix AArch32 DBGBXVR handling The consolidation of the breakpoint and watchpoint register accessors switched DBGBXVR from trap_bvr() to trap_dbg_wb_reg(). The latter selects backing storage with demux_wb_reg(), which only handles Op2 values 4 through 7. Since DBGBXVR uses Op2 1, an AArch32 guest access hits KVM_BUG_ON() and marks the VM dead. DBGBXVR aliases DBGBVR_EL1[63:32], and its AA32(HI) descriptor already selects the upper half. Map Op2 1 to dbg_bvr[] alongside Op2 4, restoring the pre-regression behavior. Fixes: 3ce9f3357e9e ("KVM: arm64: Fold DBGxVR/DBGxCR accessors into common set") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260810005616.13227-1-kmehltretter@gmail.com Signed-off-by: Oliver Upton commit d781d1b78acf547bafeb1592e8ba4020dce515c6 Author: Tejun Heo Date: Sat Sep 19 04:08:20 2026 -1000 selftests/sched_ext: Check the cmask cid-form ops.enable() receives cid-form ops.enable() now hands the task's cmask to the scheduler and set_cmask() repeats it right after. Add a cid-form selftest that checks both against p->cpus_ptr, that they match each other, that the initial set_cmask() lands before set_weight() and before the task first becomes runnable, and that set_cmask() never precedes enable(), across class-switch enables, fork-path enables and live affinity changes. v2: Mismatch details returned through a caller-local struct instead of globals, alloc_words validated in the header check, loop bounded by nr_cids directly (Andrea Righi). Signed-off-by: Tejun Heo commit 3bd46666cfe51e2bd333fb46a0234694ca594230 Author: Tejun Heo Date: Fri Sep 18 14:28:37 2026 -1000 sched_ext: Pass the initial cmask to cid-form ops.enable() The cid-form API has an obvious hole. A task's cid mask is only visible through ops.set_cmask(), which fires on affinity changes and class switches but not when a task enters a scheduler through fork, sub-sched enable or re-home, and there is no p->cpus_ptr equivalent to fall back on. Schedulers work around it by seeding the mask in ops.init_task() from p->cpus_ptr cid by cid, which is subtly wrong: on sub-sched enable and re-home, an affinity change between init_task() and enable() is delivered to the sched the task is still on, and nothing corrects the new sched's copy afterwards. Fix it by adding struct scx_enable_args to cid-form ops.enable() carrying the task's cmask, built in the per-cpu scratch under the rq lock as the task enters the scheduler, and calling set_cmask() with the same mask right after enable(), ahead of set_weight(). A scheduler can then track affinity in set_cmask() alone, and scx_qmap drops its init_task() seed. set_cmask() no longer fires for a cid-form task before it is enabled, and the class-switch republish in switching_to_scx() is limited to the cpu form. This changes the cid-form ops.enable() signature, which is fine as the cid-form API is still considered unreleased. An args struct rather than a bare cmask argument leaves room for more initial state without another signature change, and the cmask travels as a plain arena address because BTF can't type arena struct members yet. v2: The cmask travels as a u64 arena address, cmask_arena_addr, instead of a kernel-typed pointer, with the typing limitation and the planned typed alias documented (Sashiko review). v3: The initial set_cmask() is delivered before set_weight() so that the mask is in place when weight-dependent state is derived (Andrea Righi). Selftest added. Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit e3b6cb020e2f034a98068b2d11bcb3db9fff7e42 Merge: cdeea297197324 0288ed67482b6e Author: Alexei Starovoitov Date: Sat Sep 19 05:26:43 2026 +0000 Merge branch 'fix-acyclic-ownership-checks' Kumar Kartikeya Dwivedi says: ==================== Fix acyclic ownership checks Bound and ensure acyclic ownership graphs for native data structures to fix a bug reported by Nicholas. See commit logs and tests for details. The existing list/rbtree rule already rejects graph-only cycles and bounds those chains conservatively. It misses ownership through local referenced kptrs, which can produce unbounded synchronous field destruction. Validate all local ownership edges together, with an explicit depth bound, and allow longer acyclic graph-only layouts within that bound. Changelog: ---------- v1 -> v2 v1: https://lore.kernel.org/bpf/20260905090750.4064411-1-memxor@gmail.com/ * Fold the graph-walk and local-kptr changes into one complete fix. (Alexei) * Explain why the original rule catches graph-only cycles, its three-type chain bound, and the missing local-kptr ownership edges. (Alexei) * Distinguish synchronous recursive field destruction from the deferred RCU freeing of object storage. * Add depth-boundary tests with child-first BTF ordering and a shared suffix reached with different remaining budgets. * Cover list and rbtree chains at the original three-type bound and at the new eight-type bound, including rejected over-limit cases. ==================== Link: https://patch.msgid.link/20260914132444.2564218-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 0288ed67482b6e370eb3fa6b07720df435907970 Author: Kumar Kartikeya Dwivedi Date: Mon Sep 14 15:24:43 2026 +0200 selftests/bpf: Check local object ownership depth Build raw program BTF records to exercise local object ownership without constructing a runtime chain deep enough to threaten the kernel stack. Cover referenced-kptr and percpu-kptr self-cycles, a two-type cycle, and a cycle mixing a graph root with a referenced kptr. The existing graph-only check accepts these local-kptr cycles and over-limit kptr chains; the fix rejects them with -ELOOP. Pin the eight-record depth boundary with a terminal plain object. Exercise both parent-first and child-first BTF orders, and a shared suffix reached first through a shorter path. These cases require cached suffix depths to be checked against the remaining depth budget on each path. Check list and rbtree chains of three, four, eight, and nine types. This covers the old graph-only depth boundary and the new explicit bound. The existing linked-list BTF tests still reject pure graph cycles and now accept the longer acyclic layouts previously rejected by the conservative rule. Although bpf_percpu_obj_new() currently rejects types with special fields, require the percpu cycle to fail at BTF load so future support cannot bypass the ownership bound. Keep a positive control for a non-owning kptr, which remains outside the ownership graph. Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260914132444.2564218-3-memxor@gmail.com commit bfc888f04588f591851e95c974954cfca58e6c19 Author: Kumar Kartikeya Dwivedi Date: Mon Sep 14 15:24:42 2026 +0200 bpf: Bound ownership depth through local kptrs and graph roots Program-allocated objects can own other local objects through referenced kptrs. bpf_obj_free_fields() follows those pointers through __bpf_obj_drop_impl() synchronously, before the object storage is freed through RCU. A self-referential local kptr type therefore permits arbitrarily deep object chains, and dropping the head can exhaust the kernel stack. Long acyclic type chains have the same problem. btf_check_and_fixup_fields() still assumes referenced kptrs only point to kernel types and checks ownership through list and rbtree roots only. Its existing rule is sufficient for graph-only cycles: the target of each graph edge must contain a node, so every type in a cycle has both a root and a node. The rule rejects such a type owning another root, breaking every cycle. It also limits graph-only chains to three types, or two if the first type contains a node, and conservatively rejects longer acyclic chains. The missing local-kptr edges, rather than a missed graph-only cycle, are the bug introduced by support for bpf_kptr_xchg() into local kptrs. Replace that restriction with one bounded ownership walk covering graph roots and local referenced kptrs. Run it after all BTF records have been fixed up, reject cycles and paths deeper than eight record-bearing types, and cache each type's suffix depth while checking it against the remaining budget. This also permits the longer acyclic graph-only layouts rejected by the old rule; update their existing BTF tests accordingly. Keep the bound independent of MAX_CALL_FRAMES because recursive destruction can run below a BPF call chain. A plain local pointee without special-field metadata adds only a final non-recursing drop. Non-owning kptrs and kernel-BTF kptrs do not recurse through local records and remain outside the walk. Include local percpu-kptr edges too, although allocation of percpu objects with special fields is currently forbidden, so that relaxing that restriction cannot bypass the ownership bound. btf_check_and_fixup_fields() continues to initialize graph_root.value_rec, including for separately allocated map records. The ownership relationships belong to immutable program BTF and only need validation at BTF load time. Fixes: b0966c724584 ("bpf: Support bpf_kptr_xchg into local kptr") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Alexei Starovoitov Link: https://patch.msgid.link/20260914132444.2564218-2-memxor@gmail.com commit cdeea2971973247e2c95a8fc3d90a445c8f010f5 Merge: b4e875d397da45 070587848985ef Author: Alexei Starovoitov Date: Sat Sep 19 05:25:14 2026 +0000 Merge branch 'compare-stack-frames-in-exact-register-states' Kumar Kartikeya Dwivedi says: ==================== Compare stack frames in exact register states regs_exact() compares register values and their ID relationships, but it does not compare frameno. regsafe() checks frameno for ordinary PTR_TO_STACK comparisons, while its EXACT path returns through regs_exact() before reaching that check. Infinite-loop detection can therefore mistake pointers to the same offset in different stack frames for the same pointer and reject a finite loop. Move frameno into bpf_reg_state's type-specific metadata union so the existing regs_exact() prefix comparison covers it. This avoids a separate PTR_TO_STACK case and keeps the structure at 80 bytes. Adjust the states_maybe_looping() comparison boundary for the new layout. Since frameno now aliases other pointer metadata, bpf_func() returns NULL for registers that are not stack pointers; the callers that look up the frame before checking the register type dereference it only afterwards. The selftest keeps a stack pointer live in a register across a loop whose only change at the header is the pointer's frame number. On the unfixed tree, the program is rejected with "infinite loop detected". With the fix, it loads and returns the expected value. Changelog: ---------- v3 -> v4 v3: https://lore.kernel.org/bpf/20260919004327.1403382-1-memxor@gmail.com * Return NULL from bpf_func() for non-stack registers, since frameno now aliases other pointer metadata and some callers look up the frame before checking the register type. (Sashiko) v2 -> v3 v2: https://lore.kernel.org/bpf/20260918011313.3053497-1-memxor@gmail.com * Rebase on bpf/master. * Drop the redundant spilled-pointer test, since existing tests already cover the stacksafe() -> regsafe() path. (Eduard) * Place asm labels on their own line in the selftest. (Eduard) * Collect Acked-by and Tested-by tags. v1 -> v2 v1: https://lore.kernel.org/bpf/20260914161340.3419141-1-memxor@gmail.com * Rebase on bpf/master. * Move frameno into the type-specific metadata union so regs_exact()'s existing prefix comparison covers it without growing bpf_reg_state. ==================== Link: https://patch.msgid.link/20260919014213.1840880-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 070587848985efcfcd45104c5266ba76a1165f55 Author: Kumar Kartikeya Dwivedi Date: Sat Sep 19 03:42:11 2026 +0200 selftests/bpf: Cover frame changes in bounded loops Add a finite loop whose progress is represented only by changing the frame number of a stack pointer. The loop first reads zero from the caller's stack, switches to the same offset in the callee's stack, and exits after reading one on its next iteration. Force frequent checkpoints so the test exercises infinite-loop detection, and check that the program returns one when run. Without the frameno comparison in regs_exact(), the program is rejected with an "infinite loop detected" diagnostic instead of loading successfully. Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Alexei Starovoitov Tested-by: Eduard Zingerman Link: https://patch.msgid.link/20260919014213.1840880-3-memxor@gmail.com commit 8901cee9316d53a5a97398f026c2d59a3043159d Author: Kumar Kartikeya Dwivedi Date: Sat Sep 19 03:42:10 2026 +0200 bpf: Compare stack frames in regs_exact() regs_exact() compares the register state up to id, followed by the ID mappings, but does not compare frameno. The PTR_TO_STACK case in regsafe() checks frameno separately, which is bypassed when exact comparison is requested. Consequently, infinite-loop detection can treat pointers to different stack frames as the same pointer and reject a finite loop. For example, initialize fp-8 to zero in the caller and to one in the callee, then pass the caller's fp-8 to the callee as r1: loop: r0 = *(u64 *)(r1 + 0); if r0 != 0 goto done; r1 = r10; r1 += -8; goto loop; done: exit; The loop terminates after reading the callee's slot on its second iteration. At the loop header, however, the only relevant difference is r1's frameno, so exact comparison incorrectly reports an infinite loop. The same problem occurs when the pointer is spilled to the stack. Move frameno into the type-specific metadata union, ahead of id, so the existing prefix comparison in regs_exact() covers it. Ordinary stack pointers do not use another union member. Iterator and IRQ stack-slot states use their dedicated union views and do not need a frame lookup. This also keeps bpf_reg_state at 80 bytes. Since frameno now shares storage with other pointer metadata, it is only meaningful for PTR_TO_STACK registers. Return NULL from bpf_func() for other register types. process_iter_arg(), get_constant_map_key() and is_dynptr_reg_valid_init() look up the frame before checking the register type and would otherwise index frame[] with a byte of the register's map or BTF pointer. They dereference the frame only after their type check. Move the states_maybe_looping() boundary from frameno to precise after the field relocation. Its prefix comparison continues to cover the complete value state and now includes frameno. Continue to ignore precise. Precision marks control whether pruning may ignore scalar ranges; they do not change the represented values, and exact comparison already compares those ranges unconditionally. Marks can also change through backtracking while an ancestor state is still being explored. Fixes: d5b892fd607a ("bpf: make infinite loop detection in is_state_visited() exact") Reported-by: Eduard Zingerman Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Alexei Starovoitov Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260919014213.1840880-2-memxor@gmail.com commit 63edf5a009ae366369a1b484cd9ae4ee7c51946c Author: Chang S. Bae Date: Wed Sep 16 23:00:03 2026 +0000 x86/build/64: Prevent native builds from generating EGPR use Omar reports that CONFIG_X86_NATIVE_CPU=y allows builds to opportunistically emit instructions using %r16-%r31 (EGPRs) when the build host supports APX since the commit: ea1dcca1de12 ("x86/kbuild/64: Add the CONFIG_X86_NATIVE_CPU option to locally optimize the kernel with '-march=native'") But the kernel is not yet prepared to use new registers internally. For example, there is no context-switch support for general in-kernel use. Explicitly disable EGPR use when building with -march=native. For C, since GCC 14 and Clang 18, both compilers support suppressing EGPR use with -mno-apx-features=egpr, whose availability can be detected via cc-option. For Rust, pass features=-apxf through the generated JSON to avoid unstable-feature warnings, see https://github.com/rust-lang/rust/issues/139284 Note Rust only accepts the option to disable APX instructions entirely or not. Support for this gating also depends on the Rust/LLVM combination. Rust 1.88 introduced the `apxf` feature option, but versions prior to 1.93 may emit an `apxf` attribute to the backend that only LLVM 23 or later can interpret. Restrict native Rust builds accordingly. Fixes: ea1dcca1de12 ("x86/kbuild/64: Add the CONFIG_X86_NATIVE_CPU option to locally optimize the kernel with '-march=native'") Reported-by: Omar Avelar Signed-off-by: Chang S. Bae Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Nathan Chancellor Acked-by: Miguel Ojeda Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260916230003.1144622-1-chang.seok.bae@intel.com commit 10396a2d6d41d594975b6ece712278570c3c970c Author: Holger Dengler Date: Fri Aug 14 16:20:10 2026 +0200 crypto: s390/hmac - Generate intermediate CV for API partial block handling The API partial block handling requires a intermediate chaining value (CV). The internal function hash_data() sets the function code correctly, so also call cpacf_kimd() instruction for intermediate CV generation, as cpacf_klmd() always generate the final hash value. Cc: stable@vger.kernel.org # 6.15+ Fixes: 08811169ac01 ("crypto: s390/hmac - Use API partial block handling") Signed-off-by: Holger Dengler Reviewed-by: Harald Freudenberger Signed-off-by: Herbert Xu commit 6c096bb08de97cdca051fecddad22cac6a1fd275 Author: Quentin Armitage Date: Tue Sep 15 22:33:21 2026 +0100 net: allow IFLA_INET_CONF messages when NLA_F_NESTED unset Commit fa8fca88714c ("ipv4: validate IPV4_DEVCONF attributes properly") added validation of IFLA_INET_CONF attributes, and in the process changed the call of nla_for_each_nested() to nla_parse_nested(). A side effect of this change is that the IFLA_INET_CONF option is now tested for NLA_F_NESTED being set, and fails if it is not. Prior to the commit there was no check of NLA_F_NESTED. Change nla_parse_nested() to nla_parse(). This restores the previous functionality of not checking NLA_F_NESTED, thereby allowing code that (incorrectly) doesn't set NLA_F_NESTED to continue to work. This issue was identified because keepalived started logging errors when it was configuring macvlans that it created. Fixes: fa8fca88714c ("ipv4: validate IPV4_DEVCONF attributes properly") Signed-off-by: Quentin Armitage Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260915213320.1527029-2-quentin@armitage.org.uk Signed-off-by: Jakub Kicinski commit 4581c3d2adc3c73a019bc38db64ca11f28bbd7fd Author: Ralf Lici Date: Thu Sep 17 14:27:23 2026 +0200 net/mlx5e: advertise MACsec offload only when supported Commit 339ccec8d43d ("net/mlx5: Enable MACsec offload feature for VLAN interface") added NETIF_F_HW_MACSEC unconditionally to vlan_features so that VLAN devices could inherit MACsec offload support. mlx5e_build_nic_netdev subsequently copies vlan_features into hw_features and features. As a result, all mlx5e NIC netdevices advertise MACsec hardware offload, even when the firmware does not support it and the driver does not install macsec_ops. Set the MACsec feature bits in mlx5e_macsec_build_netdev, after device capabilities have been validated. This preserves MACsec-over-VLAN support and the ethtool feature control on capable devices, without advertising either on unsupported hardware. Fixes: 339ccec8d43d ("net/mlx5: Enable MACsec offload feature for VLAN interface") Cc: stable@vger.kernel.org Reviewed-by: Tariq Toukan Signed-off-by: Ralf Lici Link: https://patch.msgid.link/20260917122724.654639-1-ralf@mandelbit.com Signed-off-by: Jakub Kicinski commit d2c31b837406395e576afeb25958c98e9938f3f6 Author: Yiqi Sun Date: Tue Sep 15 17:50:17 2026 +0800 sctp: avoid livelock while updating retransmit path sctp_assoc_update_retran_path() can loop forever when every remaining transport, including retran_path, is SCTP_UNCONFIRMED: the state check runs before the wraparound test, so the loop cannot observe that it has completed a full pass. Fix this by considering a transport only when it is not UNCONFIRMED, then checking whether the walk has returned to retran_path. This makes the full-pass termination independent of the transport state while preserving the existing fallback selection semantics. Also restore the NULL guard around the retran_path assignment. In the all-UNCONFIRMED case there is no eligible replacement transport, and installing NULL would leave later retransmit-path users and the debug print with a NULL path. Fixes: 4c47af4d5eb2 ("net: sctp: rework multihoming retransmission path selection to rfc4960") Signed-off-by: Yiqi Sun Acked-by: Xin Long Link: https://patch.msgid.link/20260915095017.942213-1-sunyiqixm@gmail.com Signed-off-by: Jakub Kicinski commit 6c01564da38207b8cd1f86365fabf45963f394b2 Merge: 95c4d54ed02283 1b97a269a5bdde Author: Jakub Kicinski Date: Fri Sep 18 17:20:16 2026 -0700 Merge branch 'eth-fbnic-a-collection-of-fixes' Alexander Duyck says: ==================== eth: fbnic: a collection of fixes This series collects a handful of independent fbnic fixes for issues on released kernels, plus one core ethtool fix needed by the fbnic offline self test. The first patch keeps rtnl_lock held on the ethtool ioctl path for the self test. Since the ioctl path became rtnl-optional for ops-locked drivers, fbnic's offline self test (which brings the interface down and up via netif_close()/netif_open()) runs holding only the instance lock, tripping a lockdep splat / ASSERT_RTNL and reconfiguring the device without the lock it requires. A similar issue was found with Broadcom drivers so we expanded the scope for v2 to just have the rtnl lock held for all selftest calls. The second addresses a comparison issue in that we were limiting the maximum number of standalone Tx queues to one less than the maximum number of Tx queues. To resolve this it was just a matter of replacing a "<" with a "<=". The third addresses an indexing issue with netdev queues on fbnic in which the NAPI vector was assumed to be findable as the Rx index modulo the number of NAPI vectors. However this is actually not the case for if Tx only and Rx only queues are setup. To resolve this we make use of the cached NAPI pointer in the netdev Rx queues themselves. The fourth patch fixes a NULL pointer dereference on unbind after a failed PCIe error recovery: fbnic_pm_suspend() frees the napi vectors via a direct ndo_stop() while leaving netif_running() true, and when slot_reset -> resume fails the data path is never re-allocated. To prevent the panic we reset num_napi to 0 before we free the IRQs which prevents walking the unallocated napi vectors when we unbind the interface later. The last two patches address the FW mailbox. One sets AW_FLUSH_MODE alongside AW_FLUSH when tearing down the Rx ring, so the write pipeline actually drains the staged requests instead of hanging on the BME halt. The other handles completions flagged with FW_ERR on both mailboxes, which the driver previously ignored. This resulted in us parsing a stale Rx page, and spinning the capabilities poll to a timeout on a healthy ring. ==================== Link: https://patch.msgid.link/178941996343.7700.9376081102002673062.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Jakub Kicinski commit 1b97a269a5bdde20d4e69511f27649c9cb82b7c7 Author: Alexander Duyck Date: Mon Sep 14 14:10:33 2026 -0700 eth: fbnic: Handle FW mailbox completions flagged with an error The firmware can complete a mailbox descriptor while also setting FW_ERR to indicate it could not process the request, for example on a mailbox DMA error. The completion carries no valid data. The driver did not check FW_ERR. On the Rx mailbox it would sync and parse the stale page as a normal message, and on the Tx mailbox it silently freed the request. If the initial capabilities exchange in fbnic_mbx_poll_tx_ready() hit FW_ERR -- on the Tx request or on the Rx response descriptor -- no response was parsed and the poll spun until it timed out even though the ring was healthy. Check FW_ERR on both mailboxes. Count it per-mailbox in fbnic_fw_mbx.resp_error, which is also shown in debugfs, warn (rate limited, since the bit is firmware controlled), and drop the Rx page instead of parsing it. In fbnic_mbx_poll_tx_ready() re-issue the capabilities request when either the Tx or the Rx resp_error counter advances, so a FW_ERR on the request or on its response triggers a retry rather than a timeout. A valid capabilities response is honored before the retry check, so a response parsed in the same poll as an unrelated FW_ERR is not discarded. The counters are mailbox-wide rather than keyed to the capabilities request; that is sufficient here because the exchange runs during bring-up before any other mailbox traffic, and any spurious retry is bounded by the existing 10s timeout. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Alexander Duyck Reviewed-by: Simon Horman Link: https://patch.msgid.link/178942023343.7700.9423398932961964439.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Jakub Kicinski commit 8947f13e436a4ff5eed9f8f019b2865a07af4bb2 Author: Alexander Duyck Date: Mon Sep 14 14:10:25 2026 -0700 eth: fbnic: Set AW_FLUSH_MODE alongside AW_FLUSH when flushing the mailbox When tearing down the FW mailbox Rx ring, fbnic_mbx_reset_desc_ring() writes AW_CFG with FLUSH set and everything else, BME included, cleared. Clearing BME halts the device's writes to the host but leaves the staged requests parked in the PUL write pipeline rather than draining them, so on the write path FLUSH alone never terminates the outstanding requests and the flush the firmware waits on never completes. Add the FLUSH_MODE definition and set both bits so the staged writes drain out of the pipeline on their own. BME stays cleared, so nothing lands on the host; it is restored later in fbnic_mbx_init_desc_ring() when the ring is rebuilt, once the outstanding writes are gone. The read path is unaffected. AR_CFG has no equivalent mode bit and AR_FLUSH terminates the outstanding reads by itself, so it is left as is. Both writes remain plain stores rather than read-modify-writes. That is deliberate: the matching write in fbnic_mbx_init_desc_ring() restores BME and the TLP attributes, and clears both flush bits as a side effect. Fixes: 3b12f00ddd08 ("fbnic: Gate AXI read/write enabling on FW mailbox") Signed-off-by: Alexander Duyck Reviewed-by: Simon Horman Link: https://patch.msgid.link/178942022583.7700.11050671998277309744.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Jakub Kicinski commit 4bcc4a92c603fe7f062cea22e20da2e0ad6b12c3 Author: Alexander Duyck Date: Mon Sep 14 14:10:18 2026 -0700 eth: fbnic: reset num_napi when the napi vectors are freed fbn->num_napi is the count of live napi vectors, each of which owns an IRQ. The PM path had freed them without clearing the count. fbnic_pm_suspend() tears the datapath down via ndo_stop() and frees the IRQs, but leaves netif_running() true so resume knows to re-open. Resume rebuilds the datapath in __fbnic_pm_resume() and fbnic_reset_queues() sets num_napi and __fbnic_open() re-allocates the vectors. When the datapath is torn down but never rebuilt, num_napi is left pointing at freed vectors under 2 different scenarios: - a PCIe error recovery that fails (fbnic_err_slot_reset() -> __fbnic_pm_resume() returns an error -> PCI_ERS_RESULT_DISCONNECT), so .resume never runs; or - an __fbnic_open() that fails partway on resume and unwinds, freeing the vectors after fbnic_reset_queues() has already set num_napi. The netdev is then running with num_napi > 0 but napi[] freed, and the eventual remove/unbind close re-enters fbnic_down() -> fbnic_dbg_down() and dereferences the freed vectors: BUG: kernel NULL pointer dereference, address: 0000000000000210 RIP: fbnic_dbg_down+0x28 Clear num_napi when the vectors are freed: in the suspend teardown (a good resume re-establishes it before __fbnic_open()) and on the resume open failure. A redundant ndo_stop() then walks an empty napi[]. The normal ndo_stop() down/up cycle is untouched and keeps num_napi for the next ndo_open(). Fixes: bc6107771bb4 ("eth: fbnic: Allocate a netdevice and napi vectors with queues") Signed-off-by: Alexander Duyck Reviewed-by: Simon Horman Link: https://patch.msgid.link/178942021809.7700.10804028989308077839.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Jakub Kicinski commit b5d9e9d4d0c13bc8b60d8d97e7a07fb25fea639e Author: Alexander Duyck Date: Mon Sep 14 14:10:11 2026 -0700 eth: fbnic: use the Rx queue napi pointer to find the napi vector The queue management ndos pick the napi vector for an Rx queue with: nv = fbn->napi[idx % fbn->num_napi]; The issue is this is only correct in the cases where there are no standalone Tx vectors. In those cases we were allocating the Tx vectors first and then the Rx so the queues would be pointing to Tx NAPI vectors instead of the Rx ones. The mapping the ndos want is already recorded. fbnic_set_netif_napi() publishes it with netif_queue_set_napi(), which stores the napi pointer in netdev_rx_queue.napi, and fbnic_reset_netif_napi() clears it again. Both run under the netdev instance lock that the queue management ndos also hold, so the pointer can be read directly. Use it and drop the divide. The pointer is NULL exactly while the datapath is down, so fbnic_queue_mem_alloc() can reject that case rather than reaching into freed state: netdev_rx_queue_restart() calls it before it tests netif_running(), and fbnic_pm_suspend() leaves netif_running() true across a PCIe recovery that never completes, so a queue restart can arrive after fbnic_stop() has freed the rings and the vectors. fbnic_stop() clears the association in fbnic_reset_netif_queues() before fbnic_free_napi_vectors(), so the NULL is always published first. fbnic_queue_start() and fbnic_queue_stop() need no check of their own, as netdev_rx_queue_reconfig() only reaches them once fbnic_queue_mem_alloc() has succeeded under the same instance lock. Fixes: da43127a8edc ("eth: fbnic: support queue ops / zero-copy Rx") Signed-off-by: Alexander Duyck Reviewed-by: Simon Horman Link: https://patch.msgid.link/178942021136.7700.4391219358260544104.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Jakub Kicinski commit 1f4c73064a50f53d596c6f1d06d2d700f43c4b32 Author: Björn Töpel Date: Mon Sep 14 14:10:04 2026 -0700 eth: fbnic: Handle maximum standalone channels Standalone channels use one NAPI vector for each Tx and Rx queue. fbnic's allocation path excludes FBNIC_MAX_TXQS from that layout. A 64-Tx/64-Rx configuration therefore records 128 vectors but allocates only 64, leaving NULL entries that resource setup dereferences. Include the maximum vector count in standalone allocation. Fixes: bc6107771bb4 ("eth: fbnic: Allocate a netdevice and napi vectors with queues") Signed-off-by: Björn Töpel Reviewed-by: Simon Horman Link: https://patch.msgid.link/178942020457.7700.13129750616387075931.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Jakub Kicinski commit 1b82958f3f035df5ccaab5430a2302f08a5d5351 Author: Alexander Duyck Date: Mon Sep 14 14:09:57 2026 -0700 net: ethtool: keep rtnl_lock for the ioctl self test An offline self test that brings the interface down and back up with netif_close() / netif_open() requires rtnl_lock for both. Since the ethtool IOCTL path became rtnl-optional for ops-locked drivers, the ETHTOOL_TEST ioctl runs holding only the netdev instance lock, so on an ops-locked driver the self test now tears the device down without rtnl_lock. With lockdep this reproduces deterministically on every offline self test on such a driver; note the sole lock held is the instance lock, not rtnl: WARNING: suspicious RCU usage net/core/netpoll.c:207 suspicious rcu_dereference_protected() usage! 1 lock held by ethtool/107: #0: (&dev->lock){+.+.}, at: dev_ethtool Call Trace: netpoll_poll_disable __dev_close_many netif_close_many netif_close fbnic_self_test dev_ethtool_locked dev_ethtool dev_ioctl sock_ioctl __x64_sys_ioctl Without lockdep the same condition trips ASSERT_RTNL() in __dev_close_many() / __dev_open(); that check only samples the global rtnl state, so it can be masked by a concurrent rtnl holder, but the device is still being reconfigured without the lock it requires. The ethtool self_test is a legacy ioctl-only command, so an ETHTOOL_TEST case is only needed on the ioctl path. Add an opt-in bit for drivers whose self test needs rtnl_lock and set it on the ops-locked drivers whose offline self test tears the interface down and up: - fbnic (ops-locked via queue_mgmt_ops): fbnic_self_test() offline path uses netif_close() / netif_open(). - bnxt (ops-locked via queue_mgmt_ops): bnxt_self_test() offline path goes through bnxt_close_nic() / bnxt_half_open_nic() / bnxt_half_close_nic() / bnxt_open_nic(), which close and reopen the device. Fixes: f994752b1127 ("net: ethtool: optionally skip rtnl_lock on IOCTL path") Signed-off-by: Alexander Duyck Reviewed-by: Simon Horman Link: https://patch.msgid.link/178942019771.7700.338431553546884773.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Jakub Kicinski commit 95c4d54ed02283e9a09e8cd7360e384daa67a741 Author: Abhishek Ojha Date: Wed Sep 16 19:19:28 2026 -0400 net: phy: micrel: Advance register data pointer in write loop lanphy_write_reg_data() does not advance the data pointer while iterating over the register table. As a result, it writes the first entry num times and leaves the remaining errata registers unconfigured. Single-entry tables are unaffected, but tables with multiple entries leave every entry after the first unapplied. Advance the data pointer after each successful write so every table entry is applied in order. Fixes: c8732e933925 ("net: phy: micrel: lan8842 errata") Cc: stable@vger.kernel.org Signed-off-by: Abhishek Ojha Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260916231928.1336305-1-abhishek.ojha@savoirfairelinux.com Signed-off-by: Jakub Kicinski commit dd47bcf279f1083f09bf5266890b26263361022b Author: Kuniyuki Iwashima Date: Wed Sep 16 23:09:24 2026 +0000 ip6_gre: Call ip6erspan_tunnel_unlink_md() in ip6erspan_changelink(). The cited commit accidentally added ip6gre_tunnel_unlink_md() in ip6erspan_changelink(). Let's correct it to ip6erspan_tunnel_unlink_md(). Fixes: b80d0b93b991 ("net: ip6_gre: fix tunnel metadata device sharing.") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Xuanqiang Luo Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260916230927.378957-1-kuniyu@google.com Signed-off-by: Jakub Kicinski commit ee319bd3a0e976af5087cbe59ebc50a66f31d202 Author: Norbert Szetei Date: Wed Sep 16 21:57:53 2026 +0200 ipv6: do not let ipv6_find_hdr() return an offset past the packet end ipv6_find_hdr() walks the extension header chain, skipping each header by the length that header itself declares. ipv6_optlen() returns up to 2048, and the skip is never checked against skb->len, so the offset stored in *offset can point past the end of the packet. openvswitch installs that offset as the transport header, and update_ipv6_checksum() then reads and writes the transport checksum field out of bounds: BUG: KASAN: slab-use-after-free in inet_proto_csum_replace16+0x445/0x470 Read of size 2 at addr ffff88810b754b06 by task ovs_ipv6_oob/629 CPU: 4 UID: 1000 PID: 629 Comm: ovs_ipv6_oob Tainted: G N 7.3.0-rc3+ #348 Call Trace: inet_proto_csum_replace16+0x445/0x470 set_ipv6_addr+0x3dd/0x460 do_execute_actions+0x6a3d/0x7c40 ovs_execute_actions+0xfd/0x480 ovs_packet_cmd_execute+0xc38/0xf20 genl_rcv_msg+0x59e/0x870 netlink_rcv_skb+0x18b/0x450 genl_rcv+0x2d/0x40 netlink_unicast+0x6bc/0xa20 The buggy address belongs to the object at ffff88810b754980 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 390 bytes inside of freed 704-byte region [ffff88810b754980, ffff88810b754c40) Other callers use that offset too, so bound it here rather than in one caller. Reject a header whose declared length does not fit in the packet. ipv6_find_hdr() already fails with -EBADMSG on a malformed chain, so this adds no new failure mode. Fixes: f8f626754ebe ("ipv6: Move ipv6_find_hdr() out of Netfilter code.") Suggested-by: Ilya Maximets Suggested-by: Eric Dumazet Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Reviewed-by: Ido Schimmel Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/8F80BA1A-DDFD-432D-9075-242A3435FEB5@doyensec.com Signed-off-by: Jakub Kicinski commit 24fedc7a569bce181728f0dd616504bef9f1513b Author: Andy Moreton Date: Wed Sep 16 13:56:41 2026 +0100 sfc: add X4D PF support X4D is an X4 controller instance as an IP block in an SoC. It has the same feature set as X4. Signed-off-by: Andy Moreton Reviewed-by: Pieter Jansen van Vuuren Reviewed-by: Alejandro Lucero Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260916125641.12238-1-alucerop@amd.com Signed-off-by: Jakub Kicinski commit 310d1ac61a4d5a2ca8356a3a48d263acf54503ce Author: Lorenzo Bianconi Date: Wed Sep 16 15:30:13 2026 +0200 net: ethernet: mtk_eth_soc: unregister net_devices in case of probe failure If register_netdev() fails for one of the MTK_MAX_DEVS devices in mtk_probe(), the error path jumps to err_deinit_ppe, skipping mtk_unreg_dev(). The previously registered net_devices are then freed by mtk_free_dev() while still in NETREG_REGISTERED state, hitting the BUG_ON(dev->reg_state != NETREG_UNREGISTERED). Route the register_netdev() failure to err_unreg_netdev so the net_devices registered so far are properly unregistered before being freed. Fixes: 8a8a9e89f801 ("net: ethernet: mediatek: cleanup error path inside mtk_hw_init") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260916-mtk_eth_soc-netdev-fix-v1-1-5dac50eb65b1@oss.qualcomm.com Signed-off-by: Jakub Kicinski commit 2566866fc30965d915d0b52b5c3323b362619f0e Author: Jérémy Jean Date: Tue Sep 15 12:48:07 2026 +0000 net: gue: reject invalid REMCSUM offsets The REMCSUM option carries an absolute checksum start and checksum field offset. gue_remcsum() passes them to skb_remcsum_process(), whose partial path stores offset - start in the u16 skb->csum_offset variable. If offset is less than start, this underflows. A forwarded packet can retain CHECKSUM_PARTIAL and reach a NETIF_F_HW_CSUM driver which trusts the metadata, leading skb_copy_and_csum_dev() to write two bytes about 64 KiB beyond the destination buffer. Reject reversed tuples in validate_gue_flags(), after the existing length validation, so all GUE parsers enforce the ordering in one place. Fixes: fe881ef11cf0 ("gue: Use checksum partial with remote checksum offload") Signed-off-by: Jérémy Jean Link: https://patch.msgid.link/20260915124806.2852293-2-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Jakub Kicinski commit 40288c9206c17eb66a603262e06a58d300d0f279 Merge: 17e7b8eacf4cac 71f370e9ee1bdf Author: Linus Torvalds Date: Fri Sep 18 16:37:37 2026 -0700 Merge tag 'drm-fixes-2026-09-19' of https://gitlab.freedesktop.org/drm/kernel Pull drm fixes from Dave Airlie: "Things have picked back up a bit this week, mostly amdgpu, xe and msm this time. There are a bunch of scattered changes across the rest of drivers and core stuff, nouveau, i915. core: - fix vblank pending event leak ttm: - swapout fixes dma-buf: - scattergather fixes - enable dma-buf debug on debug kernels dma-fence: - fix signaling bit checks sched: - fix virtual runtime race msm: - DT: - Corrected indentation - Core: - Marked fbdev as system memory - GPU: - Fixed autosuspend cleanup on teardown - a750: fix timestamps - Increase GMU fw init timeout - Misc fixes/cleanups - DPU: - Fixed clock rounding, unbreaking newest platforms - Cleared pending flush state - DP: - Skip PUSH_IDLE when link was never enabled - Fixed bandwidth checks - HDMI: - Fixed runtime PM cleanup on probe failure xe: - shrinker related fixes - xe_mmio_gem fault handler and destroy fixes - xe disable i2c irq on unbind i915: - Revert a commit touching registers that don't necessarily exist - Check for negative numbers before passing to BIT() amdgpu: - SMU 14.x fix - DC IRQ fix - Runtime PM fix for P2P - RAS fix - PCIe reporting fix - DCN 6 fix - Device removal fix - DC MALL fix amdkfd: - GC 12.x fixes - Boundary checks - Mapping clear fix nouveau: - suspend/resume fixes gud: - out of bounds access fix - ignore damage clips in full update vc4: - use-after-free fix versilicon: - plane format fix longsoon: - blend mode property fix" * tag 'drm-fixes-2026-09-19' of https://gitlab.freedesktop.org/drm/kernel: (59 commits) drm/amd/display: fix MALL hysteresis timer underflow at high refresh rates drm/amdgpu: fix rmmio iounmap skipped on device removal drm/amdgpu: Skip KFD mapping clear before initialization drm/amd/display: Fix NULL dereference in dcn50/dcn60 init_hw drm/amdkfd: Avoid integer underflow in EOP ring size calculation. drm/amdkfd: Avoid integer underflow with ffs in EOP ring size calc drm/amdgpu: Fix GPU PCIe link capability reporting drm/amdgpu: check ras and obj before dereference drm/amdgpu: hold a runtime PM reference for P2P dma-buf attachments drm/amdkfd: implement restore_mqd callbacks for GFX12/12.1 drm/amd/display: Atomize IRQ register read/modify/write ops drm/amd/pm: report energy accumulator for smu 14.0.3 drm/loongson: Create blend mode property for cursor plane drm/xe/i2c: Disable IRQ on unbind Revert "drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable" drm/verisilicon: remove ARGB formats from primary plane drm/verisilicon: add primary modifier for format tables drm/verisilicon: set blend mode for the cursor plane drm/sched: Fix virtual runtime race drm/i915/display: check configuration index before shifting ... commit 47abe7a5c4eb53269aca3506446f851572a059a3 Author: Nguyen Ngoc Thang Date: Tue Sep 15 22:08:16 2026 +0700 net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure flow_offload_alloc() returns NULL when the conntrack entry is dying (e.g. raced with a conntrack flush) or when the GFP_ATOMIC allocation fails; both are expected under load and neither is a kernel bug. This path runs from softirq on every committed packet, so with panic_on_warn=1 an unprivileged user can panic the box just by racing a conntrack flush against a `tc ... action ct commit` classifier. Reproduced with a custom repro under QEMU: a small, fixed set of UDP flows through `tc filter ... action ct commit` on lo, raced against threads flooding bare ctnetlink CT_DELETE (flush) requests. Hits WARNING: net/sched/act_ct.c:437 (tcf_ct_flow_table_add(), inlined into tcf_ct_act() in this build) within ~15s on the unpatched kernel; same setup is clean on the patched kernel. The fix itself is behavior-preserving: both branches already did `goto err_alloc` before and after, only the WARN is removed. Fixes: 64ff70b80fd4 ("net/sched: act_ct: Offload established connections to flow table") Reported-by: syzbot+6cc37aba98dac721c415@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6cc37aba98dac721c415 Signed-off-by: Nguyen Ngoc Thang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260915150816.36487-1-ngocthang2710.1999@gmail.com Signed-off-by: Jakub Kicinski commit 99cc2a62e07a44a22254d7beca9ef1f8ad886d0d Author: Eric Dumazet Date: Sun Sep 13 04:42:33 2026 +0000 tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers underflow Commit 48a5fe38772b ("tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG") rejected duplicate/stale ACKs in tipc_group_proto_rcv() by returning early when less_eq(acked, m->bc_acked). However, that check remains incomplete in two ways: 1. When grp->bc_ackers is zero (e.g. on a quiet group, when replicast ACKs were not requested, or after all expected members have already acknowledged), an unexpected GRP_ACK_MSG with acked > m->bc_acked passes less_eq() and unconditionally decrements grp->bc_ackers. Because bc_ackers is a u16, this wraps to 65535, causing tipc_group_bc_cong() to permanently report congestion and blocking all future group broadcasts on the socket. 2. During an active broadcast round (grp->bc_ackers > 0), the sender transmits packet S and advances grp->bc_snd_nxt to S + 1. Receivers increment their expected counter to S + 1 upon consuming packet S, so the only valid ACK value for the current round is strictly acked == grp->bc_snd_nxt. However, tipc_group_update_bc_members() initializes each member's m->bc_acked to prev = grp->bc_snd_nxt - 1 (S - 1 before increment). This leaves a 2-sequence gap (S - 1 to S + 1) in sequence space. An incoming ACK is therefore neither rejected as duplicate nor prevented from decrementing grp->bc_ackers if an unexpected or stale value (such as S) is received. A member sending acked = S followed by acked = S + 1 could decrement grp->bc_ackers twice in the same round, prematurely clearing bc_ackers or underflowing it. Fix this by: - Dropping GRP_ACK_MSG immediately if grp->bc_ackers is zero. - Requiring acked == grp->bc_snd_nxt and rejecting duplicates where m->bc_acked == acked. Because replicast broadcast rounds are strictly sequential, only grp->bc_snd_nxt can be acknowledged, and each member can acknowledge at most once per round. Note that a related pre-existing issue in tipc_group_delete_member() (where grp->bc_ackers decrementing to zero upon member departure does not restore *grp->open or trigger a socket wakeup) will be addressed in a separate patch. Fixes: 48a5fe38772b ("tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG") Fixes: 2f487712b893 ("tipc: guarantee that group broadcast doesn't bypass group unicast") Reported-by: James Burton Cc: stable@vger.kernel.org Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260913044233.193927-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit 71f370e9ee1bdfe1f916547089d93b5265a918e7 Merge: 94f69bfa1897c9 5535d5e61a77ad Author: Dave Airlie Date: Sat Sep 19 06:48:28 2026 +1000 Merge tag 'drm-misc-fixes-2026-09-17' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Two ttm fixes for ttm_tt_swapout(), one page-alignment and one overflow fix for dma-buf, a drm_pending_vblank_event leak fix for drm, suspend/resume fixes for nouveau, one out-of-bounds access fix for gud, a use-after-free fix for vc4, a fence signaling fix, a race condition fix for sched, planes formats fixes for verisilicon, and add the blend mode property for loongson Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patch.msgid.link/aqvVENQ4ksJEIcdb@houat commit 17e7b8eacf4cac800a4fc89a28729df72a2dabda Merge: 925724c0816e32 717e0a25036b6c Author: Linus Torvalds Date: Fri Sep 18 13:44:59 2026 -0700 Merge tag 'cifs-fixes-7.3-rc4' of https://git.manguebit.org/linux Pull smb client fixes from Paulo Alcantara: "A batch of bug fixes for the smb client: - Fix multiple out-of-bounds reads and use-after-frees in the SMB2/3 receive path that are reachable from a malicious or compromised server: a stale next_buffer pointer and an integer overflow in compound encrypted frame handling, missing minimum-PDU-size and per-sub-PDU length validation before parsing command-specific response fields, missing bounds checks in DFS referral, server interface list, EA list, POSIX SID, snapshot enumeration and SMB1 reparse point parsing - Fix use-after-frees and races in multichannel and connection teardown, including an interface freed while still in use when adding channels, a server used after its channel reference was dropped, a reconnect work item left queued after the server is freed and an uninitialized reconnect list node - Fix a heap overflow in the native symlink parser: an absolute target without an NT drive prefix caused out-of-bounds writes and a u16 length underflow leading to a 64K memcpy into a small buffer, triggerable by a user with write access to a mounted share under default settings - Fix WSL reparse point parsing: use unaligned accessors for the packed extended-attribute payload to avoid alignment faults on some architectures and stop leaving partially mutated fattr fields on parse failure - Fix lease break ACKs being sent through the wrong session on multiuser mounts, which caused read failures (e.g. on NetApp ONTAP/Azure Files) when copying files - Fix an smbd_connection leak when cifs_get_tcp_session() fails after an RDMA connection was already established" * tag 'cifs-fixes-7.3-rc4' of https://git.manguebit.org/linux: cifs: Fix server use-after-free in cifs_chan_skip_or_disable() smb: client: fix reparse buffer bounds in cifs_query_reparse_point() smb: client: fix potential OOB read in smb3_enum_snapshots() smb: client: fix missing iov bounds check in parse_posix_sids() smb: client: fix OOB struct field reads in move_smb2_ea_to_cifs() smb: client: reject short Next offsets in parse_server_interfaces() smb: client: fix missing lower-bound check on DFS referral string offsets smb: client: fix server->total_read for compound encrypted PDUs smb: client: validate minimum PDU size before smb2_get_data_area_len() smb: client: fix next_buffer UAF and NextCommand bounds in compound PDUs smb: client: fix use-after-free of iface in cifs_try_adding_channels() smb: client: fix fattr leaking on wsl_to_fattr() failure smb: client: fix unaligned access in WSL reparse point parser smb: client: fix smbd_connection leak on cifs_get_tcp_session() error smb: client: fix rlist race and missing initialization smb: client: cancel reconnect work in clean_demultiplex_info() smb/client: send lease break ACKs thru correct session for multiuser mounts smb: client: validate absolute native symlink targets before NT fixups commit 8805840aad73df7146778be243a196d48b4f6430 Author: Angel J Date: Fri Sep 18 14:55:40 2026 -0500 PCI: of_property: Omit bus properties without a subordinate bus A bridge (a device with a Type 1 header) may not have a secondary bus allocated (pdev->subordinate), e.g., if there are no available bus numbers or the bridge secondary/subordinate bus numbers are not writable. The dynamic OF helpers of_pci_prop_bus_range() and of_pci_prop_intr_map() dereference pdev->subordinate without checking it. When CONFIG_PCI_DYNAMIC_OF_NODES is enabled, this can cause a NULL pointer dereference and early boot hang. Generate 'bus-range' and 'interrupt-map' properties only when a subordinate bus exists. Keep the node and its remaining properties for bridges without one. The problem was latent since 407d1a51921e ("PCI: Create device tree node for bridge"), but wasn't reachable until 1f340724419e ("PCI: of: Create device tree PCI host bridge node"), which appeared in v6.15. Before 1f340724419e, of_pci_make_dev_node() returned early because the parent OF node was missing. Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") Signed-off-by: Angel J [bhelgaas: move pdev->subordinate test to callees, commit log] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v6.6+ Link: https://patch.msgid.link/20260918195540.GA1187209@bhelgaas commit 925724c0816e327b6d3a47388cec1203d108ebe7 Merge: ef31d04b6d8adf 3d676e458fe0c5 Author: Linus Torvalds Date: Fri Sep 18 13:10:29 2026 -0700 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Four driver fixes, three of which are minor and one of which (fnic) tries to add some logic to try to avoid MSI-X being ineffective if hyperthreading is disabled. The core fix adds validation to mode sense buffer sizes because it is used by ATA and could, theoretically, be exploited by a specially crafted USB device that can simply be plugged in to any laptop or server" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: core: Validate MODE SENSE lengths in scsi_cdl_enable() scsi: fnic: Fix missed link-up when critical IRQ targets offline CPU scsi: ibmvfc: Add Kconfig dependency to fix link failure when NVME_FC=m scsi: qla2xxx: Fix the ql2xfc2target parameter description scsi: pm80xx: Fix the use_msix, use_tasklet and read_wwn parameter descriptions commit d58384c22739848efe14b34e9586e4f1242f33c0 Author: Liz Fong-Jones Date: Fri Sep 18 03:56:33 2026 +0000 PCI: Fix BAR resize for devices on a root bus pci_do_resource_release_and_resize() releases device BARs that share a bridge window with the BAR being resized, but when the device sits directly on a root bus (pdev->bus->self == NULL) it then skips resource assignment entirely and returns success, leaving the BARs it just released unassigned (IORESOURCE_UNSET). Skipping pbus_reassign_bridge_resources() is correct in that case -- there is no bridge window to adjust -- but the device BARs still have to be reassigned. Before the BAR release was consolidated into the PCI core, this case worked for amdgpu because the driver released the BARs itself and then called pci_assign_unassigned_bus_resources() unconditionally after the resize, which assigns unassigned device BARs also on a root bus. Commit db92e3fef53e ("drm/amdgpu: Remove driver side BAR release before resize") removed that call, so nothing assigns the released BARs anymore. This breaks amdgpu completely on the SolidRun HoneyComb LX2K (NXP LX2160A, arm64, ACPI), where ACPI doesn't expose the Root Port so the GPU endpoint appears directly on a "root bus" of its segment: amdgpu 0004:01:00.0: BAR 0 [mem 0xa400000000-0xa40fffffff 64bit pref]: releasing amdgpu 0004:01:00.0: BAR 2 [mem 0xa410000000-0xa4101fffff 64bit pref]: releasing amdgpu 0004:01:00.0: sw_init of IP block failed -19 amdgpu 0004:01:00.0: amdgpu_device_ip_init failed amdgpu 0004:01:00.0: Fatal error during GPU init No error is logged because the resize path reports success; amdgpu then finds BAR 0 IORESOURCE_UNSET and bails out with -ENODEV. When there is no upstream bridge, call pci_bus_assign_resources() on the root bus to place the BARs released above, using the same alignment-sorted algorithm as normal enumeration instead of a manual per-BAR loop. This also walks the rest of the hierarchy under the root bus, as pci_assign_unassigned_bus_resources() used to for amdgpu before commit db92e3fef53e ("drm/amdgpu: Remove driver side BAR release before resize") removed that call -- the core-side fix that commit asked for ("such a problem should be fixed inside pci_resize_resource() instead"). pci_bus_assign_resources() returns void, so failure is detected by checking whether the released BARs are still assigned afterward; if not, roll back as in the bridged case. This is stricter than the bridged path -- it fails on any unplaced resource, not just required ones -- since a root bus typically has one shared window, and failing loudly seemed better than leaving something silently unassigned. The root bus path also had a locking bug that any fix here necessarily touches: the old "goto out" jumped to up_read(&pci_bus_sem) without a matching down_read() (as does the "goto restore" taken when pci_dev_res_add_to_list() fails in the release loop). Take pci_bus_sem before the BAR release loop so every path through the function holds it exactly once. Fixes: 337b1b566db0 ("PCI: Fix restoring BARs on BAR resize rollback path") Link: https://bugs.launchpad.net/ubuntu/+source/linux-hwe-7.0/+bug/2159596 Suggested-by: Ilpo Järvinen Assisted-by: Claude:claude-fable-5 checkpatch Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Liz Fong-Jones [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260918035633.566823-1-lizf@honeycomb.io commit ef31d04b6d8adfc971fc6b9ff76a1d6dc9aeefab Merge: c3d85c669d0900 c9dc7d730319ad Author: Linus Torvalds Date: Fri Sep 18 12:16:25 2026 -0700 Merge tag 'pci-v7.3-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fix from Bjorn Helgaas: - Enable clock after core reset is asserted to fix enumeration regression on i.MX6Q Apalis platforms with ASM1061/ASM1062 SATA controllers (Richard Zhu) * tag 'pci-v7.3-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: imx6: Move clock enable after core reset assertion commit 1717fcc5be575d4768279148ae9465a8b13d4339 Author: Giuseppe Ranieri Date: Thu Sep 17 21:51:14 2026 +0000 drm/nouveau/disp: don't reject HDMI config on cards without SCDC nv50_hdmi_enable() passes the sink's SCDC capability from its EDID straight through to nvif_outp_hdmi(). On pre-Maxwell-2 cards there is no hdmi->scdc callback, so nvkm_uoutp_mthd_hdmi() rejects the whole configuration with -EINVAL, and nv50_hdmi_enable() returns before hdmi->ctrl() runs and before the AVI and VSI infoframes are sent. The result on such a card driving an SCDC-capable HDMI 2.0 sink is that HDMI audio silently stops working. Video is unaffected, and nothing is logged, which makes the failure hard to attribute. SCDC is optional, and the hdmi->scdc() call further down is already guarded against a missing callback. Requesting it on a card that cannot do it need not invalidate the rest of the HDMI configuration, so drop that term from the condition and let the existing guard skip SCDC alone. Fixes: 6c6abab20b99 ("drm/nouveau/disp: add output hdmi config method") Signed-off-by: Giuseppe Ranieri Co-Authored-By: Tano Dzhinski Signed-off-by: Tano Dzhinski Tested-by: Tano Dzhinski Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260917215114.1136715-1-tano.dzhinski@gmail.com commit 6a6870d3077faa501ca97760057ddca22b68418d Author: Peiyang He Date: Fri Sep 18 10:53:12 2026 +0800 drm/nouveau: don't bump pin count on failed re-pin in nouveau_bo_pin_locked() nouveau_bo_pin_locked() checks whether an already pinned BO is in a memory domain compatible with a new pin request. When the domains are incompatible, it sets -EBUSY but still calls ttm_bo_pin() before returning. Callers treat a failed nouveau_bo_pin() as not having acquired a new pin, so the extra pin count is never decreased by a matching unpin. This triggers the warning in ttm_bo_release(): WARN_ON_ONCE(bo->pin_count); Found when fuzzing the nouveau driver with a modified Syzkaller: WARNING: drivers/gpu/drm/ttm/ttm_bo.c:256 at ttm_bo_release+0x827/0x9e0 drivers/gpu/drm/ttm/ttm_bo.c:256, CPU#1: syz.3.24/2212 Modules linked in: CPU: 1 UID: 0 PID: 2212 Comm: syz.3.24 Not tainted 7.2.0 #24 PREEMPT(lazy) nouveau 0000:01:00.0: gsp:msg fn:103 len:0x40/0x20 res:0x19 resp:0x19 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:ttm_bo_release+0x827/0x9e0 drivers/gpu/drm/ttm/ttm_bo.c:256 Code: 02 00 0f 85 51 01 00 00 48 8b 7b 08 e8 d2 20 01 00 e9 80 fd ff ff e8 d8 15 c0 fe 90 0f 0b 90 e9 e1 f8 ff ff e8 ca 15 c0 fe 90 <0f> 0b 90 e9 a4 f8 ff ff e8 bc 15 c0 fe be 03 00 00 00 4c 89 e7 e8 msg: 00000000: 05 00 d0 c1 04 00 f0 f1 01 30 00 00 2d 90 00 00 .........0..-... RSP: 0018:ffffc9000f5cf710 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888018e5d2a8 RCX: ffffffff82bb1b36 RDX: ffff888017b68000 RSI: 0000000000000004 RDI: ffff888018e5d2a8 msg: 00000010: 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ RBP: ffff88801261c720 R08: 0000000000000001 R09: ffffed10031cba55 R10: ffff888018e5d2ab R11: 00000000000000f3 R12: ffff888018e5d290 R13: ffff888018e5d2d4 R14: ffff88801b219c18 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880e0f6f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31223ffc CR3: 0000000028e00005 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: kref_put include/linux/kref.h:65 [inline] ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:325 [inline] ttm_bo_fini+0x55/0x80 drivers/gpu/drm/ttm/ttm_bo.c:330 nouveau_gem_object_del+0xb2/0x1b0 drivers/gpu/drm/nouveau/nouveau_gem.c:90 drm_gem_object_free+0x5f/0x90 drivers/gpu/drm/drm_gem.c:1165 kref_put include/linux/kref.h:65 [inline] __drm_gem_object_put include/drm/drm_gem.h:562 [inline] drm_gem_object_put include/drm/drm_gem.h:575 [inline] nouveau_abi16_chan_fini.constprop.0+0x44f/0x5a0 drivers/gpu/drm/nouveau/nouveau_abi16.c:195 nouveau 0000:01:00.0: syz.2.23[2209]: Unknown handle 0x00000000 nouveau_abi16_fini+0x1d0/0x340 drivers/gpu/drm/nouveau/nouveau_abi16.c:225 nouveau_drm_postclose+0x18b/0x3e0 drivers/gpu/drm/nouveau/nouveau_drm.c:1284 nouveau 0000:01:00.0: syz.2.23[2209]: validate_init drm_file_free.part.0+0x6d6/0xb60 drivers/gpu/drm/drm_file.c:267 drm_file_free drivers/gpu/drm/drm_file.c:237 [inline] drm_close_helper.isra.0+0x11a/0x160 drivers/gpu/drm/drm_file.c:290 drm_release+0x1ab/0x330 drivers/gpu/drm/drm_file.c:438 __fput+0x39c/0xa60 fs/file_table.c:512 nouveau 0000:01:00.0: syz.2.23[2209]: validate: -2 task_work_run+0x15a/0x230 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x82b/0x25a0 kernel/exit.c:1009 do_group_exit+0xc2/0x280 kernel/exit.c:1152 get_signal+0x1d6e/0x1f30 kernel/signal.c:3046 arch_do_signal_or_restart+0x7d/0x6e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:66 [inline] exit_to_user_mode_loop+0xdf/0x440 kernel/entry/common.c:101 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline] do_syscall_64+0x4f8/0x690 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f12bac8594d Code: Unable to access opcode bytes at 0x7f12bac85923. RSP: 002b:00007f12b96e70d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: 0000000000000001 RBX: 00007f12baf15fa8 RCX: 00007f12bac8594d RDX: 00000000000f4240 RSI: 0000000000000081 RDI: 00007f12baf15fac RBP: 00007f12baf15fa0 R08: 00007f12baee8000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f12baf16038 R14: 0000000000000006 R15: 00007ffe2ed394b0 irq event stamp: 47867 hardirqs last enabled at (47883): [] __up_console_sem+0x66/0x70 kernel/printk/printk.c:347 hardirqs last disabled at (47892): [] __up_console_sem+0x4b/0x70 kernel/printk/printk.c:345 softirqs last enabled at (47880): [] __do_softirq kernel/softirq.c:656 [inline] softirqs last enabled at (47880): [] invoke_softirq kernel/softirq.c:496 [inline] softirqs last enabled at (47880): [] __irq_exit_rcu+0x137/0x1c0 kernel/softirq.c:735 softirqs last disabled at (47875): [] __do_softirq kernel/softirq.c:656 [inline] softirqs last disabled at (47875): [] invoke_softirq kernel/softirq.c:496 [inline] softirqs last disabled at (47875): [] __irq_exit_rcu+0x137/0x1c0 kernel/softirq.c:735 Fix by calling ttm_bo_pin() only when the existing placement is compatible with the new pin request. This matches the correct behavior in other DRM drivers such as amdgpu_bo_pin() in amdgpu. Cc: stable@vger.kernel.org Fixes: ad76b3f7c7a0 ("drm/nouveau: teach nouveau_bo_pin() how to force a contig vram allocation") Signed-off-by: Peiyang He Assisted-by: LLM Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/EACEF2F4E098413F+20260918025312.2814889-1-peiyang_he@smail.nju.edu.cn commit e5cccdafc855cd5f96f4b51d38114a0360b075d7 Author: Francesco Magazzu Date: Fri Sep 18 15:16:20 2026 +0200 drm/nouveau/clk: don't clobber reclock status when restoring volt/fan nvkm_cstate_prog() reuses 'ret' for the voltage and fan-speed restore calls it makes after reprogramming the clocks. Those calls almost always succeed, so the status of the reclock itself is overwritten and the function reports success even when clk->func->calc() or clk->func->prog() failed. The converse is also true: a successful reclock is reported as an error if the final restore call fails, even though that failure is only logged and otherwise ignored. The only consumer of the return value is the error message in nvkm_pstate_work(), so in practice a failing reclock is simply never reported. Nothing else changes, but a function that returns success on failure is a trap for the next caller. Keep the calc/prog status in 'ret' and use a separate local for the restore calls. Fixes: 3eca809b3c05 ("drm/nouveau/clk: cosmetic changes") Signed-off-by: Francesco Magazzu Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260918131620.405133-5-postadelmaga@gmail.com commit 7ca7b8b5f2cc89ee843c2eab3272aac5aafb7b73 Author: Francesco Magazzu Date: Fri Sep 18 15:16:19 2026 +0200 drm/nouveau/device: don't use the pstate cursor after the loop nvkm_control_mthd_pstate_attr() looks up the pstate at the index supplied by userspace by walking clk->states, and then keeps using the list_for_each_entry cursor after the loop. This is not triggerable today: the function already rejects args->v0.state >= clk->state_nr before the loop, and clk->state_nr is kept in sync with the number of entries on clk->states, so the lookup always breaks on a real entry. Should the loop ever run to completion, the cursor would point at the list head rather than at a pstate, and the pstate->base.domain[] read and the walk of pstate->list that follow would read past it. Rather than leave that trap in place, track whether the entry was found and return -EINVAL if it was not, like the other lookup failures in this function. No functional change. Signed-off-by: Francesco Magazzu Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260918131620.405133-4-postadelmaga@gmail.com commit 866dbd17c3d5f599b9d93ea9bd5b3d6859ff8350 Author: Francesco Magazzu Date: Fri Sep 18 15:16:18 2026 +0200 drm/nouveau/clk: don't use the pstate cursor after the loop nvkm_pstate_prog() walks clk->states looking for the entry at index 'pstatei' and then keeps using the list_for_each_entry cursor after the loop. This is not triggerable today: every caller clamps the index against clk->state_nr before calling, so the loop always breaks on a real entry. It is safe by virtue of what the callers happen to do, not by anything the function itself checks. Should a caller ever pass an index that is not on the list, the cursor would point at the list head rather than at a pstate, and the pstate->base.domain[] and pstate->fanspeed accesses that follow would read past it. Rather than leave that trap in place for the next caller, track whether the entry was found and return -EINVAL if it was not. No functional change. Signed-off-by: Francesco Magazzu Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260918131620.405133-3-postadelmaga@gmail.com commit aff09d9e37e02dc60bde79035ac15b136d602259 Author: Dan Carpenter Date: Fri Sep 18 15:16:17 2026 +0200 drm/nouveau/clk: fix list cursor use after loop in nvkm_clk_ustate_update If list_for_each_entry() exits without hitting a break then "pstate" is not a valid pstate pointer. Introduce a "found" variable instead. The check is reachable from userspace: nvkm_clk_ustate_update() takes the pstate id straight from the 'pstate' debugfs file, so requesting an id that is not in clk->states - or any id at all when the perf tables are broken and the list is empty - makes the pstate->pstate != req test dereference the list head cast to a struct nvkm_pstate, which is an out-of-bounds read. Fixes: 7c8565220697 ("drm/nouveau/clk: implement power state and engine clock control in core") Signed-off-by: Dan Carpenter [Francesco: rebased on drm-misc-next, expanded the commit message] Signed-off-by: Francesco Magazzu Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260918131620.405133-2-postadelmaga@gmail.com commit c3d85c669d09007aeb9eb9f3d28d8c863401f83f Merge: bfda5a01aa99c5 9fa26285ae70ac Author: Linus Torvalds Date: Fri Sep 18 11:05:55 2026 -0700 Merge tag 'ksmbd-for-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/smb Pull smb server fixes from Namjae Jeon: - Fix session expiration so that valid sessions are no longer removed after ten seconds of inactivity when a new session setup request is received. Sessions now expire only after credential expiration, while stale unauthenticated sessions are cleaned up after a 45-second timeout. - Keep earlier responses in compound requests when Query Info fails because the output buffer is too small. The error response is appended without truncating preceding responses. - Return STATUS_BUFFER_OVERFLOW for partial FILE_NORMALIZED_NAME_INFORMATION responses instead of incorrectly returning STATUS_INFO_LENGTH_MISMATCH. * tag 'ksmbd-for-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/smb: ksmbd: keep compound responses on query info errors ksmbd: fix partial normalized name responses ksmbd: follow SMB2 session expiration semantics commit 174d160884199cad97413f33fe1b56027dc0d3e1 Author: Jiangshan Yi Date: Mon Sep 14 18:45:51 2026 +0800 ASoC: codecs: rt1017-sdca-sdw: fix uninitialized stream_config->type stream_config is not initialized before being passed to sdw_stream_add_slave(). The type field may contain garbage and is later copied to stream->type by sdw_config_stream(). Zero-initialize stream_config so type defaults to SDW_STREAM_PCM. While at it, use snd_sdw_params_to_config() helper instead of open-coding the same logic. Fixes: 2b7aecd58528 ("ASoC: rt1017: Add RT1017 SDCA amplifier driver") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Link: https://patch.msgid.link/20260914104551.377880-1-yijiangshan@kylinos.cn Signed-off-by: Mark Brown commit bcd61aa247c28b721ac21dda6e4135f75a2de29f Author: Jiangshan Yi Date: Mon Sep 14 18:44:56 2026 +0800 ASoC: codecs: max98363: fix uninitialized stream_config->type stream_config is not initialized before being passed to sdw_stream_add_slave(). The type field may contain garbage and is later copied to stream->type by sdw_config_stream(). Zero-initialize stream_config so type defaults to SDW_STREAM_PCM. Fixes: 18c0af945fa3 ("ASoC: max98363: add soundwire amplifier driver") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Link: https://patch.msgid.link/20260914104456.376666-1-yijiangshan@kylinos.cn Signed-off-by: Mark Brown commit bfda5a01aa99c5c363ac9967b81cbd5902d6c940 Merge: 8cb0606271a910 229e8188307b97 Author: Linus Torvalds Date: Fri Sep 18 11:02:08 2026 -0700 Merge tag 'ntfs-for-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/ntfs Pull ntfs fixes from Namjae Jeon: - Make MFT extension work on existing Windows-created volumes by dynamically reserving MFT tail records, accounting for records added during allocation, and avoiding false -ENOSPC failures - Repack non-resident $MFT/$ATTRIBUTE_LIST when its mapping pairs no longer fit in the base MFT record, while propagating allocation and writeback errors - Serialize runlist updates with the runlist lock and restore both the in-memory runlist and on-disk mapping pairs when allocation rollback is required - Propagate folio errors and harden inode failure handling by treating interrupted reads as transient failures and discarding and unhashing inodes whose initialization fails - Fix the $MFTMirr write offset when mirror records span multiple folios, preventing mirror records from overwriting the first record with large MFT record sizes * tag 'ntfs-for-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/ntfs: ntfs: fix $MFTMirr write offset when it spans multiple folios ntfs: unhash failed inode reads ntfs: discard inodes that fail initialization ntfs: ignore interrupted inode reads as corruption ntfs: propagate folio errors ntfs: protect runlist updates with the runlist lock ntfs: account for MFT records added during allocation ntfs: repack $MFT/$ATTRIBUTE LIST ntfs: use dynamic MFT tail reservation commit 8cb0606271a9102f1ccac34e9fc9ee76f350a2ab Merge: ae09f35bd358b9 4396d70bb7fec5 Author: Linus Torvalds Date: Fri Sep 18 10:53:42 2026 -0700 Merge tag 'mmc-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC/MEMSTICK fixes from Ulf Hansson: "MMC core: - Prevent potential use-after-free for SDIO IRQ work - Fix OF node reference leak on card add failure - Fix memory lea when the port table is full for sdio_uart MMC host: - hsq: Fix use-after-free in retry work - mmci: Fix use-after-free in busy-timeout work - mmc_spi: Reset bytes_xfered before retrying CRC failures - mxcmmc: Cancel data work and watchdog on remove - rtsx_pci_sdmmc: Ignore broken write-protect on ThinkPad X260 - sdhci_am654: A couple of fixes for the tuning sequence - sdhci-of-aspeed: Remove children before releasing SDC resources - sh_mmcif: Initialize IRQ-thread mutex before requesting interrupt MEMSTICK: - ms_block: Destroy io_queue workqueue on removal * tag 'mmc-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci-of-aspeed: Remove children before releasing SDC resources mmc: sh_mmcif: initialize IRQ-thread mutex before requesting interrupt mmc: core: Fix OF node reference leak on card add failure mmc: rtsx_pci_sdmmc: ignore broken write-protect on ThinkPad X260 mmc: sdio_uart: fix xmit_fifo leak when the port table is full mmc: spi: reset bytes_xfered before retrying CRC failures mmc: sdhci_am654: Fallback to DT-provided itap delay on DDR50 tuning failure mmc: sdhci_am654: Clear ITAPDLY on tuning failure mmc: sdhci_am654: Reset command and data lines on failed tuning mmc: sdhci_am654: Move tuning_loop to local variable mmc: hsq: Fix use-after-free in retry work mmc: mxcmmc: cancel data work and watchdog on remove mmc: mmci: Fix use-after-free in busy-timeout work mmc: core: Cancel SDIO IRQ work before freeing host memstick: ms_block: destroy io_queue workqueue on removal commit ae09f35bd358b926916bd2b9f1d409b0d1924344 Merge: d24e3bf4c5484b 8d836581f9b1f5 Author: Linus Torvalds Date: Fri Sep 18 10:51:14 2026 -0700 Merge tag 'ata-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fixes from Niklas Cassel: - Explicitly clear upper address bits on quirked AHCI controllers AHCI controllers that claim to support 64-bit DMA, but which have been quirked to only do 32-bit DMA, could start the DMA engine with a non-zero value in the upper address bits registers (me) - Fix a resource leak in ahci_platform_get_resources() (Wentao) - Fix invalid kernel-doc formatting for ata_dsm_trim_pages() (me) * tag 'ata-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: libata-scsi: fix ata_dsm_trim_pages() kernel-doc ata: libahci_platform: Fix device reference leak in ahci_platform_get_resources() ata: libahci: clear PxCLBU and PxFBU for AHCI_HFLAG_32BIT_ONLY commit 81493c1dd1b1ebecb2843a7815973a5bd9a37e5a Merge: 59e0cc31cc5c43 d558af8ee0bb1b Author: Brian Masney Date: Fri Sep 18 13:38:11 2026 -0400 Merge tag 'tags/spacemit-clk-fixes-for-7.3-1' into clk-fixes RISC-V SpacemiT clock fixes for v7.3 - Add CPU PLL rate tables commit d24e3bf4c5484b29432837269ded253480fa8928 Merge: 928ba50514ac0a 92b68492eae701 Author: Linus Torvalds Date: Fri Sep 18 10:27:23 2026 -0700 Merge tag 'hwmon-for-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - Add missing sensors, and fix current sensors ID lookup (cgbc-hwmon) - Return IRQ_HANDLED from the shared alarm IRQ handler to fix possible interrupt storm (gpioufan) - Improve raw WMI string handling, and fix UaF in show function (hp-wmi-sensors) - Fix k10temp model id range of Zen5 Turin to stop reporting temperature data for non-existing CCDs - pmbus: - Increase number of phases to fix UaF problems - Fix TPS53676 phase page decoding, and select page 0 for single-page applications - Stop pwm-fan RPM timer before freeing tach data to fix UaF - Release w83793 probe data through kref to fix UaF - Remove w83791d fan/pwm 4-5 sysfs group on remove to fix UaF * tag 'hwmon-for-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (hp-wmi-sensors) Improve raw WMI string handling hwmon: (pmbus/tps53679) Select page 0 for single-page TPS53676 hwmon: (pmbus/tps53679) Fix TPS53676 phase page decoding hwmon: (hp-wmi-sensors) Fix use-after-free in fungible_show() hwmon: (w83793) release probe data through kref hwmon: (w83791d) remove fan/pwm 4-5 sysfs group on remove hwmon: (gpio-fan) return IRQ_HANDLED from the shared alarm IRQ handler hwmon: (pmbus/core) increase number of phases and add new mask hwmon: (cgbc-hwmon) Add missing sensors hwmon: (cgbc-hwmon) Fix current sensors ID lookup hwmon: (pwm-fan) Stop RPM timer before freeing tach data hwmon: (k10temp) Fix model id range of Zen5 Turin commit 928ba50514ac0a7b20ac83e6681583c2584c528d Merge: 5ad17a9760cd00 7cb575b71ab981 Author: Linus Torvalds Date: Fri Sep 18 10:18:32 2026 -0700 Merge tag 'watchdog-fixes-for-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull watchdog fixes from Guenter Roeck: - Fix suspend/resume handling of HW_RUNNING watchdog (da9062, da9063) - Avoid division by zero if clock rate is 0 (digicolor, rtd119x, and rzv2h) - Fix premature reset during timeout update, and propagate error code in msc313e resume() - Fix pci_dev reference leak in sp5100_tco_init() - Fix runtime PM leak in starfive_wdt_pm_start() * tag 'watchdog-fixes-for-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: watchdog: da9063: fix suspend/resume handling of HW_RUNNING watchdog watchdog: starfive-wdt: Fix runtime PM leak in starfive_wdt_pm_start() watchdog: da9062: fix suspend/resume handling of HW_RUNNING watchdog watchdog: msc313e: Fix premature reset during timeout update watchdog: msc313e: Propagate error code in resume() watchdog: rzv2h: Avoid division by zero watchdog: rtd119x: Avoid division by zero watchdog: digicolor: Avoid division by zero watchdog: sp5100_tco: Fix pci_dev reference leak in sp5100_tco_init() commit 5ad17a9760cd00c53d4a932a840e59af3a8f960e Merge: f259f446f5198d 53cf0f26eece09 Author: Linus Torvalds Date: Fri Sep 18 10:01:31 2026 -0700 Merge tag 'v7.3-p4' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "Fix a regression in caam" * tag 'v7.3-p4' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: caam - map job ring registers without claiming region commit 447dcff90557748a5ac384aaf5d70b2c7e3b961d Author: hpp.iscas Date: Sat Sep 5 21:43:40 2026 +0800 pinctrl: qcom: ipq5210: Publish the OF module alias The IPQ5210 TLMM platform driver can be a module and matches through ipq5210_tlmm_of_match. This table is not published for OF modalias matching. Publish the existing table, preserving arch_initcall ordering and the shared MSM pinctrl probe. Fixes: a549fe22376f ("pinctrl: qcom: Introduce IPQ5210 TLMM driver") Signed-off-by: hpp.iscas Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260905134340.67477-1-hppiscas@163.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Linus Walleij commit b0be01f133aa36d2fd12d71c916cb8a47826b4ed Author: Shawn Guo Date: Sun Aug 30 11:02:01 2026 +0800 pinctrl: qcom: nord: Split QUP1 SE2/SE3 into lane-pair functions QUP1 SE2 and SE3 pack all four of their lanes pair-wise onto only two pins each: lanes 0/1 (I2C SDA/SCL) at mux value 2 and lanes 2/3 (UART TX/RX) at mux value 1, on gpio127/gpio128 and gpio129/gpio130 respectively. Both mux values were named "qup1_se2" (respectively "qup1_se3"), so the two distinct lane pairs became indistinguishable. msm_pinmux_set_mux() stops at the first entry matching the requested function, which means mux value 1 was always selected and the I2C lanes could never be muxed out. In practice i2c9 and i2c10 got the UART lanes and did not work, while uart9 and uart10 happened to be muxed correctly. Give each lane pair its own function, following the _01/_23 naming already used for the same hardware arrangement by the shikra, eliza, hawi and maili TLMM drivers. Both functions still cover the full pin pair, so a single pinctrl state per protocol remains sufficient. Drop gpio129/gpio130 from the SE2 group list, since those pins belong to SE3 and were never reachable through the SE2 function. Also rename QUP1 SE2/SE3 functions in the binding doc accordingly. While at it, add missing "gpio", "qup3_se0_mira" and "qup3_se0_mirb" to the binding function enum to get the list complete. Fixes: c24dd0826f06 ("pinctrl: qcom: add the TLMM driver for the Nord platforms") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Shawn Guo Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260830030201.135637-1-shengchao.guo@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Linus Walleij commit f259f446f5198d98e13756d2cd531812a0ad3064 Merge: a077be4fde21ee 4dd1999783d7d1 Author: Linus Torvalds Date: Fri Sep 18 09:34:57 2026 -0700 Merge tag 'soc-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "The driver fixes are all for simple mistakes: a use-after-free bug on Samsung Exynos, error handling and reference counting on Arm SCMI firmware and a problem dealing with inconsistent firmware information. The rest are devicetree fixes for arm64 platforms from Altera, Renesas and Amlogic. On the Renesas platform, one patch addresses a boot time regression, the rest address minor performance and correctness issues" * tag 'soc-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (21 commits) soc: samsung: exynos-pmu: fix use-after-free of interrupt generator node arm64: dts: renesas: r8a779f0: Set UFS lane count firmware: arm_scmi: Fix typo "upto" in comment arm64: dts: renesas: r9a09g087: Switch GBETH TX queue scheduling to WRR arm64: dts: renesas: r9a09g077: Switch GBETH TX queue scheduling to WRR arm64: dts: renesas: r9a09g047: Switch GBETH TX queue scheduling to WRR arm64: dts: renesas: r9a09g056: Switch GBETH TX queue scheduling to WRR arm64: dts: renesas: r9a09g057: Switch GBETH TX queue scheduling to WRR firmware: arm_ffa: Tear down driver during shutdown clk: scpi: use PLATFORM_DEVID_NONE for scpi-cpufreq clk: scpi: register scpi-cpufreq once and clear on failure clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS firmware: arm_scpi: fix device_node leak in scpi_dev_domain_id arm64: dts: socfpga: change access permission from 755 to 644 ARM: socfpga: select the PL310 erratum 753970 workaround arm64: dts: amlogic: t7: fix the pin groups of the vsync PWM arm64: dts: amlogic: t7: khadas-vim4: add the PWM-driven supplies arm64: dts: amlogic: t7: fix the pin groups of two PWM outputs arm64: dts: amlogic: t7: khadas-vim4: allow the SD card to be power cycled ... commit a077be4fde21ee6e751fa70eb641ef5d9bf2fc48 Merge: 5023f5b861d50e fdb9ebc7fb7788 Author: Linus Torvalds Date: Fri Sep 18 09:28:30 2026 -0700 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "In this batch we've got a couple of hibernation fixes, a couple of minor MTE fixes, some per-cpu codegen fixes (which were found as part of Mark's series adding preemptible this_cpu_*() operations) and a fix for the Arm CMN PMU driver. Summary: - Fix hypercall arguments when resetting EL2 vectors during hibernation - Fix hibernation with 52-bit capable kernels on machines without 52-bit addressing, similarly to the recent kexec fix - Fix a bunch of clumsy codegen issues with our per-cpu accessors - Fix MTE ptrace documentation to reflect the de-facto ABI behaviour - Fix pthread_join() usage in MTE selftest - Fix port selection in the Arm CMN PMU driver" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: mte: Fix PTRACE_{PEEK,POKE}MTETAGS error documentation kselftest/arm64: Fix size of thread_data values for pthread_join() arm64: percpu: Fix LSE operations on {8,16}-bit types arm64: percpu: Fix this_cpu_and() mask generation arm64: percpu: Fix this_cpu_write() casting arm64: hibernate: clone only the linear map that exists at runtime perf/arm-cmn: Fix wp_dev_sel2 setting for multi-DTM configurations arm64: hibernate: pass HVC_SET_VECTORS args to the resume hvc commit 5023f5b861d50e43b25a3b1de47808023243484a Merge: 5dd1818b15d98d 126f16e0a1b353 Author: Linus Torvalds Date: Fri Sep 18 09:25:07 2026 -0700 Merge tag 'mips-fixes_7.3_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux Pull MIPS fixes from Thomas Bogendoerfer: - Fix kconfig dependencies for ECONET - Enable weak reordering for EYEQ - Include USB FDT fixup for Octeon even when USB is modular * tag 'mips-fixes_7.3_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: Octeon: apply USB FDT fixups also when USB is modular mips: select CONFIG_WEAK_REORDERING_BEYOND_LLSC from CONFIG_EYEQ MIPS: config: Add EcoNet EN751221 defconfig mips: econet: fix unmet dependencies for ECONET commit 692dd08e03f4a5523650e055f033f846bee43a0c Author: Xu Xin Date: Mon Sep 7 14:53:42 2026 +0800 MAINTAINERS: update Xu Xin's email Now I'm moving to the @linux.dev account, so map my old email addresses and update them to my new address. Link: https://lore.kernel.org/20260907145342529uOGtNYWTAzrSCFnghfgCb@zte.com.cn Signed-off-by: Xu Xin Signed-off-by: Andrew Morton commit 407a5d205179a4ab186571b0e16ec42725dc77bc Author: Josef Bacik Date: Wed Sep 9 18:01:07 2026 +0000 writeback: report a Tasks-RCU quiescent state per cgwb drain pass cleanup_offline_cgwbs_workfn() drains a dying cgwb by calling cleanup_offline_cgwb() until it returns false, with a cond_resched() between passes. On a CONFIG_PREEMPTION kernel that cond_resched() does nothing: _cond_resched() is a plain "return 0", and under PREEMPT_DYNAMIC the full and lazy modes disable it. Since commit 7dadeaa6e851 ("sched: Further restrict the preemption modes") those are the only two models on the architectures with PREEMPT_LAZY support, arm64 and x86 among them, so the drain loop never reports a Tasks-RCU quiescent state. A worker draining a cgwb with millions of attached inodes runs for minutes. On a 6.18 arm64 host in lazy mode the cgwb worker drained one dying cgroup's writeback domain for over 11 minutes. A BPF program unlink (bpf_trampoline_unlink_prog -> bpf_trampoline_update -> unregister_ftrace_direct -> ftrace_shutdown -> synchronize_rcu_tasks()) waited on that grace period while holding the trampoline mutex, 42 tasks queued behind it in D state, and the hung task detector fired at 614 s and panicked the host. Any BPF or ftrace detach during a long drain inherits the drain's length. Fix this by calling cond_resched_tasks_rcu_qs() so we do not stall out anybody who calls sycnrhonize_rcu_tasks(). We put this in a do { } while loop because if we have many small cgroups cleanup_offline_cgwb() will return false and we will never call cond_resched_tasks_rcu_qs(), creating the same problem. Link: https://lore.kernel.org/20260909-cgwb-tasks-rcu-qs-v1-1-967a7754771f@toxicpanda.com Fixes: c22d70a162d3 ("writeback, cgroup: release dying cgwbs by switching attached inodes") Signed-off-by: Josef Bacik Signed-off-by: Andrew Morton Link: https://lore.kernel.org/bpf/9d444098-7c03-4163-af12-bd0a79a51443@paulmck-laptop/ Assisted-by: LLM Acked-by: Tejun Heo Reviewed-by: Roman Gushchin Reviewed-by: Jan Kara Acked-by: Lorenzo Stoakes (ARM) Cc: David Hildenbrand Cc: Dennis Zhou Cc: Liam R. Howlett Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: "Paul E . McKenney" Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: commit eb64948249781bda35de04feab5a0acc36aa9051 Author: SJ Park Date: Thu Sep 10 07:28:45 2026 -0700 mm/damon/core: reset invalid quota->charge_target_from DAMOS can suddenly stop working if a target process that the quota is just fully charged on is terminated. Fix by catching and processing the corner case. When DAMOS quota is fully charged, the target and the region to continue applying the action in the next round is saved in damos_quota->charge_{target,addr}_from. In the next round, DAMOS iterates targets and regions from the beginning. It skips applying the action to the regions until it visits and skips the saved target/region. Virtual address space targets become invalid if the process is terminated. Trying to apply the scheme to invalid target is just a waste of time. Hence commit 6e4930e33329 ("mm/damon/core: fix wasteful CPU calls by skipping non-existent targets") made the logic to skip invalid targets. However, it does skip before the charged target/region skipping/updating. Let's suppose the user runs DAMOS for multiple virtual address spaces with a quota. The quota exceeded in the middle of a virtual address space. And the process of the address space is terminated. Then the charge_target_from points to the invalid target. The pointer update logic is skipped for the invalid target, so the charge_target_from is never updated. DAMOS action to every target/region is skipped. From the user's perspective, it would look like suddenly DAMOS has stopped working. No critical leak or crash can happen. The user could reinstall the scheme. But this makes use of DAMOS under certain setups quite unreliable. When the invalid target is found, further check the corner case and reset the pointer. This issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260910142846.172957-1-sj@kernel.org Link: https://lore.kernel.org/20260830064708.40CA61F000E9@smtp.kernel.org [1] Fixes: 6e4930e33329 ("mm/damon/core: fix wasteful CPU calls by skipping non-existent targets") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: Enze Li Cc: # 7.0.x commit 44fcc0bfb0874a95cec2c1672f14d426f86dc68f Author: Baolin Wang Date: Tue Sep 8 09:42:12 2026 +0800 MAINTAINERS: add Baoquan and Baolin as MGLRU reviewers Baoquan and I have been contributing MGLRU patches and helping review MGLRU related patches for some time. We will continue to follow MGLRU changes, so we'd like to be CC'd on MGLRU related patches. Link: https://lore.kernel.org/06e20ef4f603a4ffeafcdbf623ce2936281457bf.1788831480.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang Signed-off-by: Andrew Morton Acked-by: Barry Song Acked-by: Qi Zheng Acked-by: Baoquan He Acked-by: Kairui Song Cc: Axel Rasmussen Cc: Shakeel Butt Cc: Wei Xu Cc: Yuanchu Xie commit b6ac0b3f6013c168f22cad97e79967accacb08e1 Author: Jinjiang Tu Date: Tue Sep 8 20:29:24 2026 +0800 mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish On arm64 server, we find that a task trying to grab the anon_vma lock triggers hungtask. INFO: task main:2354726 blocked for more than 120 seconds. Tainted: G E 5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: __switch_to+0x7c/0xbc __schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsem_down_write_slowpath+0x3cc/0x6cc down_write+0x60/0x260 __anon_vma_prepare+0x6c/0x210 do_anonymous_page+0x258/0x660 handle_pte_fault+0x188/0x214 __handle_mm_fault+0x1b0/0x380 handle_mm_fault+0xf4/0x284 do_page_fault+0x19c/0x494 do_translation_fault+0xcc/0xf8 do_mem_abort+0x48/0xac el0_da+0x44/0x80 el0_sync_handler+0x88/0xb4 el0_sync+0x160/0x180 After analyzing the vmcore, we found the anon_vma->root->rwsem.count is -1. There is another anon_vma whose anon_vma->root->rwsem.count is 1, the anon_vma->root->rwsem.owner shows the lock is held, but the stack of the task shows the task doesn't hold the anon_vma lock. After adding more debugging info, we found __anon_vma_prepare() reuses anon_vma and triggers the UAF of anon_vma->root due to missing memory barrier, leading to locking and unlocking two different anon_vma->root, thus leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore. This race requires two adjacent VMAs that are not merged but are anon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be changed by mprotect()). Two threads fault on each VMA concurrently, both calling __anon_vma_prepare() with only mmap_lock held for reading. THREAD A THREAD B __anon_vma_prepare __anon_vma_prepare find_mergeable_anon_vma() -> NULL anon_vma = anon_vma_alloc(); anon_vma->root = anon_vma; // the two stores may be reordered vma->anon_vma = anon_vma; // finds A's anon_vma anon_vma = find_mergeable_anon_vma(vma); anon_vma_lock_write(anon_vma); // may still see the old root down_write(&anon_vma->root->rwsem); anon_vma_unlock_write(anon_vma); // see the new root, never unlock old up_write(&anon_vma->root->rwsem); thread A triggers page fault and calls __anon_vma_prepare() to prepare anon_vma for the faulting vma. __anon_vma_prepare() allocates and initializes a new anon_vma, and then publishes it to the vma with a plain store. anon_vma_prepare() only requires the mmap_lock to be held for reading, so two threads can fault on adjacent VMAs at the same time. While thread A publishes a new anon_vma, thread B could find the anon_vma via find_mergeable_anon_vma() and then locks anon_vma->root->rwsem. The store to anon_vma->root in anon_vma_alloc() and the store to vma->anon_vma can be reordered. The anon_vma_lock_write() and spin_lock() only provide acquire semantics, which do not prevent prior stores from being reordered after them. The release semantics of the corresponding spin_unlock() and anon_vma_unlock_write() come too late, the store to vma->anon_vma is already published before they take effect. As a result, thread B can observe the following order: vma->anon_vma = anon_vma; anon_vma->root = anon_vma; The anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma may reuse memory from a previously freed one. The constructor (anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma() doesn't clear it either, so the old root value persists until anon_vma_alloc() overwrites it. If that store isn't visible, thread B reads a root that points to the old anon_vma and locks it. As a result, thread B can call anon_vma_lock_write() with the old root, and call anon_vma_unlock_write() with the new root, leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore (its count is dropped from 0 to -1 due to wrong unlock). To fix it, change the plain store `vma->anon_vma = anon_vma` to store release, so that the fields of anon_vma are visible before anon_vma is published to vma->anon_vma. At read side, the load of anon_vma and anon_vma->root have address dependency. According to Documentation/memory-barriers.txt and some investigations, only Alpha needs address-dependency barriers and it has been handled by READ_ONCE() in reusable_anon_vma(). We reproduced this issue in v5.10 with KSM enabled. The kernel doesn't merge commit cf7e7a3503df ("mm: prevent KSM from breaking VMA merging for new VMAs"), so there are many adjacent VMAs that aren't merged but are compatible for anon_vma. Without this fix, our production environment could reproduce this issue about 2-5 times each month. After adding a smp_mb() before anon_vma_lock_write(anon_vma) in __anon_vma_prepare(), which is different to this patch, this issue hasn't been reproduced for one month. Link: https://lore.kernel.org/20260908122924.554373-1-tujinjiang@huawei.com Fixes: 5c341ee1dfc8 ("mm: track the root (oldest) anon_vma") Signed-off-by: Jinjiang Tu Signed-off-by: Andrew Morton Reviewed-by: Lance Yang Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Acked-by: Vlastimil Babka (SUSE) Cc: Minchan Kim Cc: Harry Yoo Cc: Hiroyouki Kamezawa Cc: Jann Horn Cc: Jinjiang Tu Cc: Kefeng Wang Cc: Larry Woodman Cc: Liam R. Howlett Cc: Nanyong Sun Cc: Rik van Riel Cc: commit 9bdad082d44bdcf93716973dcba6be77e8a06e7b Author: Jaewook You Date: Mon Sep 14 22:23:52 2026 +0900 mm/hugetlb: preserve mremap address delta when skipping page tables move_hugetlb_page_tables() optimizes mremap() by advancing to the last entry in the page table when the source page table does not exist, either initially or after unsharing a PMD table. The common loop increment then steps to the first entry in the next page table. However, the code advances both the source and destination addresses to the last entries in their respective page tables, which is wrong. The destination address must be advanced only by the same amount as the source address. If the source and destination offsets within their page tables differ, the destination address can be advanced too far, causing follow-up issues. Fix this by advancing the destination address by the source advance distance. With a reproducer, we were able to trigger a kernel panic on x86-64. With this fix in place, we can no longer reproduce the issue. Link: https://lore.kernel.org/20260914132352.472-1-jaewook376@gmail.com Fixes: e95a9851787b ("hugetlb: skip to end of PT page mapping when pte not present") Fixes: 4ddb4d91b82f ("hugetlb: do not update address in huge_pmd_unshare") Signed-off-by: Jaewook You Signed-off-by: Andrew Morton Acked-by: David Hildenbrand (Arm) Cc: Johan Hovold Cc: Muchun Song Cc: Oscar Salvador Cc: Assisted-by: LLM commit b3723b596b548c837a766aae3553c14a7b15af2b Author: Liew Rui Yan Date: Tue Sep 8 06:47:38 2026 -0700 mm/damon/core: fix unconditionally skip last region Once quota set, the charge_{target,addr}_from unconditionally skips and resets at the last region of the tracked target, so the last region can be skipped even when it has not been processed. Example: 1. Target has 2 regions: R1 (0-100 bytes) and R2 (100-200 bytes). 2. Quota is configured to process only 100 bytes per window. 3. Window 1: Processes R1 (0-100). Quota is full. charge_{target, addr}_from is saved at (Target, 100). 4. Window 2: The loop reaches R2. Because R2 is damon_last_region(t), the old code unconditionally returns true, skipping R2 entirely and resetting the charge_{target,addr}_from. Result: R2 is permanently skipped even though it has never been processed. However, it is important to note that this is a very minor issue. This is because it is triggered only when the previous window saved/kept charge_{target,addr}_from, and in the next window, all regions except the last region were skipped by damos_skip_charged_region(). Fix this by only resetting the charge_{target,addr}_from when last region is reached, only skipping when it is applied or cannot split. Link: https://lore.kernel.org/20260908134739.96919-1-sj@kernel.org Fixes: 50585192bc2e ("mm/damon/schemes: skip already charged targets and regions") Signed-off-by: Liew Rui Yan Reviewed-by: SJ Park Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: # v5.16.x commit 39c0ceedd54557bdc1542de08d22b2ed33e534e4 Author: SJ Park Date: Mon Sep 7 10:03:56 2026 -0700 mm/damon/vaddr: avoid hw-driven pte updates during damon_hugetlb_mkold() damon_hugetlb_mkold() reads the page table entry into a local variable, unsets the accessed bit in the variable, and updates the page table entry with the updated variable value. If hardware updates the same page table entry in parallel, the hw updates could be lost. For example, hardware-updated dirty bits might be lost. Avoid the parallel updates by clearing the page table entry when reading it together, using huge_ptep_get_and_clear(). If a parallel write to the memory is made after the clearing, the hw will see the page table entry is cleared, trigger page fault and wait until it is handled. The page fault handling will wait for damon_hugetlb_mkold() due to the page table lock. Because hugetlbfs is an in-memory file system and hugetlb pages cannot be reclaimed, no critical issue is expected to my best knowledge. But definitely this is a nasty bug that should be fixed sooner rather than later. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260907170358.100168-1-sj@kernel.org Link: https://lore.kernel.org/20260830160545.98969-1-sj@kernel.org [1] Fixes: 49f4203aae06 ("mm/damon: add access checking for hugetlb pages") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: Baolin Wang Cc: # 5.17.x commit 90179da203ba8b708c84a12a07cd44be0f346334 Author: Liew Rui Yan Date: Tue Sep 8 06:54:11 2026 -0700 mm/damon/core: allow esz to be set to zero When the temporal quota goal tuner determines that the goal has been achieved (score >= 10000), it sets esz_bp to zero so that the esz becomes zero. However, damos_set_effective_quota() clamps the esz to min_region_sz when quota->ms is set. This is a minor issue, the main problem is that it doesn't match the description in the documentation, which state that if the goal has already been [over-]achieved, the quota will be set to zero. Fix this by set quota (esz) as minimum as possible. Link: https://lore.kernel.org/20260908135413.97570-1-sj@kernel.org Fixes: 8bbde987c2b8 ("mm/damon/core: disallow time-quota setting zero esz") Signed-off-by: SJ Park Signed-off-by: Liew Rui Yan Signed-off-by: Andrew Morton Reviewed-by: SJ Park Cc: # v7.1.x commit f166586f74dd5d9cbadaabf86ef81c8ddf6cafa7 Author: Nathan Gao Date: Thu Sep 3 17:28:27 2026 -0700 mm/damon/ops-common: use a page-aligned address in damon_ptep_mkold() __damon_va_prepare_access_check() picks a random byte address within the region and stores it in r->sampling_addr. damon_va_mkold() passes it into a page table walk, which hands it to damon_ptep_mkold() as the address of the page to sample: damon_va_mkold(mm, r->sampling_addr) damon_va_walk_page_range(mm, addr, addr + 1) damon_mkold_pmd_entry() damon_ptep_mkold(pte, vma, addr) ptep_test_and_clear_young(vma, addr, pte) mmu_notifier_clear_young(mm, addr, addr + PAGE_SIZE) For arm64, before commit 6f0e1142173a ("arm64: mm: support batch clearing of the young flag for large folios"), the contpte helper walked exactly CONT_PTES entries from the aligned-down page table pointer and used @addr only to pass down to each entry, so an unaligned value was harmless: ptep = contpte_align_down(ptep); addr = ALIGN_DOWN(addr, CONT_PTE_SIZE); for (i = 0; i < CONT_PTES; i++, ptep++, addr += PAGE_SIZE) Now the range to walk is derived from @addr instead: end = addr + nr * PAGE_SIZE, rounded up to CONT_PTE_SIZE. For a sample in the last page of a contpte block, the sub-page offset puts end just past the block boundary, so the round-up lands a whole block further and the walk clears PTE_AF in CONT_PTES entries beyond the sampled block. For the last block in a page table page, those entries are past the end of that page, so the walk writes into the page that follows. Triggered by the full 7.1/7.2 kernel selftest suite on arm64 (EC2 c/m6g.4xlarge). The kernel sometimes crashes at or shortly after the DAMON test. What the overrun does depends on the page that happens to follow the page table, so there is no single signature. If that page is read-only, the write faults in the sampling path itself: Unable to handle kernel write to read-only memory at virtual address ffff0003c5d2d000 FSC = 0x0f: level 3 permission fault CM = 0, WnR = 1, TnD = 0, TagAccess = 0 CPU: 10 UID: 0 PID: 3487 Comm: kdamond.2 pc : contpte_test_and_clear_young_ptes+0x70/0xc0 lr : damon_ptep_mkold+0x1e8/0x1f8 Call trace: contpte_test_and_clear_young_ptes+0x70/0xc0 (P) damon_mkold_pmd_entry+0x150/0x170 walk_pmd_range+0x110/0x2b0 walk_pud_range+0x10c/0x208 walk_pgd_range+0x134/0x258 __walk_page_range+0x98/0x1b0 walk_page_range_vma_unsafe+0x90/0x148 walk_page_range_vma+0x28/0x40 damon_va_walk_page_range+0x114/0x2b8 damon_va_prepare_access_checks+0xec/0x1a8 kdamond_fn+0x534/0x770 kthread+0x128/0x138 ret_from_fork+0x10/0x20 Otherwise the page is writable, the PTE_AF clearing succeeds silently and the damage only surfaces later, in whatever happened to own the page, so the backtrace is unrelated to DAMON and differs between runs. Pass a page-aligned address to the ptep_test_and_clear_young() call in damon_ptep_mkold(), which is the only place DAMON can reach contpte_test_and_clear_young_ptes() from. Nothing else sees the aligned address, and r->sampling_addr itself is left as is, so the sampling and region bookkeeping semantics are unchanged. Link: https://lore.kernel.org/20260904002829.116381-1-sj@kernel.org Fixes: 6f0e1142173a ("arm64: mm: support batch clearing of the young flag for large folios") Signed-off-by: Nathan Gao Signed-off-by: SJ Park Signed-off-by: Andrew Morton Reviewed-by: SJ Park Reviewed-by: Baolin Wang Cc: Baolin Wang Cc: David Hildenbrand (Arm) Cc: Ryan Roberts Cc: commit 525c0edc032b3297d0c1056cf1fa20cf1f9e6184 Author: Joseph Qi Date: Fri Sep 4 10:37:51 2026 +0800 ocfs2: make ocfs2_calc_xattr_init() return void ocfs2_calc_xattr_init() used to read the default ACL off the parent inode itself, so it could return an error from ocfs2_xattr_get_nolock(). Commit bd7c05fb4a47 ("ocfs2: fix circular locking dependency in ocfs2_init_acl()") moved that lookup before the transaction starts and deleted the error path, but left the now vestigial 'int ret = 0' declaration and both 'return ret' statements behind, along with an unreachable error branch in ocfs2_mknod(). Drop the leftover variable and convert the return type to void, so the callee states that it always succeeds and the caller no longer carries a check that can never trigger. No functional change. Link: https://lore.kernel.org/20260904023751.3703334-1-joseph.qi@linux.alibaba.com Fixes: bd7c05fb4a47 ("ocfs2: fix circular locking dependency in ocfs2_init_acl()") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609040247.8B3lmoqX-lkp@intel.com/ Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao commit 8d50c2f37bcc766cd5ecde9bbb14c9c27c609f33 Author: Haowen Bai Date: Thu Sep 3 21:28:54 2026 +0800 mailmap: update Haowen Bai's email address Map Haowen Bai's former Meizu and current Ugreen addresses to baihaowen88@gmail.com as the canonical public address. Link: https://lore.kernel.org/20260903132854.1930923-1-calvin.bai@ugreen.com Signed-off-by: Haowen Bai Signed-off-by: Andrew Morton commit 8c7fdc0b4c64d6583fff3e8f7696237a16ff7c29 Author: Joshua Hahn Date: Wed Sep 2 12:45:20 2026 -0700 selftests/cgroup: account for zswap shrinker writeback The test_no_invasive_cgroup_shrink selftest checks that when a cgroup has zswapped out more memory than memory.zswap.max, it does not trigger writeback for other cgroups. To do this, it compares the writeback count in a control cgroup and makes sure that it is 0, and then checks the writeback count in an aggressor cgroup who does expect to see writeback. However, when the zswap shrinker is enabled, the victim cgroup can see legitimate writebacks not triggered by the aggressor. In some Meta CI tests, we have seen this failure mode happen. Instead of checking that the victim cgroup has 0 writeback, compare the writeback values before and after the aggressor runs and check that the victim cgroup did not perform any additional writeback. Note that this can still lead to probabilistic failures if writebacks take longer than 5 seconds, but this should fix the systematic failure case and make "not ok test_no_invasive_cgroup_shrink" less likely. Link: https://lore.kernel.org/20260902194521.3652178-1-joshua.hahnjy@gmail.com Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure") Signed-off-by: Joshua Hahn Signed-off-by: Andrew Morton Reported-by: Krush Chavan Suggested-by: Nhat Pham Cc: commit 7cb575b71ab98194d2e040bded3a7281e089c5ed Author: Li Jun Date: Thu Sep 17 09:37:10 2026 +0800 watchdog: da9063: fix suspend/resume handling of HW_RUNNING watchdog da9063_wdt_suspend() and da9063_wdt_resume() only check watchdog_active(), when the watchdog is left running by the driver sets WDOG_HW_RUNNING in da9063_wdt_probe() but userspace never opens the device, so WDOG_ACTIVE remains cleared, the wdt_disable() will not be executed in da9063_wdt_suspend. In this case, the suspend callback is a no-op and the watchdog keeps counting during system suspend, leading to an unexpected system reset. Check WDOG_HW_RUNNING and wdd，can fix this issue. Fixes: a7ceca4398bc8 ("watchdog: da9063: optionally disable watchdog during suspend") Cc: stable@vger.kernel.org Signed-off-by: Li Jun Link: https://patch.msgid.link/20260917013710.2754679-1-lijun01@kylinos.cn Signed-off-by: Guenter Roeck commit 4dd1999783d7d12434006289338373e49492dc96 Author: Alexey Klimov Date: Thu Sep 17 10:16:42 2026 +0200 soc: samsung: exynos-pmu: fix use-after-free of interrupt generator node The setup_cpuhp_and_cpuidle() parses the device tree node for the interrupt generation block via of_parse_phandle() and decrements its reference count using of_node_put() immediately after fetching the resource address. However, later the intr_gen_node pointer is passed into of_syscon_register_regmap(). Fix this by declaring intr_gen_node with __free() and removing of_node_put(). Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org?part=3 Fixes: 78b72897a5c8 ("soc: samsung: exynos-pmu: Enable CPU Idle for gs101") Cc: stable@vger.kernel.org Signed-off-by: Alexey Klimov Link: https://patch.msgid.link/20260828-exynos-pmu-cpuhp-idle-fixes-v2-1-06bce6107bd6@linaro.org Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260917081641.72291-2-krzk@kernel.org Signed-off-by: Arnd Bergmann commit 2d5061ff3762a71dac6809a9bd9013fd785aab28 Merge: ce55a6545a3755 8dc2615d570205 Author: Arnd Bergmann Date: Fri Sep 18 14:33:55 2026 +0200 Merge tag 'renesas-fixes-for-v7.3-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/fixes Renesas fixes for v7.3 (take two) - Fix UFS regression on R-Car S4. * tag 'renesas-fixes-for-v7.3-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: arm64: dts: renesas: r8a779f0: Set UFS lane count Signed-off-by: Arnd Bergmann commit 289e99e7a263c6fd6a5d07d6d8f2156b70f3a9d5 Author: Zhenghui Hao Date: Fri Sep 18 13:46:49 2026 +0800 parisc: parse early parameters in setup_arch() parisc is one of the few architectures that does not call parse_early_param() from setup_arch(). That was mostly harmless until commit d49004c5f0c1 ("arch, mm: consolidate initialization of nodes, zones and memory map") moved the consumer of several hugetlb command line parameters into mm_core_init_early(), which runs before the generic parse_early_param() call in start_kernel(). As a result hugepages=, hugepagesz=, default_hugepagesz=, hugetlb_cma= and hugetlb_free_vmemmap= are recorded after they have already been consumed and are silently dropped on parisc. Call parse_early_param() from setup_arch(), after the command line has been set up and the memory inventory has been taken. jump_label_init() must be called first because early parameter handlers may enable or disable static keys. Both functions are safe to call more than once: the generic calls in start_kernel() remain in place and turn into no-ops. Suggested-by: Mike Rapoport (Microsoft) Fixes: d49004c5f0c1 ("arch, mm: consolidate initialization of nodes, zones and memory map") Cc: Signed-off-by: Zhenghui Hao Tested-by: Helge Deller Signed-off-by: Helge Deller commit cb917b1e1c23f6f9b73802cd576b48bd606458c0 Author: Ethan Nelson-Moore Date: Thu Sep 17 20:04:14 2026 -0700 parisc: remove unused header The last use of arch/parisc/include/asm/compat_ucontext.h was removed in commit d313d4e72df3 ("parisc: remove unused compat_rt_sigframe.h header") but it was left behind. Remove it. Signed-off-by: Ethan Nelson-Moore Signed-off-by: Helge Deller commit 4485a01f4df1c9683d8ffe3e4ade6c33c9572d3c Author: Sean Young Date: Sun Sep 13 15:12:27 2026 +0100 parisc: unwind: Replace open-coded binary search with bsearch() There is a bug in the binary search where hi can underflow. If addr is less than the first entry, then "hi = mid - 1" will underflow to ULONG_MAX. Then we have an out-of-bounds read. Replace the open-coded binary search with bsearch(). Issue found by an LLM. Signed-off-by: Sean Young Signed-off-by: Helge Deller commit b7403afb7a5f85073243df10238b3483958ad69e Author: David Carlier Date: Sun Sep 6 13:14:16 2026 +0100 arm64: errata: match the target implementation CPU's own MIDR __is_affected_midr_range() is handed the MIDR and REVIDR of one target implementation CPU, but tests the erratum's range with is_midr_in_range(), which re-scans all of target_impl_cpus[] and ignores the @midr argument. The range test is thus constant across the per-CPU loop in is_affected_midr_range() and only answers "is any target CPU in range". Since just the fixed_revs REVIDR check uses the iteration's own registers, an out-of-range target CPU can decide whether a MIDR_FIXED() exemption applies. A VM then enables a workaround whose only in-range CPU is fixed silicon, e.g. erratum 2658417 on a Cortex-A510 r1p1 with REVIDR_EL1[25] set. Factor the range test into __is_midr_in_range(), which takes an explicit MIDR, and use it in __is_affected_midr_range(). Fixes: 86edf6bdcf05 ("smccc/kvm_guest: Enable errata based on implementation CPUs") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: David Carlier Signed-off-by: Will Deacon commit baaa9b126b875b40ffd9356da52c7c871917e5bb Author: Yureka Lilian Date: Fri Sep 11 19:02:10 2026 +0200 arm64: Add override for WFxT Add an override for WFxT support within ID_AA64ISAR2_EL1 to allow it to be disabled using the new arm64.nowfxt command line parameter. This accompanies the idle=nop param introduced in a previous patch series [1] in dealing with misbehaving WFI and WFIT instructions on Apple Silicon SoCs, and eases debugging of other quirky WFxT implementations. Link[1]: https://lore.kernel.org/all/20260804-arm64-idle-param-v3-1-d10f8159062b@cyberchaos.dev/ Suggested-by: Will Deacon Signed-off-by: Yureka Lilian Signed-off-by: Will Deacon commit bb756b11ad63832ebee58caf9e8f9381eaecff9f Author: Zeng Heng Date: Fri Sep 11 09:58:59 2026 +0800 arm64: io: Reject non-user protection in ioremap_prot() Mapping a stack-top page via /dev/mem with PROT_NONE and then reading that process's /proc//cmdline triggers a spurious WARN in ioremap_prot() through generic_access_phys(): WARNING: ./arch/arm64/include/asm/io.h:275 at generic_access_phys Call trace: generic_access_phys+0x1c8/0x228 (P) __access_remote_vm+0x2b4/0x398 access_remote_vm+0x14/0x30 get_mm_cmdline+0xf8/0x2a0 proc_pid_cmdline_read+0x68/0x120 generic_access_phys() passes the protection derived from the user PTE to ioremap_prot(). On arm64, a PROT_NONE mapping is represented by a present-invalid PTE, so pte_present() still returns true and the protection reaches ioremap_prot(). A PROT_NONE mapping does not have PTE_USER, causing the existing WARN_ON_ONCE() in ioremap_prot() to fire even though this is a valid user mapping. Execute-only mappings have the same issue and must not be readable through this path either. ioremap_prot() should therefore reject protection values without PTE_USER without warning. This makes the access fail cleanly for PROT_NONE and execute-only mappings while retaining the existing user-protection contract. Fixes: 8f098037139b ("arm64: io: Extract user memory type in ioremap_prot()") Signed-off-by: Zeng Heng Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon commit 406aa2b186d3f13a35bc1ad6aff4274917851bc4 Author: Robin Murphy Date: Tue Sep 15 13:24:22 2026 +0100 perf/arm-cmn: Fix multi-filter encoding The current special-case for EVICT_STATE_SEL filtering effectively assigns the "filter" and "filter2" controls in the opposite order from how the CMN S3 r2 TRM states "Filtering is programmed in pmu_hbt_lbt_sel and pmu_evict_state_sel". On reflection, not only does this seem unnecessarily non-obvious to users, but it's also likely to be a problem for scaling to a full multi-filter abstraction in future. There is a logical order to filters based on their bitfield positions in the pmu_event_sel register, which the TRM descriptions allude to, and the cmn_filter_select enum already (almost) follows, so let's fix the UABI to follow suit while it's still unreleased. Fixes: 09178f536bb9 ("perf/arm-cmn: Plumb in new filter types") Signed-off-by: Robin Murphy Reviewed-by: Ilkka Koskinen Reviewed-by: Leo Yan Signed-off-by: Will Deacon commit abc36cbda29d8f19cf3a580cd86ca9e865186a41 Merge: ea31c6498c6130 ec06546b43b612 Author: Greg Kroah-Hartman Date: Fri Sep 18 11:56:25 2026 +0100 Merge tag 'usb-serial-7.3-rc4' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB serial fixes for 7.3-rc4 Here are two fixes for a long-standing baud rate overflow issue in the two Quatech drivers and a new cp210x device id. Everything has been in linux-next with no reported issues. * tag 'usb-serial-7.3-rc4' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: quatech2: fix baud rate overflow USB: serial: ssu100: fix baud rate overflow USB: serial: cp210x: add Corsair AX1500i Power Supply commit 96443a53bc3ef4b67dab0c497878fc8d56f799f3 Author: Matthew Schwartz Date: Thu Sep 17 16:09:07 2026 -0700 selftests/x86: Check signal state for rejected software interrupts Add a test of the signal ABI for INT instructions in both 32-bit and 64-bit processes. Check the signal number, trap number, error code, si_code, si_addr, instruction pointer and RF/TF state against legacy IDT behavior. Include a 15-byte prefixed INT to check that IP uses the hardware instruction length. Exercise both INT3 encodings, INT4, UD2 and HLT to cover the unchanged trap and fault paths. Run each instruction with TF clear and set. Resume at a known NOP after handling the signal and check that single-stepping traps after the NOP. Also drive INT 0x2d under ptrace, which resumes through the fault frame rather than sigreturn and so exposes a stale FRED software event flag. Start from an INT3 stop, whose FRED frame has no software event flag, instead of the syscall frame of raise(SIGSTOP). Single-step into the INT and check that the fault reports its address. Then suppress SIGSEGV and resume at the NOP, once with PTRACE_SINGLESTEP and once with PTRACE_CONT and TF set. Section 6.2.3 of the Intel FRED specification [1] specifies the immediate single-step trap caused by returning with both that flag and TF set. Check that each trap occurs after the NOP, rather than at its address. Report whether the CPU supports FRED, since a pass looks the same on either entry path. INT 0x80 with IA32 emulation disabled and a 64-bit tracer of a 32-bit tracee are not covered. Both variants pass all 29 checks on a non-FRED AMD host and on Panther Lake with FRED enabled and the fix applied. With the same binaries on unpatched Panther Lake, 16 signal-context checks fail and the first ptrace check reports the IP after the INT. The two dependent ptrace resume checks are not reached. [1] Intel Flexible Return and Event Delivery (FRED) Specification, revision 9.0 (346446-009US), section 6.2.3. Signed-off-by: Matthew Schwartz Signed-off-by: Peter Zijlstra (Intel) Link: https://cdrdv2.intel.com/v1/dl/getContent/678938 # [1] Link: https://patch.msgid.link/20260917230907.2080792-3-matthew.schwartz@linux.dev commit 93f53499d0b945e8ae447f497faf743d60069f61 Author: Matthew Schwartz Date: Thu Sep 17 16:09:06 2026 -0700 x86/fred: Reconstruct the #GP context for rejected INT instructions FRED event delivery does not use the IDT, so the gate DPL check that rejects a user INT n falls to software (Intel FRED specification [1], section 8.3). fred_intx() rejects the same vectors as IDT delivery, but reports a zero error code and the IP after the INT. This breaks the signal ABI. Wine uses the error code to recognize INT 0x2d, so the changed context turns a handled breakpoint into an access violation in Elden Ring. Rewind IP using the instruction length in the augmented SS and synthesize the IDT selector error code, (vector << 3) | 2. Set RF in the saved flags, as the CPU does for a #GP fault. Section 5.2.1 defines the saved vector, instruction length and RF state. The supplied length handles prefixes without reading user memory. Limit the changes to already-rejected software interrupts, preserving the accepted INT3, INT4 and enabled INT80 paths and hardware exceptions. With IA32 emulation disabled, INT 0x80 now reports the same #GP as the DPL 0 gate IDT installs there. The rewound IP also stops fixup_iopl_exception() from inspecting the byte after the INT. Also clear the software event flag. Section 6.2.3 specifies that ERETU with this flag and TF set traps before executing any user instruction. A tracer that suppresses SIGSEGV and resumes with TF set expects the next instruction to run first, as after IRET. The sigreturn path clears the same flag for this reason in prevent_single_step_upon_eretu(). [1] Intel Flexible Return and Event Delivery (FRED) Specification, revision 9.0 (346446-009US), sections 5.2.1, 6.2.3 and 8.3. Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15745 Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16132 Reported-by: Paul Gofman Signed-off-by: Matthew Schwartz Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: H. Peter Anvin Link: https://cdrdv2.intel.com/v1/dl/getContent/678938 # [1] Link: https://patch.msgid.link/20260917230907.2080792-2-matthew.schwartz@linux.dev commit fe3c73d7bc769e7afc252f867a3421fe168b898d Author: Andrea Righi Date: Tue Sep 15 20:41:01 2026 +0200 sched/core: Avoid false migration warning for proxy donors Proxy execution can move a blocked donor's scheduling context to the lock owner's CPU even when the donor is migration-disabled. The donor does not execute there, and its original execution CPU remains recorded in wake_cpu. set_task_cpu() warns unconditionally for migration-disabled tasks, so a subsequent proxy migration or the wakeup path returning the donor home triggers a false positive: moving a blocked scheduling context does not violate the migration-disabled execution context. For example, creating a mutex owner on CPU1 and a migration-disabled waiter on CPU0 can trigger the following warning: proxy_migrate_repro: donor blocking on CPU0 with migration disabled proxy_migrate_repro: donor moved from CPU0 to CPU1 WARNING: kernel/sched/core.c:3389 at set_task_cpu+0x1d3/0x280 ... Call Trace: try_to_wake_up+0x43f/0x780 __mutex_unlock_slowpath+0x330/0x540 owner_fn+0x9f/0xc0 [proxy_migrate_repro] ... proxy_migrate_repro: donor woke on CPU0, task_cpu=0 proxy_migrate_repro: completed Exclude blocked proxy donors from the warning. The proxy wakeup path restores an executable placement before clearing the blocked state. Fixes: b049b81bdff6 ("sched: Handle blocked-waiter migration (and return migration)") Signed-off-by: Andrea Righi Signed-off-by: Peter Zijlstra (Intel) Acked-by: John Stultz Link: https://patch.msgid.link/20260915184101.2621252-1-arighi@nvidia.com commit 88aed0422f39b22406f35f1e758cea25e7bbcfb5 Author: Vinay Belgaumkar Date: Fri Sep 4 11:16:24 2026 -0700 perf: Fix null pointer access in is_include_guest_event() A typical module unload occurring event when there is an active perf connection leads to freeing of the pmu pointer. The call log is something like: .. __pmu_detach_event pmu_detach_event pmu_detach_events perf_pmu_unregister .. __pmu_detach_event() sets event->pmu to null. When the perf connection finally is closed, the following stack trace is observed: Oops: general protection fault, kernel NULL pointer dereference ... RIP: 0010:_free_event+0x3e/0x370 ... Call Trace: ... perf_event_release_kernel+0x260/0x2d0 perf_release+0x12/0x20 A call to mediated_pmu_unaccount_event() inside _free_event() is the root cause of this crash. Adding a check inside is_include_guest_event() ensures we don't accidentally access a null pmu ptr. In addition to this, we will now call mediated_pmu_unaccount_event() before clearing the pmu ptr so that nr_include_guest_events counts are maintained correctly. Fixes: eff95e170275 ("perf: Add APIs to create/release mediated guest vPMUs") Assisted-by: Claude:Claude-Sonnet-5 Signed-off-by: Vinay Belgaumkar Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260904181625.1394082-1-vinay.belgaumkar@intel.com commit 70194dc37670bd08e44b471389861cc01bd3a3c9 Author: Aohan Mei Date: Mon Sep 14 19:51:47 2026 +0800 netfilter: nf_tables: skip expired catchall elements on insert and delete nft_setelem_catchall_insert() looks up duplicates with nft_set_elem_active() only, while nft_set_catchall_lookup() and the dump path additionally skip expired elements. Once a catchall element with a timeout expires, this predicate drift makes it invisible to userspace dumps, yet it still blocks re-insertion: with NLM_F_EXCL the request fails with -EEXIST, and without it the request reports success but silently inserts nothing. The stale entry only goes away when the (user-tunable) gc interval elapses, so the catchall rule may silently stop matching for an arbitrarily long time after its first expiration. The delete path shows the same drift: nft_setelem_catchall_deactivate() picks the first active-next entry in the catchall list, so with an expired entry still pending GC it retires the stale entry instead of the fresh one, and it deactivates an element that userspace no longer sees instead of failing with -ENOENT. Align both walks with the lookup and dump predicates: only an element that is active and not expired counts as a duplicate or delete candidate, using the per-netns timestamp taken at transaction start, in line with the set backend .insert/.deactivate and catchall GC sync paths. Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Fixes: aaa31047a6d2 ("netfilter: nftables: add catch-all set element support") Assisted-by: CodeBuddy:Kimi-K3 Signed-off-by: Aohan Mei Signed-off-by: Pablo Neira Ayuso commit f615c80a5d3e16eee2377c63e20ae79038ae3376 Merge: 5179241521401e 1970fc4ecb52da Author: Christian Brauner Date: Fri Sep 18 11:20:59 2026 +0200 Merge patch series "binfmt: fixes for kres reports" Christian Brauner says: I asked Chris to run his kres tooling on the binfmt with bpf changes merged for this cycle. It found two issues that are fixed in this series. I reproduced both of them. * patches from https://patch.msgid.link/20260918-work-binfmt_misc-fixes-v1-0-647b24bc1c46@kernel.org: binfmt_misc: fix racy checks in bpf set_interp kfuncs binfmt_misc: fix OOB read in bpf_binprm_select_interp() Link: https://patch.msgid.link/20260918-work-binfmt_misc-fixes-v1-0-647b24bc1c46@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 1970fc4ecb52dabce2e57f9be721964b936a052d Author: Chris Mason Date: Fri Sep 18 11:20:00 2026 +0200 binfmt_misc: fix racy checks in bpf set_interp kfuncs bpf_binprm_set_interp() tests path[0] != '/' on the buffer its load program passes and then reads the same buffer again to copy it with kmemdup_nul(). The buffer can be a BPF map value that another CPU rewrites between the two reads. If byte 0 is overwritten in that window, the kfunc stages a relative or empty interpreter path. The staged path is not checked again, so open_exec() resolves a relative path against the working directory of the task doing the exec. bpf_binprm_set_interp_arg() has the same pattern for its "!len" test and can stage an empty argument, which the interpreter then receives as an empty argv entry. The verifier checks the path and path__sz pair with BPF_READ | BPF_WRITE, so a writable array map value is an accepted argument. bpf(BPF_MAP_UPDATE_ELEM) on an array map copies the new value over the old one in place and takes no lock. Both kfuncs are KF_SLEEPABLE and allocate with GFP_KERNEL between the test and the copy, so the task can sleep inside the window: load program bpf(BPF_MAP_UPDATE_ELEM) bpf_binprm_set_interp() strnlen(path, path__sz) path[0] != '/' is false kmemdup_nul(path, len, GFP_KERNEL) allocation may sleep array_map_update_elem() copy_map_value() rewrites byte 0 copy reads path again bm_bpf_stage_selection() The test in the load program's column proves what byte 0 held only at the moment the test ran. The map update takes no lock, so it can store to byte 0 right after. kmemdup_nul() then copies the rewritten bytes, and bm_bpf_stage_selection() publishes them as bprm->bpf_interp. The staged path is not checked again on its way to open_exec(): load_misc_binary() entry_select_interpreter() returns bprm->bpf_interp unchanged build_interp_argv() copy_string_kernel() copies it as argv[0] bprm_change_interp() kstrdup() entry_open_interpreter() open_exec() unless a bound file is staged or the entry is an 'F' entry None of these functions tests the first byte, and load_misc_binary() hands the pointer to nothing else. In bpf_binprm_set_interp_arg(), strnlen() finds a non-zero len, a NUL is then stored to byte 0, and build_interp_argv() later copies the empty bprm->bpf_interp_arg with copy_string_kernel(). The handler's own load program has to pass a writable map value, and something has to store into it while the kfunc runs. The allocation can sleep inside the window, and with a BPF_F_MMAPABLE array the store is a plain user space write into the mapped value, so a loop can hit it without a single bpf() call. Check the private copy in both kfuncs, so that the string that gets staged is the string that was checked. bpf_binprm_select_interp() already looks its name up in a private copy for the same reason. The remaining tests work on path__sz, arg__sz or the local len, and the copy length is len, so the copy stays inside the extent the verifier checked. Results of bpf_binprm_set_interp() with the check on the copy: - A NUL stored to byte 0 fails interp[0] != '/' and gets -EINVAL. - For len == 0, kmemdup_nul() returns an empty string, so an empty path still gets -EINVAL. - A NUL stored further into the string only shortens it to another absolute path, or another non-empty argument, that the program could have passed anyway. - A path that both lacks the leading '/' and is PATH_MAX or longer now gets -ENAMETOOLONG instead of -EINVAL. - A path that is empty or lacks the leading '/' is now rejected after the copy rather than before it, so such a call makes an allocation and returns -ENOMEM instead of -EINVAL if that allocation fails. bpf_binprm_set_interp_arg() still rejects an empty argument before allocating, so its results are unchanged apart from the raced case fixed here. Both new checks run before the previously staged string is freed or replaced. A failing call frees only its own allocation and leaves the earlier selection in place, as the -ENOMEM path already does. Fixes: b4bfe2f6b011 ("binfmt_misc: add binfmt_misc_ops bpf struct_ops") Signed-off-by: Chris Mason Link: https://patch.msgid.link/20260918-work-binfmt_misc-fixes-v1-2-647b24bc1c46@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 4f948b5949d2e418b4506752e7c514fe91bd408b Author: Chris Mason Date: Fri Sep 18 11:19:59 2026 +0200 binfmt_misc: fix OOB read in bpf_binprm_select_interp() bpf_binprm_select_interp() checks the name its load program passes with strnlen(name, name__sz) and then hands the same buffer to binfmt_misc_find_interp(), which compares it with an unbounded strcmp(). The buffer can be a BPF map value that another CPU rewrites between the two reads. If the terminating NUL is overwritten in that window, strcmp() reads past the name__sz bytes the verifier checked. That is an out-of-bounds read of up to 31 bytes of whatever follows the checked name__sz bytes. The verifier checks the name and name__sz pair with BPF_READ | BPF_WRITE, so a writable array map value is an accepted argument. bpf(BPF_MAP_UPDATE_ELEM) on an array map copies the new value over the old one in place and takes no lock. The NUL that strnlen() finds can be overwritten before strcmp() reads the buffer again: CPU0 CPU1 bpf_binprm_select_interp() strnlen(name, name__sz) finds the NUL inside name__sz bpf(BPF_MAP_UPDATE_ELEM) array_map_update_elem() copy_map_value() overwrites the NUL binfmt_misc_find_interp() strcmp(interp->name, name) reads past name__sz strnlen() proves that a NUL lies inside name__sz only at the moment it runs. The map update on CPU1 takes no lock, so it can store over the NUL right after. The lookup on CPU0 then walks the live buffer again, once per bound interpreter: fs/binfmt_misc.c:binfmt_misc_find_interp list_for_each_entry(interp, interps, list) if (!strcmp(interp->name, name)) return interp; strcmp() stops at the first mismatch or at the end of interp->name. bm_entry_add_interp() caps a bound name at BINFMT_MISC_INTERP_NAME_MAX (32) bytes, so strcmp() reads at most 33 bytes of name. The smallest name__sz the kfunc accepts is 2, which leaves up to 31 bytes read beyond the checked extent. The handler's own load program has to pass a writable map value, and something has to store into it while the kfunc runs. The window between strnlen() and strcmp() is short, but with a BPF_F_MMAPABLE array the store is a plain user space write into the mapped value, so a loop can hit it without a single bpf() call. Copy the name into a stack buffer of BINFMT_MISC_INTERP_NAME_MAX + 1 bytes, terminate it, and look up the copy. The memcpy() length is below name__sz, so the copy stays inside the extent the verifier checked, and the BPF buffer is not read again afterwards. Return -ENOENT first for a name longer than BINFMT_MISC_INTERP_NAME_MAX. bm_entry_add_interp() rejects a longer name, and the only other binding site attaches the empty name. No entry can bind such a name, so that lookup already ended in -ENOENT and no result changes. Check the first byte of the copy and return -EINVAL if it is NUL, as the existing "!len" test does for an empty name. Only an 'F' entry binds the empty name and a 'B' entry cannot carry 'F', so without that check a racing store of NUL to byte 0 would look up a name no entry binds and end in -ENOENT rather than -EINVAL. A NUL stored further into the name only shortens it to another name the program could have passed anyway. binfmt_misc_find_interp() itself is left alone: entry_attach_interpreter() calls it with a kernel string, and this kfunc now calls it with a private copy. Fixes: 6ec7c96bee30 ("binfmt_misc: let a 'B' entry bind its interpreters") Signed-off-by: Chris Mason Link: https://patch.msgid.link/20260918-work-binfmt_misc-fixes-v1-1-647b24bc1c46@kernel.org Signed-off-by: Christian Brauner (Amutable) commit 207d591c353201f3bd3e0c89bb7d44a849c8fd59 Author: Naman Gulati Date: Sat Sep 12 01:10:51 2026 +0000 netfilter: ctnetlink: fix suspicious RCU usage in expect_iter_name expect_iter_name() is invoked by nf_ct_expect_iterate_net() under spin_lock_bh(&nf_conntrack_expect_lock). It does not hold rcu_read_lock(). When accessing exp->helper with rcu_dereference() in syzbot's report, lockdep warns: ============================= WARNING: suspicious RCU usage syzkaller #0 Not tainted ----------------------------- net/netfilter/nf_conntrack_netlink.c:3393 suspicious rcu_dereference_check() usage! locks held by syz-executor381/5628: 2, last CPU#1: #0: ffffffff9aee42a0 (nfnl_subsys_ctnetlink_exp){+.+.}-{4:4}, at: nfnetlink_rcv_msg+0xa69/0x12b0 #1: ffffffff8ea74d58 (nf_conntrack_expect_lock){+...}-{3:3}, at: nf_ct_expect_iterate_net+0x38/0x180 Call Trace: dump_stack_lvl+0xe8/0x150 lockdep_rcu_suspicious+0x140/0x1d0 expect_iter_name+0xfb/0x100 nf_ct_expect_iterate_net+0xf2/0x180 ctnetlink_del_expect+0x45d/0x640 nfnetlink_rcv_msg+0xcc2/0x12b0 netlink_rcv_skb+0x226/0x4a0 nfnetlink_rcv+0x2b9/0x28c0 netlink_unicast+0x7bd/0x940 netlink_sendmsg+0x813/0xb40 ____sys_sendmsg+0x54e/0x850 ___sys_sendmsg+0x2a5/0x360 __sys_sendmsg+0x2a5/0x360 do_syscall_64+0x166/0x520 entry_SYSCALL_64_after_hwframe+0x77/0x7f Use rcu_dereference_protected() with lockdep_is_held() on nf_conntrack_expect_lock instead, similar to expect_iter_me() in nf_conntrack_helper.c. Fixes: f01794106042 ("netfilter: nf_conntrack_expect: use expect->helper") Reported-by: syzbot+4bd730aede2791e40bdf@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6aa4a377.f81106d8.2ab401.0024.GAE@google.com/T/#u Signed-off-by: Naman Gulati Signed-off-by: Pablo Neira Ayuso commit e290145564886d6a3038810c621f738c1fe9fa51 Author: Julian Anastasov Date: Fri Sep 11 14:43:15 2026 +0300 ipvs: revalidate ihl before icmp_send While the outer IP header is already pulled into the skb head, we must be careful and revalidate the embedded headers after reading them from the skb frags to prevent possible out-of-bounds access. One such place reported by Sashiko is ip_vs_in_icmp() where local process can change the ihl field and after pskb_may_pull() we can see larger value. Even if icmp_send() has checks to prevent out-of-bounds access, play safe and add check to drop the packet if the ihl field is changed. As the outer headers are pulled, make sure the transport header is updated too, it was used before commit 7fcc2fe39fed ("net: icmp: avoid invalid transport header access in icmp_send tracepoint") Fixes: f2edb9f7706d ("ipvs: implement passive PMTUD for IPIP packets") Link: https://sashiko.dev/#/patchset/20260806105211.34622-1-ja%40ssi.bg Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso commit a311a898172743558b82f6035ef2aa8c310a4223 Author: Karl Mehltretter Date: Thu Sep 10 22:02:28 2026 +0200 netfilter: nft_synproxy: use the family-aware checksum helper nft_synproxy_do_eval() verifies the TCP checksum before it switches on skb->protocol. It uses nf_ip_checksum(), which constructs an IPv4 pseudo header and relies on the IPv4 header checksum when folding the whole skb. Neither operation is valid for an IPv6 packet. A correctly checksummed IPv6 segment can therefore fail verification when it reaches the hook as CHECKSUM_NONE or, at NF_INET_LOCAL_IN, CHECKSUM_COMPLETE. nft_synproxy_do_eval() returns NF_DROP before nft_synproxy_eval_v6() can send a SYN-ACK. nft_synproxy_validate() deliberately admits NFPROTO_IPV6 and NFPROTO_INET, and the xtables counterpart ip6t_SYNPROXY.c already calls nf_ip6_checksum(). Use nf_checksum() with nft_pf() so the checksum helper dispatches to the packet family's implementation. Fixes: ad49d86e07a4 ("netfilter: nf_tables: Add synproxy support") Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Pablo Neira Ayuso commit 82313c169eddc02b1bf5ba6b427803e272d3ec42 Author: Luxiao Xu Date: Sun Sep 6 21:29:55 2026 +0800 netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read rt_mt6_check() permits rules to be configured with rtinfo->addrnr == 0 even when address matching (IP6T_RT_FST_MASK) is requested. In the IP6T_RT_FST_NSTRICT path, rt_mt6() evaluates packet routing addresses against rtinfo->addrs[i] and terminates backwards at the bottom of the loop: if (ipv6_addr_equal(ap, &rtinfo->addrs[i])) { i++; } if (i == rtinfo->addrnr) break; When addrnr is 0, if the first packet address matches rtinfo->addrs[0], i is incremented to 1. Because i is now strictly greater than addrnr (0), the loop termination condition (i == rtinfo->addrnr) is bypassed and will never be satisfied. If a crafted IPv6 packet contains matching routing addresses, i will advance past IP6T_RT_HOPS (16). The subsequent call to ipv6_addr_equal() reads beyond struct ip6t_rt, triggering UBSAN/KASAN out-of-bounds warnings or kernel panics. Fix this by: 1. Rejecting rules in rt_mt6_check() where IP6T_RT_FST_MASK is set but rtinfo->addrnr is zero. 2. In rt_mt6(), moving the termination condition (i < rtinfo->addrnr) into the for-loop header condition and removing the backwards break at the end of the loop body. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Florian Westphal Assisted-by: LLM Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Signed-off-by: Pablo Neira Ayuso commit 1b9b5323725e458906c7620a3bc10398b51ad954 Author: Weiming Shi Date: Sun Sep 6 16:44:10 2026 +0800 netfilter: ip6t_rpfilter: reject routes without inet6_dev ip6_route_lookup() can return an error-free route whose rt6i_idev is NULL. Lowering an external nexthop device's MTU below IPV6_MIN_MTU tears down its inet6_dev while fib6_ifdown() leaves routes using nexthop objects in the FIB. An unprivileged user can construct this state with rtnetlink in a private user and network namespace, then trigger a NULL dereference through an IPv6 rpfilter lookup: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: rpfilter_mt (net/ipv6/netfilter/ip6t_rpfilter.c:75) Call Trace: ip6t_do_table (net/ipv6/netfilter/ip6_tables.c:316) nf_hook_slow (net/netfilter/core.c:619) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6216) process_backlog (net/core/dev.c:6680) __napi_poll (net/core/dev.c:7739) net_rx_action (net/core/dev.c:7959) handle_softirqs (kernel/softirq.c:622) do_softirq.part.0 (kernel/softirq.c:523) __local_bh_enable_ip (kernel/softirq.c:450) __dev_queue_xmit (net/core/dev.c:4913) packet_sendmsg (net/packet/af_packet.c:3139) __sys_sendto (net/socket.c:2252) __x64_sys_sendto (net/socket.c:2259) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt Reject routes without an inet6_dev immediately after lookup. Such routes are not eligible for reverse-path filtering, and the check protects all later rt6i_idev dereferences. Fixes: e26f9a480fb6 ("netfilter: add ipv6 reverse path filter match") Reported-by: co+459f67f4d8af8ce6@bugs.sh Closes: https://lore.kernel.org/all/VtWUkE8QzJt5CroTj2V2v3ZQ0gwbXZ7nq7I3@bugs.sh/ Suggested-by: Florian Westphal Assisted-by: Claude:gpt-5 Cc: stable@vger.kernel.org Signed-off-by: Weiming Shi Signed-off-by: Pablo Neira Ayuso commit 9461613afc59acef44a0071b0dd5075f6e993ffe Author: Florian Westphal Date: Thu Sep 3 02:41:46 2026 +0200 netfilter: nfnetlink_queue: hold nfnl mutex in event notifier We must serialize the release notifier and the config netlink function. A concurrent thread can issue close() which can call the release function while unrelated socket processes UNBIND request for same portid: Oops: general protection fault, [..] RIP: 0010:__instance_destroy+0x60/0x210 [nfnetlink_queue] Call Trace: nfqnl_recv_config+0x9b0/0xdc0 [nfnetlink_queue] nfnetlink_rcv_msg+0x7c2/0xeb0 ? __pfx_nfnetlink_rcv_msg+0x10/0x10 After this, parallel UNBIND and URELEASE events are impossible. This change isn't nice, but its the shortest fix given instances are not refcounted and the nfnetlink config callback drops the rcu read lock early due to need for sleeping allocations. Fixes: 7af4cc3fa158 ("[NETFILTER]: Add "nfnetlink_queue" netfilter queue handler over nfnetlink") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso commit d644b23afe1ef509c9961a6d84a093c2587edf02 Author: Jérémy Jean Date: Tue Aug 18 20:00:15 2026 +0000 netfilter: flowtable: publish HW_DEAD after worker is done flow_offload_work_del() sets NF_FLOW_HW_DEAD before the work handler clears NF_FLOW_HW_PENDING. Once a flow is both HW_DYING and HW_DEAD, a concurrent garbage collection pass can remove it and schedule it for RCU freeing. The offload worker holds neither an RCU read lock nor a reference to the flow. If it is preempted after publishing HW_DEAD, the RCU callback can free the flow before the worker resumes and clears HW_PENDING, resulting in a use-after-free. Move HW_DEAD publication to the common worker epilogue after the pending bit is cleared, making it the final flow access by destroy work. Order all preceding flow accesses before publishing the bit that allows garbage collection to free the object. Fixes: 2c8897953f3b ("netfilter: flowtable: Add pending bit for offload work") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Pablo Neira Ayuso commit d54a489c8c4b627775445d54a6cbd32f209bda8f Author: Frank Wunderlich Date: Thu Sep 17 17:37:11 2026 +0200 gpiolib: use of_node_name if line-name is missing Until v7.0, GPIO hogs inherited the DT node name when no line-name property was specified. This was implemented as a fallback in of_parse_own_gpio(). Commit d1d564ec4992 ("gpio: move hogs into GPIO core") moved hog parsing into the GPIO core and removed this fallback. Consequently, GPIO hogs without a line-name property are now displayed with a ? in /sys/kernel/debug/gpio. Restore the old fallback. Fixes: d1d564ec4992 ("gpio: move hogs into GPIO core") Signed-off-by: Frank Wunderlich Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260917153712.134367-1-linux@fw-web.de Signed-off-by: Bartosz Golaszewski commit 5179241521401ef364294128bb43cdbce7252457 Author: Christian Brauner Date: Thu Sep 17 13:20:25 2026 +0200 fs: don't create the private nullfs mount under namespace_sem init_mount_tree() mounts the mutable rootfs on top of nullfs via LOCK_MOUNT_EXACT(). That declares a pinned mountpoint with a cleanup attribute in the scope of the whole function so the nullfs root inode lock and namespace_sem are only dropped when init_mount_tree() returns. This became a problem when the private nullfs instance for kthreads was added. kern_mount() allocates a new superblock and alloc_super() takes the new s_umount with SINGLE_DEPTH_NESTING and then shrinker_mutex via shrinker_alloc(). Doing that with namespace_sem held teaches lockdep the dependency namespace_sem -> s_umount/1 -> shrinker_mutex With CONFIG_SHRINKER_DEBUG shrinker_debugfs_rename() takes the debugfs directory inode lock under shrinker_mutex every time a block device is mounted and lock_mount_exact() takes namespace_sem under the inode lock of the mountpoint for every mount. So mounting anything on debugfs, e.g. the tracefs automount on /sys/kernel/debug/tracing, closes the cycle: WARNING: possible circular locking dependency detected 7.3.0-rc3+ #17 Not tainted ------------------------------------------------------ rasdaemon/4449 is trying to acquire lock: (namespace_sem){++++}-{4:4}, at: lock_mount_exact+0x4c/0x308 but task is already holding lock: (&sb->s_type->i_mutex_key#17){++++}-{4:4}, at: lock_mount_exact+0x3c/0x308 which lock already depends on the new lock. ... Chain exists of: namespace_sem --> shrinker_mutex --> &sb->s_type->i_mutex_key#17 This can't actually deadlock. init_mount_tree() runs single-threaded during early boot before any other task exists and nothing allocates a superblock under namespace_sem after that. But lockdep can't know that and disables itself for the rest of the boot. Move mounting the rootfs on top of nullfs into a helper so the locks are dropped when it returns. Fixes: 32750c77e811 ("fs: start all kthreads in nullfs") Reported-by: Zenghui Yu Closes: https://lore.kernel.org/15174353-3f4a-a1ca-5bd1-ea2a4c77828e@huawei.com Link: https://patch.msgid.link/20260917-atemtechnik-bleichen-befassen-9a57db01baf0@brauner Signed-off-by: Christian Brauner (Amutable) commit a363c62a653cc8b3e21da9545fa4e028ef50f9c3 Author: Longlong Xia Date: Sun Aug 23 12:40:51 2026 +0800 mm/hugetlb: do not dissolve gigantic pages without runtime support dissolve_free_hugetlb_folio() doesn't check hstate_is_gigantic_no_runtime(h) though remove_hugetlb_folio()/ update_and_free_hugetlb_folio() silently bail for such folios, so it frees a still-listed folio and, on vmemmap restore failure, the add_hugetlb_folio() rollback corrupts the free list. Link: https://lore.kernel.org/20260823044118.1097121-2-xialonglong2025@163.com Fixes: 6eb4e88a6d27 ("hugetlb: create remove_hugetlb_page() to separate functionality") Signed-off-by: Longlong Xia Signed-off-by: Andrew Morton Assisted-by: Codex:gpt-5.6-sol Acked-by: Muchun Song Cc: David Hildenbrand Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: commit 46bc52d13594848023e681860df8700c8db14354 Author: Linkui Xiao Date: Wed Sep 16 20:53:16 2026 +0800 ipv4: fib: fix data-race and stale genid check around nh->nh_saddr fib_select_multipath() compares nexthop_nh->nh_saddr against the flow source address with no lock held, while fib_info_update_nhc_saddr() stores a new value from another CPU as soon as the preferred source address of the egress device changes. Commit 195374d89368 ("ipv4: fib: annotate races around nh->nh_saddr_genid and nh->nh_saddr") added WRITE_ONCE() on the store side and READ_ONCE() in fib_result_prefsrc() after syzbot reported BUG: KCSAN: data-race in fib_select_path / fib_select_path but it only covered that reader. fib_select_multipath(), reached from fib_select_path(), is a second lockless reader of nh->nh_saddr and was left bare. Moreover, nh_saddr is only meaningful when nh_saddr_genid matches dev_addr_genid, as established by commit 436c3b66ec98 ("ipv4: Invalidate nexthop cache nh_saddr more correctly."). fib_select_multipath() skips that validation, so it can score a nexthop using a stale source address and skew the ECMP selection. Annotate both reads with READ_ONCE() and refresh the cached source address via fib_info_update_nhc_saddr() when the genid does not match, mirroring fib_result_prefsrc(). Fixes: 32607a332cfe ("ipv4: prefer multipath nexthop that matches source address") Signed-off-by: Linkui Xiao Reviewed-by: Ido Schimmel Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260916125316.988044-1-xiaolinkui@126.com Signed-off-by: Jakub Kicinski commit 651010592bdce7005c1179498327e51bfc4fe1a5 Author: Zhang Yunfei Date: Fri Sep 11 17:11:23 2026 +0800 net: txgbe: fix FDIR filter restore for VF rules txgbe_fdir_filter_restore() reprograms every filter from txgbe->fdir_filter_list after a reset. It extracts the ring part of filter->action with ethtool_get_flow_spec_ring() and maps it onto a PF rx ring, silently dropping the VF part of the cookie that txgbe_add_ethtool_fdir_entry() stores there (input->action = fsp->ring_cookie). For a rule directed at a VF, restore therefore reprograms the filter to the PF queue with the same ring index: after any down/up or txgbe_reinit_locked(), traffic matching the rule is steered to the PF instead of the VF. Handle VF rules the same way txgbe_add_ethtool_fdir_entry() does: validate vf against wx->num_vfs and ring against wx->num_rx_queues_per_pool, and map the ring onto the absolute queue index ((vf - 1) * wx->num_rx_queues_per_pool) + ring. Fixes: 7a91722e0dd4 ("net: txgbe: Support the FDIR rules assigned to VFs") Cc: stable@vger.kernel.org Signed-off-by: Zhang Yunfei Link: https://patch.msgid.link/20260911091123.798931-1-zhangyunfei1@kylinos.cn Signed-off-by: Jakub Kicinski commit 2ec28c09b320ba241bea8a70ee5cb9ccf4a099e8 Author: Aldo Ariel Panzardo Date: Tue Sep 15 14:30:50 2026 -0300 vsock: ignore empty child namespace mode writes __vsock_net_mode_string() returns success without updating new_mode when the transfer length is zero. Its caller then reads the uninitialized enum and may permanently store a stack-derived value in the write-once child mode. Return before calling __vsock_net_mode_string() when *lenp is zero so that the helper is never invoked with nothing to parse and new_mode is never read uninitialized. This also prevents an empty write from locking the current mode. Fixes: eafb64f40ca4 ("vsock: add netns to vsock core") Cc: stable@vger.kernel.org Reviewed-by: Luigi Leonardi Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Stefano Garzarella Reviewed-by: Bobby Eshleman Link: https://patch.msgid.link/20260915173050.3176344-1-qwe.aldo@gmail.com Signed-off-by: Jakub Kicinski commit 94f69bfa1897c9d5a14bb54e3ecc5188a00daf6e Merge: cd011719ba564a 2ac2fe765ef475 Author: Dave Airlie Date: Fri Sep 18 11:22:42 2026 +1000 Merge tag 'amd-drm-fixes-7.3-2026-09-17' of https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.3-2026-09-17: amdgpu: - SMU 14.x fix - DC IRQ fix - Runtime PM fix for P2P - RAS fix - PCIe reporting fix - DCN 6 fix - Device removal fix - DC MALL fix amdkfd: - GC 12.x fixes - Boundary checks - Mapping clear fix Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patch.msgid.link/20260917201213.3880863-1-alexander.deucher@amd.com commit cd011719ba564a5d72ee6474cec2ecd66362d150 Merge: c24f824f0bbfd6 a26204be587c57 Author: Dave Airlie Date: Fri Sep 18 11:08:18 2026 +1000 Merge tag 'drm-intel-fixes-2026-09-17' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes drm/i915 fixes for 7.3-rc4: - Revert a commit touching registers that don't necessarily exist - Check for negative numbers before passing to BIT() Signed-off-by: Dave Airlie From: Jani Nikula Link: https://patch.msgid.link/3f86e0ede95fb3d52053934ac43c5271812428f5@intel.com commit c24f824f0bbfd6e9ab376795d8e5862c66766cfa Merge: b15e54761a0dd5 f0e9f963a3d209 Author: Dave Airlie Date: Fri Sep 18 10:54:57 2026 +1000 Merge tag 'drm-xe-fixes-2026-09-17' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Couple shrinker related fixes plus a series of patches fixing several xe_mmio_gem issues around fault handler and destroy path. Signed-off-by: Dave Airlie From: Rodrigo Vivi Link: https://patch.msgid.link/aqvoKaPuLLPBGayA@intel.com commit b4e875d397da451fb4e9c573ff4b86db53caba05 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 18 01:32:18 2026 +0200 libbpf: Reject truncated ldimm64 CO-RE relocations CO-RE relocation of an ldimm64 instruction operates on two instruction slots. A malformed BPF ELF can end a function after the first slot and attach a CO-RE relocation to it. libbpf allocates the instruction array according to the function symbol size, so the shared relocation code would then access beyond the allocation. Reject a terminal ldimm64 in libbpf's relocation loop, where the program length is available, before resolving or applying the relocation. Both resolved and unresolved relocations validate the absent second slot, and unresolved relocation poisoning would additionally write past the array. The in-kernel caller is protected by the verifier's early instruction-stream check before it applies CO-RE relocations. Fixes: eacaaed784e2 ("libbpf: Implement enum value-based CO-RE relocations") Reported-by: Sashiko Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/20260914140852.03DA21F0089B@smtp.kernel.org Link: https://patch.msgid.link/20260917233222.2542500-11-memxor@gmail.com Signed-off-by: Eduard Zingerman commit 04ae4ffc57a6b7a8215779f0e9c536cacda9f761 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 18 01:32:17 2026 +0200 selftests/bpf: Check callback map value lock identity Add a verifier test which retains a map value from an outer callback and then acquires a lock through an inner callback value before attempting to release the outer callback value. Both values can denote different elements, so the verifier must reject the mismatched unlock. Also exercise callbacks reached through two inner-map lookups. The lookup results share inner_map_meta but may refer to different one-element arrays, so their callback values must retain distinct lock identities. Extend the existing spin_lock failure table and reuse its array and inner-map fixtures to keep these cases alongside the other lock identity tests. Update the nested callback reference-leak expectation for the extra callback value ID. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://patch.msgid.link/20260917233222.2542500-10-memxor@gmail.com Signed-off-by: Eduard Zingerman commit 71919742c83c32afcccf06a7a28e28f3f55f21a2 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 18 01:32:16 2026 +0200 bpf: Assign lock identity to callback map values A nested bpf_for_each_map_elem() callback can unlock a different element of the same map: static long inner(void *map, int *key, struct value *v, struct value **outer_value) { bpf_spin_lock(&v->lock); bpf_spin_unlock(&(*outer_value)->lock); return 0; } static long outer(void *map, int *key, struct value *v, void *ctx) { bpf_for_each_map_elem(map, inner, &v, 0); return 0; } Both callback values currently have ID zero and the same map_ptr. process_spin_lock() compares those two fields, so it accepts the unlock even though the two callbacks can receive different map elements. Assign a fresh ID to every callback map value in the for-each, timer/workqueue, and task-work constructors. Copies of one callback argument retain its ID, so locking and unlocking through that argument continues to work. Distinct callbacks also get distinct IDs for single-element arrays, including inner arrays sharing inner_map_meta. Preserve map_uid for every inner-map lookup and compare it through check_ids() during state pruning. This preserves relationships between maps, keys, and values while allowing equivalent states with different lookup IDs to match. It avoids field-specific rules for when an inner map needs an identity. Move map_uid out of the metadata union and next to the other IDs, so register comparisons can use the existing memcmp() ranges and remap the IDs separately. Clear it when resetting a register or converting a map lookup result to a socket pointer. Shrink frameno to u8, which is enough for MAX_CALL_FRAMES, to make room without growing bpf_reg_state. Fixes: d0d78c1df9b1 ("bpf: Allow locking bpf_spin_lock global variables") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260917233222.2542500-9-memxor@gmail.com Signed-off-by: Eduard Zingerman commit 3440505aca926e726a26c0fd30356454334322bd Author: Kumar Kartikeya Dwivedi Date: Fri Sep 18 01:32:15 2026 +0200 selftests/bpf: Test CO-RE instruction poisoning restrictions Add raw CO-RE relocations that fail to resolve their target enum value. Place each supported and unsupported instruction form in dead code. Unsupported targets must fail relocation with a diagnostic even when they are unreachable. Supported ALU immediates, memory accesses, and ldimm64 instructions must still be poisoned and removed as dead code, allowing the program to load. Check that both halves of ldimm64 are poisoned. Load every instruction stream without relocations first to ensure that rejection is caused by the relocation rather than the original program. Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260917233222.2542500-8-memxor@gmail.com Signed-off-by: Eduard Zingerman commit 394ae398337c5f87e567f6cd63b937fc2b2f6ddc Author: Kumar Kartikeya Dwivedi Date: Fri Sep 18 01:32:14 2026 +0200 bpf: Restrict CO-RE poisoning to relocatable instructions CO-RE relocation records can name any instruction offset. When a relocation cannot be resolved, bpf_core_patch_insn() currently poisons its target before checking whether that instruction is a valid relocation target. Malformed metadata can therefore replace jumps, calls, exits, register-source arithmetic, or non-immediate loads instead of failing at the relocation step. Handle poisoning only after the instruction has passed the same class and operand-form checks used for a resolved relocation. Route invalid forms through the existing diagnostic and return a hard error. Keep poisoning supported instructions, including both halves of a plain ldimm64, so an unresolved relocation in dead code remains valid. Extend bpf_core_poison_insn() to poison both halves of ldimm64, and return its status directly from each validated instruction case. This avoids routing the success path through a common label and leaves the helper free to report errors. The shared relocation code applies this restriction to both libbpf and in-kernel CO-RE. Fixes: d7a252708dbc ("libbpf: Improve handling of failed CO-RE relocations") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260917233222.2542500-7-memxor@gmail.com Signed-off-by: Eduard Zingerman commit 968ee7c06b62f1ac4597c351a45c2219a678a458 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 18 01:32:13 2026 +0200 selftests/bpf: Test early in-kernel CO-RE relocation Add a raw program load with CO-RE relocation metadata but no func_info or line_info. Place the relocation in dead code and require the poisoning log, proving that the kernel processes standalone CO-RE metadata instead of silently skipping it. Also give a subprogram a relocatable immediate as its terminal instruction. Require the relocation's poisoning log before check_subprogs() rejects the resulting fall-through. With the old ordering, check_subprogs() rejects the original terminal instruction before CO-RE can emit the substitution log, so the test continues to distinguish the ordering after relocation target validation is tightened. Submit a trailing ldimm64 first slot with CO-RE metadata and require the early structural diagnostic. This exercises the check that protects relocation processing instead of the later regular instruction validation. Load the standalone instruction stream without relocation metadata first to ensure that CO-RE processing causes its poisoning diagnostic. Encode the fixed BTF metadata directly with the selftest BTF helpers. Suggested-by: Eduard Zingerman Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260917233222.2542500-6-memxor@gmail.com Signed-off-by: Eduard Zingerman commit c26e97721b172163042b98572fead234797f2c3c Author: Kumar Kartikeya Dwivedi Date: Fri Sep 18 01:32:12 2026 +0200 bpf: Apply CO-RE relocations before subprogram validation check_subprogs() verifies that each subprogram ends in an exit or an unconditional jump before in-kernel CO-RE relocations are applied. An unresolved relocation can then replace that terminal instruction with an invalid helper call. The resulting fall-through into another subprogram breaks the CFG invariant used by postorder and stack liveness analysis, which can write past their per-subprogram arrays. Apply CO-RE relocations immediately after preparing the program BTF, before subprogram discovery and validation. Keep func_info and line_info validation after subprogram discovery because those records depend on the complete subprogram layout. Reject an ldimm64 first slot at the end of the instruction stream before CO-RE can inspect its missing second slot. check_subprogs() previously rejected this form before relocation processing because it is not a valid subprogram terminator. Moving CO-RE ahead of check_subprogs() removes that implicit protection, so perform an explicit check before applying relocations. Include core_relo_cnt when deciding whether to prepare program BTF. A load that supplied only CO-RE relocation metadata previously skipped both BTF setup and relocation processing. Fixes: fbd94c7afcf9 ("bpf: Pass a set of bpf_core_relo-s to prog_load command.") Suggested-by: Andrii Nakryiko Suggested-by: Alexei Starovoitov Suggested-by: Eduard Zingerman Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260917233222.2542500-5-memxor@gmail.com Signed-off-by: Eduard Zingerman commit 2059d9af54f0d66deb237aa75d2ed28648df05a1 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 18 01:32:11 2026 +0200 selftests/bpf: Test packet pointer class displacement pruning Add two paths whose packet pointer ranges are individually compatible at a join but whose members have different relative displacements. The first path proves an eight-byte access through one member. On the second path, the same guard only proves that the access starts before data_end. An affected verifier prunes the second path and accepts the program. With packet pointer class displacement preserved, it explores that path and rejects the out-of-bounds access. Read the unknown offset and branch selector directly from XDP context fields, and force state checkpoints so the pruning attempt does not depend on the verifier checkpoint heuristics. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://patch.msgid.link/20260917233222.2542500-4-memxor@gmail.com Signed-off-by: Eduard Zingerman commit fd16449a9b3b31a8f18944c2f0e29e4e218ca2cf Author: Kumar Kartikeya Dwivedi Date: Fri Sep 18 01:32:10 2026 +0200 bpf: Preserve packet pointer class displacement in regsafe() regsafe() maps packet pointer IDs between states and checks that each current register range is a subset of the corresponding explored register range. It does not, however, preserve the displacement between registers that share a packet pointer ID. This is unsound because packet range is shared by ID. A bounds check on one class member updates every member, and a later access can consume the range through another member. Commit 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers") folded the fixed pointer offset into r64 and removed the old off equality check, so two individually narrower registers can prune even when their displacement has changed. The explored path can then license an out-of-bounds packet access on the pruned path. Require matching range bases for packet pointers with an ID. Together with the existing ID mapping, this preserves the displacement between members of each packet-pointer class without adding per-ID state. Packet pointers without an ID remain unaffected. Fixes: 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260917233222.2542500-3-memxor@gmail.com Signed-off-by: Eduard Zingerman commit 261b61d3735b042ae25634f795c4540be0fc140c Author: Kumar Kartikeya Dwivedi Date: Fri Sep 18 01:32:09 2026 +0200 bpf: Make post-verification instruction rewrites killable After do_check() returns, the verifier runs several instruction rewrite passes. Some of them patch or remove one instruction at a time. Each operation moves the remaining instruction and auxiliary-data arrays and adjusts all branch offsets, making the overall work quadratic in the program length. A privileged loader can submit 131072 unconditional jumps by zero followed by a valid return. Verification finishes quickly, but bpf_opt_remove_nops() then spends a long time removing each jump separately. Since this post-verification work neither checks for signals nor reschedules, a pending SIGKILL cannot terminate the task until the rewrite finishes. Make bpf_patch_insn_data() and verifier_remove_insns() common cancellation and rescheduling points. These helpers run from BPF_PROG_LOAD process context, and bpf_patch_insn_data() can already sleep while reallocating auxiliary data. Report interrupted constant blinding as -EINTR and propagate it through both JIT paths, including kernels that permit interpreter fallback. Other blinding failures retain the existing fallback behavior. This does not reduce the quadratic cost of the rewrite passes, but it makes the work preemptible and allows a killed loader to be torn down promptly. Fixes: 52875a04f4b2 ("bpf: verifier: remove dead code") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260917233222.2542500-2-memxor@gmail.com Signed-off-by: Eduard Zingerman commit b73bcf7c1ffba42894bc9b5cc6fb76ce12a82523 Merge: 39c6580765dad6 bae23d1ae62092 Author: Jakub Kicinski Date: Thu Sep 17 17:54:36 2026 -0700 Merge branch 'net-mlx5-sd-lag-and-devcom-stability-fixes' Tariq Toukan says: ==================== net/mlx5: SD LAG and devcom stability fixes This series by Shay fixes four bugs in the Socket Direct LAG and devcom subsystems, all related to initialization/teardown ordering and concurrent access to the LAG device. ==================== Link: https://patch.msgid.link/20260915113459.3934760-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit bae23d1ae62092c7f0ec6d5f7e1be5d164822638 Author: Shay Drory Date: Tue Sep 15 14:34:59 2026 +0300 net/mlx5: LAG, reload IB reps of LAG master before the rest In a shared-FDB LAG the master device creates the bond IB device; the other LAG members do not create their own, they populate a port inside the master's IB device. mlx5_lag_reload_ib_reps_unlocked() reloaded the members' IB reps in iteration order, with no guarantee the master is reloaded first. When a non-master member is reloaded before the master, it tries to populate its port in an IB device that has not been recreated yet. Hence, reload the master's IB reps first, then every other member. Fixes: 2b204cdb1206 ("net/mlx5: LAG, use xa_alloc to manage LAG device indices") Signed-off-by: Shay Drory Reviewed-by: Akiva Goldberger Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260915113459.3934760-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit e1e29ada2b938b13ba689a06a8bd8604564da2b3 Author: Shay Drory Date: Tue Sep 15 14:34:58 2026 +0300 net/mlx5: SD, unload reps on shared FDB create error path mlx5_lag_shared_fdb_create() sets sd_fdb_active on every group member before reloading the representors, so mlx5_lag_is_active() is already true and the guard in mlx5_esw_offloads_rep_load() does not skip the VF/SF reps. If the reload then fails, the error path clears sd_fdb_active and destroys the shared FDB, leaving the reps loaded while SD LAG is inactive - the state cited commit was written to prevent. Unload the reps in the error path as well. Fixes: 68c2dd59a6c7 ("net/mlx5: E-Switch, Tie rep load/unload to SD LAG state") Signed-off-by: Shay Drory Reviewed-by: Akiva Goldberger Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260915113459.3934760-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit d09e8f64653c93da5793c16be19330968f2a32e6 Author: Shay Drory Date: Tue Sep 15 14:34:57 2026 +0300 net/mlx5: devcom, Base component size on linked devices mlx5_devcom_comp_get_size() returns the component's kref count. That kref is bumped in mlx5_devcom_register_component() under comp_list_lock, before the comp_dev is linked onto comp_dev_list_head under comp->sem. The event broadcast (mlx5_devcom_locked_send_event()) walks that list. Hence, a caller can read the expected size, but send_event won't be sent to all peers. In the SD group registration path, this lets a member broadcast its role-election event over an incomplete list, electing a primary that never completes the group, is never marked ready, and leaves the group with a stale primary. Track the number of linked comp_devs in a dedicated counter, maintained under comp->sem together with the list add/remove, and return it from mlx5_devcom_comp_get_size(). Fixes: 9bb1ac80738a ("net/mlx5: devcom, Add component size getter") Signed-off-by: Shay Drory Reviewed-by: Akiva Goldberger Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260915113459.3934760-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit 1d653a183973f5283a3db5a38cd5e195eb152244 Author: David Carlier Date: Thu Sep 17 22:24:07 2026 +0100 fprobe: Terminate the fgraph_data list when the reservation is not filled fprobe_fgraph_entry() reserves shadow stack space for every fprobe with an exit handler, but only fills it for those whose entry handler returns 0. fgraph_reserve_data() does not clear the area, so fprobe_return() parses the unused tail as headers left over from an earlier call, and an exit handler can run twice or despite its entry handler asking to skip it. Write a zero word after the last entry to terminate the walk. A zeroed slot does not decode to a NULL fprobe on the arches that encode the header into one unsigned long, since arch_decode_fprobe_header_fp() ORs in FPROBE_HEADER_MSB_PATTERN, so make read_fprobe_header() return NULL for a zeroed slot. Link: https://lore.kernel.org/all/20260917212407.384468-1-devnexen@gmail.com/ Fixes: e0a384434ae1 ("tracing: fprobe: do not zero out unused fgraph_data") Cc: stable@vger.kernel.org Suggested-by: Masami Hiramatsu (Google) Signed-off-by: David Carlier Signed-off-by: Masami Hiramatsu (Google) commit 39c6580765dad6477fb2637f6f616e0d276aae65 Author: Heyang Tan Date: Mon Sep 14 10:05:21 2026 +0800 octeontx2-af: use seq_file for rsrc_alloc debugfs The rsrc_alloc debugfs reader writes rows directly to userspace without respecting the caller's read count. It also uses the current row length as the userspace stride, which can corrupt output when rows have different widths. Use seq_file to handle userspace buffer sizes, offsets, and partial reads, and write output columns directly to the seq_file buffer. Fixes: 23205e6d06d4 ("octeontx2-af: Dump current resource provisioning status") Signed-off-by: Heyang Tan Reviewed-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260914020521.146-1-thy15333007817@163.com Signed-off-by: Jakub Kicinski commit daf677c2c6449011ee695d55b48b5b2977a36f88 Author: Kyle Hendry Date: Tue Sep 15 10:39:20 2026 -0700 net: pcs: rzn1-miic: Fix config array initialization Fix memset parameters to initialize the entire DT value array Fixes: f39e968dc168a7bd ("net: pcs: rzn1-miic: Move configuration data to SoC-specific struct") Reviewed-by: Geert Uytterhoeven Signed-off-by: Kyle Hendry Reviewed-by: Lad Prabhakar Link: https://patch.msgid.link/20260915-rzn1-miic-fix-array-v5-1-b7173fd5b97d@reliablecontrols.com Signed-off-by: Jakub Kicinski commit 960ab631f3d8789586db71b9914b361059ddcb6e Author: Jamal Hadi Salim Date: Wed Sep 16 06:01:15 2026 -0400 selftests/tc-testing: add u32 manual table handle IDR tests 35fc: create a manual table with handle 801:, then add an auto-allocated table. Before the fix, the auto allocation reuses id 1 and hands out the same handle 0x80100000, aliasing the manual table; the test requires the manual 801: handle to keep exactly one entry in the dump. a6e8: with a live u32 table keeping the tc_u_common alive, add and delete a manual table with handle 901:, then re-add it. Unpatched, the delete leaks the raw-keyed IDR entry and the re-add fails with -ENOSPC; the test requires the re-add to succeed. Reviewed-by: Victor Nogueira Tested-by: hybris Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-LQFE.v1.20260911041746.2@mojatatu.com Signed-off-by: Jakub Kicinski commit 0a5f5d9e94dead312d32c366b917c64e552b72f7 Author: Jamal Hadi Salim Date: Wed Sep 16 06:01:14 2026 -0400 net/sched: cls_u32: fix manual hash table handle IDR aliasing A u32 hash table created with an explicit handle ('tc filter add ... handle 801: u32 divisor N') keys its IDR entry on the raw handle, while the destroy paths free it under handle2id(handle). The two key domains disagree for handles in the 0x800..0xFFF htid range: handle2id() folds them back into the auto-allocated id space (1..0x7FF). A manual table therefore leaves its raw-keyed IDR entry unreachable on delete (a permanent leak), and its delete can drop the idr entry of an unrelated live auto table. A later auto allocation can then hand out a handle that aliases the live manual table; u32_lookup_ht() first-match routes lookups and TCA_U32_LINK for that htid to the wrong table. Key the divisor-path alloc on handle2id(handle) so allocation and removal share one key domain. A manual handle that maps onto an id already in use is rejected with -ENOSPC, and auto allocation skips ids held by live manual tables. Conditions to recreate: ip link add test0 type dummy tc qdisc add dev test0 clsact tc filter add dev test0 ingress protocol ip pref 1 \ handle 801: u32 divisor 16 tc filter add dev test0 ingress protocol ip pref 2 u32 divisor 16 tc -d filter show dev test0 ingress | grep 'fh 801:' # unpatched: two live tables with handle 0x80100000 (the pref 2 root # hnode is auto-allocated id 1); patched: the auto hnode takes id 2. Also tested with a poc with a live u32 table on the block, add/delete a manual table 'handle 901: u32 divisor 1' twice; unpatched, the re-add fails with -ENOSPC because the raw key leaked on the first delete. Fixes: 73af53d82076 ("net: sched: cls_u32: Fix u32's systematic failure to free IDR entries for hnodes.") Reported-by: Sashiko (gemini + nipa) Closes: https://sashiko.dev/#/patchset/20260822222049.114526-1-jhs@mojatatu.com Reviewed-by: Victor Nogueira Tested-by: hybris Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-LQFE.v1.20260911041746.1@mojatatu.com Signed-off-by: Jakub Kicinski commit e7d3e2f46dd5a69046e6d95a0f189155a5516b93 Author: Chang S. Bae Date: Wed Sep 16 22:59:39 2026 +0000 x86/microcode/intel: Reject problematic loading on Granite Rapids systems Microcode updates can usually jump revisions. However, there is an erratum on Granite Rapids systems. If they "jump over" revision 0x1000405, they result in an #MC. Avoid it. Signed-off-by: Chang S. Bae Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Dave Hansen Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260916225939.1144524-1-chang.seok.bae@intel.com commit 5dd1818b15d98d4a20806cd00b1b40320b06004f Merge: b5a051f6b840d4 8697c431e297eb Author: Linus Torvalds Date: Thu Sep 17 16:53:26 2026 -0700 Merge tag 'for-next-keys-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd Pull key fixes from Jarkko Sakkinen. * tag 'for-next-keys-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: KEYS: encrypted: fix integer overflow of datablob_len KEYS: trusted: Fix tpm2_load_cmd() boundary check keys: translate request_key_auth pid for the reading procfs instance keys: fix lost wakeup when reaping a dead key type commit 8e0b235bd918d06f54ba8fddd2c3ddc36ca59c15 Author: Björn Töpel Date: Tue Sep 15 12:49:15 2026 +0200 eth: fbnic: Fix payload page pool error cleanup The payload page pool pointer contains an error pointer when its allocation fails. The cleanup path passes that error pointer to page_pool_destroy() instead of destroying the header page pool. This can dereference the error pointer and leave the header page pool allocated. Destroy the header page pool instead. Fixes: 8a11010fdd96 ("eth: fbnic: allocate unreadable page pool for the payloads") Reported-by: Sashiko Link: https://lore.kernel.org/netdev/178915061000.219967.7726187707862333281@kernel.org/ Signed-off-by: Björn Töpel Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260915104917.3978113-1-bjorn@kernel.org Signed-off-by: Jakub Kicinski commit 717e0a25036b6c92cecace30913b2d874a4c22b8 Author: Wentao Liang Date: Thu Sep 17 16:34:39 2026 +0000 cifs: Fix server use-after-free in cifs_chan_skip_or_disable() When a secondary channel is no longer supported by the server, cifs_chan_skip_or_disable() drops the channel reference with cifs_put_tcp_session() and then continues to use the server pointer by calling cifs_signal_cifsd_for_reconnect() on it and reading its primary_server pointer. cifs_put_tcp_session() can drop the last reference of the channel and tear it down, so both the channel and the primary server (whose reference is also dropped by cifs_put_tcp_session()) can be freed before they are signaled for reconnect. Signal the channel and the primary server and capture the primary server pointer before dropping the channel reference with cifs_put_tcp_session(). Fixes: f591062bdbf4 ("cifs: handle servers that still advertise multichannel after disabling") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Paulo Alcantara commit 28114992dd2f03724eb3d024839b3f9f299656d3 Author: Syed Saba Kareem Date: Thu Sep 17 22:21:49 2026 +0530 ASoC: amd: acp: enable TAS2783 and add RT712-VB SoundWire machine The ACP7.0 SoundWire machine table did not cover boards that combine TI TAS2783 smart amplifiers on SoundWire link 0 with a Realtek RT712-VB codec on link 1. In addition, the TAS2783 SoundWire codec driver was not selected by the AMD legacy SoundWire machine config, so it was not built for these platforms. Select SND_SOC_TAS2783_SDW from SND_SOC_AMD_LEGACY_SDW_MACH so the TAS2783 SoundWire codec driver is built together with the AMD legacy (no-DSP) SoundWire machine. Add a new link/address map, acp70_tas2783a_l0_rt712_vb_l1, describing the TAS2783 amplifiers on link 0 and the RT712-VB codec on link 1, and register a corresponding entry in snd_soc_acpi_amd_acp70_sdw_machines[]. The entry uses snd_soc_acpi_amd_sdca_is_device_rt712_vb() as its machine_check callback so it only matches platforms that actually expose the RT712-VB device. Signed-off-by: Syed Saba Kareem Link: https://patch.msgid.link/20260917165314.1880855-1-syed.sabakareem@amd.com Signed-off-by: Mark Brown commit fefd9480ec361969f1a836df46326a1801062c26 Author: Guangshuo Li Date: Sat Aug 8 21:41:37 2026 +0800 drm/nouveau: fix autosuspend cleanup during teardown nouveau_drm_device_init() calls pm_runtime_use_autosuspend(), but nouveau_drm_device_fini() does not call the matching pm_runtime_dont_use_autosuspend(). If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to the common device teardown path. This issue was found by manual code inspection. Fixes: 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260808134137.2864847-1-lgs201920130244@gmail.com commit 50e80e2bb5e2be8515205b9c496b9640ddefa434 Author: Weiming Shi Date: Tue Sep 15 01:02:07 2026 +0800 bpf: Skip unsettled links in link iterator bpf_link_prime() inserts a link into link_idr before anon_inode_getfile() succeeds and before bpf_link_settle() publishes the ID in link->id. bpf_link_by_id() treats such an ID-zero link as unsettled, but the link iterator takes a reference without this check. If anon_inode_getfile() then fails, the creator removes the ID and frees its still-private link directly. The iterator is left with a dangling reference and its next bpf_link_put() accesses freed memory. Treat ID-zero entries as transient in bpf_link_get_curr_or_next(), just as bpf_link_by_id() does. BUG: KASAN: slab-use-after-free in bpf_link_put Write of size 8 by task exp/384 Call Trace: bpf_link_put kernel/bpf/syscall.c:3372 bpf_link_seq_next kernel/bpf/link_iter.c:33 bpf_seq_read kernel/bpf/bpf_iter.c:158 vfs_read fs/read_write.c:572 ksys_read fs/read_write.c:716 do_syscall_64 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:121 Kernel panic - not syncing: KASAN: panic_on_warn set ... Fixes: 9f8836127308 ("bpf: Add bpf_link iterator") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260914170206.170723-2-bestswngs@gmail.com commit f7eae6d8d768fabd6b59779ca7da79e02c74e113 Author: Jonghyuk Kim(MalHyuk) Date: Wed Sep 2 10:27:16 2026 +0900 drm/nouveau: RCU-free the scheduler-containing nouveau_sched struct nouveau_sched embeds a struct drm_gpu_scheduler (base). nouveau_sched_destroy() calls nouveau_sched_fini() (which does drm_sched_fini(&sched->base)) and then frees the object with plain kfree(sched). drm_sched_fence_get_timeline_name() returns fence->sched->name, and the scheduler fence keeps a .release callback so it is not ops-detached on signalling. A finished fence exported to userspace via drm_syncobj / sync_file therefore keeps pointing at &sched->base after nouveau_sched_destroy(), and a later get_timeline_name() -- reachable unprivileged through SYNC_IOC_FILE_INFO -- dereferences freed memory (KASAN slab-use-after-free read). Per the dma-fence lifetime contract the exporter must keep the data backing a signalled fence alive for an RCU grace period. Free the scheduler-containing object with kfree_rcu() instead of kfree(). Fixes: 5f03a507b29e ("drm/nouveau: implement 1:1 scheduler - entity relationship") Cc: stable@vger.kernel.org Signed-off-by: Jonghyuk Kim(MalHyuk) Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260902012717.880724-1-malhyuk97@gmail.com commit c9dc7d730319ad64b51570c5387f1fee7b07b510 Author: Richard Zhu Date: Thu Aug 13 17:50:03 2026 +0800 PCI: imx6: Move clock enable after core reset assertion Commit 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling regulators") inadvertently moved clock enablement before core reset assertion, breaking PCI device initialization on i.MX6Q Apalis platforms with ASM1061/ASM1062 SATA controllers connected: imx6q-pcie 1ffc000.pcie: host bridge /soc/pcie@1ffc000 ranges: imx6q-pcie 1ffc000.pcie: IO 0x0001f80000..0x0001f8ffff -> 0x0000000000 imx6q-pcie 1ffc000.pcie: MEM 0x0001000000..0x0001efffff -> 0x0001000000 imx6q-pcie 1ffc000.pcie: config reg[1] 0x01f00000 == cpu 0x01f00000 imx6q-pcie 1ffc000.pcie: iATU: unroll F, 4 ob, 4 ib, align 64K, limit 4G imx6q-pcie 1ffc000.pcie: Link: Only Gen1 is enabled imx6q-pcie 1ffc000.pcie: Link failed to come up. LTSSM: POLL_CONFIG imx6q-pcie 1ffc000.pcie: probe with driver imx6q-pcie failed with error -110 NOTE: It is not 100% clear if the issue is specific to the ASM1061/ASM1062 device or on the specific power-up sequence (reset vs cold-power-on). To fix this regression, restore the original sequence where clocks are enabled after asserting core reset and configuring the controller type. Fixes: 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling regulators") Reported-by: Leonardo Costa Closes: https://lore.kernel.org/all/bl7i3obu2clzsgeoct2a4mtfhv6typcjdqmgneropf3hpgwve6@n2m5uhlduw57/T/#u Reported-by: Franz Schnyder Closes: https://lore.kernel.org/all/t65y5d54axtksbfs7r4olcefqhwm6m4dz3njgnrnf7fcotj74i@o7avoznlafbj/ Signed-off-by: Richard Zhu Signed-off-by: Manivannan Sadhasivam [bhelgaas: move to pci/for-linus for v7.3] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # 7.2+ Link: https://patch.msgid.link/20260813095003.356062-1-hongxing.zhu@oss.nxp.com commit c0078f4d8c8fcd8edfe8c53ffe77d48565c1957e Author: Wei Wang Date: Tue Sep 15 20:14:12 2026 +0000 mailmap: add entry for Wei Wang My Meta email address is no longer active. Map it to my current address so that git and get_maintainer.pl stop pointing at a dead address for my contributions. Signed-off-by: Wei Wang Link: https://patch.msgid.link/20260915201412.2201757-1-weiwan@google.com Signed-off-by: Jakub Kicinski commit 21c89ff1fc86ffa517f3a9ca1ba5c48e9e37c1ba Author: Abdurrahman Hussain Date: Mon Aug 31 18:29:25 2026 -0700 of/overlay: don't create "//" paths for fragments targeting the root dup_and_fixup_symbol_prop() rewrites a symbol value by replacing its "/fragment/__overlay__" prefix with the fragment's target path. When the fragment targets the root node the target path is "/" and the result starts with "//", which __of_find_node_by_full_path() cannot resolve: symbols pointing into such fragments silently stop resolving. Drop the target path when it is the root and the tail is non-empty. A value naming the fragment root itself (empty tail) keeps the "/". Fixes: d1651b03c2df ("of: overlay: add overlay symbols to live device tree") Assisted-by: Claude:claude-fable-5 [Claude Code] Signed-off-by: Abdurrahman Hussain Link: https://patch.msgid.link/20260831-nh-of-alias-overlay-v7-7-02754604805a@nexthop.ai Signed-off-by: Rob Herring (Arm) commit 3359a372efb6d585c97019ee1b7f1874442bcebe Author: Peiyang He Date: Mon Sep 7 13:22:04 2026 +0800 drm/nouveau/uvmm: fix UAF in nouveau_uvmm_sm when BO is in TTM_PL_SYSTEM nouveau_uvmm_sm() calls op_map(), which passes bo->resource through nouveau_mem() to nouveau_uvma_map(). nouveau_uvmm_vmm_map() then reads mem->mem.type. But this is only valid when bo->resource is backed by struct nouveau_mem, as is the case for VRAM and TT resources. If the BO is left in TTM_PL_SYSTEM, bo->resource is only a struct ttm_resource. Treating it as struct nouveau_mem makes the mem->mem.type read past the end of the resource, causing a KASAN: slab-use-after-free Read in nouveau_uvmm_sm report: BUG: KASAN: slab-use-after-free in nouveau_uvmm_vmm_map drivers/gpu/drm/nouveau/nouveau_uvmm.c:152 [inline] BUG: KASAN: slab-use-after-free in nouveau_uvma_map drivers/gpu/drm/nouveau/nouveau_uvmm.c:199 [inline] BUG: KASAN: slab-use-after-free in op_map drivers/gpu/drm/nouveau/nouveau_uvmm.c:849 [inline] BUG: KASAN: slab-use-after-free in nouveau_uvmm_sm.constprop.0+0x6ab/0x900 drivers/gpu/drm/nouveau/nouveau_uvmm.c:903 Read of size 1 at addr ffff888127d3e3a0 by task kworker/0:1/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0 #5 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nouveau_sched_wq_2224 drm_sched_run_job_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x95/0xe0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcb/0x5a0 mm/kasan/report.c:482 kasan_report+0xca/0x100 mm/kasan/report.c:595 nouveau_uvmm_vmm_map drivers/gpu/drm/nouveau/nouveau_uvmm.c:152 [inline] nouveau_uvma_map drivers/gpu/drm/nouveau/nouveau_uvmm.c:199 [inline] op_map drivers/gpu/drm/nouveau/nouveau_uvmm.c:849 [inline] nouveau_uvmm_sm.constprop.0+0x6ab/0x900 drivers/gpu/drm/nouveau/nouveau_uvmm.c:903 nouveau_uvmm_sm_unmap drivers/gpu/drm/nouveau/nouveau_uvmm.c:932 [inline] nouveau_uvmm_bind_job_run+0xd6/0x250 drivers/gpu/drm/nouveau/nouveau_uvmm.c:1532 nouveau_job_run drivers/gpu/drm/nouveau/nouveau_sched.c:350 [inline] nouveau_sched_run_job+0x62/0xd0 drivers/gpu/drm/nouveau/nouveau_sched.c:364 drm_sched_run_job_work+0x356/0xa10 drivers/gpu/drm/scheduler/sched_main.c:1061 process_one_work+0x8a5/0x1900 kernel/workqueue.c:3322 process_scheduled_works kernel/workqueue.c:3405 [inline] worker_thread+0x5dd/0xd80 kernel/workqueue.c:3486 kthread+0x31d/0x420 kernel/kthread.c:436 ret_from_fork+0x662/0x940 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 2224 on cpu 0 at 66.550027s: kasan_save_stack+0x24/0x50 mm/kasan/common.c:57 kasan_save_track+0x17/0x60 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5334 [inline] __kmalloc_noprof+0x304/0x7c0 mm/slub.c:5359 _kmalloc_noprof include/linux/slab.h:992 [inline] dma_resv_list_alloc+0x27/0x90 drivers/dma-buf/dma-resv.c:106 dma_resv_reserve_fences+0x60e/0xa30 drivers/dma-buf/dma-resv.c:205 ttm_bo_alloc_resource+0x12c/0xbd0 drivers/gpu/drm/ttm/ttm_bo.c:721 ttm_bo_validate+0x1bc/0x4a0 drivers/gpu/drm/ttm/ttm_bo.c:856 ttm_bo_init_reserved+0x2c3/0x570 drivers/gpu/drm/ttm/ttm_bo.c:970 nouveau_bo_init+0x159/0x2c0 drivers/gpu/drm/nouveau/nouveau_bo.c:359 nouveau_gem_new+0x234/0x5f0 drivers/gpu/drm/nouveau/nouveau_gem.c:272 nouveau_gem_ioctl_new+0x1eb/0x420 drivers/gpu/drm/nouveau/nouveau_gem.c:352 drm_ioctl_kernel+0x192/0x350 drivers/gpu/drm/drm_ioctl.c:817 drm_ioctl+0x4f8/0xb40 drivers/gpu/drm/drm_ioctl.c:914 nouveau_drm_ioctl+0xea/0x2c0 drivers/gpu/drm/nouveau/nouveau_drm.c:1338 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x180/0x1d0 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x115/0x690 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 2223 on cpu 0 at 66.554063s: kasan_save_stack+0x24/0x50 mm/kasan/common.c:57 kasan_save_track+0x17/0x60 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x61/0x80 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2677 [inline] __rcu_free_sheaf_prepare+0xb6/0x2e0 mm/slub.c:2928 rcu_free_sheaf+0x1b/0x120 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 [inline] rcu_core+0x521/0x1490 kernel/rcu/tree.c:2897 handle_softirqs+0x1b1/0x8a0 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] invoke_softirq kernel/softirq.c:496 [inline] __irq_exit_rcu+0x137/0x1c0 kernel/softirq.c:735 irq_exit_rcu+0x9/0x20 kernel/softirq.c:752 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 [inline] sysvec_apic_timer_interrupt+0x70/0x80 arch/x86/kernel/apic/apic.c:1062 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674 The buggy address belongs to the object at ffff888127d3e380 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 32 bytes inside of freed 96-byte region [ffff888127d3e380, ffff888127d3e3e0) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x127d3e flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff888100041280 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888127d3e280: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc ffff888127d3e300: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc >ffff888127d3e380: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888127d3e400: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff888127d3e480: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc Fix by resetting the placement to the BO's valid domains before calling nouveau_bo_validate(), matching the handling in nouveau_uvmm_bo_validate(), so map jobs do not run for SYSTEM resources; Reject BO that cannot reside in VRAM or GART; Also skip op_map() when the GPUVA has been invalidated, matching the handling in the unmap and remap paths. Found when fuzzing the nouveau driver with a modified Syzkaller. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Cc: stable@vger.kernel.org Signed-off-by: Peiyang He Assisted-by: Codex:gpt-5.5 Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/0D77BEC410CE0129+20260907052204.1431488-1-peiyang_he@smail.nju.edu.cn commit 1d62f0f2bc7edb12ed09f71203df0e47fa4efca4 Author: Abdurrahman Hussain Date: Mon Aug 31 18:29:24 2026 -0700 of/overlay: don't leak fragment references when changeset init fails init_overlay_changeset() stores the number of initialized fragments in ovcs->count only on full success. When find_target() or the __symbols__ lookup fails partway through, the target and overlay references taken for the fragments initialized so far are never dropped: free_overlay_changeset() bounds its cleanup loop by ovcs->count, which is still 0. Store the running count on the error path so free_overlay_changeset() puts whatever was set up. The store is guarded by ovcs->fragments because on the allocation-failure path cnt still holds the counting pass total while there is no fragments array; everywhere else cnt only counts fully-initialized fragments. Reported-by: Sashiko AI Closes: https://lore.kernel.org/20260805204009.CF3891F000E9@smtp.kernel.org Fixes: 61b4de4e0b38 ("of: overlay: minor restructuring") Assisted-by: Claude:claude-opus-4-8 [Claude Code] Signed-off-by: Abdurrahman Hussain Link: https://patch.msgid.link/20260831-nh-of-alias-overlay-v7-6-02754604805a@nexthop.ai Signed-off-by: Rob Herring (Arm) commit 44081d708b5b885487bac792db78324b7b4c267d Author: Abdurrahman Hussain Date: Mon Aug 31 18:29:23 2026 -0700 of/overlay: only treat a positive changeset id as registered of_overlay_fdt_apply() stores the idr_alloc() return value in ovcs->id before checking it. On failure the stored id is negative, free_overlay_changeset()'s "if (ovcs->id)" check passes, idr_remove() is called with a negative id and list_del() runs on ovcs->ovcs_list, which is not initialized until after the id allocation. An allocation failure at that point dereferences NULL. Make free_overlay_changeset() treat only a strict-positive id as registered. The rest of the function already copes with a partially-initialized ovcs, so the error path stays a plain goto err_free_ovcs. Fixes: 61b4de4e0b38 ("of: overlay: minor restructuring") Cc: stable@vger.kernel.org Suggested-by: Geert Uytterhoeven Assisted-by: Claude:claude-fable-5 [Claude Code] Reviewed-by: Geert Uytterhoeven Signed-off-by: Abdurrahman Hussain Link: https://patch.msgid.link/20260831-nh-of-alias-overlay-v7-5-02754604805a@nexthop.ai Signed-off-by: Rob Herring (Arm) commit 814f2da6995772c07a7c9c2cc6028b6e3f3ecc9c Author: Abdurrahman Hussain Date: Mon Aug 31 18:29:22 2026 -0700 of/overlay: put property on deadprops only after changeset add succeeds add_changeset_property() links a new property of a not-yet-live target node into the node's deadprops list before handing it to of_changeset_add_property(). If that fails, the error path frees the property but leaves the freed pointer linked in deadprops, and of_node_release() frees it a second time when the aborted overlay's node is released. Record the changeset entry first and link the property into deadprops only on success. of_changeset_add_property() never looks at the node's property lists, so the order of the two steps is otherwise immaterial, and the error path frees a property that nothing references. Fixes: f96278810150 ("of: overlay: set node fields from properties when add new overlay node") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 [Claude Code] Signed-off-by: Abdurrahman Hussain Link: https://patch.msgid.link/20260831-nh-of-alias-overlay-v7-4-02754604805a@nexthop.ai Signed-off-by: Rob Herring (Arm) commit adb87c20081e5ed5b6eef1270fc08b28bd77e865 Author: Lyude Paul Date: Thu Sep 17 14:54:29 2026 -0400 drm/nouveau/gsp/r570: Enable Gcoff in fbsr again Now that we're properly saving the compbit backing stores on fbsr init, we can start setting bEnteringGcOff = 1 again without things breaking, which brings us closer to following the exact same code-paths OpenRM does for fbsr. Signed-off-by: Lyude Paul Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260917185916.1089621-6-lyude@redhat.com commit 82f4394bbe223fda560153257e5cf21bdb12b6a3 Author: Lyude Paul Date: Thu Sep 17 14:54:28 2026 -0400 drm/nouveau/gsp/r570: Start saving comptag backing stores One of the portions of OpenRM's fbsr process that we never implemented is the saving and restoring of comptag backing stores. This isn't strictly necessary for fbsr to work (as long as we don't specify bEnteringGcOff = 1), but implementing it brings us much closer to matching OpenRM's fbsr process - which means we can rely on things being well tested on Nvidia's side. Now that we have the required driver workarounds in place and fetch the required information from GSP's memsys on driver load, let's implement support for this by fetching the required space for the compbit backing stores and adding it to the amount of memory that we allocate for fbsr. With this, we should be able to safely enable bEnteringGcOff in fbsr. Signed-off-by: Lyude Paul Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260917185916.1089621-5-lyude@redhat.com commit c7ef611a43bb3ab7e7738349a860418336d507db Author: Lyude Paul Date: Thu Sep 17 14:54:27 2026 -0400 drm/nouveau/gsp/r570: Add comp mode workaround from issue #3172217 One of the things that OpenRM does right before initiating fbsr is apply a special workaround (nvidia issue #3172217) which temporarily disables raw compression mode on the GPU. It is later re-enabled after resuming with fbsr completes. Since we don't currently save the compbit backing with fbsr, this shouldn't currently make any functional difference in the suspend/resume process. But it will be required for implementing support for saving and restoring compbit backings from the GPU. Signed-off-by: Lyude Paul Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260917185916.1089621-4-lyude@redhat.com commit 3217000f0b7e4f67e5b386d5b3491ec1b9b584b8 Author: Lyude Paul Date: Thu Sep 17 14:54:26 2026 -0400 drm/nouveau/gsp/r535: Add support for MEMSYS_GET_STATIC_CONFIG This is a GSP structure describing various characteristics of the memory management system that GSP provides. Start by fetching it during driver load, but don't do anything with the information we get from it just yet. Signed-off-by: Lyude Paul Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260917185916.1089621-3-lyude@redhat.com commit cb4c7603678ccef4c52b38159f2aaad867586dbc Author: Lyude Paul Date: Thu Sep 17 14:54:25 2026 -0400 drm/nouveau/gsp/r570: Add support for INTERNAL_GCX_ENTRY_PREREQUISITE OpenRM's runtime PM handling looks a bit different then nouveau's, one part in particular that differs from us: OpenRM actually consults GSP to ask whether the GPU should be allowed to enter Gc6 and/or GcOff before runtime suspending the GPU. In the event the card isn't ready, runtime suspend is simply delayed for a few seconds before retrying. Implement the command used for querying GSP about this, NV2080_CTRL_CMD_INTERNAL_GCX_ENTRY_PREREQUISITE, and check to ensure that the GPU is ready for runtime suspend in nouveau_pmops_runtime_suspend() using this query. If the GPU can't be runtime suspended, update the last busy counter of the device and then return -EBUSY from nouveau_pmops_runtime_suspend() - essentially delaying the runtime suspend process by whatever autosuspend_delay_ms is set to. Signed-off-by: Lyude Paul Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260917185916.1089621-2-lyude@redhat.com commit 64ca4cdd1031206424e6455f0ae4fb0560d8f46a Author: Junrui Luo Date: Mon Aug 17 14:50:40 2026 +0800 drm/nouveau/dmem: pin VRAM for the whole registered range Commit c32287471077 ("gpu/drm/nouveau: enable THP support for GPU memory migration") grew the device-private region that nouveau_dmem_chunk_alloc() registers from DMEM_CHUNK_SIZE to DMEM_CHUNK_SIZE * NR_CHUNKS, but left the VRAM buffer object backing that region at DMEM_CHUNK_SIZE. nouveau_dmem_page_addr() returns chunk->bo->offset plus the page's offset within the registered region, so every page past the first chunk resolves to VRAM outside the buffer object. Size the buffer object to the region it backs. Fixes: c32287471077 ("gpu/drm/nouveau: enable THP support for GPU memory migration") Reported-by: Yuhao Jiang Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260817-nouveau-fixes-v1-1-f518d0c735f3@outlook.com commit 8d78e4f906cf0a1984cf3c852653727835e1a9e0 Author: Arnd Bergmann Date: Thu Sep 17 15:58:51 2026 +0200 ASoC: rt766: fix HID dependency for SND_SOC_SDCA_HID Selecting SND_SOC_SDCA_HID only works if HID is enabled: WARNING: unmet direct dependencies detected for SND_SOC_SDCA_HID Depends on [n]: SOUND [=y] && SND [=y] && SND_SOC [=y] && SND_SOC_SDCA [=y] && (HID [=n]=y [=y] || HID [=n]=SND_SOC_SDCA [=y]) Selected by [y]: - SND_SOC_RT766_SDCA_SDW [=y] && SOUND [=y] && SND [=y] && SND_SOC [=y] && SOUNDWIRE [=y] && SND_SOC_SDCA [=y] Change the dependency to require SND_SOC_SDCA_CLASS instead, which solves the problem without extra selects. Fixes: b50ecf5873df ("ASoC: rt766: add RT766/RT767 SDCA driver") Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260917135950.405423-1-arnd@kernel.org Signed-off-by: Mark Brown commit 97077ac87afe9e91ec074ef0be64454e7ccbf344 Author: Peiyang He Date: Wed Sep 16 18:31:38 2026 +0800 drm/nouveau: fix double-free in nvif_vmm_dtor On failure, nouveau_cli_init() calls nouveau_cli_fini() to tear the client down. Then, nouveau_drm_open() also enters into its cleanup path and calls nouveau_cli_fini() AGAIN. nouveau_cli_fini() calls nouveau_vmm_fini(): void nouveau_vmm_fini(struct nouveau_vmm *vmm) { nouveau_svmm_fini(&vmm->svmm); nvif_vmm_dtor(&vmm->vmm); vmm->cli = NULL; } Inside nvif_vmm_dtor(), vmm->page is freed unconditionally: void nvif_vmm_dtor(struct nvif_vmm *vmm) { kfree(vmm->page); nvif_object_dtor(&vmm->object); } vmm->page is never cleared after being freed, so the second call of nvif_vmm_dtor() will cause a double-free. Found by fuzzing the nouveau driver with a modified Syzkaller: BUG: KASAN: double-free in nvif_vmm_dtor+0x31/0x50 drivers/gpu/drm/nouveau/nvif/vmm.c:194 Free of addr ffff888010fcdc30 by task syz.0.173/2567 CPU: 1 UID: 0 PID: 2567 Comm: syz.0.173 Not tainted 7.2.0 #24 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x95/0xe0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcb/0x5a0 mm/kasan/report.c:482 kasan_report_invalid_free+0xaa/0xd0 mm/kasan/report.c:557 check_slab_allocation+0xe4/0x110 mm/kasan/common.c:235 kasan_slab_pre_free include/linux/kasan.h:199 [inline] slab_free_hook mm/slub.c:2622 [inline] slab_free mm/slub.c:6377 [inline] kfree+0x192/0x590 mm/slub.c:6692 nvif_vmm_dtor+0x31/0x50 drivers/gpu/drm/nouveau/nvif/vmm.c:194 nouveau_vmm_fini+0x16/0x50 drivers/gpu/drm/nouveau/nouveau_vmm.c:127 nouveau_cli_fini+0x10e/0x210 drivers/gpu/drm/nouveau/nouveau_drm.c:225 nouveau_drm_open+0x24e/0x740 drivers/gpu/drm/nouveau/nouveau_drm.c:1255 drm_file_alloc+0x5f2/0xad0 drivers/gpu/drm/drm_file.c:176 drm_open_helper+0x1d7/0x4a0 drivers/gpu/drm/drm_file.c:335 drm_open+0x190/0x3d0 drivers/gpu/drm/drm_file.c:388 drm_stub_open+0x1f2/0x460 drivers/gpu/drm/drm_drv.c:1211 chrdev_open+0x21c/0x660 fs/char_dev.c:411 do_dentry_open+0x59d/0x12b0 fs/open.c:947 vfs_open+0x82/0x390 fs/open.c:1052 do_open fs/namei.c:4700 [inline] path_openat+0x2345/0x3420 fs/namei.c:4863 do_file_open+0x207/0x460 fs/namei.c:4892 do_sys_openat2+0xd1/0x1d0 fs/open.c:1368 do_sys_open fs/open.c:1374 [inline] __do_sys_openat fs/open.c:1390 [inline] __se_sys_openat fs/open.c:1385 [inline] __x64_sys_openat+0x144/0x200 fs/open.c:1385 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x115/0x690 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc6d687594d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6d5295008 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 00007fc6d6b06180 RCX: 00007fc6d687594d RDX: 0000000000022501 RSI: 0000200000000000 RDI: ffffffffffffff9c RBP: 00007fc6d691c303 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fc6d6b06218 R14: 00007fc6d6b06180 R15: 00007ffd9451d760 Allocated by task 2567 on cpu 1 at 163.593900s: kasan_save_stack+0x24/0x50 mm/kasan/common.c:57 kasan_save_track+0x17/0x60 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5334 [inline] __kmalloc_noprof+0x304/0x7c0 mm/slub.c:5359 _kmalloc_noprof include/linux/slab.h:992 [inline] nvif_vmm_ctor+0x3c0/0x7e0 drivers/gpu/drm/nouveau/nvif/vmm.c:237 nouveau_vmm_init+0x40/0x90 drivers/gpu/drm/nouveau/nouveau_vmm.c:134 nouveau_cli_init+0x7b9/0xe10 drivers/gpu/drm/nouveau/nouveau_drm.c:293 nouveau_drm_open+0x236/0x740 drivers/gpu/drm/nouveau/nouveau_drm.c:1243 drm_file_alloc+0x5f2/0xad0 drivers/gpu/drm/drm_file.c:176 drm_open_helper+0x1d7/0x4a0 drivers/gpu/drm/drm_file.c:335 drm_open+0x190/0x3d0 drivers/gpu/drm/drm_file.c:388 drm_stub_open+0x1f2/0x460 drivers/gpu/drm/drm_drv.c:1211 chrdev_open+0x21c/0x660 fs/char_dev.c:411 do_dentry_open+0x59d/0x12b0 fs/open.c:947 vfs_open+0x82/0x390 fs/open.c:1052 do_open fs/namei.c:4700 [inline] path_openat+0x2345/0x3420 fs/namei.c:4863 do_file_open+0x207/0x460 fs/namei.c:4892 do_sys_openat2+0xd1/0x1d0 fs/open.c:1368 do_sys_open fs/open.c:1374 [inline] __do_sys_openat fs/open.c:1390 [inline] __se_sys_openat fs/open.c:1385 [inline] __x64_sys_openat+0x144/0x200 fs/open.c:1385 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x115/0x690 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 2567 on cpu 1 at 163.601355s: kasan_save_stack+0x24/0x50 mm/kasan/common.c:57 kasan_save_track+0x17/0x60 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x61/0x80 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2677 [inline] slab_free mm/slub.c:6377 [inline] kfree+0x383/0x590 mm/slub.c:6692 nvif_vmm_dtor+0x31/0x50 drivers/gpu/drm/nouveau/nvif/vmm.c:194 nouveau_vmm_fini+0x16/0x50 drivers/gpu/drm/nouveau/nouveau_vmm.c:127 nouveau_cli_fini+0x10e/0x210 drivers/gpu/drm/nouveau/nouveau_drm.c:225 nouveau_cli_init+0x593/0xe10 drivers/gpu/drm/nouveau/nouveau_drm.c:324 nouveau_drm_open+0x236/0x740 drivers/gpu/drm/nouveau/nouveau_drm.c:1243 drm_file_alloc+0x5f2/0xad0 drivers/gpu/drm/drm_file.c:176 drm_open_helper+0x1d7/0x4a0 drivers/gpu/drm/drm_file.c:335 drm_open+0x190/0x3d0 drivers/gpu/drm/drm_file.c:388 drm_stub_open+0x1f2/0x460 drivers/gpu/drm/drm_drv.c:1211 chrdev_open+0x21c/0x660 fs/char_dev.c:411 do_dentry_open+0x59d/0x12b0 fs/open.c:947 vfs_open+0x82/0x390 fs/open.c:1052 do_open fs/namei.c:4700 [inline] path_openat+0x2345/0x3420 fs/namei.c:4863 do_file_open+0x207/0x460 fs/namei.c:4892 do_sys_openat2+0xd1/0x1d0 fs/open.c:1368 do_sys_open fs/open.c:1374 [inline] __do_sys_openat fs/open.c:1390 [inline] __se_sys_openat fs/open.c:1385 [inline] __x64_sys_openat+0x144/0x200 fs/open.c:1385 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x115/0x690 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888010fcdc30 which belongs to the cache kmalloc-16 of size 16 The buggy address is located 0 bytes inside of 16-byte region [ffff888010fcdc30, ffff888010fcdc40) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10fcd flags: 0x100000000000000(node=0|zone=1) page_type: f5(slab) raw: 0100000000000000 ffff88800d441640 dead000000000100 dead000000000122 raw: 0000000000000000 0000000000550055 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888010fcdb00: fc fc 00 04 fc fc fc fc fa fb fc fc fc fc fa fb ffff888010fcdb80: fc fc fc fc fa fb fc fc fc fc 00 07 fc fc fc fc >ffff888010fcdc00: fa fb fc fc fc fc fa fb fc fc fc fc fa fb fc fc ^ ffff888010fcdc80: fc fc fa fb fc fc fc fc 00 04 fc fc fc fc fa fb ffff888010fcdd00: fc fc fc fc 00 00 fc fc fc fc fa fb fc fc fc fc Fix by removing the redundant teardown in nouveau_drm_open(), since nouveau_cli_init() already does the cleanup work. Also clear vmm->page after its freeing. Cc: stable@vger.kernel.org Fixes: 20d8a88e557a ("drm/nouveau: tidy up the client init/fini interfaces") Signed-off-by: Peiyang He Assisted-by: LLM Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/03BA723D9E5FF725+20260916103138.2651605-1-peiyang_he@smail.nju.edu.cn commit 4cae4ca34992d210d115e8e891f1e88c9df5f24c Author: Seiji Adachi Date: Thu Sep 17 22:18:51 2026 +0900 ASoC: amd: yc: Add Lenovo ThinkPad E16 Gen 2 (21JN) to quirks Signed-off-by: Seiji Adachi Link: https://patch.msgid.link/20260917131851.2122144-1-seiji_adachi@yahoo.co.jp Signed-off-by: Mark Brown commit 3d743adf090cd4c9a2120c1e02b0482e88aa0d2d Author: Frieder Schrempf Date: Thu Sep 17 16:10:15 2026 +0200 spi: fsl-qspi: Reprogram the clock rate when the operation frequency changes fsl_qspi_select_mem() returns early when the chip select has not changed, which happens before it reaches clk_set_rate(). Since the rate is now taken from the spi-mem operation rather than from the SPI device, the controller honours op->max_freq exactly once per chip select and ignores it for every operation after that. q->selected is only reset to -1 in fsl_qspi_default_setup(), i.e. at probe and on resume, so on the common single chip select board the very first operation latches a rate that all subsequent operations inherit, whatever frequency they asked for. This results in operations being issued with the wrong frequency. Cache the operation frequency the clock was programmed for next to the selected chip select, and redo the clock setup when either changes. Fixes: 2438db5253eb ("spi: fsl-qspi: Support per spi-mem operation frequency switches") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Frieder Schrempf Acked-by: Han Xu Link: https://patch.msgid.link/20260917-fsl-qspi-freq-op-fix-v1-1-5fbe6b02f738@kontron.de Signed-off-by: Mark Brown commit 1e04611d3735543bd80a67d9d13dc13f503746fb Author: Wentao Liang Date: Wed Sep 16 18:03:42 2026 +0000 drm/nouveau: Fix runtime PM leak in nouveau_connector_detect() If nvif_outp_edid_get() fails, nouveau_connector_detect() returns early without dropping the runtime PM reference taken at the start of the function, keeping the device powered on until the next successful detect. Balance the reference on the error path like the other exit paths do. Fixes: 0cd7e0718139 ("drm/nouveau/disp: add output method to fetch edid") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260916180342.2090360-1-vulab@iscas.ac.cn commit 5ea72f7b7139b123713a7983448f910bc4514d9e Author: Wentao Liang Date: Wed Sep 16 18:02:02 2026 +0000 drm/nouveau: Fix gem reference leak in validate_init() On the ttm_bo_reserve() failure and "vma not found" error paths, the loop breaks without adding the looked-up object to any validate list, so the reference taken by drm_gem_object_lookup() is never released; validate_fini() only walks the spliced lists. Drop the reference before breaking out on both paths. Fixes: 19ca10d82e33bcfe ("drm/nouveau/gem: lookup VMAs for buffers referenced by pushbuf ioctl") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260916180202.2090231-1-vulab@iscas.ac.cn commit 5f0306e731e2f46e91419eae57eee3a241c055e0 Author: Frank Sorenson Date: Wed Sep 16 16:34:00 2026 -0500 smb: client: fix reparse buffer bounds in cifs_query_reparse_point() In cifs_query_reparse_point(), the start >= end check before casting to struct reparse_data_buffer * only ensures the start pointer is within the response. It fails to verify that there is enough space remaining for the fixed 8-byte header of the structure. If a server provides a DataOffset that leaves less than 8 bytes remaining, the check passes, but subsequent reads of ReparseTag and ReparseDataLength will occur out-of-bounds. Fix this by ensuring the remaining space is at least the size of the reparse_data_buffer structure before accessing its fields. Fixes: 56e84c64fc25 ("cifs: Fix validation of SMB1 query reparse point response") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara commit 4775c3b7a597907e0b97556c7986fda238a377ae Author: Frank Sorenson Date: Wed Sep 16 16:33:59 2026 -0500 smb: client: fix potential OOB read in smb3_enum_snapshots() If snapshot_array_size is smaller than GMT_TOKEN_SIZE, smb3_enum_snapshots() sets ret_data_len to sizeof(struct smb_snapshot_array) without verifying the actual length of the server's reply. Because SMB2_ioctl() places no lower bound on the server-supplied OutputCount and allocates retbuf to exactly that length, a short reply results in ret_data_len exceeding the size of retbuf. The subsequent copy_to_user() then reads past the end of retbuf, leaking adjacent slab memory to userspace. The subsequent clamp check is ineffective as it only reduces ret_data_len. Fix this by rejecting replies shorter than sizeof(struct smb_snapshot_array) with -EIO. Note that the bound is set to the 12-byte struct size rather than the 16-byte MIN_SNAPSHOT_ARRAY_SIZE defined in MS-SMB2 3.3.5.15.1, because 12 bytes is exactly what copy_to_user() attempts to read. Fixes: e02789a53d71 ("smb3: enumerating snapshots was leaving part of the data off end") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara commit b09d092eb24ad0110f16a9b7c1ed5d2a0c1733dc Author: Frank Sorenson Date: Wed Sep 16 16:33:58 2026 -0500 smb: client: fix missing iov bounds check in parse_posix_sids() In parse_posix_sids(), sidsbuf_end is calculated using the server-supplied out_len without being validated against the actual length of the received iov (iov_len). If a server provides an inflated out_len, sidsbuf_end will point past the end of the iov. This defeats the bounds guards in posix_info_sid_size(), allowing out-of-bounds reads into adjacent kernel memory. Fix this by rejecting responses where the calculated sidsbuf_end would exceed the received iov boundaries or cause pointer wraparound. Fixes: a90f37e3d7ac ("smb: client: parse owner/group when creating reparse points") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara commit eeb5ef6083e1cefa2ef75041b5597ff228b8d7bb Author: Frank Sorenson Date: Wed Sep 16 16:33:57 2026 -0500 smb: client: fix OOB struct field reads in move_smb2_ea_to_cifs() In move_smb2_ea_to_cifs(), the while (src_size > 0) loop condition is insufficient. It allows iteration to continue even if the remaining src_size is too small to contain a complete smb2_ea_info structure. Consequently, reads of ea_name_length and ea_value_length can occur out-of-bounds. Fix this by ensuring src_size >= sizeof(*src) before attempting to read any structure fields. Additionally, reject any next_entry_offset that is smaller than sizeof(*src) or that would advance the pointer beyond the available buffer. Note that for calls where the server returns a malformed EA list, the error returned to userspace changes from -ENODATA (getxattr) or -ERANGE (listxattr) to -EIO. This correctly signals a server protocol error rather than misleadingly indicating "attribute not present" or "output buffer too small". Fixes: 95907fea4fd8 ("cifs: Add support for reading attributes on SMB2+") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara commit 1b3221bb121079ad79a1f3c3aa360ba649832e7a Author: Frank Sorenson Date: Wed Sep 16 16:33:56 2026 -0500 smb: client: reject short Next offsets in parse_server_interfaces() In parse_server_interfaces(), the server-supplied Next offset is validated against bytes_left, but not against the size of the interface structure itself. A small, non-zero Next value can pass the bounds check but advance the pointer by less than sizeof(*p). This causes the next iteration of the loop to read misaligned, overlapping structure fields. Fix this by ensuring the Next offset is at least sizeof(*p). Fixes: 7d34ec36abb8 ("smb3: fix for slab out of bounds on mount to ksmbd") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara commit e83330c55edc0c3ac08aa6c95e49e4694c65523b Author: Frank Sorenson Date: Wed Sep 16 16:33:55 2026 -0500 smb: client: fix missing lower-bound check on DFS referral string offsets parse_dfs_referrals() checks that DfsPathOffset and NetworkAddressOffset do not exceed the buffer end, but fails to check that they don't point inside the referral header itself. If a server provides an offset smaller than sizeof(struct dfs_referral_level_3), the derived string pointer overlaps with the struct fields, causing cifs_strndup_from_utf16() to interpret header data as UTF-16 strings. Fix this by enforcing that string offsets are at least sizeof(*ref). Fixes: 4ecce920e13a ("CIFS: move DFS response parsing out of SMB1 code") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara commit f73726b83e4756fdaa099e1bc1143293bd57ad79 Author: Frank Sorenson Date: Wed Sep 16 16:33:54 2026 -0500 smb: client: fix server->total_read for compound encrypted PDUs In receive_encrypted_standard(), server->total_read is left at the full decrypted frame size when walking sub-PDUs of a compound encrypted frame. As a result, cifs_handle_standard() passes this full size to smb2_check_message(), causing the PDU length guards to incorrectly validate the entire compound frame instead of the current sub-PDU. This allows truncated non-last sub-PDUs to bypass length validation, leading to out-of-bounds reads in smb2_get_data_area_len(). Fix this by setting server->total_read to the true length of the current sub-PDU: next_cmd for non-last sub-PDUs, and the remaining pdu_length for the last one. Fixes: b24df3e30cbf ("cifs: update receive_encrypted_standard to handle compounded responses") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara commit b4694f269e66dfcd66991446375285723b6957bd Author: Frank Sorenson Date: Wed Sep 16 16:33:53 2026 -0500 smb: client: validate minimum PDU size before smb2_get_data_area_len() __smb2_calc_size() calls smb2_get_data_area_len(), which reads command-specific struct fields to locate the data area. However, smb2_check_message() only validates StructureSize2, meaning a truncated response could cause smb2_get_data_area_len() to read out-of-bounds. Replace has_smb2_data_area[] with smb2_min_pdu_len[], which is now used to indicate both whether a command's response has a data area and the size of that fixed response struct. A non-zero entry means the command has a data area, and is the minimum length required before the struct is read. For each command with a data area, PDUs shorter than this minimum size are rejected instead of parsed. The minimum is not applied to SMB2 error responses, which carry only the 9-byte error body, the same exemption the StructureSize2 check above it already makes. STATUS_MORE_PROCESSING_REQUIRED is treated as a normal reply, since an in-progress SESSION_SETUP response carries a full body and a security blob. Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara commit 05762c5bc1cfdcac36747994fde2c04387a457f1 Author: Frank Sorenson Date: Wed Sep 16 16:33:52 2026 -0500 smb: client: fix next_buffer UAF and NextCommand bounds in compound PDUs Fix several related bounds checking and pointer lifecycle issues in receive_encrypted_standard()'s handling of compound encrypted frames: - Clear next_buffer after assigning it to server->bigbuf. A stale next_buffer pointer can lead to a use-after-free on subsequent error paths. - Update pdu_length to the decrypted plaintext size (buf_size). Using the pre-decryption length allows NextCommand to point into stale ciphertext residue. - Reject next_cmd values smaller than MID_HEADER_SIZE(server). - Fix an integer overflow in the upper bound check by verifying pdu_length - next_cmd < MID_HEADER_SIZE(server), ensuring the trailing slice is large enough for a header. Fixes: b24df3e30cbf ("cifs: update receive_encrypted_standard to handle compounded responses") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara commit 70504de0bb627848667207bec7ccfd647deb8814 Author: Zhiling Zou Date: Fri Sep 11 00:18:24 2026 +0800 xsk: Use a 32-bit compare in xsk_map_gen_lookup xsk_map_gen_lookup() loads a u32 key and compares it with max_entries using BPF_JMP_IMM. BPF immediates are sign-extended to 64 bits, so a max_entries value of 0x80000000 or higher becomes a threshold larger than every zero-extended 32-bit key. An out-of-range index then skips the bounds check and the generated lookup reads past xsk_map[]. Compare with BPF_JMP32_IMM so the check stays in 32-bit unsigned range. Fixes: e65650f291ee ("bpf: Implement map_gen_lookup() callback for XSKMAP") Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Alexei Starovoitov Reviewed-by: Emil Tsalapatis Link: https://patch.msgid.link/7d2cb8e8dfaa9eb8fdff85156987a60960787dc3.1789056660.git.zhilinz@nebusec.ai Signed-off-by: Eduard Zingerman commit 9e4188d7a411103b6b1406dd67d55c3bbb637551 Merge: ee363e05589536 a452e729b7be31 Author: Eduard Zingerman Date: Wed Sep 16 09:53:03 2026 -0700 Merge branch 'fix-global-subprog-verification-context' Kumar Kartikeya Dwivedi says: ==================== Fix global subprog verification context Global subprogs can be invoked in both sleepable and non-sleepable contexts, but are verified based on context assumptions for the program type as a whole and not the precise context in which they are invoked. Nicholas identified that this can violate verifier safety assumptions. Verify global subprogs once for each observed sleepability context and add workqueue callback regression tests. Changelog: ---------- v2 -> v3 v2: https://lore.kernel.org/bpf/20260905051224.2325381-1-memxor@gmail.com * Clarify that globals are checked only in contexts from which they are reached, with two passes only when both contexts occur. (Alexei) * Implement in_sleepable_context() as !in_rcu_cs(). (Alexei, Eduard) * Keep the original subprogram traversal order and repeat until all called contexts have been verified. (Eduard) * Explain why instruction accounting needs the saved total and why the exception callback uses the main program's context. (Eduard) * Rename the do_check_common() parameter to is_sleepable. (BPF CI) * Preserve the harmless global calls with __weak __noinline and check their instruction totals across both contexts. Drop the redundant task-work global RCU test and retain the review acknowledgment. (Eduard) v1 -> v2 v1: https://lore.kernel.org/bpf/20260905034018.2095649-1-memxor@gmail.com * Preserve the harmless global subprog calls in the positive test with barrier() so LLVM cannot eliminate the intended coverage. * Return zero explicitly from workqueue callbacks after global subprog calls. * Document cumulative instruction accounting across verification contexts. * Fix BPF multi-line comment formatting. ==================== Link: https://patch.msgid.link/20260914131923.2544250-1-memxor@gmail.com Signed-off-by: Eduard Zingerman commit a452e729b7be317837bb2157d5d88aa3de9873e6 Author: Kumar Kartikeya Dwivedi Date: Mon Sep 14 15:19:21 2026 +0200 selftests/bpf: Test global subprog callback contexts Exercise global subprogram verification from workqueue callbacks, which can run in a sleepable context even when the containing program is not sleepable. An unprotected callback must not let the global subprogram use implicit RCU protection inherited from the program. Add a negative case which loads an RCU-protected task kptr in a global subprogram reached from a workqueue callback. It fails on an unfixed kernel because the program is incorrectly accepted. Also cover a workqueue callback protected by an explicit RCU read-side critical section, where the same global subprogram remains valid. Call the same harmless global subprogram directly from the main program and from an unprotected callback. Mark it __weak __noinline so both calls survive optimization, and check that its instruction statistics account for both verification contexts. This also verifies that global calls from callbacks are not rejected wholesale. Workqueue callbacks return zero explicitly after the global call, as required by their contract. Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260914131923.2544250-3-memxor@gmail.com Signed-off-by: Eduard Zingerman commit 40c2096961b4e8f48d1fc17406a90c5a36ac0a8d Author: Kumar Kartikeya Dwivedi Date: Mon Sep 14 15:19:20 2026 +0200 bpf: Verify global subprogs in each sleepability context Global subprograms are verified independently with a fresh verifier root. do_check_common() currently seeds that root's in_sleepable state from the program, even though a global subprogram can also run from callbacks whose execution context differs from the program's main entry point. In particular, workqueue and task-work callbacks are sleepable even when the containing program is not. A global subprogram of that program is therefore verified as non-sleepable, making in_rcu_cs() true and allowing loads of RCU-protected kptrs to produce trusted MEM_RCU pointers. The same subprogram can then be called from a sleepable callback without a classic RCU reader. It can retain such a pointer while the object is freed and use it after free. The verifier's execution-context predicates are complementary. A state is sleepable only when in_sleepable is set and no RCU, preemption, IRQ, or lock region is active. Each condition which prevents sleeping also provides RCU protection, while in_rcu_cs() treats a non-sleepable state as implicitly protected. Use this relationship to represent a global subprogram caller with only the result of in_sleepable_context(). A protected sleepable caller is normalized to in_sleepable=false at the independent verification root. This both prevents sleepable operations and makes in_rcu_cs() true without copying caller-owned lock state. Track only the contexts in which each global subprogram is actually reached. Verify it once if all reachable calls use the same context, and twice only if both sleepable and non-sleepable calls reach it. Calls found while verifying globals or asynchronous callbacks mark further contexts for checking. Repeat the existing subprogram walk until all called contexts have been verified; unreachable global calls remain unchecked. Accumulate instruction counts over those verification passes. Preserve the total recorded before each pass, since path accounting has already added this pass's synchronous instructions and its root total must also include asynchronous subprograms. This makes an unprotected callback verify the global subprogram as sleepable, turning its RCU-protected kptr load into an untrusted pointer. Protected callers and global subprograms which do not depend on implicit RCU protection remain valid. Fixes: 81f1d7a583fa ("bpf: wq: add bpf_wq_set_callback_impl") Fixes: 38aa7003e369 ("bpf: task work scheduling kfuncs") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260914131923.2544250-2-memxor@gmail.com Signed-off-by: Eduard Zingerman commit 72de4807ba84da485dda1a91572d66da9149e95a Author: Anand Jain Date: Sun Sep 13 02:06:28 2026 +0800 btrfs: derive f_fsid with dev_t only when temp_fsid is active Commit c2a74ed0494c ("btrfs: derive f_fsid from on-disk fsid and dev_t") mixed dev_t into f_fsid for all single-device setups to avoid f_fsid collisions with cloned filesystems. However, doing this unconditionally breaks backward compatibility. statfs(2) f_fsid changes after a kernel upgrade, and also can shift across reboots or dev re-attaches as dev_t values change. Fix this by only mixing dev_t when temp_fsid is active. This means for non-temp_fsid setups or the original mount, we use the old method of deriving fsid based on the UUID. So in the case of a cloned Btrfs filesystem, we won't be able to maintain the same fsid across mount recycle if the mount order changes. Reported-by: Dave Hansen Link: https://lore.kernel.org/linux-btrfs/be0c08f5-2f31-40f5-8a3b-f2f58b3e00ff@intel.com Fixes: c2a74ed0494c ("btrfs: derive f_fsid from on-disk fsid and dev_t") CC: stable@vger.kernel.org # 7.2 Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba commit b797b52e88a66598a972111b02ef13edd8d03ed2 Author: Qu Wenruo Date: Sat Sep 12 18:12:06 2026 +0930 btrfs: add "/dev/root" exception for device path update [BEHAVIOR CHANGE] Since commit 108cc8733989 ("btrfs: fix a lockdep caused by path resolution during device scan"), users with btrfs rootfs but without an initramfs are complaining that grub2 can no longer detect the rootfs device: /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?). [CAUSE] Although using btrfs without an initramfs is not recommended (if a new device is added to the rootfs, the system can no longer boot, as there is no way to register all devices), there is still a minority of users doing this. If there is no initramfs but the rootfs is on a block-device-based filesystem, the kernel boot sequence initializes a minimal ramfs/tmpfs, creates "/dev/root" with the proper device number for the rootfs, and then invokes mount using "/dev/root". That's why the end user will get the mount output: /dev/root on / rw To be honest, this is a user space problem: no one should trust the device path shown in mount, only the device number. E.g. one can even use "/proc/self/fd/*" to mount an fs, and that proc path will be registered, and no one else can mount that fs using that path. Before commit 108cc8733989 ("btrfs: fix a lockdep caused by path resolution during device scan"), btrfs had an internal path lookup workaround to address such weird paths, it works by checking if the existing device path can still resolve to the device number. But that path resolution is deadlock prone, thus it's replaced by a simple devt check. This works fine in most cases, as a btrfs device is registered by udev at boot time, thus all paths are sane. However this will not work for systems without an initramfs, causing the unreachable "/dev/root" path to exist forever without a way to rename it. [WORKAROUND] Add an exception to the device path rename requirement. If the device has the name "/dev/root", we know it's booted without an initramfs, and only for that case we allow device path update. And if someone intentionally created "/dev/root" after boot, the existing devt checks will reject that weird name as usual. This should satisfy the minority of users, and still keep most of the existing guards preventing unexpected/unnecessary device path updates. Fixes: 108cc8733989 ("btrfs: fix a lockdep caused by path resolution during device scan") Link: https://lore.kernel.org/linux-btrfs/CAKLYgeL7nrA4nXcewdv9Fqg_s=3GS=vmoypnEiZBKQ7rySZFuQ@mail.gmail.com/ Link: https://lore.kernel.org/linux-btrfs/dfbe1e27-dab8-4d55-8cf3-0b28eeac5df4@gmail.com/ Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba commit aeab4c62875748ecfd390a47ac1d91ea7c9a6abb Author: Filipe Manana Date: Wed Sep 16 16:49:37 2026 +0100 btrfs: check if there is space for chunk item when validating sys chunk array We checked if have enough remaining space for a key before dereferencing a key, but we then dereference a chunk item, to get the number of stripes, without checking if there is space for the item. So add a check to see if there is enough space for a chunk item before dereferencing the item to extract the stripe count. Fixes: 2a9bb78cfd36 ("btrfs: validate system chunk array at btrfs_validate_super()") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba commit b5a051f6b840d48f159166ef073d3021989bfb50 Merge: 4982d3552a3bf9 3b95a04eb5f95b Author: Linus Torvalds Date: Thu Sep 17 10:40:48 2026 -0700 Merge tag 'net-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from Netfilter, Bluetooth, IPSec and WiFi. Previous releases - regressions: - netfilter: hold reference on ct until flow is released - bridge: - move switchdev call outside rcu - vlan: fix bugs caused by switchdev deletion errors - wifi: - mac80211: reset state when starting AP fails - cfg80211: don't free driver-owned scan requests - tcp: don't call skb_clone_and_charge_r() for close()d listener in tcp_v6_do_rcv() - mptcp: return sk_wait_data() errors from recvmsg() - xfrm: serialize state GC with device state flush - drop_monitor: synchronize tracepoint unregistration on error path - bluetooth: - eir: validate service data length before reading UUID - hci_sync: serialize local codec list cleanup - RFCOMM: avoid socket lock inversion in listener cleanup - eth: - lan743x: fix RX checksum use-after-free - mvpp2: prevent buffer overflow in page_pool allocation Previous releases - always broken: - core: lock the socket in sock_gettstamp() - neighbour: enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS. - sched: codel: bound the dropping loop per dequeue call - wifi: mac80211: include TIM bitmap control for buffered S1G mcast traffic - psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb() - xfrm: fix stack OOB read in iptfs_skb_reset_frag_walk() - bluetooth: hci_qca: do not write to the serial port after it is closed - dsa: mxl862xx: disable the stats poll on teardown - eth: - stmmac: fix TSO header length truncation - ip_tunnel: initialize `options_len` before referencing options" * tag 'net-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (159 commits) mptcp: fix bad accounting in __mptcp_subflow_push_pending() mptcp: close race between scheduler and state change mptcp: avoid unneeded actions on subflow reset net: skbuff: do not leave stale header offsets after pskb_carve() selftests: net: packetdrill: test exclusion of old ACK from TCP fast path tcp: exclude old ACKs from tcp fast path dpll: reject a reference sync pin which is not on the pin's dpll net: mvpp2: prevent buffer overflow in page_pool allocation net: macb: fix ordering around PTP timestamp read selftests: drv-net: psp: test PSP and TCP ULP mutual exclusion net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb() net: stmmac: preserve real_num_tx_queues on mqprio setup failure net: stmmac: propagate FPE preemption-class mapping errors net: wwan: t7xx: validate the netif index in t7xx_ccmni_recv_skb() net: wwan: mhi_wwan_mbim: check skb_copy_bits() return value net: wwan: mhi_wwan_mbim: guard against a cyclic NDP chain net: ethernet: cortina: Ack RX overrun interrupt correctly net: lock the socket in sock_gettstamp() eth: fbnic: ring the doorbell if a burst ends in a drop net: netsec: fix device_node reference leak on phy_np ... commit 97fcd34aa9fd73cefe3120ac9a82ca9d7763922f Author: Filipe Manana Date: Wed Sep 16 15:43:41 2026 +0100 btrfs: abort transaction on failure to update inode for hole punching and reflinking If we fail to update the inode we error out without aborting the transaction, which can result in a persistent inconsistency if after the failure the transaction is committed, as we have dropped file extent items from a range and either punched a hole or insert a new file extent item for that range (for reflinks). So add the missing transaction abort. Fixes: 2aaa66558172 ("Btrfs: add hole punching") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba commit 3565893cc72cdf6b795cf6a33e7ff9605322334d Author: Guanghui Yang <3497809730@qq.com> Date: Wed Sep 16 05:16:38 2026 +0000 btrfs: clear free space tree creation state on rebuild failure btrfs_rebuild_free_space_tree() sets BTRFS_FS_CREATING_FREE_SPACE_TREE before rebuilding the free space tree. Several error paths return without clearing this flag. The transaction restart failure path can leave the flag set on a live filesystem, causing delayed reference processing to be skipped. Clear it on all free space tree rebuild failure paths. Keep BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED set, since a failed rebuild leaves the free space tree untrusted. Callers must fall back to extent-tree caching. Fixes: 882af9f13e83 ("btrfs: handle free space tree rebuild in multiple transactions") CC: stable@vger.kernel.org # 6.14+ Assisted-by: LLM Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Guanghui Yang <3497809730@qq.com> Signed-off-by: David Sterba commit 9ec7ba20c97d92fa59b351832aeeb934b3b16177 Author: fangqiurong Date: Thu Sep 17 15:52:42 2026 +0800 selftests/sched_ext: Test that ops.dequeue() can iterate the consumed DSQ Add a scheduler whose ops.dequeue() iterates the source user DSQ with bpf_iter_scx_dsq. The iteration takes the DSQ's raw spinlock; on a kernel that runs ops.dequeue() while the consume path still holds that lock, the first task consumed self-deadlocks the CPU with IRQs disabled. The watchdog cannot recover from that state, so on an unfixed kernel this test wedges the system instead of failing cleanly. On a fixed kernel the scheduler runs clean and the test passes. Signed-off-by: fangqiurong Signed-off-by: Tejun Heo commit cb86607ada73185f321baa7f9d94a08a3a40bbf5 Author: fangqiurong Date: Thu Sep 17 15:52:41 2026 +0800 sched_ext: Don't run ops.dequeue() with a DSQ lock held ops.dequeue() is invoked with the source user DSQ's lock still held on the consume and move paths (scx_consume_dispatch_q(), move_task_between_dsqs()). A BPF scheduler which locks the source user DSQ from ops.dequeue() - e.g. by iterating it with bpf_iter_scx_dsq - self-deadlocks. ops.dequeue() can only call the "any" kfuncs and none of them can lock a builtin DSQ, so the global and bypass paths can't deadlock; however, all DSQ locks share one lockdep class, so iterating any user DSQ from ops.dequeue() on those paths trips the recursion check. Move the invocation after the DSQ unlock on all three paths. SCX_TASK_IN_CUSTODY is cleared under the lock serializing the transfer so that the callback is invoked exactly once. Fixes: ebf1ccff79c4 ("sched_ext: Fix ops.dequeue() semantics") Cc: stable@vger.kernel.org # v7.1+ Acked-by: Andrea Righi Signed-off-by: fangqiurong Signed-off-by: Tejun Heo commit 67b4411538c8341692548429d43256f25be99f7a Author: Wentao Liang Date: Wed Sep 16 18:00:36 2026 +0000 drm/nouveau: Fix bridge reference leak in nv1a_ram_new() pci_get_domain_bus_and_slot() takes a reference to the PCI device, which is never released once the memory size has been read from its config space. Drop the reference before returning. Fixes: 2fa6d6cdaf283c05 ("drm/nouveau: deprecate pci_get_bus_and_slot()") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260916180036.2090118-1-vulab@iscas.ac.cn commit 4982d3552a3bf94de503acf93433277d08421de6 Merge: f143ea21cf834b 546b928da0427b Author: Linus Torvalds Date: Thu Sep 17 09:57:09 2026 -0700 Merge tag 'sound-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of small fixes. Most of them are device-specific fixes while there are a few core fixes. The continued flux, but not too scaring yet. Some highlights below. ALSA Core: - Fix potential UAF after asynchronous card release - Fix a race condition in PCM timer initialization order USB-Audio: - Hardening fixes for issues reported by fuzzer for 6fire, bcd2000, and implicit FB packets - Fix double list addition in implicit FB handling - Quirks for AVerMedia GC553Pro and Behringer FCA1616 HD-Audio: - Quirks / fixes for HP OmniBook 7, OMEN 15, and Victus 15 laptops ASoC: - Support for DAI link codec channel mask to avoid mismatches - Fix HDMI-codec channel status change report - Fixes for various codecs and platforms: Realtek rt712/rt721 (calibration, reset fixes), Cirrus Logic (empty EFI variable validation, capture channel fixup), AMD ACP SoundWire (bounds checks, refactorings), ADAU1977 (OF match table support, SPI cleanups), ES8336 (Huawei Matebook B3-420 quirk), UX500 (macro fix)" * tag 'sound-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (33 commits) ASoC: adau1977-i2c: add OF match table for I2C ASoC: adau1977-spi: drop __maybe_unused and of_match_ptr() ASoC: adau1977: make the Kconfig symbols user selectable ASoC: amd: acp: fix card name length warning in SOF SoundWire machine driver ASoC: amd: acp: fix ffs() operator precedence for SoundWire link ID ASoC: amd: acp: refactor codec config count in SOF SoundWire machine driver ASoC: amd: acp: bounds-check SoundWire link ID in machine drivers ASoC: cs-amp-lib: Prevent NULL pointer if efi variable is zero length ASoC: codecs: rt712-sdca-dmic: fix uninitialized stream_config->type ASoC: hdmi-codec: Report a change when the channel status moves ASoC: ux500: Parenthesize MSP_{RX,TX}_CLKPOL_BIT() arguments ASoC: rt721: Reset codec to fix abnormal sound ALSA: usb-audio: fix list_add double-add in push_back_to_ready_list ALSA: hda: trace PCM open only after assigning a stream ALSA: usb-audio: skip the broken mute control on AVerMedia GC553Pro ALSA: hda/realtek: Enable mute LEDs on HP OmniBook 7 17-dc0xxx ALSA: 6fire: fix OOB write from device-reported iso length ALSA: usb-audio: Add capture quirk for Behringer FCA1616 ALSA: hda/realtek: Add mute LED quirk for HP OMEN 15-ax ASoC: Intel: sof_es8336: Add a quirk for Huawei Matebook B3-420 ... commit df5cdc2c832ca4e8a6d774596b9005558761a403 Author: Tejun Heo Date: Wed Sep 16 12:00:24 2026 -1000 sched_ext: Derive SCX_RQ_IN_WAKEUP from the core enqueue flags schedule_deferred_locked() skips scheduling a deferred action while SCX_RQ_IN_WAKEUP is set and relies on the task_woken_scx() call that follows a wakeup enqueue to run it. enqueue_task_scx() sets the flag from the merged enqueue flags, which include the flags stashed for a remote activation. move_remote_task_to_local_dsq() thus sets SCX_RQ_IN_WAKEUP on the destination rq when the moved task was woken up, although no task_woken_scx() follows that activation. An IMMED insert into a busy destination requests a local reenqueue during that enqueue. The request gets linked but not scheduled and stays pending until an unrelated wakeup or preemption on that CPU runs the deferred actions. The IMMED task sits behind the running task in the meantime. If nothing runs them before the scheduler is disabled, the request outlives the scheduler and points into its freed per-cpu area, which the next scheduler dereferences from run_deferred(). Test the core enqueue flags for the wakeup bit. Only the core's wakeup path is followed by task_woken_scx(). Fixes: 57ccf5ccdc56 ("sched_ext: Fix enqueue_task_scx() truncation of upper enqueue flags") Cc: stable@vger.kernel.org # v7.1+ Reported-by: Andrea Righi Link: https://lore.kernel.org/all/20260916145807.3250167-1-arighi@nvidia.com/ Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit f143ea21cf834b4d57d70b47b99e582461f2dfaf Merge: 61cc777ca7a428 242da4318d9738 Author: Linus Torvalds Date: Thu Sep 17 09:40:25 2026 -0700 Merge tag 'pwrseq-fixes-for-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull power sequencing fixes from Bartosz Golaszewski: - fix kconfig issue in pwrseq-thread-gpu - fix error path logic in pwrseq_unit_enable() - fix two NULL-pointer dereference bugs in power sequencing core * tag 'pwrseq-fixes-for-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: fix NULL-pointer dereference in pwrseq_device_register() power: sequencing: fix NULL-pointer dereference in pwrseq_unit_new() power: sequencing: don't call .post_enable() if pwrseq_unit_enable() failed power: sequencing: Fix build issue with COMPILE_TEST commit 61cc777ca7a4280568ec3a8f730651d482f46e55 Merge: 4aec9ad1c66875 50fd0ada8d3758 Author: Linus Torvalds Date: Thu Sep 17 09:08:20 2026 -0700 Merge tag 'gpio-fixes-for-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix fwnode reference leak on failure in shared GPIO handling - fix regression in OF_POPULATED logic after the unification of GPIO hog handling between OF, ACPI and machine variants - don't call free_irq() if no IRQ is installed in gpio-virtuser * tag 'gpio-fixes-for-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: virtuser: skip free_irq when no IRQ is installed gpiolib: of: don't mark hog nodes OF_POPULATED before a chip is found gpiolib: Put fwnode reference on failure commit 2ac2fe765ef475f409616ac0b57c4a3922749b0f Author: Francis Marlou Pacaro Date: Fri Sep 4 08:20:21 2026 +0800 drm/amd/display: fix MALL hysteresis timer underflow at high refresh rates dcn30_apply_idle_power_optimizations() derives the MALL frame cache hysteresis timer with tmr_delay = (uint32_t)(div_u64(..., denom) - 64LL); div_u64() returns a u64, so when the quotient is smaller than 64 the subtraction wraps instead of going negative and tmr_delay ends up huge. The loop that follows tries to squeeze it into the 6 bit register field by doubling denom, but that only makes the quotient smaller, so tmr_delay can never converge. tmr_scale is bumped past 3 and the function gives up with /* Delay exceeds range of hysteresis timer */ ASSERT(false); even though the requested delay is too *short* to encode, not too long. With mall_additional_timer_percent left at its default of 0, the quotient drops below 64 once the refresh rate used for the calculation goes above ~243 Hz. Every DCN 3.0 display above that loses MALL static screen entirely and splats a WARN once per boot. Reproduced on Navi 23 (RX 6600) driving 1920x1080, resetting /sys/kernel/debug/clear_warn_once between modes: refresh MALL ASSERT 144 Hz enabled no 240 Hz enabled no 280 Hz skipped yes 360 Hz skipped yes Commit 3bb68cec4db8 ("drm/amd/display: Add Overflow check to skip MALL") already covered the other end of the range, where a large stutter period makes the delay too long to encode. Cover the short end by clamping to 0, which selects the shortest hysteresis the register can express, 65.28us * 64 = ~4.18ms. That is marginally longer than what the formula asks for at these refresh rates, and erring long is the safe direction: it only delays MALL entry, it can never enter early. The numerator does not change between iterations, only denom does, so compute it once and keep both call sites inside 100 columns. The genuinely out of range case at very low refresh rates still reaches the ASSERT, which is where it belongs. Fixes: 52f2e83e2fe5 ("drm/amdgpu/display: add MALL support (v2)") Signed-off-by: Francis Marlou Pacaro Reviewed-by: Leo Li Signed-off-by: Alex Deucher (cherry picked from commit 387550e53e1405f1f960b62b22f8783db17c8e1d) commit 5155002b03b24ba3ef91c5c313b8cf0171b24904 Author: Chengjun Yao Date: Tue Sep 8 10:15:43 2026 +0800 drm/amdgpu: fix rmmio iounmap skipped on device removal amdgpu_pci_remove() calls drm_dev_unplug() before fini_sw(), so drm_dev_enter() is already false there and the iounmap() guarded by it is skipped. This .remove path runs on both hot-unplug and plain rmmod, so the register BAR ioremap mapping leaks one instance per unload. Unmap rmmio unconditionally (guard only on non-NULL) and drop the now unused idx. Fixes: 62d5f9f7110a ("drm/amdgpu: Unmap MMIO mappings when device is not unplugged") Signed-off-by: Chengjun Yao Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher (cherry picked from commit dd6f86a97260e5207d3329ad03aa89fdad61b1e6) Cc: stable@vger.kernel.org commit 7f9caa70aef0950e06d395ca0035831214d88187 Author: Mario Limonciello Date: Tue Sep 15 12:51:24 2026 -0500 drm/amdgpu: Skip KFD mapping clear before initialization amdgpu_amdkfd_clear_kfd_mapping() assumes that a non-NULL kfd_dev has a fully populated node array. This is not true when KFD device initialization fails after probe. For example, kgd2kfd_device_init() sets num_nodes before checking PCIe atomics support. On Polaris systems without the required atomics, it returns before allocating nodes[0], but the kfd_dev remains attached to the amdgpu device. A later GPU reset then dereferences nodes[0]->id. Require the authoritative KFD initialization flag before walking the node array, matching the existing KFD reset and teardown paths. Fixes: 70cadefcc616 ("drm/amdgpu: unmap all user mappings of framebuffer and doorbell before mode1 reset") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5833 Reviewed-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 4ac1835823c47903fbb278bbf474773c46f59edc) Cc: stable@vger.kernel.org commit 0d2f4cfa564355fcbbc71498fd8ec09243036109 Author: Srinivasan Shanmugam Date: Tue Sep 15 14:07:39 2026 +0530 drm/amd/display: Fix NULL dereference in dcn50/dcn60 init_hw dc->clk_mgr is checked for NULL earlier in dcn50_init_hw() and dcn60_init_hw(), but dcn50_initialize_min_clocks() and dcn401_initialize_min_clocks() are called without any guard, causing Smatch to report potential NULL dereferences. Guard both call sites with the same pattern used throughout both functions: if (dc->clk_mgr && dc->clk_mgr->funcs) Also fix dcn50_initialize_min_clocks() which calls get_dispclk_from_dentist without checking the function pointer, unlike the dcn401 equivalent which guards that call. Fix kernel-doc in dcn60_hwseq.c by adding missing parameter descriptions for @probe in dcn60_update_probe_status() and @type in is_probe_measurement_type_for_hubbub(). Fixes: 7f7d7ea1fa51 ("drm/amd/display: Add new sources for DCN6") Reported-by: Dan Carpenter Cc: Aurabindo Pillai Cc: Ivan Lipski Cc: Dan Wheeler Cc: Roman Li Cc: Alex Hung Cc: Tom Chung Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 325c9a827cdd748e126eafeadaffc556204773d2) commit 8ee521b8b189799e361d4233c5180ba56656d4d4 Author: David Francis Date: Wed Aug 5 09:16:51 2026 -0400 drm/amdkfd: Avoid integer underflow in EOP ring size calculation. The low 6 bits of cp_hqd_eop_control store the base-2 logarithm of the EOP ring size. This was calculated as order_base_2(q->eop_ring_buffer_size / 4) - 1 But order_base_2 can in theory return 0, so this could underflow (although in practice the ring buffer size cannot be less than 4096). Change this to order_base_2(q->eop_ring_buffer_size / 8) using properties of logarithms. Also add to the above comment to make the mathematics more clear. Reviewed-by: Kent Russell Signed-off-by: David Francis Signed-off-by: Alex Deucher (cherry picked from commit f0f43fcf8b2b3a924cad9444340921c96ed5f634) Cc: stable@vger.kernel.org commit c883d0a132d430ef7ebb23fd94323be94d0fbdb8 Author: David Francis Date: Wed Aug 5 09:51:35 2026 -0400 drm/amdkfd: Avoid integer underflow with ffs in EOP ring size calc The low 6 bits of cp_hqd_eop_control store the base-2 logarithm of the EOP ring size. This was calculated as ffs(q->eop_ring_buffer_size / sizeof(unsigned int)) - 1 - 1 But ffs can in theory return 1 or 0, so this could underflow (although in practice the ring buffer size cannot be less than 4096). Change this to ffs(q->eop_ring_buffer_size / sizeof(unsigned int) / 4) using properties of logarithms. Reviewed-by: Kent Russell Signed-off-by: David Francis Signed-off-by: Alex Deucher (cherry picked from commit 4f18c56630383c14bfc6b2d65f88f2f895d2121a) Cc: stable@vger.kernel.org commit 04de4007d32385b8b6a5dd72bff3146dfdc592c3 Author: Mario Limonciello Date: Tue Sep 15 10:59:45 2026 -0500 drm/amdgpu: Fix GPU PCIe link capability reporting Commit eb53125a7ad9 ("drm/amd: Add dedicated helper for amdgpu_device_find_parent()") made amdgpu_device_gpu_bandwidth() query the first device outside the dGPU. That is the host side of the physical link, not the GPU side. As a result, the ASIC and platform capability masks can both be based on the host port. drm_amdgpu_info_device then exposes the host capabilities to userspace, such as Gen5 x16 for a Gen4 x8 GPU. Cache both ends of the physical link during device initialization. Use link_dev for the GPU capability and link_partner for the platform capability and _PR3 detection. Reported-by: "Marek Olšák" Closes: https://lore.kernel.org/amd-gfx/CAAxE2A4VhsAzzO1QjBjUg+NgnbD04ZzMyN6xsUJxjKJHH6hxiw@mail.gmail.com/ Suggested-by: Lijo Lazar Fixes: eb53125a7ad9 ("drm/amd: Add dedicated helper for amdgpu_device_find_parent()") Reviewed-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 7ea6a47224e2c6e89a3a682d7fbaace4817a55aa) Cc: stable@vger.kernel.org commit 723d4dc628d764b19cf9efca14b82cca5ff020c9 Author: Dmitriy Chumachenko Date: Mon Sep 14 17:33:03 2026 +0300 drm/amdgpu: check ras and obj before dereference nbio_v7_9_handle_ras_controller_intr_no_bifring() dereferences ras and obj without checking either for NULL. Both amdgpu_ras_get_context() and amdgpu_ras_find_obj() can return NULL, e.g. during the window between adev->nbio.ras being set (early in amdgpu_ras_init(), by design, to enable the fatal-error interrupt as soon as possible) and the PCIE_BIF ras object actually being created in RAS late_init. Any interrupt in that window crashes in hard-IRQ context. This is analogous to commit d190b459b2a4 ("drm/amdgpu: the warning dereferencing obj for nbio_v7_4"), which fixed the same issue in the nbio_v7_4 handler. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 7692e1ee2446 ("drm/amdgpu: add RAS fatal error handler for NBIO v7.9") Reviewed-by: Tao Zhou Signed-off-by: Dmitriy Chumachenko Signed-off-by: Alex Deucher (cherry picked from commit c7071767a50a32ed727cf800ac84372429e3b4b3) commit 636139603b99d2e3a18a46cf3f8d39313ce8042e Author: Mike Lothian Date: Sat Sep 12 00:29:08 2026 +0100 drm/amdgpu: hold a runtime PM reference for P2P dma-buf attachments amdgpu_dma_buf_map() adds VRAM to the allowed domains for a peer2peer attachment. GTT is only a fallback placement when VRAM is preferred, so ttm_bo_validate() migrates the buffer from GTT into VRAM. While the exporting device is runtime suspended its SDMA rings are down and the move fails: amdgpu: Move buffer fallback to memcpy unavailable An importer on a second GPU reaches this holding no runtime PM reference on the exporter, e.g. a compositor on the APU submitting a frame that references a buffer exported by an idle dGPU: amdgpu_cs_ioctl -> amdgpu_cs_parser_bos -> amdgpu_cs_bo_validate -> ttm_bo_validate -> amdgpu_bo_move -> dma_buf_map_attachment -> amdgpu_dma_buf_map -> ttm_bo_validate -> amdgpu_bo_move Pinning a dma-buf into VRAM has the same requirement, which commit 030631e97b20 ("drm/amdgpu: revert "take runtime pm reference when we attach a buffer" v2") called out as the one case that would need the reference back. Take it in attach and drop it in detach. pm_runtime_get_if_active() never resumes the device, so it cannot deadlock against the reservation taken during resume, which is why the old pm_runtime_get_sync() had to go. If the device is not active, clear peer2peer instead: the buffer then stays in GTT, which remains accessible while the GPU is powered down. If runtime PM is disabled, take a plain reference so the put in detach stays balanced. Fixes: 030631e97b20 ("drm/amdgpu: revert "take runtime pm reference when we attach a buffer" v2") Suggested-by: Christian König Reviewed-by: Christian König Signed-off-by: Mike Lothian Assisted-by: Claude:Opus-5 [Claude Code] Signed-off-by: Alex Deucher (cherry picked from commit 062ff15e30a48d14fb7d7558eba84f8dc97197f0) Cc: stable@vger.kernel.org commit 5f28bb1c2cd9dcdb76a20d61b3ea069b85893c59 Author: Vladimir Marioukhine Date: Wed Aug 12 13:19:46 2026 -0400 drm/amdkfd: implement restore_mqd callbacks for GFX12/12.1 kfd_mqd_manager_v12.c (GFX 12.0) and kfd_mqd_manager_v12_1.c (GFX 12.1) do not implement restore_mqd callbacks, leaving the function pointers NULL and causing CRIU restore to return -EOPNOTSUPP on GFX12. Implement restore_mqd for both compute and SDMA queues in kfd_mqd_manager_v12.c and kfd_mqd_manager_v12_1.c, modeled after the GFX 11 implementation with the following improvements: - update cp_mqd_base_addr_lo/hi to the newly allocated MQD address, fixing a pre-existing gap shared with v11 where the in-MQD copy still pointed at the old checkpoint-time address after restore - memset the full allocation before memcpy for compute queues to avoid stale data in the GTT sub-allocator tail; SDMA MQDs use sizeof(*m) since they are packed at mqd_size stride in a shared BO checkpoint_mqd registration is deferred to a follow-up patch that also implements get_checkpoint_info, so that checkpoint and restore are enabled together as a complete and testable unit. Note: GFX12.1 restore handles XCC0 only. Multi-XCC CRIU restore is currently unreachable due to a separate validation issue in kfd_criu_restore_queue(). A pr_warn_once() is emitted if a multi-XCC device is encountered. Signed-off-by: Vladimir Marioukhine Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit b1f9601237d050f5df478464cf51bf1fff29a256) Cc: stable@vger.kernel.org commit 63e19ef3ddab806c472748c825f4dc88dcd994e8 Author: Leo Li Date: Tue Aug 25 23:21:53 2026 -0400 drm/amd/display: Atomize IRQ register read/modify/write ops [Why] The OTG_GLOBAL_SYNC_STATUS register controls various HW IRQ sources for the output timing generator (OTG). VUPDATE_NO_LOCK is one of them. To enable the IRQ, driver sets the VUPDATE_NO_LOCK_EN bit in the GLOBAL_SYNC_STATUS register. To ack the IRQ after it fires, the driver sets the VUPDATE_NO_LOCK_CLEAR bit in the same GLOBAL_SYNC_STATUS register. The bit sets are done through read/modify/write operations, which are not atomic. Thus, the following race is possible: Thread A: IRQ handler: *HW IRQ fires* # IRQ disable val = read(GLOBAL_SYNC_STATUS) unset(val, VUPDATE_NO_LOCK_EN) write(val, GLOBAL_SYNC_STATUS) # ACK reads VUPDATE_NO_LOCK_EN unset val1 = read(GLOBAL_SYNC_STATUS) set(val1, VUPDATE_NO_LOCK_CLEAR) # IRQ enable val = read(GLOBAL_SYNC_STATUS) set(val, VUPDATE_NO_LOCK_EN) write(val, GLOBAL_SYNC_STATUS) # BAD! clears VUPDATE_NO_LOCK_EN write(val1, GLOBAL_SYNC_STATUS) Regarding the tagged Fixes: change, it appears the change made this race more likely to occur. Since VUPDATE_NO_LOCK is now the sole IRQ source for vblank handling, a single race on high refresh panels can lead to a time out. [How] The GLOBAL_SYNC_STATUS register is only one example, other IRQ control registers also share the same scheme. On top of GLOBAL_SYNC_STATUS, let's clean up those as well. To keep things simple, Let's atomize the IRQ rmw ops via a single driver-wide spinlock. Due to the small scope of this lock, it is unlikely to cause noticeable overhead on top of all the existing locking within the IRQ set/handle paths. Since DM is responsible for locking, wrap dc_interrupt_set/ack with the spinlock in the new amdgpu_dm_irq_set/ack functions. Migrate/drop all references in DM to dc_interrupt_set/ack to use amdgpu_dm_irq_set/ack instead. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5616 Fixes: c87e6635d2db ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock") Reviewed-by: Mario Limonciello Signed-off-by: Leo Li Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 70de0a0216583a53c946155f8c8adedfdca6b4e7) Cc: stable@vger.kernel.org commit 9413959fa9fe2d94d4814f8cc2b60409f4cd46b5 Author: Kevin Wang Date: Tue Aug 25 23:09:32 2026 +0800 drm/amd/pm: report energy accumulator for smu 14.0.3 add energy accumulator on pmfw 0x00685000 and above version. Signed-off-by: Kevin Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit 4aa733ab15b303e2a40e2985ac21a0e01f24cc4a) commit 3b95a04eb5f95bf6a016a1bb9ff37d3eee48de63 Merge: a5117e1eccac6e f3ef03357396d4 Author: Jakub Kicinski Date: Thu Sep 17 08:14:38 2026 -0700 Merge branch 'mptcp-misc-fixes-for-v7-3-rc4' Matthieu Baerts says: ==================== mptcp: misc fixes for v7.3-rc4 Here are two unrelated fixes: - Patch 1: avoid unneeded actions on subflow reset. A fix for another fix introduced in v6.12 and targeting a commit from v5.7. - Patch 2: close a possible race when scheduling a closing path. A fix for another fix introduced in v6.0 and targeting v5.10. - Patch 3: fix bad accounting when __subflow_push_pending returns an error. A fix for v6.6. ==================== Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-0-0cf5c72667c8@kernel.org Signed-off-by: Jakub Kicinski commit f3ef03357396d4b147d8e76c75fb612c2f264ffc Author: Paolo Abeni Date: Thu Sep 17 15:05:59 2026 +0200 mptcp: fix bad accounting in __mptcp_subflow_push_pending() If __subflow_push_pending() errors out we should avoid updating the copied byte counters, to avoid mismatch push call later on. Fixes: 0fa1b3783a17 ("mptcp: use get_send wrapper") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-3-0cf5c72667c8@kernel.org Signed-off-by: Jakub Kicinski commit 42064de57fb83231fcc89663a94885f228a1ee53 Author: Paolo Abeni Date: Thu Sep 17 15:05:58 2026 +0200 mptcp: close race between scheduler and state change The mptcp scheduler may race with subflow sockets state change: data transmission on the selected socket may fail and a later release could try to use mss_now reset to 0 for a divide operation. Address the issue by explicitly checking for the critical scenario. Fixes: c886d70286bf ("mptcp: do not queue data on closed subflows") Cc: stable@vger.kernel.org Reported-by: Shardul Bankar Reported-by: Xinyang Ge Closes: https://lore.kernel.org/20260525194828.1137119-1-shardul.b@mpiricsoftware.com Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-2-0cf5c72667c8@kernel.org Signed-off-by: Jakub Kicinski commit 2b0f561f21b27c40c91ea4975268a06092bd7e9c Author: Paolo Abeni Date: Thu Sep 17 15:05:57 2026 +0200 mptcp: avoid unneeded actions on subflow reset Once in a blue moon, the mptcp receive path can recursively call mptcp_data_ready() via state change under unlucky error conditions, and then try to hold the data lock again. Break the recursion loop explicitly checking for the exceptional condition. Add a new flag instead of using an existing one like 'closing', to exit early in subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() and more on a dying subflow -- but also in error reporting and worker scheduling. Note that we must consume the currently peeked skb before invoking mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it. Fixes: e32d262c89e2 ("mptcp: handle consistently DSS corruption") Cc: stable@vger.kernel.org Reported-by: Xinyang Ge Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-1-0cf5c72667c8@kernel.org Signed-off-by: Jakub Kicinski commit 4aec9ad1c668755b253bff4d95a9d82a17d2d434 Merge: 238650ef6c7c7c 55a8e145186923 Author: Linus Torvalds Date: Thu Sep 17 08:03:37 2026 -0700 Merge tag 'dma-mapping-7.3-2026-09-17' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux Pull dma-mapping fixes from Marek Szyprowski: "A few fixes for the DMA-mapping code: - resolved regression in accessing encrypted memory by IOMMU-backed devices (Aneesh Kumar K.V) - improved failure handling and removed rare bug in swiotlb/highmem (Donggeun Yoo)" * tag 'dma-mapping-7.3-2026-09-17' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux: x86/mm: Don't force unencrypted DMA for IOMMU-backed devices dma-mapping: don't trace the DMA address when the allocation fails swiotlb: use the adjusted address for the highmem page lookup dma-coherent: report a failed reserved memory assignment commit 1fca688e9443003e33cf30453e7a7560367656c9 Author: shechenglong Date: Mon Sep 7 11:51:47 2026 +0800 drm/client: fix restore of partially initialized client I got a null-ptr-deref report when closing a DRM file descriptor: WARNING: drivers/gpu/drm/drm_atomic.c:2031 at __drm_atomic_helper_set_config+0x18e/0x1b0 [drm] Call Trace: drm_client_modeset_commit_atomic+0x16b/0x220 [drm] drm_client_modeset_commit_locked+0x56/0x160 [drm] drm_client_modeset_commit+0x21/0x40 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x7b/0x80 drm_fbdev_client_restore+0xe/0x20 [drm_client_lib] drm_client_dev_restore+0x9f/0xc0 [drm] drm_release+0xc5/0xe0 [drm] The warning is followed by a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: __drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x41/0x80 [drm_kms_helper] Call Trace: drm_fbdev_client_restore+0xe/0x20 [drm_client_lib] drm_client_dev_restore+0x9f/0xc0 [drm] drm_release+0xc5/0xe0 [drm] __fput+0xdc/0x2b0 __x64_sys_close+0x39/0x80 do_syscall_64+0x8d/0x460 entry_SYSCALL_64_after_hwframe+0x76/0x7e drm_client_register() adds the DRM client to the device client list before invoking the initial hotplug callback. If the hotplug callback fails, the client remains registered. For the fbdev client, a failure during drm_fb_helper_initial_config() causes the partially initialized fbdev helper to be cleaned up. drm_fb_helper_fini() releases fb_helper->info and leaves it NULL. The fbdev client therefore remains registered even though there is no fully initialized framebuffer device. Later, when userspace closes the DRM file descriptor, drm_release() can invoke the restore callbacks of registered DRM clients: drm_release() drm_client_dev_restore() drm_fbdev_client_restore() drm_fb_helper_restore_fbdev_mode_unlocked() drm_fbdev_client_restore() currently restores the fbdev state unconditionally. For a partially initialized fbdev client this can submit an incomplete modeset state and subsequently access fbdev state which has not been initialized, resulting in the warning and NULL pointer dereference above. drm_fbdev_client_unregister() already uses fb_helper->info to distinguish a fully probed framebuffer device from a partially initialized client. Use the same condition in drm_fbdev_client_restore() and skip restore if no framebuffer device has been successfully initialized. Signed-off-by: shechenglong Reviewed-by: Thomas Zimmermann Fixes: 5d08c44e47b9 ("drm/fbdev: Add memory-agnostic fbdev client") Signed-off-by: Thomas Zimmermann Cc: # v6.13+ Link: https://patch.msgid.link/20260907035147.1339-1-shechenglong@xfusion.com commit a5117e1eccac6ee3bd4aed7cacf8ebcb6b3eb309 Author: Eric Dumazet Date: Tue Sep 15 13:04:23 2026 +0000 net: skbuff: do not leave stale header offsets after pskb_carve() pskb_carve_inside_header() and pskb_carve_inside_nonlinear() remove the first bytes of a packet and reallocate skb->head. All the headers that were present before the operation are gone, but both functions call skb_headers_offset_update(skb, 0), which is a no-op : skb->mac_header, skb->network_header, skb->transport_header and skb->csum_start keep their old values and now describe bytes which are no longer there. Both helpers size the new head from the old skb_end_offset(), so the stale offsets still land inside the new allocation. They point past skb_tail_pointer() though, to bytes that were never initialized. pskb_carve_inside_nonlinear() is the worst case, because it leaves a zombie skb with an empty linear part (skb->data == skb_tail_pointer(skb), skb_headlen(skb) == 0), while skb_mac_header_was_set() is still true and skb->mac_header is way ahead of skb->data. The only user of pskb_extract() is rds_tcp_data_recv(), and the carved skb is queued on tinc->ti_skb_list. When the RDS incoming message is released, rds_tcp_inc_free() calls skb_queue_purge(), which frees the skbs with SKB_DROP_REASON_QUEUE_PURGE. This is visible from drop_monitor, which then tries to pull back to the (bogus) mac header : skbuff: __skb_pull(len=234) skb len=6968 data_len=6968 headroom=0 headlen=0 tailroom=0 end-tail=384 mac=(234,14) mac_len=14 net=(248,40) trans=288 shinfo(txflags=0 nr_frags=1 gso(size=1428 type=16 segs=5)) csum(0x100120 start=288 offset=16 ip_summed=3 complete_sw=0 valid=1 level=0) hash(0x7b446c6c sw=0 l4=1) proto=0x86dd pkttype=0 iif=60 kernel BUG at ./include/linux/skbuff.h:2847! Add skb_carve_reset_headers() to mark the mac and transport headers as not set, reset the network header, clear skb->mac_len, and drop a now meaningless CHECKSUM_PARTIAL (csum_start no longer describes anything). Invalidate the inner offsets as well. Unlike mac_header and transport_header they have no "unset" sentinel, so a leftover non-zero value still looks like a real header. Zero skb->inner_mac_header, skb->inner_network_header, skb->inner_transport_header, skb->inner_protocol and skb->encapsulation, so that all the header state is invalidated in one place. v2: fixed an inaccurate changelog. The stale offsets stay inside the new skb->head, which is never smaller than the old one, they simply point past skb_tail_pointer() to bytes that are gone. Thanks to Xuanqiang Luo for insisting on this. Also invalidate the inner header state, as suggested by the netdev AI review : https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260911114922.621937-1-edumazet%40google.com Fixes: 6fa01ccd8830 ("skbuff: Add pskb_extract() helper function") Reported-by: syzbot+586af68eb819833c2d91@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6aa3e9d3.f2639fcc.29487d.0028.GAE@google.com/ Cc: Xuanqiang Luo Cc: Allison Henderson Cc: rds-devel@oss.oracle.com Signed-off-by: Eric Dumazet Reviewed-by: Xuanqiang Luo Link: https://patch.msgid.link/20260915130423.3956471-1-edumazet@google.com Signed-off-by: Paolo Abeni commit ad9c65b8f948f9ca00d065114d6cd7d281f53ec9 Merge: d798162eb364df d841cd7513f3d4 Author: Paolo Abeni Date: Thu Sep 17 15:18:10 2026 +0200 Merge branch 'tcp-exclude-old-acks-from-fast-path' Inbal Schussheim says: ==================== tcp: exclude old ACKs from fast path Exclude ACKs outside [SND.UNA, SND.NXT] from TCP header prediction so that they fall through to the slow path, where ACK validation is applied. Add a packetdrill test for a data segment carrying an excessively old ACK. The test fails on the unpatched kernel and passes with the fix. v2: https://lore.kernel.org/netdev/20260909075644.1408171-1-inbal.lipshtat@mail.huji.ac.il/ v1: https://lore.kernel.org/netdev/20260906123151.1391349-1-inbal.lipshtat@mail.huji.ac.il/T/#u ==================== Link: https://patch.msgid.link/20260914090408.1435080-1-inbal.lipshtat@mail.huji.ac.il Signed-off-by: Paolo Abeni commit d841cd7513f3d48018175ecb1fb972cfd3c3c10b Author: Inbal Schussheim Date: Mon Sep 14 12:04:08 2026 +0300 selftests: net: packetdrill: test exclusion of old ACK from TCP fast path Add a packetdrill test for an in-sequence data segment carrying an excessively old ACK. Verify that the segment falls through from the TCP fast path to the slow path, where the existing ACK validation rejects it and sends a challenge ACK. The payload is not accepted and RCV.NXT remains unchanged. Based on the reproducer from Commit 3d501dd326fb ("tcp: do not accept ACK of bytes we never sent"). Signed-off-by: Inbal Schussheim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260914090408.1435080-3-inbal.lipshtat@mail.huji.ac.il Signed-off-by: Paolo Abeni commit f81e6c3fb06327bc49cdd6e559845293ba06a704 Author: Inbal Schussheim Date: Mon Sep 14 12:04:07 2026 +0300 tcp: exclude old ACKs from tcp fast path Exclude old ACKs before SND.UNA from the tcp fast path as well as ACKs after SND.NXT. Such ACKs will fall through to the slow path, where tcp_ack() performs the appropriate validation and challenge ACK handling according to RFC5961 and Commit 3d501dd326fb1c7 ("tcp: do not accept ACK of bytes we never sent"). This prevents old ACKs from being accepted or modifying connection state as part of the fast path before appropriate ACK validation is applied. In particular, this prevents payload carried by a segment with an excessively old ACK from advancing RCV.NXT before the ACK is rejected. Fixes: 31770e34e43d ("tcp: Revert "tcp: remove header prediction"") Reported-by: Amit Klein Reported-by: Tamir Shahar Reported-by: Inbal Schussheim Suggested-by: Eric Dumazet Cc: stable@vger.kernel.org Signed-off-by: Inbal Schussheim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260914090408.1435080-2-inbal.lipshtat@mail.huji.ac.il Signed-off-by: Paolo Abeni commit d798162eb364df2e77a56fdbe5bae54440152d3b Author: Jakub Kicinski Date: Tue Sep 15 14:30:47 2026 -0700 dpll: reject a reference sync pin which is not on the pin's dpll dpll_pin_ref_sync_state_set() resolves the partner's driver private data with dpll_pin_on_dpll_priv() and passes the result to ref_sync_get() and ref_sync_set() without looking at it. The helper returns NULL when the partner holds no ref on that dpll. Of the two drivers implementing the feature only zl3073x dereferences the pointer (sync_pin->id); ice ignores it, so ice cannot fault here. The NULL is a teardown race, not a steady state - zl3073x registers every input pin with every channel, so the partner is normally present on the dpll the base pin resolves to. zl3073x_dev_stop() unregisters pins one at a time, taking and dropping dpll_lock for each, and between the partner's turn and the base pin's the partner is out of that dpll's pin_refs while still registered with the channels not yet torn down, so dpll_pin_available() keeps passing. That path is not only driver removal: devlink reload and devlink dev flash both run zl3073x_dev_stop(). Reproduced by holding that state open with a mock dpll device, which is where the frame name comes from: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:mock_ref_sync_get+0x5/0x30 Call Trace: dpll_pin_ref_sync_set+0x19f/0x4a0 dpll_nl_pin_set_doit+0x17d/0x840 genl_family_rcv_msg_doit+0xd6/0x130 genl_rcv_msg+0x181/0x2b0 netlink_rcv_skb+0x55/0x100 genl_rcv+0x23/0x30 netlink_unicast+0x24d/0x370 netlink_sendmsg+0x1e2/0x420 __sys_sendto+0x1db/0x1f0 __x64_sys_sendto+0x1f/0x30 do_syscall_64+0xe1/0x490 Commit d2e914a4a0d0 ("dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()") added the same guard to the read side, which the kernel walks into by itself because the delete notification is emitted from inside the unregister; the write side needs a pin-set to land in the window and was left alone. Test the priv rather than look up pin_refs directly, so that the two halves key off the same condition. Fixes: 58256a26bfb3 ("dpll: add reference sync get/set") Signed-off-by: Jakub Kicinski Reviewed-by: Ivan Vecera Link: https://patch.msgid.link/20260915213047.1352286-1-kuba@kernel.org Signed-off-by: Paolo Abeni commit 14cb1e7702e5cb3c58888f6aed498381a73927d2 Author: Dmitriy Okunev Date: Mon Sep 14 12:15:57 2026 +0300 net: mvpp2: prevent buffer overflow in page_pool allocation The per‑processor buffering scheme is supported only if the number of pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS (8). This is already checked in mvpp2_probe() during the initial activation of percpu_pools. However, mvpp2_change_mtu() may later call mvpp2_bm_switch_buffers(priv, true) without this check, which can lead to an out-of-bounds access in the priv->page_pool array in mvpp2_bm_init(). The array is sized to hold MVPP2_PORT_MAX_RXQ entries, and mvpp2_get_nrxqs() may return exactly that value. The per-CPU scheme then doubles it to nrxqs * 2, exceeding the array bounds. Check that the hardware version is MVPP22 or newer and that the number of pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS before switching to per-CPU mode. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 7d04b0b13b11 ("mvpp2: percpu buffers") Signed-off-by: Dmitriy Okunev Link: https://patch.msgid.link/20260914091557.71769-1-dokunevdmitriy@gmail.com Signed-off-by: Paolo Abeni commit 95b2e0361c88753afa030c10698be0a1a5b67650 Author: Kyle Zeng Date: Thu Sep 17 12:56:43 2026 +0200 ALSA: seq: Serialize compat port-info ioctls The native sequencer ioctl path serializes handler calls with client->ioctl_mutex, but the translated port-info compat path invokes the same handlers through snd_seq_kernel_client_ctl() without taking that mutex. This lets concurrent compat CREATE_PORT requests pass the port-count check before any request reaches the serialized insertion. The computed integer port index can then exceed the address field range and wrap to an existing index. Subsequent subscriber teardown can resolve the duplicate address to the wrong port and access a freed subscriber. Take ioctl_mutex while dispatching converted port-info requests, matching the native ioctl path. All translated port-info commands share this helper, so their accesses to the client port state are serialized as well. Fixes: b3defb791b26 ("ALSA: seq: Make ioctls race-free") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol gpt-6-astra Signed-off-by: Kyle Zeng Signed-off-by: Bruno Produit Link: https://patch.msgid.link/20260917105643.90102-1-bruno.produit@trailofbits.com Signed-off-by: Takashi Iwai commit 9ca4ba24259183ce15665be86b2956cd896c4687 Author: James Clark Date: Tue Sep 15 11:58:17 2026 +0700 net: macb: fix ordering around PTP timestamp read PTP_SYS_OFFSET_EXTENDED returns system timestamps that do not correctly bracket the PHC register read on MACB/GEM. On a Raspberry Pi 5, the returned interval can be as short as 37 ns, while an ordered register read takes approximately 1 us. This biases the midpoint used by phc2sys, causing CLOCK_REALTIME to run approximately 0.5 us ahead when synchronized to the PHC. gem_tsu_get_time() reads the nanoseconds register using the driver's relaxed MMIO accessor. On weakly ordered systems, the subsequent system timestamp can be taken before the register read completes. The internal smp_rmb() in the pre-timestamp path also does not guarantee ordering against the subsequent MMIO read. Add rmb() before and after the bracketed nanoseconds read in both the normal and seconds rollover paths so the system timestamps bracket the PHC read. Adding the post-read barrier increases the minimum interval on the same Raspberry Pi 5 to approximately 1 us. Fixes: e51bb5c2784c ("net: macb: ptp: Switch to gettimex64() interface") Tested-by: Nicolai Buchwitz # Raspberry Pi CM5, min bracket 37 ns -> 981 ns Reviewed-by: Nicolai Buchwitz Reviewed-by: Théo Lebrun Assisted-by: LLM Signed-off-by: James Clark Link: https://patch.msgid.link/20260915045823.76100-1-jjc@jclark.com Signed-off-by: Paolo Abeni commit f6988c90671e83db79df1b7b9d6fdb0e5947fd84 Author: Patrick Lu (Anthropic) Date: Fri Sep 11 18:49:49 2026 +0000 writeback: bound cleanup_offline_cgwb() rescans by rotating scanned inodes cleanup_offline_cgwb() prepares at most WB_MAX_INODES_PER_ISW inodes per call and is called again until the dying wb is drained, but every call walks wb->b_attached and then wb->b_dirty_time from the same end. Inodes already prepared (they stay on the list with I_WB_SWITCH set until the switch worker runs) and inodes that cannot be switched (I_FREEING, I_WILL_FREE, !SB_ACTIVE, DAX, already on the target wb) stay where they are, so each pass rescans a growing run of them under wb->list_lock and a full drain is quadratic in the number of inodes on the list. With ~17M inodes attached to one dying cgwb we saw this end in soft lockups, with CPUs reported stuck for 21-48s. Walk both lists from the oldest end and move every scanned inode to the newest end, so the next pass starts where the previous one stopped and the drain becomes linear. b_attached is unordered, so nobody sees the reorder there. b_dirty_time is ordered by dirtied_when, but the oldest unscanned inode stays at the end move_expired_inodes() picks from, sync takes the whole list regardless of order, and prepared inodes leave the list as soon as the switch work runs and get a new dirtied_time_when on the new wb anyway, so the only inodes left out of order are the ones that can never switch (DAX), and only on the dying wb. Fixes: c22d70a162d3 ("writeback, cgroup: release dying cgwbs by switching attached inodes") Cc: stable@vger.kernel.org Acked-by: Tejun Heo Acked-by: Roman Gushchin Signed-off-by: Patrick Lu (Anthropic) Link: https://patch.msgid.link/20260911-wb-cgwb-rotate-v2-1-a9ab253a1295@gmail.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit 7459c021874246c196f397686e100702f059b9e7 Author: Julian Sun Date: Tue Sep 15 12:49:12 2026 +0800 fs: avoid repeated scans in evict_inodes() We observed hung tasks when users attempted to unmount a filesystem after its disk had been removed while still in use. During device removal, fs_bdev_mark_dead() calls evict_inodes() while holding s_umount. Each time evict_inodes() drops s_inode_list_lock to reschedule, it restarts the walk from the head of s_inodes. With many referenced inodes at the head of the list, these restarts repeatedly scan the same inodes without reclaiming them. This can keep s_umount held for a long time, blocking concurrent umount attempts and triggering hung-task reports. Keep the current inode, already marked I_FREEING, out of the disposal batch until s_inode_list_lock is reacquired. Resume the walk from this inode and dispose of it in a later batch or at the end of the walk. The zero-refcount and state checks under i_lock allow this walker to claim the inode by setting I_FREEING and removing it from the LRU. Other reclaimers skip the inode, leaving this walker responsible for eviction. Only evict() removes it from s_inodes, so keeping it out of the disposal batch ensures that it remains on the list while the lock is dropped. After reacquiring the lock, reading its current next pointer accounts for concurrent removal of following inodes. The existing inode lifetime rules prohibit acquiring a reference to an inode marked I_FREEING or I_WILL_FREE. __iget() requires its caller to hold i_lock and establish that taking a reference is valid. Inode lookup and igrab() check these flags under i_lock when acquiring a reference from zero. ihold() requires an existing reference, which would keep i_count nonzero and prevent this walker from claiming the inode. These rules already allow iput_final() and the inode shrinker to release i_lock after setting I_FREEING and before eviction completes. A temporary __iget() reference would also keep the inode on the list, but its release must preserve last-reference handling. Another user can acquire a reference, update lazy timestamps and drop its reference while the pin is held. If the pin becomes the last reference, dropping it with atomic_dec_and_test() and evicting directly bypasses iput()'s lazytime handling and can lose those timestamp updates. Releasing the pin with iput() preserves that handling, but does not guarantee eviction. fs_bdev_mark_dead() runs with SB_ACTIVE set, so iput() may retain the inode in cache, whereas evict_inodes() must evict eligible zero-reference inodes. The inode may also have been freed when iput() returns, so the walker cannot then use it to force eviction. Using I_FREEING preserves the existing eviction behavior without introducing an additional last-reference transition. The xfstests auto group passed on ext4 and XFS with known unrelated failures excluded. No new issues were observed, and the previously reproducible hung task no longer occurs with this patch. Fixes: ac05fbb40062 ("inode: don't softlockup when evicting inodes") Signed-off-by: Julian Sun Link: https://patch.msgid.link/20260915044912.3183440-1-sunjunchao@bytedance.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit c51e89c5b5db3e1927738fad7cd18b66dde68aed Author: David Howells Date: Tue Sep 15 17:21:59 2026 +0100 netfs, afs: Fix symlink reading 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) commit 02af7eac17bc62a72335c1fc8c4af4471654f6cc Author: Rosen Penev Date: Mon Sep 14 17:44:06 2026 -0700 gpio: mvebu: keep resume masks within the irqchip cache mvebu_gpio_resume() writes the edge/level mask registers saved at suspend time straight back to hardware, bypassing the irqchip's mask_cache_priv. genirq skips mask_irq() for a line it already considers masked, so restoring a bit in hardware that genirq thinks is still masked leaves that line unmasked behind genirq's back. An asserted level line then has nobody to ack it, and the moment interrupts are re-enabled the chained handler storms, hanging resume. AND the restored mask values with the matching irqchip mask cache so only lines genirq currently considers unmasked are unmasked again. Read the caches under gc->lock to keep them consistent with the mask/unmask handlers. Tested on Helios4 (armhf): 5 suspend cycles woken by magic packet, no hang; mvebu_gpio_resume() returns in 6 usecs. Assisted-by: LLM Signed-off-by: Rosen Penev Link: https://patch.msgid.link/20260915004406.115230-1-rosenp@gmail.com Signed-off-by: Bartosz Golaszewski commit e9d810279f84b30738f7790c0ed15f8dd5b9024a Author: Wentao Liang Date: Wed Sep 16 09:47:01 2026 +0000 gpio: arizona: Fix runtime PM leak in arizona_gpio_direction_out() Switching a persistent GPIO line from input to output acquires a runtime PM reference on the parent device, but if the subsequent regmap_update_bits() fails the reference is never dropped and no later direction_in() can balance it since the direction was never changed. Drop the reference on the update failure path. Fixes: 27a49ed17e22 ("gpio: arizona: Add support for GPIOs that need to be maintained") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260916094701.2007509-1-vulab@iscas.ac.cn Signed-off-by: Bartosz Golaszewski commit dcb5df182b37587d5ad6bb4388751bf5180957ac Author: Konrad Dybcio Date: Thu Sep 17 11:03:27 2026 +0200 pinctrl: qcom: qcs8300: Fix intr_target_width The default width of the interrupt target field doesn't match the actual register layout. Fix it. Fixes: 0c4cd2cc87c8 ("pinctrl: qcom: add the tlmm driver for QCS8300 platforms") Assisted-by: LLM Signed-off-by: Konrad Dybcio Reviewed-by: Shawn Guo Link: https://patch.msgid.link/20260917-topic-tlmm_intr_width_fixes-v1-3-3bc1d056aa6b@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit 912df33f296e6c4ced8c0a5e7998d570a0b82214 Author: Konrad Dybcio Date: Thu Sep 17 11:03:26 2026 +0200 pinctrl: qcom: maili: Fix intr_target_width The default width of the interrupt target field doesn't match the actual register layout. Fix it. Fixes: 251b53103a2e ("pinctrl: qcom: Add the tlmm driver for Maili platform") Assisted-by: LLM Signed-off-by: Konrad Dybcio Reviewed-by: Shawn Guo Link: https://patch.msgid.link/20260917-topic-tlmm_intr_width_fixes-v1-2-3bc1d056aa6b@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit 9d4c3e0c6a53eb390d58b8d7aaf08885e46f93fd Author: Konrad Dybcio Date: Thu Sep 17 11:03:25 2026 +0200 pinctrl: qcom: hawi: Fix intr_target_width The default width of the interrupt target field doesn't match the actual register layout. Fix it. Fixes: 90700e10d2ad ("pinctrl: qcom: Add Hawi pinctrl driver") Assisted-by: LLM Signed-off-by: Konrad Dybcio Reviewed-by: Shawn Guo Link: https://patch.msgid.link/20260917-topic-tlmm_intr_width_fixes-v1-1-3bc1d056aa6b@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit 68ab4a6a84b92f52650508acb60317eb76454250 Author: Zhangfei Gao Date: Wed Sep 16 16:57:20 2026 +0800 pinctrl: qcom: nord: fix GPIO interrupt target width The TARGET_PROC field in the Nord GPIO_INTR_CFG registers occupies bits 11:8. Describe it as four bits wide so the common Qualcomm pinctrl code clears the complete field before routing an interrupt to the application processor. Without intr_target_width, the common code uses its three-bit default mask. Since GPIO_INTR_CFG resets with TARGET_PROC set to 0xf (NONE), bit 11 remains set when the driver programs HMSS target 3. The resulting target is 0xb (HPASS_DSP_1), observed as an interrupt configuration value of 0xb1b instead of 0x31b. The GPIO interrupt status is consequently latched, but the HMSS TLMM summary interrupt at GIC SPI 208 is never asserted. This affects all Nord GPIO interrupts using the TLMM summary path, including the Ethernet PHY interrupts on GPIO55 and GPIO141. Fixes: c24dd0826f06 ("pinctrl: qcom: add the TLMM driver for the Nord platforms") Signed-off-by: Zhangfei Gao Reviewed-by: Konrad Dybcio Reviewed-by: Shawn Guo Link: https://patch.msgid.link/20260916085720.771498-1-zhangfei.gao@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit fe2f9135df43db849e74f03956d322ac20b59af7 Author: Darrick J. Wong Date: Mon Sep 14 22:39:25 2026 -0700 xfs: fix wild memcpy access when formatting ondisk rtrefcount btree roots LOLLM noticed that the inode btree root formatting methods copy too many bytes -- there's only one set of keys in node blocks, not two. This causes memory corruption of whatever's beyond the buffers. Cc: stable@vger.kernel.org # v6.14 Fixes: f0415af60f482a ("xfs: wire up a new metafile type for the realtime refcount") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 476582d754cdc5110f806001417fea6c77824c13 Author: Darrick J. Wong Date: Mon Sep 14 22:39:10 2026 -0700 xfs: don't let hidden_space go negative in xfs_metafile_resv_init LOLLM points out that if the amount of fdblocks that we can reserve for a metadata btree file goes below the space already used by that file, then the hidden_space subtraction can underflow, causing xfs_dec_fdblocks to subtract a huge amount of space. We never want the target to be less than the used sapce, so fix the logic that adjusts dblocks_avail downwards. Also fix an error in the adjacent comment. Cc: stable@vger.kernel.org # v6.15 Fixes: 1df8d75030b787 ("xfs: make metabtree reservations global") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit ffb48dccce1960a9ea24463a2f3c21d124d6b672 Author: Darrick J. Wong Date: Mon Sep 14 22:38:54 2026 -0700 xfs: drop dquot flush lock when we can't find a buffer to flush LOLLM noticed that xfs_qm_flush_one fails to drop the dquot flush lock if it can't grab the buffer associated with the dquot. Since there's no buffer, nobody else is going to drop the dqflock, so we need to do it ourselves. Cc: stable@vger.kernel.org # v6.13 Fixes: ca378189fdfa89 ("xfs: convert quotacheck to attach dquot buffers") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 65f39d09d73718611cee40399179323b5d4ead00 Author: Darrick J. Wong Date: Mon Sep 14 22:38:38 2026 -0700 xfs: fix cursor and pointer handling when recovering iunlink buckets LOLLM pointed out a bug in xlog_recover_iunlink_bucket: 1. We don't null out prev_ip after releasing it, which can lead to UAF problems if the inodegc flush call in the loop fails. at which point I noticed even more bugs: 2. If the inodegc flush inside the loop fails, we also leak @ip. 3. We set prev_agino to agino having already advanced agino, which results in inodes with i_prev_unlinked set to itself. 4. If we exit the bottom of the loop with prev_ip set, then prev_ip aliases ip and we also set its i_prev_unlinked to itself. Bugs 3 and 4 introduce loops into the unlinked list, though these loops don't surface because we immediately flush each unlinked inode after loading it. Fix all of these issues. Cc: stable@vger.kernel.org # v6.0 Fixes: 04755d2e5821b3 ("xfs: refactor xlog_recover_process_iunlinks()") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit f8f6382ff13109e19d0fc1d0224ff7d29641e56a Author: Darrick J. Wong Date: Mon Sep 14 22:38:23 2026 -0700 xfs: fix blockgc group quota scanning when usrquota isn't enforced LOLLM noticed the copy-paste error here -- if user quotas aren't enforced but we're near the group quota limit, we fail to set FLAG_GID and hence we might not actually free any preallocations, causing unnecessary EDQUOT. Fix that. Cc: stable@vger.kernel.org # v5.12 Fixes: c237dd7c709432 ("xfs: flush eof/cowblocks if we can't reserve quota for inode creation") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit d80993655f7be2a461c0a63e2022da5757f47dac Author: Darrick J. Wong Date: Mon Sep 14 22:38:07 2026 -0700 xfs: don't merge different file IO error types LOLLM noticed that we can accidentally merge file range health monitoring events even if they have different errors. We shouldn't do that. Cc: stable@vger.kernel.org # v7.0 Fixes: dfa8bad3a8796c ("xfs: convey file I/O errors to the health monitor") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit ab1c416d2377cdc16123ef521aac4da1c468c3d4 Author: Darrick J. Wong Date: Mon Sep 14 22:37:52 2026 -0700 xfs: don't let memory failures leak blocks and kill repairs LOLLM complains that a memory allocation failure in xrep_newbt_add_blocks results in online repair leaking blocks that were previously allocated to write a new btree, but the problem is worse than that -- a limitation of the codebase is that the callers cannot undo the transaction /and/ return the error -- either you undo all changes and commit the transaction, or you error out and the filesystem goes down. However, the new btree space reservation object isn't that big (~48 bytes). Let's just do a NOFAIL allocation and the problem goes away. Cc: stable@vger.kernel.org # v6.8 Fixes: be408417630427 ("xfs: implement block reservation accounting for btrees we're staging") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit d7b92cbe566f6fe54368f62e4b515d9f80c43a18 Author: Darrick J. Wong Date: Mon Sep 14 22:37:36 2026 -0700 xfs: don't cross reference rmapbt with bitmaps if they're incomplete LOLLM points out that runtime errors (e.g. ENOMEM) when we're trying to compute space usag bitmaps are silently dropped by the rmapbt scrubber. We ought to flag that as an incomplete scrub instead of reporting cross-referencing errors based on faulty data. Cc: stable@vger.kernel.org # v6.4 Fixes: fed050f3452da0 ("xfs: cross-reference rmap records with ag btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 41c4c41cf6c44f98db2916e1781f537d9ba6461a Author: Darrick J. Wong Date: Mon Sep 14 22:37:20 2026 -0700 xfs: fix rtgroup repair estimations When I added online fsck for realtime reflink, I forgot to update xrep_calc_rtgroup_resblks to factor in the size of the refcount btree when it guesses how much space we need to start a repair. This hasn't been a huge problem in practice because there are few filesystems with (a) realtime, (b) rtgroups, (c) reflink, and (d) no rmap. But let's fix this before someone stumbles upon it, especially since LOLLM flagged this for me. Cc: stable@vger.kernel.org # v6.14 Fixes: 83ccffc489975d ("xfs: online repair of the realtime refcount btree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 065f3ce5936e68da75f3dc18201d290073d78f3c Author: Darrick J. Wong Date: Mon Sep 14 22:37:05 2026 -0700 xfs: call xfs_dquot_set_prealloc_limits if we installed default rtb limits Now that we have quotas for the realtime volume, we also have precomputed watermark limits for the realtime block counts. These precomputations should be done any time we change the rtb limits, which means that xfs_qm_adjust_dqlimits needs to ensure that if we installed a default rtb limit. Cc: stable@vger.kernel.org # v6.13 Fixes: 5dd70852b03901 ("xfs: create quota preallocation watermarks for realtime quota") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit fc3ae66514ca5e87251f79044236e3e8babd24a3 Author: David Howells Date: Mon Sep 14 16:20:27 2026 +0100 netfs: Fix netfs_read_gaps() to use separate sink folios Fix netfs_read_gaps() to use separate folios rather than re-using a single sink folio to discard the unwanted data so that cifs checksum checking sees all the data that was fetched. Fixes: 7f84a7b9892d ("netfs: Make netfs_read_folio() handle streaming-write pages") Reported-by: Frank Sorenson Closes: https://lore.kernel.org/r/a385053c-1c4a-4060-a3bb-befa007ddb33@redhat.com/ Signed-off-by: David Howells Link: https://patch.msgid.link/3228134.1789399227@warthog.procyon.org.uk Tested-by: Frank Sorenson Reviewed-by: Paulo Alcantara cc: Paulo Alcantara cc: Namjae Jeon cc: netfs@lists.linux.dev cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit b15e54761a0dd5fdf3dc790a031ab0e4185b7612 Merge: fd73f4a6659897 a15fac810c7639 Author: Dave Airlie Date: Thu Sep 17 19:05:20 2026 +1000 Merge tag 'drm-msm-fixes-2026-09-16' of https://gitlab.freedesktop.org/drm/msm into drm-fixes Fixes for v7.3-rc4: DT: - Corrected indentation Core: - Marked fbdev as system memory GPU: - Fixed autosuspend cleanup on teardown - a750: fix timestamps - Increase GMU fw init timeout - Misc fixes/cleanups DPU: - Fixed clock rounding, unbreaking newest platforms - Cleared pending flush state DP: - Skip PUSH_IDLE when link was never enabled - Fixed bandwidth checks HDMI: - Fixed runtime PM cleanup on probe failure Signed-off-by: Dave Airlie From: Rob Clark Link: https://patch.msgid.link/CACSVV021rZsjmiPEyR_LR7L=k7=DRV0QdsA50BF_Gd0s2DXaCw@mail.gmail.com commit ea31c6498c61307dc0d8ce338a7f268cb8cbdd57 Author: Jameson Thies Date: Thu Sep 17 03:20:08 2026 +0000 usb: typec: ucsi: displayport: Current CAM OOB index fixup Update ucsi_displayport_enter() to return invalid error when the PPM reports an current alternate mode greater than or equal to UCSI_MAX_ALTMODES. While here, remove 0xff current cam assignment on failed GET_CURRENT_CAM response. Fixes: 04cec690b1fd ("usb: typec: ucsi: displayport: Fix OOB altmode array index") Cc: stable Reviewed-by: Heikki Krogerus Reviewed-by: Benson Leung Signed-off-by: Jameson Thies Link: https://patch.msgid.link/20260917032008.1701888-1-jthies@google.com Signed-off-by: Greg Kroah-Hartman commit a5f7a5bb3b7f28ba7e4fa246775b29a0e5537255 Author: Jinke Han Date: Tue Sep 8 15:37:42 2026 +0800 x86/kprobes: Fix crash when probing CS CALL instructions When using eBPF to probe CS CALL instructions within a function, a crash can be triggered. The eBPF tool probes offset 257 of the __hrtimer_run_queues() function: <__hrtimer_run_queues+249>: nopl 0x0(%rax,%rax,1) <__hrtimer_run_queues+254>: mov %r14,%rdi <__hrtimer_run_queues+257>: cs call <__x86_indirect_thunk_r12> <__hrtimer_run_queues+263>: mov %eax,%r12d <__hrtimer_run_queues+266>: xchg %ax,%ax <__hrtimer_run_queues+268>: mov %r13,%rdi Which triggers this crash: BUG: unable to handle page fault for address: 00000000000f41c9 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: P RIP: 0010:__hrtimer_run_queues+0x106/0x230 Note that __hrtimer_run_queues+0x106 is __hrtimer_run_queues+262, which is at the 6th byte of the above CS CALL instruction. Since the CS CALL instruction occupies 6 bytes, the exception occurred in the middle of that call instruction. The root cause is that when using eBPF tools to probe in the middle of a function, a kprobe with INT3 is used as the underlying implementation. During single-step emulation of the original CALL instruction, int3_emulate_call() assumes that the probed CALL instruction is 5 bytes long. However, the actual CS-prefixed CALL instruction occupies 6 bytes, so it constructs an incorrect exception return address. When the CPU returns from the kprobe handler, the next instruction to be executed is at the address of the last byte of that CS CALL instruction. Coincidentally, starting from that address, the CPU fetches and decodes a completely different instruction, which ultimately triggers a kernel crash. Fix the issue by using the actual instruction length obtained from the instruction decoder when constructing the exception return address, rather than relying on the hardcoded CALL_INSN_SIZE macro. [ mingo: Refined the changelog ] Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step") Suggested-by: Masami Hiramatsu (Google) Signed-off-by: Jinke Han Signed-off-by: Ingo Molnar Reviewed-by: Masami Hiramatsu (Google) Acked-by: Yafang Shao Acked-by: Borislav Petkov Cc: Peter Zijlstra Link: https://patch.msgid.link/20260908073742.GA10517@didi-ThinkCentre-M920t-N000 commit 5535d5e61a77ad79118ea7665ce1c14f857f0f12 Author: Huacai Chen Date: Thu Sep 3 16:42:12 2026 +0800 drm/loongson: Create blend mode property for cursor plane After commit 860e748bddcc929 ("drm: ensure blend mode supported if pixel format with alpha exposed") we get warnings at boot: loongson 0000:00:06.1: [drm] [PLANE:41:ls-cursor-plane-0] pixel format with alpha exposed but blend mode not setup. Please fix. loongson 0000:00:06.1: [drm] [PLANE:46:ls-cursor-plane-1] pixel format with alpha exposed but blend mode not setup. Please fix. The reason is the cursor plane supports color formats with alpha but the driver doesn't create blend mode property, which triggers the warning in validate_blend_mode_for_alpha_formats(). The loongson DC HW doesn't support DRM_MODE_BLEND_PREMULTI, so create blend mode property with DRM_MODE_BLEND_COVERAGE for cursor planes since it is the only one implemented in the driver. Signed-off-by: Huacai Chen Reviewed-by: Jianmin Lv Signed-off-by: Icenowy Zheng Link: https://patch.msgid.link/20260903084212.3621540-1-chenhuacai@loongson.cn commit 546b928da0427b0d6c663cbb992bd7bfa9ac7971 Merge: dbd9d1cbf97005 940e8fe8535d22 Author: Takashi Iwai Date: Thu Sep 17 08:15:32 2026 +0200 Merge tag 'asoc-fix-v7.3-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v7.3 A relatively large pile of fixes here, a lot of driver specific stuff that's broadly unremarkable plus a few core fixes from Richard that fix issues where SoundWire systems with multiple CODECs on the same link would configure the CODECs to use the same bus slots leading to broken audio. commit 9590f4d83880dfb5a81906e48e72779248fbe8f0 Author: Vineeth Vijayan Date: Thu Sep 10 11:32:03 2026 +0200 s390/cio: Guard PMCW field accesses with dnv check When PMCW.DNV is 0, no I/O device is associated with the subchannel. However, several code paths access PMCW fields directly from the cached sch->schib without first invoking the update helper. Add explicit DNV validation before accessing PMCW fields from the cached SCHIB to avoid using invalid data. Reported-by: William Bezenah Signed-off-by: Vineeth Vijayan Reviewed-by: Peter Oberparleiter Fixes: 8c58a229688c ("s390/cio: Do not unregister the subchannel based on DNV") Signed-off-by: Heiko Carstens commit f6f2985eabdb2bfdc82ce90a1ea3ec53ba795f34 Author: Vineeth Vijayan Date: Thu Sep 10 11:32:02 2026 +0200 s390/cio: Check pmcw.dnv before pmcw.ena in I/O entry points The device number valid (dnv) bit in the PMCW must be checked before acting on any other PMCW fields for IO-type subchannels. A subchannel with dnv=0 has no valid device number associated, making it meaningless to evaluate the enabled (ena) state or issue any I/O instruction against it. Reported-by: William Bezenah Signed-off-by: Vineeth Vijayan Reviewed-by: Peter Oberparleiter Fixes: 8c58a229688c ("s390/cio: Do not unregister the subchannel based on DNV") Signed-off-by: Heiko Carstens commit 29d9e5835d89223aa913dcf7b942cc1c148bdd25 Author: Vineeth Vijayan Date: Thu Sep 10 11:32:01 2026 +0200 s390/cio: Fix cio_update_schib() to not cache invalid schib When pmcw.dnv is 0, the contents of all SCHIB fields are unpredictable. Zero sch->schib in that case to prevent subsequent code from making decisions based on unpredictable data. Reported-by: William Bezenah Signed-off-by: Vineeth Vijayan Reviewed-by: Peter Oberparleiter Fixes: 8c58a229688c ("s390/cio: Do not unregister the subchannel based on DNV") Signed-off-by: Heiko Carstens commit 4525a911049543c23885a540a788d13be318a486 Author: Karl Mehltretter Date: Mon Sep 7 07:58:47 2026 +0200 s390/pci/docs: Fix sriov_numvfs attribute name The attribute is sriov_numvfs (drivers/pci/iov.c); the document names it sriov_numvf, which does not exist. Use sriov_numvfs. Fixes: de267a7c71ba ("s390/pci: Documentation for zPCI") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Randy Dunlap Signed-off-by: Heiko Carstens commit 2f91fc9a96cdab6c03d436246056552e04677636 Author: Hemanth Selam Date: Mon Sep 7 12:08:56 2026 +0530 s390: Fix typos in comments Fix typos in comments, reported by scripts/checkpatch.pl using the misspelling list in scripts/spelling.txt. Only touches comments, no code changes. Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam Signed-off-by: Heiko Carstens commit c9151088f1674fd29ff26a20f5fc687acf53a2f0 Merge: dd56c0bc4836fa b4288c59bda883 Author: Jakub Kicinski Date: Wed Sep 16 19:18:26 2026 -0700 Merge branch 'net-psp-avoid-conflicts-with-skb-decrypted-and-sk_validate_xmit_skb' Daniel Zahka says: ==================== net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb() Sashiko's review of commit da630d1da2b1 ("netdevsim: psp: drop tx key ops") [1] showed that there is a hazard between PSP and offloaded TLS, where both can clobber what the other set in the sk_validate_xmit_skb callback. It was discussed further on the mailing list [2], and it was pointed out that there are conflicts with PSP and TLS ULP both using the skb->decrypted bit. The simplest fix is to make psp and tls mutually exclusive. This series goes a bit further and makes psp exclusive with all TCP ULPs. The PSP implementation that we have is not designed to be used with any TCP ULP, so don't allow a socket to have state for both. I will send a subsequent series to net-next which will remove the ability to perform the rx-assoc and tx-assoc psp netlink calls on sockets that are not in the TCP_ESTABLISHED state. This will close the remaining quirk that a sk_clone() on a listen socket with psp tx-assoc state will leave a stale sk->sk_validate_xmit_skb call back on a new, non-psp socket. I do not believe that change needs to be regarded as a fix, because it only stands to add unecessary validation code in the tx path. [1]: https://sashiko.dev/#/patchset/20260903-psp-prep-v1-0-d47e9c4c375d%40gmail.com [2]: https://lore.kernel.org/netdev/20260903-psp-prep-v1-0-d47e9c4c375d@gmail.com/ ==================== Link: https://patch.msgid.link/20260915-psp-ktls-fix-v2-0-0eedc3b148ec@gmail.com Signed-off-by: Jakub Kicinski commit b4288c59bda883b0e5cd95099dc3b0b7b7fc50f6 Author: Daniel Zahka Date: Tue Sep 15 16:11:38 2026 -0700 selftests: drv-net: psp: test PSP and TCP ULP mutual exclusion Test both setting PSP after TLS ULP, and TLS ULP after PSP. Add CONFIG_TLS=y to the drivers/net/config. Signed-off-by: Daniel Zahka Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260915-psp-ktls-fix-v2-2-0eedc3b148ec@gmail.com Signed-off-by: Jakub Kicinski commit a41f24c612c3f5139a3143307eb85bbcf1bd4d07 Author: Daniel Zahka Date: Tue Sep 15 16:11:37 2026 -0700 net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb() PSP conflicts with TLS ULP in its usage of both skb->decrypted and sk->sk_validate_xmit_skb(). Make PSP mutually exclusive with TLS ULP, the only other user of either of these. As other users of skb->decrypted come along, they can be added to sk_has_decrypt_user(). It would make sense to also assert that sk->sk_validate_xmit_skb() is also NULL in both of these setup paths for similar future proofing, but the PSP listener/sk_clone() path is still broken and it could be seen as a regression to not allow rx assoc to run on a child of a listener socket with PSP tx assoc state. Include all TCP ULPs in the sk_has_decrypt_user() check, even though TLS is the only one that conflicts with PSP via the decrypted bit. This is intentional because PSP was not designed to be used with ULPs. It is best to close off surface area that may make bugs reachable, until someone wishes to design and test an actual user of PSP with ULPs. Fixes: 6b46ca260e22 ("net: psp: add socket security association code") Signed-off-by: Daniel Zahka Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260915-psp-ktls-fix-v2-1-0eedc3b148ec@gmail.com Signed-off-by: Jakub Kicinski commit dd56c0bc4836fa705acb2f6a8a44af669d30fa3a Merge: c7ead9704249d5 02fffd1939f6b4 Author: Jakub Kicinski Date: Wed Sep 16 19:07:16 2026 -0700 Merge branch 'net-stmmac-restore-previous-state-if-tc_setup_dwmac510_mqprio-fails' Lorenzo Bianconi says: ==================== net: stmmac: restore previous state if tc_setup_dwmac510_mqprio() fails Restore previous mqprio qdisc configuration if tc_setup_dwmac510_mqprio() fails running the following configuration: $tc qdisc add dev eth0 root handle 1: mqprio queues 2@0 2@2 $tc qdisc replace dev eth0 root handle 2: mqprio queues 2@0 2@2 fp E P Propagate FPE preemption-class mapping errors in tc_setup_dwmac510_mqprio() and tc_taprio_configure(). ==================== Link: https://patch.msgid.link/20260911-stmmac-tc_setup_dwmac510_mqprio-error-path-v3-0-a76b1e2547c1@oss.qualcomm.com Signed-off-by: Jakub Kicinski commit 02fffd1939f6b45892f61822459953ce95e42948 Author: Lorenzo Bianconi Date: Fri Sep 11 10:58:30 2026 +0200 net: stmmac: preserve real_num_tx_queues on mqprio setup failure With the FPE preemption-class mapping error now propagated from stmmac_fpe_map_preemption_class(), tc_setup_dwmac510_mqprio() can fail on the mapping step. The error path used to call stmmac_reset_tc_mqprio(), which resets the number of real TX queues to priv->plat->tx_queues_to_use (the platform maximum), overwriting the value that was active before the offload was attempted (for example a lower count left over from a previous mqprio configuration). The issue can be triggered using the following configuration: # First mqprio config lowers the hw queue count below the platform # default (e.g. 8 TX queues). $tc qdisc add dev eth0 root handle 1: mqprio queues 2@0 2@2 # Replace mqprio configuration with a second one that fails FPE # preemption-class mapping. stmmac driver resets the real_num_tx_queues # to the platform maximum, losing the previous configuration. $tc qdisc replace dev eth0 root handle 2: mqprio queues 2@0 2@2 fp E P Save ndev->real_num_tx_queues before lowering it and restore it, together with the TC-to-queue and priority-to-TC mappings, when the FPE preemption-class mapping fails, instead of resetting the queue count to the platform maximum. Note that a failed setup makes the qdisc layer run mqprio_destroy() on the new qdisc. Because priv->hw_offload is only assigned after ndo_setup_tc() succeeds, mqprio_destroy() calls netdev_set_num_tc(dev, 0), so dev->num_tc ends up 0 regardless of the driver-side restore and the previous qdisc is not reactivated. The restore is still needed to keep real_num_tx_queues and to avoid leaving the failed configuration's TC-to-queue and priority-to-TC mappings in place. Fixes: 195e4f409a40 ("net: stmmac: support fp parameter of tc-mqprio") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260911-stmmac-tc_setup_dwmac510_mqprio-error-path-v3-2-a76b1e2547c1@oss.qualcomm.com Signed-off-by: Jakub Kicinski commit 90e4b849dfa6fc8e6c050bcfe1b331b69c015d28 Author: Lorenzo Bianconi Date: Fri Sep 11 10:58:29 2026 +0200 net: stmmac: propagate FPE preemption-class mapping errors stmmac_fpe_map_preemption_class() dispatches through the stmmac_do_void_callback() helper, which forces the callback's return value to 0 whenever the op pointer is populated. As a result the -EINVAL returned by dwmac5_fpe_map_preemption_class() (e.g. when a preemptible TC owns more than one TXQ under SP scheduling) is silently swallowed by every caller. Switch the dispatch macro to stmmac_do_callback() so the callback's real result is propagated, and honour it in the taprio and mqprio qdisc offload. Note that the taprio "if (ret)" check in tc_taprio_configure() used to be dead code and now becomes live: a preemptible TC spanning more than one TXQ under SP scheduling cannot be programmed in hardware, so a taprio or mqprio configuration that previously returned success while leaving the preemption-class register unprogrammed now fails with -EINVAL. For taprio, the failure also runs the disable path, tearing down the schedule that was just installed; this is the intended behaviour. Fixes: 195e4f409a40 ("net: stmmac: support fp parameter of tc-mqprio") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260911-stmmac-tc_setup_dwmac510_mqprio-error-path-v3-1-a76b1e2547c1@oss.qualcomm.com Signed-off-by: Jakub Kicinski commit c7ead9704249d57d4693a04697e3bbd285138fa9 Author: Guanglei Zhu Date: Fri Sep 11 10:17:34 2026 +0800 net: wwan: t7xx: validate the netif index in t7xx_ccmni_recv_skb() The netif index carried in the DPMAIF PIT header is five bits wide, but ccmni_inst[] only has room for NIC_DEV_MAX (21) entries. t7xx_ccmni_recv_skb() indexes the array without a bounds check, so indexes 21 to 31 read past it. The out-of-bounds value lands in the callback table that follows the array, which is never NULL, so the existing !ccmni check does not catch it and the driver dereferences whatever sits there as a struct t7xx_ccmni. Drop the skb when the index is out of range. Fixes: 05d19bf500f8 ("net: wwan: t7xx: Add WWAN network interface") Cc: stable@vger.kernel.org Signed-off-by: Guanglei Zhu Verified in a QEMU guest with a fault injector setting the netif index to 25: the unpatched driver reads a value past ccmni_inst[], which lands in the callback table, and dereferences it far enough to queue the skb. With this check the packet is dropped. Well-formed traffic on index 0 is unaffected. Changes in v2: none. Link: https://patch.msgid.link/20260911021734.1396599-3-zhugl3@xiaopeng.com Signed-off-by: Jakub Kicinski commit 31550d585589fde1ae95bf7f7a8188b2d2fdf1c7 Author: Guanglei Zhu Date: Fri Sep 11 10:17:33 2026 +0800 net: wwan: mhi_wwan_mbim: check skb_copy_bits() return value mhi_mbim_rx() ignores the return value of skb_copy_bits() when it copies each datagram out of the NTB. The datagram offset and length come from the DPE, which is only checked to lie within the NTB itself, so a modem can point a datagram outside the received skb. The copy then fails and the freshly allocated skbn is passed to netif_rx() with its uninitialized contents still in place, leaking kernel heap memory into the network stack. Free the skb and account an error when the copy fails. Fixes: aa730a9905b7 ("net: wwan: Add MHI MBIM network driver") Cc: stable@vger.kernel.org Suggested-by: Loic Poulain Signed-off-by: Guanglei Zhu Verified in a QEMU guest with a fault injector pointing a DPE outside the received NTB: the copy fails, and the unpatched driver hands the uninitialized skbn to the network stack (observed as "unknown protocol" on bytes that were never written). With this check the failed datagram is dropped and counted as an rx error. Changes in v2: factor the free-and-count sequence out into mhi_mbim_rx_drop(), shared with the unknown-protocol path, as suggested by Loic Poulain. Link: https://patch.msgid.link/20260911021734.1396599-2-zhugl3@xiaopeng.com Signed-off-by: Jakub Kicinski commit 5d063822ac5184939c1ed377a339a01d8ae814e8 Author: Guanglei Zhu Date: Fri Sep 11 10:17:32 2026 +0800 net: wwan: mhi_wwan_mbim: guard against a cyclic NDP chain The NDP traversal in mhi_mbim_rx() only stops when wNextNdpIndex is zero. Nothing requires the offsets to advance, so a modem that points an NDP at itself, or at an earlier NDP, keeps the loop spinning forever on one CPU. Break out when the next NDP offset is not larger than the current one. Fixes: aa730a9905b7 ("net: wwan: Add MHI MBIM network driver") Cc: stable@vger.kernel.org Suggested-by: Loic Poulain Signed-off-by: Guanglei Zhu Verified in a QEMU guest with a fault injector feeding the driver's receive callback an NTB whose single NDP points at itself: the unpatched driver spins in mhi_mbim_rx() with one CPU pinned at 100% and the thread never returns. With this check the loop terminates within one iteration. Changes in v2: move the non-increasing check to the wNextNdpIndex retrieval site, as suggested by Loic Poulain, instead of tracking the previous offset in a separate variable. Link: https://patch.msgid.link/20260911021734.1396599-1-zhugl3@xiaopeng.com Signed-off-by: Jakub Kicinski commit 42d1221d321e55afc7bba9109a77aaf5a817c8a3 Author: Bart Van Assche Date: Mon Aug 31 12:27:20 2026 -0700 scsi: megaraid_sas: Protect megasas_get_ctrl_info() in megasas_resume() Protect the megasas_get_ctrl_info() call in megasas_resume() with instance->reset_mutex using scoped_guard(). megasas_get_ctrl_info() may release and reacquire instance->reset_mutex. Hence, calling this function without holding instance->reset_mutex is not safe. Fixes: c3b10a55abc9 ("scsi: megaraid_sas: Update controller info during resume") Cc: Kashyap Desai Cc: Sumit Saxena Cc: Shivasharan S Cc: Chandrakanth patil Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/f06b5ee432b21cf293f0663e15b64f75a84b9fd5.1788204406.git.bvanassche@acm.org Signed-off-by: Martin K. Petersen (Oracle) commit 8f0ca55016a7647109ae2bc91bcb346fc8b13785 Author: Wentao Liang Date: Wed Sep 16 17:07:04 2026 +0000 watchdog: starfive-wdt: Fix runtime PM leak in starfive_wdt_pm_start() starfive_wdt_pm_start() takes a runtime PM reference with pm_runtime_get_sync(), which increments the usage counter even when it fails, and returns the error without dropping it again. The watchdog core does not invoke the stop callback when start fails, so the reference taken on the error path is leaked. Use pm_runtime_resume_and_get() instead, which keeps the usage counter balanced when the resume fails. Fixes: db728ea9c7be ("drivers: watchdog: Add StarFive Watchdog driver") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260916170704.2086331-1-vulab@iscas.ac.cn Signed-off-by: Guenter Roeck commit 1dd85662fee6e2ac580b1c4f9a0c0a7ae6e31f0e Author: Linus Walleij Date: Mon Sep 14 23:26:41 2026 +0200 net: ethernet: cortina: Ack RX overrun interrupt correctly The RX overrun interrupt is reported in interrupt status register 4, but gmac_irq() acknowledges it using the RX descriptor error bit from status register 0. For GMAC0 this writes the GMAC1 overrun bit, while for GMAC1 the shift leaves no bit in the 32-bit register. Acknowledge the same per-port RX overrun bit that was detected. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260914-b4-gemini-ethernet-fixes-2-v2-1-5ab39a047b90@kernel.org Signed-off-by: Jakub Kicinski commit 5071122bf5a628494db16d98d253f622a5aab074 Author: Li Jun Date: Mon Sep 14 14:23:53 2026 +0800 watchdog: da9062: fix suspend/resume handling of HW_RUNNING watchdog da9062_wdt_suspend() and da9062_wdt_resume() only check watchdog_active(), when the watchdog is left running by the driver sets WDOG_HW_RUNNING in da9062_wdt_probe() but userspace never opens the device, so WDOG_ACTIVE remains cleared, the wdt_disable() will not be executed in da9062_wdt_suspend. In this case, the suspend callback is a no-op and the watchdog keeps counting during system suspend, leading to an unexpected system reset. Check WDOG_HW_RUNNING and wdt->wdd，can fix this issue. Fixes: f6c98b08381c7 ("watchdog: da9062: add power management ops") Cs: stable@vger.kernel.org Signed-off-by: Li Jun Link: https://patch.msgid.link/20260914062353.582205-1-lijun01@kylinos.cn Signed-off-by: Guenter Roeck commit 22737cfced627ffcb4b5c36d63bb3d4476f63213 Author: Tzung-Bi Shih Date: Sun Sep 13 14:51:26 2026 +0800 watchdog: msc313e: Fix premature reset during timeout update Updating the 32-bit hardware timeout requires writing to two 16-bit registers sequentially. If the watchdog is actively running, this non-atomic update might trigger a premature system reset. Clear the watchdog counter before updating the registers to prevent the timer from timing out prematurely against an intermediate threshold. Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver") Cc: stable@vger.kernel.org Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260913065126.8350-1-tzungbi@kernel.org Signed-off-by: Guenter Roeck commit 1d9763f34a85680db1e8233d654fdb85e5f897cc Author: Tzung-Bi Shih Date: Sun Sep 13 00:33:34 2026 +0800 watchdog: msc313e: Propagate error code in resume() If msc313e_wdt_start() fails during system resume, the error is currently ignored. Consequently, the watchdog isn't running without the user's knowledge. Propagate the error code and print a message if msc313e_wdt_start() fails. Signed-off-by: Tzung-Bi Shih Fixes: e9800b7994642 ("watchdog: Add Mstar MSC313e WDT driver") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260912163334.28636-1-tzungbi@kernel.org Signed-off-by: Guenter Roeck commit 6274281c41efa8dd1aa5234c59ad904ff89d7af4 Author: Tzung-Bi Shih Date: Sun Sep 13 14:48:51 2026 +0800 watchdog: rzv2h: Avoid division by zero clk_get_rate() could return 0. Avoid a division by zero panic. Fixes: f6febd0a30b6 ("watchdog: Add Watchdog Timer driver for RZ/V2H(P)") Cc: stable@vger.kernel.org Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260913064851.8239-4-tzungbi@kernel.org Signed-off-by: Guenter Roeck commit 5af7d2cbd20f893def03c8310a460ade66a5d822 Author: Tzung-Bi Shih Date: Sun Sep 13 14:48:50 2026 +0800 watchdog: rtd119x: Avoid division by zero clk_get_rate() could return 0. Avoid a division by zero panic. Fixes: 2bdf6acbfead ("watchdog: Add Realtek RTD1295") Cc: stable@vger.kernel.org Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260913064851.8239-3-tzungbi@kernel.org Signed-off-by: Guenter Roeck commit 400cb663ca019bae6eb878f06f1094ddf7c0b0df Author: Tzung-Bi Shih Date: Sun Sep 13 14:48:49 2026 +0800 watchdog: digicolor: Avoid division by zero clk_get_rate() could return 0. Avoid a division by zero panic. Since get_timeleft() cannot propagate errors, check the clock rate early in probe() and cache the rate in the driver data as it is unlikely to change at runtime. Fixes: 336694a01dae ("watchdog: digicolor: driver for Conexant Digicolor CX92755 SoC") Cc: stable@vger.kernel.org Signed-off-by: Tzung-Bi Shih Acked-by: Baruch Siach Link: https://patch.msgid.link/20260913064851.8239-2-tzungbi@kernel.org Signed-off-by: Guenter Roeck commit 9ed55f3dbef4f4adfe65eb03b0c35c53229a8490 Author: Eric Dumazet Date: Tue Sep 15 04:30:54 2026 +0000 net: lock the socket in sock_gettstamp() sk->sk_flags must only be changed while holding the socket lock, because sock_set_flag() and sock_reset_flag() use non atomic operations (__set_bit() and __clear_bit()). sock_gettstamp() is one of the last places where a bit of sk->sk_flags is changed from a syscall without owning the socket lock, through sock_enable_timestamp(sk, SOCK_TIMESTAMP). sk_set_memalloc() and sk_clear_memalloc() also change sk->sk_flags without the socket lock, but their callers (nbd, iscsi_tcp, nvme-tcp, sunrpc, wireguard) need a careful audit, this will be addressed in a separate patch. Jungwoo Lee and Wongi Lee reported an UDP socket use-after-free caused by this bug: a SIOCGSTAMPNS_NEW ioctl racing with bind() can cancel the SOCK_RCU_FREE bit that udp_lib_get_port() just set, because both threads perform a read-modify-write on the same word. CPU 0 (bind) CPU 1 (SIOCGSTAMPNS_NEW) -------------------------------- ---------------------------- read sk_flags = F read sk_flags = F compute F | BIT(SOCK_RCU_FREE) compute F | BIT(SOCK_TIMESTAMP) store F | BIT(SOCK_RCU_FREE) sk_add_node_rcu(sk, ...) store F | BIT(SOCK_TIMESTAMP) After the lost update, SOCK_RCU_FREE is clear while the socket is visible to lockless UDP receive lookups. sk_destruct() then frees the socket immediately instead of waiting for a RCU grace period, while the receive path still holds a reference-less pointer to it: BUG: KASAN: slab-use-after-free in ipv4_pktinfo_prepare+0x30/0x410 Read of size 8 at addr ffff888008806610 by task exploit/207 CPU: 0 UID: 1000 PID: 207 Comm: exploit Not tainted 6.12.95+ #1 ipv4_pktinfo_prepare+0x30/0x410 udp_queue_rcv_one_skb+0x51c/0x1180 udp_unicast_rcv_skb+0x109/0x350 ip_protocol_deliver_rcu+0x14b/0x310 ip_local_deliver_finish+0x29d/0x390 ip_local_deliver+0x24d/0x2a0 Only grab the socket lock when SOCK_TIMESTAMP has to be set, to keep the common case lockless. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Jungwoo Lee Reported-by: Wongi Lee Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260915043055.3441600-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit 490599ab23134962a6d18a024e84541d77bdb999 Author: Jakub Kicinski Date: Mon Sep 14 19:23:27 2026 -0700 eth: fbnic: ring the doorbell if a burst ends in a drop fbnic_tx_map() skips the doorbell write, and the completion request, for every packet handed to it with xmit_more set, counting on the packet which ends the burst to publish them all. When that packet is dropped instead - skb_put_padto(), skb_cow_head() or a DMA mapping failure - nothing rings. The descriptors of the preceding packets stay invisible to the HW until the next transmit on that queue, which for a burst-then-idle workload may never come. Remember the meta descriptor of the last packet left without a doorbell and flush it from the error paths. The completion request has to be set on that descriptor rather than simply writing the tail, otherwise the HW would transmit the packets but never report a head, and the ring would fill up and stall for good. This is very similar to Joe's recent series of fixes for bnxt. Not seen in real life, reproduced under QEMU with failure injection. Fixes: 9a57bacd574b ("eth: fbnic: Add basic Tx handling") Reviewed-by: Alexander Duyck Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260915022327.913218-1-kuba@kernel.org Signed-off-by: Jakub Kicinski commit 5ae916fabca141b79b32e2e57f3c915c0f1e1b2e Author: Yige Jiang Date: Sun Sep 13 14:41:02 2026 +0800 net: netsec: fix device_node reference leak on phy_np netsec_of_probe() takes a reference on the PHY device_node with of_parse_phandle() and stores it in priv->phy_np, but the driver never drops it. One device_node reference is leaked per probe, on the success path as well as on every error path reached after netsec_of_probe(). Neither consumer takes ownership. of_mdio_parse_addr() is a static inline taking a const struct device_node * that only reads the "reg" property. of_phy_connect() borrows as well: of_phy_get_and_connect() in drivers/net/mdio/of_mdio.c brackets its own call with of_node_get() at :364 and of_node_put() at :373, which would be a double put if of_phy_connect() consumed the reference. The node is still in use at netsec_netdev_open() time, where it is passed to of_phy_connect(), so it has device lifetime. Release it at the probe error label, which every failure path after the acquire funnels through, and in netsec_remove(). Both releases precede free_netdev(), since priv is netdev_priv(ndev). The ACPI probe path leaves priv->phy_np NULL and of_node_put(NULL) is a no-op. There is no end-user visible symptom on currently supported platforms: a device_node is only freed once OF_DYNAMIC is enabled and the node has been detached, so on a static device tree the imbalance is inert. It is observable as a refcount that grows across bind/unbind cycles, and would matter under device tree overlays. Found by static analysis of reference acquire/release pairing rather than from a runtime report. No reproducer was produced and the change has not been runtime tested; it is compile-tested only (arm64, CONFIG_SNI_NETSEC=m via COMPILE_TEST). Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") Signed-off-by: Yige Jiang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260913064102.37452-1-yigejiang86@gmail.com Signed-off-by: Jakub Kicinski commit 150dba2c69e93302af24a0c868eebe4871e2e107 Author: Farhad Alemi Date: Sat Sep 12 07:40:09 2026 +0000 net: remove WARN_ON_ONCE() from the dev_fill_forward_path() loop check ipip_fill_forward_path() and ip6_tnl_fill_forward_path() look up the route to the tunnel's remote endpoint and set ctx->dev to its device, which is the tunnel itself when that route resolves back to the tunnel. dev_fill_forward_path() then makes no progress and trips WARN_ON_ONCE(last_dev == ctx->dev) as soon as a flowtable tries to offload a flow through the tunnel. That routing loop is a configuration any CAP_NET_ADMIN user can set up, and ip_tunnel_xmit() and ip6_tnl_xmit() already treat it as a tx error, so remove the warning and just fail the walk, as commit 008e7a7c293b ("net: remove WARN_ON_ONCE when accessing forward path array") did for the path stack overflow. Fixes: ab427db17885 ("netfilter: flowtable: Add IPIP rx sw acceleration") Fixes: d98103575dcd ("netfilter: flowtable: Add IP6IP6 rx sw acceleration") Closes: https://lore.kernel.org/all/CA+0ovCgaRvbd0Udj70b2xxG8Cx3CaCpNhnf1V4RWQuDveZYZhA@mail.gmail.com/ Suggested-by: Pablo Neira Ayuso Signed-off-by: Farhad Alemi Reviewed-by: Xuanqiang Luo Link: https://patch.msgid.link/CA+0ovCgKDOk+Bg6Gh5Lwx94u_jJjQ30-vY1JcY2BYfhnWJJbPA@mail.gmail.com Signed-off-by: Jakub Kicinski commit 37213e61120297920ae4c937fcb326a360da5084 Author: Mark Amirkan Date: Sun Sep 13 10:31:08 2026 +0000 net/packet: avoid truncating TPACKET_V3 private size tpacket_req3.tp_sizeof_priv is an unsigned int, and packet_set_ring() validates the full value against the block size. init_prb_bdqc() then stores it in the unsigned short blk_sizeof_priv field. Commit 2b6867c2ce76 ("net/packet: fix overflow in check for priv area size") fixed the validation arithmetic, but an accepted value above USHRT_MAX still narrows when it is stored. For a 131072-byte block, tp_sizeof_priv=65536 is valid. The narrowing makes offset_to_first_pkt 48 instead of 65584, so packet records can be placed in the private area that userspace asked the kernel to preserve. blk_sizeof_priv is internal state, so widen it to hold the validated UAPI value. Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.") Cc: stable@vger.kernel.org Signed-off-by: Mark Amirkan Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260913-b4-send-packet-private-v1-1-925eab2cd388@gmail.com Signed-off-by: Jakub Kicinski commit 60404266ef3e0a1cd8f7a164060e0c83efb72f4b Author: Mark Amirkan Date: Sun Sep 13 10:30:05 2026 +0000 mptcp: return sk_wait_data() errors from recvmsg() Commit 581302298524 ("mptcp: error out earlier on disconnect") made mptcp_recvmsg() stop when sk_wait_data() returns an error. The error is stored in err, but the function then jumps to a path which returns copied. When no data was copied, recvmsg() therefore returns zero and reports a false EOF. Store the result in copied, which is the value returned by the function. This also keeps the usual partial-read result when data was copied before the error. A recvmsg() blocked in one thread reproduces the issue when another thread disconnects the same MPTCP socket with connect(AF_UNSPEC). Before this change recvmsg() returns zero; afterwards it returns -EPIPE. Fixes: 581302298524 ("mptcp: error out earlier on disconnect") Cc: stable@vger.kernel.org Signed-off-by: Mark Amirkan Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260913-b4-send-mptcp-recv-error-v1-1-4eaa3684a8b8@gmail.com Signed-off-by: Jakub Kicinski commit 33ff111d7ba3beb86e28938d6382bb5beabd865a Author: Mark Amirkan Date: Sun Sep 13 10:28:08 2026 +0000 net/packet: clear RX owner on VNET header error Commit 61fad6816fc1 ("net/packet: tpacket_rcv: avoid a producer race condition") added rx_owner_map and made tpacket_rcv() claim a V1 or V2 ring slot before converting the virtio-net header. If the conversion fails, the drop path leaves the slot claimed. With a one-frame TPACKET_V2 ring, an unsupported UDP GSO packet leaves the only slot unavailable, so the ring also drops the next valid packet. Clear the ownership bit on this error path. TPACKET_V3 already clears its block state here. Fixes: 61fad6816fc1 ("net/packet: tpacket_rcv: avoid a producer race condition") Cc: stable@vger.kernel.org Signed-off-by: Mark Amirkan Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260913-b4-send-packet-vnet-v1-1-5545ffb528ae@gmail.com Signed-off-by: Jakub Kicinski commit a9ce4053dc945c5372dedba5017ee675b30dc0c5 Author: Mark Amirkan Date: Sun Sep 13 17:14:09 2026 -0700 net: lan743x: fix RX checksum use-after-free lan743x_rx_process_buffer() adds each non-first receive buffer to the head skb's frag_list. On the last descriptor, lan743x_rx_trim_skb() linearizes the head and frees the fragment skb metadata. The checksum-success path then writes ip_summed through the local skb pointer, which still points to the final fragment. This causes a use-after-free write when a packet spans more than one receive buffer. Set ip_summed on the surviving head skb instead. Multi-buffer receive can occur after a live MTU increase because existing ring entries keep their old buffer size until they are replenished. A KUnit test invoking lan743x_rx_process_buffer() with a two-buffer packet produced a one-byte KASAN use-after-free write before this change. The same test passed after the change. The driver object also builds with W=1. This was not tested on physical LAN743x hardware. Fixes: cd6910501cfd ("net: lan743x: Add support for Rx IP & TCP checksum offload") Cc: stable@vger.kernel.org Signed-off-by: Mark Amirkan Reviewed-by: Chenguang Zhao Link: https://patch.msgid.link/20260913-b4-send-lan743x-uaf-v1-1-73d563d08ba9@gmail.com Signed-off-by: Jakub Kicinski commit 88f113634028ca90a857031837d8061d1a9e1a7b Author: Wentao Liang Date: Wed Sep 16 17:05:11 2026 +0000 watchdog: sp5100_tco: Fix pci_dev reference leak in sp5100_tco_init() sp5100_tco_init() stores the PCI device matched by for_each_pci_dev() in the global sp5100_tco_pci and keeps its reference for the lifetime of the driver, but neither sp5100_tco_exit() nor the error paths of sp5100_tco_init() call pci_dev_put(), leaking the reference on driver registration failure and on every module load/unload cycle. Drop the reference when the platform driver or device registration fails and when the module is unloaded. Fixes: 15e28bf13008 ("watchdog: Add support for sp5100 chipset TCO") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260916170511.2086199-1-vulab@iscas.ac.cn Signed-off-by: Guenter Roeck commit f6fb2ac5e19ae4b66112a698050db80e51f841c3 Author: Jamal Hadi Salim Date: Sat Sep 12 14:08:31 2026 -0400 selftests/tc-testing: add codel/fq_codel interval boundary cases Add tdc cases locking the codel/fq_codel small-interval uAPI after the dropping-loop bound (previous patch): sub-tick and two-tick intervals are ACCEPTED (the loop bound makes them safe), the 1024us boundary is accepted, and a sub-tick target sojourn delay is accepted (it does not participate in the control law): codel: 6e44/a8c3/a695/9793 - interval 1us/3us/1024us and target 1us accepted (rendered 0us/2us/1.02ms/0us by tc) fq_codel: 1b4d/3540/49c5/3e0f - interval 1us/3us/1024us and target 1us accepted The positive cases match the full rendered qdisc line (tc renders interval 1us as 0us, 3us as 2us, 1024us as 1.02ms), mirroring the existing tests in these files. These cases do not test the dropping-loop bound itself: tdc cannot observe per-dequeue drop counts. c797 (fq_codel target 1 interval 1) passes unmodified on the patched kernel, which is the uAPI evidence for the previous patch. Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-1L5H.v1.20260912080102@mojatatu.com.2 Signed-off-by: Jakub Kicinski commit 7f4a5ec6258fd7c92633ec4b0493fc51166d9398 Author: Jamal Hadi Salim Date: Sat Sep 12 14:08:30 2026 -0400 net/sched: codel: bound the dropping loop per dequeue call The CoDel control law schedules the next drop one interval/sqrt(count) after the previous drop, using the configured interval (codel_params.interval). For very small intervals the scheduled step rounds down to zero, so the dropping loop in codel_dequeue() never advances and drains the entire backlog under the qdisc lock in one call - an unprivileged user can trigger a soft lockup this way. Fix in the shared codel code used by both codel and fq_codel: 1. Make the control-law step at least 1 tick so the dropping loop always moves forward. 2. Cap the dropping loop at CODEL_MAX_DROPS_PER_DEQUEUE (256) drops per codel_dequeue() call, resyncing drop_next to now when the cap is hit: the catch-up owed to the loop grows with the idle gap and the backlog, which no interval threshold can bound. This is a deliberate behaviour change after long idle gaps. The cap applies to fq_codel (4b549a2ef4be) and the mac80211 TXQ path (fixed interval, cap only). The target sojourn delay (codel_params.target) is not validated: it does not feed the control law, so a sub-tick value is aggressive rather than deadlock-prone. Conditions to recreate the bug: - tc qdisc add dev lo root handle 1: tbf rate 1kbit burst 2kb limit 1000000 - tc qdisc add dev lo parent 1:1 handle 10: codel interval 2us target 1ms noecn limit 1000000 (same for fq_codel) - unpatched kernel: tc accepts it; a UDP flood under the 1kbit tbf soft-lockups (watchdog: BUG: soft lockup) while one codel_dequeue() call drops the backlog under the qdisc lock - patched kernel: same setup, at most 256 drops per dequeue call, no soft lockup Testing: claim reproducer and interval 2us/3us variants run clean; tdc qdisc category passes (see the selftests patch). Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Reported-by: Vega Reviewed-by: Eric Dumazet Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/QDISC-1L5H.v1.20260912080102@mojatatu.com Signed-off-by: Jakub Kicinski commit 92b68492eae701e5b0e9d142ffe229921af7b1fa Author: James Seo Date: Wed Sep 16 15:19:15 2026 -0700 hwmon: (hp-wmi-sensors) Improve raw WMI string handling Commit c9ba59258094 ("hwmon: (hp-wmi-sensors) Fix failure to load on EliteDesk 800 G6") left out some logic for recognizing raw WMI strings in check_numeric_sensor_wobj(). This issue was reported by a user along with an incomplete and unsuitable proposed solution [1]. Add the missing logic and properly remedy the issue. Also slightly refactor how raw WMI strings are recognized elsewhere to make the intent that they should be treated as regular ACPI strings clearer. Reported-by: Muhammad Bilal Link: https://lore.kernel.org/linux-hwmon/20260916002907.161210-1-meatuni001@gmail.com/ [1] Fixes: c9ba59258094 ("hwmon: (hp-wmi-sensors) Fix failure to load on EliteDesk 800 G6") Signed-off-by: James Seo Link: https://patch.msgid.link/20260916221912.434119-5-james@equiv.tech Signed-off-by: Guenter Roeck commit 089070b51ccbac411462a30a454690274c6e4270 Author: Sanman Pradhan Date: Wed Sep 16 23:54:17 2026 +0000 hwmon: (pmbus/tps53679) Select page 0 for single-page TPS53676 tps53676_identify() derives the number of PMBus pages but does not ensure that page 0 is selected for single-page configurations. pmbus_set_page() does not update the PAGE register when info->pages is 1, so if boot firmware leaves PAGE set to another value subsequent register accesses may target the wrong page. For single-page devices, select page 0 explicitly. Fixes: cb3d37b59012 ("hwmon: (pmbus/tps53679) Add support for TI TPS53676") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://patch.msgid.link/20260916235406.681131-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck commit fefaac1176bf3cf002a8dc83339d6ed6a369941a Merge: 7c7d5e9d7e3942 1eeca1d5e0920f Author: Jakub Kicinski Date: Wed Sep 16 15:54:55 2026 -0700 Merge tag 'wireless-2026-09-16' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Many fixes: - mac80211: S1G TIM bitmap fix - ath12k: remove undocumented DT ABI implementation - various firmware API and over-the-air hardening changes - fixes for most cfg80211/mac80211 syzbot reports * tag 'wireless-2026-09-16' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (67 commits) wifi: brcmsmac: fix UAF in brcms_free_timer() wifi: brcmfmac: fix lost 802.1x TX completion wakeup wifi: ath11k: cleanup arsta in ath11k_mac_peer_cleanup_all() wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardown wifi: ath12k: ahb: Revert undocumented ABI and dead code wifi: mac80211: refuse to make a monitor active when it has no queue wifi: libipw: reject TKIP frames without a full MIC wifi: virt_wifi: don't transfer operstate before register wifi: cfg80211: check if AP has been started or joined a mesh before adding new station wifi: cfg80211: move link_id validation earlier in nl80211_new_station() wifi: cfg80211: do not support direct add of station to AP_VLAN interfaces wifi: cfg80211: verify if AP_VLAN belongs to the correct AP wifi: mac80211: set up the TX info early to fix failure paths wifi: mac80211: mesh: release the channel if start fails wifi: mac80211: mesh: reset the CSA state when leaving wifi: mac80211: add HE 6 GHz capability in the scan elems len wifi: mac80211: don't access the TSF of a down interface wifi: mac80211: don't RCU-dereference the mesh CSA settings we just set wifi: mac80211: don't allow link changes when iface is down wifi: mac80211: require a peer station for TDLS setup confirm ... ==================== Link: https://patch.msgid.link/20260916083642.110609-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski commit 7c7d5e9d7e3942ba5aec9847f61a6e76d7773191 Merge: ceac0de741bfb4 96f01b53c2d05e Author: Jakub Kicinski Date: Wed Sep 16 15:54:18 2026 -0700 Merge tag 'ipsec-2026-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2026-09-16 1) xfrm: iptfs: fix stack OOB read in iptfs_skb_reset_frag_walk() Add the up-front nr_frags guard iptfs_skb_add_frags() already has, so an out-of-range offset can't walk past the on-stack frags[] array. 2) xfrm: serialize state GC with device state flush Serialize xfrm_state destruction against the deferred-device pass with a dedicated mutex, since the device GC list doesn't hold a state reference and the two paths could free the same state. 3) xfrm: add missing RCU read lock in xfrm_send_migrate_state() Hold the RCU read lock around xfrm_nlmsg_multicast() so the rcu_dereference() of net->xfrm.nlsk doesn't warn. 4) xfrm: iptfs: fix runt reassembly panic from short inner tot_len Require the runt length to cover at least the minimum IP header, so a tot_len in [6, 19] (IPv4) can't write past the declared length and trip skb_over_panic(). 5) ipv6: xfrm: use full sockets in local error paths Use skb_to_full_sk() in xfrm6_local_rxpmtu() and xfrm6_local_error() and bail out without a full socket, so a TCP_NEW_SYN_RECV request_sock isn't miscast as a full inet/IPv6 socket. 6) xfrm: fix compat ALLOCSPI request use-after-free Drop the redundant alloc_compat() in xfrm_alloc_userspi() so the compat translator no longer reads past the payload and publishes a child a multicast clone can still see after xfrm_user_rcv_msg() frees. 7) xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for xfrm_trans_reinject() Force the dst before queuing, hold dev across the workqueue deferral, and take rcu_read_lock() around the finish() loop, so transport-mode reinjection doesn't deref non-refcounted dst/dev under workqueue. 8) xfrm: use hlist_del_init_rcu for state_cache and state_cache_input Switch to hlist_del_init_rcu() so a second __xfrm_state_delete() is a no-op instead of writing through LIST_POISON2, closing the UAFs. 9) esp: downgrade zerocopy managed frags before mutating skb frags Call skb_zcopy_downgrade_managed() before ESP rewrites the skb frag array, so per-frag unrefs in esp_ssg_unref() and skb_release_data() stay balanced for ubuf-owned managed frags. 10) xfrm: hold net_device reference under RCU in bundle creation Read dst->dev via dst_dev_rcu() and keep RCU active through xfrm_fill_dst(), so a concurrent RTM_DELLINK can't free dev under bundle creation. 11) xfrm: save input state data before secpath resets Save the state protocol on the stack while it's still valid and use the saved address family for transport_finish(), so post-reset dereferences (VTI, XFRM if, MAX_DEPTH error) can't UAF the state. 12) net: xfrm: reject unrepresentable espintcp transport headers Use the careful transport-header helper and drop the skb through the XFRM error path when the offset can't be represented, instead of silently truncating it. * tag 'ipsec-2026-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec: net: xfrm: reject unrepresentable espintcp transport headers xfrm: save input state data before secpath resets xfrm: hold net_device reference under RCU in bundle creation esp: downgrade zerocopy managed frags before mutating skb frags xfrm: use hlist_del_init_rcu for state_cache and state_cache_input xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for xfrm_trans_reinject() xfrm: fix compat ALLOCSPI request use-after-free ipv6: xfrm: use full sockets in local error paths xfrm: iptfs: fix runt reassembly panic from short inner tot_len xfrm: add missing RCU read lock in xfrm_send_migrate_state() xfrm: serialize state GC with device state flush xfrm: iptfs: fix stack OOB read in iptfs_skb_reset_frag_walk() ==================== Link: https://patch.msgid.link/20260916101938.118628-1-steffen.klassert@secunet.com Signed-off-by: Jakub Kicinski commit c774ec8f0a5d02a06d34c27f5a7de7e333b91265 Author: Eva Kurchatova Date: Wed Sep 16 23:44:31 2026 +0300 selftests: cgroup: give the O_TMPFILE open in get_temp_fd() a mode O_TMPFILE, like O_CREAT, needs the third argument. Without it glibc refuses the call at compile time as soon as fortification is on: In function 'open', inlined from 'get_temp_fd' at test_memcontrol.c:33:9: /usr/include/bits/fcntl2.h:52:11: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT or O_TMPFILE in second argument needs 3 arguments The fortify checks take effect only once the compiler optimises, and cgroup/Makefile builds with "-Wall -pthread" alone, so this goes unnoticed in a plain build. Building the tests with the flags distributions commonly use, -O2 -D_FORTIFY_SOURCE=3, loses test_memcontrol entirely. Fixes: 84092dbcf901 ("selftests: cgroup: add memory controller self-tests") Signed-off-by: Eva Kurchatova Signed-off-by: Tejun Heo commit 940e8fe8535d22ce67dd2fb9588e6c55a31d7d03 Merge: fa899ba9b1bfa0 76a8fe25b97881 Author: Mark Brown Date: Wed Sep 16 20:09:57 2026 +0100 ASoC: adau1977: small fixes to make the driver more usable Alvin Šipraga says: Here's a few fixes I encountered were needed in order to use this driver as a module together with the simple audio card. Link: https://patch.msgid.link/20260914-asoc-adau1977-fixes-v1-0-aa2f0cabd728@analog.com commit 76a8fe25b97881223976363044924d5cf0511749 Author: Alvin Šipraga Date: Mon Sep 14 12:12:37 2026 +0200 ASoC: adau1977-i2c: add OF match table for I2C Like for SPI, the I2C driver needs an OF match table for the kernel to be able to automatically load the driver when built as a module. Add one. Signed-off-by: Alvin Šipraga Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20260914-asoc-adau1977-fixes-v1-3-aa2f0cabd728@analog.com Signed-off-by: Mark Brown commit 528a0da3e55b24d1113b3658e94cf432e0020913 Author: Alvin Šipraga Date: Mon Sep 14 12:12:36 2026 +0200 ASoC: adau1977-spi: drop __maybe_unused and of_match_ptr() Since commit 5ab23c7923a1 ("modpost: Create modalias for builtin modules") MODULE_DEVICE_TABLE() is enough to reference a match table and the data isn't discarded by the linker even when the driver is built-in and CONFIG_OF is disabled. Drop the of_match_ptr() wrapping so that OF matching keeps working regardless of CONFIG_OF. This also means we can drop __maybe_unused since it's always used. The entries in adau1977_spi_of_match were also erroneously indented with spaces - replace the indentation with tabs to conform with coding style. Signed-off-by: Alvin Šipraga Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20260914-asoc-adau1977-fixes-v1-2-aa2f0cabd728@analog.com Signed-off-by: Mark Brown commit 0030f62683d5061d43b80577b7ab27196f1adb4c Author: Alvin Šipraga Date: Mon Sep 14 12:12:35 2026 +0200 ASoC: adau1977: make the Kconfig symbols user selectable SND_SOC_ADAU1977_{SPI,I2C} are missing Kconfig text, so they don't show up in menuconfig and can't be selected by a user - only by another symbol such as a machine driver. Add the text to make these symbols selectable and usable with generic machine drivers like the simple audio card. Signed-off-by: Alvin Šipraga Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20260914-asoc-adau1977-fixes-v1-1-aa2f0cabd728@analog.com Signed-off-by: Mark Brown commit fa899ba9b1bfa0481a477c7a05a1a5d484285e7f Merge: 3482062c786ce4 d57616f8be5601 Author: Mark Brown Date: Wed Sep 16 20:08:20 2026 +0100 ASoC: amd: acp: SoundWire machine driver fixes Vijendar Mukunda says: This series fixes four defects in the AMD ACP SoundWire machine drivers (acp-sdw-legacy-mach.c and acp-sdw-sof-mach.c). A bounds check is added to validate the SoundWire link ID before it is used as an array index in create_sdw_dailink(), preventing out-of-bounds access when an unexpected link_mask value is encountered. The codec config count in the SOF machine driver is refactored to use a dedicated variable rather than reusing the endpoint-count variable for two purposes, making the intent clearer and avoiding a stale value being passed to the codec config array. An operator-precedence bug in the ffs(link_mask - 1) expression is corrected to ffs(link_mask) - 1, ensuring the link ID is derived from the correct bit position. Finally, the SOF machine driver card name is shortened to fit within the 16-byte snd_card driver[] field and eliminate a compile-time warning. Link: https://patch.msgid.link/20260910161728.1452808-1-Vijendar.Mukunda@amd.com commit d57616f8be5601d210bbb0f677b9cb88a5186c3c Author: Vijendar Mukunda Date: Thu Sep 10 21:46:49 2026 +0530 ASoC: amd: acp: fix card name length warning in SOF SoundWire machine driver The ALSA snd_card driver[] field is 16 bytes (including the NUL terminator), leaving 15 usable characters. The SOF framework prepends a "sof-" prefix when registering the card, so card->name = "amd-soundwire" becomes driver name "sof-amd-soundwire" which is 17 characters and overflows the driver[16] buffer, triggering a kernel warning. Fix by shortening the card name to "amd-sdw"; the resulting driver name "sof-amd-sdw" fits within the 15-character limit. Signed-off-by: Vijendar Mukunda Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260910161728.1452808-5-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown commit 27098aaf28b96ab4e6891709062c343566d4882b Author: Vijendar Mukunda Date: Thu Sep 10 21:46:48 2026 +0530 ASoC: amd: acp: fix ffs() operator precedence for SoundWire link ID ffs(link_mask - 1) computes ffs on (link_mask - 1) instead of subtracting 1 from the result of ffs(link_mask). For a typical power-of-2 link_mask this returns the wrong link ID, causing cpu_pin_id lookup to select the incorrect SoundWire manager. Fix the operator precedence to ffs(link_mask) - 1 in both acp-sdw-sof-mach.c and acp-sdw-legacy-mach.c. Fixes: 6d8348ddc56e ("ASoC: amd: acp: refactor SoundWire machine driver code") Signed-off-by: Vijendar Mukunda Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260910161728.1452808-4-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown commit 0b7d55d3a91200f2b1ed710f525a944b0a7d6369 Author: Vijendar Mukunda Date: Thu Sep 10 21:46:47 2026 +0530 ASoC: amd: acp: refactor codec config count in SOF SoundWire machine driver num_devs was used both as the endpoint count and as the output for asoc_sdw_parse_sdw_endpoints(), which overwrites it with the codec configuration count. Introduce a separate num_confs variable to hold the codec conf count so the two values remain distinct across codec_conf allocation and card->num_configs assignment. Fixes: 6d8348ddc56e ("ASoC: amd: acp: refactor SoundWire machine driver code") Signed-off-by: Vijendar Mukunda Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260910161728.1452808-3-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown commit 29218a4d11a31a8157389bc2b9e62dd768d7ea42 Author: Vijendar Mukunda Date: Thu Sep 10 21:46:46 2026 +0530 ASoC: amd: acp: bounds-check SoundWire link ID in machine drivers Add a bounds check in create_sdw_dailink() to validate that the SoundWire link ID derived from link_mask does not exceed the maximum supported by the platform. If the link ID is out of range or link_mask is zero, log an error and return -EINVAL to prevent accessing invalid CPU pin ID tables. Applied to both acp-sdw-sof-mach.c and acp-sdw-legacy-mach.c. Fixes: 6d8348ddc56e ("ASoC: amd: acp: refactor SoundWire machine driver code") Signed-off-by: Vijendar Mukunda Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260910161728.1452808-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown commit 3482062c786ce4233f8ed3224d824184f53ec154 Author: Richard Fitzgerald Date: Mon Sep 14 13:26:11 2026 +0100 ASoC: cs-amp-lib: Prevent NULL pointer if efi variable is zero length In cs_amp_alloc_get_efi_variable() the first call to cs_amp_get_efi_variable() might return EFI_SUCCESS if the variable exists with zero length. Trap this and return -ENOENT to prevent returning an unexpected NULL pointer. The first cs_amp_get_efi_variable() call was assumed to return EFI_BUFFER_TOO_SMALL if the variable existed, but if instead it returned EFI_SUCCESS this would be converted to 0 by cs_amp_convert_efi_status() and then be returned as a NULL pointer. Fixes: 00fd40bc7acec ("ASoC: cs-amp-lib: Support Dell SSIDExV2 UEFI variable") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260914122611.2783563-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit 03a5699a0a04309c597683967aaaf25d1e555ea2 Author: Jiangshan Yi Date: Mon Sep 14 18:47:12 2026 +0800 ASoC: codecs: rt712-sdca-dmic: fix uninitialized stream_config->type stream_config is not initialized before being passed to sdw_stream_add_slave(). The type field may contain garbage and is later copied to stream->type by sdw_config_stream(). Zero-initialize stream_config so type defaults to SDW_STREAM_PCM. While at it, use snd_sdw_params_to_config() helper instead of open-coding the same logic. Fixes: 63a511284c9e ("ASoC: rt712-sdca: Add RT712 SDCA driver for Mic topology") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260914104712.379574-1-yijiangshan@kylinos.cn Signed-off-by: Mark Brown commit c17ae8c26eac16ad244daef44044d714f68a2ddc Author: HyeongJun An Date: Tue Sep 15 18:25:15 2026 +0900 ASoC: hdmi-codec: Report a change when the channel status moves The put() callback of "IEC958 Playback Default" stores all 24 channel status bytes and then returns 0. The core notifies userspace only on a positive return, so a write that changes what the get() callback hands back is never announced, and a mixer holding the control open keeps showing the old value. Compare the stored bytes and return 1 when they move, the way snd_hda_spdif_default_put() does. The same shape is in img-spdif-out and uniperif_player. No board with this codec was to hand. The change is a comparison of driver state with no hardware behaviour in it, and mixer-test counts the missing notification as event_missing. Fixes: 7a8e1d44211e ("ASoC: hdmi-codec: Add iec958 controls") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-5 Link: https://patch.msgid.link/20260915092515.2638542-1-sammiee5311@gmail.com Signed-off-by: Mark Brown commit 11fc0048a6930f4fca44fe3bd16a0023e78846a2 Author: Sasha Levin Date: Sun Sep 13 13:31:32 2026 -0400 ASoC: ux500: Parenthesize MSP_{RX,TX}_CLKPOL_BIT() arguments arm allmodconfig fails to build with gcc: In file included from sound/soc/ux500/ux500_msp_i2s.c:20: sound/soc/ux500/ux500_msp_i2s.h:151:38: error: suggest parentheses around arithmetic in operand of '^' [-Werror=parentheses] sound/soc/ux500/ux500_msp_i2s.c:204:21: note: in expansion of macro 'MSP_TX_CLKPOL_BIT' cc1: all warnings being treated as errors The macros never parenthesized their argument: #define MSP_TX_CLKPOL_BIT(n) ((n & TCKPOL_MASK) << TCKPOL_SHIFT) That went unnoticed while every caller passed a plain variable, but configure_protocol() now passes an XOR expression, which binds as "a ^ (b & MASK)" rather than "(a ^ b) & MASK", and gcc rightly complains. No functional change: tx_clk_pol and rx_clk_pol only ever hold MSP_FALLING_EDGE (0) or MSP_RISING_EDGE (1), and bclk_inverted is a bool, so masking before or after the XOR gives the same 0/1 result. Parenthesize the argument anyway - it fixes the build and stops the macros from silently mis-evaluating a future composite argument. Fixes: 9ccbacf5a012 ("ASoC: ux500: Validate MSP DAI configuration") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609051547.G9SJp8UQ-lkp@intel.com/ Assisted-by: LLM Signed-off-by: Sasha Levin Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260913173132.1172003-1-sashal@kernel.org Signed-off-by: Mark Brown commit a5e22cba3549b3b9ca592a6bc62329c9b85ce285 Author: Oder Chiou Date: Wed Sep 16 18:18:03 2026 +0800 ASoC: rt721: Reset codec to fix abnormal sound The audio output may become abnormal after a warm reboot from Windows. Reset the codec once during hardware initialization to restore it to a known state and prevent the issue. Signed-off-by: Oder Chiou Link: https://patch.msgid.link/20260916101803.2301508-1-oder_chiou@realtek.com Signed-off-by: Mark Brown commit d034e836eefd7ce75e588f7031cffbeec594f5ac Author: Joseph Qi Date: Tue Sep 1 09:04:13 2026 +0800 smb: client: fix use-after-free of iface in cifs_try_adding_channels() cifs_try_adding_channels() iterates ses->iface_list with list_for_each_entry_safe_from(), which captures the next entry (niface) under iface_lock. The loop body then drops iface_lock for the whole duration of cifs_ses_add_channel(). A concurrent interface refresh (SMB3_request_interfaces() -> parse_server_interfaces()) marks all ifaces inactive and removes and frees any that are not re-advertised via list_del() + kref_put(), where release_iface() is a bare kfree(). Since niface typically has no channel holding a reference, the list reference is its last and it can be freed inside the unlocked window. On continue, the iterator advance step then dereferences niface->iface_head.next, and the loop body reads iface->rdma_capable/is_active, both on freed memory. Fix this by never keeping an unreferenced list pointer across the unlocked window. Each channel attempt now re-scans the list from the head under iface_lock, takes a kref on the selected candidate, and passes only that referenced candidate to cifs_ses_add_channel(). weight_fulfilled still tracks selection progress, so restarting the scan preserves the original weighted distribution and the weight_fulfilled-before-kref_put ordering on the failure path. Add a per-pass attempts cap so a flapping interface refresh cannot keep the inner loop spinning within a single tries increment. Fixes: aa45dadd34e4 ("cifs: change iface_list from array to sorted linked list") Cc: stable@vger.kernel.org Assisted-by: Qoder:Qwen3.8-Max Signed-off-by: Joseph Qi Acked-by: Shyam Prasad N Signed-off-by: Paulo Alcantara commit 137d6ccf0ec8c48ecf0facc47cc46926df5fd0f3 Author: Carlos Llamas Date: Wed Sep 16 12:08:32 2026 +0000 rust_binderfs: add transaction_report feature entry rust_binderfs is missing the equivalent of commit f37b55ded8ed ("binder: add transaction_report feature entry"), which adds "transaction_report" to the binderfs feature list. This helps userspace determine if the BINDER_CMD_REPORT from the generic netlink API is supported. Cc: stable Fixes: f14e0c8183bc ("rust_binder: report netlink transactions") Signed-off-by: Carlos Llamas Link: https://patch.msgid.link/20260916120833.593407-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman commit 2a74ccd1bcc170e66525f34e9de8652b57e2cf3d Author: Alice Ryhl Date: Thu Sep 3 11:36:03 2026 +0000 rust_binder: reschedule node refcount update on thread exit 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 Signed-off-by: Greg Kroah-Hartman commit 62479b6e5df82cbdf3c4145130928f233fae78fb Author: Alice Ryhl Date: Thu Sep 3 09:22:52 2026 +0000 rust_binder: cancel deferred work items in thread exit If there are deferred work items on the thread todo list, then they are not cleaned up in the Thread::release() method. Thus, update the code to clean up the work items even if they are deferred. This can happen if the thread dies while it has an active outgoing transaction. Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260903-binder-exit-get-work-v1-1-2d6129a238df@google.com Signed-off-by: Greg Kroah-Hartman commit 30d15f44a9e513ec2f257fdf192d9d1fa5af0799 Author: Peiyang He Date: Sun Sep 13 16:56:45 2026 +0800 binderfs: fix UAF write in binder_add_device binderfs_binder_device_create() publishes the new dentry with d_make_persistent() and then calls simple_done_creating(), which drops the parent directory lock and the creator's dentry reference. It then calls binder_add_device() to register the device in the global binder_devices list. After simple_done_creating() releases the parent directory lock, a concurrent unlinkat() can remove the new device entry. Dropping the creator's dentry reference can then trigger binderfs_evict_inode(), freeing the device. binder_add_device() later accesses the freed object, causing UAF write. Found by a modified Syzkaller: BUG: KASAN: slab-use-after-free in hlist_add_head include/linux/list.h:1073 [inline] BUG: KASAN: slab-use-after-free in binder_add_device+0xa9/0xc0 drivers/android/binder.c:7068 Write of size 8 at addr ffff88805b340c00 by task syz.1.532/11389 CPU: 0 UID: 0 PID: 11389 Comm: syz.1.532 Not tainted 7.2.0 #4 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 hlist_add_head include/linux/list.h:1073 [inline] binder_add_device+0xa9/0xc0 drivers/android/binder.c:7068 binderfs_binder_device_create.isra.0+0x724/0x990 drivers/android/binderfs.c:196 binder_ctl_ioctl+0x186/0x1b0 drivers/android/binderfs.c:241 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9027a833d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ff903674018 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ff902a35fa0 RCX: 00007ff9027a833d RDX: 0000200000000500 RSI: 00000000c1086201 RDI: 0000000000000004 RBP: 00007ff902850733 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ff902a36038 R14: 00007ff902a35fa0 R15: 00007ffd7166bfa0 Allocated by task 11389: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __kmalloc_cache_noprof+0x2e4/0x6f0 mm/slub.c:5489 _kmalloc_noprof include/linux/slab.h:988 [inline] _kzalloc_noprof include/linux/slab.h:1309 [inline] binderfs_binder_device_create.isra.0+0x17a/0x990 drivers/android/binderfs.c:148 binder_ctl_ioctl+0x186/0x1b0 drivers/android/binderfs.c:241 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 11389: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2677 [inline] slab_free mm/slub.c:6377 [inline] kfree+0x2fc/0x6e0 mm/slub.c:6692 binderfs_evict_inode+0x1e8/0x260 drivers/android/binderfs.c:268 evict+0x3c2/0xad0 fs/inode.c:825 iput_final fs/inode.c:2019 [inline] iput fs/inode.c:2068 [inline] iput+0x79a/0xd30 fs/inode.c:2031 dentry_unlink_inode+0x27f/0x460 fs/dcache.c:479 dentry_kill+0x25d/0xc20 fs/dcache.c:826 finish_dput fs/dcache.c:1001 [inline] dput.part.0+0xce/0x230 fs/dcache.c:1042 dput+0x1f/0x30 fs/dcache.c:1037 end_dirop+0x7d/0xa0 fs/namei.c:2956 binderfs_binder_device_create.isra.0+0x71c/0x990 drivers/android/binderfs.c:194 binder_ctl_ioctl+0x186/0x1b0 drivers/android/binderfs.c:241 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff88805b340c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 0 bytes inside of freed 512-byte region [ffff88805b340c00, ffff88805b340e00) Fix by calling binder_add_device() before d_make_persistent(), while the parent directory lock is still held and the dentry cannot be discarded. Cc: stable Fixes: b89aa544821d ("convert binderfs") Signed-off-by: Peiyang He Assisted-by: Codex:gpt-5.5 Acked-by: Carlos Llamas Link: https://patch.msgid.link/F6EF5FB778E87C98+20260913085645.1639558-1-peiyang_he@smail.nju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 22c135635fdd9816c0ef140d6de7b2e4fdf73e89 Author: Tomer Pomeranc Date: Wed Aug 12 22:53:16 2026 +0300 binder: fix is_failure flag for superseded transaction cleanup When a TF_UPDATE_TXN transaction supersedes a pending async transaction, binder_release_entire_buffer() is called with is_failure=false. Since the superseded transaction was never delivered, binder_apply_fd_fixups() was never called and no fds were installed in the target process. With is_failure=false, the BINDER_TYPE_FDA cleanup handler interprets stale buffer contents as installed fd numbers and passes them to binder_deferred_fd_close(), closing unrelated file descriptors. Pass is_failure=true since the transaction was never delivered to the target, matching the semantics of all other undelivered-transaction cleanup paths. Fixes: 9864bb480133 ("Binder: add TF_UPDATE_TXN to replace outdated txn") Cc: stable Signed-off-by: Tomer Pomeranc Acked-by: Carlos Llamas Link: https://patch.msgid.link/20260812195316.259136-3-tomerpo@gmail.com Signed-off-by: Greg Kroah-Hartman commit c4c02084d6687d5cd5edccaf52cc45e5160f1184 Author: Tomer Pomeranc Date: Wed Aug 12 22:53:15 2026 +0300 binder: fix leaked fd fixups on TF_UPDATE_TXN supersede When a TF_UPDATE_TXN transaction supersedes a pending async transaction in a frozen process, the outdated transaction is freed with kfree() directly. This skips binder_free_txn_fixups(), leaking all binder_txn_fd_fixup entries and their fget()'d struct file references. The leaked file refcounts never reach zero, so the struct file objects are permanently pinned in memory. They survive process exit and accumulate across invocations until file-max exhaustion. Every other transaction cleanup path (binder_free_transaction(), binder_transaction() error paths, binder_release_work()) correctly calls binder_free_txn_fixups(). Add the missing call before kfree() in the t_outdated cleanup block. Fixes: 9864bb480133 ("Binder: add TF_UPDATE_TXN to replace outdated txn") Cc: stable Signed-off-by: Tomer Pomeranc Acked-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260812195316.259136-2-tomerpo@gmail.com Signed-off-by: Greg Kroah-Hartman commit 08b2ccd7eb7e41f77a04a09112ca3edcc588e3f0 Author: Myeonghun Pak Date: Mon Sep 14 21:20:11 2026 -0400 usb: ohci-st: disable controller wakeup on removal Probe enables controller wakeup after the OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Removal does not undo this, so the wakeup source can remain attached after driver unbind. Disable controller wakeup after removing the HCD. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: d115837259ad ("usb: host: ohci-st: Add OHCI driver support for ST STB devices") Cc: stable Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Patrice Chotard Acked-by: Alan Stern Link: https://patch.msgid.link/20260915012011.61874-5-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit b1b0f8bdbbc891a4ee7f3b1a878c633e02b7bbeb Author: Myeonghun Pak Date: Mon Sep 14 21:20:10 2026 -0400 usb: ohci-spear: disable controller wakeup on removal Probe enables controller wakeup after the OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Removal does not undo this, so the wakeup source can remain attached after driver unbind. Disable controller wakeup after removing the HCD. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: a6eeeb9f45b5 ("USB: Update USB default wakeup settings") Cc: stable Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Alan Stern Link: https://patch.msgid.link/20260915012011.61874-4-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8dd8451c527e2a723bca20da5a6d724b8592551f Author: Myeonghun Pak Date: Mon Sep 14 21:20:09 2026 -0400 usb: ohci-s3c2410: disable controller wakeup on removal Probe enables controller wakeup after the OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Removal does not undo this, so the wakeup source can remain attached after driver unbind. Disable controller wakeup after removing the HCD. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: a6eeeb9f45b5 ("USB: Update USB default wakeup settings") Cc: stable Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Alan Stern Link: https://patch.msgid.link/20260915012011.61874-3-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 901197dd4c7dcffbf97426487d4c047555c98554 Author: Myeonghun Pak Date: Mon Sep 14 21:20:08 2026 -0400 usb: ohci-da8xx: disable controller wakeup on cleanup The OHCI core marks controllers with RemoteWakeupConnected as wakeup-capable. Probe enables wakeup, but neither removal nor a later notifier registration failure disables it, leaving the wakeup source attached. Disable controller wakeup after removing the HCD on both paths. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: a6eeeb9f45b5 ("USB: Update USB default wakeup settings") Cc: stable Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Alan Stern Link: https://patch.msgid.link/20260915012011.61874-2-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit ebe9b68c396792c15d0ac690d592e449e74ed804 Author: Fan Wu Date: Wed Sep 9 09:56:55 2026 +0000 usb: cdns3: fix use-after-free in cdns3_gadget_exit() cdns3_gadget_start() arms two works on system_freezable_wq: pending_status_wq for the deferred ep0 status stage and aligned_buf_wq for realigned request buffers. Both handlers use the cdns3_device the works are embedded in, and cdns3_pending_setup_status_handler() also calls the ep0 request completion. cdns3_gadget_exit() does not wait for these works. It frees all endpoints and aligned buffers and drops the last reference to the gadget device, which frees priv_dev, so a work queued before the exit can run after the free. Fix this by waiting for both works after the gadget driver is unbound and the IRQ is freed, when no new work can be queued, and before the endpoints and buffers are released. This issue was found by an in-house static analysis tool. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable Reported-by: Sicong Huang Closes: https://lore.kernel.org/linux-usb/7f5719b.8700.18f67b324d3.Coremail.congei42@163.com/ Suggested-by: Sicong Huang Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Acked-by: Peter Chen Link: https://patch.msgid.link/20260909095655.694527-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit f1d6f7d25fe88ee49aaad96c8649e090fc3a4b68 Author: Myeonghun Pak Date: Sun Sep 13 00:10:33 2026 -0400 usb: chipidea: tegra: disable runtime PM on resume failure tegra_usb_probe() enables runtime PM before resuming the device. If pm_runtime_resume_and_get() fails, probe returns without disabling runtime PM. The later error paths reach pm_runtime_force_suspend(), but this early return bypasses that cleanup. Disable runtime PM before returning the resume error. Do not use the fail_power_off path: the failed resume did not retain a usage reference, so its pm_runtime_put_sync_suspend() would be unbalanced. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 8b85e11c1a7a ("usb: chipidea: tegra: Add runtime PM and OPP support") Cc: stable Assisted-by: OpenAI:GPT-5.6 Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Peter Chen Link: https://patch.msgid.link/20260913041033.25144-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 469600d5d292b1482c90dd6853555821d11b8c5f Author: Linkai Gong Date: Thu Sep 10 09:11:50 2026 +0800 usb: typec: anx7411 - stop the IRQ before destroying the workqueue The IRQ is devm-managed, so it can still queue plat->work while remove() is tearing the queue down. Disable it first. Fixes: fe6d8a9c8e64 ("usb: typec: anx7411: Add Analogix PD ANX7411 support") Cc: stable Signed-off-by: Linkai Gong Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260910011150.2966843-1-gonglinkai@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 98d00deb6ae4a83f567444215302ab7b101ed439 Author: Igor Paunovic Date: Mon Sep 7 20:30:41 2026 +0200 usb: typec: tcpm: fix use-after-free of the kthread worker on port unregister tcpm_unregister_port() destroys the port's kthread worker first and calls tcpm_reset_port() afterwards. Since the Discover Identity retry mechanism was added, tcpm_reset_port() calls mod_vdm_discovery_cancel_delayed_work(), which does kthread_cancel_work_sync(&port->vdm_discovery_work). That dereferences work->worker, which still points at the worker that kthread_destroy_worker() has already freed: tcpm_unregister_port() kthread_destroy_worker(port->wq) -> kfree(worker) ... tcpm_reset_port() mod_vdm_discovery_cancel_delayed_work() kthread_cancel_work_sync(&port->vdm_discovery_work) __kthread_cancel_work_sync() raw_spin_lock_irqsave(&worker->lock, ...) <- freed memory KASAN report on 7.3-rc1 when unbinding a fusb302 port (RK3588): BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x10c/0x210 Write of size 4 at addr ffff00010122ef04 by task bash/8349 Call trace: _raw_spin_lock_irqsave+0x10c/0x210 __kthread_cancel_work_sync+0x60/0x408 kthread_cancel_work_sync+0x20/0x48 tcpm_reset_port+0x18c/0xb80 [tcpm] tcpm_unregister_port+0x104/0x2f8 [tcpm] fusb302_remove+0xc8/0x200 [fusb302] i2c_device_remove+0x7c/0x288 ... Allocated by task 112: kthread_create_worker_on_node+0x14c/0x2c8 tcpm_register_port+0x288/0x3918 [tcpm] fusb302_probe+0x604/0xc88 [fusb302] Freed by task 8349: kfree+0x260/0x558 kthread_destroy_worker+0xa0/0x130 tcpm_unregister_port+0x74/0x2f8 [tcpm] fusb302_remove+0xc8/0x200 [fusb302] With CONFIG_PROVE_LOCKING the same unbind shows up as "DEBUG_LOCKS_WARN_ON(lock->magic != lock)" in __lock_acquire, followed by an oops in the unbinding task, which then exits with interrupts disabled and the following shutdown hangs. The work itself cannot be pending at that point: kthread_destroy_worker() has flushed the worker and the discovery timer is cancelled right before the cancel call. So just remember that the worker is gone and skip the cancel in that case. Tested on an Orange Pi 5 Plus (RK3588, fusb302) with KASAN: unbinding the port reports the use-after-free above without this patch and nothing with it; the port binds again fine afterwards in both cases. Fixes: 205dc9cb39f5 ("usb: typec: tcpm: implement retry mechanism for Discover Identity VDMs") Signed-off-by: Igor Paunovic Assisted-by: LLM Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260907183041.8253-1-royalnet026@gmail.com Signed-off-by: Greg Kroah-Hartman commit b5dbb41b212c50c095a4dbee3017a84fe94f033b Author: Aldo Ariel Panzardo Date: Tue Sep 15 12:59:52 2026 -0300 Bluetooth: mgmt: fix race in read_unconf_index_list() read_unconf_index_list() counts unconfigured controllers before allocating its response, then checks the device flags again while filling it. hci_dev_list_lock stabilizes list membership, but it does not serialize the per-device flags. During asynchronous controller setup, the worker can set HCI_UNCONFIGURED and clear HCI_SETUP between the two passes. A controller omitted from the allocation count can then become eligible for the fill pass, causing an out-of-bounds write to rp->index[]. Allocate space for every device on hci_dev_list. Since list membership cannot change while hci_dev_list_lock is held, the response remains large enough regardless of flag transitions. The reported count and response length still include only eligible unconfigured controllers. Fixes: 73d1df2a7a10 ("Bluetooth: Add support for Read Unconfigured Index List command") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz commit 6c78a213d9070b610c7f418af2c25b66180b7e37 Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:02:39 2026 -0300 Bluetooth: L2CAP: validate frame length before control and FCS access l2cap_data_rcv() unpacks either a two-byte or four-byte control field without first ensuring that it is present. A short ERTM or streaming-mode frame can therefore cause an out-of-bounds read. There is a second short-frame case when CRC16 is enabled. After the control field is pulled, l2cap_check_fcs() subtracts two from skb->len without checking it. If fewer than two bytes remain, the subtraction wraps; skb_trim() leaves the buffer unchanged and the subsequent FCS load reads past the logical end of the frame. Validate that the frame contains both its control field and, when enabled, its FCS before either field is accessed. Fixes: 1c2acffb76d4 ("Bluetooth: Add initial support for ERTM packets transfers") Fixes: fcc203c30d72 ("Bluetooth: Add support for FCS option to L2CAP") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz commit 4c94557dd02569efa6c1072a0439addaef9a5224 Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:03:32 2026 -0300 Bluetooth: ISO: balance the parent hold in hci_bind_bis() hci_conn_link() takes a lifetime reference to its parent with hci_conn_get(), but only takes an operational hold on the child. hci_conn_unlink() later balances both a hold and a reference on the parent. The SCO and CIS paths pass a parent acquired from a connect helper, so it already has a hold. For an additional BIS, hci_bind_bis() obtains the parent from hci_conn_hash_lookup_big(), which returns a bare pointer. Unlinking the child then drops the parent's existing hold and can schedule it for disconnection while its socket is still using it. Take a hold on the parent before linking it and drop that hold if linking fails. A successful link transfers the hold to hci_conn_unlink(). Fixes: fa224d0c094a ("Bluetooth: ISO: Reassociate a socket with an active BIS") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz commit b0a6cf99afd57a39598b1beca0e86ef5004980de Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:03:07 2026 -0300 Bluetooth: hci_sock: validate event length before filtering is_filtered_packet() reads the event code from skb->data[0] without first checking that the skb is nonempty. When an opcode filter is configured, it also reads the command opcode at offsets 3 or 4 without checking that a Command Complete or Command Status event is long enough. hci_send_to_sock() invokes the filter before hci_event_packet() validates the event header. A malformed event supplied by a controller or a vhci device can therefore cause an out-of-bounds read. Keep the unmasked event code for the opcode checks. The masked value is needed for the 64-bit event bitmap, but using it to identify command events aliases event codes above 0x3f. In particular, Synchronous Train Complete (0x4f) was treated as Command Status (0x0f) even though its payload has no opcode. Reject actual command events that are too short for the field being inspected. A truncated command event cannot match a configured opcode. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz commit e93fad891c72deb84cae49430163b384ebcc92b1 Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:03:58 2026 -0300 Bluetooth: hci_sock: reject out-of-range OCF values The raw HCI socket security filter has 128 OCF bits per supported OGF, but masks the 10-bit OCF with 127 before looking up the command. An unprivileged socket can therefore submit a reserved OCF that aliases an allowlisted command modulo 128. A conforming controller should reject reserved opcodes. Nevertheless, the security decision must apply to the opcode that will actually be sent, especially since controller-specific behavior is outside the host stack's control. Reject OCF values that cannot be represented by the security filter instead of aliasing them onto an unrelated command. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz commit 0fcd4dad555c96e0bd3a1b8c569f989be85c7341 Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:04:30 2026 -0300 Bluetooth: ISO: release unused CIS holds after channel attach hci_bind_cis() and hci_connect_cis() return one hci_conn hold for the ISO layer. A new channel association consumes that hold, which is eventually released by iso_conn_free(). There are two cases where iso_chan_add() does not create an association: it returns success when the socket is already attached to the same iso_conn, and it returns -EBUSY when another socket is attached. The hold returned for the current call is unused in both cases. This occurs when deferred setup calls iso_connect_cis() again for its existing socket, or when another socket attempts to reuse the CIS. Detect the idempotent case while the connection is locked and release the unused hold after iso_chan_add(). Also release it on -EBUSY. Do not drop it for other errors: a newly allocated iso_conn releases the transferred hold when its last temporary reference is put. Fixes: 69997d50ec57 ("Bluetooth: ISO: handle bound CIS cleanup via hci_conn") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz commit e06d549fcd4a0ba381ed67ddf1ab3c7a6ca4314c Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:04:29 2026 -0300 Bluetooth: hci_conn: fix CIS hold ownership on reuse Commit 69997d50ec57 ("Bluetooth: ISO: handle bound CIS cleanup via hci_conn") made hci_bind_cis() and hci_connect_cis() return a connection with one hold for the ISO layer. hci_bind_cis() currently takes that hold only after configuring a CIS, so its BT_CONNECTED and matching BT_BOUND paths return a bare lookup result. Its configuration failure path can likewise call hci_conn_drop() before taking a hold. Take the hold before any state-dependent return or configuration error so every successful return follows the documented ownership contract and every error drop is balanced. hci_connect_cis() also assumes hci_conn_link() always takes a new CIS hold before dropping the one returned by hci_bind_cis(). However, the helper returns an existing link without taking another hold. In that case, preserve the CIS hold for the caller and drop the redundant LE hold because the existing link already owns its parent hold. Returning early also avoids changing an existing CIS back to BT_CONNECT. Fixes: 69997d50ec57 ("Bluetooth: ISO: handle bound CIS cleanup via hci_conn") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz commit 71af682ba4692c2ed9ace4c3d4ca462ae368c029 Author: Lee Jones Date: Tue Sep 15 12:08:22 2026 +0000 Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel In send_cancel(), pending mesh_tx objects are removed from the hdev->mesh_pending list and freed via mesh_send_complete(). However, if a mesh transmission was already queued onto hdev->cmd_sync_work_list via mesh_next(), the queued entry retains a raw pointer to mesh_tx. When hci_cmd_sync_work later processes the entry, it attempts to execute mesh_send_sync and its destroy callback mesh_send_start_complete using the already freed mesh_tx pointer, leading to a use-after-free. Fix this by invoking hci_cmd_sync_dequeue() for mesh_send_sync on the target mesh_tx before completing it. If the entry is found and dequeued, its destroy callback will complete and free the object; otherwise, mesh_send_complete() is called directly. Additionally, ensure the transmission queue advances after cancellation or errors. In mesh_send_start_complete(), call mesh_next() on error unless err is -ECANCELED, because hci_cmd_sync_dequeue() holds hdev->cmd_sync_work_lock and calling mesh_next() synchronously would deadlock. Instead, advance the queue in send_cancel() once the lock is released and if no transmission is in progress. Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Signed-off-by: Lee Jones Signed-off-by: Luiz Augusto von Dentz commit f2bbb36426581045a8bf7793da5419b9375e4348 Author: Zijun Hu Date: Tue Sep 15 19:17:18 2026 -0700 Bluetooth: btnxpuart: Fix skb leak in nxp_process_fw_dump() When CONFIG_DEV_COREDUMP=n, hci_devcd_append() returns -EOPNOTSUPP without freeing its skb argument. This leaks the cloned skb and also prevents nxp_set_ind_reset() from being called to perform recovery. Fix by guarding the hci_devcd_append(hdev, skb_clone(skb, GFP_ATOMIC)) call with IS_ENABLED(CONFIG_DEV_COREDUMP). Fixes: 998e447f443f ("Bluetooth: btnxpuart: Add support for HCI coredump feature") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz commit f033482d76a9f18080c7a40c5f9c678bd7adc8f3 Author: Christiano Amora Date: Wed Sep 16 10:46:22 2026 -0300 Bluetooth: SMP: reject Security Request over BR/EDR Bose QC Ultra Headphones (dual-mode, same public address on both transports) occasionally send an SMP Security Request on the BR/EDR SMP fixed channel right after the ACL link is encrypted. The kernel handles it as if it were an LE link: smp_cmd_security_req() has no transport check, smp_ltk_encrypt() looks up an LTK with the ACL connection's dst_type, and hci_find_ltk() matches the peer's LE LTK because the LE public address type is stored as ADDR_LE_DEV_PUBLIC (0), the same value as BDADDR_BREDR. HCI_OP_LE_START_ENC is then issued on the ACL handle, the controller rejects it with Invalid HCI Command Parameters, and hci_cs_le_start_enc() disconnects the link with HCI_ERROR_AUTH_FAILURE. The headphones drop within a second of connecting, before any profile is up; a manual reconnect works. btmon (MediaTek MT7922, kernel 7.0.12): > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 50 Address: BC:87:FA:47:73:5E (Bose Corporation) Encryption: Enabled with AES-CCM (0x02) > ACL Data RX: Handle 50 flags 0x02 dlen 6 BR/EDR SMP: Security Request (0x0b) len 1 Authentication requirement: No bonding, No MITM, SC (0x08) < HCI Command: LE Start Encryption (0x08|0x0019) plen 28 Handle: 50 Address: BC:87:FA:47:73:5E (Bose Corporation) > HCI Event: Command Status (0x0f) plen 4 LE Start Encryption (0x08|0x0019) ncmd 1 Status: Invalid HCI Command Parameters (0x12) < HCI Command: Disconnect (0x01|0x0006) plen 3 Handle: 50 Address: BC:87:FA:47:73:5E (Bose Corporation) Reason: Authentication Failure (0x05) SMP over BR/EDR is limited to cross-transport key derivation; the Security Request procedure (Core Specification Vol 3, Part H, Section 2.4.6, PDU in Section 3.6.7) has no BR/EDR counterpart. Reply with Pairing Failed / Command Not Supported on a non-LE link, before the PDU is parsed, and keep the connection. The reply is sent directly rather than through smp_failure(): rejecting a command on the wrong transport is not an authentication failure, and MGMT_EV_AUTH_FAILED would make bluetoothd disconnect the device. Tested on the affected host (kernel 7.0.12, MediaTek MT7922, Bose QC Ultra) with the patched module built out of tree: 7 days and 49 reconnects without a drop, against 2 drops in the 3 days before the patch. Every disconnect in that week had a userspace or remote reason. Fixes: b5ae344d4c0f ("Bluetooth: Add full SMP BR/EDR support") Assisted-by: LLM Signed-off-by: Christiano Amora Signed-off-by: Luiz Augusto von Dentz commit e922bad8b2d5028c51a096d083fea41cd0987154 Author: Itai Handler Date: Thu Sep 10 20:48:32 2026 +0300 spi: spi-zynqmp-gqspi: stop the controller on shutdown The driver has no ->shutdown, and platform_drv_shutdown() has no fallback of its own. Unlike pci_device_shutdown(), which clears bus mastering when kexec_in_progress, nothing on the platform bus disarms a device that can still write to memory. The normal kexec path never calls ->suspend either, so the quiesce in zynqmp_qspi_suspend() is not reached. A controller that is still executing a DMA read may therefore keep writing to memory across a kexec. QSPIDMA_DST_ADDR still points at memory owned by the kernel that called kexec, DST_SIZE is non-zero and the flash is still clocked, so data can keep landing in RAM while the new kernel is being relocated, and after it has started executing. That destination is a physical address which means nothing to the new kernel, so the writes can corrupt whatever now occupies it: kernel text or data, page tables, or the initrd. Nothing reports an error and the resulting behaviour is undefined. This can be observed by reading GQSPI_EN (offset 0x114) and QSPIDMA_DST_ADDR/SIZE/STS/CTRL (offsets 0x800 to 0x80c) early in the new kernel, before the driver probes: without this patch GQSPI_EN reads 1 and QSPIDMA_DST_ADDR still points into the previous kernel's memory. Add a ->shutdown that stops the controller the way zynqmp_qspi_suspend() already does. spi_controller_suspend() stops the queue, waits for a message that is already executing and makes any later transfer fail with -ESHUTDOWN, so nothing can be cut short by the register write that follows. It may sleep, which is fine here: device_shutdown() runs in process context. Unlike ->suspend this cannot abort on error, because a controller left mastering the bus is worse than a truncated transfer, so a failure to drain is only logged. GQSPI_EN_OFST is then cleared, as zynqmp_qspi_remove() and zynqmp_qspi_suspend() already do. Skip that write only when pm_runtime_get_if_in_use() returns 0, i.e. runtime suspended: the clocks are gated, so the registers are unreachable and the controller cannot be mastering the bus. A negative return is not the same thing - it is what the CONFIG_PM=n stub always returns, and there probe() has enabled pclk and refclk for good, so the controller is running and must be stopped. Fixes: dfe11a11d523 ("spi: Add support for Zynq Ultrascale+ MPSoC GQSPI controller") Cc: stable@vger.kernel.org Signed-off-by: Itai Handler Link: https://patch.msgid.link/20260910174832.873352-1-itai.handler@gmail.com Signed-off-by: Mark Brown commit 1d9bb9c870632adea249cfdec49ac37e6f069164 Author: Myeonghun Pak Date: Sun Sep 13 00:03:12 2026 -0400 pinctrl: single: free the IRQ on domain creation failure pcs_irq_init_chained_handler() requests a shared IRQ on affected SoCs, but its domain creation failure path only removes a chained handler. That does not release the action installed by request_irq(). The probe can continue without interrupt support while leaving the shared IRQ action registered. Use pcs_irq_free() to undo the appropriate type of handler registration. At this point pcs->domain is NULL, so the helper only releases the parent IRQ handler. Then mark the IRQ invalid, as the other initialization error paths already do, to prevent another release from a later probe unwind or remove. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 3e6cee1786a1 ("pinctrl: single: Add support for wake-up interrupts") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Linus Walleij commit ef56085dfd1df3a53ecce8a4ff440cf6d67f430d Author: Andre Przywara Date: Mon Sep 14 12:07:44 2026 +0200 pinctrl: sunxi: A523: fix voltage withstand encoding The Allwinner A523 uses the same GPIO voltage "withstand" programming (setting the input level voltage thresholds) as the previous SoCs, but for some odd reason inverts the encoding of 1.8V vs. 3.3V. Add a new bias voltage type to note this difference, and select it for the A523. At the same time also use the newer "CTL" version, which in addition allows to turn off the withstand programming for I/O voltages other than exact 1.8V or 3.3V (for instance for 2.5V sometimes used for Ethernet PHYs). The A523 has that enable register, but didn't use it so far. This fixes eMMC and reportedly Ethernet operation on some A523 boards. Fixes: 648be4cd9517 ("pinctrl: sunxi: Add support for the Allwinner A523") Signed-off-by: Andre Przywara Tested-by: Per Larsson Tested-by: Juan Manuel Lopez Carrillo Reviewed-by: Chen-Yu Tsai Tested-by: Chen-Yu Tsai # Fixes eMMC on Orange Pi 4A Signed-off-by: Linus Walleij commit acb03d3881818581052924a9bbbe92b8741ed448 Author: Hyunwoo Kim Date: Fri Sep 11 11:09:17 2026 +0200 exec: Cleanup POSIX timers right after de_thread() A per-thread CPU timer holds a reference to the PID of the thread it is attached to and, while it is armed, its node is queued in that thread's posix_cputimers. The task is looked up by that PID. When a non-leader thread exec()s, de_thread() changes which task owns that PID. pid_task(timer->it.cpu.pid, PIDTYPE_PID) then returns NULL, but the node is still queued on tsk, which is alive. timer_lock_sighand() takes a failed lookup to mean that the node is already dequeued, so it has nothing to undo. begin_new_exec() calls posix_cpu_timers_exit(me) right after exec_task_namespaces() and that removes the leftover node, so the state normally stays invisible. But bprm->point_of_no_return is set before de_thread(), so if unshare_files(), set_mm_exe_file(), exec_mmap() or exec_task_namespaces() fails, the task dies before it gets there. exit_itimers() then frees the k_itimer while its node is still queued, and reaping tsk later erases that freed node from the rbtree. In short: the non-leader thread B the parent timer_create(CLOCK_THREAD_CPUTIME_ID) timer_settime() arm_timer() // the node is queued on B execve() de_thread(B) exchange_tids(B, leader) // B's PID now belongs to the leader release_task(leader) __exit_signal(leader) posix_cpu_timers_exit(leader) // cleans leader's queue, not B's __unhash_process(leader) // that PID has no task anymore exec_mmap() mmap_read_lock_killable(old_mm) kill(B, SIGKILL) // -EINTR get_signal() do_exit() exit_itimers() posix_timer_delete() posix_cpu_timer_del() posix_timer_unhash_and_free() // freed while still queued wait4() release_task(B) posix_cpu_timers_exit(B) cleanup_timerqueue() timerqueue_del() // use-after-free Move the POSIX timer cleanup right after de_thread() before any of the later failure conditions brings the task into do_exit(). [ tglx: Move the cleanup right after de_thread() ] Fixes: 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task") Signed-off-by: Hyunwoo Kim Signed-off-by: Thomas Gleixner Tested-by: Kijo Park Reviewed-by: Oleg Nesterov Reviewed-by: Frederic Weisbecker Cc: stable@vger.kernel.org Link: https://patch.msgid.link/ao7Q8miiuLAPVnWv@v4bel Link: https://patch.msgid.link/20260911090541.627712075@kernel.org commit d2710c8d938ae6a825a6463158e6e6f31eac792a Author: Thomas Gleixner Date: Fri Sep 11 11:09:12 2026 +0200 signal: Prevent exec() race Hyunwoo debugged the following KASAN UAF splat: BUG: KASAN: slab-use-after-free in __send_signal_locked+0xb27/0xba0 Write of size 8 at addr ffff888007ed80c8 by task poc/79 ... Call Trace: __send_signal_locked+0xb27/0xba0 do_send_sig_info+0xa7/0x160 do_send_specific+0x76/0xa0 __x64_sys_tgkill+0x193/0x270 ... Allocated by task 80: do_timer_create+0x1a4/0x1030 __x64_sys_timer_create+0x145/0x190 ... Freed by task 12: kmem_cache_free_bulk+0x1f8/0x4a0 kvfree_rcu_bulk+0x14f/0x1c0 kfree_rcu_work+0x128/0x1a0 ... Last potentially related work creation: kvfree_call_rcu+0x39/0x390 __flush_itimer_signals+0x211/0x320 flush_itimer_signals+0x47/0x90 begin_new_exec+0xa6b/0x28c0 It turned out that this happens with a non-leader exec() as Hyunwoo explained: de_thread() calls exchange_tids() before release_task(leader), so the struct pid held by a SIGEV_THREAD_ID timer created against the leader's tid now points to the thread which called execve(). pid_task() returns that thread and lock_task_sighand() on it succeeds. If the timer signal is blocked, its sigqueue stays queued on the leader's task::pending. The next expiry of that timer can then run while release_task() flushes the queue. posixtimer_send_sigqueue() checks whether the sigqueue is already queued with a plain list_empty(), which only reads list_head::next. list_del_init() is not atomic and INIT_LIST_HEAD() stores list_head::next before list_head::prev, so the check can pass in between. list_add_tail() queues the entry on the task::pending of the live thread, and the list_head::prev store from the flush then overwrites the list_head::prev link that list_add_tail() has just set. __flush_itimer_signals() does not undo that either. With list_head::prev pointing at the entry itself, its list_del_init() only stores the same values again, so the entry is not removed from the list. It is still there after the last reference is dropped and the timer is freed by RCU, and the list_add_tail() of a later tgkill() follows that list_head::prev into the freed timer. This problem surfaced with the recent commit which moved the sigqueue flush out of the sighand lock held region. Hyonwoo proposed to fix this by using list_del_init_careful(), but that just papers over the problem. After some disucssions and various attempts to solve it, Eric pointed out that there is no reason to flush task::pending late in release_task() and it should be done in exit_signals() already. As nothing can collect and deliver signals which are queued in a dying task's pending queue, there is no reason to delay it further. But it has to be ensured that no signals can be queued into it after that point. exit_signals() sets PF_EXITING in task::flags, which can be used as an indicator for this. Cure it by: - Preventing signal queueing for task private signals (PIDTYPE_PID) when the task has PF_EXITING set in __send_signal_locked() and in posixtimer_send_sigqueue(). - Protecting the unlocked setting of PF_EXITING in exit_signals() for the task group empty and the group exit case with sighand lock - Flushing task::pending signals right there. Optimize that by moving the whole pending list to an on-stack list head under sighand lock and free the signals without the lock held. There has been quite some discussion about the lockless flush and the non-leader exec case on weakly ordered systems. The problem is that a third party which tries to send a posix timer signal relies on the PID lookup to find the target task and that lookup might result in the new leader when the signal was originaly directed to the old leader. In case that the signal was queued on the old leader then the lockless flush raised a concern over the following situation: old_leader new_leader third party A: flush_list() // list_del_init() stores to sigqueue LOCK (tasklist) old_leader->exit_state = EXIT_ZOMBIE; B: UNLOCK (tasklist) C: LOCK (tasklist) if (old_leader->exit_state) transfer_tids() D: store PID posix_timer_send_sigqueue() // Observes #D so t = new_leader E: t = get_target() F: LOCK (sighand) G: if (list_empty(sigqueue)) list_add(sigqueue) The concern was that the third party might observe #D but not observe #A and therefore would proceed to #G while the list_del() stores (#A) in flush_list() are not visible yet, which could result in list corruption. That would be possible if looking at it solely from a RELEASE+ACQUIRE ordering point of view, but B-C is a UNLOCK+LOCK hand-over, which is not the same as RELEASE+ACQUIRE: RELEASE+ACQUIRE: RCpc, only the CPUs involved agree on the ordering UNLOCK+LOCK: RCtso, the hand-over is store-ordering As B-C is UNLOCK+LOCK, which is RCtso and that does impose store order, A stores must happen before the D store. Combine with E-F, which has a data dependency from the LOAD to the LOCK and thereby constraints later LOADs, those sigqueue loads in G that come after F must in fact observe the A stores. Fixes: fb3bbcfe344e ("exit: change the release_task() paths to call flush_sigqueue() lockless") Reported-by: Hyunwoo Kim Debugged-by: Hyunwoo Kim Suggested-by: "Eric W. Biederman" Signed-off-by: Thomas Gleixner Tested-by: Kijo Park Reviewed-by: Oleg Nesterov Reviewed-by: Frederic Weisbecker Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260911090541.572536604@kernel.org Closes: https://patch.msgid.link/aok1rdkBgZsynHZB@v4bel commit 238650ef6c7c7cca08e032527329424c9fbd70e5 Merge: 9b87fdc9af2fbf 0b271f7d7f5ed4 Author: Linus Torvalds Date: Wed Sep 16 09:29:25 2026 -0700 Merge tag 'powerpc-7.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Madhavan Srinivasan: "KVM: - fix use-after-free in kvmhv_emulate_tlbie_all_lpid() - fix secure device page leak on uv_page_in() failure iommu: - Fix the overflow validation in iommu_tce_check_ioba Thanks to Amit Machhiwal, Gautam Menghani, Ritesh Harjani (IBM), R Nageswara Sastry, and Shivaprasad G Bhat" * tag 'powerpc-7.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/iommu: Fix the overflow validation in iommu_tce_check_ioba KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure KVM: PPC: Book3S HV: fix use-after-free in kvmhv_emulate_tlbie_all_lpid() commit 1d12fb94ac0975566545871dda100df34df5f845 Author: Sanman Pradhan Date: Tue Sep 15 16:48:35 2026 +0000 hwmon: (pmbus/tps53679) Fix TPS53676 phase page decoding tps53676_identify() reads the USER_DATA_03 phase configuration to count the phases assigned to each channel and derive the number of PMBus pages. In each 16-bit phase descriptor the channel (PAGE) is encoded in bit 4 and the firing order in bits 3:0, but the code tested bit 3 (0x08), which is part of the firing-order field. TPS53676 supports up to seven phases, so firing-order bit 3 is never set. As a result the existing test classifies every enabled phase as channel A. On a dual-channel configuration the phases assigned to channel B are therefore miscounted as channel A and page 1 is not exposed. Test the PAGE field (bit 4) instead. Fixes: cb3d37b59012 ("hwmon: (pmbus/tps53679) Add support for TI TPS53676") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://patch.msgid.link/20260915164823.160977-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck commit e6cb0b4d4ecb8e71fd2200d907ab2e9663356f69 Author: Muhammad Bilal Date: Wed Sep 16 05:29:26 2026 +0500 hwmon: (hp-wmi-sensors) Fix use-after-free in fungible_show() nsensor->current_state is dynamically replaced as the sensor's state changes. update_numeric_sensor_from_wobj() does this by freeing the old string and installing a new one: if (strcmp(trimmed, nsensor->current_state)) { new_string = hp_wmi_strdup(dev, trimmed); if (new_string) { devm_kfree(dev, nsensor->current_state); nsensor->current_state = new_string; } } This function is only ever called from hp_wmi_update_info() while state->lock is held, so the free-and-replace itself is properly serialized against concurrent updates. fungible_show(), however, reads the same pointer after the lock has already been dropped: err = hp_wmi_update_info(state, info); if (err) return err; switch (prop) { ... case HP_WMI_PROPERTY_CURRENT_STATE: seq_printf(seqf, "%s\n", nsensor->current_state); break; hp_wmi_update_info() takes state->lock internally and releases it before returning, so by the time fungible_show() dereferences nsensor->current_state in seq_printf(), no lock is held. Two processes reading a sensor's current_state debugfs entry at overlapping times (or one reading it while another read of the same sensor triggers a refresh) can race: one thread's seq_printf() can be part-way through printing the string at the moment another thread's call into update_numeric_sensor_from_wobj() frees it with devm_kfree() and installs a new pointer, causing a use-after-free read. Take state->lock around the read in fungible_show() as well, so it can never run concurrently with the free-and-replace in update_numeric_sensor_from_wobj(). Fixes: 23902f98f8d4 ("hwmon: add HP WMI Sensors driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Acked-by: James Seo Link: https://patch.msgid.link/20260916002926.161595-1-meatuni001@gmail.com Signed-off-by: Guenter Roeck commit 8d836581f9b1f57ceaa2b47654754ef1260b410b Author: Niklas Cassel Date: Wed Sep 16 15:00:32 2026 +0200 ata: libata-scsi: fix ata_dsm_trim_pages() kernel-doc make htmldocs fails with: Documentation/driver-api/libata:604: ./drivers/ata/libata-scsi.c:2301: ERROR: Unexpected indentation. [docutils] The Return: section of ata_dsm_trim_pages() ends its first sentence with a colon and continues with an indented bullet list. reStructuredText requires a blank line before an indented block, so docutils chokes on the list. Simply adding the missing blank line does not work either: Return: is a kernel-doc "special section", which is terminated by the first blank line, so the bullet list would end up in the Description section, detached from the sentence introducing it. Spell the two bounds out as prose instead, so that the Return: section stays self-contained. Documentation-only change. Fixes: e64e6b5dc867 ("ata: libata-scsi: scale DSM TRIM payload by MAX PAGES PER DSM COMMAND") Reported-by: Thomas Huth Closes: https://lore.kernel.org/linux-ide/b0a0b8e8-cc4f-4c7b-8bc5-fee0712d405a@redhat.com/ Reviewed-by: Damien Le Moal Reviewed-by: Thomas Huth Link: https://lore.kernel.org/r/20260916130031.29990-2-cassel@kernel.org Signed-off-by: Niklas Cassel commit b6ec0f79745967c751c85df373062c8d15e45fc4 Author: ZHOU Jiaxiang Date: Wed Sep 16 21:58:22 2026 +0800 scsi: sd_zbc: Reject disks with too many zones sd_zbc_read_zones() computes the number of zones with 64-bit arithmetic and stores the result in the unsigned int nr_zones field of struct zoned_disk_info, silently truncating counts that exceed 32 bits. The truncated count is later used to size per-zone resources, while the device may still report more zones than fit. Moreover, sd_zbc_report_zones() counts the reported zones with a signed int zone_idx, which overflows past INT_MAX. Reject devices reporting more than INT_MAX zones at scan time; such a device is not realistic for any medium that exists today, and accepting it produces inconsistent zone bookkeeping. Fixes: 89d947561077 ("sd: Implement support for ZBC devices") Signed-off-by: ZHOU Jiaxiang Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/C41798AB5AA6BF2B+20260916135822.32584-3-me@fxti.xyz Signed-off-by: Martin K. Petersen (Oracle) commit 7c431d61b69a3fd0784c20aa4cd0b8fb501b5653 Author: ZHOU Jiaxiang Date: Wed Sep 16 21:58:21 2026 +0800 scsi: block: Fix zones_cond out-of-bounds write on zone report blk_revalidate_disk_zones() sizes the zones_cond array from the disk capacity and zone size, but the index used by blk_revalidate_zone_cond() comes from the device-driven report_zones() walk and is never checked against the array size. A device reporting more zones than fit the array makes blk_zone_set_cond() write out of bounds. One way to reach this is a zone count exceeding 32 bits: both blk_revalidate_zone_args.nr_zones and struct zoned_disk_info.nr_zones are unsigned int, so a disk advertising more than UINT_MAX zones (e.g. 2^32 + 1024 zones of one 512-byte logical block) gets its zone count truncated to a small value, undersizing the array while the report walk keeps counting upward. Check the index against the array size before storing the zone condition, and refuse to revalidate when the zone count does not fit 32 bits. Fixes: 6e945ffb6555 ("block: use zone condition to determine conventional zones") Signed-off-by: ZHOU Jiaxiang Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/7815D1B293A8F55E+20260916135822.32584-2-me@fxti.xyz Signed-off-by: Martin K. Petersen (Oracle) commit 76bf149cd0298544631e756670b89c399c7acbca Author: Daniel Linjama Date: Wed Sep 16 09:15:56 2026 +0300 btrfs: handle lack of space when cleaning up verity items When enable_verity() hits the qgroup limit, rollback_verity() needs its own metadata reservation. When the qgroup limit or lack of space refuses the rollback, the whole filesystem is forced read-only even though the qgroup limit was for one subvolume only. Also orphan cleanup at the next mount fails the same way, so the leftover items are never removed: with -EDQUOT the subvolume stays unreachable, and with -ENOSPC on a full filesystem the next read-write mount fails. Start transactions with btrfs_start_transaction_fallback_global_rsv() in btrfs_orphan_cleanup(), drop_verity_items() and rollback_verity(). Those calls only delete items and free the space in the end, so they may use the global reserve and skip the qgroup limit, which avoids -ENOSPC and -EDQUOT. Fixes: 146054090b08 ("btrfs: initial fsverity support") Reviewed-by: Qu Wenruo Signed-off-by: Daniel Linjama Signed-off-by: David Sterba commit cc337324cc6be1ce0ae7e5a068dcb7e99ae1b59c Author: Filipe Manana Date: Mon Sep 14 18:11:30 2026 +0100 btrfs: fix creation of compressed inline extents that don't save space If the compressed data of an inline extent is larger than or equals to the size of the uncompressed data, we are still allowing the creation of the compressed inline extent, which does not result in any benefits, quite the contrary as we waste metadata space and have to decompress when reading. This is a recent regression introduced in commit 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated delalloc helper"). It happens because we are passing the block size to btrfs_compress_bio(), so we don't get -E2BIG from the compression code anymore, but we can not pass i_size either, because if i_size is smaller than sector size, we end up never creating lzo compressed inline extent for such small i_size values. So refuse the compressed result at run_delalloc_inline() if its size is not smaller than the uncompressed size (i_size). Reported-by: Hanabishi Link: https://lore.kernel.org/linux-btrfs/c97652a5-ac6b-4de6-aa23-3cdebc01d00b@gmail.com/ Fixes: 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated delalloc helper") CC: stable@vger.kernel.org # 7.1+ Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba commit ec06546b43b612cefc851558981b4955c0ef9e46 Author: Johan Hovold Date: Tue Sep 15 14:40:12 2026 +0200 USB: serial: quatech2: fix baud rate overflow The requested baud rate is incorrectly truncated to 16 bits so that line speeds above 65535 bps cannot be set. Use 32 bits for the rate while rejecting rates outside of [50,921600] to avoid having the 16-bit divisor overflow. Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver") Cc: stable@vger.kernel.org # 3.5 Cc: Bill Pemberton Signed-off-by: Johan Hovold commit afc235a217360c6859068d2e37a4df305c4d1be2 Author: Johan Hovold Date: Tue Sep 15 14:40:11 2026 +0200 USB: serial: ssu100: fix baud rate overflow The requested baud rate is incorrectly truncated to 16 bits so that line speeds above 65535 bps cannot be set. Use 32 bits for the rate and remainder while rejecting rates outside of [50,460800] to avoid having the divisor or remainder overflow. This issue was flagged by an LLM. Fixes: 52af95459939 ("USB: add USB serial ssu100 driver") Cc: stable@vger.kernel.org # 2.6.36 Cc: Bill Pemberton Assisted-by: LLM Signed-off-by: Johan Hovold commit d84e27d87738634b92001500435ae4dadba10a13 Author: Jérémy Carrat Date: Thu Sep 10 18:26:09 2026 +0200 USB: serial: cp210x: add Corsair AX1500i Power Supply The Corsair AX1500i power supply exposes its Corsair Link monitoring interface on a mini-USB port through an on-board CP2103, using a Corsair-specific product ID. Without the ID in the table no driver binds and no tty is created. Tested by forcing the driver association with echo 1b1c 1c02 > /sys/bus/usb-serial/drivers/cp210x/new_id and then setting the serial port to 115200 8N1. Adding the ID is sufficient to talk to the device: the tty reaches a USB-to-SMBus bridge sitting behind the UART, which identifies itself as "USB to SMB Bridge (Firmware by Ross Fosler)" version 0.9 and relays PMBus reads to the power supply controller. Input voltage and current, input and output power, internal temperature and fan speed were all read back on an AX1500i. [ 7.806181] usb 3-14: New USB device found, idVendor=1b1c, idProduct=1c02, bcdDevice= 1.00 [ 698.526754] usbcore: registered new interface driver cp210x [ 698.526767] usbserial: USB Serial support registered for cp210x [ 698.527863] cp210x 3-14:1.0: cp210x converter detected [ 698.529263] usb 3-14: cp210x converter now attached to ttyUSB0 The related AX1600i (1b1c:1c11, iProduct "USB API") is expected to be the same kind of device but has not been tested here, so it is not added. Cc: stable@vger.kernel.org Signed-off-by: Jérémy Carrat Signed-off-by: Johan Hovold commit a13f7f5d14af9baf34eb12c25962f8d3542b281d Author: Ilya Titov Date: Thu Sep 3 12:17:18 2026 +0300 pinctrl: sunxi: keep a shadow copy of the data register output latches On Allwinner SoCs, reading a bank's data register returns the pin level, not the output latch, for pins that are muxed as inputs. Writing a GPIO therefore corrupts the output latches of all input-muxed pins in the same bank: the read-modify-write in sunxi_pinctrl_gpio_set() reads back their pin levels and writes those into their latches. This breaks emulated open-drain lines (e.g. a bit-banged I2C bus from i2c-gpio). Such a line is released high by muxing it as input and letting the pull-up raise it, so any concurrent GPIO write in the same bank stores 1 into its latch. Driving the line low afterwards is a non-atomic data-then-mux sequence in sunxi_pinctrl_gpio_direction_output(); if the poisoning write lands between the two steps, the pin actively drives high (push-pull) instead of low. Observed in practice as sporadic glitches on a T507 board bit-banging I2C on port E while other PE GPIOs are toggled. On a scope the failure is unmistakable: on a clock pulse where SCL should fall to GND, the line instead steps *above* its idle high level for the whole low phase — the pad drives a strong push-pull 3.3 V high, higher than the level the pull-up sustains on the loaded bus — before the next transition recovers it. The same can hit SDA, corrupting data instead of clocks. Steps to reproduce on any sunxi board with a bit-banged (i2c-gpio) bus: # background: toggle any other GPIO of the same bank, e.g. line 21 gpioset -c --toggle 100us 21=0 & # foreground: keep the bit-banged bus busy while :; do i2cdetect -y 0x50 0x57; done # watch SCL/SDA with a scope or logic analyzer: sporadic clock-low # phases driven high (above the pull-up level) instead of low The bank spinlock cannot help: the racing write is a perfectly valid whole-register RMW that faithfully writes back what the hardware returned. There are no set/clear registers on this IP to write a single bit atomically. Fix it the same way gpio-mmio handles hardware whose data register read does not return the output latch: keep a shadow copy of each bank's latches, base the read-modify-write on the shadow, and only write the register. The shadow is seeded from the hardware at probe time so pins left in output mode by the bootloader keep their state. Pins that reach output mode through the gpiolib paths write their value (and thereby their shadow bit) before the mux switch in sunxi_pinctrl_gpio_direction_output(); pins muxed to gpio_out directly through a pinmux node bypass that path, so sunxi_pmx_set() refreshes their shadow bit from the latch (readable once the pin is in output mode) to keep them driving their pre-existing level. Seeding the shadow reads the PIO registers at probe time, which requires the bus clock to be enabled. The clock was only requested at the very end of probe, after devm_pinctrl_register() had already claimed the pin hogs described in the device tree - which mux pins, and thus access registers, with the clock still gated. Move the request ahead of both. Boards whose bootloader leaves the PIO clock running are unaffected, which is why the pre-existing hog problem has gone unnoticed since commit 950707c0eb5c ("pinctrl: sunxi: add clock support"). Fixes: df7b34f4c3d2 ("pinctrl: sunxi: Fix gpio_set behaviour") Cc: stable@vger.kernel.org Signed-off-by: Ilya Titov Signed-off-by: Linus Walleij commit 2cc67425a97eead2e3248b6d5415c13b768ec295 Author: Marc Zyngier Date: Tue Sep 15 13:37:03 2026 +0100 Revert "interconnect: qcom: x1e80100: enable QoS configuration" This reverts commit 5a8b2cc36e796d595c9d97eab23c2be22805cc1c. Since the introduction of this QoS change, X1 machines based on the Purwa SoC (such as the Lenovo Mini X) take a hard reset at boot time. Other machines based on Hamoa (such as the X1E001DE Snapdragon Devkit) end-up with a similar hard reset while under load, most likely due to the PCIe ports being starved of traffic. Revert the whole thing until someone figures out what magic parameters allow QoS to work in a sensible manner, as a usable machine is somehow preferable to one that crashes efficiently. Link: https://lore.kernel.org/all/apgeBNSiP01YfNcs@google.com Link: https://lore.kernel.org/all/86ld9d4h4n.wl-maz@kernel.org Signed-off-by: Marc Zyngier Cc: Georgi Djakov Cc: Raviteja Laggyshetty Cc: Konrad Dybcio Cc: Abel Vesa Cc: Bjorn Andersson Cc: Mostafa Saleh Cc: Thorsten Leemhuis Reviewed-by: Abel Vesa Reviewed-by: Mostafa Saleh Tested-by: Mostafa Saleh Closes: https://krzk.eu/#/builders/102/builds/70/steps/23/logs/warnings__3_ Link: https://patch.msgid.link/20260915123703.3228329-1-maz@kernel.org Signed-off-by: Georgi Djakov commit f0e9f963a3d209d7dc7ddd61116118ab5da2797d Author: Raag Jadav Date: Fri Sep 11 17:45:47 2026 +0530 drm/xe/i2c: Disable IRQ on unbind Currently, struct xe_i2c is freed before SGUnit IRQ is disabled in unbind path, leaving a potential UAF in case I2C IRQ is hit during this small window. Explicitly disable I2C IRQ in xe_i2c_remove() and fix this. Fixes: 0bb78ce09926 ("drm/xe/i2c: Wire up reset/postinstall for I2C IRQ") Signed-off-by: Raag Jadav Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260911121547.2407261-1-raag.jadav@intel.com Signed-off-by: Matt Roper (cherry picked from commit 8ba5c8b8ab3fd362267c11df2cd5a90ee46f6e24) Signed-off-by: Rodrigo Vivi commit b61b6f95d6722ddbbbd09e689fa41b55fd36f9a5 Author: Peter Zijlstra Date: Fri Sep 11 11:04:47 2026 +0200 futex: Also allocate private hash on vfork() As Jann demonstrated, it is entirely feasible to access the mm through vfork(). Therefore we need to allocate a private hash on vfork() as well as any other CLONE_VM user. Specifically, it must be avoided to have (private) futex waiters before allocating the private hash. Fixes: ee9dce44362b ("futex: Drop CLONE_THREAD requirement for private default hash alloc") Reported-by: Jann Horn Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260911090447.GT788244@noisy.programming.kicks-ass.net commit ce55a6545a375563983ef83eb48915a11493b64e Merge: 869e97e66d3f5c 406292fd75f95a Author: Arnd Bergmann Date: Wed Sep 16 13:05:17 2026 +0200 Merge tag 'amlogic-fixes-v7.3-rc' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into arm/fixes Amlogic DT Fixes for v7.3: - Set of fixes for Amlogic T7: - use the real UART pclk - allow the SD card to be power cycled by dropping regulator-always-on - fix the pin groups of two PWM outputs - add the CPU cores PWM-driven supplies to fix runtime crashes - fix the pin groups of the vsync PWM using non-existing pin group * tag 'amlogic-fixes-v7.3-rc' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux: arm64: dts: amlogic: t7: fix the pin groups of the vsync PWM arm64: dts: amlogic: t7: khadas-vim4: add the PWM-driven supplies arm64: dts: amlogic: t7: fix the pin groups of two PWM outputs arm64: dts: amlogic: t7: khadas-vim4: allow the SD card to be power cycled arm64: dts: amlogic: t7: use the real UART pclk Signed-off-by: Arnd Bergmann commit a26204be587c57bd5c54fa513be26c4fd7bf252d Author: Nemesa Garg Date: Wed Sep 9 16:33:31 2026 +0530 Revert "drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable" This reverts commit 7f1172a2ac0d7e50850785e2e65789c8aac8411a. This commit replaced the crtc_state->enable_psr2_sel_fetch guard in icl_plane_disable_sel_fetch_arm() and i9xx_cursor_disable_sel_fetch_arm() with HAS_PSR2_SEL_FETCH(). This is a display version check and says nothing about the pipe, so every plane and cursor disable on a display 12+ platform started writing SEL_FETCH_PLANE_CTL() / SEL_FETCH_CUR_CTL(), including on pipes that do not implement them. It shows up as an unclaimed register access on pipes driving HDMI where selective fetch was never enabled. The stale selective fetch enable bit that commit addressed is handled in the next patch. Fixes: 7f1172a2ac0d ("drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16876 Signed-off-by: Nemesa Garg Reviewed-by: Jouni Högander Signed-off-by: Suraj Kandpal Link: https://patch.msgid.link/20260909110332.3528029-2-nemesa.garg@intel.com (cherry picked from commit d393529394167e0f5f706657eebe84d8529ce4fc) Signed-off-by: Jani Nikula commit 53cf0f26eece095a3752642151150404bc3351cc Author: Rosen Penev Date: Tue Sep 1 13:37:36 2026 -0700 crypto: caam - map job ring registers without claiming region devm_platform_ioremap_resource() ends up calling request_mem_region(), which fails with -EBUSY on i.MX SoCs: There the job rings are modelled as sub-regions of their parent fsl,sec-v4.0 register window, and caam_probe() already reserves the whole window exclusively via devm_of_iomap() before the children are populated. Every job ring therefore collides with its own parent and fails to probe, taking the hardware RNG offline (seen on i.MX6, i.MX7 and i.MX8 boards such as colibri-imx7 and verdin-imx8mp). Map the job ring registers with devm_ioremap() instead, which does not claim the (already owned) region. Fixes: 9a955c0a7d11 ("crypto: caam - simplify probe resource and IRQ handling") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Reported-by: Emanuele Ghidoli Tested-by: Emanuele Ghidoli Tested-by: Richard Leitner # i.MX8MP Tested-by: Sahil Malhotra # i.MX8MM-EVK Signed-off-by: Herbert Xu commit 703749b069d53b55f92499e088b30b031e47b8f9 Author: Karl Mehltretter Date: Wed Sep 9 08:37:44 2026 +0200 random: fix vgetrandom_opaque_params kernel-doc struct vgetrandom_opaque_params contains size_of_opaque_state, but its kernel-doc describes size_per_opaque_state. This leaves the real member undescribed and adds a nonexistent member to the generated documentation. Use the member's actual name. Fixes: 4ad10a5f5f78 ("random: introduce generic vDSO getrandom() implementation") Signed-off-by: Karl Mehltretter Signed-off-by: Jason A. Donenfeld commit 3d0a9e74ce9401c4e287df72cc75c9d4b25b4060 Author: Hemanth Selam Date: Mon Sep 7 12:27:51 2026 +0530 random: vDSO: fix repeated word 'to' in comment Drop the second 'to', reported by checkpatch.pl as a possible repeated word. Only touches a comment, no code changes. Signed-off-by: Hemanth Selam Signed-off-by: Jason A. Donenfeld commit 9a7d3340cd0f615a05c81c8f972cbffc8eb96230 Author: Randy Dunlap Date: Sun Aug 30 22:52:36 2026 -0700 siphash: clean up kernel-doc comments Use the correct function parameter names and add function return value descriptions to avoid kernel-doc warnings: Warning: include/linux/siphash.h:82 function parameter 'len' not described in 'siphash' Warning: include/linux/siphash.h:82 No description found for return value of 'siphash' Warning: include/linux/siphash.h:132 function parameter 'len' not described in 'hsiphash' Warning: include/linux/siphash.h:132 No description found for return value of 'hsiphash' Signed-off-by: Randy Dunlap Signed-off-by: Jason A. Donenfeld commit 403f45735f383eea48bae0e05744c3b610d495bb Author: Jason A. Donenfeld Date: Sun Aug 30 21:46:44 2026 -0600 virt: vmgenid: move to using dev_set/get_drvdata The prior commit moved the order of initializing driver_data around. In looking through the tree at what is normally done, it appears that actually few drivers set or get driver_data directly, but instead go through the dev_set/get_drvdata helpers, which are simple inline helpers that amount to the same exact code. So, for the sake of consistency, use the helpers. Signed-off-by: Jason A. Donenfeld commit 6c62dfd2820f0c32b0083668edbe0baca6e10b92 Author: Icenowy Zheng Date: Thu Sep 10 17:50:00 2026 +0800 drm/verisilicon: remove ARGB formats from primary plane As the blending of the primary plane is currently explicitly disabled (and it's not possible on DC8000), remove the ARGB formats from the primary plane format tables. Signed-off-by: Icenowy Zheng Reviewed-by: Thomas Zimmermann Link: https://patch.msgid.link/20260910095000.3505878-2-zhengxingda@iscas.ac.cn commit e5d43d7e924d7e1d0c815a5c7407f2a40a6dd2f2 Author: Icenowy Zheng Date: Thu Sep 10 17:49:59 2026 +0800 drm/verisilicon: add primary modifier for format tables Currently the format tables are only used for the primary plane. Add primary modifiers to names related to the tables. Signed-off-by: Icenowy Zheng Reviewed-by: Thomas Zimmermann Link: https://patch.msgid.link/20260910095000.3505878-1-zhengxingda@iscas.ac.cn commit 5a83606d9f31a38273ee803f3aae2e39247032c5 Author: Icenowy Zheng Date: Thu Sep 10 17:49:04 2026 +0800 drm/verisilicon: set blend mode for the cursor plane Blend mode properties are now required to expose pixel formats w/ alpha. Experiments show that the fixed blending mode for the cursor seems to be COVERAGE: - With a cursor plane filled with R=G=0, B=0xff, A=0x40, the cursor is visible on a pure-white background, which means the background is multiplied. - With a cursor plane filled with R=G=B=0xff, A=0x40, the cursor isn't pure white and non-white patterns can be see through, which means the cursor is multiplied. Add a fixed COVERAGE blend mode property for the cursor plane. Signed-off-by: Icenowy Zheng Reviewed-by: Thomas Zimmermann Link: https://patch.msgid.link/20260910094904.3502741-1-zhengxingda@iscas.ac.cn commit 1f7745fb3580152ca902ef181b605f33cabfb1d0 Author: Ran Hongyun Date: Mon Jul 13 19:55:25 2026 +0800 squashfs: Add dictionary size range check to prevent shift-out-of-bounds When an abnormal SquashFS image (COMP_OPTS flag is 1 but dictionary size is 0) is mounted, and performs shift operations using dictionarysize, the shift exponent is -1, causing a shift-out-of-bounds. Detail as below: squashfs_comp_opts(msblk, buffer, length) squashfs_xz_comp_opts() if (comp_opts) n = ffs(opts->dict_size) - 1;<----opts->dict_size=0, n=-1 if (opts->dict_size != (1 << n) && opts->dict_size != (1 << n) + (1 << (n + 1))) <----shift-out-of-bounds Fix it by adding a dictionary size range check before the shift operation. Fixes: ff750311d30a ("Squashfs: add compression options support to xz decompressor") Signed-off-by: Ran Hongyun Link: https://patch.msgid.link/20260713115525.2661734-1-ranhongyun1@huawei.com Reviewed-by: Phillip Lougher Reviewed-by: Zhihao Cheng Signed-off-by: Christian Brauner (Amutable) commit 0b271f7d7f5ed45bc498a03ce0aa9cfd8402fc71 Author: Shivaprasad G Bhat Date: Tue Sep 15 22:04:17 2026 +0530 powerpc/iommu: Fix the overflow validation in iommu_tce_check_ioba The commit b1af23d836f8 ("KVM: PPC: iommu: Unify TCE checking") unified IOBA parameter checking across KVM and VFIO into iommu_tce_check_ioba(). While doing so, the passed in argument npages is ignored and constant value '1' is used leaving out a possible overflow as the callers can legitimately be using npages > 1 for H_STUFF_TCE or H_PUT_TCE_INDIRECT cases. Fix this by accounting for 'npages', checking for arithmetic overflow, and verifying that the entire requested range (ioba - offset + npages) does not exceed the table capacity 'size'. Fixes: b1af23d836f8 ("KVM: PPC: iommu: Unify TCE checking") Reviewed-by: Ritesh Harjani (IBM) Tested-by: R Nageswara Sastry Signed-off-by: Shivaprasad G Bhat Signed-off-by: Gautam Menghani Signed-off-by: Madhavan Srinivasan commit 0a416ee20bcccddf91ca5b63696a23b9d11d73aa Author: Amit Machhiwal Date: Tue Sep 15 22:04:16 2026 +0530 KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure In kvmppc_svm_page_in(), if uv_page_in() fails after kvmppc_uvmem_get_page() has succeeded, the secure device page is never released. kvmppc_uvmem_get_page() sets a bit in kvmppc_uvmem_bitmap, allocates a kvmppc_uvmem_page_pvt struct, marks the GFN as KVMPPC_GFN_UVMEM_PFN, and calls zone_device_page_init() which sets refcount=1 and locks the page. The subsequent goto out_finalize skips the *mig.dst assignment, so migrate_vma_finalize() is a no-op for the page, and none of those resources are ever reclaimed. Each occurrence permanently consumes one entry from the firmware-bounded secure memory pool (kvmppc_uvmem_bitmap), leaks pvt, and leaves the GFN marked as secure — making it unusable for the lifetime of the VM. The twin __kvmppc_svm_page_out() already handles the analogous uv_page_out() failure correctly with unlock_page(dpage); __free_page(dpage). Apply the same pattern here: unlock_page() followed by put_page(), which chains through free_zone_device_folio() into kvmppc_uvmem_folio_free() to clear the bitmap bit, free pvt, and reset the GFN state. Reachable whenever uv_page_in() returns an error (e.g. UV pool exhaustion) on any POWER9/10 + Ultravisor/PEF system. Fixes: ca9f4942670c ("KVM: PPC: Book3S HV: Support for running secure guests") Reviewed-by: Ritesh Harjani (IBM) Tested-by: R Nageswara Sastry Signed-off-by: Amit Machhiwal Signed-off-by: Gautam Menghani Signed-off-by: Madhavan Srinivasan commit 51938dfa8a51a4f85328413fca9b6e21f9d2d088 Author: Amit Machhiwal Date: Tue Sep 15 22:04:15 2026 +0530 KVM: PPC: Book3S HV: fix use-after-free in kvmhv_emulate_tlbie_all_lpid() kvmhv_emulate_tlbie_all_lpid() iterates the nested-guest IDR and drops mmu_lock before calling kvmhv_emulate_tlbie_lpid(), but does not hold a reference on the kvm_nested_guest pointer obtained from the IDR. A concurrent vCPU issuing a single-LPID tlbie (is=2, ric=2) can race through kvmhv_flush_nested() -> kvmhv_remove_nested() -> idr_remove / --refcnt -> kvmhv_release_nested() -> kfree(gp) in that window, leaving the iterating vCPU with a dangling pointer. The subsequent mutex_lock(&gp->tlb_lock) and accesses to gp->shadow_pgtable, gp->shadow_lpid and gp->l1_host all touch freed memory. The free path is fully L1-controlled. Fix this by incrementing gp->refcnt inside the loop before dropping mmu_lock, mirroring what kvmhv_get_nested() does, and releasing the reference with kvmhv_put_nested() after the per-guest work completes. This is the same get/put discipline already used at every other call site that drops mmu_lock while holding a nested-guest pointer. Fixes: e3b6b4661527 ("KVM: PPC: Book3S HV: Implement H_TLB_INVALIDATE hcall") Reviewed-by: Ritesh Harjani (IBM) Tested-by: R Nageswara Sastry Signed-off-by: Amit Machhiwal Signed-off-by: Gautam Menghani Signed-off-by: Madhavan Srinivasan commit 666f12ae9f504625e5a93581d8fbcba3dd60c294 Merge: 2ab510e6319736 fd73f4a6659897 Author: Maxime Ripard Date: Wed Sep 16 09:43:25 2026 +0200 Merge fdo/drm/drm-fixes into drm-misc-fixes Backmerging to get drm-misc-fixes up to v7.3-rc3. Signed-off-by: Maxime Ripard commit c230bc2b926d137ed06cd4538dfccf57b80fb9ea Author: Mario Limonciello Date: Tue Sep 15 15:46:23 2026 -0500 Revert "thunderbolt: Add quirk to reset host interface on DMA path teardown for AMD USB4 routers" This commit has caused a deadlock at shutdown. A proper fix with another approach will be coming later. Revert commit f1de1fc5f632cdeae1f5c2984572ab710d4dfcaa for now. Reported-by: juan.martinez@amd.com Closes: https://lore.kernel.org/linux-usb/20260825214237.4179813-1-juan.martinez@amd.com/ Cc: Sanath S Cc: Basavaraj Natikar Signed-off-by: Mario Limonciello Signed-off-by: Mika Westerberg commit dbd9d1cbf9700528c8595ab1fa7ef832e79821fe Author: Nguyen Ngoc Thang Date: Tue Sep 15 23:31:10 2026 +0700 ALSA: usb-audio: fix list_add double-add in push_back_to_ready_list stop_urbs() clears ep->ready_playback_urbs with a bare INIT_LIST_HEAD() instead of unlinking each queued snd_urb_ctx. If a URB survives past wait_clear_urbs()'s forced STOPPING->STOPPED timeout, its ctx is left looking "linked" (stale next/prev) even though the list head has forgotten it. When the endpoint later restarts and re-queues that same ctx onto the (now real) ready list, and the old URB's completion handler then calls push_back_to_ready_list() for it a second time, the ctx is still the list's own tail and list_add's double-add check trips: kernel BUG at lib/list_debug.c:35 (list_add double add) Guard push_back_to_ready_list() with a list_empty() check so a still-linked ctx isn't re-added, and make stop_urbs() actually unlink each ctx via list_del_init() instead of only resetting the head, so a dropped ctx doesn't keep looking linked to that guard. Reported-by: syzbot+9fe3b8d9f5c64ff410a7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9fe3b8d9f5c64ff410a7 Signed-off-by: Nguyen Ngoc Thang Link: https://patch.msgid.link/20260915163110.58124-1-ngocthang2710.1999@gmail.com Signed-off-by: Takashi Iwai commit 2ab510e63197360945f915dd5631a77c63ac6b27 Author: Tvrtko Ursulin Date: Tue Sep 15 16:05:57 2026 +0100 drm/sched: Fix virtual runtime race Prevent pushing a new job to an entity seeing it being the first in the queue, and hence entering the drm_sched_rq_add_entity() path, if the pop side in drm_sched_entity_pop_job() has just de-queued the job but not yet updated the saved virtual time. Restoring the unsaved virtual time, which is at this point not a delta but still an absolute value, pushes the said entity to the rear of the run queue for a potentially very long time. We close this race by pulling the locked sections out to encompass both the queue push/pop and corresponding rbtree management. This is aligned with the future direction to replace the current lockless job queue with one of the fully locked standard list primitives. Signed-off-by: Tvrtko Ursulin Fixes: 2fa4d8e2c109 ("drm/sched: Add fair scheduling policy") Suggested-by: Luke.Wildhardt@proton.me # via Claude Opus Tested-by: Luke.Wildhardt@proton.me Cc: Christian König Cc: Danilo Krummrich Cc: Philipp Stanner Cc: Pierre-Eric Pelloux-Prayer Cc: Matthew Brost Cc: Vitaly Prosyak Cc: stable@vger.kernel.org # v7.2+ [phasta: commit title] Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260915150557.62847-1-tvrtko.ursulin@igalia.com commit ad34235808b63a70ca4989b7a2852923193d06ef Author: Linkai Gong Date: Mon Sep 7 15:11:02 2026 +0800 i2c: atr: fix dangling adapter pointer on add failure i2c_atr_add_adapter() stores atr->adapter[chan_id] before i2c_add_adapter() so that the I2C bus notifier can match child clients during registration. On failure the channel is freed but the slot was left pointing at freed memory, which can lead to use-after-free in i2c_atr_del_adapter() / cleanup and also block reuse with -EEXIST. Clear the slot on the i2c_add_adapter() error path before freeing chan. Fixes: a076a860acae ("media: i2c: add I2C Address Translator (ATR) support") Signed-off-by: Linkai Gong Cc: # v6.6+ Reviewed-by: Andy Shevchenko Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260907071102.1080840-1-gonglinkai@kylinos.cn commit 0d1cb83337f13af082afb68b28d3fdfe29cde7fb Author: Wentao Liang Date: Tue Sep 15 06:59:33 2026 +0000 ata: libahci_platform: Fix device reference leak in ahci_platform_get_resources() of_find_device_by_node() takes a reference on the port platform device, which is only used to look up its port regulator and is never released, neither on success nor on the error paths. Drop the reference with put_device() once the regulator has been obtained, which covers both the success and error paths. Fixes: c7d7ddee7e24 ("ata: libahci: Allow using multiple regulators") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://lore.kernel.org/r/20260915065933.1733061-1-vulab@iscas.ac.cn Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel commit e0c3e9d76adbe522dd420a766ce42d03ce887c29 Author: Guangshuo Li Date: Mon Sep 14 17:15:44 2026 +0800 i2c: imx: disable autosuspend on remove i2c_imx_probe() enables runtime PM autosuspend with pm_runtime_use_autosuspend(). The probe error path correctly undoes this setting with pm_runtime_dont_use_autosuspend(), but the normal remove path only disables runtime PM. The runtime PM API requires pm_runtime_use_autosuspend() to be undone with pm_runtime_dont_use_autosuspend() at driver exit unless runtime PM was enabled with devm_pm_runtime_enable(). Leaving the autosuspend flag set therefore leaves the runtime PM state incompletely cleaned up after the driver is unbound. Add the missing pm_runtime_dont_use_autosuspend() call to the remove path. This issue was found by manual code inspection. Fixes: 588eb93ea49f ("i2c: imx: add runtime pm support to improve the performance") Signed-off-by: Guangshuo Li Cc: # v4.5+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260914091544.1667137-1-lgs201920130244@gmail.com commit 78fc54b934bfb2c18aad8154c7302067146946f9 Author: Karl Mehltretter Date: Sat Aug 29 23:32:56 2026 +0200 selinux: recheck intermediate backing files on mprotect() mprotect() can be used to bypass the SELinux checks that mmap() performs against the intermediate layers of a stacked filesystem. mmap() checks every backing layer as the request descends through the stack. mprotect() only has the lowest backing file in vma->vm_file, so it rechecks the top-level user and the lowest mounter, but skips the mounters of every layer in between. With two nested overlayfs mounts and a policy denying mounter_t -> middle_file_t:file { execute }, a direct mmap(PROT_EXEC) is denied: avc: denied { execute } for pid=71 comm="nested_exec" path="/payload" dev="overlay" ino=9 scontext=user_u:base_r:mounter_t tcontext=user_u:object_r:middle_file_t tclass=file permissive=0 while mmap(PROT_NONE) followed by mprotect(PROT_EXEC) succeeds. Preserve each intermediate path, mounter SID and file-description SID in the backing-file security blob, copying the saved entries when another backing layer is opened. Allocate the array only for nested backing files, and release it and the path references in the backing_file_free hook. During mprotect(), recheck fd { use } and the requested inode permissions for every saved mounter, and include the intermediate layers in the execmod checks. Policy for nested stacking may then need to grant intermediate mounters what a direct mmap() already requires, and execmod on intermediate labels for binaries using text relocations. Tested on arm64 QEMU with a small BusyBox initramfs and a purpose-built SELinux policy, on a mainline tree containing commit f2381b546e7e ("fs: fix user path of nested backing files"). Cc: stable@vger.kernel.org Fixes: 82544d36b172 ("selinux: fix overlayfs mmap() and mprotect() access checks") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Stephen Smalley [PM: subject tweak] Signed-off-by: Paul Moore commit 8c0c602202b9a4909b00bc3354e3c0355bc69e65 Author: Karl Mehltretter Date: Sat Aug 29 23:32:55 2026 +0200 selinux: preserve user SID across nested backing files SELinux saves the user file SID in a backing-file security blob so it remains available after mmap() replaces vma->vm_file with a backing file. For nested backing files (overlayfs over overlayfs, or FUSE passthrough backed by overlayfs), user_file may itself be a backing file. Its fsec->sid is the SID of the mounter that opened it, rather than the user that opened the top-level file. mprotect() then checks fd { use } against the mounter SID. This can incorrectly deny access without a domain transition, or check the wrong target SID after one. Copy the saved user SID when user_file is a backing file. Keep using the regular file SID for the first backing layer. With two nested overlayfs mounts and SELinux enforcing, mprotect(PROT_READ) returns EACCES with an fd { use } denial against the mounter SID. With this change, mprotect() succeeds. Tested on arm64 QEMU with a small BusyBox initramfs and a purpose-built SELinux policy. The original test was also repeated with Fedora Cloud Base 44 userspace and gave the same result. Cc: stable@vger.kernel.org Fixes: 82544d36b172 ("selinux: fix overlayfs mmap() and mprotect() access checks") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Amir Goldstein Reviewed-by: Stephen Smalley Signed-off-by: Paul Moore commit 278210c60c6f6958bd2eeaa2120c862683b83d09 Author: Arnd Bergmann Date: Tue Sep 15 22:20:59 2026 +0200 scsi: leapraid: Avoid -Wformat-security warning When extra warnings are enabled, the alloc_ordered_workqueue() function cannot be called with a variable name for the format string: drivers/scsi/leapraid/leapraid_os.c: In function 'leapraid_probe': drivers/scsi/leapraid/leapraid_os.c:2062:58: error: format not a string literal and no format arguments [-Werror=format-security] 2062 | alloc_ordered_workqueue(adapter->fw_evt_s.fw_evt_name, 0); | ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~ As the string is only assembled before the call and not used anywhere else, just fold the earlier snprintf() into the alloc_ordered_workqueue() call. Fixes: 5597088c9e79 ("scsi: leapraid: Add new SCSI driver") Signed-off-by: Arnd Bergmann Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/20260915202134.3534708-1-arnd@kernel.org Signed-off-by: Martin K. Petersen (Oracle) commit f06a44e235ef188689ba23ffc72e9e89b10951a9 Author: Ewan D. Milne Date: Tue Sep 15 13:38:00 2026 -0400 scsi: devinfo: Add BLIST_SKIP_IO_HINTS for EMC Symmetrix EMC Symmetrix returns an error on MODE SENSE for page 0Ah subpage 05h because it does not implement the SBC-5 I/O hints. These commands began to be sent as a result of commit 4f53138fffc2 ("scsi: sd: Translate data lifetime information"). Add BLIST_SKIP_IO_HINTS to avoid sending these commands because in large configurations the failed commands are displacing other useful information in internal error logs. Signed-off-by: Ewan D. Milne Link: https://patch.msgid.link/20260915173800.39117-1-emilne@redhat.com Signed-off-by: Martin K. Petersen (Oracle) commit bce07e2f37b5e4a427d36fd6b1c14067b27591db Author: Yehyeong Lee Date: Sat Aug 1 22:36:35 2026 +0900 scsi: libiscsi_tcp: Check the data direction of a Data-In PDU The Data-In branch of iscsi_tcp_hdr_dissect() resolves the ITT to a task and copies the PDU's data segment into that command's scatterlist without asking whether the command was reading. iscsi_tcp_r2t_rsp() in the same file does ask, and rejects an R2T for a command that is not DMA_TO_DEVICE. A target that answers a WRITE command's ITT with a Data-In therefore has the initiator write target-supplied bytes into the pages that write was about to send. Those are the caller's own pinned pages for an O_DIRECT write, and page cache pages for a buffered one. Observed against a test target that emits one 512-byte Data-In naming a 128 KB write's ITT, after the R2T for that write. With O_DIRECT the caller's buffer ends up holding 512 bytes of the target's data while pwrite() returns 131072. Buffered is quieter: pwrite() and fsync() both succeed, nothing is logged, and reading those blocks back returns the target's bytes out of the page cache without a command going on the wire. Check the direction before using the scatterlist, the way the R2T path already does. Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Reviewed-by: Mike Christie Link: https://patch.msgid.link/20260801133635.1986706-1-yhlee@isslab.korea.ac.kr Fixes: a081c13e39b5 ("[SCSI] iscsi_tcp: split module into lib and lld") Signed-off-by: Martin K. Petersen (Oracle) commit c9ee6511332687ea714ad8ab86a53cb837d86eea Author: Geert Uytterhoeven Date: Mon Sep 14 16:00:01 2026 +0200 scsi: ufs: pltfrm: Add quirk for R-Car S4 lacking lanes-per-direction Since commit e72323f3b09f ("scsi: ufs: core: Configure only active lanes during link"), the following error is observed on R-Car S4: ufshcd-renesas e6860000.ufs: Tx lane mismatch [config,reported] [2,1] ufshcd-renesas e6860000.ufs: link startup failed -67 ufshcd-renesas e6860000.ufs: error -ENOLINK: Initialization failed with error -67 ufshcd-renesas e6860000.ufs: probe with driver ufshcd-renesas failed with error -67 R-Car S4 has one UFS lane per direction, as described in section 152.1 of its hardware manual. Without lanes-per-direction, the UFS platform driver defaults to two lanes. Previously, the core used PA_CONNECTEDRXDATALANES and PA_CONNECTEDTXDATALANES to configure the link without checking them against lanes-per-direction, so the missing property did not prevent initialization. While fixing the R-Car S4 DTS is the proper solution, doing only that would still break backwards compatibility with existing DTBs. Hence add a quirk to let lanes-per-direction default to one on R-Car S4. Fixes: e72323f3b09f9c89 ("scsi: ufs: core: Configure only active lanes during link") Reported-by: Koichiro Den Closes: https://lore.kernel.org/20260911073058.253000-1-den@valinux.co.jp Cc: stable@vger.kernel.org # 7.2+ Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/ae0cc2bd764e6dfffce99db3d8b44a55887c508c.1789394185.git.geert+renesas@glider.be Signed-off-by: Martin K. Petersen (Oracle) commit ceac0de741bfb47ca255eee075257b3bb31f0651 Author: Eric Dumazet Date: Fri Sep 11 16:08:04 2026 +0000 netlink: do not free nlk->groups while lockless readers can use it netlink_realloc_groups() uses krealloc() under netlink_table_grab(). Whenever NLGRPSZ(groups) lands in a different kmalloc bucket, the old bitmap is freed immediately. Two readers of nlk->groups / nlk->ngroups do not hold the netlink table lock: 1) sk_diag_dump_groups(). Hashed (bound) sockets are dumped from the rhashtable walk in __netlink_diag_dump(), which only holds RCU. Only the mc_list part of the dump takes nl_table_lock. 2) netlink_native_seq_show() (/proc/net/netlink), whose walk has been lockless since commit 21e4902aea80 ("netlink: Lockless lookup with RCU grace period in socket release"). Both can read a freed buffer, and sk_diag_dump_groups() can also read past the end of the old (smaller) buffer if it happens to load the old @groups pointer together with the new @ngroups value, copying the result into a NETLINK_DIAG_GROUPS attribute. This is the same class of bug that commit f773608026ee ("netlink: access nlk groups safely in netlink bind and getname") fixed for bind() and getname(); these two readers were missed. Simply grabbing the table lock in sk_diag_dump_groups() is not an option, because it is also called with nl_table_lock already held from the mc_list section of the dump. Make the lockless readers safe instead: - Allocate a new bitmap and free the old one after an RCU grace period, instead of relying on the implicit kfree() done by krealloc(). - Publish @groups before @ngroups, both with release semantics, and have the lockless readers load @ngroups first. A reader can then never pair the new (bigger) size with the old (smaller) buffer, and a reader picking up the new pointer while still seeing the old size is guaranteed to see the initialized bitmap. netlink_realloc_groups() is called from process context (bind() and setsockopt()), so kfree_rcu_mightsleep() can be used, once the table has been released. Fixes: 21e4902aea80 ("netlink: Lockless lookup with RCU grace period in socket release") Fixes: ad202074320c ("netlink: Use rhashtable walk interface in diag dump") Reported-by: James Burton Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260911160804.917099-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit b52d695d062095327b944acf7daabbc816ab319b Author: Stanley Jhu Date: Sat Sep 12 21:16:25 2026 +0800 scsi: ufs: core: Keep internal commands dispatchable during error handling Commit 08b12cda6c44 ("scsi: ufs: core: Switch to scsi_get_internal_cmd()") switched UFS internal commands to allocate requests on hba->host->pseudo_sdev->request_queue, which shares the host tagset with regular LUNs. During error recovery, ufshcd_err_handling_prepare() calls blk_mq_quiesce_tagset(&hba->host->tag_set), marking all queues in the tagset as quiesced, including pseudo_sdev->request_queue. When ufshcd_verify_dev_init() subsequently issues internal commands (e.g. NOP OUT UPIU) via blk_execute_rq(), blk_mq_run_hw_queue() skips running the quiesced queue, resulting in an unrecoverable circular wait deadlock. Keep quiescing the tagset and unquiesce the pseudo SCSI device on top of that, so internal commands stay dispatchable while the logical units remain quiesced. Re-quiesce the pseudo device before unquiescing the tagset so that quiesce_depth stays balanced. Clock scaling and ufshcd_pause_command_processing() are unaffected: they keep quiescing the whole tagset, internal commands included. Fixes: 08b12cda6c44 ("scsi: ufs: core: Switch to scsi_get_internal_cmd()") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/6f78c4bd-a70b-402d-abfd-599091b67674@acm.org/ Signed-off-by: Stanley Jhu Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260912131625.2301486-1-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) commit 2842ce397dd09882530b42f7fdb0c855767eb24e Author: Nikolay Aleksandrov Date: Mon Sep 14 13:52:58 2026 +0300 net: bridge: vlan: fix bugs caused by switchdev deletion errors Allowing switchdev to prevent vlan deletion and error out in __vlan_del could cause multiple different issues - inconsistent state, memory leaks when flushing, NULL pointer dereference on bridge error when flushing. It doesn't make sense to allow it to stop __vlan_del, so log the error and continue with software vlan deletion. This is also consistent with 8021q behaviour. Suggested-by: Ido Schimmel Fixes: bf361ad38165 ("net: bridge: check __vlan_vid_del for error") Fixes: 5454f5c28eca ("net: bridge: vlan: check for errors from __vlan_del in __vlan_flush") Fixes: 2594e9064a57 ("bridge: vlan: add per-vlan struct and move to rhashtables") Fixes: 9c86ce2c1ae3 ("net: bridge: Notify about bridge VLANs") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260914105258.3436918-1-razor@blackwall.org Signed-off-by: Jakub Kicinski commit f0ef4b1eaed000a304726a43091588e8426ba08a Author: Lorenzo Bianconi Date: Mon Sep 14 09:41:07 2026 +0200 net: stmmac: do not overwrite phc_index when no PTP clock is registered stmmac_get_ts_info() reports phc_index as 0 when hardware timestamping is supported but no PTP clock has been registered yet (e.g. while the interface is down). Zero is a valid PHC index and would make userspace resolve the wrong clock; the absence of a clock should be reported as -1. The ethtool core already initializes phc_index to -1 before invoking the get_ts_info callback (ethtool_init_tsinfo()), so just drop the erroneous assignment. Fixes: 9364fa7fcf12 ("net: stmmac: Remove setting of RX software timestamp") Reviewed-by: Maxime Chevallier Reviewed-by: Rahul Rameshbabu Signed-off-by: Lorenzo Bianconi Reviewed-by: Gal Pressman Link: https://patch.msgid.link/20260914-stmmac-fix-phc_index-v2-1-bf3d90373fe4@oss.qualcomm.com Signed-off-by: Jakub Kicinski commit 3f118c8217c109fd13ca61caa301d72c483897ef Author: Zhiling Zou Date: Sat Sep 12 21:22:43 2026 +0800 openvswitch: avoid reallocating confirmed conntrack labels ovs_ct_get_conn_labels() adds the labels extension when a conntrack entry does not have one. Confirmed conntracks can be read locklessly, so adding an extension may reallocate and free the extension block while another CPU accesses it. Only add the extension for unconfirmed conntracks. A confirmed conntrack without labels now fails the caller's label operation instead of reallocating its extension storage. Fixes: c2ac66735870 ("openvswitch: Allow matching on conntrack label") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Reviewed-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/372fbb062b40ae6723684f55484be86ff0064f8e.1789218015.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski commit ad77dba64dc1a522014b2cd7376a67004140375b Merge: 455ebeadf714f5 439f392084f8f7 Author: Jakub Kicinski Date: Tue Sep 15 17:58:36 2026 -0700 Merge branch 'net-drop_monitor-fix-concurrency-issues-preemption-warning-and-buffer-overrun' Eric Dumazet says: ==================== net: drop_monitor: fix concurrency issues, preemption warning, and buffer overrun This series addresses several issues discovered in the drop_monitor subsystem: Patch 1 adds missing tracepoint unregistration synchronization to the net_dm_trace_on_set() error unwind path, preventing in-flight probes from scheduling work after the module reference has been dropped. Patch 2 resolves a race condition during monitoring teardown where per-CPU timers can be re-armed after deletion if a concurrent worker encounters a memory allocation failure, switching to timer_shutdown_sync(). Patch 3 fixes a CONFIG_DEBUG_PREEMPT warning reported by syzbot when kfree_skb() is invoked from preemptible process context, using raw_cpu_ptr() since each per-CPU queue is safely protected by its own spinlock. Patch 4 fixes an out-of-bounds write in reset_per_cpu_data() where memset() overwrote the allocated SKB tailroom by sizeof(struct nlattr) bytes. ==================== Link: https://patch.msgid.link/20260910204612.3762015-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit 439f392084f8f7f59ab9d47a9579185accefe1d8 Author: Eric Dumazet Date: Thu Sep 10 20:46:12 2026 +0000 drop_monitor: fix out-of-bounds write in reset_per_cpu_data() In reset_per_cpu_data(), al is computed as: al = sizeof(struct net_dm_alert_msg); al += dm_hit_limit * sizeof(struct net_dm_drop_point); al += sizeof(struct nlattr); skb = genlmsg_new(al, GFP_KERNEL); ... nla = nla_reserve(skb, NLA_UNSPEC, sizeof(struct net_dm_alert_msg)); ... msg = nla_data(nla); memset(msg, 0, al); Because al includes sizeof(struct nlattr) (the 4-byte attribute header), genlmsg_new() allocates al bytes of tailroom starting at nla. However, msg points to nla_data(nla), which is located sizeof(struct nlattr) bytes past nla. Calling memset(msg, 0, al) therefore writes al bytes starting from msg, exceeding the allocated buffer by sizeof(struct nlattr) (4 bytes) and corrupting skb_shared_info. Fix this by letting al represent only the payload length, allocating the skb with genlmsg_new(nla_total_size(al), GFP_KERNEL), and zeroing al bytes from msg. Fixes: 683703a26e46 ("drop_monitor: Update netlink protocol to include netlink attribute header in alert message") Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260910204612.3762015-5-edumazet@google.com Signed-off-by: Jakub Kicinski commit c19b7d35086b7d240f1ca3088b0079d2bd39ffb9 Author: Eric Dumazet Date: Thu Sep 10 20:46:11 2026 +0000 drop_monitor: use raw_cpu_ptr() in tracepoint probes syzbot reported a preemption warning in sk_skb_reason_drop(): BUG: using smp_processor_id() in preemptible [00000000] code: syz.0.17/5917 caller is net_dm_packet_trace_kfree_skb_hit+0x119/0x350 net/core/drop_monitor.c:519 In net_dm_packet_trace_kfree_skb_hit(), data = this_cpu_ptr(&dm_cpu_data) is evaluated before spin_lock_irqsave(&data->drop_queue.lock, flags). When kfree_skb() is called from preemptible context (e.g. process context during close() on /dev/net/tun), preemption is enabled, triggering the CONFIG_DEBUG_PREEMPT warning in smp_processor_id(). The same pattern exists in net_dm_hw_trap_summary_probe() and net_dm_hw_trap_packet_probe() for dm_hw_cpu_data. This is a false positive because each per-cpu structure is protected by its own spinlock. If the task migrates to another CPU right after reading the per-cpu pointer, the lock still safely synchronizes access to that queue. Use raw_cpu_ptr() instead of this_cpu_ptr() to silence CONFIG_DEBUG_PREEMPT without disturbing interrupt state or breaking PREEMPT_RT locking semantics. Fixes: ca30707dee2b ("drop_monitor: Add packet alert mode") Fixes: 5855357cd40e ("drop_monitor: Prepare probe functions for devlink tracepoint") Reported-by: syzbot+dc57fd6722deb17e92af@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6aa316b2.f81106d8.2ab401.0014.GAE@google.com/ Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260910204612.3762015-4-edumazet@google.com Signed-off-by: Jakub Kicinski commit c391a40f71886b28c082b47270f0e856fa3e1150 Author: Eric Dumazet Date: Thu Sep 10 20:46:10 2026 +0000 drop_monitor: use timer_shutdown_sync() to prevent timer rearming during teardown In drop_monitor teardown paths (net_dm_trace_off_set(), net_dm_hw_monitor_stop(), and error unwind paths in net_dm_trace_on_set() and net_dm_hw_monitor_start()), per-CPU timers are stopped using timer_delete_sync() followed by cancel_work_sync(). However, there is a circular dependency between send_timer and dm_alert_work: 1) sched_send_work() (timer callback) schedules dm_alert_work. 2) send_dm_alert() / net_dm_hw_summary_work() calls reset_per_cpu_data() or net_dm_hw_reset_per_cpu_data(). 3) If memory allocation fails under memory pressure in the reset function, it re-arms the timer via mod_timer(&data->send_timer, ...). If dm_alert_work is running concurrently while timer_delete_sync() executes on another CPU, an allocation failure in the worker will re-arm the timer after timer_delete_sync() has already returned. Once cancel_work_sync() completes and module_put() is called, the timer remains active in the timer wheel. If the module is then unloaded, the timer will fire and execute sched_send_work() in freed memory, triggering a kernel panic / use-after-free. Switch from timer_delete_sync() to timer_shutdown_sync(). This guarantees that any in-flight timer handler has finished and prevents subsequent re-arming attempts from running workers from succeeding. When monitoring is restarted later, timer_setup() is invoked, which cleanly re-initializes the timer. Fixes: 9398e9c0b1d4 ("drop_monitor: Perform cleanup upon probe registration failure") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260910204612.3762015-3-edumazet@google.com Signed-off-by: Jakub Kicinski commit 6a038ef2b57922b6d9ca98ddac0df0681849b704 Author: Eric Dumazet Date: Thu Sep 10 20:46:09 2026 +0000 drop_monitor: synchronize tracepoint unregistration on error path If register_trace_napi_poll() fails in net_dm_trace_on_set(), unregister_trace_kfree_skb() is called to roll back the kfree_skb tracepoint registration. However, tracepoint_synchronize_unregister() is omitted before calling cancel_work_sync() and module_put(). An in-flight probe executing concurrently on another CPU could call schedule_work() after cancel_work_sync() has already returned, leaving a pending work item scheduled after the module reference is dropped. If the module is then unloaded, executing the work item triggers a kernel panic. Add tracepoint_synchronize_unregister() after unregister_trace_kfree_skb() in the error path, matching net_dm_trace_off_set() and net_dm_hw_probe_unregister(). Fixes: 7c747838a558 ("drop_monitor: Split tracing enable / disable to different functions") Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260910204612.3762015-2-edumazet@google.com Signed-off-by: Jakub Kicinski commit 455ebeadf714f51e1dbbd6a022c74c9215b1cd76 Author: Gris Ge Date: Sun Sep 13 17:08:50 2026 +0800 net: ip_tunnel: initialize `options_len` before referencing options The following command triggers a kernel panic: ip link add d0 type dummy; ip link set d0 up ip route add 10.30.0.0/16 \ encap ip id 300 geneve_opts 4660:66:11223344 dev d0 memcpy: detected buffer overflow: 4 byte write of buffer size 0 kernel BUG at lib/string_helpers.c:1044! ... ip_tun_parse_opts.part.0.cold+0x10/0x10 ip_tun_build_state+0x116/0x2a0 On kernels built with GCC 15+ and `CONFIG_FORTIFY_SOURCE`, the fortified `memcpy()` got 0 sized destination with request of 4 bytes length: static int ip_tun_parse_opts_geneve(...) { ... attr = tb[LWTUNNEL_IP_OPT_GENEVE_DATA]; data_len = nla_len(attr); /* == 4 */ struct geneve_opt *opt = ip_tunnel_info_opts(info) + opts_len; memcpy(opt->opt_data, nla_data(attr), data_len); /* ^^^^^^^^^^^^^ 0 since options_len is assigned afterwards */ Fixed by initializing the counter before the options are referenced. Matching what `tunnel_key_opts_set()` already does. Fixes: bb5e62f2d547 ("net: Add options as a flexible array to struct ip_tunnel_info") Cc: stable@vger.kernel.org Signed-off-by: Gris Ge Reviewed-by: Hangbin Liu Reviewed-by: Gustavo A. R. Silva Link: https://patch.msgid.link/20260913090851.468216-1-cnfourt@gmail.com Signed-off-by: Jakub Kicinski commit ecc7253683a3c55caa868ce0ee530fcb0044bd3c Author: Eric Dumazet Date: Sat Sep 12 23:30:48 2026 +0000 pppoatm: ensure a writable skb header and linear data In pppoatm_send(), LLC encapsulation checks whether there is sufficient headroom for the 4-byte LLC header, but does not ensure that the skb header is writable. Normal transmit packets passing through ppp_start_xmit() have their header unshared via skb_cow_head(). However, packets can also reach pppoatm_send() via PPP channel bridging (PPPIOCBRIDGECHAN) without going through ppp_start_xmit(). Use skb_cow_head() to ensure both sufficient headroom and a writable header before pushing the LLC header. While at it: - Call pskb_may_pull(skb, 1) before inspecting skb->data[0] to prevent out-of-bounds reads on zero-length or non-linear frames (e.g. from bridging). - Defer SC_COMP_PROT protocol compression until after pppoatm_may_send() succeeds. This eliminates the temporary skb allocation on admission failure and completely removes the fragile "undo" heuristic at the nospace label, avoiding any risk of reading uninitialized headroom or performing an unbalanced skb_push(). Fixes: 4cf476ced45d ("ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls") Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260912233048.3977192-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit 562219874cba1be6b708fb29a89fe8f54544b022 Merge: 15989abd74f16f 14c5eb685cdefb Author: Jakub Kicinski Date: Tue Sep 15 17:03:13 2026 -0700 Merge branch 'net-sched-fix-action-batch-deletion-cleanup' Xuanqiang Luo says: ==================== net/sched: fix action batch deletion cleanup Batched RTM_DELACTION requests can leak references to unprocessed actions when deletion stops at a filter-bound action. Patch 1 fixes the failure cleanup. Patch 2 adds tc-testing regression coverage. Failure reproduction (key output excerpts): python3 tdc.py -f /root/tc-testing/batch-delete.json not ok 1 d710 - Release tail references after first action deletion fails Could not match regex pattern. Verify command output: [...] index 2 ref 2 bind 0 [...] index 3 ref 2 bind 0 not ok 2 d711 - Release tail references after middle action deletion fails Could not match regex pattern. Verify command output: [...] index 3 ref 2 bind 0 not ok 3 d713 - Delete a tail action once after a failed batch Could not match regex pattern. Verify command output: total acts 2 [...] index 2 ref 1 bind 0 ==================== Link: https://patch.msgid.link/20260910093413.34509-1-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski commit 14c5eb685cdefbd32e73d2723071ecbd8effbce9 Author: Xuanqiang Luo Date: Thu Sep 10 17:34:13 2026 +0800 selftests: tc-testing: test action batch deletion failure cleanup Add tests for cleanup after a batched RTM_DELACTION request fails at a gact action bound to a filter. Check that subsequent actions retain their original reference counts and that earlier successful deletions are preserved. Cover failures at the first and middle entries. Verify that a remaining unbound action can be removed with one subsequent delete. Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260910093413.34509-3-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski commit 6e05e46fa821a5c1b281355f1f622ac76cb6080a Author: Xuanqiang Luo Date: Thu Sep 10 17:34:12 2026 +0800 net/sched: act_api: release tail references on DELACTION failure A batched RTM_DELACTION request takes a temporary reference on each action before attempting any deletion. tcf_action_delete() clears each processed slot and drops its temporary reference before attempting the deletion. If deletion fails, tca_action_gd() calls tcf_action_put_many() to release the remaining references, but its tcf_act_for_each_action() iterator stops at the first NULL slot. When a batch stops at an action bound to a filter, this leaks a reference on each subsequent action. A later delete of an unbound action can then return success without removing it from the IDR. Walk the full array in tcf_action_put_many() and skip NULL slots to release the references held on the unprocessed actions. Fixes: a0e947c9ccff ("net/sched: act_api: avoid non-contiguous action array") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260910093413.34509-2-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski commit 15989abd74f16f44bf953d056b95f1d2fda9b0cd Author: Lorenzo Bianconi Date: Fri Sep 11 11:20:15 2026 +0200 net: stmmac: fix TSO header length truncation stmmac_tso_xmit() stores the protocol header length returned by stmmac_tso_header_size() in a u8. stmmac_tso_valid_packet() admits headers up to 1023 bytes, so a header longer than 255 bytes wraps modulo 256 (486 becomes 230, 256 becomes 0). A TCP over IPv6 socket carrying a few hundred bytes of sticky destination/hop-by-hop options makes skb_tcp_all_headers() exceed 255 while staying below the 1023-byte limit, so such an skb reaches stmmac_tso_xmit(). Widen proto_hdr_len to unsigned int, which is sufficient since the value is bounded by the hardware limit, and adjust the debug print specifier accordingly. Fixes: 9edfa7dab811 ("net: stmmac: enable TSO for IPv6") Signed-off-by: Lorenzo Bianconi Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260911-stmmac-fix-header-length-v1-1-8fc103334327@oss.qualcomm.com Signed-off-by: Jakub Kicinski commit 433cfc302561bc7e23b1305e1779e0d83156cb61 Merge: c5e367a8a3f939 b645ccd410547d Author: Jakub Kicinski Date: Tue Sep 15 16:45:06 2026 -0700 Merge branch 'af_unix-fix-inconsistent-scc_index' Kuniyuki Iwashima says: ==================== af_unix: Fix inconsistent scc_index. James Burton reported that a single SCC could have multiple scc_index and unix_vertex_dead() fails to detect a dead SCC. Patch 1 fixes it and Patch 2 adds a test case. ==================== Link: https://patch.msgid.link/20260912030852.1467872-1-kuniyu@google.com Signed-off-by: Jakub Kicinski commit b645ccd410547d0e0e4a9543f828119e24dc7635 Author: Kuniyuki Iwashima Date: Sat Sep 12 03:07:52 2026 +0000 selftest: af_unix: Add test case with mixed lowpoint in scm_rights.c. The new test case creates two SCCs so that each of them has multiple scc_index. Without patch, GC cannot free the sockets and the test fails. # RUN scm_rights.dgram.mixed_lowpoints ... # scm_rights.c:176:mixed_lowpoints:Expected 0 (0) == ret (12) # mixed_lowpoints: Test terminated by assertion # FAIL scm_rights.dgram.mixed_lowpoints not ok 5 scm_rights.dgram.mixed_lowpoints ... # FAILED: 45 / 50 tests passed. # Totals: pass:45 fail:5 xfail:0 xpass:0 skip:0 error:0 With the patch, all tests pass. # PASSED: 50 / 50 tests passed. # Totals: pass:50 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by: Kuniyuki Iwashima Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260912030852.1467872-3-kuniyu@google.com Signed-off-by: Jakub Kicinski commit 4a4263dfeabad72f95e8ab6e15146861fa4144dd Author: Kuniyuki Iwashima Date: Sat Sep 12 03:07:51 2026 +0000 af_unix: Unify scc_index when finalising SCC in __unix_walk_scc(). Commit bfdb01283ee8 ("af_unix: Assign a unique index to SCC.") changed Tarjan's algorithm to update lowlink with lowlink, which is called lowpoint (unix_vertex.scc_index). unix_vertex_dead() assumes all vertices in an SCC share the same lowpoint, but this is not always true if an SCC has two or more back edges, depending on the order of DFS. For example, the graph below has two back edges from B to A and from C to B. A --> B --> C ^ | ^ | `----' `----' If DFS walks through A -> B -> C -> B (-> C -> B) -> A (-> B -> A), each index and scc_index will be updated as follows. A --> B --> C C = (3, 3) (index, scc_index) B = (2, 2) A = (1, 1) A ... B ... C C = (3, 2)<-. ^ | B = (2, 2) -' `----' A = (1, 1) A ... B ... C C = (3, 2) ^ | . . B = (2, 1)<-. `----' .... A = (1, 1) -' Then, unix_vertex_dead() thinks that B is passed to another SCC with scc_index 2, and the SCC is not garbage-collected. This does not happen if DFS walks in a different order below or starts from B. 1 3 A --> B --> C ^ | ^ | `----' `----' 2 4 Let's unify scc_index across the SCC when finalising it. Note that updating v->index was previously done in unix_scc_dead(), when called from __unix_walk_scc(), just to save one loop. Since __unix_walk_scc() now iterates over the SCC anyway, the update is moved back to __unix_walk_scc() and 'fast' argument is dropped. Fixes: 4090fa373f0e ("af_unix: Replace garbage collection algorithm.") Reported-by: James Burton Signed-off-by: Kuniyuki Iwashima Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260912030852.1467872-2-kuniyu@google.com Signed-off-by: Jakub Kicinski commit c5e367a8a3f939e9935369a38ea7e0f872f594b5 Merge: 83a945a529d6e0 801fb950cae704 Author: Jakub Kicinski Date: Tue Sep 15 16:40:55 2026 -0700 Merge tag 'for-net-2026-09-15' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: Core: - hci: put the peer's on-air address on air when we cannot resolve - hci: keep dst_type with dst when reusing an LE connection - hci_core: Fix queuing tx_work after workqueue is drained - hci_sync: Serialize local codec list cleanup - hci_codec: validate vendor codec count length - eir: validate service data length before reading UUID - RFCOMM: avoid socket lock inversion in listener cleanup - ISO: Fix parent socket leak in iso_conn_ready() - ISO: set BT_LISTEN before requesting a BIG sync - coredump: Quiesce dump work on unregister Drivers: - btintel_pcie: validate TX skb length in send_sync - btmtk: fix wrong status for short WMT FUNC_CTRL events - btmtksdio, btmtkuart: validate WMT event length before struct access - hci_qca: Do not write to the serial port after it is closed - btusb: fix NXP IW610 composite device handling - btintel_pcie: fix off-by-one bounds check in RX submit - btmtksdio: Fix PM runtime reference leak in shutdown * tag 'for-net-2026-09-15' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup Bluetooth: keep dst_type with dst when reusing an LE connection Bluetooth: btintel_pcie: fix off-by-one bounds check in RX submit Bluetooth: btmtksdio: Fix PM runtime reference leak in shutdown Bluetooth: btmtksdio, btmtkuart: validate WMT event length before struct access Bluetooth: btmtk: fix wrong status for short WMT FUNC_CTRL events Bluetooth: ISO: set BT_LISTEN before requesting a BIG sync Bluetooth: ISO: Fix parent socket leak in iso_conn_ready() Bluetooth: hci_sync: Serialize local codec list cleanup Bluetooth: hci_qca: Do not write to the serial port after it is closed Bluetooth: hci_codec: validate vendor codec count length Bluetooth: put the peer's on-air address on air when we cannot resolve Bluetooth: coredump: Quiesce dump work on unregister Bluetooth: btintel_pcie: validate TX skb length in send_sync Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained Bluetooth: eir: validate service data length before reading UUID Bluetooth: btusb: fix NXP IW610 composite device handling ==================== Link: https://patch.msgid.link/20260915192441.1130583-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski commit 7de9a6fb44eae4f05e68c805d58b9c618815adfa Author: Tejun Heo Date: Tue Sep 15 12:34:44 2026 -1000 sched_ext: Wait for SCX_OPSS_DISPATCHING before reenqueueing a task ebf1ccff79c4 ("sched_ext: Fix ops.dequeue() semantics") moved the final ops_state store in scx_dispatch_enqueue() after the DSQ unlock so that the custody update and ops.dequeue() precede it. A task can thus be found on a DSQ while still SCX_OPSS_DISPATCHING. The dequeue and core-sched pick paths wait for the state to clear in ops_dequeue() but the reenqueue paths don't. A reenqueue in that window runs ops.enqueue() and sets SCX_OPSS_QUEUED before the dispatch has completed. The dispatcher's final store then overwrites it with SCX_OPSS_NONE and finish_dispatch() drops every later dispatch of the task. Wait for SCX_OPSS_DISPATCHING to clear before dequeueing a task for reenqueue, the same way ops_dequeue() does. Fixes: ebf1ccff79c4 ("sched_ext: Fix ops.dequeue() semantics") Cc: stable@vger.kernel.org # v7.1+ Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit 089e4f3c4862ba3f29dff2361caa8084879194fd Author: Mark Brown Date: Tue Sep 1 22:47:00 2026 +0100 KVM: arm64: Fix FGT mapping for HFGITR_EL2.nGCSEPP The encoding to trap mapping currently maps a FGT on OP_GCSPOPX to HFGITR_EL2.nGCSEPP but as per DDI0601 2026-06 this FGT controls trapping of GCSPUSHX and GCSPOPCX, and not the separate GCSPOPX instruction. Update the mapping to reflect the architecture. Fixes: 863ac38984a82 ("KVM: arm64: Add missing HFGITR_EL2 FGT entries to nested virt") Reviewed-by: Leonardo Bras Signed-off-by: Mark Brown Reviewed-by: Lorenzo Stoakes (ARM) Link: https://patch.msgid.link/20260901-arm64-gcs-v20-2-f31750bdfadb@kernel.org Signed-off-by: Oliver Upton commit 96e6757cb0674acb86ee8b558ee6bffe0eec0bb0 Author: Sebastian Ott Date: Mon Sep 14 15:10:13 2026 +0200 KVM: selftests: fix steal_time for arm64 with host page size > 4K Fix the following failure when running with 16K host page size: ==== Test Assertion Failure ==== lib/kvm_util.c:991: vm_adjust_num_guest_pages(vm->mode, npages) == npages pid=873 tid=873 errno=0 - Success 1 0x0000000000405a27: vm_mem_add at kvm_util.c:991 2 0x000000000040241f: check_steal_time_uapi at steal_time.c:223 (discriminator 7) 3 (inlined by) main at steal_time.c:539 (discriminator 7) 4 0x00007fff8b57af3b: ?? ??:0 5 0x00007fff8b57b007: ?? ??:0 6 0x0000000000402b6f: _start at ??:? Number of guest pages is not compatible with the host. Try npages=4 Fixes: fc240715fc50 ("KVM: selftests: arm64: Fix steal_time test after UAPI refactoring") Reported-by: Zenghui Yu Link: https://lore.kernel.org/kvmarm/7575a845-a542-4b16-b512-aec3126f97f3@linux.dev/T/#u Signed-off-by: Sebastian Ott Reviewed-by: Zenghui Yu (Huawei) Link: https://patch.msgid.link/20260914131013.60334-1-sebott@redhat.com Signed-off-by: Oliver Upton commit 49d9d295d69d07e850cae35933ba8519e2915f26 Author: Fuad Tabba Date: Mon Sep 14 10:38:38 2026 +0100 KVM: arm64: Don't WARN on an unknown VM ioctl in protected mode kvm_pkvm_ioctl_allowed() WARNs when kvm_get_cap_for_kvm_ioctl() doesn't find the ioctl number in vm_ioctl_caps[], and kvm_arch_vm_ioctl() calls it for every number the generic code doesn't handle, so ioctl(vm_fd, 0xdeadbeef) from userspace taints a pKVM host and panics it under panic_on_warn. The lookup is fed userspace input: return false, and userspace gets the -EINVAL kvm_arch_vm_ioctl() returns for that number on a host without pKVM. Fixes: b12b3b04f6ba0 ("KVM: arm64: Check whether a VM IOCTL is allowed in pKVM") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Reviewed-by: Suzuki K Poulose Link: https://patch.msgid.link/20260914093838.1082637-1-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit e5843f4effaa2ffac3e789ecd4456403564961d4 Author: Marc Zyngier Date: Fri Sep 11 17:22:03 2026 +0100 KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction We free the shadow S2 structures from kvm_arch_flush_shadow_all(), which is a Bad Idea(tm). Freeing the page tables is fair game (this is what this callback is for), but freeing the container that could still be referenced by another part of the system is not great. Instead, grow separate destructors that gets called when we tear the VM down for good. From there, we can nuke both the individual MMUs as well as the global array that points to them, safe in the knowledge that the vcpus themselves have been destroyed already. Fixes: 4f128f8e1aaac ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures") Reviewed-by: Lorenzo Stoakes (ARM) Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260911162203.1919330-3-maz@kernel.org Signed-off-by: Oliver Upton commit 33346f8960c7bb6a3b4e273b5cfe25c5a8be349f Author: Marc Zyngier Date: Fri Sep 11 17:22:02 2026 +0100 KVM: arm64: nv: Fix life cycle of the nested_mmus array The nested_mmus array holds the shadow page tables that are used when a guest is running a nested context. These structures are allocated on VCPU_INIT for whole guest, which implies that they may have to be relocated as the array grows. Should a VCPU_INIT occur whilst a vcpu is actively running an L2 and that the allocation requires relocation, that vcpu will still be running with a pointer to the previous structure, which will have been freed. Fix this by turning the array of structures to an array of pointers, which is now allocated at VM creation, sized to the absolute maximum that KVM can handle. In turn, each VCPU_INIT contributes S2_MMU_PER_VCPU to the pool. No reallocation is ever performed, and the life cycle of each object is much clearer: - the nested_mmus array is allocated in kvm_init_nested(), and freed in kvm_arch_destroy_vm() - s2_mmu structures are allocated in kvm_vcpu_init_nested(), and freed on kvm_arch_flush_shadow_all() Finally, the freeing of vcpu->arch.vncr_array is made consistent rather than being done on some failure paths, but not others. Fixes: 4f128f8e1aaa ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures") Reported-by: Shen Yongchao Reported-by: Karl Mehltretter Suggested-by: Karl Mehltretter Acked-by: Lorenzo Stoakes (ARM) Link: https://lore.kernel.org/r/20260803224405.41468-1-kmehltretter@gmail.com Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260911162203.1919330-2-maz@kernel.org Signed-off-by: Oliver Upton commit cfe80c3837f93202970b6d8f706f79c5c7396f17 Author: Fuad Tabba Date: Tue Sep 8 12:07:13 2026 +0100 KVM: arm64: Check every private mapping is hyp-owned at pKVM init fix_host_ownership() transfers only what it walks, so a hyp mapping outside the linear map is not manipulated by the walk. Walk the quarter of the VA space holding the private range and the vmemmap once the transfer is done, and fail init unless every valid leaf is hyp-owned: in the vmemmap when the page is memory, and in the host stage-2, where hyp text may instead be mapped without write access. A leaf that is not memory has no vmemmap entry and is checked against the host stage-2 alone. Hyp text is matched by physical address, since the only executable mapping in the range is the Spectre-v3a vectors, whose VA is a private allocation, and an executable mapping of anything else must not be host-readable. The vmemmap can be block-mapped, so the walker checks each page of a leaf. Suggested-by: Will Deacon Signed-off-by: Fuad Tabba Reviewed-by: Vincent Donnefort Tested-by: Vincent Donnefort Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260908110713.1540304-5-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 2245841401147b8022a5857061b870d82e595352 Author: Fuad Tabba Date: Tue Sep 8 12:07:12 2026 +0100 KVM: arm64: Move the private VA allocation cursor to __io_map_next __io_map_base is the start of the private VA range only until the first allocation from it, after which it is the allocation cursor. Keep it as the start and move the cursor to __io_map_next, for the walk of the range the next patch adds. No functional change intended. Signed-off-by: Fuad Tabba Reviewed-by: Vincent Donnefort Tested-by: Vincent Donnefort Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260908110713.1540304-4-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 5a8b505ede133fb30ca3b3a19d0db00c08237615 Author: Fuad Tabba Date: Tue Sep 8 12:07:11 2026 +0100 KVM: arm64: Match hyp text by physical address in fix_host_ownership() On a non-hVHE host, fix_host_ownership_walker()'s test for PAGE_HYP_EXEC never matches: KVM_PGTABLE_PROT_UX is cleared at map time and only PX is reported on read-back. Hyp text is therefore donated rather than left read-only in the host stage-2, and the instruction dump in nvhe_hyp_panic_handler() reads a page the host has no access to. Match the text by physical address instead, in a helper a later patch reuses. A test on the permissions would leave any other executable mapping host-readable too. Fixes: 80cbfd7174f31 ("KVM: arm64: Honor UX/PX attributes for EL2 S1 mappings") Signed-off-by: Fuad Tabba Reviewed-by: Vincent Donnefort Tested-by: Vincent Donnefort Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260908110713.1540304-3-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 3a8c562892b96f35bba1e00d5e455a15963bbb92 Author: Fuad Tabba Date: Tue Sep 8 12:07:10 2026 +0100 KVM: arm64: Transfer the hyp stack pages out of the host stage-2 fix_host_ownership() walks only the linear-map alias of each memblock region, and the per-CPU hyp stack, mapped in the private VA range for its guard page, has none. Walk each stack's VA range with the same walker. Fixes: 1a919b17ef012 ("KVM: arm64: Add guard pages for pKVM (protected nVHE) hypervisor stack") Reported-by: Hiroyuki Katsura Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Reviewed-by: Vincent Donnefort Tested-by: Vincent Donnefort Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260908110713.1540304-2-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 0a46eb5719fa57cc9d06025dcd8ba271643dee61 Author: Karl Mehltretter Date: Sat Aug 29 07:48:56 2026 +0200 KVM: arm64: selftests: Test empty SMCCC filter range at base 0 test_invalid_nr_functions() only checks an empty range at PSCI_0_2_FN64_CPU_ON, which KVM's end < start check happens to catch. It never exercised base 0, where the inclusive end wraps to U32_MAX instead. Add the base 0 case. Without the preceding fix it fails with EEXIST. Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Steffen Eiden Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Link: https://patch.msgid.link/20260829054856.70549-3-kmehltretter@gmail.com Signed-off-by: Oliver Upton commit 64dc6f1db7e620f2e9337bb181f305fb0561da79 Author: Karl Mehltretter Date: Sat Aug 29 07:48:55 2026 +0200 KVM: arm64: Return -EINVAL for an empty SMCCC filter range at base 0 kvm_smccc_set_filter() only rejects a range if its inclusive end, base + nr_functions - 1, is below base. That catches an empty range (nr_functions == 0) at every nonzero base, but at base 0 the end wraps to U32_MAX and KVM tries to insert [0, U32_MAX], which overlaps the reserved Arm Architecture Calls ranges. KVM_ARM_VM_SMCCC_FILTER then returns -EEXIST instead of the -EINVAL that the smccc_filter selftest expects for an empty range. Reject a zero function count explicitly. Tested with a userspace reproducer on an arm64 VHE host under QEMU TCG: EEXIST before, EINVAL after. Fixes: 821d935c87bc ("KVM: arm64: Introduce support for userspace SMCCC filtering") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Steffen Eiden Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Link: https://patch.msgid.link/20260829054856.70549-2-kmehltretter@gmail.com Signed-off-by: Oliver Upton commit 4f16c5fc8dc4c5596e3777ab9f449a54e3f85fd5 Author: Fuad Tabba Date: Tue Aug 25 09:59:48 2026 +0100 KVM: arm64: Derive GUEST_HAS_SVE from the SVE feature bit at EL2 pkvm_init_features_from_host() takes KVM_ARCH_FLAG_GUEST_HAS_SVE and KVM_ARM_VCPU_SVE from the host separately, but pkvm_vcpu_init_sve() tests the bit while vcpu_has_sve() reads the flag. A host that sets the flag without the bit gets a vCPU with a NULL sve_state that the world switch loads the guest's SVE state from. Derive the flag from the bit, and drop the protected path's copy of the host's flag, which is dead code since protected VMs are not allowed SVE. Fixes: 41d6028e28bd ("KVM: arm64: Convert the SVE guest vcpu flag to a vm flag") Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260825085948.1674721-5-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 0d62fbf34d8fe7a3ff56692d39fbb8e6e9bf15fb Author: Fuad Tabba Date: Tue Aug 25 09:59:47 2026 +0100 KVM: arm64: Key unpin_host_sve_state() on the state it unpins unpin_host_sve_state() gates on the VM's SVE feature bit, but what it unpins is the state pkvm_vcpu_init_sve() pinned. A vCPU that completed init has sve_state set exactly when that bit is set, so the two agree. Gate on sve_state, which is what is being unpinned. Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260825085948.1674721-4-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit a1b3c788ad31837e348075e93dbba3f447492776 Author: Fuad Tabba Date: Tue Aug 25 09:59:46 2026 +0100 KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure pkvm_vcpu_init_sve() clears KVM_ARM_VCPU_SVE in kvm->arch.vcpu_features when it fails, but vcpu_has_sve() tests KVM_ARCH_FLAG_GUEST_HAS_SVE, which is left set. Later vCPUs on that VM then skip the SVE setup and register with a NULL sve_state, which the guest's first FP access hands to sve_load_state(). Return the error without touching vcpu_features. Fixes: 5db1bef93342 ("KVM: arm64: Track SVE state in the hypervisor vcpu structure") Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260825085948.1674721-3-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 2a2eb10795a1e495aebc7f829ccecb72c05b4fd9 Author: Fuad Tabba Date: Tue Aug 25 09:59:45 2026 +0100 KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve() pkvm_vcpu_init_sve() clamps only the upper bound of the host-provided sve_max_vl, so an invalid vector length reaches sve_state_size_from_vl() and the WARN_ON() there, which is fatal at EL2. The existing !sve_state_size test rejects such a length, but only after the macro has run. Check sve_vl_valid() before deriving the state size. A valid length cannot yield a zero size, so the !sve_state_size test goes with it. Fixes: 5db1bef93342 ("KVM: arm64: Track SVE state in the hypervisor vcpu structure") Reported-by: Stefan Teodorescu Reviewed-by: Marc Zyngier Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260825085948.1674721-2-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 4c74e233cdedd11592775fae2a6243e67ca3f891 Author: Lorenzo Stoakes (ARM) Date: Tue Sep 1 18:29:00 2026 +0100 KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race Commit 7270cc9157f4 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers") introduced VNCR_EL2 invalidation in both kvm_nested_s2_unmap() and kvm_nested_s2_wp(). However at the point of this being performed concurrent stage 2 teardown of a nested guest can cause kvm->arch.mmu.pgt to be set to NULL. This happens in kvm_flush_shadow_all() -> kvm_arch_flush_shadow_all() -> kvm_free_stage2_pgd() and is performed under the kvm->mmu_lock. Commit ec14c272408a ("KVM: arm64: nv: Unmap/flush shadow stage 2 page tables") introduced the teardown of the entire nested MMU range, which then invokes stage2_apply_range() with resched=true: mmu_notifier_invalidate_range_start() -> ... -> kvm_mmu_notifier_invalidate_range_start() -> kvm_mmu_unmap_gfn_range() -> kvm_unmap_gfn_range() -> kvm_nested_s2_unmap() -> kvm_stage2_unmap_range() -> __unmap_stage2_range() -> stage2_apply_range() This means that stage2_apply_range() can drop the kvm->mmu_lock and thus concurrent progress can be made in lockstep with kvm_arch_flush_shadow_all(). If kvm_arch_flush_shadow_all() advances ahead of stage2_apply_range() and completes its operation it guarantees a NULL pointer deref. Since kvm_free_stage2_pgd() is performed under the kvm->mmu_lock this will either be observed NULL or not and serialised against kvm_free_stage2_pgd(). Resolve the issue by abstracting the invalidation to a new function, kvm_invalidate_vncr_ipa_all(), and check that the pgt is non-NULL before dereferencing it. Fixes: 7270cc9157f4 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers") Cc: stable@vger.kernel.org Reviewed-by: Marc Zyngier Signed-off-by: Lorenzo Stoakes (ARM) Tested-by: Jonathan Davies Link: https://patch.msgid.link/20260901-kvm-arm-nested-virt-fix-v3-2-b154676f7e4c@kernel.org Signed-off-by: Oliver Upton commit 38b70fc453c3112f1a62583b89903ae41116cc27 Author: Lorenzo Stoakes (ARM) Date: Tue Sep 1 18:28:59 2026 +0100 KVM: arm64: Fix spurious warning for benign stage 2 teardown race kvmtool was used to establish an L1 guest with 8 CPUs and 8 GiB of RAM, an L2 guest with 4 CPUs and 4 GiB of RAM and an L3 guest with 2 CPUs and 2 GiB of RAM, all of which was then exited. Under memory pressure in the L0 host warnings were observed due to migration triggered by compaction: WARNING: arch/arm64/kvm/mmu.c:336 at __unmap_stage2_range+0x64/0x80, CPU#5: kcompactd0/66 Which was, in turn, triggered by an MMU notifier for the host invalidation: mmu_notifier_invalidate_range_start() -> ... -> kvm_mmu_notifier_invalidate_range_start() -> kvm_mmu_unmap_gfn_range() -> kvm_unmap_gfn_range() -> kvm_nested_s2_unmap() -> kvm_stage2_unmap_range() -> __unmap_stage2_range() -> stage2_apply_range() <- -EINVAL, triggering a WARN_ON() Racing with L0's teardown of stage 2 page tables: exit_mm() -> mmput() -> __mmput() -> exit_mmap() -> mmu_notifier_release() -> ... -> kvm_mmu_notifier_release() -> kvm_flush_shadow_all() -> kvm_arch_flush_shadow_all() -> kvm_free_stage2_pgd() -> [ acquire kvm->mmu_lock for write ] -> mmu->pgt = NULL [ among other tasks ] -> [ release kvm->mmu_lock for write ] It turns out there is a benign race resulting in a spurious warning: Thread A - notify: migration | Thread B - notify: release -------------------------------|--------------------------------- < kvm->mmu_lock held > | stage2_apply_range() | get mmu->pgt, check !NULL | ... | kvm_arch_flush_shadow_all() cond_resched_rwlock_write(); | < contend, sleep kvm->mmu_lock > < drop kvm->mmu_lock > | < acquire kvm->mmu_lock> | ... | kvm_free_stage2_pgd() | mmu->pgt = NULL | < invalidate MMU > | ... | < release kvm->mmu_lock > [ scheduled ] | stage2_apply_range() | < loop to next > | get, mmu->pgt, check !NULL | is NULL, return -EINVAL | __unmap_stage2_range() | WARN_ON(-EINVAL) <--- entirely spurious - the race was handled correctly. Fix the spurious warning by updating stage2_apply_range() to no longer treat concurrent PGT teardown on lock release as an error - whether the walker is tearing down page tables or doing something else this is a legitimate reason to abort the operation without error. This keeps the warning in place for all other circumstances. In practice only __unmap_stage2_range() actually does anything with the error so this only impacts that. Fixes: ec14c272408a ("KVM: arm64: nv: Unmap/flush shadow stage 2 page tables") Cc: stable@vger.kernel.org Reviewed-by: Yuan Yao Reviewed-by: Marc Zyngier Signed-off-by: Lorenzo Stoakes (ARM) Link: https://patch.msgid.link/20260901-kvm-arm-nested-virt-fix-v3-1-b154676f7e4c@kernel.org Signed-off-by: Oliver Upton commit 6f182db39fb00548c26d689163ceb2fe4a802793 Author: Fuad Tabba Date: Fri Aug 21 07:44:45 2026 +0100 KVM: arm64: selftests: Add ITS table save tests Cover the two ways a guest can leave a table that KVM_DEV_ARM_ITS_SAVE_TABLES has to cope with: a GITS_BASER write that changes the table, which drops the collections it described, and a device whose L2 block the guest invalidated, which the save skips. Each case then resets and restores, which is what the save exists for. Both fail without the preceding patches. The first save returns -EINVAL, and the second saves a DTE pointing 8192 entries ahead, at an entry the save never wrote. Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Fuad Tabba Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260821064445.615838-5-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit cc5d96036e01ac330d24b2f0c336d60f82ab4930 Author: Fuad Tabba Date: Fri Aug 21 07:44:44 2026 +0100 KVM: arm64: vgic-its: Skip unreachable devices instead of failing the save vgic_its_save_device_tables() aborts with -EINVAL when a device's entry falls outside the device table, which a guest can arrange on its own: an indirect table lets it clear an L1 entry's valid bit without touching GITS_BASER. That fails a save userspace should be able to issue reliably. Skip the device instead, and point the saved DTE chain past it, as commit ad1e686e2378d ("KVM: arm64: vgic-its: Point saved ITEs at the next valid entry") does for ITEs. compute_next_devid_offset() takes the next device off the list whether or not it was saved, so the predecessor would otherwise point at an entry the save never wrote. Restore follows that offset while it stays inside the table being scanned: within an L2 block, or anywhere in a flat table. Both need userspace to remove a memslot under the table, since dropping an L1 entry takes the whole block with it and scan_its_table() stops at the block boundary. Fixes: 57a9a117154c9 ("KVM: arm64: vgic-its: Device table save/restore") Suggested-by: Marc Zyngier Link: https://lore.kernel.org/all/86bjaz5s6v.wl-maz@kernel.org/ Signed-off-by: Fuad Tabba Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260821064445.615838-4-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 30908e7272479b6453745022abb9f2eb9c9933f7 Author: Fuad Tabba Date: Fri Aug 21 07:44:43 2026 +0100 Revert "KVM: arm64: vgic-its: Don't save collections the table cannot hold" This reverts commit 9b10fb74e4b661543d188701bd4d024fc5c18f58. Freeing the collections when GITS_BASER changes removes the state this check rejected: vgic_its_cmd_handle_mapi(), vgic_its_cmd_handle_mapc() and vgic_its_restore_cte() all validate the ID against the current table before allocating, and the table can no longer change under the list. What remains is a collection whose entry is not backed by a memslot, which the write fails on anyway, so the check costs a save userspace should be able to issue reliably and buys nothing. The reverted commit credited the check with bounding the walk as well. It stays bounded without it: collection IDs are unique and each is below the table's capacity, so the list cannot be longer than the table. Suggested-by: Marc Zyngier Link: https://lore.kernel.org/all/87ecg9owwa.wl-maz@kernel.org/ Signed-off-by: Fuad Tabba Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260821064445.615838-3-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 8cd92f77ae4f5371a7d581f8324c24919670b304 Author: Fuad Tabba Date: Fri Aug 21 07:44:42 2026 +0100 KVM: arm64: vgic-its: Free the caches when GITS_BASER changes A guest that disables the ITS and re-points or shrinks GITS_BASER with VALID still set keeps the devices and collections it mapped against the old table, as KVM frees them only when VALID is cleared. The contents of the table are IMPLEMENTATION DEFINED, so a write that gives GITS_BASER a different address or size may lose whatever the old value described. Free the list whenever the stored value changes, and drop the translation cache with it. The cache is not empty just because the ITS is disabled: its->enabled is written under the cmd_lock, while vgic_its_resolve_lpi() tests it under the its_lock, so an injection can still cache an entry after the ITS was disabled. Hence the invalidation inside the its_lock section. Test for a change rather than a write: its_restore_enable() rewrites GITS_BASER from its probe-time cache on resume, and KVM reports GITS_TYPER.HCC as 0, so nothing re-maps the boot CPU's collection afterwards. Fixes: 36d6961c2b481 ("KVM: arm/arm64: vgic-its: Free caches when GITS_BASER Valid bit is cleared") Suggested-by: Marc Zyngier Link: https://lore.kernel.org/all/87ecg9owwa.wl-maz@kernel.org/ Signed-off-by: Fuad Tabba Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260821064445.615838-2-fuad.tabba@linux.dev Signed-off-by: Oliver Upton commit 8861db305103107199b1426f25fde1fb6d465583 Author: Christian Göttsche Date: Thu Sep 3 13:43:38 2026 +0200 selinux: always fill AVC decision in avc_has_perm_noaudit() avc_has_perm_noaudit() is documented to return a copy of the access decision in @avd, but its early return for an empty requested permission set leaves the buffer untouched. All callers pass an uninitialized stack variable and afterwards feed it to avc_audit(), and the inode hook even stores it in the per-task decision cache. Fill in a deny-all, audit-all decision, similar to avd_init(), so every caller receives a defined value at no cost on the hot path. Cc: stable@vger.kernel.org Fixes: e6f2f381e4015386 ("selinux: replace BUG_ONs with WARN_ONs in avc.c") Signed-off-by: Christian Göttsche Reviewed-by: Stephen Smalley Signed-off-by: Paul Moore commit 9b87fdc9af2fbfcdb5c24a64139685ef80f6573f Merge: 6fb20c02710dab a9e3760b083829 Author: Linus Torvalds Date: Tue Sep 15 11:57:51 2026 -0700 Merge tag 'sched_ext-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext Pull sched_ext fixes from Tejun Heo: - An error raised by a BPF program before the scheduler finished enabling was consumed by the disable path's pre-enable shortcut, leaving a running scheduler that couldn't be disabled and was later freed while in use. - Two compat kfuncs dereferenced a NULL scheduler when handed an exited or idle task, oopsing the kernel. - Keep-running decisions in the dispatch path used the root scheduler's flags for tasks belonging to a sub-scheduler, causing warnings and stalls. - Schedulers with their own CPU ID mapping had no way to learn which IDs are online. Add a kernel-maintained online mask to plug the hole. - Cgroup idle state: the initial cpu.idle state wasn't passed on cgroup init and same-value rewrites delivered spurious callbacks. - Example scheduler fixes for a reenqueue loop on attach, placements on CPUs without effective grants, stalled partition work and stale idle tracking. * tag 'sched_ext-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: Maintain an online cid mask in the scheduler arena sched_ext: scx_qmap: Restore unused idle claims from ops.dispatch() sched_ext: Close the pre-enable ops error claim window sched_ext: scx_qmap: Fix pending partition work handoff sched_ext: scx_qmap: Place only on cids whose caps are in effect sched_ext: scx_qmap: Do not add IMMED to rescue inserts sched_ext: Use @prev's scheduler for the keep decisions in dispatch_one() sched_ext: Rename sch to root_sch in dispatch_one() sched_ext: Fix NULL sched deref in kfunc sub-sched error paths sched_ext: Don't deliver duplicate ops.cgroup_set_idle() for same value sched_ext: Pass the initial cpu.idle state in scx_cgroup_init_args commit 801fb950cae7048eb7d83b18857d1ca37b8cd5a4 Author: Juan Perdomo Date: Sat Sep 12 23:09:45 2026 -0400 Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup rfcomm_sock_cleanup_listen() closes unaccepted child sockets through rfcomm_sock_close(), which takes the child socket lock before rfcomm_dlc_close() acquires rfcomm_mutex. The RFCOMM worker takes these locks in reverse order while handling connections and DLC state changes, so lockdep reports a possible deadlock. Close dequeued children without taking their socket lock. The accept queue owns a reference to each child, and bt_accept_dequeue() locks the child while unlinking it and clearing its parent pointer. Dropping the child lock makes it important to prevent a concurrent rfcomm_connect_ind() from enqueueing a new child after cleanup observes an empty queue. Set a listening socket to BT_CLOSED while its lock is still held, before dropping the lock and draining the queue. The state check in rfcomm_connect_ind() then rejects new children once cleanup starts. Reported-by: syzbot+0cece8fa7d83523f47a3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0cece8fa7d83523f47a3 Fixes: b7ce436a5d79 ("Bluetooth: switch to lock_sock in RFCOMM") Signed-off-by: Juan Perdomo Signed-off-by: Luiz Augusto von Dentz commit 555cd2bd860e7c4bdc3f4e4405b05515b0d9bc87 Author: Radek Podgorny Date: Sun Sep 13 22:28:02 2026 +0200 Bluetooth: keep dst_type with dst when reusing an LE connection hci_connect_le() swaps the caller's identity address for the peer's cached RPA when one is known, and stamps the matching ADDR_LE_DEV_RANDOM on the local dst_type. On the conn-reuse path only the address is copied into the connection: if (conn) { bacpy(&conn->dst, dst); so conn->dst ends up holding an RPA while conn->dst_type still names the identity it was resolved from, and hci_le_create_conn_sync() puts that pair on air unchanged. An RPA declared as a public address is not something any peer can answer. Measured on a CYW43438 against a peer advertising an RPA the host holds the IRK for, connecting to the identity address over a raw L2CAP socket. The first attempt creates the connection, the second takes the reuse path: LE Create Connection 3C:78:95:78:37:C3 type public LE Create Connection 5B:75:A2:26:D6:18 type public LE Connection Complete: Unknown Connection Identifier (0x02) The second address is the peer's RPA. btmon annotates it with an OUI lookup rather than "(Resolvable)" precisely because the command declares it public; the same bit pattern annotates as resolvable once the type is right. The mistyped pair is also why nothing downstream repairs it. hci_bdaddr_is_rpa() tests the type before the address, so an RPA carrying a public type is not recognised as one, and hci_find_irk_by_addr() then searches for an identity address that does not match it either. Copy the type along with the address. The assignment used to be unconditional just below this block and covered both paths; it moved into hci_conn_add_unset(), which the reuse path does not go through. Cc: stable@vger.kernel.org Fixes: 14b06c3a88f7 ("Bluetooth: HCI: Always use the identity address when initializing a connection") Assisted-by: Claude:claude-opus-5 Signed-off-by: Radek Podgorny Signed-off-by: Luiz Augusto von Dentz commit 2ea5a87a5a7ae58cb2662b8a7d06f209383e1765 Author: Sai Teja Aluvala Date: Fri Sep 11 17:22:22 2026 +0530 Bluetooth: btintel_pcie: fix off-by-one bounds check in RX submit btintel_pcie_submit_rx() used frbd_index > rxq->count to guard the FRBD array access, allowing frbd_index == rxq->count to pass through and index one element past the end of the array. Change the check to >= rxq->count so every out-of-range index is rejected. This issue was reported by Claude Mythos. Fixes: c2b636b3f788 (Bluetooth: btintel_pcie: Add support for PCIe transport) Signed-off-by: Sai Teja Aluvala Signed-off-by: Luiz Augusto von Dentz commit 7b60ee5f46f2ee329de661f7c68b6818d8136220 Author: Tzung-Bi Shih Date: Mon Sep 14 09:47:29 2026 +0000 Bluetooth: btmtksdio: Fix PM runtime reference leak in shutdown In btmtksdio_shutdown(), pm_runtime_get_sync() is called at the beginning of the function. However, if sending the WMT function control command fails later, the driver returns early. It bypasses the corresponding pm_runtime_put_noidle() and pm_runtime_disable() calls, leaking the PM usage counter and leaving PM runtime enabled indefinitely. Fall through to execute the PM runtime cleanup block even if WMT errors. Fixes: 7f3c563c575e ("Bluetooth: btmtksdio: Add runtime PM support to SDIO based Bluetooth") Signed-off-by: Tzung-Bi Shih Signed-off-by: Luiz Augusto von Dentz commit 8879e3e0a84a86954c855caceead4867e74a9a27 Author: Chris Lu Date: Mon Sep 14 14:56:54 2026 +0800 Bluetooth: btmtksdio, btmtkuart: validate WMT event length before struct access btmtksdio.c and btmtkuart.c cast a received WMT event straight to struct btmtk_hci_wmt_evt and read its op/flag fields without checking the event is long enough to contain them, unlike btmtk.c. The FUNC_CTRL case then further casts to struct btmtk_hci_wmt_evt_funcc and reads its 2-byte status field, again without a length check. Firmware that sends a short or malformed WMT event makes both drivers read past the end of the received SKB. Mirror btmtk.c: validate the base WMT header with skb_pull_data() before touching any of its fields, and when a FUNC_CTRL event turns out to be the short, header-only form (a plain enable/disable ack with no status word), decode the result from the header's own flag byte instead (0 = success, otherwise failure). Verified setup on MT7920, MT7921, MT7922 and MT7925: no regression. Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Fixes: e0b67035a90b ("Bluetooth: mediatek: update the common setup between MT7622 and other devices") Assisted-by: Claude:claude-opus-5 Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz commit 78b6abd6c7a7591aacdae657f813214dae4fcd3b Author: Chris Lu Date: Mon Sep 14 14:56:53 2026 +0800 Bluetooth: btmtk: fix wrong status for short WMT FUNC_CTRL events A too-short BTMTK_WMT_FUNC_CTRL event (WMT header only, no trailing 2-byte status word) is always treated as BTMTK_WMT_ON_UNDONE. This short form is how firmware acks a plain enable/disable request, and the actual result is carried in the header's own flag byte (0 = success), not a separate status word. Decode it from there instead of assuming failure. Verified setup on MT7920, MT7921, MT7922 and MT7925: no regression. Fixes: e3ac0d9f1a20 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events") Assisted-by: Claude:claude-opus-5 Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz commit 296e7f3c5071cc02dc22e1566e759179fa1792ae Author: Luiz Augusto von Dentz Date: Thu Sep 10 14:07:24 2026 -0400 Bluetooth: ISO: set BT_LISTEN before requesting a BIG sync A BIS connection is matched to its parent socket by looking for a socket in BT_LISTEN state with the same BIG handle: iso_conn_ready() if (test_bit(HCI_CONN_BIG_SYNC, &hcon->flags)) parent = iso_get_sock(hdev, &hcon->src, &hcon->dst, BT_LISTEN, iso_match_big_hcon, hcon); The socket was only moved to BT_LISTEN after iso_conn_big_sync() returned, while the LE BIG Create Sync command has already been queued by then. If the BIG sync is established before the state is updated, which is easy to hit with an emulated controller as the command may complete in a few hundred microseconds, no parent is found and the BIS connections are never notified to the listening socket. The user space is then left waiting for connections that never arrive, e.g. bluetoothd never completes a MediaTransport1.Acquire of a Broadcast Sink transport. Move the socket to BT_LISTEN before requesting the BIG sync, so the state is visible by the time the command is queued, and restore the previous state if the request could not be started. Since the socket is briefly visible as a listening socket, child sockets may have been queued in the meantime, so drain the accept queue before restoring the state: the cleanup paths of BT_CONNECT2/BT_CONNECTED don't do it and the children would be left with a dangling parent pointer. Fixes: fbdc4bc47268 ("Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync") Signed-off-by: Luiz Augusto von Dentz commit ca18ee413a7cb6f09885778039225e58bae0d607 Author: Luiz Augusto von Dentz Date: Thu Sep 10 14:06:27 2026 -0400 Bluetooth: ISO: Fix parent socket leak in iso_conn_ready() iso_get_sock() returns the parent socket with a reference held, which is dropped by sock_put() once the child socket has been set up. The error path taken when iso_sock_alloc() fails only calls release_sock() and returns, leaking the reference and thus the parent socket itself. Drop the reference on that path as well. Fixes: fa224d0c094a ("Bluetooth: ISO: Reassociate a socket with an active BIS") Signed-off-by: Luiz Augusto von Dentz commit 9a10987a2f160a44a638c9a35994ca6e3089696e Author: Chengfeng Ye Date: Sat Aug 22 01:43:50 2026 +0800 Bluetooth: hci_sync: Serialize local codec list cleanup hci_dev_close_sync() clears hdev->local_codecs after releasing hdev->lock. Codec list additions and both traversals in sco_sock_getsockopt() use that lock, but the close path does not. A close and BT_CODEC query can therefore interleave as follows: hci_dev_close_sync() sco_sock_getsockopt() hci_dev_lock() fetch codec entry hci_codec_list_clear() kfree(entry) read entry->id The reader then accesses an entry which the close path has freed. KASAN reported: BUG: KASAN: slab-use-after-free in sco_sock_getsockopt+0xfa0/0xfe0 Read of size 1 at addr ffff8881001c3450 Call Trace: sco_sock_getsockopt+0xfa0/0xfe0 do_sock_getsockopt+0x537/0x7b0 __sys_getsockopt+0xf2/0x170 Allocated by task 92: hci_codec_list_add.isra.0+0x2c/0x440 hci_read_codec_capabilities+0x224/0x590 hci_read_supported_codecs+0x2c2/0x640 Freed by task 92: kfree+0x131/0x3c0 hci_codec_list_clear+0xd8/0x160 hci_dev_close_sync+0x92a/0xfa0 Take hdev->lock around the clear operation at its existing point in the close path. This makes the clear wait for active readers and prevents a new traversal until the list is empty without changing teardown ordering. Fixes: b938790e7054 ("Bluetooth: hci_codec: Fix leaking content of local_codecs") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz commit 4e93c65f87825e1e012bce56615320aeb123815d Author: Ibrahim Abdelkader Date: Wed Aug 19 14:54:25 2026 +0200 Bluetooth: hci_qca: Do not write to the serial port after it is closed hci_uart_close() closes the serdev port if HCI_QUIRK_NON_PERSISTENT_SETUP is set (for example, for the WCN399x family). A failed hci_dev_open_sync() following a successful qca_setup() calls hdev->close() but not hdev->shutdown(), so the port is closed while power->vregs_on is left true. qca_serdev_remove() then passes its power->vregs_on test and calls qca_power_off(), which writes to the closed port unconditionally. Seen on a WCN3988 by unbinding the driver after a controller failure. The trace below is from a 7.0.0 based kernel, where qca_power_off() was still named qca_power_shutdown(): Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 Call trace: tty_set_termios+0x50/0x238 (P) ttyport_set_baudrate+0x84/0xc0 serdev_device_set_baudrate+0x24/0x40 qca_power_shutdown+0x158/0x1fc [hci_uart] qca_serdev_remove+0x54/0x68 [hci_uart] serdev_drv_remove+0x1c/0x2c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xc0 Check HCI_UART_PROTO_READY, which hci_uart_close() clears in the same place it closes the port, before writing to it. The regulator disable is left unconditional so the controller is still powered down. The dangling serport->tty that turns this into a use-after-free is addressed in a separate patch. Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990") Signed-off-by: Ibrahim Abdelkader Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Luiz Augusto von Dentz commit d0795cfd6f655f4de84868a4f4bb41a03f037b3d Author: Laxman Acharya Padhya Date: Mon Aug 24 21:42:36 2026 +0545 Bluetooth: hci_codec: validate vendor codec count length The Read Local Supported Codecs parsers consume the variable-sized standard codec array before parsing the vendor codec count. Although the initial reply-size check includes a vendor count byte in the fixed layout, it does not guarantee that the byte remains after the standard codec array. If a controller reply ends immediately after that array, calculating the vendor codec array size reads vnd_codecs->num beyond the skb data. Use skb_pull_data() to validate and consume each codec header before using its count in both command variants. Fixes: 8961987f3f5f ("Bluetooth: Enumerate local supported codec and cache details") Fixes: 9ae664028a9e ("Bluetooth: Add support for Read Local Supported Codecs V2") Cc: stable@vger.kernel.org Suggested-by: Luiz Augusto von Dentz Signed-off-by: Laxman Acharya Padhya Signed-off-by: Luiz Augusto von Dentz commit 4914c499896121ae8b9d5b90f0abc5c8287ff396 Author: Radek Podgorny Date: Wed Sep 9 00:29:37 2026 +0200 Bluetooth: put the peer's on-air address on air when we cannot resolve An identity address only reaches a peer that is advertising an RPA if the controller resolves it on our behalf. Where it cannot, the host has to put the peer's on-air address on air itself. hci_connect_le() still swaps the caller's identity address for the peer's cached RPA before creating the connection, but __hci_conn_add() resolves the RPA back to the identity address when it stores it, so the identity is what goes out. Storing the identity is right when the controller translates it on the way to the radio; without LL Privacy, or with this peer absent from the resolving list, nothing does. A peer advertising an RPA cannot answer its identity address, so the attempt burns a full create-connection timeout. That is not merely a slow connect: a controller without extended scanning cannot scan while it is initiating, so every dead attempt also takes the scanner off the air for the whole timeout. Measured on a CYW43438, which reports neither LL Privacy nor extended advertising (LE features 3f 00 00 08 00 00 00 00), against a peer advertising a resolvable private address the host holds the IRK for, with the connection requested on the peer's identity address: before: LE Create Connection to the identity address, public type 1.61s -> 22.07s, then LE Create Connection Cancel LE Connection Complete: Unknown Connection Identifier (0x02) after: LE Create Connection to the peer's RPA, random type LE Connection Complete: Success Advertising reports reaching the host per second, same window, same five unrelated devices on the adapter: before 1s:2 [nothing from 2s through 21s] 22s:5 23s:3 after 0s:11 1s:5 2s:2 3s:5 4s:3 5s:4 ... 21s:2 22s:1 23s:2 One dead connect costs twenty seconds of scanning for every device on the adapter, not just the one being dialled. Keep the RPA in conn->dst unless the controller will translate the identity address: address resolution enabled and the peer's identity actually programmed into the resolving list. Testing ll_privacy_capable() alone would not be enough: it reports the feature bit, not whether resolution is switched on and not whether this peer is in the list. Resolution is cleared with the other volatile flags on power-off and switched off again while suspend pauses scanning, and a peer's IRK is only programmed along the accept list path, so a direct-connect target, a peer without HCI_CONN_FLAG_ADDRESS_RESOLUTION, and one that did not fit in a full list are all absent from it. With the peer programmed, the identity address stays in conn->dst and the controller translates it: measured on an Intel controller, the host dials the identity and LE Enhanced Connection Complete reports Resolved Public with the peer's RPA in the separate peer resolvable private address field. With the peer absent from the list the same setup dials the RPA itself. Everything downstream already copes with an RPA in conn->dst: it is what every outgoing LE connection stored before 14b06c3a88f7, the connection complete event names the address that was dialled, and le_conn_complete_evt() resolves it back to the identity once the link is up. ISO links keep the unconditional conversion: they are created from an existing ACL or a periodic sync and never dial this address themselves. Keeping the RPA is only right while the peer is still using it, which is why the preceding patch drops the cached RPA as soon as the peer is seen advertising its identity address. Without that, a peer that turns privacy off would be dialled on the address it abandoned rather than the one it is answering on. Fixes: 14b06c3a88f7 ("Bluetooth: HCI: Always use the identity address when initializing a connection") Assisted-by: Claude:claude-opus-5 Assisted-by: Claude:claude-fable-5 Signed-off-by: Radek Podgorny Signed-off-by: Luiz Augusto von Dentz commit d236517c264e41dc09833c708ef23bccb7a91219 Author: Weiming Shi Date: Sun Sep 6 23:43:32 2026 +0800 Bluetooth: coredump: Quiesce dump work on unregister hci_devcd_handle_pkt_init() arms dump_timeout and coredump producers queue dump_rx without holding an hdev reference. Unregister leaves both works live, so disconnecting during an active dump lets them access hdev after hci_release_dev() frees it. Shut down coredump processing during unregister. Close the producer gate under dump_q.lock before disabling both works, then free the active buffer and queued packets under hci_dev_lock. Serializing the gate with enqueue prevents controller-specific workers from adding packets after the final purge. Fixes: 9695ef876fd1 ("Bluetooth: Add support for hci devcoredump") Reported-by: syzbot+b170dbf55520ebf5969a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b170dbf55520ebf5969a Reported-by: Aby Sam Ross Link: https://lore.kernel.org/r/20260322210849.68743-1-abysamross@gmail.com Suggested-by: Aby Sam Ross Reported-by: Tristan Madani Link: https://lore.kernel.org/r/20260814231248.3096377-1-tristmd@gmail.com Reported-by: Xiang Mei Assisted-by: OpenAI Codex:gpt-5 Signed-off-by: Weiming Shi Reported-by: Xiang Mei Signed-off-by: Luiz Augusto von Dentz commit 4b837ebd0ea21ae5cc26f02dc042edc6fe7b46b9 Author: Chandrashekar Devegowda Date: Tue Sep 8 15:26:58 2026 +0530 Bluetooth: btintel_pcie: validate TX skb length in send_sync btintel_pcie_prepare_tx() copies skb->len bytes into a fixed BTINTEL_PCIE_BUFFER_SIZE (4096) DMA slot via an unchecked memcpy. Oversized packets are currently rejected only in btintel_pcie_send_frame(); any future caller of btintel_pcie_send_sync() would silently overflow the DMA buffer. Add the bounds check in btintel_pcie_send_sync() itself, right before skb_push() and the DMA copy. Assisted-by: Copilot:claude-sonnet-5 code-review code-generation Fixes: 6e65a09f9275 ("Bluetooth: btintel_pcie: Add *setup* function to download firmware") Signed-off-by: Chandrashekar Devegowda Signed-off-by: Luiz Augusto von Dentz commit 6610c6fe4b8936c232048e6049bf77c70a6f759c Author: ThangNN99 Date: Sun Sep 6 22:21:27 2026 +0700 Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained hci_send_acl(), hci_send_sco() and hci_send_iso() queue hdev->tx_work unconditionally. They can run from the L2CAP/SCO/ISO socket send path while hci_dev_close_sync() is draining hdev->workqueue (HCIDEVDOWN racing with a socket write). Since that queue_work() is not chained work from the tx_work worker itself, __queue_work() sees the queue marked __WQ_DRAINING, warns "cannot queue %ps on wq %s", and drops the work: WARNING: CPU: 1 PID: 5985 at kernel/workqueue.c:2352 __queue_work Call Trace: queue_work_on l2cap_chan_send l2cap_sock_sendmsg ... hci_dev_close_sync() already sets HCI_CMD_DRAIN_WORKQUEUE before draining, but only hci_cmd_work() and handle_cmd_cnt_and_timer() check it before queuing. Route the tx_work producers through the same guard via a shared hci_sched_tx() helper. Fixes: 525daaea459f ("Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close") Reported-by: syzbot+b6919040d9958e2fc1ae@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b6919040d9958e2fc1ae Signed-off-by: ThangNN99 Signed-off-by: Luiz Augusto von Dentz commit 6fb20c02710dabc2f63aa21cb23a154d76ef9921 Merge: f6e7b42bf05b24 057dac23d329d5 Author: Linus Torvalds Date: Tue Sep 15 11:40:30 2026 -0700 Merge tag 'cgroup-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fix from Tejun Heo: - The task iterator could pick up a dying task whose refcount had already dropped to zero and resurrect it, leading to a use-after-free when reading cgroup.procs. Skip such tasks. * tag 'cgroup-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup: Avoid iteration of dying tasks with zero refcount commit e8241766794cf551d787fa3a77c0d54bbea6f6aa Author: Aamir Ahmed Date: Mon Sep 7 00:37:43 2026 +0100 Bluetooth: eir: validate service data length before reading UUID eir_get_service_data() reads a 16-bit UUID from the service data using get_unaligned_le16() without first checking that the data is long enough to hold a UUID16 (2 bytes). If a malformed EIR entry has a service data field with only 1 byte of payload (field_len=2), eir_get_data() returns dlen=1. The subsequent get_unaligned_le16() then reads 1 byte past the field boundary. Additionally, if the corrupted UUID happens to match, the length calculation "dlen - 2" underflows to SIZE_MAX since dlen is size_t. Current callers either pass NULL for the length parameter or bounds-check the returned length, but future callers may not. Add a check that dlen >= sizeof(u16) and skip fields that are too short to contain a valid UUID16. Fixes: 8f9ae5b3ae80 ("Bluetooth: eir: Add helpers for managing service data") Cc: stable@vger.kernel.org Signed-off-by: Aamir Ahmed Signed-off-by: Luiz Augusto von Dentz commit 2b50adefed9808a56d84d1de803cad882cc787fa Author: Nicolas Thibert Date: Tue Sep 8 10:01:08 2026 +0200 Bluetooth: btusb: fix NXP IW610 composite device handling The NXP IW610 module exposes itself as a composite USB device (0471:0215) with three interfaces: two real Bluetooth HCI interfaces (class 0xe0) and one vendor-specific WiFi interface (class 0xff) used by mwifiex-nxp. The composite device's whole USB descriptor reports class 0xe0/01/01 (Bluetooth), so btusb_table's generic USB_DEVICE_INFO(0xe0, 0x01, 0x01) entry matches every interface, not just the two real HCI ones -- btusb ends up binding the WiFi interface too, and mwifiex-nxp never gets it. Fix: 1. In btusb_table (the table the USB core actually matches against), explicitly ignore the WiFi interface via BTUSB_IGNORE, ahead of the generic entry. 2. In quirks_table, scope the existing BTUSB_MARVELL entry to the BT interface class instead of matching the whole device by VID/PID (harmless either way since quirks_table isn't consulted for initial binding, but keep it correct). Not upstream anywhere: checked NXP's own i.MX kernel fork (nxp-imx/linux-imx), no IW610 references in btusb.c on any branch -- their reference designs wire this chip differently (WiFi over SDIO per their release notes), so they never hit this. Signed-off-by: Nicolas Thibert Cc: stable@vger.kernel.org Assisted-by: LLM (Claude Sonnet 5, Anthropic) Signed-off-by: Luiz Augusto von Dentz commit a9e3760b0838299649c0d57cca44daaf40ba3c33 Author: Tejun Heo Date: Mon Sep 14 22:12:34 2026 -1000 sched_ext: Maintain an online cid mask in the scheduler arena Schedulers on the default cid mapping treat [0, nr_online_cids) as the online set and restart on hotplug. Schedulers that install their own mapping with scx_bpf_cid_override() have no way to learn which cids are online: the count no longer identifies members and the CPU-form cpumask is unusable from cid programs. This is an obvious hole in the cid API. Add scx_bpf_online_cmask(), a kernel-maintained cmask in the scheduler's arena, allocated alongside the per-CPU scratch masks and populated after the cid mapping is finalized and before ops.init(), for child schedulers too. The pointer stays valid through ops.exit() with no reference to take. It is the arena offset as a void pointer, the same form struct_ops arena arguments arrive in. The verifier types the void return as a scalar for the program's arena cast. The mask follows the SCX hotplug notifications: seeded from cpu_active_mask and updated before ops.cid_online/offline() runs, so it lags cpu_online_mask only inside a hotplug transition. Updates walk the scheduler list under the lock that also serializes unlinking. Reads are live, not atomic snapshots. Root initialization excludes hotplug. v2: Reworded the getter kerneldoc (Andrea Righi). Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit 9a0b159ff18c8f6fcf982bb81e15a9ceb14db43a Author: Tejun Heo Date: Mon Sep 14 22:12:34 2026 -1000 sched_ext: scx_qmap: Restore unused idle claims from ops.dispatch() scx_qmap tracks idle cids itself. pick_direct_dispatch_cid() claims a cid by clearing its bit and the task is inserted into that cid's local DSQ, which kicks the CPU. When the task does not arrive, for example because the insert fell back to the global DSQ after an affinity change, the CPU wakes, finds nothing and picks idle again. That is not an idle transition, so ops.update_idle() is not called and the cid stays marked busy until an unrelated task runs on it. Restore the claim from ops.dispatch(). The kick guarantees a dispatch on the kicked CPU, and when it finds nothing to run with a NULL @prev, the CPU is going back to idle. Document the pattern in ops.update_idle(), which reports only actual transitions. Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi Cc: Andrea Righi commit f6e7b42bf05b2427fb8a7a1d1c387a86638bb413 Merge: 587858367581b9 afdf35cfae0d03 Author: Linus Torvalds Date: Tue Sep 15 09:43:15 2026 -0700 Merge tag 'sysctl-7.03-fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl Pull sysctl fixes from Joel Granados: - Re-add the range check for millisecond to jiffy conversion in sysctl They where removed in d174174c6776 ("sysctl: replace SYSCTL_INT_CONV_CUSTOM macro with functions") and b96b5c6708ea ("sysctl: Replace do_proc_do{int,ulong,uint}vec with do_proc_vec") - Fix type truncation in sysctl_msec_to_jiffies Previously truncated millisecond values now get converted into MAX_JIFFY_OFFSET * tag 'sysctl-7.03-fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl: sysctl: Fix type truncation in sysctl_msec_to_jiffies sysctl: Check range in do_proc_ulong_conv_ms_jiffies sysctl: Check range in proc_dointvec_ms_jiffies_minmax commit 095858324f063dba830041f067872f0a08765d2f Author: Hao-Qun Huang Date: Sun Sep 13 03:20:49 2026 +0800 spi: virtio: Use the per-transfer bits per word virtio_spi_transfer_one() puts spi->bits_per_word into the request header, so a transfer that sets its own word size reaches the backend with the device default instead. The SPI core has already copied that default into xfer->bits_per_word when the transfer leaves it at zero, the same way it does for xfer->speed_hz, which this function already uses. Per-transfer word sizes are ordinary SPI usage. mipi_dbi, for one, sends a 9-bit command and reads the reply as 8-bit data in the same message. With a 16-bit device default, a one-byte transfer asking for 8 bits goes out as a partial 16-bit word, which the backend may reject. Fixes: f98cabe3f6cf ("SPI: Add virtio SPI driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Hao-Qun Huang Link: https://patch.msgid.link/20260913032049.11209.alvinhuang0603@gmail.com Signed-off-by: Mark Brown commit 075bc7b1d3dde5ed43fbaabbc1a69f09b7fc3a47 Author: Baineng Shou Date: Thu Sep 10 10:16:52 2026 +0800 dmaengine: mmp_pdma: fix wrong sg length in mmp_pdma_prep_slave_sg() In mmp_pdma_prep_slave_sg(), for_each_sg() iterates the scatterlist putting each entry into 'sg', but the entry length is read from 'sgl' (the list head) instead of 'sg' (the current entry): for_each_sg(sgl, sg, sg_len, i) { addr = sg_dma_address(sg); avail = sg_dma_len(sgl); /* should be 'sg' */ Consequently 'avail' is always the length of the first entry. For multi-sg lists this causes out-of-bounds reads when a later entry is shorter than the first, and silent data loss when it is longer. Single-sg or uniformly-sized lists happen to mask the issue. Fixes: c8acd6aa6bed3 ("dmaengine: mmp-pdma support") Signed-off-by: Baineng Shou Reviewed-by: Frank Li Link: https://patch.msgid.link/20260910021652.1296640-1-shoubaineng@gmail.com Signed-off-by: Vinod Koul commit 9fa26285ae70ac2d3d1b47459a6b4463ab053e1c Author: Namjae Jeon Date: Wed Sep 9 09:58:48 2026 +0900 ksmbd: keep compound responses on query info errors Do not reset the RFC1002 length of the complete response when a query info buffer is too small. The current command will add its error response through ksmbd_iov_pin_rsp(), while resetting the base length can truncate earlier responses in a compound request. This lets ksmbd return the earlier responses and the query-info error response together. Remove the now-unused rsp_org parameter from the pipe query-info helpers. Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Reported-by: Mobin Aydinfar Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon commit f4fafaf02174c32bce2f9bb4196fadf13f1fd96e Author: Namjae Jeon Date: Wed Sep 9 09:58:22 2026 +0900 ksmbd: fix partial normalized name responses Windows may request FILE_NORMALIZED_NAME_INFORMATION with an output buffer that only fits the fixed portion of the variable-length response. Treat the fixed portion as FILE_NORMALIZED_NAME_INFORMATION_SIZE so ksmbd returns STATUS_BUFFER_OVERFLOW instead of STATUS_INFO_LENGTH_MISMATCH. This avoids rejecting valid partial normalized-name responses. Fixes: 6b8b79226bc3 ("ksmbd: fix partial file information responses") Reported-by: Mobin Aydinfar Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon commit 41e81f7e3ef96594fb840445343c0ee7723aa550 Author: Tan Chi Date: Mon Sep 14 11:11:46 2026 +0800 RISC-V: KVM: Fix HSM hart status error propagation kvm_sbi_hsm_vcpu_get_status() returns SBI_ERR_INVALID_PARAM when the requested hart does not exist. However, the HART_STATUS case returns from the SBI handler without storing this error in retdata->err_val. As a result, a guest querying the status of a non-existent hart observes SBI_SUCCESS instead of SBI_ERR_INVALID_PARAM. Use the common SBI error handling path for HART_STATUS after saving a valid hart state in retdata->out_val. This preserves the returned error when kvm_sbi_hsm_vcpu_get_status() fails. Fixes: bae0dfd74e01 ("RISC-V: KVM: Modify SBI extension handler to return SBI error code") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tan Chi Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260914031146.446157-1-tanchi25@mails.ucas.ac.cn Signed-off-by: Anup Patel commit c7e2cc38c56142cdab25e6f73602a8222bf9479b Author: SeungJu Cheon Date: Tue Aug 25 17:37:19 2026 +0900 RISC-V: KVM: Fix perf-backed counter accounting across stop and read pmu_ctr_read() adds the event count returned by perf_event_read_value() to counter_val, which can accumulate the same count repeatedly across reads. kvm_riscv_vcpu_pmu_ctr_stop() also leaves counter_val stale by not folding the current event count into it. Make reads of perf-backed counters side-effect free, and use perf_event_pause() when stopping a counter to fold the current event count into counter_val while resetting it. This preserves the counter value across stop/start and lets the snapshot path use counter_val directly. Fixes: 0cb74b65d2e5 ("RISC-V: KVM: Implement perf support without sampling") Signed-off-by: SeungJu Cheon Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260825083719.643970-4-suunj1331@gmail.com Signed-off-by: Anup Patel commit 057dd2639ceae79adced5d8fe52c32d562edcb3a Author: SeungJu Cheon Date: Tue Aug 25 17:37:18 2026 +0900 RISC-V: KVM: Report snapshot write failure to the guest If kvm_vcpu_write_guest() fails while updating the PMU snapshot area on counter stop, the guest may receive SBI_SUCCESS without the snapshot being updated, leaving stale data in shared memory. Return SBI_ERR_FAILURE when the snapshot write fails. Fixes: c2f41ddbcdd7 ("RISC-V: KVM: Implement SBI PMU Snapshot feature") Signed-off-by: SeungJu Cheon Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260825083719.643970-3-suunj1331@gmail.com Signed-off-by: Anup Patel commit 8b3fd1a8b305321171602bfa7c41212441cf69e4 Author: SeungJu Cheon Date: Tue Aug 25 17:37:17 2026 +0900 RISC-V: KVM: Preserve firmware counter value across stop/start Firmware events accumulate in kvpmu->fw_event[].value while running, but counter stop only clears fw_event[].started without saving the value back to pmc->counter_val. A subsequent counter start without SBI_PMU_START_FLAG_SET_INIT_VALUE reloads the stale counter_val into fw_event[].value, losing all events counted so far. Save fw_event[].value into counter_val when actually stopping a running counter, and remove the now redundant synchronization from the snapshot path. Fixes: badc386869e2c ("RISC-V: KVM: Support firmware events") Signed-off-by: SeungJu Cheon Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260825083719.643970-2-suunj1331@gmail.com Signed-off-by: Anup Patel commit b7749531a9b195f4fd7db92ca3cc49bda1a4dc8d Author: Zongmin Zhou Date: Wed Aug 26 14:41:17 2026 +0800 RISC-V: KVM: Fix sdata leak and stale snapshot_addr in snapshot_set_shmem A guest may call SBI_PMU_SNAPSHOT_SET_SHMEM repeatedly. Each call overwrites kvpmu->sdata without freeing the old buffer (memory leak), and if a later kvm_vcpu_write_guest() fails, the error path frees sdata but leaves snapshot_addr stale. A subsequent SBI_PMU_COUNTER_START then passes the INVALID_GPA check and crashes the host with a NULL buffer in kvm_vcpu_read_guest(). Fix this by clearing the previously installed snapshot area before installing a new one, which keeps sdata and snapshot_addr consistent. The SBI spec suggests a single invocation but defines no error code for repeated calls, so KVM must tolerate them. Fixes: c2f41ddbcdd756 ("RISC-V: KVM: Implement SBI PMU Snapshot feature") Cc: stable@vger.kernel.org Signed-off-by: Zongmin Zhou Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260826064117.58029-1-min_halo@163.com Signed-off-by: Anup Patel commit b3d346838ec65fac7fd83f5dbcedd13cadfffddb Author: Zongmin Zhou Date: Wed Aug 26 15:50:09 2026 +0800 KVM: riscv: Fix NACL hfence entry update order The SBI v3.0 specification (section 15.1.2) requires a nested HFENCE entry to be populated as follows: 1) find an unused entry with Config.Pending == 0 2) update the Page_Number and Page_Count words 3) update the Config word with Config.Pending set __kvm_riscv_nacl_hfence() writes the Config word first, so the SBI implementation (or NACL hardware) can observe a pending entry with pnum/pcount values left over from the previous use of that entry, resulting in incorrect TLB flush ranges. Write pnum and pcount first and the Config word last. Since the consumer is an external agent on coherent shared memory, use WRITE_ONCE() to stop the compiler from reordering the stores and smp_wmb() to make the parameter words globally visible before the Pending bit is set. Fixes: d466c19cead5 ("RISC-V: KVM: Add common nested acceleration support") Signed-off-by: Zongmin Zhou Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260826075009.68952-1-min_halo@163.com Signed-off-by: Anup Patel commit f41fb17143df890855d3de980f8eb92dfd595817 Author: Xie Bo Date: Mon Aug 10 13:15:44 2026 +0800 RISC-V: KVM: Propagate interrupted G-stage faults __kvm_faultin_pfn() reports an interrupted host page fault with KVM_PFN_ERR_SIGPENDING. RISC-V currently handles it as a generic error PFN and returns -EFAULT. Return -EINTR for the signal-pending sentinel so callers can distinguish an interrupted fault from an invalid userspace mapping. Do not log the expected interruption as a vCPU exit error. Fixes: 9d05c1fee837 ("RISC-V: KVM: Implement stage2 page table programming") Cc: stable@vger.kernel.org Signed-off-by: Xie Bo Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260810051544.3953925-3-xb@ultrarisc.com Signed-off-by: Anup Patel commit ed54fdb460a6e81d5f8f38388d1f10b385dd4a58 Author: Xie Bo Date: Mon Aug 10 13:15:43 2026 +0800 RISC-V: KVM: Release unused page after MMU invalidation If an MMU invalidation races with a G-stage fault, the fault handler skips installing the page but leaves ret set to zero. As a result, kvm_release_faultin_page() treats the page as used and can unnecessarily mark it dirty. Track the invalidation retry separately and release the page as unused, while preserving the existing return value so that the vCPU retries the fault. Fixes: 2ed90cb0938a ("KVM: RISC-V: Retry fault if vma_lookup() results become invalid") Cc: stable@vger.kernel.org Signed-off-by: Xie Bo Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260810051544.3953925-2-xb@ultrarisc.com Signed-off-by: Anup Patel commit 8ae12ccaec6ec74945d8c1ef39f2c1b8df779abc Author: Xie Bo Date: Mon Aug 10 09:21:15 2026 +0800 RISC-V: KVM: Serialize IMSIC attributes with vCPU migration KVM device ioctls are not serialized against KVM_RUN. As a result, kvm_riscv_aia_imsic_rw_attr() can snapshot the physical CPU and HGEI of an IMSIC VS-file before a concurrent vCPU migration releases it. The HGEI can then be allocated to another vCPU before imsic_vsfile_rw() uses the stale tuple. A GET or SET attribute may consequently access the new owner's interrupt file. Serialize the entire IMSIC attribute operation with the target vCPU mutex. This prevents the VS-file from being migrated and recycled until the attribute access completes. Acquire the mutex killably so that the device ioctl remains interruptible while waiting for KVM_RUN to finish. Fixes: db8b7e97d613 ("RISC-V: KVM: Add in-kernel virtualization of AIA IMSIC") Cc: stable@vger.kernel.org Signed-off-by: Xie Bo Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260810-imsic-attr-race-v2-1-00ed95ad321e@ultrarisc.com Signed-off-by: Anup Patel commit 52c6b7d20d3e791a9e75aa2be2a467990154c7cd Author: Yicong Yang Date: Tue Aug 4 21:40:18 2026 +0800 RISC-V: KVM: Fix the conversion between vsip and hvip Per AIA spec 1.0 Section 6.3.2, the interrupt numbers 13-63 shares same bit position between related VS shadow CSRs and hypervisor CSRs. So there's a shift only for SSI, STI and SEI interrupt. Currently the KVM always does a shift for all the interrupts (include LCOFI with number 13) when doing the conversion between vsip and hvip. Fix this by only doing shift the SSI, STI and SEI. Add wrappers for doing the conversion between vsip and hvip. Fixes: 16b0bde9a37c ("RISC-V: KVM: Add perf sampling support for guests") Signed-off-by: Yicong Yang Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260804134018.85497-1-yang.yicong@picoheart.com Signed-off-by: Anup Patel commit aaad136d56d91252517272b68cd533e5714698d5 Author: Myeonghun Pak Date: Sat Aug 1 01:35:50 2026 +0900 RISC-V: KVM: Synchronize hrtimer callback during teardown The non-Sstc hrtimer callback clears next_set before its final uses of the enclosing vCPU. If teardown observes next_set as false while the callback is still running, kvm_riscv_vcpu_timer_cancel() skips hrtimer_cancel() and kvm_destroy_vcpus() can free the vCPU before the callback enters kvm_riscv_vcpu_set_interrupt(). A guest can arm the timer with SBI TIME and request shutdown with SBI legacy shutdown or SRST. A VMM that honors KVM_EXIT_SYSTEM_EVENT and destroys the VM supplies the teardown side of the race; no post-launch host ioctl is needed to arm or request teardown. On upstream master 62cc90241548, generic KASAN reported: BUG: KASAN: slab-use-after-free in do_raw_spin_lock Write of size 4 at addr ff60000005e58898 kvm_riscv_vcpu_set_interrupt kvm_riscv_vcpu_hrtimer_expired __hrtimer_run_queues hrtimer_interrupt The object was allocated by KVM_CREATE_VCPU and freed concurrently by: kvm_destroy_vcpus kvm_arch_destroy_vm kvm_destroy_vm __fput For deterministic validation, I added mdelay(1000) immediately after the existing next_set = false assignment. This only widens the existing post-clear callback window. A no-delay trace build naturally reached the callback-after-teardown-start/before-deinit ordering in 12 of 200 runs, but 1,500 stock-kernel stress iterations did not produce a KASAN report, so natural reproduction is timing-sensitive. Always invoke hrtimer_cancel() for an initialized timer. Preserve the existing -EINVAL result when the timer is no longer set, but only after synchronizing with a running callback. With this patch, hrtimer_cancel() blocked for the full widened callback window before vCPU destruction. KASAN reported no error in 100 fixed-and-widened runs or 200 fix-only timing-sweep runs. Fixes: 3a9f66cb25e1 ("RISC-V: KVM: Add timer functionality") Cc: stable@vger.kernel.org Assisted-by: OpenAI:GPT-5.6 Signed-off-by: Myeonghun Pak Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260731163550.46991-1-mhun512@gmail.com Signed-off-by: Anup Patel commit 83a945a529d6e002dd7339c532288a931f463dba Author: Eric Dumazet Date: Sat Sep 12 14:48:48 2026 +0000 tcp: do not let tcp_rmem be set below 4096 We can hit a division by zero crash in tcp_rcvbuf_grow() and tcp_rcv_space_adjust(): divide error: 0000 [#1] PREEMPT SMP RIP: 0010:tcp_rcvbuf_grow+0x187/0x450 net/ipv4/tcp_input.c:939 ... grow = div_u64(((u64)rcvwin << 1) * (newval - oldval), oldval); The division uses oldval = tp->rcvq_space.space as divisor. When tp->rcvq_space.space is zero, this leads to a divide-by-zero exception. tp->rcvq_space.space is initialized in tcp_init_buffer_space(): tp->rcvq_space.space = min3(tp->rcv_ssthresh, tp->rcv_wnd, (u32)TCP_INIT_CWND * tp->advmss); If tcp_rmem[1] is configured to very small values (such as 1), sk->sk_rcvbuf is initialized to 1. Then tcp_full_space(sk), which computes (sk->sk_rcvbuf * scaling_ratio) >> 8, truncates to 0. This sets tp->window_clamp = 0, tp->rcv_ssthresh = 0, and tp->rcvq_space.space = 0. Later, when data arrives and DRS is invoked, tcp_rcvbuf_grow() divides by oldval == 0. Back in 2015, commit b1cb59cf2efe ("net: sysctl_net_core: check SNDBUF and RCVBUF for min length") ensured that net.core.rmem_default and net.core.rmem_max cannot be set below SOCK_MIN_RCVBUF. Similarly, SO_RCVBUF setsockopt enforces max_t(int, val * 2, SOCK_MIN_RCVBUF). However, net.ipv4.tcp_rmem still had .extra1 = SYSCTL_ONE, allowing arbitrarily small values. Because SOCK_MIN_RCVBUF depends on sizeof(struct sk_buff) and cacheline alignment, its value varies across architectures and configuration options. Using a fixed constant of 4096 ensures a predictable, architecture- independent lower bound that is safely above SOCK_MIN_RCVBUF everywhere and matches the documented 4K default. Fix this by setting tcp_rmem.extra1 to 4096 and updating the documentation. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260912144848.3448026-1-edumazet@google.com Signed-off-by: Paolo Abeni commit 8e759cd1f6444a946bd1fd2b2b29eea582eea1d5 Author: Kuniyuki Iwashima Date: Mon Sep 14 01:14:01 2026 +0000 tcp: Don't call skb_clone_and_charge_r() for close()d listener in tcp_v6_do_rcv(). tcp_v6_do_rcv() no longer calls skb_clone_and_charge_r() for TCP_LISTEN since commit 073d89808c06 ("net: fix data-races around sk->sk_forward_alloc"). However, there is still a small race window between tcp_v6_rcv() and tcp_v6_do_rcv(), where concurrent close() changes TCP_LISTEN to TCP_CLOSE, causing skb_clone_and_charge_r() to be called locklessly and resulting in the splat below. [0] Let's avoid calling skb_clone_and_charge_r() for TCP_CLOSE as well. This is fine for non-listeners because tcp_rcv_state_process() drops skb for TCP_CLOSE and opt_skb was freed immediately anyway. [0]: sk->sk_forward_alloc WARNING: net/ipv4/af_inet.c:162 at inet_sock_destruct+0x64d/0x810 net/ipv4/af_inet.c:162, CPU#1: ksoftirqd/1/28 Modules linked in: CPU: 1 UID: 0 PID: 28 Comm: ksoftirqd/1 Not tainted 7.2.0 #17 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x64d/0x810 net/ipv4/af_inet.c:162 Code: 3d 49 ff e9 06 fd ff ff e8 d0 5b 83 f8 90 0f 0b 90 e9 35 fe ff ff e8 c2 5b 83 f8 90 0f 0b 90 e9 c5 fe ff ff e8 b4 5b 83 f8 90 <0f> 0b 90 e9 04 ff ff ff e8 a6 5b 83 f8 90 0f 0b 90 e9 65 fe ff ff RSP: 0018:ffffc90000677bb8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880117bde80 RCX: ffffffff8957eb41 RDX: ffff88801dad5d00 RSI: ffffffff8957ec3c RDI: 0000000000000005 RBP: 00000000fffff000 R08: ffffffff8957eb41 R09: 00000000fffff000 R10: 0000000000000005 R11: 0000000000000000 R12: dffffc0000000000 R13: ffff8880117bdf10 R14: ffffffff81c08eb7 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8880d7ae5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f93a1021138 CR3: 00000000207a9000 CR4: 0000000000350ef0 Call Trace: __sk_destruct+0x82/0xae0 net/core/sock.c:2356 rcu_do_batch kernel/rcu/tree.c:2645 [inline] rcu_core+0x59c/0x1100 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9b0 kernel/softirq.c:622 run_ksoftirqd kernel/softirq.c:1076 [inline] run_ksoftirqd+0x38/0x60 kernel/softirq.c:1068 smpboot_thread_fn+0x458/0xc80 kernel/smpboot.c:160 kthread+0x396/0x4a0 kernel/kthread.c:436 ret_from_fork+0x8e0/0xe40 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fixes: e994b2f0fb92 ("tcp: do not lock listener to process SYN packets") Reported-by: Taras Madan Signed-off-by: Kuniyuki Iwashima Reviewed-by: Xuanqiang Luo Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260914011420.115556-1-kuniyu@google.com Signed-off-by: Paolo Abeni commit ba13f1f32d96d7ce9069ae4f32404ecde8da89c4 Author: Meijing Zhao Date: Tue Sep 15 20:46:41 2026 +0800 mm: memblock: add missing HugeTLB flag name Commit 7d163a75f821 ("memblock: make HugeTLB bootmem allocation work with KHO") added MEMBLOCK_RSRV_HUGETLB but did not add the corresponding entry to flagname[]. As a result, memblock debugfs cannot report the flag by name. Add the missing RSV_HUGETLB entry. Fixes: 7d163a75f821 ("memblock: make HugeTLB bootmem allocation work with KHO") Signed-off-by: Meijing Zhao Signed-off-by: Wandun Chen Link: https://lore.kernel.org/lkml/20260821020910.3428585-2-zhaomeijing100@gmail.com/ Link: https://patch.msgid.link/20260915124641.2498280-1-chenwandun1@gmail.com Signed-off-by: Mike Rapoport (Microsoft) commit 0654f4dba1fbc697f2653aba30cd68587fcbf10e Author: Jamal Hadi Salim Date: Sat Sep 12 14:09:20 2026 -0400 selftests/tc-testing: add hhf hh_limit cap tests Cover the new TCA_HHF_HH_FLOWS_LIMIT bound: values above 2*HH_FLOWS_CNT (4294967295, 65536, 2049) are rejected with the configured limit left untouched on both the change and the add path, the boundary value 2048 is accepted (installed at 100 first so the boundary change is load-bearing), and an add-time hh_limit 500 is preserved instead of being clobbered by the default. Reviewed-by: Victor Nogueira Tested-by: hybris Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-B855.v1.20260911153152@mojatatu.com.2 Signed-off-by: Paolo Abeni commit 2cef2588c995722a901368def30befeef9ae55c6 Author: Jamal Hadi Salim Date: Sat Sep 12 14:09:19 2026 -0400 net/sched: hhf: cap hh_flows_limit at change time hhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge hh_flows_limit lets each new heavy-hitter flow pass the hh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size kzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory growth. Bound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the hhf_init() default) and report the rejected value via extack. The deprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on TCA_OPTIONS. Configs relying on hh_limit above the default were relying on unbounded, unsafe behaviour and are not supported going forward. hhf_init() also ran hhf_change() before setting the default hh_flows_limit, so a user-supplied hh_limit at add time was clobbered back to 2048. Set the default before hhf_change() so the configured value sticks. This is a follow-up to commit eb56a495f59b ("net/sched: hhf: clamp quantum in change and init paths"), which bounded the quantum of the same qdisc; the hh_flows_limit bound is the remaining unbounded knob of that series' scope. Conditions to recreate the bug: CAP_NET_ADMIN in a user namespace; tc qdisc change dev X root hhf hh_limit 4294967295 succeeds and the value is echoed by tc qdisc show, unbounding heavy-hitter flow allocations; also tc qdisc add dev X root hhf hh_limit 500 stores 2048 instead of 500. Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Cc: stable@vger.kernel.org Reported-by: Sashiko (gemini) Closes: https://sashiko.dev/#/patchset/20260822195509.112717-1-jhs@mojatatu.com Reviewed-by: Victor Nogueira Tested-by: hybris Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-B855.v1.20260911153152@mojatatu.com Signed-off-by: Paolo Abeni commit 18a6fe05fb6e18de29fa90d388bb34044114b3d8 Author: Nikolay Aleksandrov Date: Fri Sep 11 13:50:21 2026 +0300 net: bridge: mst: move switchdev call outside rcu This is a follow-up of one of sashiko's pre-existing bug reports. br_mst_set_state() calls switchdev_port_attr_set() for nonzero MSTIs while holding rcu_read_lock() which invokes the blocking switchdev notifier chain and may sleep. Nonzero MSTI changes come from netlink with rtnl held. Move the switchdev call before entering the rcu section and assert that rtnl is held. The call cannot be deferred because netlink needs its error and extack. Also DSA reads the old bridge MST state during the callback and checks it. A deferred callback will be late and will see the updated state. Fixes: 3a7c1661ae13 ("net: bridge: mst: fix vlan use-after-free") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260911105021.1385934-1-razor@blackwall.org Signed-off-by: Paolo Abeni commit 1eeca1d5e0920fbdad6449768fd2d4364e714180 Author: Jiangshan Yi Date: Sat Aug 15 20:10:43 2026 +0800 wifi: brcmsmac: fix UAF in brcms_free_timer() brcms_free_timer() calls brcms_del_timer() which uses the non-synchronous cancel_delayed_work() to cancel the timer's underlying delayed work. If the work callback (_brcms_timer) is already running, cancel_delayed_work() returns false without waiting, and brcms_free_timer() proceeds to kfree(t) while the callback still accesses t through container_of(). Add an explicit cancel_delayed_work_sync() after brcms_del_timer() to guarantee that any in-flight callback has completed before the timer structure is freed. Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260815121043.938414-1-yijiangshan@kylinos.cn Signed-off-by: Johannes Berg commit 621d90169cef6c8da5b6134db5c0c4e23cdd09ce Author: Karl Mehltretter Date: Tue Aug 11 10:27:02 2026 +0200 wifi: brcmfmac: fix lost 802.1x TX completion wakeup brcmf_txfinalize() decrements pend_8021x_cnt before a lockless waitqueue_active() check. atomic_dec() does not order the decrement against the check. The waiter can therefore observe a nonzero count while the waker observes an empty queue, losing the final wakeup and delaying key installation until the 950 ms timeout. Add smp_mb__after_atomic() to order the decrement before the queue check. wait_event_timeout() provides the matching barrier. LKMM confirms that this forbids the lost-wakeup outcome. Fixes: 21fff75d2fb6 ("brcmfmac: use wait_event_timeout for 8021x pending count") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260811082702.44521-1-kmehltretter@gmail.com Signed-off-by: Johannes Berg commit 769ec67d0abc64c7f716d16e9826c8ae2c5264c2 Merge: 2b04d6556964ae 820b8cff81c796 Author: Johannes Berg Date: Tue Sep 15 11:50:57 2026 +0200 Merge tag 'ath-current-20260914' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git update for v7.3-rc4 In ath12k: revert an undocumented and unapproved DT ABI that was added during the v7.3 merge window. In wcn36xx and ath11k: fix preexisting object lifetime issues. ================== Signed-off-by: Johannes Berg commit 82e47533221d4746947b74d2e79a478c36c6433a Author: Niklas Cassel Date: Fri Sep 4 15:43:11 2026 +0200 ata: libahci: clear PxCLBU and PxFBU for AHCI_HFLAG_32BIT_ONLY A user reported that commit 105c42566a55 ("ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585") made the JMicron JMB585 unusable on his board. The failure is seen as soon as the ahci driver is probed, and booting with iommu=off does not solve the problem. Looking at the AHCI specification, PxCLBU and PxFBU are both read only '0' for HBAs that do not support 64-bit addressing. For HBAs that do support 64-bit addressing, the registers are read write, with a reset value that is Implementation Specific. When using the AHCI_HFLAG_32BIT_ONLY flag, the HBA does support 64-bit addressing, and a 32-bit DMA mask is set by simply clearing HOST_CAP_64. Thus, in this case, we need to explicitly clear the registers to 0. Fixes: 105c42566a55 ("ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585") Fixes: c7a42156d99b ("ahci: disable 64bit dma on sb600") Cc: stable@vger.kernel.org Reported-by: Roland Waltersson Closes: https://lore.kernel.org/linux-ide/IA0PR17MB668730A4ECCD65F7A1DC3EDC9EB62@IA0PR17MB6687.namprd17.prod.outlook.com/ Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260904134310.1465051-2-cassel@kernel.org Signed-off-by: Niklas Cassel commit 2f3c2a6f963e57cf4f0f34cbf24ab11abb64d118 Author: Hemanth Selam Date: Fri Sep 11 13:00:07 2026 +0530 xfs: fix typos and repeated words in comments Correct ten misspellings and eight accidentally doubled words in comments. No code changes. The doubled word in xfs_zone_alloc.c was not a duplicate: "so that is is reused" is "it is" misspelt, so that one reads "so that it is reused" rather than dropping a word. Signed-off-by: Hemanth Selam Reviewed-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit 7c8810c2e69c3d9ca6df870b40ae9218e50b4fb1 Author: Hohyun Sim Date: Thu Sep 10 15:37:43 2026 +0900 net: fddi: skfp: fix NULL deref when setting the MAC address while down skfp_ctl_set_mac_address() calls ResetAdapter() unconditionally, without checking netif_running(). ResetAdapter() first calls card_stop(), which sets smc->hw.hw_state to STOPPED, and then mac_drv_clear_tx_queue(), which walks the two transmit queues: for (i = QUEUE_S; i <= QUEUE_A0; i++) { queue = smc->hw.fp.tx[i] ; ... t = queue->tx_curr_get ; smc->hw.fp.tx[] is only populated by init_tx(), which is reached from skfp_open() through init_smt() -> init_fddi_driver() -> init_fplus() -> init_mac() -> init_tx(). The private area is allocated and zeroed by alloc_fddidev(), so on an interface that has never been brought up both queue pointers are still NULL. The hw_state test at the top of mac_drv_clear_tx_queue() does not catch this, because card_stop() has just set STOPPED; the function proceeds into the loop and dereferences NULL. ResetAdapter() does call init_smt() itself, but only after the queues have been cleared. Setting the MAC address on a down interface therefore oopses: ip link set dev fddi0 address 02:00:00:00:00:01 BUG: KASAN: null-ptr-deref in mac_drv_clear_tx_queue+0x68/0x2c0 [skfp] Read of size 8 at addr 0000000000000010 by task ip/302 Call Trace: mac_drv_clear_tx_queue+0x68/0x2c0 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] ResetAdapter+0x29/0x100 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] skfp_ctl_set_mac_address+0x57/0x80 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] netif_set_mac_address+0x1e4/0x2c0 do_setlink+0x684/0x2680 Address 0x10 is the offset of tx_curr_get, the third pointer in struct s_smt_tx_queue, on 64-bit. mac_drv_clear_rx_queue(), which ResetAdapter() calls immediately afterwards, dereferences smc->hw.fp.rx[QUEUE_R1] in the same way behind the same ineffective hw_state test; the transmit queue merely crashes first. Both are covered by the guard below. Skip the adapter reset when the interface is down. dev_addr_set() is left unconditional, so the new address is still recorded in dev->dev_addr. Nothing is lost by not resetting the adapter here: skfp_open() deliberately re-reads the factory address on every open, read_address(smc, NULL); eth_hw_addr_set(dev, smc->hw.fddi_canon_addr.a); and the comment above it states this is done to discard exactly such an address override across a close/open cycle. An address set while the interface is down could not have survived the following open even before this change, so the guard removes no working behaviour. Guarding the hardware side of ndo_set_mac_address() with netif_running() is established practice; skge_set_mac_address() has done so since commit 2eb3e621c4e0 ("skge: set mac address bonding fix"). Guarding the reset as a whole, rather than NULL-checking the queues, is also what the rest of the driver expects. After a previous open/close the queue pointers are stale but non-NULL, so there is no crash, yet ResetAdapter() goes on to call smt_online() and STI_FBI() ("Enable Board Interrupts") while skfp_close() has already called free_irq() - the adapter would be brought back online with no handler installed. The only other ResetAdapter() caller is skfp_interrupt(), which by construction runs only while the device is open. Found by automated driver testing against an emulated SysKonnect FDDI adapter under a KASAN-enabled 7.0.0 kernel. Triggering it requires CAP_NET_ADMIN. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: LLM KASAN Signed-off-by: Hohyun Sim Link: https://patch.msgid.link/20260910063743.110747-1-tlaghgus0425@korea.ac.kr Signed-off-by: Paolo Abeni commit 2998147b59c9df0a51477c7a6b3d1f0ba3127dd4 Author: Dong Chenchen Date: Thu Sep 10 22:00:42 2026 +0800 ipv4: icmp: reject RTN_UNREACHABLE input routes in icmp_route_lookup When the forward output route cannot be used in icmp_route_lookup(), it enters the "reverse path" and calls ip_route_input() on fl4_dec.daddr, the original packet's source address. ip_route_input() only returns an error for truly invalid packets. For unreachable addresses it will succeed and return an input route whose dst.output is set to ip_rt_bug(). The existing check only rejects RTN_LOCAL routes, so the RTN_UNREACHABLE route types can still be returned and later used for output, syzkaller triggering a WARN_ON_ONCE() in ip_rt_bug() as bellow: ------------[ cut here ]------------ WARNING: net/ipv4/route.c:1273 at ip_rt_bug+0x14/0x20 RIP: 0010:ip_rt_bug+0x14/0x20 Call Trace: ip_push_pending_frames+0xfa/0x100 __icmp_send+0x905/0xf10 ip_options_compile+0xc0/0xd0 ip_rcv_finish_core+0x321/0xae0 ip_rcv+0x1de/0x260 __netif_receive_skb_one_core+0x11a/0x130 netif_receive_skb+0x7b/0x260 tun_get_user+0x11bf/0x1c10 ------------[ cut here ]------------ Reject input route that is RTN_UNREACHABLE to fix it. The net warning is only printed for RTN_LOCAL, as RTN_UNREACHABLE is not the result of a race condition. Fixes: 8b7817f3a959 ("[IPSEC]: Add ICMP host relookup support") Suggested-by: Ido Schimmel Reviewed-by: Jiayuan Chen Reviewed-by: Ido Schimmel Signed-off-by: Dong Chenchen Link: https://patch.msgid.link/20260910140042.1880242-1-dongchenchen2@huawei.com Signed-off-by: Paolo Abeni commit c16b885ad6b589b233534ee99ade82110d2bc381 Author: Anuj Gupta Date: Fri Sep 4 18:06:41 2026 +0530 xfs: remove unused xfs_reflink_remap_range declaration The implementation was inlined into xfs_file_remap_range() by commit 3fc9f5e40931 ("xfs: remove xfs_reflink_remap_range"), leaving this declaration orphaned. Signed-off-by: Anuj Gupta Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino commit ce2b91bebc7bc0495fe3ad5ee47e4977fbb77fc5 Author: Jiangshan Yi Date: Mon Sep 14 16:21:11 2026 +0800 xfs: remove duplicate INO1_WRITTEN check 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 commit ee415ce8cba154d07d02a6d2fbb27ff518264c3a Author: Luca Coelho Date: Tue Sep 8 13:06:51 2026 +0300 drm/i915/display: check configuration index before shifting The calc_allowed_config_filter() function passes the return value of iter_pos_to_idx() directly to BIT(), but the helper can return -1 for an invalid iterator. The iterator already rejects negative indices before doing a configuration, so this should not matter in normal flows. In any case, for robustness, check the index explicitly and warn if it is negative, avoiding an undefined shift. Fixes: 39e30bdf2f92 ("drm/i915/dp_link_caps: Add link configuration iterator") Reviewed-by: Imre Deak Link: https://patch.msgid.link/20260908100659.113555-1-luciano.coelho@intel.com Signed-off-by: Luca Coelho (cherry picked from commit fe05cb9b9fb0ecc10409c4c6133257214b6cd8c8) Signed-off-by: Jani Nikula commit 14e379600d3e57ab0872b049c28cfe5ef519d439 Author: Christoph Hellwig Date: Mon Sep 14 13:35:38 2026 +0200 xfs: don't try to get a reference to a NULL oz in xfs_get_cached_zone oz can be NULL when we resample it after taking i_flags_lock, so account for that. Fixes: 2d829cc76777 ("xfs: fix racy open zone caching") Signed-off-by: Christoph Hellwig Reviewed-by: Hans Holmberg Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit e9193f2f1ce32d02b9230094ffdbfab715ab6137 Author: Darrick J. Wong Date: Thu Sep 10 22:54:58 2026 -0700 xfs: check di_forkoff correctly in scrub The di_forkoff check in xchk_dinode is incorrect, according to LOLLM. XFS_DFORK_BOFF returns a byte count relative to the start of the literal area, not the start of the inode. Therefore, this check won't flag di_forkoff values that are larger than the literal area but not the inode size itself. Fix this check; sadly the old APTR code was correct. Cc: stable@vger.kernel.org # v6.8 Fixes: 6b5d917780219d ("xfs: dont cast to char * for XFS_DFORK_*PTR macros") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit c54110d814c3e8ed6bbbb5e02874994ed9f668ac Author: Darrick J. Wong Date: Thu Sep 10 22:54:42 2026 -0700 xfs: only flag zero padding for dir3 data blocks, not dir3 block blocks LOLLM complains that xchk_directory_data_bestfree can be passed a directory block that is either in "block" or "data" format, but the check here unconditionally treats the dir3_block and dir3_data blocks as if they have the same header format (they don't). Consequently, we can incorrectly set the preen state on dir3_block blocks, which of course we can't preen away because dir3_block blocks do not have a padding field. Fix this. Cc: stable@vger.kernel.org # v7.1-rc4 Fixes: 939919ccddfcc3 ("xfs: check directory data block header padding in scrub") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 46c1b6674a7b3a8385e7fa27f4efc6f45eddf967 Author: Darrick J. Wong Date: Thu Sep 10 22:54:26 2026 -0700 xfs: fix integer overflows in xbitmap set functions LOLLM complains that the xbitmap set functions can suffer an integer underflow or overflow and thereby return the wrong left and right pointers. Fix that logic bomb, even though (AFAICT) we never actually try to set the *entire* bitmap. Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 471e0b6e2ddac9e16b8dc2153d6e5575fefb8a2f Author: Darrick J. Wong Date: Thu Sep 10 22:54:11 2026 -0700 xfs: use the correct reservations for rtrmap/refcount recovery LOLLM noticed that we might reserve the wrong number of blocks for recovering rtrmap and rtrefcount updates after a crash. Fix that. Cc: stable@vger.kernel.org # v6.14 Fixes: 5e0679d1c62f25 ("xfs: support recovering rmap intent items targetting realtime extents") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 8fc18580ec17f90beac4c933fbe4c74dcd3b7f36 Author: Darrick J. Wong Date: Thu Sep 10 22:53:55 2026 -0700 xfs: don't call xfs_exchange_range_finish for a dry run LOLLM noticed that we strip file privileges and whatnot even for a dry run. We also shouldn't flush dirty data to disk or trim COW staging events for a dry run. Neither of those behaviors are allowed by the manpage, so fix that by exiting early on DRY_RUN in various functions. Cc: stable@vger.kernel.org # v6.10 Fixes: 42672471f938cd ("xfs: bind together the front and back ends of the file range exchange code") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 3083ba8dde765a9ab2337f3db68d00724a6b1202 Author: Darrick J. Wong Date: Thu Sep 10 22:53:39 2026 -0700 xfs: check padding field in xfs_ioc_commit_range LOLLM points out that we don't check the ioctl padding field here, so let's do that. I don't think there are many users yet since exchrange requires a new feature flag, so it's a good time to try to plug this hole. Cc: stable@vger.kernel.org # v6.12 Fixes: 398597c3ef7fb1 ("xfs: introduce new file range commit ioctls") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 984aab2d905a8557fafb27cd9e8713d6d12b3437 Author: Darrick J. Wong Date: Wed Sep 9 23:01:18 2026 -0700 xfs: use correct jiffies comparison function in xchk_maybe_relax LOLLM points out that we're supposed to use time_after_eq, not a raw >= operation here, or else jiffies wraps can go unnoticed. Fix this. Cc: stable@vger.kernel.org # v6.10 Fixes: 271557de7cbfde ("xfs: reduce the rate of cond_resched calls inside scrub") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 8b4ad2814274d43ed8bdfcf857efb8c79815d9c6 Author: Darrick J. Wong Date: Wed Sep 9 23:01:03 2026 -0700 xfs: release AGFL after walking it during rmapbt repair LOLLM suggests that we not hold the AGFL locked to the scrub transaction for any longer than we have to when we're rebuilding the rmapbt. Since we only took it to generate an rmap record for the AGFL blocks, I think we can safely release it. Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 1c32cdc986467eaffeedb6c5334852809555b82d Author: Darrick J. Wong Date: Wed Sep 9 23:00:47 2026 -0700 xfs: release orphanage dir inode if chown fails LOLLM points out that we leak the igrab'd reference to the orphanage directory inode if chowning it fails. Fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: 1e58a8ccf2597c ("xfs: move orphan files to the orphanage") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit bb991b7f79dd34cc5f24db0f736bf75630c970e7 Author: Darrick J. Wong Date: Wed Sep 9 23:00:31 2026 -0700 xfs: fix attr fork block count checks in xrep_inode_blockcounts LOLLM points out that a file has an attr fork, it will call xchk_inode_count_blocks to set @ablocks to the number of fsblocks mapped by the attr fork; but then it'll compare @blocks (aka the count of fsblocks mapped by the data fork). We already checked that and we never do anything with @acount, so I think this is clearly a bug. Fix the comparison. Cc: stable@vger.kernel.org # v6.8 Fixes: 2d295fe65776d1 ("xfs: repair inode records") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit afbccf99f7f82117cba9ad4b0b006692030f49e8 Author: Darrick J. Wong Date: Wed Sep 9 23:00:16 2026 -0700 xfs: don't assert when XFS_SCRUB_TYPE_HEALTHY scans return corruption XFS_SCRUB_TYPE_HEALTHY is a synthentic scrub type so that xfs_scrub can tell the kernel "Hey, I finished a scan and saw no problems" and have the kernel forget that it saw indirect evidence of corruption. Unfortunately, as LOLLM points out, it's possible for the health system to record a new corruption just before xfs_scrub gets to XFS_SCRUB_TYPE_HEALTHY. In this case, the existing logic doesn't return early and instead wanders into unknown regions of type_to_health_flag and trips the assert because HEALTHY doesn't have a group assignment. Fix the logic so that we always return early for a HEALTHY scrub type, even if we decide not to call xchk_mark_all_healthy. Cc: stable@vger.kernel.org # v6.9 Fixes: a1f3e0cca41036 ("xfs: update health status if we get a clean bill of health") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 5b644229bd677d52c4efa5973c1fab842c57f896 Author: Darrick J. Wong Date: Wed Sep 9 22:59:59 2026 -0700 xfs: guard against igrab failure in xrep_findparent_from_dcache LOLLM suggests that we need to handle igrab returning NULL here. I don't think it's possible for the inode to enter I_FREEING or I_WILL_FREE while we have an active reference to the corresponding dentry, but we can code defensively anyway. Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 3ed11c671ff7ec58c8fd96410233c677df23f407 Author: Christian König Date: Fri Sep 4 10:26:13 2026 +0200 dma-buf/dma-fence: fix checking signaling bit for timeline and driver name v3 The patch "dma-buf: dma-fence: Fix potential NULL pointer dereference" changed the check to test for the ops pointer instead of the signaled bit to avoid a potential NULL dereference when the ops pointer has been cleared. The problem is now that the ops pointer is cleared only when neither the release nor the wait callback is implemented and this isn't true for a lot of dma_fence implementations yet. So those implementations lost the RCU protection after signaling of the returned string resulting in potential use after free. Add the signaling check additional to the ops pointer check so that we have both the protection against NULL dereference as well as the RCU protection after signaling for the returned string. v2: improve comments to note RCU protection and explain why we check both signaling state and ops pointer v3: some comment improvements suggested by Philip Signed-off-by: Christian König Fixes: 035219a760ed ("dma-buf: dma-fence: Fix potential NULL pointer dereference") CC: stable@vger.kernel.org # 7.2+ Reported-by: Jonghyuk Kim(MalHyuk) Tested-by: Jonghyuk Kim(MalHyuk) Reviewed-by: Philipp Stanner Link: https://lore.kernel.org/r/20260914182740.1587-1-christian.koenig@amd.com commit afdf35cfae0d039a4a6c907fa5d8391f1ef0a0aa Author: Joel Granados Date: Thu Sep 10 12:22:16 2026 +0200 sysctl: Fix type truncation in sysctl_msec_to_jiffies Return MAX_JIFFY_OFFSET for all the values truncated when val (u64) is passed to msecs_to_jiffies (u32). This aligns with how very large millisecond values get translated into MAX_JIFFY_OFFSET. Fixes: b96b5c6708ea ("sysctl: Replace do_proc_do{int,ulong,uint}vec with do_proc_vec") Suggested-by: Kuniyuki Iwashima Signed-off-by: Joel Granados commit 318012c56576e09806747f64f89f8f3cde1f999f Author: Kuniyuki Iwashima Date: Sat Sep 5 23:36:31 2026 +0000 sysctl: Check range in do_proc_ulong_conv_ms_jiffies Add the range check back to do_proc_ulong_conv_ms_jiffies that commit b96b5c6708ea ("sysctl: Replace do_proc_do{int,ulong,uint}vec with do_proc_vec") incorrectly removed. Append "_minmax" to the end of do_proc_ulong_conv_ms_jiffies so it is clear that there should be a range check. Fixes: b96b5c6708ea ("sysctl: Replace do_proc_do{int,ulong,uint}vec with do_proc_vec") Signed-off-by: Kuniyuki Iwashima Signed-off-by: Joel Granados commit 82431877d837a6c2593efd8e66ba28b35a220ca4 Author: Kuniyuki Iwashima Date: Sat Sep 5 23:36:30 2026 +0000 sysctl: Check range in proc_dointvec_ms_jiffies_minmax Add the range check to do_proc_int_conv_ms_jiffies_minmax that commit d174174c6776 ("sysctl: replace SYSCTL_INT_CONV_CUSTOM macro with functions") incorrectly removed. Fixes: d174174c6776 ("sysctl: replace SYSCTL_INT_CONV_CUSTOM macro with functions") Signed-off-by: Kuniyuki Iwashima Signed-off-by: Joel Granados commit 23ca4ddc4fce2c233a49e9fd34d4b5b02bd7324e Author: Nicolai Buchwitz Date: Sun Sep 13 21:00:52 2026 +0200 net: bcmgenet: restore the hardware filters on open bcmgenet_hfb_init() runs INIT_LIST_HEAD() on priv->rxnfc_list, which drops every rule off the list, and bcmgenet_open() calls it on each ifup. Every rule the user configured is silently lost: # ethtool -N eth0 flow-type ether dst $MAC action 0 Added rule with ID 0 # ethtool -n eth0 | grep -c Filter: 1 # ip link set eth0 down && ip link set eth0 up # ethtool -n eth0 | grep -c Filter: 0 Initialise the lists once at probe and restore the rules on open, as bcmgenet_resume() already does. Fixes: 3e370952287c ("net: bcmgenet: add support for ethtool rxnfc flows") Signed-off-by: Nicolai Buchwitz Reviewed-by: Justin Chen Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260913190052.939955-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski commit 9e92ad4630f5dd1838ce6bbe6b1bd2c73d34de36 Author: Daniel Golle Date: Thu Sep 10 14:13:15 2026 +0100 net: dsa: mxl862xx: disable the stats poll on teardown mxl862xx_setup() arms the stats poll before mxl862xx_setup_mdio(), and nothing stops it until dsa_register_switch() has returned an error to mxl862xx_probe(). DSA frees the dsa_port list before it returns, so a poll that fires once .setup or a later step of dsa_tree_setup() has failed walks freed ports. On shutdown the user ports stay registered, and the WORK_STOPPED flag test in mxl862xx_get_stats64() is not atomic with the cancel in mxl862xx_shutdown(), so a re-arm that read the flag before it was set queues the poll after cancel_delayed_work_sync() has returned. Arm the poll once .setup has succeeded and stop it from a .teardown op, which DSA calls on unregister and after a failed registration, in both cases before it frees the ports. Use disable_delayed_work_sync() there and in shutdown(): it drains a running poll as the cancel did and turns every later attempt to queue the work into a no-op, so the re-arm cannot bring the poll back. remove() and the probe error path only set WORK_STOPPED, which crc_err_work tests before it walks the ports. Fixes: a21d33a5265f ("net: dsa: mxl862xx: implement .get_stats64") Signed-off-by: Daniel Golle Link: https://patch.msgid.link/1eb6f7fc1789b67e4b11e3f4d5ff080d0b6f7cbb.1789045590.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski commit 7616242a2b37883f7322aaa1d2bd6cd0fed28315 Author: Andrea Mayer Date: Sun Sep 13 21:44:21 2026 +0200 seg6: set IPSKB_L3SLAVE from IP6SKB_L3SLAVE on IPIP decapsulation When an SRv6 packet arrives on an interface enslaved to a VRF, vrf_ip6_rcv() sets IP6SKB_L3SLAVE in IP6CB, but decap_and_validate() has never set IPSKB_L3SLAVE in IPCB. The bit stayed clear in the common case, and with CONFIG_IPV6_MIP6 the leftover frag_max_size of a reassembled outer packet could even set it, with no VRF involved. Commit 44930446dde4 ("ipv6: seg6: clear IPv4 control block on IPIP decapsulation") then made the unreliable bit reliably clear. The effect of the missing flag is visible with End.DX4 when a delivery to a local address of the node reaches the socket lookup. For example, a UDP socket bound to the enslaved ingress interface does not receive any of the decapsulated packets, while an unbound socket outside the VRF does. This contradicts Documentation/networking/vrf.rst: by default the scope of an unbound UDP or TCP socket is limited to the default VRF. Set IPSKB_L3SLAVE for IPv4 in decap_and_validate(), which already does the same for IPv6. The socket lookup then matches the decapsulated packet like any other packet received on that enslaved interface. Such a packet matches an unbound UDP or TCP socket only when udp_l3mdev_accept or tcp_l3mdev_accept is set. Fixes: 891ef8dd2a8d ("ipv6: sr: implement additional seg6local actions") Signed-off-by: Andrea Mayer Reviewed-by: David Ahern Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260913194421.31-1-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski commit bde5212360bd44506edec073ebbd6d0c72f75820 Author: Ahmed Naseef Date: Sat Sep 12 17:43:06 2026 +0400 net: phy: mediatek: do not report link and per-speed LED rules together mtk_phy_led_hw_ctrl_get() reports TRIGGER_NETDEV_LINK whenever any of the speed bits in on_set is on, and in addition reports every individual TRIGGER_NETDEV_LINK_* bit that is set. The netdev trigger refuses that combination: netdev_led_attr_store() rejects TRIGGER_NETDEV_LINK together with any per-speed rule, and it validates the whole resulting mode rather than just the bit being written. Once the hardware has any link bit programmed, every write to the trigger attributes of that LED therefore fails with -EINVAL and the LED can no longer be configured. The rules are also fed back into the hardware: the trigger stores what is read back, and a later write of device_name programs it again, expanding TRIGGER_NETDEV_LINK to every speed in on_set. An LED configured for a single speed is thereby silently widened to "on at any link speed". Both are easy to see on the EcoNet EN7528, whose four PHYs share one LED block. The first LED programs the block correctly, the second reads those rules back and rewrites them widened, and the remaining two then read the widened value, so an LED configured for "link_10 link_100" ends up lit on a 1000 Mbps link. on_set holds every speed the LED can indicate and is exactly what mtk_phy_led_hw_ctrl_set() programs for TRIGGER_NETDEV_LINK, so report the speed independent rule only when all of them are on, and the individual speeds otherwise. The mapping is then the inverse of the one used when programming the LED and round trips without changing the register. Fixes: c66937b0f8db ("net: phy: mediatek-ge-soc: support PHY LEDs") Cc: stable@vger.kernel.org Signed-off-by: Ahmed Naseef Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260912134306.3544329-1-naseefkm@gmail.com Signed-off-by: Jakub Kicinski commit 6fb0a9d9071f1ff0cc5cfc0782302d9c90d642cb Author: Chunfeng Song Date: Thu Sep 10 05:51:10 2026 +0000 rust: net: phy: fix off-by-one bit positions in device status accessors The hand-written bitfield offsets in is_link_up(), is_autoneg_enabled() and is_autoneg_completed() were correct when the abstraction was merged: at that time autoneg, link, and autoneg_complete were at bits 13, 14, and 15 of struct phy_device's first bitfield unit. Commit 2796ff1e3dca ("net: phy: add flag is_genphy_driven to struct phy_device") later inserted is_genphy_driven just before autoneg, shifting the three fields up by one, so the accessors now read: is_link_up() reads bit 14 = autoneg is_autoneg_enabled() reads bit 13 = is_genphy_driven is_autoneg_completed() reads bit 15 = link The official ax88796b Rust driver uses all three accessors in its read_status() implementation, so it inherits the bug. phy_attach_direct() sets is_genphy_driven only when it falls back to the generic driver, and ax88796b has a real driver, so is_genphy_driven stays 0. The broken is_autoneg_enabled() therefore reads bit 13 as 0, compares it against AUTONEG_ENABLE (1), and always returns false, so read_status() never reaches the resolve_aneg_linkmode() call. The ordinary bindgen accessors take &self. Calling them through (*phydev).link() would create a shared reference to the complete bindings::phy_device, which is not appropriate for an object wrapped in Opaque. Use the bindgen-generated raw accessors (link_raw(), autoneg_raw(), and autoneg_complete_raw()) instead. They retain the bit positions and endianness handling generated from the C layout without creating a Rust reference to the complete phy_device. Drop the hand-written numbers together with the TODO comment that marked them as a stopgap. The raw accessors are only emitted by bindgen 0.71 and later, and were added at the Rust-for-Linux project's request, so this fix can only be backported to stable branches whose minimum bindgen version is at least that, hence the scope on the Cc: stable line below. Found by a static equivalence audit (C2RustDrv, a C-to-Rust driver migration tool) that compares hand-written bitfield offsets against the bindgen layout of struct phy_device. Verified by building the bindings and checking the generated accessors; no runtime testing was possible without PHY hardware. Fixes: 2796ff1e3dca ("net: phy: add flag is_genphy_driven to struct phy_device") Cc: stable@vger.kernel.org # Only 7.1.y and later (requires bindgen's raw pointer accessors). Link: https://github.com/rust-lang/rust-bindgen/issues/2674 Signed-off-by: Chunfeng Song Reviewed-by: FUJITA Tomonori Link: https://patch.msgid.link/20260910055110.167110-1-springbreeze@stu.pku.edu.cn Signed-off-by: Jakub Kicinski commit f97d8c7bab7843631206a114986c9059da03efeb Author: Aohan Mei Date: Fri Sep 11 15:34:32 2026 +0800 rds: ib: use rds_conn_drop() on protocol version mismatch rds_ib_cm_connect_complete() runs from the RDMA-CM event handler with conn->c_cm_lock held. When the peer negotiates a protocol version older than RDS_PROTOCOL_COMPAT_VERSION, the handler calls rds_conn_destroy(), which is only safe in the rmmod path: it synchronously tears the connection down and flush_work()es the shutdown work cp_down_w. That shutdown work (rds_conn_shutdown()) needs cp_cm_lock, which is the very lock the event handler still holds, so the flush never completes: the two workers wait on each other and the RDS connection workqueues stall for good. All other RDMA-CM failure paths (REJECTED, CONNECT_ERROR, DISCONNECTED) use rds_conn_drop(), which marks the connection RDS_CONN_ERROR and schedules the shutdown work asynchronously. Use it here as well. Fixes: f147dd9ecabf ("RDS/IB: Disallow connections less than RDS 3.1") Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Reviewed-by: Allison Henderson Signed-off-by: Aohan Mei Link: https://patch.msgid.link/20260911073436.3542080-1-ljp1205831794@gmail.com Signed-off-by: Jakub Kicinski commit e1253a82bb4c0fed6706a5839fc8b6e01be1abe2 Author: Paulo Alcantara Date: Sun Sep 13 21:15:41 2026 -0300 smb: client: fix fattr leaking on wsl_to_fattr() failure wsl_to_fattr() mutates fattr fields as it parses each WSL EA. If validation later fails, the function returns false with partially mutated fattr fields that callers do not reset. Fix this by parsing into local variables and only committing them to fattr on success. Closes: https://sashiko.dev/#/patchset/20260906200517.725015-1-pc%40manguebit.org Fixes: 78e26bec4d6d ("smb: client: parse uid, gid, mode and dev from WSL reparse points") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: David Howells Cc: Tom Talpey Cc: Shyam Prasad N Cc: Ronnie Sahlberg Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org commit e1aeaf79dea51e6065da56924bc07e22d59012ac Author: Paulo Alcantara Date: Sun Sep 13 21:09:15 2026 -0300 smb: client: fix unaligned access in WSL reparse point parser When wsl_to_fattr() parses WSL extended attributes, it computes a payload pointer from ea->ea_data + ea_name_length + 1. Since the smb2_file_full_ea_info struct is __packed and all WSL xattr names are 6 bytes long, the value pointer always lands at an odd byte offset, never satisfying __le32 or __le64 alignment requirements. The code then casts this pointer to __le32 * or __le64 * and dereferences it directly, which may cause alignment faults on some architectures. Replace all such casts with get_unaligned_le32() and get_unaligned_le64() in reparse_mkdev(), wsl_make_kuid(), wsl_make_kgid() and wsl_to_fattr(). Closes: https://sashiko.dev/#/patchset/20260906200517.725015-1-pc%40manguebit.org Fixes: 78e26bec4d6d ("smb: client: parse uid, gid, mode and dev from WSL reparse points") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: David Howells Cc: Tom Talpey Cc: Shyam Prasad N Cc: Ronnie Sahlberg Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org commit d558af8ee0bb1b2e88e696be84adb93cf2b7be6f Author: Troy Mitchell Date: Mon Sep 7 09:54:36 2026 +0800 clk: spacemit: k3: add CPU PLL rate tables The K3 CPU PLL rate tables currently describe only one rate per PLL, although the hardware supports a wider range. PLL3 and PLL4 support rates from 1.05 to 2.4 GHz, while PLL5 and PLL8 support rates from 1.05 to 2 GHz. Populate the tables with every supported rate in 50 MHz steps. Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree") Cc: stable@vger.kernel.org # 7.0+ Reviewed-by: Aurelien Jarno Tested-by: Aurelien Jarno Tested-by: Anirudh Srinivasan Signed-off-by: Troy Mitchell Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260907-k3-pll5-pll8-1800mhz-v5-1-5cc96d716b0a@linux.spacemit.com Signed-off-by: Yixun Lan commit 6c21ebc81338dd8abe021dec3d01acebd789ea2c Merge: e6b6078ea1731b e75a9fa1d44bcb Author: Jakub Kicinski Date: Mon Sep 14 17:06:52 2026 -0700 Merge tag 'nf-26-09-11' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Pablo Neira Ayuso says: ==================== Netfilter fixes for net 1) Fix KMSAN reports an uninit-value in nf_nat_setup_info() for netmap, from Theodor Arsenij Larionov Trichkine. 2) Restrict deletion of netdevice in basechain and flowtable to exact matching only, from Fernando F. Mancera. 3) Fix nf_nat_register_fn() error path allowing for a memleak. 4) Hold reference on ct until flow is released to address, otherwise access to release ct->ext or different ct due to typesafe RCU semantics. * tag 'nf-26-09-11' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: flowtable: hold reference on ct until flow is released netfilter: nf_nat: unregister and release hooks on error netfilter: nf_tables: fix device name and prefix match in hook lookup netfilter: nft_nat: fully initialise new_addr in netmap setup ==================== Link: https://patch.msgid.link/20260913205447.1889203-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski commit a15fac810c76397ec9f62a6fc26c4d7ab6e238a7 Author: Krzysztof Kozlowski Date: Sun Sep 13 14:33:33 2026 +0200 dt-bindings: display/msm: Use consistent indentation in the example Correct indentation in the examples to consistent 2- or 4-spaces indentation to fix dt-check-style warnings ("example 0 [indent-consistent] indent mismatch ..."). Preferred is 4-spaces, but re-indenting entire example just for that is too much churn. Signed-off-by: Krzysztof Kozlowski Patchwork: https://patchwork.freedesktop.org/patch/753054/ Link: https://lore.kernel.org/r/20260913123331.100293-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov commit f4fae975db08a9aeec0b15e145c7d4d0fe02a0ec Author: Guangshuo Li Date: Sun Sep 13 16:58:14 2026 +0800 drm/msm/hdmi_phy: fix runtime PM cleanup on probe failure msm_hdmi_phy_probe() enables runtime PM before enabling the PHY resources and initializing the PLL, but failures from either operation return without calling the matching pm_runtime_disable(). The remove path disables runtime PM, but it is not called when probe fails. As a result, runtime PM remains enabled after an unsuccessful probe. Route failures after pm_runtime_enable() through a common error path and disable runtime PM before returning. This issue was found by manual code inspection. Fixes: 15b4a4523859 ("drm/msm/hdmi: Create a separate HDMI PHY driver") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Krzysztof Kozlowski Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/753043/ Link: https://lore.kernel.org/r/20260913085814.1509352-1-lgs201920130244@gmail.com Signed-off-by: Dmitry Baryshkov commit 2028280686f4fa78e2f1f6dede4b6c1fd782b9e3 Author: Dmitry Baryshkov Date: Thu Sep 3 15:19:10 2026 +0300 drm/msm/dsi: round the byte clock rate after reparenting to the PHY PLL DSI 6G v2.9 hosts (SM8650, SM8750, Kaanapali, etc.) reparent the byte and pixel RCGs to the DSI PHY PLL at runtime from dsi_link_clk_set_rate_6g_v2_9(), after the PHY has been enabled. However dsi_calc_clk_rate_6g() runs earlier, in order to compute the bit clock request for the PHY. At that point the byte RCG still has its reset parent (XO), so clk_round_rate() returns a bogus rate, which then ends up in the PHY bit clock request and the PLL gets programmed to a wrong frequency, breaking the panel. Move the rounding to dsi_link_clk_set_rate_6g(), which is called after the RCGs have been reparented to the PLL. Storing the rounded rate at this point still makes later link_clk_set_rate() calls no-ops in the CCF. Derive the byte interface clock rate from the rounded byte clock rate, otherwise it would keep requesting the idealized rate and retrigger the PLL on every transfer. Reported-by: Abel Vesa Reported-by: Krzysztof Kozlowski Fixes: 6cd33b6f4155 ("drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value") Assisted-by: LLM Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Tested-by: Konrad Dybcio # SM6115P J606F Tested-by: Abel Vesa Reviewed-by: Abel Vesa Patchwork: https://patchwork.freedesktop.org/patch/750496/ Link: https://lore.kernel.org/r/20260903-fix-eliza-dsi-v1-1-3474a6c9f2e0@oss.qualcomm.com commit 057dac23d329d5c5ed62352f2659a39fd46c6d4a Author: Michal Koutný Date: Mon Sep 14 14:19:10 2026 +0200 cgroup: Avoid iteration of dying tasks with zero refcount The commit 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()") extended the lifetime of tasks on the dying_tasks list. The iterators have provision to go through dying_tasks because of dying threadgroup leaders or explicit CSS_TASK_ITER_WITH_DEAD, however, it was expected that such tasks can obtain a new reference (that is possible before cgroup_task_release()/put_task_struct_rcu_user()). The tasks after cgroup_task_release() and before cgroup_task_free() are subject to race when they may or may not have ->usage count > 0. The race window is between css_task_iter_next() invocations when css_set_lock is released and we may arrive at a new ->task_pos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero. (When that happens, __put_task_struct_rcu_cb() is already imminent and the returned task_struct would could be used after free.) As for the fix, we cannot simply check the signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that are going to be free'd. Therefore add an extra check to rule out ->usage==0 tasks from any iteration. The repeat: loop in css_task_iter_advance() doesn't consider ->usage count, so add a new loop to css_task_iter_next() to skip de-used tasks on the dying_list. Rough illustration of the possible race R (reader of cgroup.procs) T (thread) L (group leader) --------------------------------- -------------------------------- -------------------------------- L exits, signal->live > 0 cgroup_task_dead(L) css_set_skip_task_iters() // skips only cset->tasks list_add_tail(&L->cg_list, &cset->dying_tasks) css_task_iter_next() take css_set_lock css_task_iter_advance() leader && signal->live != 0 => it->task_pos = &L->cg_list release css_set_lock T exits --signal->live == 0 cgroup_task_dead(T) // css_set_lock release_task(T) cgroup_task_release(T) release_task(L) // zap_leader cgroup_task_release(L) put_task_struct_rcu_user(L) ...RCU... put_task_struct(L) L->usage = 0 /* L still on dying_tasks */ ...RCU... __put_task_struct(L) css_task_iter_next() // another iteration take css_set_lock it->task_pos = &L->cg_list get_task_struct(L) => addition on 0 drop css_set_lock cgroup_task_free(L) css_set_skip_task_iters() // dying skip comes too late free_task(L) cgroup_procs_show() task_pid_vnr(L) Fixes: 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()") Cc: stable@vger.kernel.org # v6.19+ Link: https://lists.debian.org/debian-kernel/2026/08/msg00220.html Reported-by: Noah Elias Feldt Reported-by: Salvatore Bonaccorso Tested-by: Salvatore Bonaccorso Signed-off-by: Michal Koutný Signed-off-by: Tejun Heo commit f59d86d25e41c5ac511584d9d6808ee448fd42b0 Author: Filipe Manana Date: Thu Sep 10 17:48:06 2026 +0100 btrfs: tree-checker: fix error message regarding free space extent items The error message mentions a free space info item, but we are processing a free space extent item, so fix the message. Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba commit a1167d9420474ab9ed9efca99d86aeb6217c0265 Author: Filipe Manana Date: Thu Sep 10 17:37:48 2026 +0100 btrfs: tree-checker: print dev extent offset in error message If a dev extent's offset is not sector size aligned, the error message is printing the dev extent's objectid instead of the offset. This is a copy paste error, as before this check we check the objectid field. Fixes: 008e2512dc56 ("btrfs: tree-checker: add dev extent item checks") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba commit 0594e3423f4ba3137c734371169491f9a98e9af4 Author: Hongling Zeng Date: Mon Aug 31 13:38:01 2026 +0800 btrfs: take commit root semaphore when iterating in mark_block_group_to_copy() mark_block_group_to_copy() iterates over the commit root with skip_locking=true. A concurrent transaction commit can swap and free the commit root during iteration, causing use-after-free when accessing extent buffers. Fix it by using path->need_commit_sem to protect the commit root search. Fixes: 78ce9fc269af ("btrfs: zoned: mark block groups to copy for device-replace") CC: stable@vger.kernel.org Assisted-by: Codex:gpt-5.5 Reviewed-by: Johannes Thumshirn Signed-off-by: Hongling Zeng Reviewed-by: David Sterba Signed-off-by: David Sterba commit 3a35e787ac1acf94d33eebb26fd7248811cc66c9 Author: Johannes Thumshirn Date: Mon Aug 24 18:19:10 2026 +0200 btrfs: zoned: handle RAID profiles in btrfs_can_activate_zone() btrfs_can_activate_zone() only accounts for the single and DUP profiles. For a RAID0, RAID1, RAID1C3, RAID1C4 or RAID10 block group the profile switch matches no case, so 'ret' stays false and the function reports that no zone can be activated, even when the devices have plenty of active zones left. As a side effect BTRFS_FS_NEED_ZONE_FINISH gets set and, since btrfs_can_activate_zone() bails out early once that bit is set, data allocations will fail permanently: writers loop on -EAGAIN and hang in btrfs_new_extent_direct() waiting for the bit to clear. Each of these profiles needs one active zone per device, just like single, so handle them the same way. Reviewed-by: Boris Burkov Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba commit 820b8cff81c796ba20573e04722ab62500713f97 Author: Nicolas Escande Date: Fri Jul 31 16:58:30 2026 +0200 wifi: ath11k: cleanup arsta in ath11k_mac_peer_cleanup_all() When mac80211 removes a sta, it calls .sta_state() which in turn calls ath11k_mac_station_remove(). In that function we clean up both peers & arsta related resources. But when the firmware crashes, ath11k calls ieee80211_restart_hw(), which assumes that all driver related resources are cleaned up beforehand. This cleanup is supposedly done by ath11k_mac_peer_cleanup_all() but does not in fact free arsta->rx_stats / tx_stats. Extract the arsta cleanup from ath11k_mac_station_remove() into a new ath11k_mac_station_cleanup() and call it from both there and ath11k_mac_peer_cleanup_all(). This should handle kmemleaks reports like: unreferenced object 0xffffff801ae66400 (size 1024): comm "hostapd", pid 1306, jiffies 4295011565 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc d61c08ec): kmemleak_alloc+0x3c/0x50 __kmalloc_cache_noprof+0x2b0/0x3e0 ath11k_mac_op_sta_state+0x1dc/0xb10 drv_sta_state+0xac/0x6f8 sta_info_insert_rcu+0x314/0x5e0 sta_info_insert+0x14/0x38 ieee80211_add_station+0x10c/0x1a0 nl80211_new_station+0x3e8/0x680 genl_family_rcv_msg_doit+0xc0/0x120 genl_rcv_msg+0x1b4/0x258 netlink_rcv_skb+0x4c/0x108 genl_rcv+0x38/0x60 netlink_unicast+0x190/0x278 netlink_sendmsg+0x15c/0x370 ____sys_sendmsg+0x120/0x290 ___sys_sendmsg+0x70/0xa0 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Nicolas Escande Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260731145830.769811-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson commit d9be5e75530772fc31637070d51e5717d6aeaa2a Author: Fan Wu Date: Thu Sep 10 02:09:07 2026 +0000 wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardown wcn36xx_dxe_deinit() tears down the TX ack timer with timer_delete(), which only dequeues the timer and does not wait for a callback that is already executing; the preceding free_irq() calls synchronize the interrupt handlers only. The callback, wcn36xx_dxe_tx_timer(), can therefore be running past the teardown and use the wcn freed along with the ieee80211_hw in wcn36xx_remove(): it takes wcn->dxe_lock, reads wcn->tx_ack_skb and passes wcn->hw to ieee80211_tx_status_irqsafe(). Fix this by using timer_shutdown_sync(), which waits for a running callback and also prevents the timer from being rearmed again. The timer is set up again by wcn36xx_dxe_init() on the next start, so the start/stop cycle is unaffected. This issue was found by an in-house static analysis tool. Fixes: fdf21cc37149 ("wcn36xx: Add TX ack support") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20260910020907.3353-1-fanwu01@zju.edu.cn Signed-off-by: Jeff Johnson commit ce9d5197d651cdd0fbb586c3d77c28438abe1b10 Author: Krzysztof Kozlowski Date: Tue Aug 25 10:13:14 2026 +0200 wifi: ath12k: ahb: Revert undocumented ABI and dead code Commit 96f46607bbce ("wifi: ath12k: add AHB platform descriptor support") added undocumented OF ABI, by relying on a very specific node name. This is not allowed and was never acked by Devicetree maintainers. Additionally that part of code is not even used, because all devices have exactly the same user pd, so this was added "for future". Adding dead code just "for future" is heavily discouraged in kernel coding. Signed-off-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260825081313.71351-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Jeff Johnson commit 587858367581b9c55c3690f4e63382ad622719d4 Merge: 59826bc5a42a5e f76017a7663c4c Author: Linus Torvalds Date: Mon Sep 14 10:41:30 2026 -0700 Merge tag 'nfsd-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux Pull nfsd fix from Chuck Lever: - Fix handling of NFSEXP_PNFS in the netlink codepath * tag 'nfsd-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux: nfsd: fix handling of NFSEXP_PNFS in the netlink codepath commit 59826bc5a42a5e85dc21d4cdf3892f22dcda65f8 Merge: 01414b70cb6f7a c60ae98c5aa640 Author: Linus Torvalds Date: Mon Sep 14 10:20:28 2026 -0700 Merge tag '9p-for-7.3-rc4' of https://github.com/martinetd/linux Pull 9pfs fix from Dominique Martinet: "This is a single fix for a 9p/netfs regression that got in 7.1 (and was backported to 7.0) We need to rework how cached attributes, and in particular i_size, are handled in 9p more thoroughly but that will take more time and this appears to be enough for the most obvious problems" * tag '9p-for-7.3-rc4' of https://github.com/martinetd/linux: 9p: Fix v9fs_issue_write() to update i_size and remote_i_size commit 01414b70cb6f7a5911b65de0cc97225061f60a59 Merge: ebb58ec7f85394 9ff797e516dbc1 Author: Linus Torvalds Date: Mon Sep 14 09:58:12 2026 -0700 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma Pull rdma fixes from Jason Gunthorpe: "Lots of bug fixes from the last weeks: - Various error unwind bugs - Several more races and bugs in siw and rxe, including remote triggerable - HFI1 corruption with its credit scheme - Remove a bogus user triggerable dev_warn - Lock __ethtool_get_link_ksettings() properly - Fix a lockdep loop with diassociation - Several storage related bugs, some triggerable remotely - Do no leak physical addresses to userspace in bnxt_re - Fix wrong irq context for the xarrays in erdma - User triggerable race in ucma with multicast - Race in ipoib with multicast flushing and destruction" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: (28 commits) RDMA/siw: Bound fragmented header copies by the remaining length RDMA/efa: Keep EQ resources alive while IRQ is registered RDMA/efa: Keep admin queues alive while IRQ is registered RDMA/core: fix refcount bug in iwpm_get_nlmsg_request() IB/IPoIB: Avoid restoring OPER_UP after multicast flush RDMA/ucma: Serialize join and leave on copy_to_user failure RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted RDMA/irdma: Enforce local fence for IB_WR_REG_MR RDMA/erdma: Use IRQ-safe XArray helpers for QP and CQ tables RDMA/mad: Fix receive buffer leak when PKey enforcement fails RDMA/uverbs: Fix potential leak of resources->collection in flow_resources_alloc() RDMA/bnxt_re: Avoid exposing umdbr to userspace RDMA/rtrs: guard against null kobj name RDMA/bnxt_re: check create_singlethread_workqueue() in DCB setup IB/isert: wait for deferred control PDU completions before releasing the connection IB/iser: reject a remote invalidation of an unregistered direction RDMA/srp: Fix srp_remove_target() IB/mlx4: Fix use-after-free on pkey sysfs registration failure RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency RDMA/core: Reject unregistering netdevs in ib_get_eth_speed ... commit ebb58ec7f8539450804741d974acbb985da0f071 Merge: 164f652b6ef920 6e33dc90df108c Author: Linus Torvalds Date: Mon Sep 14 09:36:43 2026 -0700 Merge tag 'fixes-2026-09-14' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/memblock Pull memblock fixes from Mike Rapoport: "Fix for regions display in debugfs and MAINTAINERS update: - Make sure that multiple flags on a memblock region are all displayed in debugfs - Update memblock tree tags in MAINTAINERS" * tag 'fixes-2026-09-14' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/memblock: MAINTAINERS: update memblock tree URLs mm: memblock: show all region flags in debugfs commit c9e6e5f38bf75276605f1952b22285f5f3abcaff Author: Slavin Liu Date: Sun Sep 13 20:51:54 2026 +0800 ALSA: hda: trace PCM open only after assigning a stream Stream assignment can fail when hardware streams are exhausted. Move the tracepoint after the NULL check because its payload accesses the assigned stream tag. Detected by static analysis and reviewed with AI-assisted source auditing. Fixes: 184865085b88 ("ALSA: hda - rename hda_intel_trace.h to hda_controller_trace.h") Assisted-by: LLM Signed-off-by: Slavin Liu Link: https://patch.msgid.link/20260913125154.109944-1-bolin.liu@seu.edu.cn Signed-off-by: Takashi Iwai commit b6f69097c8271cca30314fd6e4c802f90737bfcc Author: Benjamin Tissoires Date: Fri Sep 4 14:53:01 2026 +0200 selftests/hid: add unnumbered variant to the hid_bpf tests A bug appeared in hid_bpf_dispatch.c where it wasn't properly handling unnumbered reports. Add a device variant without report IDs so we can also test them. Signed-off-by: Benjamin Tissoires commit c4afa4862b878d56e0cc1021298794ac1b45bc49 Author: Benjamin Tissoires Date: Fri Sep 4 14:53:00 2026 +0200 HID: bpf: fix __hid_bpf_hw_check_params report length Turns out that USB, I2C and other transport drivers (except uhid which just passes the data) still need to have the report ID in the first byte. Because they expect the first byte to be the report ID or 0, when the report ID is 0, they strip that first byte before forwarding to the device. This means that the transport layer forwards a buffer of size N-1 to the device, which gets rejected. Fixes: 5599f8019661 ("HID: bpf: export hid_hw_output_report as a BPF kfunc") Signed-off-by: Benjamin Tissoires commit 9d1e523b92d8cb11a4a7e5a2655d6824c2d0f6e3 Author: Benjamin Tissoires Date: Fri Sep 4 14:52:59 2026 +0200 selftests/hid: add define for commonly used buf size If we want to add another report descriptor without report IDs with a report size bigger than 10, we have multiple magic values to replace. Put a #define once and for all, so we don't have dangling ones. Signed-off-by: Benjamin Tissoires commit 164f652b6ef9209437ca016beedfcab626ff4f02 Merge: 704340f1cd0dce 7891fbb9512f12 Author: Linus Torvalds Date: Mon Sep 14 08:59:09 2026 -0700 Merge tag 'mm-hotfixes-stable-2026-09-13-21-50' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "14 hotfixes. 10 are cc:stable. 11 are for MM. All are singletons - please see the changelogs for details" * tag 'mm-hotfixes-stable-2026-09-13-21-50' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/folio: EXPORT_SYMBOL_FOR_KVM(lru_cache_drain_for_folio) mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem mm/vma: correctly unaccount on mmap_prepare() failure mm/mlock: use the IRQ-safe accessor for NR_MLOCK in __munlock_folio() remove old lib/alloc_tag.c fs/dax: check zero or empty entry before converting xarray entry fs: fix missed removal of super_fs_objects_eligible() mm: filemap: retain mapped dropbehind folios mailmap: update entry for Christopher Obbard memcg: avoid charging the root memcg from obj_cgroup_charge_pages() mm, swap: fix SWAP_USAGE_OFFLIST_BIT collision with real usage count mailmap: map Coiby Xu's address mm/mremap: account mm->locked_vm correctly for MREMAP_DONTUNMAP mm/huge_memory: bypass THP tuneables for huge pfnmap mappings commit 5ab3dc647751996784cff20a51f3730f4e88afe4 Author: Asai Neko Date: Mon Sep 14 18:58:29 2026 +0800 ALSA: usb-audio: skip the broken mute control on AVerMedia GC553Pro Skip the nonfunctional master mute control on the AVerMedia Live Gamer ULTRA S GC553Pro (07ca:1553). USB tracing shows that GET_CUR returns zero bytes instead of the required one-byte value, both through usbfs and during ALSA initialization. SET_CUR succeeds, but switching capture off does not mute HDMI audio. Before the change, the driver exposed a misleading PCM Capture Switch and logged: 3:2: failed to get current value for ch 0 (-22) With the patch applied, the switch and warning are absent. A ten-second sound recording through PipeWire confirmed that stereo 48 kHz, 16-bit capture still works. Tested on NixOS with the patched 7.3.0-rc3 kernel. The USB audio driver object builds with Clang and W=1; sparse and strict checkpatch pass. Signed-off-by: Asai Neko Link: https://patch.msgid.link/20260914-avermedia-gc553pro-alsa-v1-1-4c694e8b0cd5@sne.moe Signed-off-by: Takashi Iwai commit 1c4f6202876a74e752a8cfd3696955f761671c7a Author: Jaeho Cho Date: Mon Sep 14 10:24:42 2026 -0400 ALSA: hda/realtek: Enable mute LEDs on HP OmniBook 7 17-dc0xxx The HP OmniBook 7 Laptop 17-dc0xxx (SSID 103c:8d9c) has mute and mic-mute LEDs on its F6 and F9 keys, but neither lights up. Its quirk entry only sets up the two CS35L41 amplifiers, so no LED control is registered for either key. Writing to the ALC245 by hand with hda-verb, the mute LED responds to COEF 0x0b bits 2-3 and the mic-mute LED to GPIO 0x04, lit when the pin is low. That appears to match what ALC245_FIXUP_HP_X360_MUTE_LEDS already does, so add a fixup that chains the two-amp I2C setup to it and use it for this model. Tested on 7.2.4 with the patched module: hda::mute and hda::micmute are registered, and both LEDs follow the speaker and microphone mute state, including from the F6 and F9 keys. Signed-off-by: Jaeho Cho Link: https://patch.msgid.link/20260914142445.3476212-1-jaeho2025@gmail.com Signed-off-by: Takashi Iwai commit c702a5f18b780e477eccbbab558e590e9673e4cb Author: Guangshuo Li Date: Mon Sep 14 15:36:38 2026 +0800 hwmon: (w83793) release probe data through kref w83793_probe() initializes data->kref to manage the lifetime of the driver data. The normal remove path drops the driver-owned reference with kref_put(), while watchdog users take and release additional references through the same kref. However, the probe error path still frees data directly with kfree(). This bypasses the kref-managed lifetime and discards the initial reference without a matching kref_put(), leaving the reference accounting unbalanced. Drop the probe-owned reference with kref_put() instead and let w83793_release_resources() perform the final free, matching the normal remove path. This issue was found by manual code inspection. Fixes: 5852f9609d21 ("hwmon: (w83793) Add watchdog functionality") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260914073638.1662500-1-lgs201920130244@gmail.com Signed-off-by: Guenter Roeck commit 0ff9c7775e51ac6d47b1bb5c46f06b1434fe58a8 Author: Guangshuo Li Date: Mon Sep 14 14:28:09 2026 +0800 hwmon: (w83791d) remove fan/pwm 4-5 sysfs group on remove When the fan/pwm 4-5 pins are not used as GPIO, w83791d_probe() creates the w83791d_group_fanpwm45 sysfs group on the I2C client device. The probe error path removes this group when a later initialization step fails, but the normal remove path only removes w83791d_group. As a result, the optional fan/pwm 4-5 sysfs files can remain after the driver is unbound. The callbacks associated with these files access the driver data, which is devm allocated and released after driver unbind. Leaving the sysfs files behind can therefore result in accesses to stale driver data. Remove w83791d_group_fanpwm45 during normal teardown as well. This issue was found by manual code inspection. Fixes: 6e1ecd9b8f13 ("hwmon: (w83791d) fan 4/5 pins can also be used for gpio") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260914062809.1650538-1-lgs201920130244@gmail.com Signed-off-by: Guenter Roeck commit bdf5f731957de48acada392f28e82bc019713adb Author: Cong Nguyen Date: Mon Sep 14 17:41:36 2026 +0700 hwmon: (gpio-fan) return IRQ_HANDLED from the shared alarm IRQ handler fan_alarm_irq_handler() always schedules alarm_work but returns IRQ_NONE, so the kernel treats every alarm interrupt as unhandled. On a shared line that risks the whole line being disabled as spurious. v1 just fixed that, but it was still IRQF_SHARED, and always returning IRQ_HANDLED there defeats spurious-interrupt detection for the line -- if the interrupt ever fires without a real event, nothing catches it, and a fault could spin the CPU in the handler. Sashiko flagged this in v1, and Guenter confirmed: this interrupt must not be shared. So v2 drops IRQF_SHARED too. Fixes: d6fe1360f42e ("hwmon: add generic GPIO fan driver") Reported-by: Sashiko AI review Link: https://lore.kernel.org/r/20260901160931.DD3811F00A3D@smtp.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Link: https://patch.msgid.link/20260914104136.1797979-1-congnt264@gmail.com Signed-off-by: Guenter Roeck commit 073a30d75f309812ed61af134f24ffef4107b13a Author: Karl Mehltretter Date: Sat Aug 22 16:31:10 2026 +0200 drm/vc4: Use managed KMS polling to fix UAF on unbind vc4_kms_load() calls drm_kms_helper_poll_init() but the driver provides no matching drm_kms_helper_poll_fini(). The output poll work stays scheduled after unbind and runs on the freed drm_device: # modprobe vc4; rmmod vc4; sleep 10 BUG: KASAN: slab-use-after-free in delayed_work_timer_fn BUG: KASAN: slab-use-after-free in drm_client_dev_hotplug [drm] Workqueue: events output_poll_execute [drm_kms_helper] Allocated by task 171: __devm_drm_dev_alloc Freed by task 262 (rmmod): drm_dev_put / component_del Use drmm_kms_helper_poll_init() so polling is finalized with the device, as other drivers do. Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260822143110.68594-1-kmehltretter@gmail.com Reviewed-by: Maíra Canal Signed-off-by: Maíra Canal commit 869e97e66d3f5c37a42571154b103c09778e41cb Merge: 2d5adffc11cc8d 8544e0da1a04c7 Author: Arnd Bergmann Date: Mon Sep 14 17:02:16 2026 +0200 Merge tag 'scmi-ffa-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm firmware fixes for v7.3 SCPI fixes address resource leaks and invalid firmware responses, while FF-A gains shutdown cleanup needed for normal kexec. - Release the device node reference acquired during SCPI domain lookup. - Validate SCPI DVFS OPP counts and indices returned by firmware to prevent out-of-bounds accesses and invalid clock rates. - Register the SCPI cpufreq device only once across DVFS providers, preserving the registered device pointer for cleanup and allowing retries after registration failure. - Run FF-A teardown during orderly shutdown so notifications, partition devices and RX/TX mappings are released before a replacement kernel boots through normal kexec. Also includes replacing a literal platform device ID with PLATFORM_DEVID_NONE and correcting an SCMI comment typo. * tag 'scmi-ffa-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Fix typo "upto" in comment firmware: arm_ffa: Tear down driver during shutdown clk: scpi: use PLATFORM_DEVID_NONE for scpi-cpufreq clk: scpi: register scpi-cpufreq once and clear on failure clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS firmware: arm_scpi: fix device_node leak in scpi_dev_domain_id Signed-off-by: Arnd Bergmann commit 2d5adffc11cc8d694e309dc38f9a8ae7fa14a65a Merge: ebdad7d867a59a 2ac7bad110be6e Author: Arnd Bergmann Date: Mon Sep 14 17:01:55 2026 +0200 Merge tag 'renesas-fixes-for-v7.3-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/fixes Renesas fixes for v7.3 - Fix Ethernet stalls on RZ/V2H, RZ/V2N, RZ/G3E, RZ/T2H, and RZ/N2H. * tag 'renesas-fixes-for-v7.3-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: arm64: dts: renesas: r9a09g087: Switch GBETH TX queue scheduling to WRR arm64: dts: renesas: r9a09g077: Switch GBETH TX queue scheduling to WRR arm64: dts: renesas: r9a09g047: Switch GBETH TX queue scheduling to WRR arm64: dts: renesas: r9a09g056: Switch GBETH TX queue scheduling to WRR arm64: dts: renesas: r9a09g057: Switch GBETH TX queue scheduling to WRR Signed-off-by: Arnd Bergmann commit ebdad7d867a59a6fbf01652bbe183cbfc69b0a8f Merge: 8c8a0cac6ff087 5f8cb07d7a8573 Author: Arnd Bergmann Date: Mon Sep 14 17:01:17 2026 +0200 Merge tag 'socfpga_dts_fix_for_v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into arm/fixes SoCFPGA DTS fix for v7.3 - Fix DTS file access permissions * tag 'socfpga_dts_fix_for_v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: arm64: dts: socfpga: change access permission from 755 to 644 Signed-off-by: Arnd Bergmann commit 8c8a0cac6ff08791c39dc095d5cde95f6feec4a6 Merge: df2908090cda36 cfc1e9a543e358 Author: Arnd Bergmann Date: Mon Sep 14 17:00:55 2026 +0200 Merge tag 'socfpga_fix_for_v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into arm/fixes SoCFPGA fix for v7.3 - Fix PL310_ERRATA_753970 Kconfig option * tag 'socfpga_fix_for_v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: ARM: socfpga: select the PL310 erratum 753970 workaround Signed-off-by: Arnd Bergmann commit 44b8a0bf5f96e8393312fc34b956766882341f16 Author: Runyu Xiao Date: Thu Aug 27 16:26:56 2026 +0800 mtd: spi-nor: core: Fix mutex leak in spi_nor_rww_start_exclusive() Use the same guard(mutex) pattern as the other RWW helpers so nor->lock is released on both the busy and successful return paths. Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Reviewed-by: Miquel Raynal Reviewed-by: Tudor Ambarus [mw: rephrased commit message] Signed-off-by: Michael Walle commit 985862be16c7e4da808c51f393d631fb60c0be5c Author: Shuicheng Lin Date: Wed Sep 9 16:21:02 2026 +0000 drm/xe/shrinker: Take a runtime PM ref before shrinking non-system memory __xe_shrinker_walk() walks the SYSTEM and TT LRUs without a runtime PM reference. Shrinking a bo outside system memory invalidates its GPU mappings, which needs the device resumed, so while it is runtime suspended the page table zap trips an assert and the TLB invalidation returns -ENODEV: WARNING: drivers/gpu/drm/xe/xe_bo.c:770 at xe_bo_move_notify+0x1fc/0x450 [xe] xe_bo_shrink+0x20f/0x2b0 [xe] __xe_shrinker_walk+0x174/0x410 [xe] xe_shrinker_scan+0x10c/0x1e0 [xe] do_shrink_slab+0x176/0x7e0 drop_caches_sysctl_handler+0x9c/0xf0 Take a reference before walking a memory type other than XE_PL_SYSTEM and stop there if it cannot be acquired. Reuse the shrinker's existing acquire path, which resumes the device directly where reclaim allows that and otherwise queues the PM worker for a later scan. Stop the walk once the scan target is met, so a satisfied scan does not wake the device. System memory is still reclaimed while the device is suspended. Gate this on xe_device_is_l2_flush_optimized(), the same condition under which xe_bo_trigger_rebind() issues the invalidation for a non-fault-mode vm, so reclaim is unaffected elsewhere. The System CCS copy already has its own reference in xe_bo_shrink(). Only a non-fault-mode vm can reach this, since a fault-mode vm requires LR mode and that holds a runtime PM reference for the vm's lifetime. Reproduced with igt@xe_madvise@dontneed-before-exec while the GPU is runtime suspended. v2: simplify needs_rpm check. (Matt) retarget Fixes tag since the issue occurs with the non-fault-mode path added by 4e7ebff69aed. v3: handle this in xe_shrinker.c instead of xe_bo.c (Thomas) v4: stop the walk once the scan target is met. (Sashiko) v5: rebase on the freed page accounting fix. (Sashiko) v6: reuse the shrinker acquire path so runtime pm can be resumed directly instead of always queueing a worker. (Thomas) v7: replace xe_pm_runtime_put() with xe_shrinker_runtime_pm_put(). (Thomas) Fixes: 4e7ebff69aed ("drm/xe/xe3p_lpg: flush shrinker bo cachelines manually") Assisted-by: Claude:claude-opus-5 Cc: Tejas Upadhyay Cc: Matthew Brost Reviewed-by: Thomas Hellström Link: https://patch.msgid.link/20260909162102.1097006-3-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 628f92b28bf4c371c10207daf6fc4caee0c0db2e) Signed-off-by: Rodrigo Vivi commit 3c90e42a01426262f0cd166bc01b45c05562640d Author: Shuicheng Lin Date: Wed Sep 9 16:21:01 2026 +0000 drm/xe/shrinker: Return the freed page count through a parameter __xe_shrinker_walk() and xe_shrinker_walk() return either the number of pages freed or a negative error, so the two cannot be reported at once. On error the pages already freed are dropped, and since xe_shrinker_scan() only accumulates non-negative returns while *scanned is updated by pointer, the shrinker tells mm that it scanned without freeing. Accumulate the count into a caller-provided counter and return only the status, so an error no longer discards what the walk had freed. Fixes: 00c8efc3180f ("drm/xe: Add a shrinker for xe bos") Assisted-by: Claude:claude-opus-5 Reviewed-by: Thomas Hellström Cc: Matthew Brost Link: https://patch.msgid.link/20260909162102.1097006-2-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit d7aac1a0235a6ce41e30cec385e2db8c33dad12d) Signed-off-by: Rodrigo Vivi commit d0c09528781938362655d9c336364e777119bd6b Author: Ilia Levi Date: Tue Sep 8 17:50:53 2026 +0100 drm/xe/mmio_gem: fix destroy flow xe_mmio_gem_destroy() currently frees the GEM object directly, bypassing reference counting. Since existing VMAs hold a reference and the fault handler accesses the object through vma->vm_private_data, this is use-after-free. Additionally, nothing prevents the fault handler from installing PTEs to the real MMIO after destroy. Fix this with proper synchronization and refcounting. Also, do not set vm_pgoff to zero. Many DRM drivers do this because helpers like dma_mmap_pages() interpret vm_pgoff as an intra-buffer page offset; leaving the DRM fake offset there would break these helpers. Those drivers can get away with zeroing it because they map eagerly - all PTEs are established before mmap returns, so vm_pgoff is never consulted again. Our driver does not use such helpers and the newly introduced call to drm_vma_node_unmap() relies on vm_pgoff being untouched. v2: (Matt Auld) - use dma_resv lock to serialize fault handler with destroy - SIGBUS on access after destroy Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-16-matthew.auld@intel.com (cherry picked from commit fb2ee38bab8025ad6a7a9cbb4635c5a178e4a7bc) Signed-off-by: Rodrigo Vivi commit de40d31275cd57408ff1fdd97ea117a3f8c50cc5 Author: Ilia Levi Date: Tue Sep 8 17:50:52 2026 +0100 drm/xe/mmio_gem: cache the dummy page per object Currently, when the fault handler provides a dummy page, it allocates a new one on every invocation and ties its lifetime to the drm_device via drmm_add_action_or_reset(). Concurrent faults after hot-unplug therefore accumulate pages that persist until device teardown. Cache a single dummy page in the xe_mmio_gem object and use dma_resv lock to protect its allocation. Free it with the object. v2: use dma_resv lock to protect the allocation (Matt Auld) Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-15-matthew.auld@intel.com (cherry picked from commit 8bf6213f9831e46313af4722a1ee6db1b7596378) Signed-off-by: Rodrigo Vivi commit 37fcbd7b2f8996d783932dab11bc668e169b0de6 Author: Shuicheng Lin Date: Tue Sep 8 17:50:51 2026 +0100 drm/xe/mmio_gem: Revoke drm_vma_node on xe_mmio_gem destroy xe_mmio_gem_create() calls drm_vma_node_allow() but nothing ever calls drm_vma_node_revoke(). The drm_vma_offset_file rb-tree entry allocated by drm_vma_node_allow() is not freed by drm_gem_object_release(), so it is leaked on every create/destroy cycle. Add a struct drm_file * parameter to xe_mmio_gem_destroy() and call drm_vma_node_revoke() from there, mirroring the drm_vma_node_allow() call in xe_mmio_gem_create(). Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Suggested-by: Ilia Levi Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Shuicheng Lin Reviewed-by: Ilia Levi Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-14-matthew.auld@intel.com (cherry picked from commit 32f0cb250598456d812fb7ca57a040282858323d) Signed-off-by: Rodrigo Vivi commit 0c50663403b7aa271b1974ba32ee6c8296711142 Author: Ilia Levi Date: Tue Sep 8 17:50:50 2026 +0100 drm/xe/mmio_gem: simplify fault handler loop Make the iteration over the addresses in the VMA more explicit. No functional change, as the VMA matches the GEM object exactly. Signed-off-by: Ilia Levi Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-13-matthew.auld@intel.com (cherry picked from commit 6666ca9192f3bdf839aad33b9e1c9ebb7a222a29) Signed-off-by: Rodrigo Vivi commit 2b04d6556964ae9f89819b86a0a7801e39c3aae5 Author: Devin Wittmayer Date: Fri Sep 4 13:03:38 2026 -0700 wifi: mac80211: refuse to make a monitor active when it has no queue A monitor interface only gets a TXQ if it's created active, and one can't be added later. Setting the flag on a down interface is still allowed, so the driver is handed a monitor with no queue. ath9k dereferences it: BUG: kernel NULL pointer dereference, address: 0000000000000066 RIP: 0010:ath_tx_node_init+0x49/0x170 [ath9k] ath9k_add_interface+0x10c/0x140 [ath9k] drv_add_interface+0x54/0x250 [mac80211] ieee80211_do_open+0x32f/0x800 [mac80211] Reached with CAP_NET_ADMIN by "iw dev X set monitor active" followed by "ip link set X up". RTNL is held, so netlink operations block behind it. Refuse the flag when there is no queue to give. Fixes: 79af1f866193 ("mac80211: avoid allocating TXQs that won't be used") Cc: stable@vger.kernel.org Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260904200338.10829-1-lucid_duck@justthetip.ca Signed-off-by: Johannes Berg commit 819f189265a5955da743e78e20a713a038982e89 Author: Ilia Levi Date: Tue Sep 8 17:50:49 2026 +0100 drm/xe/mmio_gem: use write-back mapping for dummy page Currently vmf_insert_pfn() maps the dummy page as UC, inheriting the VMA's page protection which was set for the real MMIO region. This conflicts with the direct map's WB mapping of the same page, creating a cache type alias which is architecturally undefined on some platforms. Use vmf_insert_pfn_prot() with a WB pgprot instead. Also simplify to fault in the requested page instead of the whole VMA. Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260525125801.975038-6-ilia.levi%40intel.com Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-12-matthew.auld@intel.com (cherry picked from commit 1e8e28e35df0e77ae1b22fc091c1f422f62fa5e9) Signed-off-by: Rodrigo Vivi commit 247a82da6f563dcfd9074a68f99a0c0997d0679c Author: Ilia Levi Date: Tue Sep 8 17:50:48 2026 +0100 drm/xe/mmio_gem: forbid VMA split The fault handler assumes it always operates on a VMA spanning the entire GEM object. This does not hold when the VMA has been split, e.g. by a partial munmap or mprotect. In that case the handler may map wrong physical pages or cause SIGBUS. Handle this by forbidding VMA split, as partial unmaps are not deemed useful for MMIO GEMs. Suggested-by: Matthew Auld Signed-off-by: Ilia Levi Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-11-matthew.auld@intel.com (cherry picked from commit f3391a0b12d7bf826a0b21600d2f294f3dce4c14) Signed-off-by: Rodrigo Vivi commit 06f42accaf3c6aecab1dcc57f68dde6c06c8b380 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Sep 9 15:11:24 2026 +0900 wifi: libipw: reject TKIP frames without a full MIC libipw_michael_mic_verify() assumes that an skb contains an eight-byte Michael MIC. A short TKIP frame makes the unsigned payload length wrap, causing michael_mic() to read past the skb. Check that the MIC is present before verifying it, and use the existing MICHAEL_MIC_LEN constant for all MIC lengths in the verifier. Fixes: b453872c35cf ("[NET] ieee80211 subsystem") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/20260909061124.3802517-1-4ncienth@gmail.com Signed-off-by: Johannes Berg commit e5c8d7acd31b27057ea42cd405d0b3ece097bc89 Author: Zihan Xi Date: Wed Sep 9 12:37:18 2026 +0000 wifi: virt_wifi: don't transfer operstate before register virt_wifi_newlink() calls netif_stacked_transfer_operstate() before register_netdevice(). If the lower device is dormant, that queues the new netdev on lweventlist while it is still uninitialized. If registration fails after that, for example because of an invalid name such as "bad/name", free_netdev() immediately frees the object. A later linkwatch_fire_event() then use-after-frees the list entry. Move the transfer to after netdev_upper_dev_link(), as macvlan and ipvlan already do. Fixes: c7cdba31ed8b ("mac80211-next: rtnetlink wifi simulation device") Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Link: https://patch.msgid.link/f5a832fb0ab228ce6e2b5a91fba4ca8b79198a2f.1788948455.git.zihanx@nebusec.ai Signed-off-by: Johannes Berg commit a842cfc1d6d85b34ad73959460def4d4641e82e8 Author: Slawomir Stepien Date: Thu Sep 10 10:04:18 2026 +0200 wifi: cfg80211: check if AP has been started or joined a mesh before adding new station Adding a new station to AP makes only sense when the AP has been started (nl80211_start_ap()) or joined a mesh (__cfg80211_join_mesh()). Check if AP is up and beaconing on the link or joined the mesh, when adding new station. Return error if this isn't the case. Note that libertas devices need special handling since they do not implement join_mesh() and the decision must be made on channel definition. Reported-by: syzbot+9bdc0c5998ab45b05030@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9bdc0c5998ab45b05030 Signed-off-by: Slawomir Stepien Link: https://patch.msgid.link/20260910080418.725741-3-sst@poczta.fm Signed-off-by: Johannes Berg commit e3d1acb0276742f288094cd7a497745364876bb8 Author: Slawomir Stepien Date: Thu Sep 10 10:04:17 2026 +0200 wifi: cfg80211: move link_id validation earlier in nl80211_new_station() I do not see a reason why this check is so low in the function. Move it up right next to param fetch. This new position is more beneficial for AP/Link state check that will be added in upcoming commit. Signed-off-by: Slawomir Stepien Link: https://patch.msgid.link/20260910080418.725741-2-sst@poczta.fm Signed-off-by: Johannes Berg commit 4ae3128c230372b43d0c417e0fcf816e8290e9fa Author: Slawomir Stepien Date: Thu Sep 10 10:04:16 2026 +0200 wifi: cfg80211: do not support direct add of station to AP_VLAN interfaces Prevent userspace from adding stations directly to AP_VLAN type interfaces. Userspace should first add the station to the base interface (AP type) and then can use CMD_SET_STATION to move it to AP_VLAN. The other way is by using NL80211_ATTR_STA_VLAN. Without this path, we cannot check if the AP has been started before adding the station - wdev for AP_VLAN does not store information about the base AP interface. Signed-off-by: Slawomir Stepien Link: https://patch.msgid.link/20260910080418.725741-1-sst@poczta.fm Signed-off-by: Johannes Berg commit ba7a79b9bc87776c8c1808407a7508a8be3a789e Author: Slawomir Stepien Date: Mon Sep 14 10:13:50 2026 +0200 wifi: cfg80211: verify if AP_VLAN belongs to the correct AP The get_vlan() only checks if NL80211_ATTR_STA_VLAN target is an AP/AP_VLAN/P2P_GO interface on the same wiphy. It has no notion of which specific AP a given AP_VLAN belongs to. Fix that by comparing the ethernet addresses of the two net devices. Given VLAN A' must have the same address as AP A. Otherwise, return error code. Signed-off-by: Slawomir Stepien Reported-by: Johannes Berg Link: https://lore.kernel.org/all/22e7ddfc50d7a6a16c437b876dab5fe223799610.camel@sipsolutions.net/ Link: https://patch.msgid.link/20260914081350.83484-1-sst@poczta.fm Signed-off-by: Johannes Berg commit 65bcc5f89704efe5b9d69d4ea2c1002d90c31382 Author: Slawomir Stepien Date: Mon Sep 14 11:50:07 2026 +0200 HID: amd_sfh: Validate PCI BAR size before mapping The amd_sfh driver maps PCI BAR 2 using pcim_iomap_regions() and subsequently accesses MMIO registers at offsets up to 0x10958 (e.g., AMD_P2C_MSG3 at 0x1068C). However, the driver never validates that the BAR size is large enough to cover these accesses. If the driver is bound to a device with a smaller BAR 2, this leads to an out-of-bounds memory access and a page fault during the probe function. For example, a page fault can occur when reading from privdata->mmio + AMD_P2C_MSG3 in mp2_select_ops(): BUG: unable to handle page fault for address: ffffc9000390368c PGD 100000067 P4D 100000067 PUD 1012c1067 PMD 105b64067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline] RIP: 0010:mp2_select_ops drivers/hid/amd-sfh-hid/amd_sfh_pcie.c:282 [inline] RIP: 0010:amd_mp2_pci_probe+0x337/0x5f0 drivers/hid/amd-sfh-hid/amd_sfh_pcie.c:487 Call Trace: local_pci_probe drivers/pci/pci-driver.c:332 [inline] pci_call_probe drivers/pci/pci-driver.c:394 [inline] __pci_device_probe drivers/pci/pci-driver.c:455 [inline] pci_device_probe+0x431/0xc90 drivers/pci/pci-driver.c:489 Fix this by verifying that the length of BAR 2 is at least 128KB before attempting to map it. Since the maximum accessed offset is 0x10958, and PCI BAR sizes are powers of 2, any legitimate hardware will have a BAR size of at least 128KB. Fixes: 4f567b9f8141 ("SFH: PCIe driver to add support of AMD sensor fusion hub") Assisted-by: Gemini:gemini-3.7-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+4eadd4dfe9e66522bae8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4eadd4dfe9e66522bae8 Link: https://syzkaller.appspot.com/ai_job?id=3bc1c45c-548f-4ab5-8243-d2c8ec321d6c Signed-off-by: Slawomir Stepien Acked-by: Basavaraj Natikar Link: https://syzkaller.appspot.com/bug?extid=4eadd4dfe9e66522bae8 Signed-off-by: Jiri Kosina commit d7fd1f98607f2cd358e583f9548bdf0173090a86 Author: Namjae Jeon Date: Thu Sep 3 14:06:02 2026 +0900 ksmbd: follow SMB2 session expiration semantics ksmbd_session_register() destroys valid sessions after ten seconds of inactivity whenever a client starts another SessionSetup exchange. This confuses Session.IdleTime with Session.ExpirationTime. Windows can create additional authenticated sessions on an existing connection, so deleting the older session invalidates its tree connects and makes mapped drives fail with STATUS_NETWORK_NAME_DELETED. The session expiration rules require the server to change a valid session to expired only after its credential expiration time passes. A valid or expired session otherwise keeps its connection from being scavenged. Connections that have not negotiated a dialect, have no sessions, or have only InProgress sessions are disconnected after an implementation-specific timeout. Use the Windows-compatible 45 second value and run the expiration check periodically for both TCP and SMB Direct. Keep zero as an infinite credential expiration time, and count each Valid-to-Expired transition. Set expired sessions to InProgress when they reauthenticate. If authentication fails, remove the session from the global and per-connection tables immediately, including SMB3 multichannel connections. Retain protection against abandoned SessionId-zero exchanges by allowing only one InProgress authentication per connection. Additional exchanges fail with STATUS_INSUFFICIENT_RESOURCES, and stale InProgress sessions are reaped after the same 45 second setup timeout. This bounds the original unauthenticated memory-exhaustion path without evicting established sessions. Fixes: ea174a918939 ("ksmbd: destroy expired sessions") Reported-by: Mobin Aydinfar Signed-off-by: Namjae Jeon commit 4396d70bb7fec531bcf934fed016b2f3300c670b Author: Myeonghun Pak Date: Sun Sep 13 18:35:38 2026 -0400 mmc: sdhci-of-aspeed: Remove children before releasing SDC resources Probe failure and removal leave SDHCI child devices registered after the parent clock and managed resources are released. Unregister the OF children in reverse order before disabling the parent clock on both paths. Use of_platform_device_destroy() because manual child creation does not set the flag required by of_platform_depopulate(). This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: bb7b8ec62dfb ("mmc: sdhci-of-aspeed: Add support for the ASPEED SD controller") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Assisted-by: OpenAI:GPT-5.6 Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson commit 1589afe2d099d3e817873bc474676968d7080410 Author: Xiang Mei Date: Mon Sep 14 00:43:24 2026 -0700 ALSA: 6fire: fix OOB write from device-reported iso length usb6fire_pcm_in_urb_handler() sizes each outgoing isochronous packet as (actual_length - 4) / (in_n_analog << 2) * (out_n_analog << 2) + 4, where actual_length is the unsigned length the device reported for the matching IN packet. A packet completed with status 0 and actual_length < 4 wraps the subtraction to 0x7fffffec; a zero-length isochronous packet is legal on the bus, and the preceding loop rejects only non-zero status. The sum reaches memset() on out_urb->buffer, a 4832-byte object from kcalloc(PCM_MAX_PACKET_SIZE, PCM_N_PACKETS_PER_URB). Even without the wrap the result is out of bounds: at 88.2/96 kHz the 4-in/6-out scaling turns a full 420-byte IN packet into 628, so eight packets span 5024 bytes of that buffer. usb_submit_urb() rejects an over-long descriptor only after the memset() and the usb6fire_pcm_playback() copy of user PCM data have run. Guard the subtraction as the sibling usb6fire_pcm_capture() already does, and limit the frame count to what fits in rt->out_packet_size, the OUT endpoint's wMaxPacketSize. This bounds total_length by the buffer size while keeping each packet length aligned to a whole output frame. BUG: KASAN: out-of-bounds in usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338) Write of size 18446744073709551456 at addr ffff88802a3d0000 by task vhci_rx/5018 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) kasan_check_range (mm/kasan/generic.c:186 mm/kasan/generic.c:200) __asan_memset (mm/kasan/shadow.c:84) usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741) vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107 drivers/usb/usbip/vhci_rx.c:242) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 10: __kmalloc_cache_noprof (mm/slub.c:5563) usb6fire_pcm_init (sound/usb/6fire/pcm.c:560 sound/usb/6fire/pcm.c:595) usb6fire_chip_probe (sound/usb/6fire/chip.c:133) usb_probe_interface (drivers/usb/core/driver.c:399) The buggy address belongs to the object at ffff88802a3d0000 which belongs to the cache kmalloc-8k of size 8192 The buggy address is located 0 bytes inside of 4832-byte region [ffff88802a3d0000, ffff88802a3d12e0) Kernel panic - not syncing: Fatal exception in interrupt Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB") Reported-by: co+855929c2df672879@bugs.sh Closes: https://lore.kernel.org/all/gisnub8aWGLbyZLcDCSc7zWsHonMWGcyRgt5%40bugs.sh/ Assisted-by: LLM Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260914074324.3590843-1-xmei5@asu.edu Signed-off-by: Takashi Iwai commit 8039b75af5808572ff3656eaed07d348aed3989a Author: Conor Dooley Date: Mon Aug 31 11:50:59 2026 +0100 pinctrl: mpfs-mssio: use correct regmap function to set bank voltage regmap_assign_bits() is not the correct function to use for an RMW operation, as it maps to regmap_set_bits() or regmap_clear_bits() and the former will never zero a bit. Use regmap_update_bits() instead, which will actually set the bank voltages to what have been requested. CC: stable@vger.kernel.org Fixes: 488d704ed7b7 ("pinctrl: add polarfire soc mssio pinctrl driver") Signed-off-by: Conor Dooley Signed-off-by: Linus Walleij commit e6c5d6c589764a41218cbd81bd7d6c9b906e2cf0 Author: Conor Dooley Date: Mon Aug 31 11:50:58 2026 +0100 pinctrl: mpfs-mssio: fix width of unused bank voltage setting The bank voltages are only 4 bits wide, so when a pin was unused the driver was not correctly interpreting it as being at zero volts, because the driver's value for unused had two extra set bits. CC: stable@vger.kernel.org Fixes: 488d704ed7b7 ("pinctrl: add polarfire soc mssio pinctrl driver") Signed-off-by: Conor Dooley Signed-off-by: Linus Walleij commit 51ae99659469edba2e83931efa26b77d36ca02c2 Author: Sarah Emery Date: Fri Aug 28 17:58:17 2026 +0200 pinctrl: generic: serialise pinctrl_generic_dt_node_to_map() pinctrl_generic_add_group() documents that the caller must take care of locking, and pinmux_generic_add_function() needs it too, but pinctrl_generic_dt_node_to_map() calls them without holding pctldev->mutex, and the core caller in create_pinctrl() does not take it either. The driver core calls pinctrl_bind_pins() before probing a device, so two devices that reference the same pin controller can run pinctrl_generic_dt_node_to_map() on one pctldev at the same time. Both `add` functions take the new selector from pctldev->num_groups or pctldev->num_functions, and radix_tree_insert() at that index. Two racing callers can read the same selector before either has inserted, so the second insert collides and fails: k1-pinctrl d401e000.pinctrl: error -EEXIST: error adding function pcie2-0-cfg k1-pinctrl d401e000.pinctrl: does not have pin group pcie0-0-cfg.pcie0-0-pins leaving one consumer without its pin configuration. This was hit on a SpacemiT K3 board, where PCIe devices probe in parallel against the single shared pin controller. Take pctldev->mutex across the whole function, so that the groups and the function referring are in a single critical section. Fixes: 43722575e5cd ("pinctrl: add generic functions + pins mapper") Signed-off-by: Sarah Emery Signed-off-by: Linus Walleij commit 50fd0ada8d37587223001600933270b59cb30e19 Author: Runyu Xiao Date: Mon Sep 14 13:15:37 2026 +0800 gpio: virtuser: skip free_irq when no IRQ is installed Disabling interrupt monitoring uses atomic_xchg() to clear the stored IRQ. When monitoring is already disabled, atomic_xchg() returns 0. It must not be passed to free_irq(). The bug is reproducible on an x86_64 QEMU guest with CONFIG_GPIO_VIRTUSER=y and CONFIG_GPIO_SIM=y. Configure a live gpio-virtuser device through configfs. Its input lookup must refer to a live gpio-sim bank, such as key gpio-sim-test with offset 0. The consumer's dev_name attribute is shown as below; then run: echo 0 > /sys/kernel/debug/gpio-virtuser//gpiod:input:0/interrupts On an unpatched kernel, this reaches gpio_virtuser_interrupts_set() with ld->irq still at its initial value 0, and free_irq() reports: Trying to free already-free IRQ 0 The same reproducer completes without the warning on the patched kernel. Fixes: 91581c4b3f29 ("gpio: virtuser: new virtual testing driver for the GPIO API") Assisted-by: LLM Signed-off-by: Runyu Xiao Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260914051537.15320-1-runyu.xiao@seu.edu.cn Signed-off-by: Bartosz Golaszewski commit 80756e263846ab694984e749e8c626897331438f Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Sep 9 10:07:37 2026 +0900 thunderbolt: Reject oversized XDomain properties responses tb_xdp_properties_request() allocates room for 45 data dwords in its 252-byte response buffer. The XDomain length field is six bits wide, however, and a malicious peer can set it to 63. After the fixed response fields are subtracted, the driver treats this as 48 data dwords. Commit 322e93448d90 ("thunderbolt: Clamp XDomain response data copy to allocation size") only bounds the copy against data_len. If data_len is at least 48, memcpy() reads 192 bytes from the 180-byte res->data array, causing a 12-byte heap out-of-bounds read. Commit 4db2bd2ed478 ("thunderbolt: Limit XDomain response copy to actual frame size") limits the earlier copy but does not constrain this header-derived length. Reject response data lengths that exceed the allocated source buffer before copying them into the assembled property block. Fixes: d1ff70241a27 ("thunderbolt: Add support for XDomain discovery protocol") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Mika Westerberg commit 692f32609a30f75ca3401e25b504bfd06bd5662a Author: Sean Anderson Date: Mon Aug 17 12:22:11 2026 -0400 pinctrl: meson: Fix typo in s4 group name One of the i2c pin groups has some junk at the end. The name should be i2c2_scl_h1, and indeed that's the name used by i2c2_pins3 in meson-s4.dtsi. Fixes: 775214d389c25 ("pinctrl: meson: add pinctrl driver support for Meson-S4 Soc") Signed-off-by: Sean Anderson Reviewed-by: Neil Armstrong Signed-off-by: Linus Walleij commit 8dc2615d5702059b2b71fca6f93c0d7d10ae54cb Author: Koichiro Den Date: Fri Sep 11 16:30:58 2026 +0900 arm64: dts: renesas: r8a779f0: Set UFS lane count Since commit e72323f3b09f ("scsi: ufs: core: Configure only active lanes during link"), the following error is observed on R-Car S4: ufshcd-renesas e6860000.ufs: Tx lane mismatch [config,reported] [2,1] ufshcd-renesas e6860000.ufs: link startup failed -67 ufshcd-renesas e6860000.ufs: error -ENOLINK: Initialization failed with error -67 ufshcd-renesas e6860000.ufs: probe with driver ufshcd-renesas failed with error -67 R-Car S4 has one UFS lane per direction, as described in section 152.1 of its hardware manual. Without lanes-per-direction, the UFS platform driver defaults to two lanes. Previously, the core used PA_CONNECTEDRXDATALANES and PA_CONNECTEDTXDATALANES to configure the link without checking them against lanes-per-direction, so the missing property did not prevent initialization. Explicitly set lanes-per-direction to 1, now that the validation is in place. Fixes: 5235d551779d ("arm64: dts: renesas: r8a779f0: Add UFS node") Cc: stable@vger.kernel.org # 7.2+ Signed-off-by: Koichiro Den Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260911073058.253000-1-den@valinux.co.jp Signed-off-by: Geert Uytterhoeven commit 242da4318d97380741516b595af3920207b2f0f1 Author: Bartosz Golaszewski Date: Wed Sep 9 14:37:09 2026 +0200 power: sequencing: fix NULL-pointer dereference in pwrseq_device_register() If dev_set_name() fails in pwrseq_device_register(), we jump to the err_put_pwrseq label before initializing pwrseq->targets. pwrseq_release() will try to iterate over targets unconditionally and subsequently dereference an invalid pointer. Move the call to dev_set_name() after the list head is initialized. Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Cc: stable@vger.kernel.org Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260903-pwrseq-kunit-v1-0-1f893d2cabc2%40oss.qualcomm.com?part=2 Link: https://patch.msgid.link/20260909-pwrseq-kunit-v2-3-ef496afc89d2@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit 115b303e8e093d964089ec6f3c40d984d77b33d0 Author: Bartosz Golaszewski Date: Wed Sep 9 14:37:08 2026 +0200 power: sequencing: fix NULL-pointer dereference in pwrseq_unit_new() If memory allocation fails in pwrseq_unit_setup_deps(), pwrseq_unit_put() is called to release the partially initialized unit. However, we've never initialized unit->list and pwrseq_unit_release() will unconditionally call list_del() on it. Initialize unit->list right after allocating the unit struct. Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Cc: stable@vger.kernel.org Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260903-pwrseq-kunit-v1-0-1f893d2cabc2%40oss.qualcomm.com?part=1 Link: https://patch.msgid.link/20260909-pwrseq-kunit-v2-2-ef496afc89d2@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit 5f90f85eae4e9d2e9628b2019870994ba830b533 Author: Bartosz Golaszewski Date: Wed Sep 9 14:37:07 2026 +0200 power: sequencing: don't call .post_enable() if pwrseq_unit_enable() failed If the call to pwrseq_unit_enable() failed in pwrseq_enable(), bail out instead of calling target->post_enable() which assumes the target was successfully enabled. Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260909-pwrseq-kunit-v2-1-ef496afc89d2@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit beb34fe8312eda37b9cf1568550d722530444822 Author: Kitty Makin Date: Mon Sep 14 00:24:24 2026 +0000 ALSA: usb-audio: Add capture quirk for Behringer FCA1616 The Behringer FCA1616 (1397:0004) returns silent capture samples unless its playback endpoint is active. Use the existing fixed implicit-feedback mechanism to keep playback endpoint 0x01 on interface 1 active during capture. Tested with 16-channel S32_LE capture at 44.1 and 48 kHz. Signed-off-by: Kitty Makin Link: https://patch.msgid.link/20260914002334.12691-1-autumnull@posteo.net Signed-off-by: Takashi Iwai commit 2de887f891662814b1160cbfb8c1bf2a5a46d418 Author: Xavier Goffin Date: Sun Sep 13 23:11:55 2026 +0200 ALSA: hda/realtek: Add mute LED quirk for HP OMEN 15-ax On the HP OMEN 15 ax-202nf, the keyboard mute LED is exposed through NID 0x1b rather than 0x18. This reuses the existing quirk (ALC269_FIXUP_HP_MUTE_LED_MIC3) to allow the keyboard LED to reflect the built-in speaker mute state. Tested on HP OMEN 15 ax-202nf with Realtek ALC295: - hda::mute/brightness properly follows mute state - mute/unmute via keyboard shortcut or via GUI volume control - state is kept on suspend & resume, and reboot - plugging a 3.5mm jack headset reflects the headset mute status - unplugging reverts the LED to the speaker mute status - USB/Bluetooth headsets are not covered Signed-off-by: Xavier Goffin Link: https://patch.msgid.link/20260913211155.20305-1-xaviergoffin42@gmail.com Signed-off-by: Takashi Iwai commit ee363e055895364039bf28348ff13c615afad4ba Merge: 953824e508b27d 26a43a5f8c31b9 Author: Alexei Starovoitov Date: Sun Sep 13 21:59:21 2026 -0700 Merge branch 'bpf-arm64-fix-the-exception-callback-s-frame-pointer' Donggeun Yoo says: ==================== bpf, arm64: fix the exception callback's frame pointer The arm64 JIT does not set BPF_REG_FP in the prologue of an exception callback, so the callback runs with whatever x25 held when bpf_throw() was called. A callback that materializes the register, for instance to pass the address of a local variable to a helper, then works on the frame of the subprogram that threw. Patch 1 sets ctx->fp_used on that path, the same fix commit b114fcee766d ("bpf, arm64: Fix fp initialization for exception boundary") made for the exception boundary. Patch 2 adds a selftest that reaches the case. Tested on aarch64 under QEMU with vmtest.sh, on the base below. Without patch 1 the new test panics the kernel, because the address handed to the helper lands on the helper's own saved return address: pc : 0x1234 lr : 0x1234 Call trace: 0x1234 (P) bpf_test_run+0x188/0x3e0 bpf_prog_test_run_skb+0x47c/0x998 __sys_bpf+0xbdc/0xdd8 Kernel panic - not syncing: Oops: Fatal exception in interrupt 0x1234 is the value the callback reads, so the helper wrote it over its own return address. With patch 1 applied the whole group passes: #117/11 exceptions/exception_throw_subprog_stack_cb:OK #117 exceptions:OK Summary: 1/118 PASSED, 0 SKIPPED, 0/0 FAILED Not tested on other architectures. v1: https://lore.kernel.org/bpf/20260904070210.4163193-1-donggeunyoo.kernel@gmail.com/ v2: https://lore.kernel.org/bpf/20260907054235.473103-1-donggeunyoo.kernel@gmail.com/ v2 -> v3: - patch 2: use the standard multi-line comment style - patch 1: no change, added the Acked-by Nothing compiled changed, so the numbers above are still v2's. v1 -> v2: - rebase onto bpf/master; CI could not apply v1 - spell the three new declarations u64 rather than __u64, to match the rest of progs/exceptions.c - no change to patch 1 ==================== Link: https://patch.msgid.link/20260907130624.611942-1-donggeunyoo.kernel@gmail.com Signed-off-by: Alexei Starovoitov commit 26a43a5f8c31b9132dc40a449d0f6c7ecfaa1f40 Author: Donggeun Yoo Date: Mon Sep 7 22:06:24 2026 +0900 selftests/bpf: cover the exception callback using its own BPF stack The existing exception tests do not reach a callback that materializes BPF_REG_FP into a register. They either throw from the main program, where BPF_REG_FP already holds the value the callback needs, or use a callback whose only stack accesses are frame pointer relative, which the arm64 JIT rewrites to be stack pointer relative. Add a test that throws from a subprogram using its own BPF stack, with a callback that hands the address of a local variable to bpf_probe_read_kernel(). The helper and the callback have to name the same slot for the value read back to be the one the helper stored. Signed-off-by: Donggeun Yoo Link: https://lore.kernel.org/r/20260907130624.611942-3-donggeunyoo.kernel@gmail.com Signed-off-by: Alexei Starovoitov commit ef1fb82f12186dd26153b14d9fbcf4ec98db81b3 Author: Donggeun Yoo Date: Mon Sep 7 22:06:23 2026 +0900 bpf, arm64: set up the frame pointer for the exception callback A program acting as exception boundary saves all callee-saved registers, so build_prologue() takes the exception_cb path and never calls push_callee_regs(). That is the only place find_used_callee_regs() runs, and with it the only place ctx->fp_used is set, so the callback prologue does not emit the mov x25, sp that points BPF_REG_FP at the frame the callback runs on. x25 keeps whatever it held when bpf_throw() was called. If the throw came from a subprogram that uses its own BPF stack, that is the subprogram's frame pointer, and since the subprogram never returns it never restores x25 either. Stack accesses through BPF_REG_FP are rewritten to be stack pointer relative, so those still land in the callback's own frame. Materializing the register does not: a callback that passes the address of a local variable to a helper hands over an address in the dead subprogram's frame. That address is below the callback's stack pointer by then, and the helper's own call chain covers it, so the helper can write over its own return address. 0x1234 below is the value the helper was asked to store: pc : 0x1234 lr : 0x1234 Call trace: 0x1234 (P) bpf_test_run+0x188/0x3e0 bpf_prog_test_run_skb+0x47c/0x998 __sys_bpf+0xbdc/0xdd8 Kernel panic - not syncing: Oops: Fatal exception in interrupt Set ctx->fp_used on the exception callback path so that the existing code further down sets x25 from the stack pointer. The epilogue restores it from the main program's save area along with the other callee-saved registers, as it already does. x86 sets the frame pointer for the callback from the argument it is passed, and powerpc computes it from the stack pointer. Fixes: 5d4fa9ec5643 ("bpf, arm64: Avoid blindly saving/restoring all callee-saved registers") Acked-by: Xu Kuohai Signed-off-by: Donggeun Yoo Link: https://lore.kernel.org/r/20260907130624.611942-2-donggeunyoo.kernel@gmail.com Signed-off-by: Alexei Starovoitov commit 953824e508b27d12837e32ef37ef6248e1f6fc7a Author: Masoud Aghasi Date: Thu Sep 3 09:27:34 2026 +0100 bpf: Fix u32 overflow issue in map batch operations Several map batch operation implementations such as generic_map_lookup_batch() use calculations in the form of "values + cp * map->value_size" to compute the desired userspace memory address for reading or writing. This can overflow the u32 type (the result of "cp * map->value_size") when the map size exceeds 4GB. generic_map_lookup_batch() may corrupt values for some keys in userspace memory, and in some cases it mismatches values for some keys while still reporting success. Other batch operations may fail to delete or update some keys, or the syscall may return unexpected errors. Add size_t casts to prevent the affected offset and size calculations from overflowing. Fixes: cb4d03ab499d ("bpf: Add generic support for lookup batch op") Fixes: aa2e93b8e58e ("bpf: Add generic support for update and delete batch ops") Fixes: 057996380a42 ("bpf: Add batch ops to all htab bpf map") Signed-off-by: Masoud Aghasi Link: https://lore.kernel.org/r/20260903082734.623904-1-maghasi@disroot.org Signed-off-by: Alexei Starovoitov commit 490a83d6386eec1d29f470c8d7331677fb46c3b7 Author: Geliang Tang Date: Tue Sep 8 17:08:32 2026 +0800 bpf, sockmap: Fix self-redirect copied_seq double-counting When a BPF stream_verdict program redirects an skb back to the same socket (self-redirect with BPF_F_INGRESS), sk_psock_verdict_apply() calls tcp_eat_skb() which advances tcp_sk->copied_seq. However, the skb is then delivered to the socket's psock ingress queue and later read by tcp_bpf_recvmsg_parser(), which also advances copied_seq via the copied_from_self accounting path. This double-counting causes copied_seq to advance by 2x the actual data length, triggering: TCP recvmsg seq # bug 2: copied BF2E806, seq BF2E7FD, \ rcvnxt BF2E806, fl 0 WARNING: net/ipv4/tcp.c:2745 at tcp_recvmsg_locked+0x72b/0x2640 Call Trace: tcp_recvmsg+0x10a/0x500 sock_recvmsg+0x168/0x1d0 __sys_recvfrom+0x19a/0x2a0 __x64_sys_recvfrom+0xe4/0x1f0 do_syscall_64+0xf7/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f cleanup rbuf bug: copied BF2E806 seq BF2E806 rcvnxt BF2E806 WARNING: net/ipv4/tcp.c:1609 at tcp_cleanup_rbuf+0xf2/0x1c0 Call Trace: tcp_recvmsg_locked+0x8d1/0x2640 tcp_recvmsg+0x10a/0x500 sock_recvmsg+0x168/0x1d0 __sys_recvfrom+0x19a/0x2a0 __x64_sys_recvfrom+0xe4/0x1f0 do_syscall_64+0xf7/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by converting self-redirect verdict to __SK_PASS at the beginning of sk_psock_verdict_apply(). This bypasses the __SK_REDIRECT case entirely (which calls sk_psock_eat_skb), letting the __SK_PASS path queue the skb to the psock ingress queue. The data is then read via tcp_bpf_recvmsg_parser(), which advances copied_seq exactly once through copied_from_self. Cross-socket redirects continue through __SK_REDIRECT with sk_psock_eat_skb() unchanged. Fixes: e5c6de5fa025 ("bpf, sockmap: Incorrectly handling copied_seq") Suggested-by: Jakub Sitnicki Suggested-by: Jiayuan Chen Signed-off-by: Geliang Tang Reviewed-by: Emil Tsalapatis Reviewed-by: Jiayuan Chen Link: https://lore.kernel.org/r/1a8e797a1b26e2f695aaac22ac644c2862f63466.1788858299.git.tanggeliang@kylinos.cn Signed-off-by: Alexei Starovoitov commit 06bd6794b5fd2163880ac3bfe973d4cc61f359f3 Author: Nuno Sá Date: Fri Sep 11 14:53:37 2026 +0100 hwmon: (pmbus/core) increase number of phases and add new mask Increase the number of phases to 16 as a new upcoming device supports such a number. While at it, add a new mask for controlling the source of the output voltage. Note (groeck): This patch was meant to prepare for support of MAX20826 and compatible devices, which support more than 10 phases per page. However, Sashiko reports that the mp2975 driver already supports up to 14 phases, and the mp2856 driver supports up to 12 phases. This already has the potential for out-of-bounds writes when probing the affected chips, making this patch a bug fix. Fixes: 2c6fcbb21149 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2975 controller") Fixes: f9e5f289b686 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2856/mp2857 controller") Signed-off-by: Nuno Sá Link: https://patch.msgid.link/20260911-hwmon-max20826-support-v2-1-5e30cbd97d84@analog.com Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck commit 3550d1dbbcb9f51b77e077e8958423ee2c401c6c Author: Thomas Richard (congatec GmbH) Date: Fri Sep 11 19:31:59 2026 +0200 hwmon: (cgbc-hwmon) Add missing sensors Add the following sensors: - Alternate Board Temperature (temp11_input) - Top DIMM 1-7 Temperature (temp12_input to temp18_input) - Bottom DIMM 1 Temperature (temp19_input) - 12V Standby Voltage (in14_input) This fixes the following warning on conga-SA7: Board Controller returned an unknown sensor (bc_type=1, bc_id=11), ignore it Also update existing labels to match Congatec documentation. Cc: stable@kernel.org Fixes: 08ebc9def79f ("hwmon: Add Congatec Board Controller monitoring driver") Signed-off-by: Thomas Richard (congatec GmbH) Link: https://patch.msgid.link/20260911-cgbc-hwmon-fix-and-new-sensors-v2-2-0c6bf078d173@bootlin.com Signed-off-by: Guenter Roeck commit 7bae83ffb133bc373d098fa6828cef2ef4da49fe Author: Thomas Richard (congatec GmbH) Date: Fri Sep 11 19:31:58 2026 +0200 hwmon: (cgbc-hwmon) Fix current sensors ID lookup Current sensors on the Congatec Board Controller don't use consecutive IDs, unlike other sensor types (voltage, temperature, fan). The driver assumed consecutive IDs and performed a simple lookup, which caused an unknown sensor warning. Define current sensor IDs explicitly. Changes the warning on conga-SA7 (type and channel are correct now). Before: Board Controller returned an unknown sensor (type=2, channel=17), ignore it After: Board Controller returned an unknown sensor (bc_type=1, bc_id=11), ignore it Cc: stable@kernel.org Fixes: 08ebc9def79f ("hwmon: Add Congatec Board Controller monitoring driver") Signed-off-by: Thomas Richard (congatec GmbH) Link: https://patch.msgid.link/20260911-cgbc-hwmon-fix-and-new-sensors-v2-1-0c6bf078d173@bootlin.com Signed-off-by: Guenter Roeck commit 26d5ff79768548efb1e604bb6e8697c101e06269 Author: Yibo Tan Date: Fri Sep 11 15:18:09 2026 +0800 hwmon: (pwm-fan) Stop RPM timer before freeing tach data sample_timer() rearms the RPM timer and accesses the devm-managed ctx->tachs and ctx->pulses_per_revolution arrays. The cleanup action which stops the timer is registered before those arrays are allocated. Since devres releases entries in reverse order, driver detach can free the arrays before pwm_fan_cleanup() shuts down the timer. A timer expiry in that window accesses the freed tach data. With a KASAN kernel, a test-only kprobe delayed entry to pwm_fan_cleanup() while normal sysfs unbind ran. Each of three runs reported three four-byte reads and two four-byte writes in sample_timer() after its backing devm allocations had been freed. The helper did not invoke the timer callback, cleanup actions or free functions. With the fix, three matching unbind runs completed without KASAN, BUG, WARNING, Oops or panic. Instrumentation confirmed that timer retirement completed before the first timer backing allocation was released. Split timer retirement from the power cleanup and register its devres action after the timer backing data and IRQ actions are installed. This preserves the early power rollback action while ensuring the timer is retired before its backing data is released. Use timer_shutdown_sync() because the callback can rearm itself. Fixes: 01695410d452 ("hwmon: (pwm-fan) Store tach data separately") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Yibo Tan Link: https://patch.msgid.link/20260911071809.130151-1-lhfff@tju.edu.cn Signed-off-by: Guenter Roeck commit 451b1c19dc7cbbad194a6e717b6a732c443d7dd5 Author: Rong Zhang Date: Fri Sep 11 02:39:25 2026 +0800 hwmon: (k10temp) Fix model id range of Zen5 Turin Model 20h-2Fh are mobile processors with single CCD. For example, model 24h is Strix Point, i.e., Ryzen AI 7 (PRO) (H/HX) 360/365/370. Including mobile processors in the model id range of Zen5 Turin processors leads to bogus reporting: k10temp-pci-00c3 Adapter: PCI adapter Tctl: +54.1°C Tccd4: +148.6°C Tccd6: +148.4°C Tccd7: +149.1°C Tccd8: +149.2°C Tccd9: +149.2°C Tccd12: +149.1°C Tccd14: +22.0°C Tccd15: +22.0°C Tccd16: +22.0°C Fix it by removing the said range. Fixes: 8440d5aca227 ("hwmon: (k10temp) Add per-CCD temperature monitoring for Zen5 Turin") Signed-off-by: Rong Zhang Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260911-k10temp-fix-zen5-epyc-v1-1-643f5a248ae1@rong.moe Signed-off-by: Guenter Roeck commit 1c21452d02eec2f008e2c5535820f85adbd7587a Author: Pu Lehui Date: Sat Sep 5 02:11:39 2026 +0000 bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk Syzkaller repeatedly triggered UAF splats related to nodes in waiting_for_gp_ttrace within the bpf memalloc: BUG: KASAN: slab-use-after-free in llist_del_first+0x85/0x110 lib/llist.c:61 Read of size 8 at addr ffff8881572cd080 by task syz.4.470/5112 ... llist_del_first+0x85/0x110 lib/llist.c:61 alloc_bulk+0x193/0x460 kernel/bpf/memalloc.c:229 bpf_mem_refill+0x386/0x560 kernel/bpf/memalloc.c:436 Freed by task 14: ... __free_rcu kernel/bpf/memalloc.c:281 [inline] __free_rcu_tasks_trace+0x48/0xd0 kernel/bpf/memalloc.c:291 rcu_tasks_invoke_cbs+0x1ec/0x3e0 kernel/rcu/tasks.h:571 rcu_tasks_one_gp+0x13d/0x220 kernel/rcu/tasks.h:621 rcu_tasks_kthread+0xf3/0x120 kernel/rcu/tasks.h:651 The reason is that the UAF occurs after the RCU Tasks Trace GP expires: when the __free_rcu() callback runs, there is no synchronization protecting llist_del_all() against concurrent alloc_bulk() operating on waiting_for_gp_ttrace, leading to the race condition below: CPU0 CPU1 __free_rcu (RCU Tasks Trace callback) alloc_bulk llist_del_first(&c->waiting_for_gp_ttrace) entry = smp_load_acquire(&head->first); do { if (entry == NULL) return NULL; free_all(llist_del_all(&c->waiting_for_gp_ttrace)) llist_for_each_safe(pos, t, llnode) free_one(pos); next = READ_ONCE(entry->next); <-- trigger UAF } while (!try_cmpxchg(&head->first, &entry, next)); In addition, there is also a theoretical race condition on the free_by_rcu_ttrace list. This race requires two preconditions: an in-flight Tasks Trace GP keeping c->call_rcu_ttrace_in_progress == 1, and concurrent cross-CPU frees repopulating c->free_by_rcu_ttrace with new nodes. Under these conditions, the following scenario triggers UAF: // CPU0 // irq work is still busy (on PREEMPT_RT) alloc_bulk() llist_del_first(&c->free_by_rcu_ttrace) entry = smp_load_acquire(&head->first); do { if (entry == NULL) return NULL; // CPU1 bpf_mem_alloc_destroy() WRITE_ONCE(c->draining, true) // wait for CPU0 irq_work_sync() // CPU2 do_call_rcu_ttrace(tgt(CPU0)) if (c->draining) { llist_del_all(&c->free_by_rcu_ttrace) free_all() } // CPU0 continue next = READ_ONCE(entry->next); <-- trigger UAF while (!try_cmpxchg(&head->first, &entry, next)); Fix this by introducing a raw spinlock to synchronize the concurrent consumption on waiting_for_gp_ttrace and free_by_rcu_ttrace. Fixes: 04fabf00b4d3 ("bpf: Allow reuse from waiting_for_gp_ttrace list.") Suggested-by: Alexei Starovoitov Suggested-by: Hou Tao Signed-off-by: Pu Lehui Acked-by: Hou Tao Link: https://lore.kernel.org/r/20260905021139.4116529-1-pulehui@huaweicloud.com Signed-off-by: Alexei Starovoitov commit 309731e95917125bbd13626a7a5600490a5bf44f Author: Runyu Xiao Date: Wed Sep 2 23:40:04 2026 +0800 Input: hp_sdc - shut down kicker timer on module exit hp_sdc_kicker() rearms hp_sdc.kicker with mod_timer() after scheduling the tasklet. The module exit path uses timer_delete_sync(). That waits for a callback already running but can still leave the timer rearmed. A callback can therefore leave the timer pending while hp_sdc_exit() tears down the driver, allowing timer activity to access dismantled driver state. Use timer_shutdown_sync() for final teardown. It waits for a running callback and prevents rearming after module exit begins. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Acked-by: Helge Deller Link: https://patch.msgid.link/20260902154004.3595416-1-runyu.xiao@seu.edu.cn Signed-off-by: Dmitry Torokhov commit 971fa7ea8621e123feb9c8d7dc61be1c656bd945 Author: Erich Sartison Date: Thu Sep 3 12:31:37 2026 +0200 Input: xpad - add support for Victrix Pro BFG Controller The controller doesn't currently work via USB-cable. Signed-off-by: Erich Sartison Link: https://patch.msgid.link/20260903103137.630170-1-byt.es@mailbox.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov commit 55fc280e951ab2b39f3dcb640edc1b1eebc6d173 Author: Rob Herring (Arm) Date: Mon Aug 31 14:43:51 2026 -0500 Input: tsc2007 - read "ti,poll-period" as u32 The "ti,poll-period" property is documented as a normal uint32 cell. The driver used a u64 helper, which makes the helper type disagree with the schema even though the stored value is still small. Read "ti,poll-period" with the u32 helper matching the documented DT cell size. Assisted-by: Codex:gpt-5-5 Signed-off-by: Rob Herring (Arm) Link: https://patch.msgid.link/20260831194352.1185860-1-robh@kernel.org Signed-off-by: Dmitry Torokhov commit 7e61560628d17ea6b1d8ee370f6d42694cff8758 Author: Ulises Mendez Martinez Date: Fri Sep 4 15:07:09 2026 +0000 objtool: Validate disassembler headers in libopcodes probe commit 3f2de814c059 ("objtool: Fix libopcodes linking with static libraries") tested for libopcodes availability by linking a test snippet with a forward declaration of disassemble_init_for_target(). However, testing symbol linkage with an extern declaration only verifies the presence of the library (.so/.a) and bypasses checking for development headers (binutils-dev). On systems where libopcodes is present without development headers installed, the probe succeeds, enabling BUILD_DISAS. Subsequent compilation of objtool then fails: fatal error: 'bfd.h' file not found 113 | #include Additionally, the probe invokes $(HOSTCC) without $(HOSTCFLAGS), ignoring any sysroot or include flags specified for the host compiler. Fix this by including and directly in the test snippet, passing $(HOSTCFLAGS) so host compiler options are respected, and defining PACKAGE="objtool" to satisfy the configuration check in . Fixes: 3f2de814c059 ("objtool: Fix libopcodes linking with static libraries") Fixes: 436326bc525d ("objtool: fix build failure due to missing libopcodes check") Reported-by: Alice Ryhl Assisted-by: Antigravity:Gemini-Next Signed-off-by: Ulises Mendez Martinez Link: https://patch.msgid.link/20260904150710.2997558-1-umendez@google.com Signed-off-by: Josh Poimboeuf commit 45b0037899704caf9078be2be4de69361ca7d933 Author: Karl Mehltretter Date: Sat Sep 5 12:20:38 2026 +0200 Input: trackpoint - fix the inertia attribute name in the ABI document The attribute is created as "inertia" (TRACKPOINT_INT_ATTR(inertia, ...) in drivers/input/mouse/trackpoint.c); the ABI file spells the path "intertia". The description below it already says inertia. Fix the spelling. Fixes: aebb47d4e7a9 ("Input: trackpoint: document sysfs interface") Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260905102038.42882-1-kmehltretter@gmail.com Signed-off-by: Dmitry Torokhov commit a52ae68a937efc353251aec27fc995ff66cbe1ca Author: hpp.iscas Date: Sat Sep 5 21:40:04 2026 +0800 Input: eeti_ts - publish the OF module alias The EETI driver matches eeti,exc3000-i2c Device Tree clients, but only publishes the legacy eeti_ts I2C ID. The I2C core emits an OF modalias for a Device Tree client. Publish the existing OF match table within its CONFIG_OF guard. Fixes: e32d7f1b246c ("Input: eeti - add device tree matching table") Signed-off-by: hpp.iscas Link: https://patch.msgid.link/20260905134004.66336-1-hppiscas@163.com Signed-off-by: Dmitry Torokhov commit cba76c0f47af1a389d718c5bb69e75cbd67bba98 Author: Roberts Kursitis Date: Sun Sep 6 17:30:40 2026 +0300 Input: xpad - add support for Azeron devices Azeron controllers (Cyro, Cyborg, Classic/Compact, Cyro Lefty, Cyborg II and Keyzen) present a standard Xbox 360 controller interface, so they work with the existing xpad driver once their USB IDs are added. The 0x16d0 vendor ID is a shared block, but this is safe because xpad only binds interfaces that match the Xbox 360 signature. Tested with an Azeron Keyzen. Signed-off-by: Roberts Kursitis Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260906143040.162418-1-roberts.kursitis@azeron.eu Signed-off-by: Dmitry Torokhov commit 704340f1cd0dcef829eb62f5b48ae95a2ce17bdf Merge: fd73f4a6659897 27600805e62f80 Author: Linus Torvalds Date: Sun Sep 13 17:50:28 2026 -0700 Merge tag 'x86_urgent_for_7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Dave Hansen: "The most notable fix is THP not silently losing user data and having been around for a couple of years. The main explanation I'd have for its longevity is that it requires a few different things to align at the same time: MADV_FREE, THP and heavy reclaim. - Fix user-space data loss with THP - Fix set_memory oopses - Fix addition of large constants in mul_u64_add_u64_div_u64() - Fix FineIBT hash offset in cfi_get_func_hash() - Fix PCI device reference counting in amd_smn_init()" * tag 'x86_urgent_for_7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/amd_node: Fix PCI device reference counting in amd_smn_init() x86/div64: Fix addition of large constants in mul_u64_add_u64_div_u64() x86/cfi: Fix FineIBT hash offset in cfi_get_func_hash() x86/mm: Fix user-space data loss with MADV_FREE and THP x86/mm/pat: Allocate split page tables as kernel page tables x86/alternatives: Exclude text poking against change_page_attr() x86/mm/pat: Acquire init_mm read lock on attribute changes to avoid UAF x86/mm/pat: Acquire init_mm write lock on collapse to avoid UAF commit 7bc369cb3d3f3656eb77285628ee264264d28ad4 Author: Jeremy Nyberg Date: Sun Sep 13 17:43:02 2026 -0700 Input: xpad - fix PDP Marvel Xbox 360 controller The PDP Marvel Xbox 360 controller with USB ID 0e6f:0147 is incorrectly classified as an Xbox One controller. With the current XTYPE_XBOXONE classification, the controller is detected but produces no input, while its four player LEDs continue blinking indefinitely. Classify USB ID 0e6f:0147 as an Xbox 360 controller instead. Tested on a PDP Marvel Xbox 360 controller with USB ID 0e6f:0147. All inputs register correctly and the player LED indicates the current player. Fixes: c225370e01b8 ("Input: xpad - sync supported devices with 360Controller") Cc: stable@vger.kernel.org Signed-off-by: Jeremy Nyberg Link: https://patch.msgid.link/20260910071627.236014-1-SlickStretch3.0@gmail.com Signed-off-by: Dmitry Torokhov commit ea48250a0dc9708c198e8665391973bfc6c86fd2 Author: Dmitry Torokhov Date: Sun Sep 13 17:19:48 2026 -0700 Input: document that no new LED codes should be added Add a comment to input-event-codes.h clarifying that no new LED definitions should be added to the input subsystem. The existing LED_* definitions are legacy and grandfathered for backwards compatibility with userspace via evdev. Any new LED indicators should instead use the dedicated LED subsystem. Signed-off-by: Dmitry Torokhov commit fb5022278b6ea7f1838e3ef78028d5d5e3375f65 Author: Hans de Goede Date: Wed Sep 9 11:39:34 2026 +0200 Input: soc_button_array - check btns_desc->package.count Check that btns_desc->package.count is not 0 before accessing btns_desc->package.elements[0]. Fixes: 4c3362f44980 ("Input: soc_button_array - add support for ACPI 6.0 Generic Button Device") Cc: stable@vger.kernel.org Reported-by: Shashiko Closes: https://lore.kernel.org/linux-input/20260909091440.3384C1F00A3A@smtp.kernel.org/ Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20260909093934.29411-2-johannes.goede@oss.qualcomm.com Signed-off-by: Dmitry Torokhov commit ed22ad5fdbdbf9b4cb4ad3003f60314b5a5eb89d Author: Hans de Goede Date: Wed Sep 9 11:39:33 2026 +0200 Input: soc_button_array - fix MS Surface Pro 11 probe failure On the MS Surface Pro 11 soc_button_array probing races with the GPIO driver probing. If soc_button_array wins the race then gpiod_get() returns EPROBE_DEFER, which should normally take care of retrying later, but the soc_button_array code deliberately ignores EPROBE_DEFER causing it to fail its probe() which causes the volume and power buttons to now work. The ignoring of EPROBE_DEFER is there to deal with a problem specific to older Bay Trail (BYT) and Cherry Trail (CHT) tablets which often use this driver. Modify the error handling to only ignore EPROBE_DEFER on BYT and CHT platforms and propagate EPROBE_DEFER normally on other platforms. Fixes: bcf059578980 ("Input: soc_button_array - partial revert of support for newer surface devices") Cc: stable@vger.kernel.org Reported-by: Sergey Lebedev Closes: https://lore.kernel.org/lkml/20260830141355.55898-1-lsa.uz@pm.me/ Signed-off-by: Hans de Goede Tested-by: Sergey Lebedev Link: https://patch.msgid.link/20260909093934.29411-1-johannes.goede@oss.qualcomm.com Signed-off-by: Dmitry Torokhov commit 930a7312c946bf4731721cadd82bb9a2ada496ca Author: Gabor Juhos Date: Wed Sep 9 16:08:25 2026 +0200 spi: spi-qpic-snand: avoid writing QPIC_EBI2_ECC_BUF_CFG register The description of commit bfb34eced559 ("mtd: rawnand: qcom: avoid writing to obsolete register") says this: "QPIC_EBI2_ECC_BUF_CFG register got obsolete from QPIC V2.0 onwards. Avoid writing this register if QPIC version is V2.0 or newer." Although the referenced commit is related to the 'qcom-nandc' driver, however the hardware supported by the current driver is also based on QPIC v2.0 so we should avoid writing that register here as well. Remove the register writing code to avoid undefined behaviour. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Signed-off-by: Gabor Juhos Reviewed-by: Md Sadre Alam Link: https://patch.msgid.link/20260909-qpic-snand-avoid-ebi2-reg-write-v1-1-9b1b1466cc75@gmail.com Signed-off-by: Mark Brown commit 576725ded009f09a28da19852f7edf62dbc5f94c Author: Ai Chao Date: Fri Sep 11 16:19:32 2026 +0800 ASoC: Intel: sof_es8336: Add a quirk for Huawei Matebook B3-420 Add DMI entry for Huawei Matebook B3-420 (BDZ-WXX9) with HEADPHONE_GPIO and HEADSET_MIC1 quirks. Similar to Huawei Matebook D (BOD-WXX9). On the same machine,audio routing between speakers and headphones works correctly when running Windows with the Huawei audio driver. However, after reinstalling Linux, both the speakers and headphones output sound simultaneously,indicating that the amplifier enable GPIOs are not being toggled correctly to separate the two outputs. Signed-off-by: Ai Chao Link: https://patch.msgid.link/20260911081932.2605407-1-aichao@kylinos.cn Signed-off-by: Mark Brown commit 0cde044bc4768203ae70840eafe9df1290d8cb22 Merge: d56fe35c1bce1f b5b00a57868b1e Author: Mark Brown Date: Mon Sep 14 00:37:42 2026 +0100 ASoC: Fix missing channel fixup for codec end of ch_map Richard Fitzgerald says: Struct snd_soc_dai_link_ch_map had a single mask member to set the CPU channel masks. But no fixup was done to the codec end of the link. For example if a 4-channel CPU capture DAI was made from two codecs both supplying 2 channels, the hw_params() of the codec would be passed a channel count of 4. On SoundWire this could cause multiple codecs to send data in the same bits of a frame because the unused channels were not disabled. The changes in this series are: - Separate channel masks for CPU and codec in struct snd_soc_dai_link_ch_map . - Apply the codec channel mask as a channel count fixup if the machine drive has not set a TDM mask. - Set the codec channel mask in the SoundWire machine driver. - Remove the workaround from the cs_amp machine driver. Link: https://patch.msgid.link/20260910114500.1586637-1-rf@opensource.cirrus.com commit b5b00a57868b1eabdf90a29a51f0eb732c609f3a Author: Richard Fitzgerald Date: Thu Sep 10 12:45:00 2026 +0100 ASoC: sdw_utils: cs_amp: Delete bogus and incorrect capture channel fixup Delete the asoc_sdw_cs_spk_feedback_rtd_init(). This is not needed now that the ASoC bug it was working around has been fixed. And it was broken anyway because it didn't match the way the core SoundWire code mapped codec channels to frame bitslots. This code was added to avoid a problem where multiple codec DP outputs were mapped to the same SoundWire frame bit slot. This would allow a user to break the SoundWire bus just by enabling mixer outputs using ALSA controls. As no production system has used the capture stream, this workaround was of little consequence and the problem of conflicting DP mappings was not investigated. The ASoC bug that enabled too many channels on each codec has now been fixed. So this workaround can be completely deleted. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260910114500.1586637-6-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit 290845e151cd4e307cc1f25319583aaceb4eeb30 Author: Richard Fitzgerald Date: Thu Sep 10 12:44:59 2026 +0100 ASoC: sdw_utils: Set snd_soc_dai_link_ch_map.codec_ch_mask for capture In asoc_sdw_hw_params() set the codec_ch_mask member of struct snd_soc_dai_link_ch_map for capture streams. ASoC will then pass the correct number of channels to each codec hw_params(). This prevents trying to enable more channels on the codec DP than have been allocated bitslots in the SoundWire frame, which would cause bus clash errors. In theory codec_ch_mask could also be set for playback streams, but for those the CPU is the only sender so there is no risk of bus clash. For playback streams codec_ch_mask is set to 0 to preserve the existing behavior and avoid introducing bugs. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260910114500.1586637-5-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit 6b382bdfe26a2232091bf743e454e6794295783e Author: Richard Fitzgerald Date: Thu Sep 10 12:44:58 2026 +0100 ASoC: soc-pcm: Apply snd_soc_dai_link_ch_map.codec_ch_mask to codec params In __soc_pcm_hw_params() if there is a snd_soc_dai_link_ch_map with non-zero codec_ch_mask, use that channel mask to restrict which channels are enabled on the codec. But only if there isn't a TDM mask. It is possible that a snd_soc_dai_link_ch_map could include the same codec multiple times on different CPUs so the for_each_rtd_ch_maps() loop accumulates the channel masks for all entries of that codec. If a TDM mask was also set, it takes priority and is used instead of any possible snd_soc_dai_link_ch_map entries. (They cannot be ANDed together because the bit positions are indicating different things: TDM is a bit for each TDM slot, codec_ch_mask is a bit for each codec channel.) This fixes a problem of incorrect TX channels enabled on the codec when multiple codecs are aggregated on a single capture link. For example: - Two CPUs with six 4-channel codecs. - The machine driver chooses to assign one channel from each codec to one channel on the CPU - But the codec hw_params() would be passed a channel count of 6, which (a) is more channels than the codec has and (b) allows enabling channels that should not be driving the audio bus. Fixes: ac950278b087 ("ASoC: add N cpus to M codecs dai link support") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260910114500.1586637-4-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit 88b14c0d0bab5c0f3e7c641f274e3c70210c0e36 Author: Richard Fitzgerald Date: Thu Sep 10 12:44:57 2026 +0100 ASoC: Add codec_ch_mask to snd_soc_dai_link_ch_map Add a codec_ch_mask member to snd_soc_dai_link_ch_map. The CPU and codec channel masks are not necessarily the same, and are quite likely different. SoundWire and I2S/TDM both support assigning different sample slots to each codec, so for example channel 0 on each codec could map to different channels at the CPU. It is also possible for one TX channel to map to multiple RX channels. So it isn't _always_ safe to assume that the total number of set bits in the CPU ch_mask is the same as the total number of enabled channels on the codec. For example consider this mapping on a capture stream: CPU0 CODEC0 cpu_ch_mask = 0x03 CPU1 CODEC0 cpu_ch_mask = 0x03 This could be either four TX channels on the codec split across two receiving CPUs, or two TX channels on the codec duplicated to two CPUs. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260910114500.1586637-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit 4d855d747521505b54457c96bc73577bf74b2374 Author: Richard Fitzgerald Date: Thu Sep 10 12:44:56 2026 +0100 ASoC: Rename snd_soc_dai_link_ch_map.ch_mask to cpu_ch_mask Rename the ch_mask member of snd_soc_dai_link_ch_map to cpu_ch_mask, as that is what it is used for. The CPU and codec channel masks are not necessarily the same, and are quite likely different. SoundWire and I2S/TDM both support assigning different sample slots to each codec, so for example channel 0 on each codec could map to different channels at the CPU. So it's quite normal that the channel mask at the CPU end is different for each codec, but the codec channel masks are the same for each codec. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260910114500.1586637-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit d56fe35c1bce1f547eb600695f60c139a508ff6e Author: Jack Yu Date: Wed Sep 9 16:54:49 2026 +0800 ASoC: rt712-sdca: reconfigure PLL2 to fix calibration time-out Add pll2 reconfiguration sequence in order to fix calibration time-out issue and to support 24.576MHz MCLK on specific platforms. Signed-off-by: Jack Yu Link: https://patch.msgid.link/20260909085449.862350-1-jack.yu@realtek.com Signed-off-by: Mark Brown commit 88c4aff39452d7f0ab59f13730182a43bc7257c6 Author: Richard Fitzgerald Date: Thu Sep 10 13:10:46 2026 +0100 ASoC: wm_adsp: Firmware search progress log should not look like an error In wm_adsp_request_firmware_file() only log the "Failed to request FILENAME" message when there is a real error (not when the file is missing). Add a new debug message to log the sequence of filenames tried during the file search. People have enabled debug messages, seen the "Failed to request" messages that are only logging the normal file search sequence, and reported them as errors. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260910121047.1592541-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit 25e424eb4ae1a662d9c3573218d06ac32f797fc5 Author: Chris Sommers Date: Mon Sep 7 11:27:23 2026 -0700 Input: i8042 - add quirk for Acer Aspire Go 15 AG15-42P On the Acer Aspire Go 15 (AG15-42P), the internal keyboard drops out ~5 seconds after boot on both Linux and Linux-LTS kernels. Keystrokes on the built-in keyboard stop registering while the trackpad and external keyboards remain functional. Testing confirms that booting with the i8042.reset kernel parameter resolves the issue and keeps the internal keyboard responsive. Add SERIO_QUIRK_RESET_ALWAYS to i8042_dmi_quirk_table for the Acer Aspire AG15-42P to automatically apply this quirk on boot. Signed-off-by: Chris Sommers Link: https://patch.msgid.link/20260907182723.2709981-1-chris.sommers@icloud.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov commit 26eb3d92c7a4d7adb1ae1740ca6e8e100b11d1ec Author: Raphaël Larocque Date: Thu Sep 10 12:44:25 2026 -0400 Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722) The Lenovo ThinkPad T440p (PNP ID LEN0036, board id 2722) has a Synaptics touchpad whose SMBus companion is not ready at boot and takes roughly 200 seconds to appear. During this window the touchpad and TrackPoint are completely unresponsive on approximately 50% of boots, making the machine unusable until the companion finally registers. The device is in the topbuttonpad_pnp_ids[] SMBus allowlist, so the kernel attempts to use SMBus/RMI4 mode by default. When the companion is not ready, psmouse_smbus_init() leaves breadcrumbs and returns -EAGAIN, the PS/2 fallback path is taken, but the device does not function properly until the companion appears and RMI4 takes over. Disable SMBus InterTouch for board id 2722 so the touchpad and TrackPoint work immediately via PS/2 from boot. Users can still force SMBus with psmouse.synaptics_intertouch=1 if needed. Tested-by: Raphaël Larocque Signed-off-by: Raphaël Larocque Link: https://patch.msgid.link/20260910164425.12832-1-rlarocque@disroot.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov commit ec31dc39e835ccde0930daccece8c492d28282fc Author: Michael Kelley Date: Mon Aug 31 20:45:14 2026 -0700 Drivers: hv: Don't reset VMBus connection state on error/exit paths In two places, current code forces vmbus_connection.conn_state to DISCONNECTED prior to calling vmbus_disconnect(). But vmbus_disconnect() calls vmbus_initiate_unload(), which unloads the VMBus connection only if the conn_state is CONNECTED. Consequently, the connection remains and the Hyper-V host might continue to send messages or post VMBus interrupts. The problem was introduced in commit 74347a99e73ae ("x86/Hyper-V: Unload vmbus channel in hv panic callback"), in that vmbus_initiate_unload() started checking the current connection state before doing the unload. This commit removed some occurrences where conn_state was forced to DISCONNECTED, but these two remained, apparently due to an oversight at the time. Fix this by not forcing conn_state to DISCONNECTED during VMBus exit, or if a failure occurs when establishing the connection in the first place. Whatever value conn_state has at the time is then read by vmbus_initiate_unload() to determine if there is a connection to be unloaded. Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hyperv/20260805205806.B5AC31F000E9@smtp.kernel.org/ Fixes: 74347a99e73ae ("x86/Hyper-V: Unload vmbus channel in hv panic callback") Signed-off-by: Michael Kelley Signed-off-by: Wei Liu commit 7b74c117e2aac78e0f723e1c9c3644451c56b0d9 Author: Michael Kelley Date: Tue Sep 1 20:01:27 2026 -0700 x86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index() hv_apicid_to_vp_index() currently uses the per-cpu hypercall input and output pages. This function is called when running in VTL2 and when running in an SEV-SNP CoCo VM with no paravisor. In the former case, the output page is allocated, but in the latter case it is not, so the hypervisor stores the output VP index in memory that has not been allocated by the guest. Fix this by using the input page for both input and output. The hypercall has very small input and output, so sharing the same page for both is straightforward. An alternative fix is to allocate the per-cpu output page when running in an SEV-SNP CoCo guest, but this uses significantly more memory, particularly with larger vCPUs counts. Fixes: 86c48271e0d6 ("x86/hyperv: Fix APIC ID and VP index confusion in hv_snp_boot_ap()") Signed-off-by: Michael Kelley Reviewed-by: Tianyu Lan Signed-off-by: Wei Liu commit 0cdd57a4c56115af5d736b5b2d9310ad91494abc Author: Jiangshan Yi Date: Tue Sep 1 11:32:01 2026 +0800 x86/hyperv: Fix stale comments after stimer message mode removal The removal of stimer message mode in commit be0cfab740e5 ("clocksource: hyper-v: Remove support for stimer interrupts in message mode") left a few comments out of date. hv_stimer_setup_percpu_clockev() picked up two typos ("afters", "to allows"), and the hv_synic_suspend() comment still references the deleted hv_stimer_legacy_cleanup(), the legacy non-Direct Mode configuration, and clockevents_unbind_device(), which is no longer on the cleanup path. Update the typos and rewrite the hv_synic_suspend() comment to describe the current Direct Mode path: non-boot CPU stimers are cleaned up via the cpuhp teardown callback hv_stimer_cleanup(), and CPU0's stimer is left alone because it is harmless (interrupts stay disabled across the suspend/resume window) and is shut down later by the timekeeping code. Signed-off-by: Jiangshan Yi Reviewed-by: Michael Kelley Signed-off-by: Wei Liu commit 32ea0a33e3a0fb7c10c601b43e1b2f6c06a3f5fd Author: Waiman Long Date: Sun Aug 30 19:41:24 2026 -0400 Drivers: hv: Avoid infinite retry loop in init_vp_index() There is a retry loop in init_vp_index() where the CPUs from a certain node are stripped out if they have already been in the allocated cpumask or not in HK_TYPE_MANAGED_IRQ housekeeping cpumask. If there is no CPU left, the allocated cpumask is ignored and the process is retried again. However, if the HK_TYPE_MANAGED_IRQ housekeeping cpumask turns out not to contain any CPU in that particular node, that will become an infinite retry loop. This particular problem was reported by sashiko [1]. This should rarely happen, but we still need to guard against this. Fix this infinite loop problem by also skipping NUMA node that has no housekeeping CPU in the inner while loop of init_vp_index(). Also update the early abort check to check for the absence of online housekeeping CPUs instead of just the emptiness of the cpumask. As the outer for loop will only be reached if the housekeeping cpumask has at least one online CPU, a NUMA node with housekeeping CPUs will eventually be found. Link: https://sashiko.dev/#/message/20260422030903.E1BFCC2BCB0%40smtp.kernel.org [1] Fixes: 6640b5df1a38 ("Drivers: hv: vmbus: Don't assign VMbus channel interrupts to isolated CPUs") Signed-off-by: Waiman Long Reviewed-by: Michael Kelley Signed-off-by: Wei Liu commit a5b5cc909931572aec446e129c035b76b3f0c1fa Author: Saim Shujah Date: Fri Aug 28 11:54:40 2026 +0500 drm/msm/dpu: clear pending peripheral flush state dpu_hw_ctl_clear_pending_flush() resets the cached per-block state after a flush transaction, but misses pending_periph_flush_mask. The peripheral flush updater accumulates interface bits in this mask. A later transaction which sets the top-level peripheral flush bit can write stale interface bits to CTL_PERIPH_FLUSH together with the current state. Peripheral flush support was added after the helper started clearing every individual pending flush mask. Clear the peripheral mask together with the other cached child masks. Fixes: 64f7b81f0358 ("drm/msm/dpu: add support of new peripheral flush mechanism") Cc: stable@vger.kernel.org Signed-off-by: Saim Shujah Patchwork: https://patchwork.freedesktop.org/patch/748968/ Link: https://lore.kernel.org/r/20260828065440.140410-1-saimzst@gmail.com Signed-off-by: Dmitry Baryshkov commit fd73f4a6659897191fa0d40695fe370925dd3780 Author: Linus Torvalds Date: Sun Sep 13 14:38:02 2026 -0700 Linux 7.3-rc3 commit 58995b11dfb7dda095d23f22fa4dc79b923b5adf Author: William Bright Date: Wed Aug 12 11:05:52 2026 +0100 drm/msm/dp: fix link bandwidth check when wide bus is enabled msm_dp_display_mode_valid() halves the pixel clock when either YUV420 or wide bus is in use, then uses that halved value both for the controller pixel clock limit and for the DP link bandwidth check. Only YUV420 halves the data crossing the link. Wide bus widens the internal DPU to DP interface to two pixels per clock, halving the controller clock. Every pixel is still transmitted, so the link bandwidth requirement remains. As a result, modes needing up to twice the available link bandwidth pass validation. On the IMDT QCS8550 SBC (rev5 with CYPD6125), where DP runs over USB-C alt mode where only two lanes are available, 3840x2160@60 was accepted despite needing 9.6 Gbps against the 8.64 Gbps the link can carry. Use a separate link pixel clock that is only halved for YUV420 for the bandwidth calculation, leaving the wide bus halving to apply solely to the controller pixel clock limit. With this, 4k@60 is correctly rejected and 4k@30 selected instead. Fixes: df9cf852ca30 ("drm/msm/dp: account for widebus and yuv420 during mode validation") Assisted-by: Claude:claude-opus-5 Signed-off-by: William Bright Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/746145/ Link: https://lore.kernel.org/r/20260812-msm-dp-link-bw-v1-1-b0e3ce1190be@imd-tec.com [DB: dropped useless comment] Signed-off-by: Dmitry Baryshkov commit 6fbbf1e152f34ad3913e4a6476680aba672c5068 Author: Guangshuo Li Date: Sat Aug 8 21:16:24 2026 +0800 drm/msm/adreno: fix autosuspend cleanup during teardown adreno_gpu_init() calls pm_runtime_use_autosuspend(), but adreno_gpu_cleanup() does not call the matching pm_runtime_dont_use_autosuspend() during teardown. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to adreno_gpu_cleanup(). This issue was found by manual code inspection. Fixes: eeb754746b14 ("drm/msm/gpu: use pm-runtime") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/745110/ Link: https://lore.kernel.org/r/20260808131624.2854412-1-lgs201920130244@gmail.com Signed-off-by: Dmitry Baryshkov commit e249a6e2a130c08bb4d8b0a55cbe29754307e5c9 Author: Jesse Casco Date: Sat Aug 8 13:13:25 2026 -0400 drm/msm/dp: skip PUSH_IDLE when the link was never enabled msm_dp_display_atomic_enable() returns early when link training fails, leaving ->power_on false and the main link down. msm_dp_display_atomic_disable() nevertheless writes DP_STATE_CTRL_PUSH_IDLE and waits for an idle-pattern completion that cannot arrive, so every failed enable is followed by "PUSH_IDLE pattern timedout". Every other step of the teardown is already gated on that flag: msm_dp_display_disable(), called from .atomic_post_disable(), returns early on !power_on. The PUSH_IDLE write is the only one that is not, so the controller's runtime-PM reference is then dropped without the link having been taken down. On glymur (Snapdragon X2 Elite) the consequence is not a warning. The SoC does not survive it: TrustZone force-stops the SOCCP and ADSP remote processors and the machine resets silently about 50 ms later, with no oops and no panic. On an ASUS Zenbook A16 (UX3607OA), whose eDP panel does not currently train, this reproduces without any compositor or GPU involvement: # eDP enable has already failed with "Failed link training (rc=-104)" echo 1 > /sys/class/graphics/fb0/blank [535.645455] === marker === [535.694833] qcom_q6v5_pas d00000.remoteproc: fatal error received: \ sys_m_smsm.c:512:TZ force stop [535.694875] remoteproc remoteproc0: crash detected in soccp: type fatal error [535.728857] qcom_q6v5_pas 6800000.remoteproc: fatal error received: \ sys_m_smsm.c:783:err fatal notification received from TZ Gate the PUSH_IDLE write on ->power_on so the disable path is consistent with the rest of the teardown. With this applied the same sequence is harmless and the machine stays up; without it, it resets every time. The unconditional write dates back to the original DP driver (c943b4948b58 ("drm/msm/dp: add displayPort driver support")), but the surrounding code has been restructured several times since, so no Fixes: tag is offered. Note that the eDP link-training failure that exposes this on the A16 is a separate problem in the glymur eDP PHY and is reported separately; this change is about not damaging the machine when training fails, for whatever reason. Tested on ASUS Zenbook A16 (UX3607OA), Snapdragon X2 Elite Extreme, on linux-next next-20260803 and next-20260807. The machine has since been running next-20260807 with this patch as its daily driver. Assisted-by: Anthropic:Claude-Opus-5 Signed-off-by: Jesse Casco Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/745167/ Link: https://lore.kernel.org/r/20260808171325.133041-1-jesse.casco@gmail.com Signed-off-by: Dmitry Baryshkov commit ea9dadeac79cef509a4b8b4a3e3b39a741e63313 Author: Dmitry Baryshkov Date: Thu Jul 30 16:05:13 2026 +0300 drm/msm: mark the fbdev framebuffer as system memory msm_fbdev_driver_fbdev_probe() points screen_buffer at a kernel virtual mapping of the GEM object and uses the deferred sysmem fb ops, but never sets FBINFO_VIRTFB. The framebuffer core then assumes the memory is not in the virtual address space and warns on the first console draw: fb0: sys_fillrect: framebuffer is not in virtual address space. The drm_fbdev_dma, drm_fbdev_shmem and drm_fbdev_ttm helpers all set the flag for system memory. Do the same here. Signed-off-by: Dmitry Baryshkov Assisted-by: Claude:claude-opus-5 Patchwork: https://patchwork.freedesktop.org/patch/743293/ Link: https://lore.kernel.org/r/20260730-drm-msm-fbinfo-virt-v1-1-a27099a6dc58@oss.qualcomm.com Acked-by: Rob Clark # on IRC Signed-off-by: Dmitry Baryshkov commit 22098763a10d9c1340827fcf6edab66f153b27f0 Merge: d681d7ef617ef8 d860c67c051685 Author: Linus Torvalds Date: Sun Sep 13 12:27:00 2026 -0700 Merge tag 'trace-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Don't destroy user event fields when removal fails User event fields are destroyed before the event is removed from visibility. But that can fail leaving the still visible event with no fields. Move the destroying of the fields to after the event is successfully removed from visibility. - Initialize function graph state is fork before calling copy_exec_state() For non-CLONE_VM forks, copy_exec_state() allocates a new task_exec_state. If that allocation fails, ftrace_graph_exit_task() will free the tasks ret_stack pointer. Since that pointer is still using the parent's ret_stack, it mistakenly frees the parent's pointer too. Call ftrace_graph_init() on the task first which will NULL out the new tasks's ret_stack and if the copy fails, it will not free anything. - Remove FGRAPH_MAX_INDEX The macro FGRAPH_MAX_INDEX was added but never used. Remove it. - Save ent_size in function graph printing of nested functions The function graph tracer needs to look at the next event to see if the next event is the return of the current function entry. If it is, it prints a single line: ktime_get(); Otherwise it prints it like a nested function: tick_nohz_irq_exit() { ktime_get(); kcpustat_irq_exit(); } In order to look at the next event, it must save the current event so that it has the information to print from it. It saves the event in the iterator descriptor called "ent". What it doesn't save is the ent_size of the event which is now used to know if the function graph arguments are to be printed. The peek doesn't save the size so the size used happens to be that of the size of the last event that was seen. Save the entry event size in the iterator descriptor so that the correct size is used. - Fix several errors with freeing data in the histogram code The histogram code had a lot of leaked or or incorrect accounting when failures happen. Correct them. - Fix histogram regression of .percent and .graph modifiers Up until 6.3 histogram values could have "percent" or "graph" modifiers that changed how they were printed. But a change that added restricting histograms values from being strings, stack traces and other modifiers inadvertently prevented them from using the percent and graph modifiers, which were legal use cases for values. Put back the percent and graph modifiers. - Fix various typos in the comments - Set the trace_clock before initializing a histogram with clock argument The histogram API allows the user to specific which trace clock to use via a "clock=" string. The histogram is set up first before the clock is checked. If the passed in clock is not valid, it exits without fully fixing up the histogram leaving it on the list and a use-after-free can trigger. Update the clock argument first and if it fails then exit gracefully before the histogram trigger is placed on any lists. - Restore :mod: trailer after parsing in ftrace_set_clr_event The function ftrace_set_clr_event() modifies the parse string and needs to put it back to what was passed in. It searches for ":mod:" via a strsep() but fails to put back the first ':' in the string. Add back the ':' in the passed in string. - Take trace_array reference when opening a tracer options file The options files are dynamically created and some tracers add their own options. When a tracer adds their own list of options, the trace_array holding them has an array to hold the list of options for each tracer. This array increases in size via a krealloc(), and the new entry gets a newly allocated array to hold the options of the new tracer being added. The element in each entry of the tracer's option array holds a pointer back to the trace_array, a pointer to the tracer it is associated to, a pointer to the flags of the option. The issue is that these arrays are freed when the trace_array is freed when its instance it represents is removed from the instances directory. There's a race that an open of one of these options files can happen when the instance is being removed. Add a new helper function to be called by the open function of the options file to iterate all existing trace_arrays under a lock and find the one that has the given option element in one of it's tracer arrays. If found, then update the associated trace_array's reference counter to keep it from being freed. If not found, have the open call return -ENODEV. - Disable interrupts when acquiring the lock in rb_wake_up_waiters() The function rb_wake_up_waiters() assumes it will be called in interrupt context and does not disable irqs when taking cpu_buffer->reader_lock, which can be called in hard interrupt context. The issue is in PREEMPT_RT, this function is called in thread context leaving this lock open to a deadlock. Take the lock with interrupts disabled. - Use rcu_assign_pointer() for tmp_ops filter hash The tmp_ops used in update_ftrace_direct_mod() assigns its filter_hash field directly, but that field is annotated as __rcu and sparse complains. Assign it with rcu_assign_pointer() - Fix use-after-free in enable_trigger_private_data_free() The trace_event_call is accessed through the event_trigger_data's trace_event_file pointer to put the trace_event_call on freeing. The issue is that the trace_event_file data may have been freed already causing a use-after-free. Add a field to the event_trigger_data that points directly to the trace_event_call so that it can decrement its reference directly without needing to go through the trace_event_file. - Fix accounting of buffer data remote headers trace_buffer_desc_size() and trace_remote_alloc_buffer() undercount the number of pages is needed for the asked for size as it doesn't take into account the meta data on each page. Add a helper function to do the calculation properly and use that in these functions. - Catch nr_page_va overflow in ring_buffer_desc sizing The number of pages per remote ring buffer is capped by ring_buffer_desc::nr_page_va (32 bits). A buffer_size large enough to overflow that field would silently allocate a descriptor smaller than what was asked for. - Do not resize the subbuf order if any per_cpu buffer is disabled The mmapping of ring buffers disables resizing the subbuffers, but it is done per-cpu whereas the subbuf size change is done for all the per_cpu buffers under the buffer->mutex. It could change the size of some while the mapping is happening on others. Have the resize of the subbuf order check all the per_cpu buffers under the lock to see if any of them is disabled before starting and causing an inconsistency between buffers that are being mapped. * tag 'trace-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: (25 commits) ring-buffer: Check resize_disabled before publishing the new subbuf order tracing/remotes: Catch nr_page_va overflow in ring_buffer_desc sizing tracing/remotes: Account for ring buffer page header in size calculation tracing: Don't dereference trace_event_file in deferred trigger free ftrace: Use rcu_assign_pointer() for tmp_ops filter hash ring-buffer: Acquire the lock with irqsave in rb_wake_up_waiters() tracing: Take trace_array reference when opening a tracer options file tracing: Fix ring_buffer_read_page_size() kernel-doc tracing: Restore :mod: trailer after parsing in ftrace_set_clr_event() tracing: Fix memory corruption from a "STACKTRACE" histogram key tracing: Fix memory corruption from the histogram stacktrace modifier tracing: Undo the registration when enabling the histogram trigger fails tracing: Take the reference before publishing the named histogram trigger tracing: Set the trace clock before registering the histogram trigger tracing: Fix typo "preceeded" in comment tracing: Fix typo "availabe" in comment tracing: Let histogram values keep the percent and graph modifiers tracing: Keep the entry count when the histogram stats allocation fails tracing: Free histogram the field rejected for a bad modifier tracing: Free histogram the var ref when its initialization fails ... commit e75c96157d45e498970158c8f7373d90102e33b9 Author: Paulo Alcantara Date: Sat Sep 12 14:20:08 2026 -0300 smb: client: fix smbd_connection leak on cifs_get_tcp_session() error When an RDMA connection is successfully established via smbd_get_connection() but cifs_get_tcp_session() later fails (e.g. kthread_create() returns an error), the error path frees tcp_ses without first destroying the smbd_connection. Fix this by calling smbd_destroy() in the out_err cleanup path before kfree(tcp_ses). smbd_destroy() safely handles the case where smbd_conn is NULL, so it can be called unconditionally. Closes: https://sashiko.dev/#/patchset/20260912165503.521597-1-pc%40manguebit.org Fixes: 2f8946464b11 ("CIFS: SMBD: Upper layer connects to SMBDirect session") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Tom Talpey Cc: Stefan Metzmacher Cc: Shyam Prasad N Cc: Ronnie Sahlberg Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org commit 5f270f091256da1338c3631083e15d7f83cc05e1 Author: Paulo Alcantara Date: Wed Sep 9 13:52:14 2026 -0300 smb: client: fix rlist race and missing initialization TCP_Server_Info.rlist is allocated via kzalloc which zeros both ->next and ->prev to NULL instead of pointing to itself, making list_empty() always return false and list_add() dereference a NULL ->prev pointer. Also, cifs_signal_cifsd_for_reconnect() can be called concurrently from multiple cifsd threads, allowing the same server's rlist node to be added twice into the local list, corrupting it. Closes: https://sashiko.dev/#/patchset/20260911204446.1719356-1-pc%40manguebit.org Fixes: df0e03a4fb94 ("smb: client: fix potential deadlock when reconnecting channels") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: David Howells Cc: Shyam Prasad N Cc: Ronnie Sahlberg Cc: Tom Talpey Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org commit c65eae6f61d1778ff7a82e4aae4080e26f486af1 Author: Paulo Alcantara Date: Fri Sep 11 22:38:04 2026 -0300 smb: client: cancel reconnect work in clean_demultiplex_info() clean_demultiplex_info() cancels server->echo delayed work but not server->reconnect, which can cause a use-after-free when the demultiplex thread exits while a reconnect work is still queued: cifs_demultiplex_thread() cifs_readv_from_socket() cifs_reconnect() __cifs_reconnect() cifs_queue_server_reconn() mod_delayed_work(cifsiod_wq, &server->reconnect, 0) clean_demultiplex_info() cancel_delayed_work_sync(&server->echo) // echo canceled // reconnect NOT canceled kfree_sensitive(server) // server freed ...later, on cifsiod_wq: smb2_reconnect_server() server->srv_count // UAF read of freed server Fix this by canceling server->reconnect delayed work in clean_demultiplex_info() before the server is freed, the same way cifs_put_tcp_session() already does. Reported-by: syzbot+5003556314abc915a71f@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/6aa4a12d.f81106d8.2ab401.0023.GAE@google.com Fixes: 53e0e11efe92 ("CIFS: Fix a possible memory corruption during reconnect") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: David Howells Cc: Shyam Prasad N Cc: Ronnie Sahlberg Cc: Tom Talpey Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org commit d681d7ef617ef83d6a4de36e5cb4418ef602e122 Merge: 180534c09b2dd8 856c562c94964a Author: Linus Torvalds Date: Sun Sep 13 10:18:23 2026 -0700 Merge misc regression fixes that seem to have fallen through the cracks Thorsten continues to track regressions, and reporting on known issues with fixes that don't seem to make any progress. I'm going to do an rc3 release later today - let's not keep these known issues pending for yet another rc for no obvious reason. Reported-by: Thorsten Leemhuis Link: https://lore.kernel.org/all/46403cf8-9a81-4596-87eb-dde58ae4c5db@leemhuis.info/ * regressions: media: ipu-bridge: do not use the CVS device lookup for IVSC wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe wifi: mt76: mt7921: skip unknown CLC firmware records commit 856c562c94964a74f63c6d5f38a1509a59a2357d Author: Sergey Zagursky Date: Wed Sep 2 22:15:24 2026 +0100 media: ipu-bridge: do not use the CVS device lookup for IVSC Since commit c6b1b34b5090 ("media: pci: intel: Add CVS support for IPU bridge driver") the internal camera no longer works on laptops where the sensor sits behind an IVSC, for example a Dell XPS 16 9640 (IPU6, INTC10CF, ov02c10): intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00 intel-ipu6 0000:00:05.0: Connected 1 cameras ivsc_csi intel_vsc-92335fcf-3203-4472-af93-7b4453ac29da: mei-csi probed without device fwnode! No sensor subdevice is registered, the media graph has no sensor entity and userspace finds no camera at all. ipu_bridge_get_ivsc_csi_dev() first looks for the platform device named "intel_vsc" and returns its mei-csi child. That device is created by mei_vsc, which on this machine only appears once the LJCA USB bridge and its SPI controller have probed, about a second after the IPU6 probe that runs the bridge: 07:59:29.297 platform INTC10CF:00 created (ACPI scan) 07:59:41 intel-ipu6 probe -> ipu_bridge_init() 07:59:42.391 platform intel_vsc created (mei_vsc) The commit above added two fallbacks for CVS which match on the ACPI companion alone. They are reached for every entry of ivsc_acpi_ids[], IVSC IDs included. The IVSC ACPI device has two physical nodes: INTC10CF:00/physical_node -> platform/INTC10CF:00 (no driver bound) INTC10CF:00/physical_node1 -> platform/intel_vsc (mei_vsc) so bus_find_device_by_acpi_dev(&platform_bus_type, adev) returns the bare platform device. ipu_bridge_instantiate_ivsc() then attaches the IVSC software node to that device instead of to the mei-csi client, the bridge reports success, and the probe is never retried. mei_csi later probes without a fwnode, the CSI-2 link is never described, and the sensor ACPI device, which has an honoured _DEP on the IVSC device, is never enumerated. Before those fallbacks existed the lookup returned NULL here, the bridge failed with -ENODEV and the probe was retried once the IVSC device had shown up. Skip those fallbacks for IVSC devices, keying on the IVSC IDs rather than the CVS ones: new CVS IDs keep being added, whereas the IVSC list is complete. CVS binds a driver to the ACPI device itself, so matching on the companion stays unambiguous there. Fixes: c6b1b34b5090 ("media: pci: intel: Add CVS support for IPU bridge driver") Link: https://lore.kernel.org/linux-media/20260901194526.6369-1-gvozdoder@gmail.com/ Cc: stable@vger.kernel.org Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Sergey Zagursky Signed-off-by: Linus Torvalds commit 7825de3f75d184612d77655669a04ea0da252c17 Author: Devin Wittmayer Date: Tue Aug 25 11:17:12 2026 -0700 wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe Some laptops carry a MediaTek power table in their firmware, and the driver reads it to set a transmit limit for each frequency range. It only fills in the ranges themselves when it registers the device. The startup step that does this existed already, but it never programmed anything. Two recent commits made it run a regulatory update instead, which sets the limits on the way through, long before registration. As a result, on a machine that has the table the driver reads through an empty pointer and the interface never appears: BUG: kernel NULL pointer dereference, address: 0000000000000004 RIP: 0010:mt792x_init_acpi_sar_power Call Trace: mt7921_set_tx_sar_pwr mt7921_mcu_regd_update mt7921_regd_update mt7921_run_firmware mt7921e_mcu_init mt7921_init_work Skip it when the ranges are missing. They are applied again once the device is up, which is where they came from before. Reported-by: Klara Modin Closes: https://lore.kernel.org/linux-wireless/aoyxqHYvSuaBeubf@soda.int.kasm.eu/ Fixes: 9b80bd9cab40 ("wifi: mt76: mt7921: add regulatory wiphy self manager support") Fixes: e9f3f1cc133f ("wifi: mt76: mt7925: add regulatory wiphy self manager support") Signed-off-by: Devin Wittmayer Tested-by: David Gow Tested-by: Klara Modin Signed-off-by: Linus Torvalds commit 1a296bfd3e775e515233f746218824fc7dd5ff16 Author: Laxman Acharya Padhya Date: Sun Aug 16 23:33:40 2026 +0545 wifi: mt76: mt7921: skip unknown CLC firmware records Treat an out-of-range CLC index as newer firmware rather than a malformed image. linux-firmware 20260810 ships MT7922 records with idx 3, and rejecting them made mt7921e fail to probe. Keep the record-length checks, and report those as errors so a truncated table is visible instead of a silent retry loop. Fixes: 9417c5818a01 ("wifi: mt76: mt7921: validate CLC firmware records") Reported-by: Mikhail Gavrilov Signed-off-by: Laxman Acharya Padhya Reviewed-by: Junjie Cao Tested-by: Mikhail Gavrilov Signed-off-by: Linus Torvalds commit d860c67c051685abb0460b593b193f0f45f4fa92 Author: David Carlier Date: Sat Sep 12 11:39:38 2026 +0100 ring-buffer: Check resize_disabled before publishing the new subbuf order ring_buffer_subbuf_order_set() stores the new order and only then walks the CPUs, returning -EBUSY if any of them has resizing disabled. A user mapped buffer has resizing disabled, and __rb_map_vma() reads buffer->subbuf_order without buffer->mutex, so an mmap of an already mapped CPU racing the failing order change sizes the mapping with the new order and inserts pages past the sub-buffer into the VMA. Check the CPUs before storing the new order. Cc: stable@vger.kernel.org Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions") Link: https://patch.msgid.link/20260912103938.1127021-1-devnexen@gmail.com Signed-off-by: David Carlier Signed-off-by: Steven Rostedt commit d059d8bf2c9b5d563d15e7552d73e17d7535013a Author: Vincent Donnefort Date: Fri Sep 11 20:39:36 2026 +0100 tracing/remotes: Catch nr_page_va overflow in ring_buffer_desc sizing The number of pages per remote ring buffer is capped by ring_buffer_desc::nr_page_va (32 bits). A buffer_size large enough to overflow that field would silently allocate a descriptor smaller than what was asked for. Return SIZE_MAX from trace_buffer_desc_size() on nr_page_va overflow. Link: https://patch.msgid.link/20260911193937.602202-3-vdonnefort@google.com Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt commit 442ffa742daa65a0e8fe003abe9fbe472366e4de Author: Vincent Donnefort Date: Fri Sep 11 20:39:35 2026 +0100 tracing/remotes: Account for ring buffer page header in size calculation trace_buffer_desc_size() and trace_remote_alloc_buffer() undercount the required pages because every ring buffer page contains a header (BUF_PAGE_HDR_SIZE). Account for that header to ensure allocated remote ring buffers aren't smaller than requested by the user. The newly introduced helper __calc_nr_pages_ring_buffer_desc() can return a value that overflows the descriptor nr_pages field (32 bits). Link: https://patch.msgid.link/20260911193937.602202-2-vdonnefort@google.com Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt commit 1e713f9bb2ac583521f06b0eb4e22440b1e3d078 Author: Nguyen Ngoc Thang Date: Sun Sep 13 20:44:46 2026 +0700 ALSA: pcm: set timer->private_data before registering the PCM timer snd_pcm_timer_init() calls snd_device_register() to link the new struct snd_timer into the global timer list while it still carries hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop), and only afterwards sets timer->private_data = substream. Once the timer is on the list under register_mutex, a concurrent reader can already reach it through the same mutex and invoke these callbacks. /proc/asound/timers does this via c_resolution(), and snd_timer_open()+snd_timer_start() reach start()/stop() the same way. All three dereference timer->private_data, which for this brief window is NULL, giving a NULL-pointer dereference: substream = timer->private_data; return substream->runtime ? ... // substream is NULL Move the private_data/private_free assignment before snd_device_register() so the timer is never visible on the list without its private_data set. On the snd_device_register() failure path, private_free() (snd_pcm_timer_free()) can now run, but it only does substream->timer = NULL, which is already NULL at that point since substream->timer is set to the new timer just once, after a successful registration -- so the failure path stays safe. Reported-by: syzbot+19da64013c46df87f971@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=19da64013c46df87f971 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Nguyen Ngoc Thang Link: https://patch.msgid.link/20260913134446.114724-1-ngocthang2710.1999@gmail.com Signed-off-by: Takashi Iwai commit 180534c09b2dd877c3ec83c900253765923c2e42 Merge: 6a0b3fb48d4857 f4c3e38111fd84 Author: Linus Torvalds Date: Sun Sep 13 09:28:28 2026 -0700 Merge tag 'rust-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Work around a 'bindgen' 0.73.2 bug that emits an 'allow' attribute for 'unnecessary_transmutes', which is unknown in older compilers - Clean 'clippy::as_underscore' lints in generated code by the new 'bindgen' 0.73.0+ releases - Clean new 'clippy::needless_range_loop' lint for the upcoming Rust 1.100.0 (expected 2026-11-12) 'kernel' crate: - 'num' module: fix soundness issue in 'Bounded' by sealing the 'Integer' trait 'pin-init' crate: - Fix unreachable warning for the upcoming Rust 1.100.0 (expected 2026-11-12) due to 'Infallible' becoming an alias of '!' Samples: - Add missing newlines in 'pr_*!'s macro calls" * tag 'rust-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: rust: allow `unknown_lints` in generated bindings for Rust < 1.88 rust: allow `clippy::as_underscore` in the generated bindings rust: num: seal Integer drm/panic: clean new `clippy::needless_range_loop` lint for Rust 1.100.0 rust: samples: add missing newlines in rust_print_main rust: pin-init: use irrefutable pattern for `stack_pin_init` commit 6a0b3fb48d485754661dd648a0cf9533cfcfa3e5 Merge: c874ace034a9cb 7812d6dab06980 Author: Linus Torvalds Date: Sun Sep 13 09:16:36 2026 -0700 Merge tag 'bootconfig-fixes-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull bootconfig fixes from Masami Hiramatsu: "Fix integer overflow and truncation in size checks. - Fix size check bypasses caused by integer overflow and truncation when parsing initrd or standalone bootconfig files, preventing buffer overflow and out-of-bounds writes in the userspace tool. - Fix pointer arithmetic wrap-around in get_boot_config_from_initrd() when handling crafted huge size values, preventing fatal kernel page faults during early boot" * tag 'bootconfig-fixes-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: bootconfig: Fix integer overflow in initrd size check tools/bootconfig: Fix integer overflow and truncation in size checks commit c874ace034a9cb647fe5e2a28fdb262b49c846e4 Merge: b2a8a7669e9bef c5dcb3aadc18d7 Author: Linus Torvalds Date: Sun Sep 13 09:10:38 2026 -0700 Merge tag 'timers-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fixes from Ingo Molnar: - Fix clockevents replacement race when a broadcast device is replaced which may trigger a BUG() crash (朱恺乾 - Zhu Kaiqian) - Fix potential timerqueue ordering bug when rearming a queued timer with nonzero slack (Andrea Parri) * tag 'timers-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: hrtimer: Use hard expiry when updating timers on the same base tick/broadcast: Plug clockevents replacement race commit b2a8a7669e9befcec50fec990e1e1ee96f040cdf Merge: 85855f85de484c f5741d2b34519d Author: Linus Torvalds Date: Sun Sep 13 09:03:22 2026 -0700 Merge tag 'sched-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Ingo Molnar: - Fix EEVDF se->max_slice value on enqueueing (Vincent Guittot) - Fix EEVDF augmented rb-trees re-balancing with multiple fields (Vincent Guittot) - In proxy scheduling, account cgroup CPU time to the execution context, not the scheduling context (Hui Su) - Likewise, call wq_worker_tick() for the execution context, not the scheduling context (Hui Su) * tag 'sched-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/core: Call wq_worker_tick() for the execution context sched: Account cgroup CPU time to the execution context sched/eevdf: Fix rb augmented with multi fields sched/eevdf: Fix augmented max_slice commit c7a1c6e8004ab12a9c9bfdcb603f60f9bf4a3cee Author: fangqiurong Date: Sat Sep 12 21:15:18 2026 +0800 sched_ext: Close the pre-enable ops error claim window scx_alloc_and_add_sched() publishes ops->priv before scx_root_enable_workfn() switches the state to SCX_ENABLING. An error claimed via scx_bpf_error_bstr() from an associated BPF program in that window is consumed by scx_disable_workfn(), which takes the pre-enable shortcut in scx_root_disable(). The shortcut returns without any teardown and restores SCX_DISABLED with an unconditional scx_set_enable_state() xchg racing the enable workfn's own transition. The enable then completes with the claim consumed: the scheduler stays up but can never be disabled again, and bpf_scx_unreg() frees it while still in use, resulting in a use-after-free. Both WARN_ON_ONCE()s fire back to back: WARNING: kernel/sched/ext/ext.c:7522 at scx_root_enable_workfn+0xeec/0x1be0, CPU#3: scx_enable_help/276 WARNING: kernel/sched/ext/ext.c:6398 at scx_root_disable+0xb50/0xdb8, CPU#0: sched_ext_helpe/664 scx_root_enable_workfn() switches to SCX_ENABLING before the scheduler allocation, so ops->priv is never visible while SCX_DISABLED. The allocation failure path restores SCX_DISABLED. Fixes: 105dcd005be2 ("sched_ext: Introduce scx_prog_sched()") Cc: stable@vger.kernel.org Signed-off-by: fangqiurong Signed-off-by: Tejun Heo commit 85855f85de484c464adb39076ebcb090c7eeb3b5 Merge: feb66eea6b095e a56c03a397e2cd Author: Linus Torvalds Date: Sun Sep 13 08:44:54 2026 -0700 Merge tag 'perf-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf events fixes from Ingo Molnar - Fix sched_cb_list corruption on PMU callbacks that invoke list_del() during perf_event_overflow() calls (Thomas Richter) - Fix PEBS pt_regs->flags snapshot data that regressed with the introduction of adaptive PEBS v4 support (Dapeng Mi) - Fix possible drain_pebs() re-entry bug when intel_pmu_drain_pebs_buffer() is called from process context (Dapeng Mi) * tag 'perf-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel: Prevent drain_pebs() reentry perf/x86/intel: Correct pt_regs->flags update for PEBS path perf/core: Allow list_del during perf_event_overflow() commit feb66eea6b095e488755052e96f1e0d8b51e42c4 Merge: f10ae89f3d7994 ac323c94670924 Author: Linus Torvalds Date: Sun Sep 13 08:37:11 2026 -0700 Merge tag 'objtool-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull objtool fixes from Ingo Molnar: - Fix potential klp-build allocation leak in cleanup functionality handling kzalloc() failure (Yafang Shao) - Fix KLP checksum false positives triggering with GCC, caused by quirks in string literal symbol generation (Josh Poimboeuf) * tag 'objtool-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool/klp: Fix checksums for constant pool references klp-build: Fix wrong index in funcs cleanup error path commit f10ae89f3d7994e680a1190c27f383f76f5ea73e Merge: 086fd27ee9c41f 1017911fcc0358 Author: Linus Torvalds Date: Sun Sep 13 08:28:08 2026 -0700 Merge tag 'irq-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Ingo Molnar: - Fix ARM gic-v5 irqchip driver regression, where its enable/disable functions may corrupt unrelated ICC_CR0_EL1 hardware state (Sascha Bischoff) * tag 'irq-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/gic-v5: Preserve ICC_CR0_EL1 state commit 086fd27ee9c41f1a3ae040ffe5c9c00b45296f82 Merge: ff4b61e3b7b338 954f7a48fa2ae7 Author: Linus Torvalds Date: Sun Sep 13 08:23:41 2026 -0700 Merge tag 'core-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull entry code fix from Ingo Molnar: - Fix generic entry code cross-build failure on !CONFIG_AUDITSYSCALL kernels using older RISCV64 and S390 cross-compilers (Thomas Gleixner) * tag 'core-urgent-2026-09-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: entry: Guard syscall_enter_audit() invocation with CONFIG_AUDITSYSCALL commit 486a70ef848264dcf9a57f0bb0452848db9537de Author: AngeloGioacchino Del Regno Date: Fri Sep 11 09:40:15 2026 +0200 phy: mediatek: phy-mtk-hdmi-mt8195: Fix TMDS clk bit ratio setting The comment in the mtk_phy_tmds_clk_ratio() function clearly and correctly explains that the TMDS ratio has to be 1/10 for data rates under 3.4Gbps, and 1/40 over that. Unfortunately though, the TXC_DIV register setting was wrong, as in value 3 means to divide by 8 and, in order to achieve the in spec 1/40 (tmds) data rate, this has to divide by 4 instead! Add definitions for the TXC_DIV register values clearly explaining the meanings (DIV2, DIV4, DIV8), and program the correct, DIV 4, value to the register in mtk_phy_tmds_clk_ratio(). This fixes out of spec clocking and, with this change, SoCs using the MT8195 class HDMI PHYs can now successfully be configured to output 3840x2160@60Hz over HDMI. Fixes: 45810d486bb4 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195") Reviewed-by: Manivannan Sadhasivam Signed-off-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20260911074015.9994-3-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul commit de7f29a1fe1dc2864d8a47f8c39d508442cae167 Author: AngeloGioacchino Del Regno Date: Fri Sep 11 09:40:14 2026 +0200 phy: mediatek: phy-mtk-hdmi-mt8195: Fix PLL calc divisor overflow When trying to calculate a PLL rate for target display resolutions above 2560x1440, 24bpp, 30Hz, the pixel clock value will be more than 32-bits long but the division to finally calculate the digital clock divider is being done with div_u64(), which expects a 32bit unsigned divisor. Fix the overflow by using div64_u64() instead. Fixes: 9d9ff3d2a4a5 ("phy: mediatek: hdmi: mt8195: fix wrong pll calculus") Reviewed-by: Manivannan Sadhasivam Signed-off-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20260911074015.9994-2-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul commit 48e97c59a49c9e90270f5e3d221db253b76de5da Author: Claudiu Beznea Date: Thu Jul 16 21:32:46 2026 +0300 phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic context The OTG PHY initialization sequence needs to wait for 20 ms at a specific step, as described in commit 72c0339c115b ("phy: renesas: rcar-gen3-usb2: follow the hardware manual procedure"). Commit 55a387ebb921 ("phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver data") tried to address various problems in the rcar-gen3-usb2 driver and converted the mutex protecting HW register accesses to a spin lock, leaving, however, a long delay in the critical section protected by the spin lock. This may become a problem, especially on RT kernels. To address this, release the spin lock before sleeping for 20 ms as required by the HW manual and reacquire it afterwards. To avoid other threads entering the critical section and configuring the HW while the software is waiting for the OTG initialization to complete, introduce the otg_initializing variable alongside the otg_init_done wait queue. Any other thread trying to configure the HW while the OTG PHY initialization is in progress waits for the wait queue instead of immediately returning errors to PHY users. The IRQs were also disabled while waiting for the OTG PHY initialization to complete, as the interrupt handler may also apply HW settings. The OTG can only be initialized once. It is initialized by the first PHY that calls struct phy_ops::rcar_gen3_phy_usb2_init(). To avoid failures when multiple PHYs call struct phy_ops::rcar_gen3_phy_usb2_init() simultaneously, and the PHY responsible for initializing the OTG either fails or deinit quiqly and another PHY takes over the PHY init role), the code waiting for the channel->otg_init_done wait queue retries up to NUM_OF_PHYS times. Fixes: 55a387ebb921 ("phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver data") Cc: stable@vger.kernel.org Reported-by: Pavel Machek Closes: https://lore.kernel.org/all/afhkX2Ys2BG1gnqy@duo.ucw.cz Reported-by: Nobuhiro Iwamatsu Closes: https://lore.kernel.org/all/afhkX2Ys2BG1gnqy@duo.ucw.cz Signed-off-by: Claudiu Beznea Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/all/afhkX2Ys2BG1gnqy@duo.ucw.cz Link: https://patch.msgid.link/20260716183246.3183877-1-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Vinod Koul commit 6c05d00af307560e6a9f1631d6270d3df5aa2272 Author: Yuho Choi Date: Thu Sep 10 23:11:21 2026 -0400 ALSA: virtio: reset device before deleting virtqueues virtsnd_remove() and virtsnd_freeze() delete the virtqueues before resetting the device. del_vqs() frees the vring backing, but does not provide a generic device quiesce operation. In particular, modern virtio-pci keeps enabled queues active until the device is reset. Reset the device before deleting the virtqueues so it can no longer access the vring memory when that memory is released. This also covers probe failures after DRIVER_OK, which unwind through virtsnd_remove(). Fixes: de3a9980d8c3 ("ALSA: virtio: add virtio sound driver") Fixes: 575483e90a32 ("ALSA: virtio: introduce device suspend/resume support") Cc: stable@vger.kernel.org Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260911031121.1542502-1-oss.patchbox@gmail.com Signed-off-by: Takashi Iwai commit fd95e68df6fe66344161a1329cbe5e5805e7b704 Author: Takashi Iwai Date: Sat Sep 12 18:21:42 2026 +0200 ALSA: core: Fix potential UAF after asynchronous card release Usually a sound driver releases the resources assigned to the card via snd_card_free(), and it synchronizes with the whole release procedure. However, when the card is released asynchronously via snd_card_free_when_closed() like USB-audio driver, the situation is slightly different; although the snd_card_disconnect() call at the disconnection guarantees that any newer accesses will be gated, the in-flight tasks might be still accessing to the underlying card->dev device even after the disconnection, which would cause a use-after-free in the end, as reported by fuzzers. For addressing the bug above, this patch takes the refcount of card->dev at initialization of the card object, and releases at its destructor. This assures the availability of the card->dev in its whole lifecycle. Reported-by: Farhad Alemi Closes: https://lore.kernel.org/CA+0ovChexj4TrZL_2iG_P0WBEbZc5+73GfB3DkciQi=R8pZOnA@mail.gmail.com Closes: https://lore.kernel.org/CA+0ovCgQUQNN=Z1tJTouiCsDaXR5M-3-SQEGk-cpPXQkM5Xh+w@mail.gmail.com Cc: Link: https://patch.msgid.link/20260912162150.455144-1-tiwai@suse.de Signed-off-by: Takashi Iwai commit 76a986c980bb502c7688d605ac7a67fd257a9a1b Author: Xiang Mei Date: Sat Sep 12 13:05:30 2026 -0700 ALSA: usb-audio: Clamp implicit feedback packet count to URB capacity data_ep_set_params() allocates each data URB for exactly u->packets isochronous frames, so urb->iso_frame_desc[] has u->packets slots and ctx->packets is the driver's only record of that limit. For an implicit feedback sink, snd_usb_queue_pending_output_urbs() overwrites it with the sync source's packet count, which is calculated independently from the capture endpoint's parameters. When that count is larger, prepare_playback_urb() and prepare_silent_urb() can write iso_frame_desc[] past the allocation; their existing bounds limit payload bytes, not the descriptor index. The reproducer uses a high-speed UAC2 device declaring bInterval 1 for implicit feedback capture (8 packets) and bInterval 4 for playback (1 packet). On the first capture completion after the stream starts, it accesses seven descriptors spanning 112 bytes beyond the one-packet URB: BUG: KASAN: slab-out-of-bounds in prepare_playback_urb (sound/usb/pcm.c:1560) Write of size 4 at addr ffff88801e696ad0 by task vhci_rx/178 prepare_playback_urb (sound/usb/pcm.c:1560) prepare_outbound_urb (sound/usb/endpoint.c:340) snd_usb_queue_pending_output_urbs (sound/usb/endpoint.c:501) snd_complete_urb (sound/usb/endpoint.c:1834) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741) vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107) kthread (kernel/kthread.c:436) The buggy address belongs to the object at ffff88801e696a00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of allocated 208-byte region [ffff88801e696a00, ffff88801e696ad0) Record the allocated packet count per endpoint and clamp both the adopted count and the packet-size copy to it. Fold the Format Type II delimiter into urb_packs before the allocation loop so the recorded limit matches every URB. Fixes: cf044e441902 ("ALSA: usb-audio: Update the number of packets properly at receiving") Reported-by: co+8eacd4fa193b1b28@bugs.sh Closes: https://lore.kernel.org/all/22xPn8drvIUtYgVeQnBiNqXuevOTpBAjepLz%40bugs.sh/ Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260912200530.1955491-1-xmei5@asu.edu Signed-off-by: Takashi Iwai commit 229e8188307b9724cc676a49e9600c4acd24b571 Author: Zhu Tianhao Date: Tue Sep 8 05:41:00 2026 +0900 ntfs: fix $MFTMirr write offset when it spans multiple folios When commit 115380f9a2f9 ("ntfs: update mft operations") refactored the MFT code to use folios, it assumed $MFTMirr is allocated contiguously, which is indeed what mkfs arranges. However, the folio rewrite kept a leftover from the old buffer-head/runlist based implementation: vol->cluster_size_mask is still applied to the mirror write offset. In fact it is no longer needed -- and in some configurations it is actively wrong. The bug triggers whenever the four mirror records do not fit in a single folio, i.e. when mft_record_size exceeds PAGE_SIZE / 4 (for example mft_record_size > 1KiB on 4KiB pages). For example, on the built-in 4Kn SSD (Apple SSD AP0256J) of a MacBookPro14,1 with 4096-byte MFT records, mirror record 3 is still written to the location of record 0. $MFTMirr therefore gets out of sync with $MFT and the following warning is printed on remount: ntfs: (device nvme0n1p3): check_mft_mirror(): $MFT and $MFTMirr record 0 do not match. Run chkdsk. Fix it by always adding the folio offset (folio->index << PAGE_SHIFT) to the base LCN address instead of applying the cluster_size_mask truncation. This is the standard file-offset calculation and is correct for every combination of cluster size, page size and MFT record size, provided $MFTMirr data is contiguous from mftmirr_lcn (which mkfs always arranges). Tested on the volume above: before the change mirror records 1-3 are all written to record 0's sector; after the change the write-back probe reports: ntfs: NTFSDBG pre mft_no=0x3 folio_idx=0x3 ofs=0x0 mftmirr_lcn=0x2540c5 clu_bits=12 rec_bits=12 PAGE_SHIFT=12 sect=0x12a0640 ntfs: NTFSDBG pre mft_no=0x0 folio_idx=0x0 ofs=0x0 mftmirr_lcn=0x2540c5 clu_bits=12 rec_bits=12 PAGE_SHIFT=12 sect=0x12a0628 which matches the expected sectors computed as: (NTFS_CLU_TO_B(mftmirr_lcn) + (folio->index << PAGE_SHIFT)) >> SECTOR_SHIFT record 0: (0x2540c5 << 12) + 0x0000 = 0x2540c5000 >> 9 = 0x12a0628 record 3: (0x2540c5 << 12) + 0x3000 = 0x2540c8000 >> 9 = 0x12a0640 A 13 MB file write succeeds on this volume and the file is byte-for-byte identical after a umount/mount cycle. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Assisted-by: UOS-AI Assisted-by: CodeBuddy:Hy4 preview Signed-off-by: Zhu Tianhao Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon commit 0c32a42fd96a0e7c06c8a648a6dd8f1ec0bf643b Author: Namjae Jeon Date: Mon Sep 7 13:38:17 2026 +0900 ntfs: unhash failed inode reads Remove a newly allocated inode from the inode hash before discarding it. NTFS may set i_nlink before a later initialization step fails, in which case iput alone can retain the incomplete inode in the cache. Fixes: bf6be898fbc5 ("ntfs: discard inodes that fail initialization") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit fc440366c47000b768d013e347f60e81d60328ca Author: Namjae Jeon Date: Mon Sep 7 13:34:44 2026 +0900 ntfs: discard inodes that fail initialization Discard a newly allocated normal, attribute, or index inode when initialization fails. Keeping an incompletely initialized inode in the inode cache can expose stale sequence data to later directory lookups. Fixes: d7aa04984f12 ("ntfs: return errors from inode initialization") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 8c5dc7587fdd45f957af81a9adc1e16863f300fc Author: Namjae Jeon Date: Mon Sep 7 13:34:25 2026 +0900 ntfs: ignore interrupted inode reads as corruption Do not mark the volume in error or report an inode as corrupt when reading it was interrupted by a signal. -EINTR and -ERESTARTSYS indicate a transient read failure rather than on-disk NTFS corruption. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 1923eeffa63edeff427d76fc302bc5eb835771ce Author: Namjae Jeon Date: Mon Sep 7 13:34:01 2026 +0900 ntfs: propagate folio errors Return the error from __filemap_get_folio() instead of replacing it with -ENOMEM. Fixes: af0db57d4293 ("ntfs: update inode operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 91709ba5d6d709b2b663287b7e871e2c6b480502 Author: Namjae Jeon Date: Sun Sep 6 21:37:28 2026 +0900 ntfs: protect runlist updates with the runlist lock ntfs_non_resident_attr_shrink() calls runlist helpers that require the runlist write lock, but did not hold it while freeing clusters and truncating the runlist. Serialize those operations and the resident conversion with the runlist lock. ntfs_attr_map_cluster() can merge a newly allocated run before updating mapping pairs. If the update fails, free the clusters and restore both the in-memory runlist and on-disk mapping pairs from a saved runlist. Mark the volume in error if either rollback step fails. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 631946431ddc66a472c5cc629cd654e62dfa1f88 Author: Namjae Jeon Date: Fri Sep 4 14:46:38 2026 +0900 ntfs: account for MFT records added during allocation When no free MFT record is available in the initialized $MFT/$BITMAP, ntfs_mft_record_alloc() extends $MFT/$DATA and formats the requested record together with a dynamically sized tail reserve. Those records become visible through the $MFT file size before charging the requested record to the free-record counter. Account for all newly visible records before releasing the MFT allocation lock, then subtract the one record being allocated. Keep MFT counter updates independent of the asynchronous free-cluster scan and update the counter when a record is successfully cleared in the MFT bitmap. Store the clamped result of the MFT bitmap scan and keep statfs from exposing an invalid cached count if an accounting error occurs. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit b1d732e62a5b3942546e4edaab8976258e779287 Author: Namjae Jeon Date: Sun Sep 6 11:12:47 2026 +0900 ntfs: repack $MFT/$ATTRIBUTE LIST Repack the non-resident $MFT/$ATTRIBUTE_LIST into a contiguous run when its mapping pairs no longer fit in the base MFT record. Propagate allocation and writeback errors, and check synchronous replacement writes. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 6d8c197c9992659a65525a07de4368c8401fdda7 Author: Namjae Jeon Date: Tue Sep 8 15:52:46 2026 +0900 ntfs: use dynamic MFT tail reservation The ntfs MFT allocator historically treated records below 64 as a permanent extension area and stopped searching for $MFT extent records after record 400. Windows and ntfs3 do not maintain that on-disk layout, so an NTFS volume can have free MFT records while ntfs returns -ENOSPC when $MFT:$DATA needs another mapping-pairs extent. Use record 24 as the first normal record and maintain an in-memory tail reserve of up to four initialized records. Normal allocations skip the reserve, while $MFT metadata extent allocations consume it. When a new tail is initialized, allocate at least two records and reserve the following records to avoid recursive allocation during MFT extension. Existing free runs can seed the reserve on volumes mounted without one. For $MFT/$DATA, constrain an extent record to a record whose byte offset is below the new extent lowest VCN byte offset. This preserves bootstrap reachability without an arbitrary record 400 limit. If no safe record is available, validate and use reserved records 15, 12, 13, and 14 as bootstrap candidates while keeping their MFT bitmap entries in use. This allows existing Windows volumes to extend $MFT using their actual free records and prevents normal file allocation from consuming the metadata reserve. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit ff4b61e3b7b338a92cbea555013937e69c25fa52 Merge: 2f0c1cf72f4682 9868f5c077dfe0 Author: Linus Torvalds Date: Sat Sep 12 17:32:14 2026 -0700 Merge tag 'edac_urgent_for_v7.3_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras Pull EDAC fix from Borislav Petkov: - A single fix to altera_edac to use the proper objects when performing managed device operations instead of using temporary shallow struct copies which can cause dangling list pointers and havoc eventually * tag 'edac_urgent_for_v7.3_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/altera: Use parent device for devres in altr_portb_setup() commit 2f0c1cf72f4682178506f513bbf015e591b1aa4a Merge: 3ce99a68f7d5b8 dc2136341be983 Author: Linus Torvalds Date: Sat Sep 12 16:22:25 2026 -0700 Merge tag 's390-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Vasily Gorbik: - Fix NULL pointer dereferences in s390dbf when setting debug levels or resizing debug areas while logging events. Remove duplicate messages about kernel parameter overrides - Fix PAI perf crashes when per task events move to newly onlined CPUs. Add CPU hotplug callbacks to allocate and free the per-CPU data - Fix mutex use in atomic context in AES and PAES CTR code by using semaphore trylocks instead. Remove conditional locking and enable Clang CONTEXT_ANALYSIS for the crypto code - Fix scatterlist walk error handling in AES and PAES and avoid freeing PAES walk resources twice - Fix missing scrubbing of temporary AES and PAES buffers, including AES GCM error paths - Set missing CRYPTO_ALG_ASYNC and CRYPTO_ALG_NO_FALLBACK flags for PAES - Fix -EBUSY handling in PAES and PHMAC to avoid cleaning up requests already queued to the crypto engine - Fix PAES and PHMAC requests being completed twice on errors - Fix PAES and PHMAC hangs when key conversion keeps returning -EBUSY by returning -EIO after the last retry * tag 's390-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/crypto: Enable CONTEXT_ANALYSIS s390/crypto: Map EBUSY to EIO when key conversion fails repeatedly s390/crypto: Fix wrong return code to engine in asynch callbacks s390/crypto: Fix handling of EBUSY in PHMAC when req is pushed to crypto engine s390/crypto: Fix handling of EBUSY in PAES when req is pushed to crypto engine s390/crypto: Fix missing cra_flags in paes_s390 s390/crypto: Fix use of mutex in atomic context in PAES s390/crypto: Fix missing scrub of temp buffers with PAES algorithm s390/crypto: Fix return code handling at skcipher_walk_done in PAES algorithms s390/crypto: Fix use of mutex in atomic context s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm s390/crypto: Fix skcipher_walk return code handling in aes_s390 s390/debug: Fix race between debug area resize and event logging s390/debug: Do not repeat parameter override notice on debug_set_level() s390/debug: Fix NULL pointer dereference in debug_set_level() s390/pai: Support CPU hotplug for PMU PAI s390/pai: Move locking to event init and delete s390/pai: Use PAI PMU index as parameter replacing event commit 7d70a0b02d262971201fdd1e221586bdd95c2910 Author: Zhixing Chen Date: Thu Sep 3 18:43:58 2026 +0800 bpf: Use kvfree() in xdp_test_run_teardown() xdp_test_run_setup() allocates xdp->frames and xdp->skbs with kvmalloc_array(). The setup error path already releases both arrays with kvfree(), while the normal teardown path still uses kfree(). Use kvfree() in xdp_test_run_teardown() as well, so the release helper matches the allocator on both paths. Signed-off-by: Zhixing Chen Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260903104358.29228-1-running910@gmail.com Signed-off-by: Alexei Starovoitov commit 3ce99a68f7d5b878a7746d479591a18651a8238f Merge: cba2348ab11439 59351365ac271b Author: Linus Torvalds Date: Sat Sep 12 11:29:20 2026 -0700 Merge tag 'kbuild-fixes-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux Pull Kbuild fixes from Nicolas Schier: "Fix a build race and builds on stable branches. The other two are low-hanging fruits from Lorenzo's recent kbuild speed-up patch set that fix older symbol leakages. - don't delete in-flight filechk temporaries in asm-headers A rule for generating header files was changed from using make $(wildcard) fnglob to 'find' instead; as 'find' finds "hidden" files by default, temporary files from Kbuild's 'filechk', used for generating asm header files, may get deleted and break header file generating. - scripts/sorttable: Mark long_size as __maybe_unused Fix builds with clang-23 or newer on trees w/o commit b055f4c431e3 ("sorttable: Move ELF parsing into scripts/elf-parse.[ch]"); targetting for backport to stable kernels < 6.19. - scripts/mksysmap: drop the MODULE_INFO() symbols from kallsyms Update regexp to remove kallsyms entries from kernel binary, saves about 32 KiB of bzImage. - scripts/mksysmap: fix escape of '$' in the __pi_ pattern Prevent arm64 PIE namespace local symbols from appearing System.map and /proc/kallsyms" * tag 'kbuild-fixes-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: scripts/mksysmap: fix escape of '$' in the __pi_ pattern scripts/mksysmap: drop the MODULE_INFO() symbols from kallsyms scripts/sorttable: Mark long_size as __maybe_unused kbuild: don't delete in-flight filechk temporaries in asm-headers commit 75f8cf22463d82bb1fb0239a3d485fc8f4c8ef03 Author: Jiayuan Chen Date: Thu Sep 3 18:09:20 2026 +0800 bpf: Fix out-of-bounds read of rtt_min in sock_ops A sockops prog reading skops->rtt_min never checks the sk type: on the tcp_conn_request() path sock_ops->sk is a request_sock (non-full), and the ctx rewrite casts it to a tcp_sock (full) and reads rtt_min past the end of the request_sock, returning dirty adjacent memory. SEC("sockops") int prog(struct bpf_sock_ops *skops) { switch (skops->op) { case BPF_SOCK_OPS_RWND_INIT: leak = skops->rtt_min; /* reads the request_sock OOB */ ... } } For instance one such read returned rtt_min=0xffff8881, the high half of a leaked kernel pointer. Guarding that cast is exactly what SOCK_OPS_GET_FIELD() does -- it checks is_locked_tcp_sock and returns 0 when sock_ops->sk is not a locked full socket. Every other tcp_sock field in sock_ops goes through it; rtt_min is the only one open-coded, so it skips the check. Read rtt_min through SOCK_OPS_GET_FIELD() too. rtt_min is a bit special: it is a struct minmax and we only want the current min, so pass rtt_min.s[0].v. That is equivalent to the old hand-computed offset offsetof(struct tcp_sock, rtt_min) + sizeof_field(struct minmax_sample, t) (s[0] sits at rtt_min + 0 and .v at + sizeof(.t), i.e. what minmax_get() returns), so the loaded field is unchanged and only the full-sock guard is added. The two BUILD_BUG_ON()s that protected the hand-computed offset are no longer needed. Before patch: 0: r1 = *(u64 *)(r1 +0) ; r1 = skops->sk 1: r1 = *(u32 *)(r1 +2324) ; ((tcp_sock *)sk)->rtt_min.s[0].v After patch: 0: *(u64 *)(r1 +56) = r9 1: r9 = *(u8 *)(r1 +50) ; is_locked_tcp_sock 2: if r9 == 0 goto pc+4 ; not a locked full sock -> 0 3: r9 = *(u64 *)(r1 +56) 4: r1 = *(u64 *)(r1 +0) ; r1 = skops->sk 5: r1 = *(u32 *)(r1 +2324) ; rtt_min.s[0].v 6: goto pc+2 7: r9 = *(u64 *)(r1 +56) 8: r1 = 0 Fixes: 44f0e43037d3 ("bpf: Add support for reading sk_state and more") Reported-by: VEGA Signed-off-by: Jiayuan Chen Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260903100921.113374-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit 59351365ac271b5e0eb180f211c531476a36221f Author: Lorenzo Stoakes (ARM) Date: Tue Sep 8 21:55:02 2026 +0100 scripts/mksysmap: fix escape of '$' in the __pi_ pattern Commit b18b047002b7 ("kbuild: change scripts/mksysmap into sed script") converted scripts/mksysmap from a shell script to a sed script. However an error was made - escaping of '$' required \\ escaping in shell but only \ in a sed script. This was mostly corrected in commit 7a6c355b55c0 ("scripts/mksysmap: Fix escape chars '$'"), but this fix missed arm64 PIE namespace local symbols like __pi_$x and __pi_$d which appear in System.map and /proc/kallsyms: $ grep __pi_\\$ /proc/kallsyms | sort -u 0000000000000000 d __pi_$d 0000000000000000 t __pi_$x Fix the escaping properly. Fixes: b18b047002b7 ("kbuild: change scripts/mksysmap into sed script") Assisted-by: LLM Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Nathan Chancellor Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260908-build-speedup-v1-2-5dc1ac01672d@kernel.org Signed-off-by: Nicolas Schier commit 281b61d408d4c39544583e393c6707af0ef5ee50 Author: Lorenzo Stoakes (ARM) Date: Tue Sep 8 21:55:01 2026 +0100 scripts/mksysmap: drop the MODULE_INFO() symbols from kallsyms Commit 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") keeps .modinfo symbols out of System.map and kallsyms, which assumes unique IDs have a format like '__UNIQUE_ID_modinfo123'. However, commit afb026b6d35c ("compiler: Tweak __UNIQUE_ID() naming"), sent in the same cycle, changes this to '__UNIQUE_ID_modinfo_123'. As a result this regexp has never matched and every kernel since v6.18 has carried one kallsyms entries for every MODULE_INFO() declaration in the kernel whether the modules are compiled or not. That's 5,810 entries for an x86 defconfig build and 15,200 for arm64. On x86 defconfig that is 113 KiB of kallsyms tables and 32 KiB of bzImage, and every lookup walks past them. Fix the pattern. Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") Assisted-by: LLM Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Nicolas Schier Reviewed-by: Nathan Chancellor Link: https://patch.msgid.link/20260908-build-speedup-v1-1-5dc1ac01672d@kernel.org Signed-off-by: Nicolas Schier commit 4f73462856576797b8f3c55564a9be99f76dc67b Author: Nathan Chancellor Date: Mon Aug 31 18:46:31 2026 -0700 scripts/sorttable: Mark long_size as __maybe_unused When building in a kernel tree prior to commit b055f4c431e3 ("sorttable: Move ELF parsing into scripts/elf-parse.[ch]") with clang-23 or newer, which implements a new warning under -Wunused-but-set-variable for static global variable, there is a warning from sorttable because long_size is unused when MCOUNT_SORT_ENABLED is not set: scripts/sorttable.c:452:12: error: variable 'long_size' set but not used [-Werror,-Wunused-but-set-global] 452 | static int long_size; | ^ Mark long_size as __maybe_unused to avoid inserting more ugly #ifdef directives while insuring the warning does not reappear, as the aforementioned change does not alter the uses of long_size, so it appears to be coincidence that the warning disappears after this refactoring. Cc: stable@vger.kernel.org Signed-off-by: Nathan Chancellor Tested-by: Nicolas Schier Link: https://patch.msgid.link/20260831-sorttable-long_size-unused-but-set-global-v1-1-8a96b88697e5@kernel.org Signed-off-by: Nicolas Schier commit 06bb43d8c79762fa3452f292cd080e54bef5d431 Author: Vlad Poenaru Date: Wed Sep 2 09:13:47 2026 -0700 kbuild: don't delete in-flight filechk temporaries in asm-headers Commit 2d69b891e646 ("kbuild: Support generated asm-headers in subdirectories") switched the stale-wrapper sweep in scripts/Makefile.asm-headers from $(wildcard $(obj)/*.h) to a find(1) invocation, so that generated headers in subdirectories are considered. The two do not match the same set of files. Make's $(wildcard) uses glob semantics, where a leading '.' has to be matched explicitly, whereas find's -name uses fnmatch() without FNM_PERIOD, so '*.h' matches dotfiles as well. filechk writes its output to $(dir $@).tmp_$(notdir $@) before renaming it into place, so such a scratch file, if it happens to exist in $(obj) when the sub-make is parsed, is now picked up in old-headers. It appears in neither generic-y, generated-y nor syscall-y, is therefore classified as unwanted, and cmd_remove deletes it. On x86 this races with archprepare, which lists both asm-generic and arch/x86/include/generated/asm/cpufeaturemasks.h as prerequisites. Under -j they run concurrently against the same directory, and the build fails intermittently: mv: cannot stat 'arch/x86/include/generated/asm/.tmp_cpufeaturemasks.h': No such file or directory make[1]: *** [arch/x86/Makefile:269: arch/x86/include/generated/asm/cpufeaturemasks.h] Error 1 The same commit also converted the generic wrapper rule to filechk, so those wrappers now create .tmp_*.h in $(obj) too and can race among themselves. Restore the previous behaviour by excluding dotfiles from the sweep. Subdirectories, which is what the find(1) conversion was for, keep being descended into. While at it, quote the -name argument: it is currently expanded by the shell against the build directory before find sees it. Fixes: 2d69b891e646 ("kbuild: Support generated asm-headers in subdirectories") Signed-off-by: Vlad Poenaru Reviewed-by: Nathan Chancellor Reviewed-by: Thomas Weißschuh Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260902161347.4163577-1-vlad.wing@gmail.com Signed-off-by: Nicolas Schier commit 85136bf22404474a815fc0ed26ec0d1cbc1bc3f9 Author: Jose Fernandez (Anthropic) Date: Wed Sep 9 17:51:04 2026 +0000 bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch() __htab_map_lookup_and_delete_batch() has no rescheduling point. The batch count bounds how many entries are copied out, not how many buckets are visited, so one BPF_MAP_LOOKUP_BATCH call can walk the map end to end. The empty-bucket fast path is worse: it stays inside a single rcu_read_lock() / bpf_disable_instrumentation() section for any run of consecutive empty buckets. That holds up on small maps, but it falls apart at scale. On a 144-CPU arm64 host running a CONFIG_PREEMPT_NONE kernel, periodic BPF_MAP_LOOKUP_BATCH calls against an LRU hash map with 16,777,216 buckets held a CPU inside the batch op for 77+ seconds and triggered the soft lockup watchdog. Commit 75134f16e7dd ("bpf: Add schedule points in batch ops") fixed this same problem in the generic batch ops, but not in this htab-native path, which every htab-based hash map variant uses for its lookup[_and_delete] batch ops. Complete that fix here. Leave the critical section after 64 consecutive empty buckets, call cond_resched_tasks_rcu_qs(), and resume at the saved bucket cursor. No locks are held at that point, and resuming from the cursor is already the function's behavior for non-empty buckets. Add the same call to the per-bucket loop after copy_to_user(), where every lock has been dropped. cond_resched_rcu() is not enough here: sleeping with bpf_prog_active elevated makes tracing programs on that CPU silently skip their invocations. Plain cond_resched() is not enough either. It is a no-op under PREEMPT and PREEMPT_LAZY, the only models arm64 and x86 have offered since commit 7dadeaa6e851 ("sched: Further restrict the preemption modes"). It is also never a Tasks RCU quiescent state, in any model: the reschedule counts as a preemption. The walking task stays a holdout and stalls every synchronize_rcu_tasks() caller, ftrace and BPF trampoline teardown included, until the syscall returns [1]. cond_resched_tasks_rcu_qs() is the usual tool for that [2]. It reports the quiescent state at each yield and still reschedules as cond_resched() does on PREEMPT_NONE and PREEMPT_VOLUNTARY kernels. Fixes: 057996380a42 ("bpf: Add batch ops to all htab bpf map") Cc: "Paul E. McKenney" Cc: Rik van Riel Link: https://lore.kernel.org/bpf/20260715215314.44423f47@fangorn/ [1] Link: https://lore.kernel.org/bpf/9d444098-7c03-4163-af12-bd0a79a51443@paulmck-laptop/ [2] Assisted-by: LLM Signed-off-by: Jose Fernandez (Anthropic) Signed-off-by: Josef Bacik Reviewed-by: Rik van Riel Link: https://lore.kernel.org/r/20260909-b4-htab-batch-resched-v2-1-0cb529d8f95a@toxicpanda.com Signed-off-by: Alexei Starovoitov commit bcfe2816e6ec46c3f4c58aa4264476665ddb3f69 Author: Ali Ahmet Memiş Date: Fri Sep 11 18:56:47 2026 +0300 tracing: Don't dereference trace_event_file in deferred trigger free The enable_event trigger defers trace_event_put_ref() to the trigger free kthread, but the trace_event_file can already be freed when the instance is removed. Keep the trace_event_call directly in enable_trigger_data so the deferred free does not access the freed trace_event_file. Cc: stable@vger.kernel.org Fixes: e091351b3881 ("tracing: Delay module ref count for "enable_event" trigger") Reported-by: Alexander Gordeev Closes: https://lore.kernel.org/all/20260828134340.2501683A24-agordeev@linux.ibm.com/ Link: https://patch.msgid.link/20260911155650.354844-1-aliamemis@disroot.org Signed-off-by: Ali Ahmet Memiş Signed-off-by: Steven Rostedt commit b4dcc18b97913888e8d009624e07c8014ce41b84 Author: Leon Hwang Date: Fri Sep 11 22:25:12 2026 +0800 ftrace: Use rcu_assign_pointer() for tmp_ops filter hash tmp_ops.func_hash->filter_hash is annotated __rcu, but update_ftrace_direct_mod() assigns hash to it directly. Sparse reports an address-space mismatch. Use rcu_assign_pointer() for the assignment. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260911142512.19344-1-leon.hwang@linux.dev Fixes: 50b35c9e50a8 ("ftrace: Use hash argument for tmp_ops in update_ftrace_direct_mod") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609110704.Q3M5vCDV-lkp@intel.com/ Signed-off-by: Leon Hwang Signed-off-by: Steven Rostedt commit ac781acaef4904b9be64a7b5755c778e5d76ede6 Author: Siddharth Chintamaneni Date: Wed Sep 2 17:14:14 2026 +0000 selftests/bpf: Test terminal gotox instructions Add tests that place gotox at the end of the main program and a subprogram, with each jump-table target preceding the gotox instruction. This tests gotox as a valid non-fallthrough terminal instruction. Signed-off-by: Siddharth Chintamaneni Reviewed-by: Anton Protopopov Link: https://lore.kernel.org/r/20260902171414.96165-2-sidchintamaneni@gmail.com Signed-off-by: Alexei Starovoitov commit 0d7823cd4cda35f2060a685fa276ff7709915abc Author: Siddharth Chintamaneni Date: Wed Sep 2 17:14:13 2026 +0000 bpf: Allow terminal gotox instructions check_subprogs() treats gotox as a direct jump and validates its reserved zero offset. When gotox is the final instruction, this produces a synthetic successor one instruction past the end of the subprogram and rejects an otherwise valid program. Skip direct-offset validation for gotox and accept it as a non-fallthrough terminal instruction. Its actual targets remain validated from the instruction-array jump table during CFG construction. Fixes: 493d9e0d6083 ("bpf, x86: add support for indirect jumps") Signed-off-by: Siddharth Chintamaneni Reviewed-by: Anton Protopopov Link: https://lore.kernel.org/r/20260902171414.96165-1-sidchintamaneni@gmail.com Signed-off-by: Alexei Starovoitov commit ba970587a0e1203b6a0934b5b9174886b4c4d24c Author: Rob Clark Date: Sat Sep 12 08:09:14 2026 -0700 drm/msm/a6xx+: Increase GMU FW init timeout We were using 10ms, kgsl uses 100ms. In practice it is usually takes less than 10ms, but very occasionally goes a bit above 10ms, leading to a "GMU firmware inialization timed out", from which point things go south. There are probably some things that could be done to speed up init, like increasing GMU freq. But to be safe, increase the timeout to match kgsl. Signed-off-by: Rob Clark Reviewed-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/753014/ Message-ID: <20260912150915.28700-1-robin.clark@oss.qualcomm.com> commit cba2348ab114391f5b1a00fa65c5b739f13f0563 Merge: 95deca8dd9a910 ad4497a92caba4 Author: Linus Torvalds Date: Sat Sep 12 08:44:12 2026 -0700 Merge tag 'xfs-fixes-7.3-rc3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux Pull xfs fixes from Carlos Maiolino: "More than the usual amount of fixes. The highlights here are a block under reservation fix which caused an assert to be triggered in non-default configurations. The assert, initially added on 7.3-rc2 just makes the problem explicit but is not the cause. Another highlight is a missed lock/unlock mutex in the xfs healthmonitor which was causing lockdeps warnings. Besides those two, this also contains a myriad of fixes for random bugs found by LLM tools in the healthmon, scrub and online repair. A few bug fixes for zoned xfs are also included. This also includes an accounting fix for our buffer slab cache where the memory payload associated to each object was not being properly accounted for. The remaining of the patches are a few lock context annotations added and/or fixed. They are mostly disabled by now, but still worth fixing before we get them enabled. And last but not least, a few clean ups" * tag 'xfs-fixes-7.3-rc3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: (75 commits) xfs: advance the findparent inode scan cursor while holding ILOCK xfs: reset parent pointer args before each dir tree unlink repair xfs: fix replaying dirent removals into the temporary directory xfs: fix termination logic in xchk_bmap xfs: fix rtrmap cross-referencing elision logic xfs: actually check internal-rtdev fields in the superblock xfs: fix under-reservation of blocks when repairing sf directories xfs: take hm->lock in xfs_ioc_health_monitor() before insert xfs: set IOMAP_F_INTEGRITY for zoned writes on integrity devices xfs: avoid extra cache flushes for multi-device file systems in xfs_fsync xfs: don't continue on error in xfs_fsync xfs: also flush the RT device cache in xlog_write_iclog xfs: bail out on bitmap errors in xrep_agfl_fill xfs: snapshot old AGFL before rewriting it xfs: remove redundant function declaration xfs: report runtime failures in scrub xfs: report healthy filesystem events in scrub stats xfs: snapshot scrub stats when rendering them xfs: remove several unused and never-implemented declarations xfs: count escaped corruption errors in scrub stats ... commit 95deca8dd9a91063babb2ef3a69f5248b1fa824e Merge: 4d85a45df03118 09f1294ee2abee Author: Linus Torvalds Date: Sat Sep 12 08:31:48 2026 -0700 Merge tag 'for-7.3-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - tree-checker updates, validate values in b-tree item keys, other item length checks - don't do unnecessary transaction commit fallback when logging parent directories - in zoned mode, initialize space info of a block group early enough so it does not lead to NULL pointer dereference * tag 'for-7.3-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: tree-checker: validate name length for extref items btrfs: tree-checker: validate parent field for inode extref items btrfs: tree-checker: validate key offset for inode ref keys btrfs: fix unnecessary transaction commit fallback from btrfs_log_all_parents() btrfs: set space_info before adding new free space in btrfs_make_block_group() commit 4d85a45df03118ade0eb34486fb7948bca17acf8 Merge: 31a4327ffe2d8c 135d84c66f8542 Author: Linus Torvalds Date: Sat Sep 12 08:18:50 2026 -0700 Merge tag 'erofs-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs Pull erofs updates from Gao Xiang: "The most impactful fix here is to disable LZ4 rolling decompression for now. AWS folks recently found their systems could get corrupted data with some rare, specific LZ4 datasets, and after a deeper analysis, I found the root cause is that there could be uncontrolled backward memory copies in the current LZ4 implementation and it breaks the assumption of the rolling decompression optimization, since the kernel LZ4 codebase is out of our control and it needs more time to plan how to do next, so disable LZ4 rolling decompression for now to ensure data correctness for real production on these rare cases first. The technical details also see the corresponding commit. Other changes are random minor fixes. Summary: - Disable LZ4 rolling decompression for now due to the uncontrolled LZ4 implementation - Fix missing sysfs feature entry for xattr prefixes - Fix invalid LZMA decoders on resize failure - Rearrange the inode_share cache key to avoid potential collisions - Fix erofs_bread() when fsoffset is used on sub-page-block EROFS filesystems" * tag 'erofs-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs: erofs: add missing buf->off in erofs_bread() erofs: delimit inode_share cache key components erofs: disable LZ4 rolling decompression for now erofs: preserve LZMA decoders on resize failure erofs: add sysfs feature entry for xattr prefixes commit 31a4327ffe2d8cbd0f51a3af6a3ffc5ecd7fdbee Merge: f6e213d5a2a942 a0a34a40ed299c Author: Linus Torvalds Date: Sat Sep 12 08:06:04 2026 -0700 Merge tag 'fbdev-for-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev Pull fbdev fixes from Helge Deller: "Two patches for VT core code and fbcon prevent potential out-of-bounds reads on font or screen size changes, one fix limits the Superblitter in atafb to supported modes only, and some minor fixes for vfb, ssd1307fb and omapfb" * tag 'fbdev-for-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev: fbdev: vfb: defer cleanup until the last reference fbdev: atafb: Restrict SuperBlitter to supported formats fbdev: ssd1307fb: fix NULL pointer dereference on missing match data fbcon: Fix KASAN slab-out-of-bounds Read in fbcon_prepare_logo fbdev: omapfb: Fix __be32 sparse warning in panel_enabled() vt: hide cursor prior to font changes to avoid out-of-bound reads commit f6e213d5a2a94255b31926f0e9f7c1eb234bbf22 Merge: 52311be52f66f1 b63c3c26726576 Author: Linus Torvalds Date: Sat Sep 12 07:55:52 2026 -0700 Merge tag 'iommu-fixes-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux Pull IOMMU fixes from Joerg Roedel: "RISC-V: - Serialize command queue publication to prevent concurrent producers from exposing incomplete or out-of-order commands to hardware - Wait for queue space outside the command queue lock - Avoid waiting for IOFENCE completion when command enqueue failed AMD: - Prevent GA log buffers from being reallocated and leaked during resume, where allocation also occurs in an unsuitable syscore callback context - Fix a regression on older systems whose firmware advertises incorrect IOMMU features - Preserve allocation errors when assigning host domain IDs to nested domains s390: - Prevent a NULL dereference when translating an unmapped IOVA with five-level ZPCI translation tables Misc: - Remove a stale MAINTAINERS entry and clean up unused or redundant AMD IOMMU declarations, macros, and checks" * tag 'iommu-fixes-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: iommu/amd: Remove unused macro iommu/amd: Remove redundant checks from interrupt handler path iommu/amd: Remove redundant check in irq_remapping_select() iommu/amd: Make iommu_sva_set_dev_pasid as static MAINTAINERS: Drop the nonexistent vsi-iommu.h file entry iommu/amd: Fix ineffective error check in nested domain allocation iommu/amd: Fix premature break in init_iommu_one() again iommu/amd: Do not reallocate GA log buffers on resume iommu/s390: Fix NULL dereference in iova_to_phys() with ZPCI_TABLE_TYPE_RFX iommu/riscv: Avoid waiting on failed command enqueue iommu/riscv: Serialize command queue publishing iommu/riscv: Add command queue lock commit 52311be52f66f1a3c71bc808d156482feb1eb79f Merge: 5225b8eec4c9bb 9e5c53d75c560a Author: Linus Torvalds Date: Sat Sep 12 07:45:01 2026 -0700 Merge tag 'powerpc-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Madhavan Srinivasan: - powerpc/entry: Fix double accounting of user time on interrupt entry - Fix leak in htmdump_init_debugfs - KVM: PPC: Book3S HV: Set irqfd->producer only on success - powerpc/kexec_file: print configured kernel command line - Remove redundant early_init_dt_scan_root() call - misc fixes and cleanup Thanks to Aboorva Devarajan, Amit Machhiwal, Athira Rajeev, Christophe Leroy, Christophe Leroy (CS GROUP), Kunwu Chan, leixiang, longlong yan, Michail Tatas, Mukesh Kumar Chaurasiya (IBM), Ritesh Harjani (IBM), Shivang Upadhyay, Sourabh Jain, Thibault Ferrante, Vaibhav Jain, and Venkat Rao Bagalkote * tag 'powerpc-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/pasemi: Add a null pointer check to the pas_setup_mce_regs powerpc/prom: Remove redundant early_init_dt_scan_root() call selftests/powerpc: use MAP_FAILED instead of (void *)-1 in tm-signal-context-force-tm powerpc/kexec_file: print configured kernel command line KVM: PPC: Book3S HV: Set irqfd->producer only on success powerpc/pseries/htmdump: Fix leak in htmdump_init_debugfs selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value selftests/powerpc/pmu/ebb: fix lost_exception_test hang with sched yield change powerpc/entry: Fix double accounting of user time on interrupt entry commit 59ced288fcba9e91bd38e61a972ad782c4edb7d0 Author: Sajal Gupta Date: Wed Sep 2 18:00:57 2026 +0530 drm/gud: fix out-of-bounds write in gud_plane_atomic_check() The plane property loop uses req->properties[num_properties + i] as write index while simultaneously incrementing `num_properties` inside the loop. At iteration i, num_properties has also incremented by i, so the write is done at `initial_num_properties + 2*i`, skipping every other index and advancing by 2 per iteration. With just 2 connector and 32 plane properties the last write happens at index 64, one slot past the end of the 64-slot (indices 0–63) allocation. A USB device can trigger OOB by advertising the maximum number of properties. Fix by dropping the redundant `+ i`; num_properties is already the correct running index, as gud_connector_fill_properties() fills the preceding slots. Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Reported-by: Sashiko Link: https://sashiko.dev/#/patchset/20260821071812.16500-1-sajal2005gupta%40gmail.com?part=1 Signed-off-by: Sajal Gupta Cc: Acked-by: Ruben Wauters Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260902123254.36987-1-sajal2005gupta@gmail.com commit effce1cb87ee0d8b3a8cbe7722968f4ea7efd360 Author: Sophie D Date: Wed Sep 9 21:49:10 2026 -0400 drm/gud: Ignore damage clips in full update mode When running in full update mode, previously small updates (such as moving the mouse across the screen) would cause many full frames to be generated. This would bog down the bus and lower the effective framerate significantly - I was seeing a drop from 60 FPS to 2 FPS. Set ignore_damage_clips in full update mode so the damage iterator yields a single full-plane rectangle instead of one per clip. Fixes: 73cfd166e045 ("drm/gud: Replace simple display pipe with DRM atomic helpers") Cc: # 6.18.x Signed-off-by: Sophie D Reviewed-by: Thomas Zimmermann Acked-by: Ruben Wauters Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260910014910.8564-1-patches@scd31.com commit 221253723dc58bb901c3f27a7659823e63fc598c Author: Takashi Iwai Date: Thu Sep 10 17:52:23 2026 +0200 ALSA: bcd2000: Fix race between rawmidi and disconnect Although we tried to fix the potential UAF issues at USB disconnect on bcd2000 driver, there is still an overlooked case -- namely, when a rawmidi trigger callback has been already running at USB disconnect handling, the in-flight function (e.g. bcd2000_midi_send()) could still access the URB, because the previous URB NULL-check & clearance was considered only for the URB complete callbacks, but not about the parallel rawmidi operations. For addressing the race, this patch introduced a new spinlock that covers each rawmidi operation as well as the rawmidi handling in the complete callback. The URB is cleared with the lock, so it guarantees that the pending rawmidi task already finished or a NULL check is effective. Fixes: 459d3a64766f ("ALSA: bcd2000: clear the URB pointers on disconnect") Link: https://patch.msgid.link/20260910155227.996210-1-tiwai@suse.de Signed-off-by: Takashi Iwai commit 5cddf63367ef894ba0026dfa2d524346f7048de9 Author: Krish Gulati Date: Sat Sep 12 12:36:13 2026 +0530 ALSA: hda/realtek: Add quirk for HP Victus 15-fa1xxx (MB 8BB1) mute LED The mute LED on this board does not respond to mute state changes because no fixup is matched for SSID 103c:8bb1. The reporter verified the LED can be toggled manually via COEF index 0x0B. Reported-by: Mazen Ahmed Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221982 Tested-by: Mazen Ahmed Signed-off-by: Krish Gulati Link: https://patch.msgid.link/20260912070618.21272-1-krishgulati7@gmail.com Signed-off-by: Takashi Iwai commit c60ae98c5aa64021751b38ab1313b19d620bf640 Author: David Howells Date: Fri Sep 11 10:25:04 2026 +0100 9p: Fix v9fs_issue_write() to update i_size and remote_i_size Fix v9fs_issue_write() to update i_size and remote_i_size to the new size of the server file if we made it larger, using the start fpos and the count returned by p9_client_write() to calculate the new minimum file size. This assumes that if the 9P server makes a short write (say it hits ENOSPC), a reduced count is returned. Fixes: 5fb70e7275a6 ("netfs, 9p: Implement helpers for new write code") Reported-by: Michael Mulqueen Closes: https://lore.kernel.org/r/fbb9e395-1e07-4212-8f70-23f3cd498074@method-b.uk/ Cc: stable@vger.kernel.org Signed-off-by: David Howells Message-ID: <2226525.1789118704@warthog.procyon.org.uk> Signed-off-by: Dominique Martinet commit e6b6078ea1731b05b3b552497b3bce4bf8b014ae Merge: 78445023439506 979aabdad8dd03 Author: Jakub Kicinski Date: Fri Sep 11 17:25:19 2026 -0700 Merge branch 'neighbour-small-fixes-for-rtm_-get-set-neightbl' Kuniyuki Iwashima says: ==================== neighbour: Small fixes for RTM_{GET,SET}NEIGHTBL. While working on the follow-up suggested here, https://lore.kernel.org/20260902143023.GA3966681@shredder I found a few bugs in RTM_GETNEIGHTBL and RTM_SETNEIGHTBL, which this series fixes. Patch 1, 3, 4 will conflict with net-next in neightbl_dump_info() due to removal of net_eq() below: p = list_next_entry(&tbl->parms, list); list_for_each_entry_from_rcu(p, &tbl->parms_list, list) { if (!net_eq(neigh_parms_net(p), net)) continue; Note also that currently neigh_proc_dointvec_ms_jiffies_positive() is buggy and does not enforce min/max, and it needs this fix: https://lore.kernel.org/20260905233819.1064529-2-kuniyu@google.com ==================== Link: https://patch.msgid.link/20260909233143.2401847-1-kuniyu@google.com Signed-off-by: Jakub Kicinski commit 979aabdad8dd03394467ee484a1a70f3d40b19ba Author: Kuniyuki Iwashima Date: Wed Sep 9 23:31:26 2026 +0000 neighbour: Skip default parms when resumed in neightbl_dump_info(). neightbl_dump_info() calls neightbl_fill_info() in each loop to render the default parms. If there are many devices and neightbl_fill_param_info() failed, neightbl_fill_info() is called again when the dump resumes: # ynl --family rt-neigh --dump getneightbl --output-json | jq '.[] | {name: .name, ifindex: .parms.ifindex}' ... { "name": "ndisc_cache", "ifindex": null } ... { "name": "ndisc_cache", "ifindex": 6 } { "name": "ndisc_cache", "ifindex": null } { "name": "ndisc_cache", "ifindex": 5 } Let's skip neightbl_fill_info() if it is already called in neightbl_dump_info(). Note that we cannot use !neigh_skip instead of !default_skip because default_skip == 1 && neigh_skip == 0 could be true if the first neightbl_fill_param_info() fails. Also, nidx must be cleared at the end of each table loop; otherwise, if neightbl_fill_info() for a subsequent table fails, the leftover nidx from the previous table would be saved in cb->args[1], resulting in erroneously skipping parms of the subsequent table in the next dump. Fixes: c7fb64db001f ("[NETLINK]: Neighbour table configuration and statistics via rtnetlink") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260909233143.2401847-5-kuniyu@google.com Signed-off-by: Jakub Kicinski commit 7b430fcfc972f61b09cc19ca95997586af4a147d Author: Kuniyuki Iwashima Date: Wed Sep 9 23:31:25 2026 +0000 neighbour: Don't render blackhole_netdev via RTM_GETNEIGHTBL. The cited commits started to initialise blackhole_netdev with neigh_parms_alloc(). This is visible in init_net as the ifindex==0 entries via RTM_GETNEIGHTBL: # ynl --family rt-neigh --dump getneightbl --output-json \ | jq '.[] | select(.parms.ifindex == 0) | {name: .name, ifindex: .parms.ifindex}' { "name": "arp_cache", "ifindex": 0 } { "name": "ndisc_cache", "ifindex": 0 } For RTM_SETNEIGHTBL, ifindex being 0 means wildcard. Let's skip blackhole_netdev's parms in neightbl_dump_info(). Note that lookup_neigh_parms() does not need the same change because the default parms is always the first entry and matches with ifindex == 0. Fixes: e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev") Fixes: 22600596b675 ("ipv4: give an IPv4 dev to blackhole_netdev") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260909233143.2401847-4-kuniyu@google.com Signed-off-by: Jakub Kicinski commit 6d79b223ec44ada58ad37db42f539b60985a7722 Author: Kuniyuki Iwashima Date: Wed Sep 9 23:31:24 2026 +0000 neighbour: Enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS. NDTPA_INTERVAL_PROBE_TIME_MS sets .type and .min but misses .validation_type, so no validation is applied: # ynl --family rt-neigh --do setneightbl \ --json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 0}}' # ynl --family rt-neigh --dump getneightbl --output-json | \ jq '.[] | select(.name == "arp_cache" and has("config")) | .parms["interval-probe-time-ms"]' 0 Moreover, nla_get_msecs() uses msecs_to_jiffies(), and u64 is silently cast to u32, so a larger value can bypass the min check: e.g. 4294967296 == 0x100000000 # ynl --family rt-neigh --do setneightbl \ --json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 4294967296}}' # ynl --family rt-neigh --dump getneightbl --output-json | \ jq '.[] | select(.name == "arp_cache" and has("config")) | .parms["interval-probe-time-ms"]' 0 msecs_to_jiffies() returns MAX_JIFFY_OFFSET if the value is larger than INT_MAX. Also, INT_MAX ms overflows int NEIGH_VAR() when HZ > 1000 (Alpha, MIPS), and passing a negative integer to queue_delayed_work(unsigned long delay) causes sign extension, which wraps around the expiry time to the past, resulting in it being handled as 0 delay in the timer wheel. Let's use NLA_POLICY_FULL_RANGE() and limit the max to 1 day. The same max check is applied to sysctl as well. Note that this controls the probe interval for NTF_MANAGED entries, so the max of 1 day is unlikely to break any deployments. Fixes: 211da42eaa45 ("net, neigh: introduce interval_probe_time_ms for periodic probe") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260909233143.2401847-3-kuniyu@google.com Signed-off-by: Jakub Kicinski commit 764dcebb033764633700a036c7351a7c6350eec6 Author: Kuniyuki Iwashima Date: Wed Sep 9 23:31:23 2026 +0000 neighbour: Add missing RCU annotation for neightbl_dump_info(). neightbl_dump_info() fetches the first non-default neigh_parms with list_next_entry(&tbl->parms, ...) and iterates through the list with list_for_each_entry_from_rcu(). However, list_next_entry() does not use RCU helper. Let's use list_for_each_entry_rcu() and skip the default parms. Fixes: 4ae34be50064 ("neighbour: Convert RTM_GETNEIGHTBL to RCU.") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260909233143.2401847-2-kuniyu@google.com Signed-off-by: Jakub Kicinski commit 59e0cc31cc5c43586c6eaada62c2c863bfbcbfb5 Author: Andreas Kemnade Date: Wed Sep 9 14:16:36 2026 +0200 clk: ti: composite: resolve parent clocks by name again Trying to resolve them by DT index causes massive havoc on OMAP3, Clocks around the timers used as a system clocksource are not properly resolved causing ealy boot failures. The problem seems to be that parents must be resolved by looking into the clocks property of the component node marked with "ti,composite-mux-clock", with the switch to dt index, that node was not used anymore. It was used by the of_clk_parent_fill() call. To a lesser extent also OMAP4/5 boards are affected. Since this patch was introduced just because of a cleanup request and not to solve the actual problem (https://lore.kernel.org/linux-omap/alkZmw-XmnCOZfOD@redhat.com/) just revert it. Cleanup needs really more thought here. The similar change to the TI mux clock, which solves a problem on the AM3 platform, seems to be harmless. So just revert commit fe3dd92ac54a ("clk: ti: composite: resolve parent clocks by DT index, not by name") for now. Fixes: fe3dd92ac54a ("clk: ti: composite: resolve parent clocks by DT index, not by name") Reviewed-by: Mathieu Dubois-Briand Signed-off-by: Andreas Kemnade Signed-off-by: Brian Masney commit 5225b8eec4c9bb21aecff6295fab6346a3c3738e Author: Jens Axboe Date: Fri Sep 11 15:45:37 2026 -0600 mailmap: update entry for Jens Axboe I recently changed jobs, let's update the .mailmap entry so that patches are attributed to the right (current) company. Signed-off-by: Jens Axboe Signed-off-by: Linus Torvalds commit 114f73092b5d1bbea2554a6a784f5ebb53d47bdb Merge: 0fb234ce373a33 f3e6ef13e24c9f Author: Linus Torvalds Date: Fri Sep 11 15:24:21 2026 -0700 Merge tag 'regulator-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "One fix for pf1550 which checked for errors on multiple regulators but always notified via one of them regardless of which one had the problem, plus one device ID addition in the fan53555 DT bindings" * tag 'regulator-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: pf1550: fix which regulator is notified regulator: dt-bindings: fan53555: add tcs,tcs4526 commit 0fb234ce373a331a21c1d33cffef28e53cee4ddb Merge: 525f0f99a4f775 f77de4c33f0edb Author: Linus Torvalds Date: Fri Sep 11 15:10:31 2026 -0700 Merge tag 'spi-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fix from Mark Brown: "New device ID for v7.3: update the DesignWare DT binding to say how to describe the UltraRISC DP1000 instance of the controller" * tag 'spi-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: dt-bindings: snps,dw-apb-ssi: Add compatible for UltraRISC DP1000 SoC commit 8697c431e297eb0d0ab13dda6bc172b48a34f05c Author: Cen Zhang Date: Sat Sep 12 00:31:16 2026 +0300 KEYS: encrypted: fix integer overflow of datablob_len encrypted_key_alloc() stores datablob_len in a u16. It is computed from multiple string and payload lengths. If the result exceeds U16_MAX, the assignment truncates the allocation size. KASAN reports a 32760-byte slab-out-of-bounds write when __ekey_init() copies the master key description into the undersized buffer. The total payload length stored in key->datalen is also a u16. Use check_add_overflow() to reject values that do not fit either destination, and use kzalloc_flex() for the flexible-array allocation. Fixes: 7e70cb497850 ("keys: add new key-type encrypted") Cc: stable@vger.kernel.org Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Cen Zhang Signed-off-by: Francis Perron Reviewed-by: Jarkko Sakkinen Tested-by: R Nageswara Sastry Link: https://lore.kernel.org/r/20260909153433.83117-1-cenzhang@linux.microsoft.com Signed-off-by: Jarkko Sakkinen commit 114f00d738f15dd8c7318369edcdc53dd6d08763 Author: Jarkko Sakkinen Date: Tue Sep 1 23:58:06 2026 +0300 KEYS: trusted: Fix tpm2_load_cmd() boundary check tpm2_load_cmd() does boundary checks against the ASN.1 size i.e., payload->blob_len. Address this by passing the decoded blob size to tpm2_load_cmd(), and use it for the boundary checks. Cc: stable@vger.kernel.org # v5.13+ Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Reported-by: co+6a581c4284f721d4@bugs.sh Closes: https://bugs.sh/b/6a581c4284f721d4/ Reviewed-by: Stefano Garzarella Tested-by: Srish Srinivasan Link: https://lore.kernel.org/r/20260901205809.2028454-1-jarkko@kernel.org Signed-off-by: Jarkko Sakkinen commit 0d6a4268b06084baafd8ee5d66955c7e1c2e053b Author: Maoyi Xie Date: Fri Aug 21 17:59:35 2026 +0800 keys: translate request_key_auth pid for the reading procfs instance request_key_auth_describe() prints rka->pid into /proc/keys as a raw pid_t in the initial pid namespace. A reader can open /proc/keys through a mount in another pid namespace. That reader sees a number with no meaning there. The number can even name an unrelated task. The line needs VIEW on the key. So the reader either shares the key owner's uid or possesses the key. The fix keeps a struct pid. Commit 4f82f45730c6 ("net ip6 flowlabel: Make owner a union of struct pid * and kuid_t") gave /proc/net/ip6_flowlabel the same storage. The print goes through pid_nr_ns(). It renders against the pid namespace of the procfs instance the line is read through. Commit ad08978ab41c ("ipv6/flowlabel: simplify pid namespace lookup") moved that print to the same anchor. Output through an initial namespace /proc does not change. The line shows 0 for a requestor with no number in that namespace. Translating at read time was the alternative. find_pid_ns() can resolve a recycled number. The line would then name a live task with no connection to the key. A stored struct pid gives 0 instead when the requestor has no number there. Link: https://lore.kernel.org/keyrings/20260809110202.2180410-1-maoyixie.tju@gmail.com/ Fixes: 78b7280cce23 ("KEYS: Improve /proc/keys") Cc: stable@vger.kernel.org # v5.10+ Assisted-by: Claude:claude-opus-5 codeql Signed-off-by: Maoyi Xie Link: https://lore.kernel.org/r/20260821095935.1864998-1-maoyixie.tju@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 2725ab3f5ad1c5f375c7c9fee4af02a9b138f701 Author: Karl Mehltretter Date: Fri Aug 21 04:53:27 2026 +0200 keys: fix lost wakeup when reaping a dead key type clear_bit() is atomic with respect to the word it modifies, but it is an unordered operation: it implies no memory barrier on either side (Documentation/atomic_bitops.txt). key_garbage_collector() clears KEY_GC_REAPING_KEYTYPE with clear_bit() and calls wake_up_bit() after reaping a dead key type. wake_up_bit() uses a lockless waitqueue check and requires a full barrier after the clear. The existing smp_mb() is before clear_bit(), so nothing orders the clear against that check. The GC can see an empty waitqueue while unregister_key_type() still sees the bit set. The final wakeup is then lost, leaving module unload stuck in wait_on_bit(). Use clear_and_wake_up_bit(). Its clear_bit_unlock() has RELEASE semantics, so the completed GC work stays ordered before the clear, and its smp_mb__after_atomic() orders the clear before the waitqueue check. Fixes: 0c061b5707ab ("KEYS: Correctly destroy key payloads when their keytype is removed") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://lore.kernel.org/r/20260821025327.61488-1-kmehltretter@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 77be3641f3e3a56e42a5ed889372ef395a933f3c Author: Mikhail Gavrilov Date: Thu Sep 3 16:51:35 2026 +0500 debugfs: don't warn about uninitialized debugfs for an error parent Since commit c3a280ff728a ("debugfs: warn if file creation failed due to uninitialized debugfs") every boot with CONFIG_REF_TRACKER=y and CONFIG_DEBUG_FS=y prints two errors before the root filesystem is mounted: debugfs: Unable to create file 'net_refcnt@(____ptrval____)', debugfs is not initialized yet debugfs: Unable to create file 'net_notrefcnt@(____ptrval____)', debugfs is not initialized yet Nothing is actually wrong. Both files show up under /sys/kernel/debug/ref_tracker/ once the system is up. The kernel is reporting an error for a condition the caller has already accounted for. net_ns_init() runs directly from start_kernel(), before any initcall, and calls ref_tracker_dir_init() for init_net's two trackers. debugfs_init() is a core_initcall, so debugfs cannot possibly be up at that point. That is by design: ref_tracker_dir_debugfs() is documented as safe to call again later, and net/core/net_namespace.c has a late_initcall() that re-registers both directories once debugfs exists. ref_tracker also states that intent to debugfs. ref_tracker_debug_dir is initialised to ERR_PTR(-ENOENT) and only gets a real dentry in a late_initcall, so the early call hands debugfs_create_file() a parent that is already an error. debugfs_start_creating() honours that and returns the parent error, but only after the new pr_err() has fired. Move the IS_ERR(parent) check above the debugfs_initialized() test. A caller passing an error parent is propagating an earlier failure, which is the pattern debugfs documents and which the warning is not aimed at. A caller passing a valid or NULL parent too early - the case the warning was added for - still gets it. One behaviour change: an early caller with an error parent now gets PTR_ERR(parent) back instead of -ENOENT. All callers of these interfaces are documented to ignore the return value. Fixes: c3a280ff728a ("debugfs: warn if file creation failed due to uninitialized debugfs") Link: https://lore.kernel.org/all/6d1dc775f7d5e754d734907514534054f682bac5.1781171918.git.yk@y-koj.net/ Signed-off-by: Mikhail Gavrilov Tested-by: Yohei Kojima Link: https://patch.msgid.link/20260903115135.63210-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Danilo Krummrich commit 525f0f99a4f775060288b3069e12b1d3e2b576da Merge: 827751b699b79a b1edd3a3e00369 Author: Linus Torvalds Date: Fri Sep 11 13:50:47 2026 -0700 Merge tag 'drm-fixes-2026-09-12' of https://gitlab.freedesktop.org/drm/kernel Pull drm fixes from Dave Airlie: "Weekly fixes pull, this seems relatively quiet for the new world, scattered fixes, mostly amdgpu leading the way, but lots of minor fixes in other drivers. drm_exec: - fix 0 object handling sched: - null ptr deref fix in kunit tests amdgpu: - Freesync fix - GPUVM fix - Debugfs fixes - HDMI fixes - IPS fix - GPU reset fix - RGB quantization fixes - SMU 13.0.x fixes xe: - runtime PM guard fix - cache flushing fix i915: - Fix a memleak on perf config query error path - Fix UHBR SST SDP splitting when sink doesn't support it bridge: - fix ti-sn65dsi83 error handling - tc358768: Enforce input bus flags via atomic_check ast: - fix blend mode property on cursor plane qxl: - fix blend mode property on primary/cursor planes virtio: - fix blend mode property on cursor plane vboxvideo: - fix blend mode property on planes rockchip: - fix endpoint name length - fix Kconfig issues ivpu: - limit firmware log prints to field size - validate buffer range in ivpu address translation - validate fw log buffers ethosu: - ensure SRAM sizing - ensure cmd stream formatting - drop IRQF_SHARED - fix open return value adp: - fix Kconfig logicvc: - fix Kconfig" * tag 'drm-fixes-2026-09-12' of https://gitlab.freedesktop.org/drm/kernel: (38 commits) drm/amd/pm: report energy accumulator for smu 13.0.0 drm/amd/pm: fix gpu metrics energy accumulator for smu 13.0.0/13.0.7 drm/amd/display: Rebuild InfoFrames on output color space changes drm/amd/display: Honor Broadcast RGB for BT.2020 RGB output drm/amd/display: Propagate HDMI RGB quantization selectability Revert "drm/amdgpu: debugfs: avoid extra EOLs in amdgpu_gem_info" drm/amdgpu: skip gfx switch_power_profile during GPU reset drm/amd/display: Fix HF-VSDB DSC bpc detection to be cumulative drm/amd/display: Exit IPS before connector detection on resume drm/amd/display: Shorten hdmi_frl_status_polling_workqueue dm/amdgpu: fix malformed link_settings debugfs output drm/amdgpu: skip the VMID 0 flush for VRAM drm/amd/display: Consult MCCS FreeSync cap only if requested & supported drm/i915: Fix memory leak in query_perf_config_list() drm/i915/dp: Gate UHBR SST SDP splitting on sink capability drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches drm/xe: Guard page-fault worker with runtime PM check drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work() drm/bridge: tc358768: Enforce input bus flags via atomic_check drm/drm_exec: fix up contended obj when num_objects is 0 ... commit 827751b699b79a6e569983359c02dce67f81b94c Merge: 1235ff329981ec b94cec5761d226 Author: Linus Torvalds Date: Fri Sep 11 13:15:13 2026 -0700 Merge tag 'riscv-for-linus-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: "From a RISC-V point of view, there's one notable fix here, reverting an earlier bogus fix to the pointer masking code. Fortunately the practical impact appears to be small. - Revert a bad fix, likely LLM-generated, in the pointer masking code that confused the RISC-V hardware pointer masking implementation with the Linux kernel tagged address feature - Fix unexpected faults caused by kprobe instruction slot writes when !CONFIG_STRICT_MODULE_RWX - Fix unexpected faults on minimal configurations during runtime code patching on !CONFIG_STRICT_MODULE_RWX systems - Fix a misplaced variable clear causing incorrect reuse of previous values in the RISC-V hardware feature probing code - Fix two bugs in the PMU SBI perf code on rv32: use BIT_ULL rather than BIT on 64-bit masks; and use a bitmap rather than an unsigned long on a quantity that can exceed 32 bits And a few miscellaneous cleanups: - Avoid a potential dereference-before-NULL-pointer-check bug in the PMU SBI perf driver - Use CONFIG_GENERIC_BUG_RELATIVE_POINTERS to simplify the rv32 bug table code (like x86 and PPC) - Report the RISC-V standard ISA extensions Z[v]fhmin when support is claimed for the superset RISC-V standard ISA extensions Z[v]fh; and simplify our FPU test code to only check for the presence of the D extension - Use an existing kernel string helper in place of some open-coded code in kernel/usercfi.c - Fix some yamllint issues in the RISC-V DT bindings for CPUs - Convert one use of __ASSEMBLY__ to __ASSEMBLER__ that snuck into the RISC-V CFI selftest code - Update the translation for the simplified Chinese translation of the RISC-V kernel patch acceptance policy" * tag 'riscv-for-linus-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: skip software algning code for HAVE_EFFICIENT_UNALIGNED_ACCESS kselftest/riscv: Replace __ASSEMBLY__ with __ASSEMBLER__ docs/zh_CN: Update arch/riscv/patch-acceptance.rst translation dt-bindings: riscv: cpus: Fix yamllint style issues riscv: hwprobe: simplify has_fpu() to check D extension only perf: RISC-V: check cpu_hw_evt before dereference in overflow IRQ riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present perf: RISC-V: store available counter mask as bitmap perf: RISC-V: use BIT_ULL for u64 overflow masks riscv: bug: Make RV32 use GENERIC_BUG_RELATIVE_POINTERS riscv: hwprobe: initialize pair->value in hwprobe_one_pair() riscv: use string helper in setup_global_riscv_enable() Revert "riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set" riscv: patch: skip fixmap mapping when kernel text is already writable riscv: mm: make EXECMEM_KPROBES writable without CONFIG_STRICT_MODULE_RWX commit 1235ff329981ecde9ccbf49b83bd4d71e827d541 Merge: 707662b40a82c9 d144a494d81fcf Author: Linus Torvalds Date: Fri Sep 11 12:52:48 2026 -0700 Merge tag 'platform-drivers-x86-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from Ilpo Järvinen: - amd/pmf: Fix build on !CONFIG_AMD_PMF_DEBUG - asus-laptop: Fix ACPI event handling - hp-wmi: Fix board_params typo for 8DD6 board - x86-android-tablets: Fix Arizona and Crystal Cove GPIO lookups * tag 'platform-drivers-x86-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: MAINTAINERS: fix sysfs-platform-ayaneo-ec documentation path platform/x86: x86-android-tablets: fix gpio_secondary_fwnode_init() not working platform/x86: x86-android-tablets: use shared battery swnode group on Yoga Tab 2 platform/x86: x86-android-tablets: drop redundant swnode group on YT3 platform/x86: x86-android-tablets: add Crystal Cove GPIO swnode support platform/x86: x86-android-tablets: pass node group to gpio_secondary_fwnode_init() platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown platform/x86: x86-android-tablets: fix Arizona GPIO swnode references platform/x86/amd/pmf: fix build on !CONFIG_AMD_PMF_DEBUG platform/x86: asus-laptop: Fix ACPI event handling platform/x86: hp-wmi: Fix board_params typo for 8DD6 board commit 707662b40a82c96e416fe17f3c116a4d648f1fdb Merge: 35ef102063fd6f a19d4f9b8befdc Author: Linus Torvalds Date: Fri Sep 11 12:44:11 2026 -0700 Merge tag 'ata-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fix from Niklas Cassel: - Drop documentation for no longer existing pata_legacy kernel parameters (Ethan) * tag 'ata-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: pata_legacy: remove documentation for removed module parameters commit 35ef102063fd6f39e045e6d4e92ac04d3d29c0bf Merge: 42f961c42b6b29 94b1a3ca9b8db3 Author: Linus Torvalds Date: Fri Sep 11 12:38:44 2026 -0700 Merge tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull block fixes from Jens Axboe: - Fix the start and length check added to iov_iter_extract_bvecs(), which used iter_iov_addr()/iter_iov_len() helpers that aren't safe for the ITER_BVEC/FOLIOQ/etc iterator types passed - sunvdc fixes for an -EIO issue from lack of retries, and unmapping LDC cookies when the descriptor send fails - Clear force_abort in ublk_queue_reset_io_flags() - ublk selftest install fix * tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: selftests: ublk: add batch IO cases to recover_03 ublk: clear force_abort in ublk_queue_reset_io_flags() sunvdc: fix -EIO issue due to lack of retries sunvdc: unmap LDC cookies when the descriptor send fails block: Fix start and length check added to iov_iter_extract_bvecs() selftests: ublk: install test_common.sh and trace/ scripts commit 42f961c42b6b29532c7c75e028b4192ed333fbcb Merge: 3026c6e4f223bd 47ccc3f1c615a4 Author: Linus Torvalds Date: Fri Sep 11 12:36:13 2026 -0700 Merge tag 'io_uring-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull io_uring fixes from Jens Axboe: - Fix a deadlock in the write path with superblock freezing - Fix an issue where a provided buffer ring would overconsume when using MSG_TRUNC - Keep the CQE flags on iopoll requests when adding kbuf flags * tag 'io_uring-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: io_uring/rw: keep CQE flags on iopoll requests when adding kbuf flags io_uring/net: don't overconsume buffers when using MSG_TRUNC io_uring/net: let io_recv_buf_select return the length of the buffer region io_uring/rw: end write accounting from ->ki_complete commit ebc5660132ddd244b57f03ed324922013a3d7363 Author: April Cardenas Date: Thu Sep 10 00:16:49 2026 -0500 smb/client: send lease break ACKs thru correct session for multiuser mounts Currently, when cifs_oplock_break handles a break request from the server it searches for the appropriate tlink to handle the request but incorrectly uses the current fsuid as the search key, eventually causing read errors for users with multiuser mounts on NetApp. Fix this by using the tlink from the cfile struct instead to respond through the correct session. As breaks are handled in a worker thread, the current fsuid isn't guaranteed to match the session that the break is intended for. This means that cifs_sb_tlink may search the rbtree using the wrong fsuid, and return a tlink with an incorrect session than the lease break was intended for. As a result, the breaks may be ACKed through an incorrect session. While it seems that Samba/Windows Servers 2016-2025 ignore this as long as the lease key is correct, we ran into a case where if you're using NetApp ONTAP or Azure NetApp Files they will reject the ACK and return `STATUS_LOCK_NOT_GRANTED` errors on any future read requests a user may initiate through their still held open file handle, and the server will eventually close the file. In the dmesg logs, the user may see errors like these: CIFS: Status code returned 0xc0000128 STATUS_FILE_CLOSED CIFS: VFS: Send error in read = -9 With a multiuser mount using NetApp, this issue is really easy for users to hit on a wide variety of kernel versions by attempting to copy a file from the share to the local machine through GNOME Files/Nautilus. This copy will always result in Nautilus throwing a `Bad File Descriptor` error to the user and fail. With this fix, you can copy files through Nautilus without issue. >From looking at the traces, it seems that glib will open the file first, and call listxattr before actually attempting to copy the file data. The listxattr call always triggers a break, causing the copy to fail. The proposed fix returns to the way the client grabbed the tlink before commit e8f5f849ffce2 ("cifs: fix potential oops in cifs_oplock_break"). The bulk of that commit (checking for list empty) remains untouched, and I think the change to using cifs_sb_tlink was intended to avoid a NULL/ERR deference on the tlink as well as update the reference count. I believe this fix should preserve those safety properties, but of course I'd appreciate any corrections here. Fixes: e8f5f849ffce2 ("cifs: fix potential oops in cifs_oplock_break") Cc: stable@vger.kernel.org Signed-off-by: April Cardenas Reviewed-by: Namjae Jeon Reviewed-by: Bharath S M Signed-off-by: Paulo Alcantara commit 8cd280282d1239bca68f8c3632ef1ac8556a396b Author: Sean Christopherson Date: Thu Aug 6 14:46:18 2026 -0700 KVM: Never clear KVM_REQ_VM_DEAD from a vCPU's requests Use kvm_test_request() instead of kvm_check_request() when querying KVM_REQ_VM_DEAD, i.e. don't clear KVM_REQ_VM_DEAD, as the entire purpose of KVM_REQ_VM_DEAD is to prevent the vCPU from enterring the guest ever again, even if userspace insists on redoing KVM_RUN. Ensuring KVM_REQ_VM_DEAD is never cleared will allow relaxing KVM's rule that ioctls can't be invoked on dead VMs, to only disallow ioctls if the VM is bugged, i.e. if KVM hit a KVM_BUG_ON(). Opportunistically add compile-time assertions to guard against clearing KVM_REQ_VM_DEAD through the standard APIs. Reviewed-by: Kai Huang Acked-by: Marc Zyngier Link: https://patch.msgid.link/20260806214618.82180-1-seanjc@google.com Signed-off-by: Sean Christopherson commit f13368e0acffd6d6289629705cb821d921104725 Author: Sean Christopherson Date: Wed Aug 26 09:14:30 2026 -0700 KVM: selftests: Use __GLIBC__, not _GNU_SOURCE, to detect actual glibc Use __GLIBC__ in the hardware disable test to detect when selftests are being built/linked against glibc and thus pthread_attr_setaffinity_np() is (hopefully) available. As pointed out by Sashiko and Hisam, _GNU_SOURCE is effectively a "request" macro to enable functionality, whereas __GLIBC__ is an announcement of support and selftests' idiomatic way of guarding code that's specific to glibc. Fixes: 496779b54943 ("KVM: selftests: Pre-set threads affinity in hardware disable test when possible") Reported-by: Sashiko Bot Closes: https://lore.kernel.org/all/20260731201140.5AF0C1F00AC4@smtp.kernel.org Suggested-by: Hisam Mehboob Link: https://patch.msgid.link/20260826161430.714316-1-seanjc@google.com Signed-off-by: Sean Christopherson commit 79a71cc2568f4b5d42284da2aa26f3b4f47ce01b Author: Jim Mattson Date: Wed Sep 2 11:47:11 2026 -0700 KVM: x86/pmu: Move Intel PMU global MSRs to intel_is_valid_msr() Commit c85cdc1cc1ea ("KVM: x86/pmu: Move handling PERF_GLOBAL_CTRL and friends to common x86") moved the existence check for the following Intel PMU MSRs to kvm_pmu_is_valid_msr(): - MSR_CORE_PERF_GLOBAL_STATUS - MSR_CORE_PERF_GLOBAL_CTRL - MSR_CORE_PERF_GLOBAL_OVF_CTRL That commit deemed these MSRs valid whenever pmu->version > 1. It intended to share the check with AMD PerfMonV2 because both vendor implementations require version 2 or greater for global PMU controls. However, as noted in the commit message, AMD uses different MSR indices for its global PMU registers. Commit 4a2771895ca6 ("KVM: x86/svm/pmu: Add AMD PerfMonV2 support") subsequently added AMD PerfMonV2 support and set pmu->version = 2. Because kvm_pmu_is_valid_msr() validated the Intel MSRs whenever pmu->version > 1, KVM incorrectly permitted AMD guests with PerfMonV2 to access these Intel MSRs without a #GP. Move the validation of these Intel MSRs to intel_is_valid_msr() and remove the common switch statement from kvm_pmu_is_valid_msr(). AMD already validates its own global PMU MSRs in amd_is_valid_msr(). Fixes: 4a2771895ca6 ("KVM: x86/svm/pmu: Add AMD PerfMonV2 support") Signed-off-by: Jim Mattson Reviewed-by: Like Xu Reviewed-by: Sandipan Das Link: https://patch.msgid.link/20260902184711.138538-1-jmattson@google.com Signed-off-by: Sean Christopherson commit 3026c6e4f223bdded6448fefe53ff85d9cbe51bd Merge: 576da3462c9919 4a724bcf5d703e Author: Linus Torvalds Date: Fri Sep 11 11:56:33 2026 -0700 Merge tag 'slab-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/slab Pull slab fixes from Vlastimil Babka: - Stable fix for an ABA issue causing slab list corruption introduced in 7.2 (Harry Yoo, with big thanks to Hyunwoo Kim for the thorough report and initial version of the fix) - Fix for 7.3 regression of kvfree_rcu() on PREEMPT_RT which can cause a deadlock from the set_cpus_allowed_force() caller (Vlastimil Babka) * tag 'slab-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/slab: mm/slab: take n->list_lock in __slab_try_return_freelist() to avoid race mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again commit 7ba5290db6bf365e46fb70bf13dc2a47048165ea Author: Stefano Radaelli Date: Wed Sep 2 18:43:17 2026 +0200 arm64: dts: imx8mp-var-dart-sonata: Fix Sonata SD I/O supply LDO5 powers the USDHC2 I/O rail on DART-MX8M-PLUS. Without a regulator consumer, the kernel disables LDO5 during late init, which removes the SD card and causes filesystem I/O errors. Reference LDO5 as the Sonata USDHC2 VQMMC supply, so the regulator remains enabled while the SD interface is active. Fixes: 41cd3d91ca859 ("arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board") Co-developed-by: Luan Rafael Carneiro Signed-off-by: Luan Rafael Carneiro Signed-off-by: Stefano Radaelli Signed-off-by: Frank Li commit a2b65837980a513cf24825bc4a50b0430e3391e7 Author: Neil Armstrong Date: Wed Sep 9 15:07:38 2026 +0200 drm/msm/a6xx: Use CX AO Counter register for timestamp on a750 GPUs The a750 uses the GMU CX AO Counters instead of the GMU_ALWAYS_ON_COUNTER register on A6xx and other A7xx GPUs, use it when running a A750 GPU. The GMU_ALWAYS_ON_COUNTER at offset 0x1f888 doesn't seem to exist on the SM8650 A750 GMU and returns 0, but the CX AO counter at offset 0x1f880 returns some proper timestamp data. Signed-off-by: Neil Armstrong Patchwork: https://patchwork.freedesktop.org/patch/752235/ Message-ID: <20260909-topic-sm8650-gmu-a750-timestamp-reg-v2-2-091d74958951@linaro.org> Signed-off-by: Rob Clark commit ed9ad3d4183053d4a8c43960a3d23ea8db71c30d Author: Neil Armstrong Date: Wed Sep 9 15:07:37 2026 +0200 drm/msm/a6xx: Add CX AO Counter registers used for a750 GPUs The a750 uses the CX AO Counters instead of the GMU_ALWAYS_ON_COUNTER register on A6xx and other A7xx GPUs. Signed-off-by: Neil Armstrong Patchwork: https://patchwork.freedesktop.org/patch/752234/ Message-ID: <20260909-topic-sm8650-gmu-a750-timestamp-reg-v2-1-091d74958951@linaro.org> Signed-off-by: Rob Clark commit 3163cd7253432f262c2fa22edb51474d7afc76a0 Author: George Emmanuel Thomas Date: Sat Aug 15 22:13:35 2026 +0530 drm/msm: remove stale perf counter XML TODO The adreno_perfcntrs macro already takes the XML file stem as its second argument, allowing each perf counter JSON file to select the appropriate register XML. The a2xx and a5xx entries already pass their respective XML file stems. Remove the stale TODO comment. Signed-off-by: George Emmanuel Thomas Patchwork: https://patchwork.freedesktop.org/patch/746745/ Message-ID: <20260815164335.158958-1-georgeemmanuelthomas@gmail.com> Signed-off-by: Rob Clark commit 327c428ba79b13e4cc5253333a9d5c0aa5579bdf Author: Hao Zhang Date: Sat Sep 12 00:04:57 2026 +0800 blk-cgroup: save IRQ state in blkg_tryget_closest() bio_set_dev() associates the bio with a blkg through bio_associate_blkg(). If the blkg lookup misses, blkg_tryget_closest() takes q->queue_lock with spin_lock_irq() and releases it with spin_unlock_irq(), which unconditionally enables local interrupts. Callers may call bio_set_dev() with interrupts already disabled, e.g. dm-thin's pool_map() does so while holding pool->lock taken with spin_lock_irq(). The nested spin_unlock_irq() then enables interrupts while pool->lock is still held, so an I/O completion softirq can run on the same CPU, re-acquire pool->lock (thin_endio(), or overwrite_endio() -> complete_mapping_preparation()) and deadlock. lockdep reports this as inconsistent SOFTIRQ-ON-W to IN-SOFTIRQ-W usage. Commit 3a762de55b4e ("block: save irq state in blkg_lookup_create()") fixed the same problem while the lock lived in blkg_lookup_create(), but commit 9327a865e395 ("blk-cgroup: don't nest queue_lock under rcu in blkg_lookup_create()") moved the locking into blkg_tryget_closest() and reverted it to spin_lock_irq(). Save and restore the caller's IRQ state instead. Fixes: 9327a865e395 ("blk-cgroup: don't nest queue_lock under rcu in blkg_lookup_create()") Cc: Ming Lei Signed-off-by: Hao Zhang Acked-by: Tejun Heo Link: https://patch.msgid.link/aqQmqb1k57PXj8Ef@192.168.1.215 Signed-off-by: Jens Axboe commit 815e07c8fe885a87751c2496a30ae0dcd4118210 Author: Sebastian Andrzej Siewior Date: Fri Sep 11 12:21:52 2026 +0200 ring-buffer: Acquire the lock with irqsave in rb_wake_up_waiters() rb_wake_up_waiters() is a irq_work callback which is initialized with init_irq_work(). As such it will be invoked in thread context on PREEMPT_RT. Invoking the callback in IRQ context on PREEMPT_RT is not an option due its usage of wake_up_all(). Since this callback may run in thread context, it needs to acquire ring_buffer_per_cpu::reader_lock with disabling interrupts and may not assume that they are disabled. Use raw_spinlock_irqsave() to acquire ring_buffer_per_cpu::reader_lock. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260911102152.YEtwkBj9@linutronix.de Fixes: 68282dd930ea3 ("ring-buffer: Fix resetting of shortest_full") Reviewed-by: Vincent Donnefort Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Steven Rostedt commit 23c240d9509e15f72e4112fc95f0160ab32ec430 Author: Jérémy Jean Date: Thu Sep 10 18:37:43 2026 +0000 smb: client: validate absolute native symlink targets before NT fixups With symlinkroot unset, an absolute target is copied without conversion to an NT drive path. Later code still assumes an NT prefix is present when modifying the target and calculating the print name length. For "/ab", this causes two failures: sym[5] and path[5] are written past their allocations, and plen -= 2 * poff subtracts an assumed 8-byte prefix from a 6-byte UTF-16 target, wrapping u16 plen to 65534. That underflow causes another overflow: memcpy() copies 65534 bytes into a 24-byte buffer. A user with write access to a mounted share can trigger these bugs with default settings. Validate the NT drive prefix, including an ASCII drive letter, before accessing fixed offsets or subtracting the prefix length. Fixes: 3363da82e02f ("smb: client: fix native SMB symlink traversal") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit ed0aff60f83a9bdc2f6556376ac79c96b3ce7e80 Author: Steven Rostedt Date: Thu Sep 10 22:12:09 2026 -0400 tracing: Take trace_array reference when opening a tracer options file 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 commit 7e645147dfba67edb3ed3090a1ed1d89df77fc27 Author: Karl Mehltretter Date: Wed Sep 9 08:29:17 2026 +0200 tracing: Fix ring_buffer_read_page_size() kernel-doc ring_buffer_read_page_size() takes a parameter named rpage, but its kernel-doc describes page. As a result, kernel-doc reports rpage as undescribed and page as an excess parameter description. Rename the documentation entry to match the function. Link: https://patch.msgid.link/20260909062917.89482-1-kmehltretter@gmail.com Fixes: dae8dda341d2 ("tracing: Fix subbuf resize races with trace_pipe_raw readers") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Vincent Donnefort Signed-off-by: Steven Rostedt commit 911002e99e15f640f1fdc6d276206beaef59e790 Author: Thomas Weißschuh Date: Tue Sep 8 08:22:15 2026 +0200 tracing: Restore :mod: trailer after parsing in ftrace_set_clr_event() While ftrace_set_clr_event() modifies its input buffer during parsing, before returning to the caller the buffer is supposed to be restored to its original state. This works correctly for the colon between the subsystem and event but not the colon at the beginning of :mod:. Restore the colon, so the :mod: trailer is not stripped after ftrace_set_clr_event(). Cc: stable@vger.kernel.org Fixes: 4c86bc531e60 ("tracing: Add :mod: command to enabled module events") Link: https://patch.msgid.link/20260908-tracing-cli-event-filter-v2-1-05396a3fb663@linutronix.de Signed-off-by: Thomas Weißschuh Signed-off-by: Steven Rostedt commit 7f711e62355bb3123a2ca2f97a2facbfebc678c6 Author: Donggeun Yoo Date: Tue Sep 8 00:50:45 2026 +0900 tracing: Fix memory corruption from a "STACKTRACE" histogram key "cpu", "CPU", "stacktrace" and "STACKTRACE" are generic fields, defined with an offset and a size of zero so that the filter code can match them by name. parse_field() maps them onto their common_* equivalents for backward compatibility, but unlike the common_* names it hands the placeholder back to the caller instead of NULL. create_hist_field() takes a non-NULL field as a promise that the record carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc word is read from offset 0, that is from common_type, and its low 16 bits are followed as an offset into the record. What is found there becomes the length of an unbounded memcpy. Pick an event whose id is small enough that the offset stays inside its own record and the length is a kernel text address: # cd /sys/kernel/tracing # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger # echo hello > trace_marker Oops: general protection fault, probably for non-canonical address RIP: 0010:rb_next+0x23/0x60 RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x2e7/0x12c0 Kernel panic - not syncing: Fatal exception in interrupt Leave the field NULL, which is what the comment above the branch says the code does and what common_stacktrace already does. FILTER_CPU and FILTER_COMM are left alone, their create_hist_field() branches never look at the field. Cc: stable@vger.kernel.org Fixes: 4b512860bdbd ("tracing: Rename stacktrace field to common_stacktrace") Link: https://patch.msgid.link/20260907155045.692664-3-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt commit a5e70ba87ca8ebc79b4e63de302d03b0625fe153 Author: Donggeun Yoo Date: Tue Sep 8 00:50:44 2026 +0900 tracing: Fix memory corruption from the histogram stacktrace modifier parse_field() sets HIST_FIELD_FL_STACKTRACE from the ".stacktrace" modifier before it looks the field name up, and nothing afterwards checks that the name resolved to a field which holds a stacktrace. create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the field pointer alone, which reads a __data_loc word from the record and follows its low 16 bits as an offset into the same record. event_hist_trigger() takes the first word there as an entry count and copies that many longs into a 31 entry array: n_entries = *stack; memcpy(entries, ++stack, n_entries * sizeof(unsigned long)); Neither end of that copy is bounded, and the count is whatever the event holds at the offset, so any field will do: # cd /sys/kernel/tracing/events/sched/sched_process_fork # echo 'hist:keys=parent_pid.stacktrace' > trigger # (true) BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:rb_insert_color+0x18/0x130 timerqueue_linked_add+0x7e/0xd0 enqueue_hrtimer+0x39/0xb0 __hrtimer_run_queues+0x10f/0x1f0 RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x165/0x690 The timer interrupt landed on the rbtree the copy had already run over. No debug options are needed for this; KASAN reports the same write as an out-of-bounds read of 13835058055416381440 bytes. Documentation/trace/histogram.rst already states the rule, "must be a long[] type", so enforce it once the name has been resolved. Names which resolve to no field at all, "hitcount.stacktrace" and the common_* pseudo-fields, are refused for the same reason: they hold no stacktrace to read. Cc: stable@vger.kernel.org Fixes: cc5fc8bfc961 ("tracing/histogram: Add stacktrace type") Link: https://patch.msgid.link/20260907155045.692664-2-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt commit 92383cef66791a0c63a2f27755cadbdb2fbf270b Author: Donggeun Yoo Date: Mon Sep 7 21:44:20 2026 +0900 tracing: Undo the registration when enabling the histogram trigger fails Commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list") described how a trigger that is registered but not on file->triggers ends up freed while still on the global named_triggers list, and moved the registration down so that hist_trigger_enable() follows it immediately. One path still gets there. hist_trigger_enable() adds the trigger and takes it straight back out when the event cannot be enabled: list_add_tail_rcu(&data->list, &file->triggers); update_cond_flag(file); if (trace_event_trigger_enable_disable(file, 1) < 0) { list_del_rcu(&data->list); update_cond_flag(file); ret--; } so the list walk in hist_unregister_trigger() matches nothing, test stays NULL, and the ->free() that would call del_named_trigger() is skipped. out_unreg falls through to out_free, which frees the trigger anyway: BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff8880091d3160 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0xa00 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 69: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Leave the trigger where hist_unregister_trigger() can find it and let that undo the registration, which is the only code that knows all of what cmd_ops->init() took: the named list entry, the hist_pad reference, the reference on the trigger a named histogram is shared with, and the copied cmd_ops. It also pairs the failed trace_event_trigger_enable_disable(), whose sm_ref and buffered event reference are otherwise left behind. Since ->free() releases trigger_data and, for a trigger that does not share its histogram, hist_data with it, out_unreg can no longer fall through to out_free. For a trigger that does share, hist_register_trigger() has already destroyed the caller's hist_data, so the fall-through was reading freed memory there as well. Move the enable_timestamps check in hist_unregister_trigger() above the ->free() call for the same reason: hist_data does not outlive it once the trigger being removed is the one that owns it. Cc: stable@vger.kernel.org Fixes: 067fe038e70f ("tracing: Add variable reference handling to hist triggers") Reported-by: Sashiko AI Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/ Link: https://patch.msgid.link/20260907124420.607097-3-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt commit 0fe23b8eaba0d3372c66b7b31204408da0715edc Author: Donggeun Yoo Date: Mon Sep 7 21:44:19 2026 +0900 tracing: Take the reference before publishing the named histogram trigger event_hist_trigger_named_init() puts the trigger on the global named_triggers list and only then takes the reference on the trigger it shares its histogram with: data->ref++; save_named_trigger(data->named_data->name, data); ret = event_hist_trigger_init(data->named_data); if (ret < 0) { kfree(data->cmd_ops); data->cmd_ops = &trigger_hist_cmd; } return ret; event_hist_trigger_init() fails when alloc_hist_pad() cannot allocate, and nothing takes the trigger back off the list on the way out. event_hist_trigger_parse() frees it, and the next lookup by name reads the freed object: BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff888009346860 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0xa00 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 67: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Do the reference first and publish once it has succeeded, so that nothing which can fail runs after the trigger becomes findable. Cc: stable@vger.kernel.org Fixes: 7ab0fc61ce73 ("tracing: Move histogram trigger variables from stack to per CPU structure") Reported-by: Sashiko AI Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/ Link: https://patch.msgid.link/20260907124420.607097-2-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Acked-by: Tom Zanussi Signed-off-by: Steven Rostedt commit 6ede78d0563a2a3ae3e46f9c07cedb5d79645429 Author: Donggeun Yoo Date: Mon Sep 7 18:14:15 2026 +0900 tracing: Set the trace clock before registering the histogram trigger hist_register_trigger() puts the trigger on the global named_triggers list in cmd_ops->init(), and only then sets the trace clock: if (data->cmd_ops->init) { ret = data->cmd_ops->init(data); if (ret < 0) goto out; } if (hist_data->enable_timestamps) { ret = tracing_set_clock(file->tr, hist_data->attrs->clock); if (ret) { hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock)); goto out; } The clock string is not checked anywhere before that call, so a named trigger using common_timestamp with an unknown clock fails after it has already become findable. event_hist_trigger_parse() then frees it without taking it off the list, and the next lookup by name reads the freed object: ~# cd /sys/kernel/tracing/events/sched/sched_switch ~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=foo:keys=common_pid' > trigger BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff88800915d760 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0x900 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 63: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Set the clock before the trigger is registered, so that nothing which can fail runs after it is published, the way commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list") moved the registration below the rest of the setup. tracing_set_filter_buffering() is reference counted, so the init failure path has to drop the reference that the clock block now takes first. Cc: stable@vger.kernel.org Fixes: a4072fe85ba3 ("tracing: Add a clock attribute for hist triggers") Link: https://patch.msgid.link/20260907091415.554535-1-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt commit 0999d3e16d13b6299fd7cc7a7fb2825c18e90dd0 Author: Hemanth Selam Date: Mon Sep 7 12:26:07 2026 +0530 tracing: Fix typo "preceeded" in comment Correct "preceeded" to "Preceded", reported by scripts/checkpatch.pl using the misspelling list in scripts/spelling.txt. Only touches comments, no code changes. Link: https://patch.msgid.link/20260907065607.36615-1-hemanth.selam@gmail.com Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam Signed-off-by: Steven Rostedt commit 89b000ba0796593aa61f6eec24d369337594588b Author: Hemanth Selam Date: Mon Sep 7 11:56:08 2026 +0530 tracing: Fix typo "availabe" in comment Correct "availabe" to "available", reported by scripts/checkpatch.pl using the misspelling list in scripts/spelling.txt. Only touches comments, no code changes. Link: https://patch.msgid.link/20260907062608.13924-1-hemanth.selam@gmail.com Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam Signed-off-by: Steven Rostedt commit 3d617bfd79330ae3acf94862c18bb3ccf5f5a0f9 Author: Donggeun Yoo Date: Mon Sep 7 14:21:13 2026 +0900 tracing: Let histogram values keep the percent and graph modifiers The .percent and .graph modifiers exist only for histogram values, but a value carrying either of them has been rejected since v6.3. The example in Documentation/trace/histogram.rst, # echo 'hist:keys=prev_comm:vals=hitcount.percent:nohitcount' > \ events/sched/sched_switch/trigger returns -EINVAL. parse_field() sets the two flags only when the field is neither a key nor a variable, that is, only on a value: } else if (strncmp(modifier, "percent", 7) == 0) { if (*flags & (HIST_FIELD_FL_VAR | HIST_FIELD_FL_KEY)) goto error; *flags |= HIST_FIELD_FL_PERCENT; __create_val_field() then rejects a value for carrying them, so no field can reach hist_trigger_print_val(), where both are implemented. commit e0213434fe3e ("tracing: Do not let histogram values have some modifiers") added the check after a value with .buckets oopsed in hist_field_name(). That happens because .buckets and .log2 make create_hist_field() build a nested field in operands[0] which hist_field_name() then walks into. The percent and graph flags do not create an operand and are not read by hist_field_name(); they are only used when printing a value. Stop rejecting the two flags on a value. The check for variables is left alone, where they are unreachable anyway because parse_field() rejects a variable carrying them first. With the two flags removed, the trigger above installs and prints as documented: { prev_comm: rcu_preempt } hitcount (%): 0.00 { prev_comm: init } hitcount (%): 99.98 Totals: Hits: 237896 Cc: stable@vger.kernel.org Fixes: e0213434fe3e ("tracing: Do not let histogram values have some modifiers") Link: https://patch.msgid.link/20260907052113.430818-1-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt commit 06f5634ec5584954177f9a22e36b3bfb398a971b Author: Donggeun Yoo Date: Mon Sep 7 15:03:23 2026 +0900 tracing: Keep the entry count when the histogram stats allocation fails print_entries() uses n_entries both as the number of sort entries and as its own return value, so the -ENOMEM it stores when the stats allocation fails overwrites the count that the cleanup still needs: n_entries = tracing_map_sort_entries(map, ...); if (n_entries < 0) return n_entries; ... if (!stats) { n_entries = -ENOMEM; goto out; } ... out: tracing_map_destroy_sort_entries(sort_entries, n_entries); tracing_map_destroy_sort_entries() takes an unsigned int and loops up to it, so -ENOMEM arrives as 4294967284. It walks an array of at most map->max_elts pointers and calls destroy_sort_entry(), which dereferences and frees, on whatever lies past the end. Reading the hist file of a trigger with a .percent value, with that allocation forced to fail: BUG: KASAN: vmalloc-out-of-bounds in tracing_map_destroy_sort_entries+0xa0/0xb0 Read of size 8 at addr ffffc90000045000 by task init/1 tracing_map_destroy_sort_entries+0xa0/0xb0 hist_show+0x6f7/0x1df0 seq_read_iter+0x2b8/0x1190 vfs_read+0x176/0xa40 The buggy address belongs to a 4-page vmalloc region starting at ffffc90000041000 allocated at tracing_map_sort_entries+0x5c/0xd50 A few pages further the fault is fatal. The registers at the oops confirm the bound: the loop's end pointer less the array start, over the pointer size, is 4294967284. Return the error in a separate variable and leave n_entries holding the count, the way tracing_map_sort_entries() does on its own error path. The stats block is only entered for a value carrying .percent or .graph, which __create_val_field() has rejected since v6.3, so this cannot be reached in mainline as it stands. It becomes reachable again with "tracing: hist: let values keep the percent and graph modifiers", so it should be applied first. Cc: stable@vger.kernel.org Fixes: abaa5258ce5e ("tracing: Add .percent suffix option to histogram values") Link: https://patch.msgid.link/20260907060323.480728-1-donggeunyoo.kernel@gmail.com Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260907053113.1CED91F00A3A@smtp.kernel.org/ Signed-off-by: Donggeun Yoo Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt commit 230234d12ce42ab04132a32c3a848f07a5d27a71 Author: Donggeun Yoo Date: Mon Sep 7 12:49:48 2026 +0900 tracing: Free histogram the field rejected for a bad modifier Writing a hist trigger whose value or variable carries a modifier that is not allowed there leaks the fields that were built for it. __create_val_field() takes the field from parse_expr() and stores it in hist_data->fields[] only after the modifier checks have run: hist_field = parse_expr(hist_data, file, field_str, flags, var_name, &n_subexprs); ... if (hist_field->flags & HIST_FIELD_FL_VAR) { if (hist_field->flags & (...)) goto err; } else { if (hist_field->flags & (...)) goto err; } hist_data->fields[val_idx] = hist_field; Both checks jump past that store, and the err label returns without freeing anything. The error unwinds to create_hist_data(), which calls destroy_hist_data() -> destroy_hist_fields(), and that reaches a field only by walking fields[]. A field that never got there is unreachable. commit e0213434fe3e ("tracing: Do not let histogram values have some modifiers") set ret to -EINVAL and fell through to the store, which left the field owned by fields[] and freed along with the rest of hist_data. Splitting the check into a value case and a variable case replaced that fall-through with a goto that skips it. With CONFIG_DEBUG_KMEMLEAK, 200 writes of # echo 'hist:keys=prev_pid:vals=next_pid.log2' > \ events/sched/sched_switch/trigger each correctly rejected with -EINVAL, leave 332 unreferenced objects (63744 bytes) reported at create_hist_field(); 200 install and remove cycles of a valid trigger leave none. A '.log2' field is two allocations, since create_hist_field() puts the plain field in operands[0] of the log2 field, and both are reported. Use destroy_hist_field() rather than __destroy_hist_field() so that operands[0] is freed as well. It returns early for HIST_FIELD_FL_VAR_REF, which is what an operand owned by hist_data->var_refs[] needs; the rejected field itself is never a var ref, because a var ref never carries a modifier flag. Cc: stable@vger.kernel.org Fixes: e30fbc618e97 ("tracing/histograms: Allow variables to have some modifiers") Link: https://patch.msgid.link/20260907034948.240387-1-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt commit 516001d53e6b2ea95a251ee2ef54a1a689a3fd58 Author: Donggeun Yoo Date: Sun Sep 6 22:33:52 2026 +0900 tracing: Free histogram the var ref when its initialization fails create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroy_hist_field(). init_var_ref() cannot free it either. The caller owns the field, so init_var_ref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave create_var_ref() passing freed memory to destroy_hist_field(), which reads its flags. Call __destroy_hist_field(), which frees the field without consulting the flag. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260906133352.3815019-1-donggeunyoo.kernel@gmail.com Fixes: 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt commit 4bddcb346a6cf4615ca77f69a589623b877ca267 Author: Donggeun Yoo Date: Sun Sep 6 21:40:25 2026 +0900 tracing: Free histogram var refs regardless of how often they are referenced Using the same variable three or more times in one hist trigger leaks the variable reference and its strings when the trigger is removed. commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") made a trigger's var_refs[] array the only owner of a var ref: destroy_hist_field() returns early for HIST_FIELD_FL_VAR_REF, so the field expressions never destroy one. One entry, freed once, no count needed. commit 8bcebc77e85f ("tracing: Fix histogram code when expression has same var as value") then made repeated references share one object and added a count of them. Only the increment side exists, since those expressions still return early and never drop a reference, so __destroy_hist_field() sees how many references were created rather than how many are left. It frees when the decremented count is 0 or 1, so two references work and three or more leak. Sharing kept one array entry per object, and create_var_ref() searches and appends within a single trigger, so nothing outside it holds the object. Removing a trigger whose variables are still referenced is already refused by check_var_refs() with -EBUSY. Drop the count and free unconditionally. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260906124025.3550596-1-donggeunyoo.kernel@gmail.com Fixes: 8bcebc77e85f ("tracing: Fix histogram code when expression has same var as value") Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt commit 0701995aaf8fc2281154db829ca85e231951e51d Author: Donggeun Yoo Date: Sun Sep 6 12:44:06 2026 +0900 function_graph: Use the saved entry's size when reprinting it When a graph entry does not fit in the trace_seq, print_graph_entry() saves it in the iterator's fgraph_data and reprints it on the next read. The entry has already been consumed from the ring buffer by then, so the copy is all that is left of it. The copy is sized with iter->ent_size, which no longer describes the saved entry but whatever entry the iterator has moved on to. The argument count is derived from the same field, so a 72 byte entry saved and then reprinted ahead of a 48 byte return entry loses its arguments. Record the size next to the failure flag, so that the two are always set together, and restore it before reprinting. Cc: stable@vger.kernel.org Fixes: ff5c9c576e75 ("ftrace: Add support for function argument to graph tracer") Link: https://patch.msgid.link/20260906034406.1335316-1-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt commit b22845487096247f5370c412376a472304627847 Author: Donggeun Yoo Date: Sun Sep 6 06:19:22 2026 +0900 fgraph: Remove unused FGRAPH_MAX_INDEX FGRAPH_MAX_INDEX has no user, and it expands to FGRAPH_INDEX_SIZE and FGRAPH_RET_INDEX, neither of which is defined anywhere in the tree. It was added in that form by commit 91c46b0aa917 ("function_graph: Implement fgraph_reserve_data() and fgraph_retrieve_data()"), which introduced the current data word layout under new names, so anything referencing it would have failed to build ever since. Remove it. Link: https://patch.msgid.link/20260905211922.1196366-1-donggeunyoo.kernel@gmail.com Signed-off-by: Donggeun Yoo Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt commit 08cacffeef8f64f1a222c93467ca84f24a46c953 Author: Jérémy Jean Date: Sat Aug 22 19:53:22 2026 +0000 ftrace: fork: Initialize function graph state before copy_exec_state() dup_task_struct() copies the parent's task_struct, including ret_stack. ftrace_graph_init_task() clears the copied function graph state, but it currently runs after copy_exec_state(). For non-CLONE_VM forks, copy_exec_state() allocates a new task_exec_state. If that allocation fails, copy_process() reaches bad_fork_free and free_task() calls ftrace_graph_exit_task(). Since the child still carries the parent's ret_stack pointer, the unwind frees the parent's active function graph return stack. The parent subsequently accesses freed memory from function_graph_enter_regs(). KASAN reports: [ 22.190920] ================================================================== [ 22.195899] BUG: KASAN: slab-use-after-free in function_graph_enter_regs+0xa76/0xb90 [ 22.200747] Write of size 8 at addr ff110000054dc0a8 by task repro/1 [ 22.205134] [ 22.210770] CPU: 0 UID: 0 PID: 1 Comm: repro Not tainted 7.2.0-07732-g9328b3b03bdc-dirty #3 PREEMPT(lazy) [ 22.212576] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 22.213750] Call Trace: [ 22.215271] [ 22.216242] ? ftrace_stub_direct_tramp+0x10/0x10 [ 22.217774] dump_stack_lvl+0x4e/0x70 [ 22.220531] print_report+0x157/0x4b4 [ 22.223202] ? fixup_red_left+0x9/0x30 [ 22.224407] ? complete_report_info+0x83/0x110 [ 22.226679] ? function_graph_enter_regs+0xa76/0xb90 [ 22.228084] kasan_report+0xce/0x100 [ 22.230109] ? function_graph_enter_regs+0xa76/0xb90 [ 22.232860] ? stack_trace_save+0x4/0xd0 [ 22.234156] function_graph_enter_regs+0xa76/0xb90 [ 22.236090] ? kasan_save_stack+0x30/0x50 [ 22.237752] ? __pfx_function_graph_enter_regs+0x10/0x10 [ 22.238694] ? ring_buffer_lock_reserve+0x345/0xf80 [ 22.239628] ? stack_trace_save+0x4/0xd0 [ 22.242121] ? stack_trace_save+0x4/0xd0 [ 22.243588] ftrace_graph_func+0xda/0x160 [ 22.245362] ? ftrace_stub_direct_tramp+0x10/0x10 [ 22.246520] 0xffffffffa0000095 [ 22.250528] ? stack_trace_save+0x9/0xd0 [ 22.251757] ? ring_buffer_unlock_commit+0x11d/0x5c0 [ 22.253152] stack_trace_save+0x9/0xd0 [ 22.254264] kasan_save_stack+0x30/0x50 [ 22.273631] kasan_save_track+0x14/0x30 [ 22.276763] kasan_save_free_info+0x3b/0x70 [ 22.278296] __kasan_slab_free+0x43/0x70 [ 22.280157] kmem_cache_free+0xbf/0x3b0 [ 22.282963] ? ftrace_stub_direct_tramp+0x10/0x10 [ 22.284001] free_task+0xa2/0x160 [ 22.285699] ? ftrace_stub_direct_tramp+0x10/0x10 [ 22.286752] copy_process+0x2aae/0x7bc0 Initialize the child function graph state immediately after dup_task_struct(), before the first fallible operation. Cc: stable@vger.kernel.org Fixes: 6b1c66c9cca9 ("exec_state: relocate dumpable information") Reviewed-by: Bradley Morgan Link: https://patch.msgid.link/20260822195321.962383-2-Jeremy.Jean@oss.cyber.gouv.fr Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Steven Rostedt commit 2deb753127d7b7035e893955c5e91875e767d1f8 Author: Henry Martin Date: Fri Sep 4 19:52:23 2026 +0800 tracing/user_events: Don't destroy fields when event removal fails destroy_user_event() destroys the event's fields before attempting to remove the trace event call. If user_event_set_call_visible() fails, e.g. because the event is still enabled and trace_remove_event_call() returns -EBUSY, the event is left registered with an irreversibly destroyed field list. Any subsequent interaction with the event then operates on an empty field list while it is still fully visible in tracefs. Move the field destruction after the call removal, and splice the field list back onto the event when the removal fails so the event remains in a consistent state. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260904115223.2976446-1-bsdhenrymartin@gmail.com Fixes: 7f5a08c79df35 ("user_events: Add minimal support for trace_event into ftrace") Signed-off-by: Henry Martin Reviewed-by: Beau Belgrave Signed-off-by: Steven Rostedt commit bbb9293c9bb792f3f16c842f223b8c97bdbaf227 Author: Lyude Paul Date: Fri Aug 14 15:43:51 2026 -0400 drm/nouveau/gsp: Increase delay for magic sleep in r535_gsp_fini() As it turns out, Turing isn't the only architecture that needs this. On this Dell Precision 7780 with an AD103 GPU, along with pretty much every other laptop I tested, runtime PM is still somewhat unreliable. At first glance it seems as if it's fixed, but lowering the autosuspend delay to 500ms and then doing a stress test of suspend/resume cycles on the GPU ends up causing everything to start timing out. After quite a lot of digging, I eventually landed back on this magic timeout in r535_gsp_fini(). As it turns out, increasing the timeout ends up fixing the runtime PM issues as far as I can tell, even during intense stress testing. Unfortunately after spending quite a bit of time trying to dig through OpenRM to figure out what this magic sleep is actually doing, I've also come up short with any reasonable explanation. In lieu of that, I'm going to include the observations I did make while trying to figure this out in hopes someone eventually does figure this out: * The magic sleep has to occur after fbsr is initialized. Performing it at any time before that doesn't appear to work. * In situations where runtime PM starts getting flaky, some rather interesting visual effects end up happening on occasion before the GPU fully falls over. In particular, squares that look like the result of an incomplete blitting operation to a tiled buffer end up showing up on applications like vkcube. Interestingly enough, they remain in precisely the same place between runtime PM cycles until the GPU falls over - even when restarting vkcube multiple times, and even when vkcube is actively updating the screen. Even more interestingly, they're not limited to a specific framebuffer - you can see the squares changing as the cube rotates around. We cannot however, say that this is likely to be a incomplete fbsr operation. The magic sleep happens before fbsr is actually saved (which happens on the GSP unload), so it's something else. * During a short bit of testing with a desktop that I have, the magic sleep seemed to make no difference to whether or not suspend/resume works. It seems to generally work almost always. So we can assume this is likely exclusive to runtime PM, not S3. As well, here's a list of the things I tried before settling on the magic sleep: * Hooking up NV2080_CTRL_CMD_INTERNAL_GCX_ENTRY_PREREQUISITE and then blocking runtime PM until OpenRM signals that GC6/GCOFF is ready appears to make no difference. * Hooking up some (maybe not all, unsure about that part) bits of comptag saving including: * Fetching static memsys information from GSP * Adding the size of the comptag storage to the fbsr data * Adding a GA103+ workaround for disabling raw compression mode during fbsr (it doesn't seem like it applies for any systems I tried it on anyhow) * Setting bPreserveVideoMemoryAllocations=1 in GspSystemInfo So, until we can figure this out properly - just sleep for longer. Signed-off-by: Lyude Paul Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144") Cc: # v6.16+ Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260814194542.781955-5-lyude@redhat.com (cherry picked from commit 09b47186a4164f3aaa3591313f80794443117342) Signed-off-by: Lyude Paul commit 24fbd6d4bcf3363ef13ebe0d36dea93f30396c6d Author: Lyude Paul Date: Fri Aug 14 15:43:50 2026 -0400 drm/nouveau/gsp/r570: Enable S/R Display workaround in GSP There's two flags that we've never been setting when asking GSP to suspend the GPU, which OpenRM does set: GPU_STATE_FLAGS_PRESERVING GPU_STATE_FLAGS_PM_TRANSITION These flags aren't -supposed- to do much in GSP, they're mostly used by OpenRM itself for state tracking. The only thing they do from GSP's side is control whether or not a single display related workaround is applied during suspend. But as it turns out, that single workaround is actually quite crucial for getting runtime PM working with nouveau - and without it set we end up seeing a lot more failures with runtime PM resume. So, let's start setting it. Signed-off-by: Lyude Paul Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144") Cc: # v6.16+ Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260814194542.781955-4-lyude@redhat.com (cherry picked from commit ca57629b3eb912c77bc4357178a2130ea6c2d6df) Signed-off-by: Lyude Paul commit 12f6eff11ccf9cad3b2dfcdd94184fdb9ffface2 Author: Lyude Paul Date: Fri Aug 14 15:43:49 2026 -0400 drm/nouveau/gsp/r570: Set GcOff = 0 in fbsr Previously, it looked as if we were able to fix suspend/resume on some desktops by setting Gcoff based on whether or not we were entering runtime PM. This was a mistake though - the only time suspend/resume would end up actually working was if Gcoff = 0. It seems like it's likely the main reason for this is the FBSR GcOff argument actually controls GSP's behavior with regards to which buffers it decides to save across suspend/resume. When GcOff = 1, RM reserved regions are saved unless they are marked as LOST_ON_SUSPEND, and RM channel-context and kernel-client buffers are also saved -including- when they are LOST_ON_SUSPEND. This means with GcOff = 1, we end up having GSP save and restore buffers that actually need to be reinitialized on resume - causing the failures we're setting. Thanks to John Hubbard from Nvidia for providing some background on what these options do in the GSP firmware do! Signed-off-by: Lyude Paul Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144") Cc: # v6.16+ Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260814194542.781955-3-lyude@redhat.com (cherry picked from commit c7abe771e013848970421e5ca29c6b2f05c31965) Signed-off-by: Lyude Paul commit a5c41fa7f925fda2db394329fa0b26243fa63a81 Author: Lyude Paul Date: Fri Aug 14 15:43:48 2026 -0400 Revert "nouveau/gsp: fix suspend/resume regression on r570 firmware" This reverts commit 8302d0afeaec0bc57d951dd085e0cffe997d4d18. It turns out this looked like the right fix on some systems, but it's not - as this causes runtime PM to actually fail on many a laptop. Fixes: 8302d0afeaec ("nouveau/gsp: fix suspend/resume regression on r570 firmware") Cc: # v6.19+ Signed-off-by: Lyude Paul Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260814194542.781955-2-lyude@redhat.com (cherry picked from commit 94097122bfd701976bc1a62ccd434c13f3f67cde) Signed-off-by: Lyude Paul commit 576da3462c991923ee4aed4bcc22d94531beb0dd Merge: d5d6c9d244c6d4 e10f2b7e28be3e Author: Linus Torvalds Date: Fri Sep 11 10:00:07 2026 -0700 Merge tag 'sound-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of device-specific small fixes. At this time, the majority of changes are about ASoC while we have usual suspects like HD- and USB-audio quirks. Some highlights below. ASoC Intel / SoundWire: - Fix bus and stream resource leaks at error path in avs and hda-ext - More fixes and refactoring in avs for constraining MSBs, async handling D0ix - Add support for TAC5xx2 SoundWire family and NVL MAX98360A RT5682 machines - Fix uninitialized stream configurations in Realtek SoundWire codecs - Adjust latency control to fix no-sound issue on RT721-SDCA ASoC AMD: - Avoid binding for the acp-da7219-max98357a machine driver - Add quirks for Acer Nitro AN17-41 and HP 255R G10 - Fix memory leaks in ACP6x ASoC Codecs & Platforms: - Fixes for cs35l56 to avoid deadlock, kexec race, and runtime PM imbalances - Split stereo streams across mono amps on tas2783-sdw - Fix pop noise on es8326 and enable_count underflow on es8389 - Various fixes for fsl_micfil, sprd, sti, and publish OF module aliases - Fixes & cleanups for Ux500 (MSP/I2S) and AB8500 codecs HD-audio: - Fix for channel status notification changes - Quirks for HP laptops USB-audio: - Fix embedded URBs in caiaq, 6fire, hiface, and ua101 drivers - More hardening in usx2y and us122l drivers - Quirks for Behringer devices Misc: - Add PCI ID for RME HDSPe AIO PCI Express audio card in hdspm - Fix S/PDIF passthrough on CA20K2 in ctxfi" * tag 'sound-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (65 commits) ALSA: hdspm: Add a new PCI device ID (1d18:3fc6) for RME HDSPe AIO PCI express audio ASoC: amd: acp-da7219-max98357a: don't bind on Raven/Picasso boards ALSA: hda: Report a change when only the channel status bytes move ALSA: us122l: Prevent write upgrades for read mappings ALSA: hda/realtek: Add quirk for HP Elite Dragonfly Max G2 speaker ASoC: cs35l56: Fix race between kexec and snd_soc_register_component() ASoC: amd: yc: add quirk for Acer Nitro AN17-41 internal mic ASoC: mt6351: Publish the OF module alias ASoC: Intel: SST: Publish the PCI module aliases ASoC: bcm: bcm63xx: Publish the OF module aliases ALSA: usb-audio: Add quirk flags for Behringer UV1 ALSA: usb-audio: Add boot quirk for Behringer CM1A ALSA: hda/realtek: Add quirk for HP Omen 16-wd0xxx mute LED ALSA: usbusx2y: validate URB actual_length in interrupt callback ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough ALSA: usb: 6fire: Avoid embedded URBs ALSA: usb: hiface: Avoid embedded URBs ALSA: usb: ua101: Avoid embedded URBs ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev ... commit 8e2a4b458ad25e13422bb059758c30a6562aa9cf Author: Oscar Priego Verdugo Date: Mon Aug 17 06:05:46 2026 -0600 HID: elecom: fix bus type for M-XGL20DLBK The M-XGL20DLBK is matched as a USB device by hid-elecom, but its entry in hid_have_special_driver[] uses HID_BLUETOOTH_DEVICE. This prevents the special-driver quirk entry from matching the USB device handled by hid-elecom. Use HID_USB_DEVICE there as well. Fixes: 55633e681afb ("HID: elecom: add support for EX-G M-XGL20DLBK wireless mouse") Signed-off-by: Oscar Priego Verdugo Signed-off-by: Jiri Kosina commit d5d6c9d244c6d447c356df70d5c754b145dccd5c Merge: 08df884136f1c1 37bef2170d4c88 Author: Linus Torvalds Date: Fri Sep 11 09:49:40 2026 -0700 Merge tag 'media/v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media fixes from Mauro Carvalho Chehab: "Core: - add bounded tile-count helpers for HEVC stateless decoders - validate AV1 tile counts fits in array size - validate HEVC tile counts fits in array size - fix memcmp() size in B1 reference list comparison mediatek: - bound AV1 tile-start copy to fit in array size rockchip: - reject AV1 frames exceeding the tile size - guard VPU981 AV1 divisor and tile buffer hantro and rkvdec: - bound G2 HEVC tile loops and PPS id to the buffer size rppx1: - read the raw pattern from the PRE2 acquisition module - describe the MAIN_POST white balance gains block" * tag 'media/v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: media: mediatek: vcodec: bound AV1 tile-start copy to the array capacity media: verisilicon: rockchip: reject AV1 frames exceeding the tile capacity media: verisilicon: rockchip: guard VPU981 AV1 divisor and tile buffer media: verisilicon: hantro: bound G2 HEVC tile loop to the buffer capacity media: rkvdec: bound HEVC tile loops and PPS id to the array capacity media: hevc: add bounded tile-count helpers media: v4l2-ctrls: validate AV1 tile counts media: v4l2-ctrls: validate HEVC tile counts media: v4l2-h264: Fix memcmp() size in B1 reference list comparison media: rppx1: bls: read the raw pattern from the PRE2 acquisition module media: rppx1: describe the MAIN_POST white balance gains block commit f3c2b266b8fd7cf816d36168d19f67e716f2c080 Author: Berke Durak Date: Mon Sep 7 11:47:19 2026 -0700 HID: elecom: Add support for ELECOM M-XT4DRBK (018E) The 2025 revision of the left-handed EX-G wireless trackball (M-XT4DRBK-G) reports USB ID 056e:018e instead of 056e:00fd. Its report descriptor declares an 8-bit button field (Report Count 8) but only five usages (Usage Maximum 5), so the sixth (Fn) button ends up as a duplicate of button 5 and is unusable. The report descriptor has the same layout as the M-XT3DRBK 018C (button usage maximum at offset 16, button report count at 22, button report size at 24, padding report size at 30), so reuse that fixup. Rename the existing M_XT4DRBK define to M_XT4DRBK_00FD to match the convention used for the other EX-G revisions. Tested on a Raspberry Pi 5 with the same fixup in an out-of-tree module on 6.12 (6.12.96+rpt-rpi-2712); all six buttons are reported after the fix, and they work (tested with xev as well). Report descriptor as sent by the device, pre-fix (056e:018e, 215 bytes): 05 01 09 02 A1 01 09 01 A1 00 85 01 05 09 19 01 29 05 15 00 25 01 95 08 75 01 81 02 95 01 75 00 81 01 05 01 09 30 09 31 16 00 80 26 FF 7F 75 10 95 02 81 06 C0 A1 00 05 01 09 38 15 81 25 7F 75 08 95 01 81 06 C0 A1 00 05 0C 0A 38 02 95 01 75 08 15 81 25 7F 81 06 C0 C0 06 01 FF 09 00 A1 01 85 02 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0 05 0C 09 01 A1 01 85 05 15 00 26 3C 02 19 00 2A 3C 02 75 10 95 01 81 00 C0 05 01 09 80 A1 01 85 03 19 81 29 83 15 00 25 01 95 03 75 01 81 02 95 01 75 05 81 01 C0 06 BC FF 09 88 A1 01 85 04 95 01 75 08 15 00 26 FF 00 19 00 2A FF 00 81 00 C0 06 02 FF 09 02 A1 01 85 06 09 02 15 00 26 FF 00 75 08 95 07 B1 02 C0 Assisted-by: LLM Signed-off-by: Berke Durak Signed-off-by: Jiri Kosina commit 1d00442cc4699accfaa2317fb18259ddd7556f9a Author: Stuart Hayhurst Date: Tue Aug 18 14:00:53 2026 +0100 HID: corsair-void: Fix firmware event packet description The size was incorrectly stated as 4 bytes since the ID was missed out. Add the ID in and correct the indices for the firmware versions. Signed-off-by: Stuart Hayhurst Signed-off-by: Jiri Kosina commit 58d97b45f3f43af0afd9c74e8480d22d36fd3f72 Author: Youth Cao Date: Fri Sep 4 00:14:44 2026 +0800 HID: i2c-hid: Add i2c-hid-quirk-bad-input-size quirk for 0911:5288 device I have recently acquired a cheap Apollo Lake-based laptop that uses a Hynitron CST128-A touchpad controller. While booting from a Debian LiveCD, the kernel log is flooded with the following error (though the touchpad works well): i2c_hid_acpi i2c-ALPS0001:00: i2c_hid_get_input: incomplete report (27/42405) The CST128-A was identified via ACPI as ALPS0001:00, and the I2C HID device ID (0911:5288) was shared with the Hantick 5288. Add the I2C_HID_QUIRK_BAD_INPUT_SIZE quirk option to the existing Hantick 5288 quirk entry to suppress the kernel log flood. Signed-off-by: Youth Cao Signed-off-by: Jiri Kosina commit abd24922c2a9797d6184be0561dd85e7bcdfd091 Author: Tristan Madani Date: Fri Sep 4 10:58:00 2026 +0000 HID: hid-oxp: use cancel_delayed_work_sync() in remove oxp_hid_remove() uses cancel_delayed_work() for all three delayed work items. cancel_delayed_work() only dequeues a pending work item without waiting for a currently executing callback to finish. If any of the work callbacks (oxp_rgb_queue_fn, oxp_btn_queue_fn, oxp_mcu_init_fn) is running at the time of removal, the callback continues executing concurrently with hid_hw_close() and hid_hw_stop(), accessing the HID device after it has been closed and stopped. Use cancel_delayed_work_sync() instead to ensure that any in-progress work callback completes before device teardown proceeds. Fixes: 84910c459d65 ("HID: hid-oxp: Add OneXPlayer configuration driver") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Reviewed-by: Derek J. Clark Link: https://lore.kernel.org/r/20260804-oxp-fix-v2-1-b2d56e4c8a2c@cherr.cc Link: https://lore.kernel.org/r/20260804-oxp-fix-v1-1-51a4fe787167@cherr.cc Signed-off-by: Jiri Kosina commit 39e8e085710a2d36d9ceade11739fb7b87f5aeb0 Author: Oleg Keri Date: Thu Sep 10 08:30:50 2026 +0200 HID: i2c-hid: add reset quirk for Lenovo Yoga Slim 7x Gen 11 keyboard The ITE controller behind the keyboard of the Lenovo Yoga Slim 7x Gen 11 (048d:83db) carries out a reset but never raises the interrupt that acknowledges it. i2c_hid_finish_hwreset() therefore waits out its full one second timeout and logs "device did not ack reset within 1000 ms" on every probe and every resume, before the keyboard comes up regardless. Set I2C_HID_QUIRK_NO_IRQ_AFTER_RESET for it, as is already done for several other ITE parts, so the reset is followed by a fixed 100 ms sleep instead. Signed-off-by: Oleg Keri Signed-off-by: Jiri Kosina commit d76994443eed0af297cb82bd038ae9d76327ef90 Author: Dmitry Antipov Date: Wed Sep 2 12:45:49 2026 +0300 HID: roccat: fix locking in roccat_connect() and roccat_disconnect() Extend critical section in roccat_connect() to ensure that partially initialized 'struct roccat_device' is never exposed in 'devices' list, and do the same in roccat_disconnect() to avoid racy 'devices' access against roccat_release(). Signed-off-by: Dmitry Antipov Signed-off-by: Jiri Kosina commit b63c3c26726576e2a87baeee80bc202a5a43c9e5 Author: Vasant Hegde Date: Fri Sep 11 08:33:53 2026 +0000 iommu/amd: Remove unused macro Remove unsed device range capability related macros. No functional changes. Signed-off-by: Vasant Hegde Signed-off-by: Joerg Roedel commit 80a4e3ad8daba66915a9bdf0fcae5831cc8dbd5f Author: Vasant Hegde Date: Fri Sep 11 08:33:52 2026 +0000 iommu/amd: Remove redundant checks from interrupt handler path PPR and GAlog interrupt is enabled only if buffer is allocated. (See amd_iommu_enable_ppr_log() and iommu_ga_log_enable()). The duplicate check in interrupt hanlder path is unnecessary and can be removed. No functional changes. Signed-off-by: Vasant Hegde Signed-off-by: Joerg Roedel commit 5e1afd4ea1d6a9bbaecf3e28707dac9c8b56bd45 Author: Vasant Hegde Date: Fri Sep 11 08:33:51 2026 +0000 iommu/amd: Remove redundant check in irq_remapping_select() The amd_iommu_irq_remap flag is already validated during irq remapping domain creation (before calling amd_iommu_create_irq_domain()). The duplicate check in irq_remapping_select() is unnecessary and can be removed. Additionally, mark amd_iommu_irq_remap as static. No functional changes. Signed-off-by: Vasant Hegde Signed-off-by: Joerg Roedel commit 798514a25544d6978d0bd7fe7071c9bdb5503076 Author: Vasant Hegde Date: Fri Sep 11 08:33:50 2026 +0000 iommu/amd: Make iommu_sva_set_dev_pasid as static Its used inside pasid.c only. No functional changes. Signed-off-by: Vasant Hegde Signed-off-by: Joerg Roedel commit 7e749a7972829a53fd1e41568cf2018c180627d1 Author: Erik Håkansson Date: Tue Sep 1 22:30:44 2026 +0200 HID: steelseries: Add support for Arctis 7 (2018) The headset reports connection and battery status on HID interface 5. When the device is disconnected, ignore incoming battery reports as they will incorrectly report battery level 0. Clamp overreported battery values to 100% and add USB ID 1038:12ad to the driver's device tables. Signed-off-by: Erik Håkansson Signed-off-by: Jiri Kosina commit fce551616dfa4523c15fe50c27aa3baf8afda955 Author: Andres Diaz Date: Mon Aug 31 23:01:47 2026 -0600 HID: logitech-hidpp: Add support for G502 X Lightspeed USB mouse The G502 X Lightspeed enumerates as 046d:c098 when connected with its cable. Add the id so the driver handles the wired device. Signed-off-by: Andres Diaz Signed-off-by: Jiri Kosina commit d5ea0d226e8f0801d78702142a124d78c317d822 Author: Runyu Xiao Date: Wed Sep 2 22:09:26 2026 +0800 mmc: sh_mmcif: initialize IRQ-thread mutex before requesting interrupt The threaded IRQ handler can run before devm_request_threaded_irq() returns, but thread_lock was initialized afterwards. Initialize it before requesting either interrupt. Fixes: 8047310ee984 ("mmc: sh_mmcif: fix a race, causing an Oops on SMP") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Signed-off-by: Ulf Hansson commit 31fe2cb51133f00e1138c617fef8ee808a37714d Author: Julia Lawall Date: Thu Aug 27 13:29:49 2026 +0200 HID: fix semantic patch and improve its performance Replace "expression" with "identifier" in the declaration of hdev. This is necessary because hdev is used as the name of a function parameter. Move the two uses of @p2 to the relevant function names. Convert <... ...>, meaning that the contained pattern is optional, to use ..., when any, and exists. This requires that the function contain calls to hid_hw_start, etc, which reduces the set of files that are considered for matching against this pattern. Reported-by: Ricardo Ribalda Signed-off-by: Julia Lawall Signed-off-by: Jiri Kosina commit 2f271b812170d4cad578bae1f91db72f3c2e36e7 Author: Julian Sun Date: Tue Sep 8 11:35:18 2026 +0800 nvmet: preserve device path on allocation failure nvmet_ns_device_path_store() frees the old path before allocating its replacement, losing the existing configuration if allocation fails. Allocate the new path before freeing the old one. Fixes: a07b4970f464 ("nvmet: add a generic NVMe target") Signed-off-by: Julian Sun Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch commit 62b70e6c87121ae5b79ca20c3a5b005590336ec5 Author: Maurizio Lombardi Date: Tue Sep 8 16:34:34 2026 +0200 nvme-fc: do not warn on controller removal race In nvme_fc_reconnect_or_delete(), the system attempts to remove the controller when reconnect limits are reached by calling nvme_delete_ctrl(). This call is currently wrapped in a WARN_ON(). If a user concurrently deletes the controller via sysfs, the controller's state may have already transitioned out of the CONNECTING state. When this happens, nvme_delete_ctrl() correctly rejects the operation and returns -EBUSY. Because of the WARN_ON() wrapper, this race condition triggers an unnecessary kernel warning stack trace. Remove the WARN_ON() macro around nvme_delete_ctrl(); this allows the system to safely ignore the -EBUSY return value if the controller is already being deleted. Signed-off-by: Maurizio Lombardi Reviewed-by: Daniel Wagner Signed-off-by: Keith Busch commit c72f9f7bd23c91e944910d9bcbf12503d21a4a1f Author: Bean Huo Date: Fri Sep 4 12:51:55 2026 +0200 nvme-pci: add NVME_QUIRK_DMAPOOL_ALIGN_512 for Micron 4100AT The Micron 4100AT fetches PRP Lists in 512 byte strides, but the driver allocates small PRP List descriptors in 256 byte strides. A descriptor in the last 256 bytes of a dmapool page makes the controller read past the page: the access lands on an adjacent IOVA, the IOMMU faults the command. That last block only became reachable with commit da9619a30e73 ("dmapool: link blocks across pages"), so this affects v6.4 and later. Align the small descriptor pool to 512 bytes, as commit ebefac564796 ("nvme-pci: 512 byte aligned dma pool segment quirk") already does for another controller with the same erratum. The last block then starts at offset 0xE00 and the fetch stays inside the page. Cc: # 6.4.x: ebefac564796: nvme-pci: 512 byte aligned dma pool segment quirk Cc: # 6.4.x Signed-off-by: Gaurav Sinha Signed-off-by: Bean Huo Signed-off-by: Keith Busch commit d3aba3442798ce4a4c8ce3104d7b286d61e605f9 Author: Chen Changcheng Date: Fri Aug 14 15:06:21 2026 +0800 HID: alps: fix use-after-free on input2 registration failure alps_input_configured() stores data->input2 before calling input_register_device(). If registration fails, input_free_device() frees the input device but data->input2 still points to the freed memory. alps_input_configured() calls hid_hw_open() before allocating input2, so URBs are already active and raw_event can fire during the failure window. A U1_SP_ABSOLUTE_REPORT_ID report arriving then causes u1_raw_event() to dereference the freed data->input2 -> use-after-free. Fix by only storing input2 into drvdata after successful registration and adding a NULL guard in the raw_event path. Fixes: 2562756dde55 ("HID: add Alps I2C HID Touchpad-Stick support") Cc: stable@vger.kernel.org Signed-off-by: Chen Changcheng Signed-off-by: Jiri Kosina commit aa9dde93e05a837645fdfd577eea71f0733f0694 Author: Chen Changcheng Date: Fri Aug 14 15:06:20 2026 +0800 HID: alps: unregister DualPoint Stick input device on remove alps_input_configured() allocates a second input device ("DualPoint Stick") with input_allocate_device() and registers it, but the alps_driver struct has no .remove handler and input2 is not tracked in hdev->inputs. The default remove path (hid_hw_stop -> hidinput_disconnect) only iterates hdev->inputs, so input2 is never unregistered and leaks on every device removal. Add a .remove handler that stops the device first (preventing URB callbacks from touching input2 during teardown) and then unregisters input2. Fixes: 2562756dde55 ("HID: add Alps I2C HID Touchpad-Stick support") Cc: stable@vger.kernel.org Signed-off-by: Chen Changcheng Signed-off-by: Jiri Kosina commit a1a5ad37e50ceb192c07ac7e2d7143638cd4d110 Author: René Onier Date: Wed Aug 12 13:13:59 2026 -0400 HID: winwing: fix use-after-free in force feedback teardown winwing_init_ff() passes the driver's private data, allocated with devm_kzalloc() in winwing_probe(), as the effect context to input_ff_create_memless(). The memoryless force-feedback core takes ownership of that pointer and frees it with kfree() from input_ff_destroy() (ml_ff_destroy()) when the input device is destroyed. Freeing a devm-managed allocation with kfree() is an invalid free, and the same object is then released again by devres when the HID device is torn down, a double free. As the allocation also embeds the LED class devices, their timers and work item live on freed memory and the slab gets corrupted. This triggers on unbind, rmmod, hot-unplug and on system suspend, where the firmware cache walks the now-corrupt devres list. KASAN reports: BUG: KASAN: invalid-free in input_ff_destroy Allocated by task N: winwing_probe Pass NULL as the memless context instead and fetch the driver data from the input device in winwing_play_effect(): the HID core already stores the hid_device as the input device's drvdata. The force-feedback core then owns nothing that it must not free. Fixes: 42d020b54edc ("HID: winwing: Enable rumble effects") Signed-off-by: René Onier Signed-off-by: Jiri Kosina commit 9eb1a393c89a79c4210230d23e7d88d239c61d7b Author: Thadeu Lima de Souza Cascardo Date: Wed Aug 26 08:46:58 2026 -0300 drm: Fix drm_pending_vblank_event leak in error path for out_fence_ptr When an out_fence_ptr is provided but DRM_MODE_PAGE_FLIP_EVENT is not set, a drm_pending_vblank_event will be allocated. If later, there is an allocation failure or another failure at setup_out_fence(), that event will not have base.fence set and it will not be released at complete_signaling(). Release the event and set crtc_state->event to NULL just like in the DRM_MODE_PAGE_FLIP_EVENT case when there is a failure at drm_event_reserve_init(). That is, prepare_signaling() releases the event and there is nothing to be done at complete_signaling(). Use drm_event_cancel_free() as that will also undo drm_event_reserve_init() in case it has been called. Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260727-drm_crtc_atomic_commit_leak-v1-1-23d9948a9d7c@igalia.com?part=1 Fixes: 92c715fca907 ("drm/atomic: Fix double free in drm_atomic_state_default_clear") Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260826-drm_pending_vblank_event_leak-v4-1-f8de8b996b9d@igalia.com commit aaaea79efba5a27cb9e0a5a628046d829d3f2cbb Author: Lovekesh Solanki Date: Wed Aug 5 01:50:31 2026 +0530 HID: multitouch: Add report ID mismatch quirk for ASUS ROG Z13 Folio Commit e716edafedad ("HID: multitouch: Check to ensure report responses match the request") introduced validating GET_FEATURE responses return the requested report ID. ASUS ROG Z13 Flow (2025) GZ302EA touchpad (USB 0b05:1a30) returns a different report ID for Win8 feature request. Before this check, the response was still processed and allowed device to switch into its full Touchpad Precision mode. After the validation, the response is discarded before hid_report_raw_event() processes it and device remains in fallback mode and no longer exposes ABS_MT_SLOT, ABS_MT_TOOL_TYPE or the multi-finger BTN_TOOL_* capabilities for palm rejection. Add a device quirk to allow the known firmware behavior for this device while preserving report ID validation for all other devices. The device previously matched the generic MT_CLS_WIN_8 entry, so base the new class on MT_CLS_WIN_8 to keep it on the same quirk set as before the regression. MT_QUIRK_CONFIDENCE must be set explicitly: it is normally enabled by the class name check in mt_touch_input_mapping(), which only matches the MT_CLS_WIN_8* names, and it is what makes ABS_MT_TOOL_TYPE available for touchpads. Fixes: e716edafedad ("HID: multitouch: Check to ensure report responses match the request") Signed-off-by: Lovekesh Solanki Reported-by: mayhemandcoffee Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221774 Tested-by: mayhemandcoffee Link: https://bugzilla.kernel.org/show_bug.cgi?id=221774 Signed-off-by: Jiri Kosina commit 7812d6dab0698001e50e8c2f901e17da3eb6f429 Author: Masami Hiramatsu (Google) Date: Fri Sep 11 00:15:34 2026 +0900 bootconfig: Fix integer overflow in initrd size check Sashiko reported that in get_boot_config_from_initrd(), a crafted initrd with a huge bootconfig size (such as 0xFFFFFFFF) can cause the pointer arithmetic: data = ((void *)hdr) - size; to wrap around on 32-bit systems (or when pointer subtraction overflows). Because data wraps around, the subsequent bounds check: if ((unsigned long)data < initrd_start) evaluates to false, bypassing the check. The kernel then calls xbc_calc_checksum(data, size), which attempts to read 4GB of memory, hitting unmapped pages and triggering a fatal kernel page fault during early boot. Furthermore, on 64-bit systems with an initrd > 4.29 GB, an unbounded 32-bit size can similarly bypass the initrd_start check. Fix this by: 1. Ensuring the initrd is at least large enough to contain the bootconfig footer and verifying hdr is within the initrd bounds. 2. Checking that size does not exceed XBC_DATA_MAX and does not exceed the available space between initrd_start and hdr before performing pointer subtraction. Link: https://lore.kernel.org/all/178905333479.213925.1358412668943562406.stgit@devnote2/ Fixes: de462e5f1071 ("bootconfig: Fix to remove bootconfig data from initrd while boot") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260910010137.EE0431F000FF@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.8-flash Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Sang-Heon Jeon commit 462d0b066b613103f579793031429db2ca23abc0 Author: Masami Hiramatsu (Google) Date: Fri Sep 11 00:15:24 2026 +0900 tools/bootconfig: Fix integer overflow and truncation in size checks Sashiko reported that on 32-bit systems, if an attacker crafts size in the bootconfig footer such that adding BOOTCONFIG_FOOTER_SIZE wraps around (for instance, if size is 0xFFFFFFFF), the size check in load_xbc_from_initrd() can be bypassed: if (stat.st_size < size + BOOTCONFIG_FOOTER_SIZE) { pr_err("bootconfig size is too big\n"); return -E2BIG; } Furthermore, on 64-bit systems with an initrd > 4.29 GB, comparing a corrupted 32-bit size (e.g. 0xFFFFFFFF) against stat.st_size - BOOTCONFIG_FOOTER_SIZE can also bypass the check if size is not bounded. Similarly, load_xbc_file() passes 64-bit stat.st_size directly into the 32-bit int size parameter of load_xbc_fd(), truncating large standalone files (>= 2GB). In both cases, passing 0xFFFFFFFF to load_xbc_fd() truncates to -1, resulting in malloc(0), an integer overflow in read(), and an out-of-bounds null-byte write. Fix this by: 1. Rejecting size > XBC_DATA_MAX or size > stat.st_size - BOOTCONFIG_FOOTER_SIZE in load_xbc_from_initrd(). 2. Rejecting stat.st_size > XBC_DATA_MAX in load_xbc_file() before passing it to load_xbc_fd(). 3. Checking size < 0 || size > XBC_DATA_MAX defensively in load_xbc_fd(). Link: https://lore.kernel.org/all/178905332413.213925.3179977110281463499.stgit@devnote2/ Fixes: 950313ebf79c ("tools: bootconfig: Add bootconfig command") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260909161113.16C691F00A3A@smtp.kernel.org/ Closes: https://lore.kernel.org/all/20260910010137.EE0431F000FF@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.8-flash Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Sang-Heon Jeon commit 9aa237cf66495b2426ddde8532e9b08a0ed83aaa Author: Wei Jie LAW <98lawweijie@gmail.com> Date: Wed Sep 9 09:15:13 2026 +0800 HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce() The 'wacom_wac_pen_serial_enforce()' function may calculate and pass an invalid offset to hid_field_extract(), resulting in memory reads at incorrect addresses -- possibly beyond the end of the report. If a field in the HID descriptor lists more usages than its Report Count actually reserves space for, the function's inner 'j' will walk past the end of the field: for (i = 0; i < report->maxfield; i++) { for (j = 0; j < report->field[i]->maxusage; j++) { ... value = hid_field_extract(hdev, raw_data + 1, offset + j * size, size); A descriptor listing 12288 usages against Report Count 1 has the loop extract the usage at index 12287 from bit offset 98296 -- about 12 KB past a 2-byte received report. The value is stored in wacom_wac->serial[0] and can reach userspace as an MSC_SERIAL event, making this an information disclosure. Clamp the loop to field->report_count, the number of value slots the report holds. Value slots past the last declared usage are still scanned; they reuse that usage (HID 1.11, 6.2.2.8). Verified on v6.12.105 with a UHID reproducer: a 2-byte report from such a descriptor trips KASAN before the patch and not after it. Fixes: 83417206427b ("HID: wacom: Queue events with missing type/serial data for later processing") Suggested-by: Jason Gerecke Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Assisted-by: GLM:glm-5.3 Signed-off-by: Wei Jie Law <98lawweijie@gmail.com> Reviewed-by: Jason Gerecke Signed-off-by: Jiri Kosina commit fdb9ebc7fb7788b8371fbef6c17dc5c8291e1429 Author: Catalin Marinas Date: Mon Sep 7 12:30:25 2026 +0100 arm64: mte: Fix PTRACE_{PEEK,POKE}MTETAGS error documentation PTRACE_{PEEK,POKE}MTETAGS return -EIO rather than -EOPNOTSUPP (as documented) when no tags are copied from/to a mapping without PROT_MTE. This has been the behaviour since the interface was introduced, though the original intent was to distinguish between address not being accessible and mapped as untagged. Update the documentation to match the implementation (de-facto ABI). Since -EOPNOTSUPP was never returned, change the error assignment to -EIO as well to avoid confusion. Fixes: df9d7a22dd21 ("arm64: mte: Add Memory Tagging Extension documentation") Fixes: 18ddbaa02b7a ("arm64: mte: ptrace: Add PTRACE_{PEEK,POKE}MTETAGS support") Reported-by: Yury Khrustalev Cc: Will Deacon Cc: Mark Rutland Signed-off-by: Catalin Marinas Signed-off-by: Will Deacon commit 3d1ba5cbfb622025690c218d8f20da92a9ecb383 Author: Thomas Huth Date: Wed Sep 9 17:57:07 2026 +0200 kselftest/arm64: Fix size of thread_data values for pthread_join() pthread_join() stores the thread's return value (a "void *", i.e. 8 bytes on 64 bit computers) into the address that is passed as second parameter. However, the entries of thread_data are only normal "int"s, i.e. only 4 bytes. The additional 4 bytes of the return value clobber whatever is adjacent on the stack, i.e. other members of the thread_data array (which will be re-written in the next iteration of the for-loop, so that nobody noticed this problem), or another other local variable on the stack for the last iteration. Use "intptr_t" to declare the thread_data array entries with the correct size. Fixes: 29f080881601c ("kselftest/arm64: check GCR_EL1 after context switch") Cc: stable@vger.kernel.org Signed-off-by: Thomas Huth Signed-off-by: Will Deacon commit 8c51ea651d043c786c37668c51624bd6b338a0ef Author: Pannarat Wiriyaarritham Date: Thu Sep 10 09:33:37 2026 +0700 usb: typec: ucsi: acpi: Assume UCSI 1.2 on Acer Nitro ANV15-41 The Acer Nitro ANV15-41 exposes a functional UCSI ACPI PPM but reports a UCSI VERSION value of zero. ucsi_register() rejects a zero version with -ENODEV, leaving the system without registered USB Type-C connectors. The PPM works correctly when using the UCSI 1.2 layout. With UCSI 1.2 assumed, both Type-C connectors register correctly and USB Power Delivery negotiation works. Add a DMI-specific UCSI operation for the Acer Nitro ANV15-41 that substitutes UCSI 1.2 only when firmware reports a zero version. Preserve any valid non-zero firmware version. Tested on an Acer Nitro ANV15-41 with BIOS V1.51. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: stable Assisted-by: LLM Signed-off-by: Pannarat Wiriyaarritham Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260910023338.31816-1-pannarat.wiriyaarritham@danielcorp.dev Signed-off-by: Greg Kroah-Hartman commit 8cf2093f5372952a9ebc805c418d45df7112cd14 Author: Mark Rutland Date: Tue Sep 8 16:17:23 2026 +0100 arm64: percpu: Fix LSE operations on {8,16}-bit types The assembly for __percpu_##name##_case_##sz() and __percpu_##name##_return_case_##sz() doesn't use the 'sfx' macro argument to form the LSE instruction. Without 'sfx', a W register argument will imply a 32-bit memory location, and consequently {8,16}-bit ops will erroneously read and write 32 bits of memory when the LSE instruction is used. Fix this by appending 'sfx' to 'op_lse' to LSE instruction. It is not necessary (and not valid) to append 'sfx' to 'op_llsc', as 'op_llsc' is a register-register operation which does not access memory (and does not take a size suffix). Fixes: 959bf2fd03b5 ("arm64: percpu: Rewrite per-cpu ops to allow use of LSE atomics") Signed-off-by: Mark Rutland Reviewed-by: Jinjie Ruan Cc: Ada Couprie Diaz Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: James Morse Cc: Marc Zyngier Cc: Peter Zijlstra Cc: Vladimir Murzin Cc: Will Deacon Cc: Yang Shi Cc: stable@vger.kernel.org Reviewed-by: Vladimir Murzin Signed-off-by: Will Deacon commit 44274c657256b4911de82f8104e9e22f054cf742 Author: Mark Rutland Date: Tue Sep 8 16:17:22 2026 +0100 arm64: percpu: Fix this_cpu_and() mask generation The arm64 implementation of this_cpu_and(pcp, val) is built in terms of ANDNOT operations, which requires the 'val' argument to be bitwise negated. The bitwise negation is not implemented correctly, with two bugs described below. (1) The bitwise negation is performed as '~val' rather than '~(val)'. This won't always generate the expected value when 'val' is an expression. For example, for this_cpu_and(pcp, 1 - 1): * 'val' is '1 - 1' ===> (int) 0x00000000 * '~val' is '~1 - 1' ===> (int) 0xfffffffd * '~(val)' is '~(1 - 1)' ===> (int) 0xffffffff ... and thus bit[1] of 'pcp' would be preserved unexpectedly by the ANDNOT operation. (2) The bitwise negation is performed on 'val' before it has been cast to (at least) the width of 'pcp'. This won't always generate the expected value for the upper bits. For example, for this_cpu_and(pcp, zero), where 'pcp' is a u64 and 'zero' is a u32: * 'zero' ===> (u32) 0x00000000 * '~(zero)' ===> (u32) 0xffffffff * '(u64)~(zero)' ===> (u64) 0x00000000ffffffff * '~((u64)(zero))' ===> (u64) 0xffffffffffffffff ... and thus bits[63:32] of 'pcp' would be preserved unexpectedly by the ANDNOT operation. Fix these issues by adding brackets around 'val', and by casting 'val' to an appropriately-sized type before bitwise negation. Fixes: 959bf2fd03b5 ("arm64: percpu: Rewrite per-cpu ops to allow use of LSE atomics") Signed-off-by: Mark Rutland Reviewed-by: Jinjie Ruan Tested-by: Muhammad Usama Anjum Acked-by: Christopher Lameter (Ampere) Cc: Ada Couprie Diaz Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: James Morse Cc: Marc Zyngier Cc: Peter Zijlstra Cc: Vladimir Murzin Cc: Will Deacon Cc: Yang Shi Cc: stable@vger.kernel.org Signed-off-by: Will Deacon commit 885bff055a0f251a51a0d4fd4f0a7b525582a3de Author: Mark Rutland Date: Tue Sep 8 16:17:21 2026 +0100 arm64: percpu: Fix this_cpu_write() casting The arm64 implementation of this_cpu_write() casts 'val' to unsigned long. This is necessary to handle cases where 'val' is a pointer type, and to avoid spurious compiler warnings for the (unreachable!) cases where the pointer type would be cast to a smaller integer type. Unfortunately, the cast is applied to 'val' rather than '(val)', which won't always generate the expected value when 'val' is an expression. For example, for this_cpu_write(pcp, zero - 1), where 'pcp' is a u64 and 'zero' is a u32: * 'zero' ===> (u32) 0x00000000 * 'zero - 1' ===> (u32) 0xffffffff * '(unsigned long)zero - 1' ===> (u64) 0xffffffffffffffff * '(unsigned long)(zero - 1)' ===> (u64) 0x00000000ffffffff Fix this by adding brackets around 'val'. Fixes: 959bf2fd03b5 ("arm64: percpu: Rewrite per-cpu ops to allow use of LSE atomics") Reported-by: David Laight Signed-off-by: Mark Rutland Reviewed-by: David Laight Reviewed-by: Jinjie Ruan Tested-by: Muhammad Usama Anjum Acked-by: Christopher Lameter (Ampere) Cc: Ada Couprie Diaz Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: James Morse Cc: Marc Zyngier Cc: Peter Zijlstra Cc: Vladimir Murzin Cc: Will Deacon Cc: Yang Shi Cc: stable@vger.kernel.org Reviewed-by: Lorenzo Stoakes (ARM) Signed-off-by: Will Deacon commit e4a6f57d22e079e23fafac51057fad534160b269 Author: Breno Leitao Date: Thu Sep 10 06:53:27 2026 -0700 arm64: hibernate: clone only the linear map that exists at runtime This is similar to commit 1537e55728ec2 ("arm64: trans_pgd: clone only the linear map that exists at runtime"), but in a different place. swsusp_arch_resume() clones the kernel linear map with trans_pgd_create_copy(..., PAGE_OFFSET, PAGE_END). PAGE_OFFSET comes from the compile-time VA_BITS, so a CONFIG_ARM64_VA_BITS_52 kernel booting on hardware without LPA2 -- vabits_actual is 48 and the fifth level is folded -- hands the walk a 3.9PB window while its linear map only spans the top 128TB. On a VA_BITS_52 4k kernel with CONFIG_KASAN_GENERIC in a 4GB VM, I see: swapper/0: page allocation failure: order:0, mode:0x920(GFP_ATOMIC|__GFP_ZERO) hibernate_page_alloc+0x10/0x1c swsusp_arch_resume+0x70/0x320 hibernation_restore+0xa4/0x138 software_resume+0x15c/0x270 PM: hibernation: Failed to load image, recovering. PM: hibernation: resume failed (-12) Fix it by copying the linear map that is the actual one, not the compiled one. Fixes: a6bbf5d4d9d1 ("arm64: mm: Add definitions to support 5 levels of paging") Signed-off-by: Breno Leitao Reviewed-by: Ard Biesheuvel Signed-off-by: Will Deacon commit 49daa3d668b69a5454b5aba0078848a479f79f1c Author: Shouping Wang Date: Thu Sep 10 19:46:01 2026 +0800 perf/arm-cmn: Fix wp_dev_sel2 setting for multi-DTM configurations When MXP_MULTIPLE_DTM_EN is TRUE, each DTM will monitor at most two device ports. In this case, {wp_dev_sel2, wp_dev_sel} will only use values 2'b00 and 2'b01 per DTM. Previously the setting allowed values beyond the supported range per DTM, which could cause each DTM to select invalid ports when MXP_MULTIPLE_DTM_EN is TRUE. Fix this by only setting CMN_DTM_WPn_CONFIG_WP_DEV_SEL2 when !multi_dtm. Fixes: 60d1504070c2 ("perf/arm-cmn: Support new IP features") Signed-off-by: Shouping Wang Reviewed-by: Robin Murphy Signed-off-by: Will Deacon commit e75a9fa1d44bcbd66ea02e8781bcca6ea4076e0d Author: Pablo Neira Ayuso Date: Mon Sep 7 21:04:05 2026 +0200 netfilter: flowtable: hold reference on ct until flow is released nf_ct_put() releases the ct->ext area inmediately, the rcu typesafe semantics also allow to refer to the wrong conntrack from the flowtable datapath. Hold reference on ct until flow is released after rcu grace period. Add rcu_barrier() on module exit path, to ensure pending flow entries are release before module goes away. Fixes: 0ff90b6c2034 ("netfilter: nf_flow_offload: fix use-after-free and a resource leak") Signed-off-by: Pablo Neira Ayuso commit cbdd39ce42530a193c56beb206a3356cb6d01016 Author: Pablo Neira Ayuso Date: Thu Sep 3 01:28:56 2026 +0200 netfilter: nf_nat: unregister and release hooks on error If nf_hook_entries_insert_raw() fails, the NAT hooks get never released, resulting in a memleak. Postpone setting nat_proto_net->nat_hook_ops when the hooks are registered to simplify the error path to decide whether the nat hooks need unwinding. Fixes: 1cd472bf036c ("netfilter: nf_nat: add nat hook register functions to nf_nat") Signed-off-by: Pablo Neira Ayuso commit 444e4c88c9c62a3d823069006563513fe7d5aa66 Author: Fernando Fernandez Mancera Date: Thu Aug 27 12:32:56 2026 +0200 netfilter: nf_tables: fix device name and prefix match in hook lookup Currently, a netdev chain or flowtable hooked to a device prefix can be unintentionally deleted by a control-plane request targeting an exact device name or even a shorter one due to the usage of min() to calculate the length to match. Fix this by making sure an exact device match never matches a prefix and that both the target and the candidate have the same length during delete operation. The add and update paths retain the existing overlap matching to prevent a single device from matching multiple hooks. Reported-by: Wei Fang Closes: https://lore.kernel.org/netfilter-devel/CANE+tVrDeNCHQVmsqkV2ozeBqyE3GtRDMhZgsg1bhw10yGNTRQ@mail.gmail.com/ Fixes: 6d07a289504a ("netfilter: nf_tables: Support wildcard netdev hook specs") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso commit d313499df66159b4b7971d760d16729598ab7e5a Author: Theodor Arsenij Larionov Trichkine Date: Tue Aug 25 12:10:56 2026 +0300 netfilter: nft_nat: fully initialise new_addr in netmap setup nft_nat_setup_netmap() builds the mapped address in an on-stack union nf_inet_addr. For an IPv4 mapping it writes only the 4-byte .ip member and the loop runs a single 32-bit iteration, but it then copies the whole 16-byte union into range->min_addr and range->max_addr, so the upper 12 bytes reach nf_nat_setup_info() uninitialised. KMSAN reports an uninit-value in nf_nat_setup_info() reached from nft_nat_eval(). The IPv6 path fills all 16 bytes and is not affected. Zero-initialise new_addr. Fixes: 3ff7ddb1353d ("netfilter: nft_nat: add netmap support") Signed-off-by: Theodor Arsenij Larionov Trichkine Signed-off-by: Pablo Neira Ayuso commit 06dd5e1ae8ce4e129791087c8c66594950f0ba03 Author: David Hu Date: Tue Sep 1 17:08:49 2026 +0000 dma-buf: Split sgl by largest page-aligned chunk Currently, `fill_sg_entry()` splits the scatterlist using `UINT_MAX`. This creates a non-page-aligned DMA length (`0xFFFFFFFF`) for the first entry, resulting in non-page-aligned DMA addresses for all subsequent entries. While the underlying IOMMU mapping may be contiguous, hardware DMA engines often require explicit address alignment (e.g., page, cacheline, or storage sector boundaries). Passing unaligned addresses and lengths can cause explicit failures in DMA descriptor creation or silent data corruption if lower unaligned bits are truncated. In addition, a non-page-aligned sgl length will trigger an edge case in `ib_umem_find_best_pgsz()`. In case of a discontinuity in later buffers, we will have a `va` with lowest bit set to 1. That will lead to `ib_umem_find_best_pgsz()` always return 0, and break the promise to find best page size for the mapping on the NIC side. Fix this by splitting the scatterlist by the largest possible page aligned chunk within `UINT_MAX` (`ALIGN_DOWN(UINT_MAX, PAGE_SIZE)`). This ensures all scatterlist DMA addresses and lengths remain page aligned, while minimizing the total number of sgl entries. Page-aligned entries allow the system to cleanly chunk payloads into PCIe MaxPayloadSize (MPS) (e.g., 128 bytes, 256 bytes, 512 bytes). As a result, this may help reduce TLP fragmentation in P2P transfers and alleviate potential congestion within a logical PCIe switch partition, especially when Relaxed Ordering is not possible due to hardware constraints. Reported-by: sashiko-bot Closes: https://lore.kernel.org/all/20260609165431.778061F00893@smtp.kernel.org/ Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: stable@vger.kernel.org Reviewed-by: Leon Romanovsky Signed-off-by: David Hu Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260901170849.4052816-3-dhu@x6u.co commit b344ca94e8cc85796f16ea25e2e5a8e0303fe813 Author: David Hu Date: Tue Sep 1 17:08:48 2026 +0000 dma-buf: Fix silent overflow for phys vec to sgt In case MMIO size is bigger than 4G and peer2peer DMA goes through host bridge, we trigger a code path that assigns the total linked IOVA (which is greater than 4G) to mapped_len. Previously, `mapped_len` was declared as 32-bit `unsigned int`. When accumulating `size_t` lengths, this leads to a silent wrap-around. This truncation causes truncated lengths to be passed to functions like `fill_sg_entry()`. Fix this by changing `mapped_len` to `size_t` (64-bit). While at it, fix similar potential overflow issues in `calc_sg_nents` by using `check_add_overflow()` for `nents` and using `unsigned int` for the loop iterator in `fill_sg_entry` to match. Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: stable@vger.kernel.org Cc: iommu@lists.linux.dev Reviewed-by: Pranjal Shrivastava Reviewed-by: Kevin Tian Reviewed-by: Leon Romanovsky Signed-off-by: David Hu Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260901170849.4052816-2-dhu@x6u.co commit 143755bdabaa96776c24f878014608e9cb44f930 Author: Karl Mehltretter Date: Mon Sep 7 04:00:15 2026 +0200 dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels Commit 646013f513f3 ("dma-buf: enable DMABUF_DEBUG by default on DEBUG kernels") changed the default of DMABUF_DEBUG to "y if DEBUG", but no Kconfig symbol DEBUG exists, so the option has had no default since. Use DEBUG_KERNEL, the Kconfig symbol for a debug kernel. Fixes: 646013f513f3 ("dma-buf: enable DMABUF_DEBUG by default on DEBUG kernels") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260907020015.24719-1-kmehltretter@gmail.com commit 049094c8878062cebd93c8c22d2c13b1d6804e99 Merge: 9bc184a2eda8b7 7d38af8f20239a Author: Greg Kroah-Hartman Date: Fri Sep 11 11:52:17 2026 +0200 Merge tag 'iio-fixes-for-7.3a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-linus Jonathan writes: IIO: 1st set of fixes for the 7.3 cycle. A couple of core fixes, the rest usual mix of driver issues that surfaced from merge window until now. core - buffer: Ensure that when using the iio_push_to_buffers_with_ts_unaligned() that the full buffer is zeroed. - trigger: Cancel reenable_work() before freeing the trigger that might be re-enabled. dma-buffer - Fix wrong sizing for a mapped sg_list. If an IOMMU was using a fused entry the mapping might walk off the end. adi,ade9000 - Wait for power up before requesting interrupts. - Fix overlap in scan index for current and voltage channels. - Ensure Phase C dip event included in IRQ1 handler. adi,adf4377 - Initialize all of a clk_init_data. adi,adis* - Ensure debugfs reads are finished before unbind. adi,axi-adc - Initialize mutex. adi,admv1013 - Ensure mutex is intialized before notifier that might use it is registered. - Fix wrong channel field used for read_raw. allwinner,sun4i - Drop a pm_runtime_put() when there was no get. - Ensure correct cleanup on driver probe fail due to any issues with the thermal zone. aspeed,adc, - Don't eat reset deassert errors. awinic,aw96103 - Make sure firmware length is validated rather than blindly trusting it. bosch,bmp280 - Fix out of bounds lookup of sampling frequency due to indexing based on elements in matrix rather than just the correct dimension. invensense,timestamp library - Ensure time estimate doesn't invert wrt to current time in a corner case occasionally seen. kionix,kx022a - Off by one in array boundary check. - Close a memory leak and state corruption in error path. maxim,max1363 - Sign extend bipolar values to ensure correct reporting to userspace. maxim,max30102 - Fix NULL dereference by checking there is data in the FIFO before trying to do anything with it. microchip,mcp47a1 - Ensure highest possible value actually settable. pulsed-light,lidar-lite - Don't leak the IIO device registration if runtime pm setup fails particularly as it was being freed. rockchip,saradc - Fix wrong fallback compatible for rv1106 that lead to trying to use too many channels (correct support will follow next merge window) rohm,bd79124 - Correct limit used for rising alarms. - Fix which registers related to limits are used in initialization. - Apply GPIO mask to allow subset of GPIOs to be toggled. - Add missing regmap error handling in a few places. - Ensures scale is read only. rohm,bm1390 - Don't silently eat a data read error. rohm,bu27034 - Don't silently eat error when reading gain. - Ensure we infinite delay doesn't happen on error. semtech,sx9324 - Fix wrong proximity channel resolution. sharp,gp2ap020a00f - Make sure to drain irq_work in remove path. st,vl5310x - Ensure direct mode is claimed for read_raw avoiding corruption of buffered accesses. vishay,vcnl3020 - Use write bits for ISR mask and ensure right event reported. vti,sca3000 - Fix up a condition check for the frequency divider. xilinx,xadc - Swap registration of cleanup of work with that of irq to ensure that no irqs can cause work that has been freed to be queued. x-powers,axp288 - Add bias override quirk for Haier HV103H. Fix because we used to always override then moved to trusting the firmware setup - which fixed some boards, but broke others. * tag 'iio-fixes-for-7.3a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (42 commits) iio: proximity: vcnl3020: fix ISR bitmask check in IRQ handler iio: proximity: vl53l0x-i2c: claim direct mode for raw reads iio: dac: mcp47a1: Allow full-scale output iio: accel: kionix-kx022a: Prevent memory leak and fix state iio: light: rohm-bu27034: Fix infinite delay on error iio: adc: sun4i-gpadc-iio: clean up on thermal zone registration failure iio: adc: sun4i-gpadc-iio: drop underflowing pm_runtime_put() calls iio: adc: axp288: Add TS bias override for Haier HV103H dt-bindings: iio: adc: rockchip-saradc: Fix RV1106 compatible dt-bindings: iio: adc: rockchip-saradc: Group single-entries into an enum list iio: inv_sensors: fix estimated value larger than interrupt timestamp iio: adc: aspeed: propagate reset deassert errors iio: buffer-dmaengine: fix sg entry iteration when building dma_vecs iio: proximity: pulsedlight: fix iio_device left registered on PM setup failure iio: trigger: cancel reenable_work before freeing trigger iio: frequency: admv1013: fix wrong channel field used in admv1013_read_raw() iio: accel: sca3000: fix frequency divider condition check iio: admv1013: initialize callback mutex before registering notifier iio: gyro: adis16136: fix unprotected debugfs reads iio: imu: adis16400: fix unprotected debugfs reads ... commit 2077aaac93c166211cda020680015f01e3ce3ec1 Merge: be4219dd986087 ae0e61d95677ef Author: Greg Kroah-Hartman Date: Fri Sep 11 11:51:17 2026 +0200 Merge tag 'usb-serial-7.3-rc3' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB serial fixes for 7.3-rc3 Here is a fix for a long-standing ioctl-hangup race and a couple of fixes for port lifetime issues that can lead to NULL-pointer dereferences when disconnecting devices or deregistering drivers. Included are also a fix for a related dynamic id leak and some new modem device ids. All have been in linux-next with no reported issues. * tag 'usb-serial-7.3-rc3' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: fix ioctl hangup race USB: serial: use iterator for driver deregistration USB: serial: fix driver deregistration order USB: serial: fix dynamic id driver deregistration race USB: serial: fix port tear down use-after-free USB: serial: option: add Compal EXC-T1 support USB: serial: option: add Quectel RG660QB USB: serial: option: add Compal EXM-G1x support USB: serial: option: add support for SIMCom SIM8260C USB: serial: option: add Quectel EG060W commit b1edd3a3e00369080012b2e4c665fc662b96ecbd Merge: e17b6f1307cabc f3c6a8ae601abf Author: Dave Airlie Date: Fri Sep 11 17:59:56 2026 +1000 Merge tag 'amd-drm-fixes-7.3-2026-09-10' of https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amdgpu: - Freesync fix - GPUVM fix - Debugfs fixes - HDMI fixes - IPS fix - GPU reset fix - RGB quantization fixes - SMU 13.0.x fixes Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patch.msgid.link/20260910202516.825788-1-alexander.deucher@amd.com commit 55a8e1451869233db837a97e8f3cbf9983bc8678 Author: Aneesh Kumar K.V (Arm) Date: Tue Sep 8 17:02:32 2026 +0530 x86/mm: Don't force unencrypted DMA for IOMMU-backed devices Commit 8277a12d0d60 ("dma-pool: track decrypted atomic pools and select them via attrs") exposed an issue with force_dma_unencrypted() on systems using host memory encryption. force_dma_unencrypted() checks whether the device DMA mask can address the encryption bit and, if not, requires DMA allocations to use unencrypted memory. However, this check is not applicable when the device is using the IOMMU. In that case, the device DMA mask constrains the IOVA seen by the device, not the backing physical address, so it does not need to cover the C-bit. This currently causes dma_alloc_attrs() to set __DMA_ATTR_ALLOC_CC_SHARED for such devices. iommu_dma_alloc() does not support that attribute and rejects the allocation, causing DMA allocations to fail. Do not force DMA allocations to be unencrypted when the device is using the IOMMU. This allows the IOMMU to map the encrypted physical pages as before and avoids incorrectly requesting CC_SHARED allocations. Fixes: 8277a12d0d60 ("dma-pool: track decrypted atomic pools and select them via attrs") Reported-by: Timo Witte Closes: https://lore.kernel.org/all/CANB4YXS=Nf-co3t8eMHtqrW4sn=1BDcP6o=EoTrgZm0WYMYTyw@mail.gmail.com/ Signed-off-by: Aneesh Kumar K.V (Arm) Link: https://lore.kernel.org/r/20260908113232.247457-1-aneesh.kumar@kernel.org [mszyprow: adjusted url and changed 'link' tag to the 'closes' one] Signed-off-by: Marek Szyprowski commit c5dcb3aadc18d7b82ba64790721b005d18193d35 Author: Andrea Parri Date: Thu Sep 10 16:34:42 2026 +0200 hrtimer: Use hard expiry when updating timers on the same base Rearming a queued timer with nonzero slack can leave the timerqueue out of order. remove_and_enqueue_same_base() checks the new soft expiry against its neighbours' hard expiries, then stores the new hard expiry in the node without requeueing it. For example, with A at 10 and B at 20, rearming A at 11 with slack 30 passes the neighbour check but leaves A's hard expiry of 41 before B's 20. The same function also caches the soft expiry in base->expires_next when updating or inserting the first timer, giving next-event selection an earlier deadline than the queue head's hard expiry. Set the timer expiry before handling the queue. Use its stored hard expiry for the in-place ordering check and both updates to base->expires_next. The early update is safe because remove_and_enqueue_same_base() runs with base->cpu_base->lock held. The lock keeps the queue stable while hrtimer_can_update_in_place() checks the new expiry against both neighbours. If the check fails, timerqueue_linked_del() removes the node without comparing expiry values before it is reinserted. Fixes: eddffab8282e3 ("hrtimer: Keep track of first expiring timer per clock base") Fixes: 343f2f4dc5425 ("hrtimer: Try to modify timers in place") Signed-off-by: Andrea Parri Signed-off-by: Thomas Gleixner Assisted-by: LLM Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260910143442.2018-1-parri.andrea@gmail.com commit e17b6f1307cabc1a5d142e6edaf92bae94472fda Merge: a202936da8436f cbd3dafc2003db Author: Dave Airlie Date: Fri Sep 11 16:45:19 2026 +1000 Merge tag 'drm-intel-fixes-2026-09-10' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes drm/i915 fixes for v7.3-rc3: - Fix a memleak on perf config query error path - Fix UHBR SST SDP splitting when sink doesn't support it Signed-off-by: Dave Airlie From: Jani Nikula Link: https://patch.msgid.link/27458ccc4d6be77a0d440f32279586711f3294f0@intel.com commit ad4497a92caba4630f75c80d49cb947026213280 Author: Darrick J. Wong Date: Tue Sep 8 23:06:08 2026 -0700 xfs: advance the findparent inode scan cursor while holding ILOCK LOLLM pointed out a race condition in xrep_findparent_scan -- the directory live update hook holds the directory ILOCK when it calls the xchk_iscan_want_live_update predicate to figure out if it needs to remember the live update, but xrep_findparent_scan drops the directory ILOCK before advancing the cursor. Therefore, it's possible for a live update to check the scan cursor after the scan drops the ILOCK but before the scan updates its cursor. If this happens, we'll fail to record the live update. Fix this by moving the cursor update logic inside xrep_findparent_walk_directory. Note that for non-directories it's ok to advance the cursor without holding any ILOCK because the findparent scan only cares about directory parents, not the children. Cc: stable@vger.kernel.org # v6.10 Fixes: a07b45576264e7 ("xfs: scan the filesystem to repair a directory dotdot entry") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit a202936da8436f627a48d3e7db249e5318a73237 Merge: 2991f9f794c9a9 f5fcf7e638b904 Author: Dave Airlie Date: Fri Sep 11 16:13:23 2026 +1000 Merge tag 'drm-xe-fixes-2026-09-10' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes A runtime_pm guard for page-fault worker and a cache flush fix. Signed-off-by: Dave Airlie From: Rodrigo Vivi Link: https://patch.msgid.link/aqLD4xjzFF6ROxBu@intel.com commit 69e10c2b4a51b4ff3c88a70e90f5180ad58c758f Author: Darrick J. Wong Date: Tue Sep 8 23:05:52 2026 -0700 xfs: reset parent pointer args before each dir tree unlink repair LOLLM noticed that xfs_parent_removename only partially initializes the passed-in parent pointer arguments object. In the directory tree repair code, we could decide to remove multiple links to a file, so we don't want state from one call to bleed into the next one. Zero the whole thing explicitly. Cc: stable@vger.kernel.org # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit e854f9a28b1fa08dfa5bf18ee4184fae90106180 Author: Darrick J. Wong Date: Tue Sep 8 23:05:37 2026 -0700 xfs: fix replaying dirent removals into the temporary directory xrep_dir_replay_removename is the function that replays a directory entry removal from sc->ip into the temporary directory so that when we swap the contents of sc->tempip and sc->ip, the directory is correct. LOLLM noticed that we were passing the wrong inode pointer into xrep_dir_init_args. It doesn't make sense to set rd->args.dp to rd->args.dp so let's fix this. Cc: stable@vger.kernel.org # v6.10 Fixes: 8559b21a64d983 ("xfs: implement live updates for directory repairs") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit d3a6a35a220615c4f4578aedf3b1626b91d3acae Author: Darrick J. Wong Date: Tue Sep 8 23:05:21 2026 -0700 xfs: fix termination logic in xchk_bmap xchk_should_terminate can turn its @error argument into -EINTR if the user is sitting on ^C. Unfortunately, this code here turns that into a 0 return, which isn't quite correct. LOLLM complains about this, though I think it's a very minor matter because the only way -EINTR happens is if there's a fatal signal. Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 3bdbf472a608aeb7e8e4dc70ee86738ad5256356 Author: Darrick J. Wong Date: Tue Sep 8 23:05:06 2026 -0700 xfs: fix rtrmap cross-referencing elision logic LOLLM points out that xchk_bmap_xref_rmap_cow skips the cross-reference if the data-section rmapbt cursor is not present. However, this is broken for realtime file data fork scanning, because they will have an rtrmapbt cursor and not an rmapbt cursor. Fix the behavior by removing the cursor checks because xchk_bmap_get_rmap already accounts for that. Cc: stable@vger.kernel.org # v6.14 Fixes: 037a44d8277adf ("xfs: cross-reference the realtime rmapbt") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 1ee2ce797c360785a3813fef62c90f427f3aed34 Author: Darrick J. Wong Date: Tue Sep 8 23:04:50 2026 -0700 xfs: actually check internal-rtdev fields in the superblock LOLLM points out that the superblock scrubber doesn't check the new fields that were added for internal realtime volumes when we added zoned device support. Cc: stable@vger.kernel.org # v6.15 Fixes: 2167eaabe2fadd ("xfs: define the zoned on-disk format") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit 4d3c07591534517c633945c8d8e6526f10e3fabc Author: Darrick J. Wong Date: Thu Sep 10 21:42:28 2026 -0700 xfs: fix under-reservation of blocks when repairing sf directories Whilst running QA on XFS for-next as of 7.3-rc2 with MKFS_OPTIONS="-n size=8192", I observed the following (trimmed) dmesg splat: XFS: Assertion failed: args->total >= dp->i_nblocks - nblks, file: fs/xfs/libxfs/xfs_da_btree.c, line: 2387 WARNING: fs/xfs/xfs_message.c:104 at assfail+0x46/0x4a [xfs], CPU#0: xfs_scrub/1426511 CPU: 0 UID: 0 PID: 1426511 Comm: xfs_scrub Tainted: G W 7.3.0-rc2-djwx #rc2 PREEMPT(lazy) 6e418570b606a39783b0e7e7b30dc407b965f9e8 Tainted: [W]=WARN RIP: 0010:assfail+0x46/0x4a [xfs] RSP: 0018:ffffc900010d7890 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000ffffffd1 RDX: 0000000000000000 RSI: 0000000000000021 RDI: ffffffffa059fd38 RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000000a R11: 000000007fffffff R12: ffffc900010d7940 R13: ffff888368d8f980 R14: ffffc900010d7a48 R15: ffffc900010d78d0 FS: 00007f445c5ce680(0000) GS:ffff8884a97ea000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f443803b9a8 CR3: 0000000107a4b000 CR4: 00000000003506f0 Call Trace: xfs_da_grow_inode_int+0x2e0/0x300 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xfs_dir2_grow_inode+0x6e/0x150 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xfs_dir2_sf_to_block+0x149/0x870 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xrep_dir_swap_prep+0xe2/0x110 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xrep_dir_swap+0xfb/0x2f0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xrep_dir_rebuild_tree+0x99/0x100 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xrep_directory+0x83/0x1c0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xrep_attempt+0x4f/0x1e0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xfs_scrub_metadata+0x393/0x5b0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xfs_ioc_scrubv_metadata+0x306/0x570 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] xfs_file_ioctl+0xa4f/0x1150 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x7a/0x3b0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 This is a consequence of commit 0fe77e57588b98, which added the following assertion to xfs_da_grow_inode_int: ASSERT(args->total >= dp->i_nblocks - nblks); Tracing this back to xrep_dir_swap_prep, I noticed that the xfs_da_args object that's passed to xfs_dir2_sf_to_block sets args->total to 1. This is incorrect because mkfs set the directory block size to 8k and the filesystem block size to 4k. In other words, args->total should be 2 here, not 1. Dave Chinner tripped over the same problem with the same branch through a different channel -- his test setup set the fs block size to 1k, in which case the directory block size is still set to 4k. Here, args->total should be 4. Changing the assignment of args->total to sc->mp->m_dir_geo->fsbcount makes the assertion go away, but that isn't a complete fix. In xrep_tempexch_estimate, we also incorrectly assume that a shortform conversion requires 1 fsblock when it should be m_dir_geo->fsbcount. Without that, we can under-reserve space in the transaction and cause a filesystem shutdown. Note that the xfs_dabuf_nfsb helper will compute the correct value for directories and xattr, so we use that instead of open-coding the logic. Also fix xrep_xattr_swap_prep to assign args->total via xfs_dabuf_nfsb to avoid one logic bomb if we ever support multi-fsblock attrs. Cc: stable@vger.kernel.org # v6.10 Cc: floss@jetm.me Reported-by: dgc@kernel.org Fixes: 629fdaf5f5b1b7 ("xfs: use atomic extent swapping to fix user file fork data") Tripped-by: 0fe77e57588b98 ("xfs: assert the reservation covers each da fork growth") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit 2991f9f794c9a9be699b2221f757662213d17514 Merge: df2908090cda36 4600b4d1a9ee73 Author: Dave Airlie Date: Fri Sep 11 10:55:23 2026 +1000 Merge tag 'drm-misc-fixes-2026-09-10' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A fair amount of fixes this week as well: - create blend mode property for more driver planes - Kconfig cleanups across the board - sched: null pointer dereference fix in kunit tests - ethosu misc fixes about error handling and corner cases handling - ivpu fixes about buffer and metadata validation - rockchip: fixes around buffer overflow and kconfig - tc358768: fix bus flags and error handling Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patch.msgid.link/aqJd5TPXpwqwsM0F@houat commit 135d84c66f85426299db01a09d93a79a87af18ba Author: Binglei Wang Date: Fri Sep 11 12:11:33 2026 +0800 erofs: add missing buf->off in erofs_bread() erofs_bread() locates the target folio with index = (buf->off + offset) >> PAGE_SHIFT; but computes the in-folio offset without taking buf->off into account: return buf->base + (offset & ~PAGE_MASK); If buf->off is not page-aligned, the returned pointer misses the in-page component of buf->off, so callers end up fetching data from a wrong offset. buf->off is set to sbi->dif0.fsoff in erofs_init_metabuf(), and fsoff can be specified via the "fsoffset=" mount option, which only requires block-size alignment. Therefore, on an image with a sub-page block size (e.g. 512 bytes), a non-page-aligned fsoff (e.g. 512) triggers the issue, since 512 is a multiple of the block size but not of PAGE_SIZE. It can be reproduced by mounting an image that is placed at a non-page-aligned offset: mkfs.erofs -b512 -zlz4hc sub.erofs src/ # prepend 512 bytes of padding to the image mount -t erofs -o loop,fsoffset=512 padded.erofs /mnt which fails with erofs (device loop0): cannot find valid erofs superblock because the on-disk superblock (at offset 1024 within the image, i.e. 1536 within the padded file) is read from a wrong in-folio offset. With this fixed, the very same image mounts successfully and its file contents match those read from the unpadded image. Fix it by including buf->off in the in-folio offset calculation, so that it is consistent with the folio index calculation. Fixes: c36ec00d7f67 ("erofs: add 'fsoffset' mount option to specify filesystem offset") Signed-off-by: Binglei Wang Reviewed-by: Gao Xiang Signed-off-by: Gao Xiang commit 94b1a3ca9b8db3151f1416263704c159a9470da5 Author: Yang Xiuwei Date: Fri Aug 21 18:30:47 2026 +0800 selftests: ublk: add batch IO cases to recover_03 Add -b coverage for quiesce recover. Signed-off-by: Yang Xiuwei Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260821103047.369522-3-yangxiuwei@kylinos.cn Signed-off-by: Jens Axboe commit 8a14be55bdc6d5a25cd7b0ac5d4d884fcc727b49 Author: Yang Xiuwei Date: Fri Aug 21 18:30:46 2026 +0800 ublk: clear force_abort in ublk_queue_reset_io_flags() Quiesce sets ubq->force_abort for batch I/O. Recovery never clears it, so batch fetch keeps failing with -ENODEV and the device stays QUIESCED. Fixes: a4d883755399 ("ublk: add UBLK_U_IO_FETCH_IO_CMDS for batch I/O processing") Signed-off-by: Yang Xiuwei Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260821103047.369522-2-yangxiuwei@kylinos.cn Signed-off-by: Jens Axboe commit 27600805e62f800bacf990354632eae4e487d34c Author: Yazen Ghannam Date: Thu Sep 3 10:43:25 2026 -0500 x86/amd_node: Fix PCI device reference counting in amd_smn_init() The local "root" pointer is a temporary variable used during the device search. Therefore, refcount related to the search iterators should be cleaned up after the search is complete. Use the __free() cleanup macro to ensure the refcount is decremented when the temporary pointer goes out of scope. Additionally, increment the refcount when caching a root pointer. This ensures the in-use refcount is separate from the temporary search refcounting. Finally, drop the redundant "root = NULL" before the second search loop. The pci_get_class() iterator always decrements the refcount of its "from" argument, so the first loop can only fall through with "root" already NULL. Fixes: 0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching") Closes: https://sashiko.dev/#/patchset/20260806160159.230453-1-jason.andryuk%40amd.com Reported-by: Sashiko Assisted-by: LLM Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Mario Limonciello (AMD) Cc: Link: https://patch.msgid.link/20260903154325.74343-1-yazen.ghannam@amd.com commit 15071f2a1263e82150c77eeb1e94dbfc31950a8e Merge: f77d2124571069 8036d3a5a6589e Author: Alexei Starovoitov Date: Thu Sep 10 16:58:40 2026 -0700 Merge branch 'bpf-tcp-fix-bpf_sock_destroy-on-time_wait-and-listener-socks' Jiayuan Chen says: ==================== bpf,tcp: Fix bpf_sock_destroy() on TIME_WAIT and listener socks Fix two bugs in bpf_sock_destroy(). One is an out-of-bounds read of sk->sk_protocol on TIME_WAIT and NEW_SYN_RECV socks, since the field is not in struct sock_common. The other is a might_sleep splat when destroying a listener with children in its accept queue, the cond_resched() in inet_csk_listen_stop() runs under the iterator's rcu_read_lock(). Patch 3 adds a subtest for each. v2 -> v3: - Patch 1: add Reviewed-by from Kuniyuki. - Patch 2: reword why cond_resched() has to go, it can reschedule or report a bogus quiescent state there. - Patch 2: keep the cond_resched() for the non-BPF path rather than removing it as Kuniyuki suggested. VOLUNTARY and NONE are still there on some arches, and on x86 in stable where this goes, so a big listener close() still relies on it. Can go once those modes are gone. - Selftest: don't leak the fd if accept() unexpectedly succeeds. v2: https://lore.kernel.org/bpf/20260906074135.185212-1-jiayuan.chen@linux.dev/ v1 -> v2: - Patch 1: fix the return comment too. - Patch 2: new. - Selftest: server recv()s EOF before close so the FINs can't cross, comment style, keep the blank line before RUN_TESTS(), add the tcp_listen_pending subtest. v1: https://lore.kernel.org/bpf/20260903125306.299943-1-jiayuan.chen@linux.dev/ ==================== Link: https://patch.msgid.link/20260910112107.148770-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit 8036d3a5a6589ef0721d15e7c03976bc3996f7a8 Author: Jiayuan Chen Date: Thu Sep 10 19:28:02 2026 +0800 selftests/bpf: Test bpf_sock_destroy() on TIME_WAIT and listener socks Add two subtests. tcp_timewait: the client shuts down first and the server closes after it, so the client sock ends up in TIME_WAIT. A tcp iterator then finds the timewait sock by the cookie it inherited from the client sock and destroys it. Iterate once more to make sure it is gone. Without the first fix bpf_sock_destroy() reads past the timewait sock and KASAN complains. tcp_listen_pending: connect to a listener but never accept, so the child sits in the accept queue, then destroy the listener. Without the second fix the cond_resched() in inet_csk_listen_stop() trips the might_sleep check under rcu_read_lock(). ./test_progs -a sock_destroy #444/1 sock_destroy/tcp_client:OK #444/2 sock_destroy/tcp_server:OK #444/3 sock_destroy/tcp_listen_pending:OK #444/4 sock_destroy/tcp_timewait:OK #444/5 sock_destroy/udp_client:OK #444/6 sock_destroy/udp_server:OK #444/7 sock_destroy/trace_tcp_destroy_sock:OK #444 sock_destroy:OK Summary: 1/7 PASSED, 0 SKIPPED, 0/0 FAILED Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260910112810.153801-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit eaab8cab451b9502ce224cd202550375b894a467 Author: Jiayuan Chen Date: Thu Sep 10 19:27:28 2026 +0800 tcp: Skip cond_resched() in inet_csk_listen_stop() under BPF context bpf_sock_destroy() runs from the tcp iterator, under rcu_read_lock(). If the sock is a listener that still has children in its accept queue, tcp_abort() ends up in inet_csk_listen_stop() and the cond_resched() there trips the debug check: BUG: sleeping function called from invalid context at net/ipv4/inet_connection_sock.c:1523 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 628, name: test_progs preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 locks held by test_progs/628: 3, last CPU#3: #0: ffff8881158cee18 (&p->lock){+.+.}-{4:4}, at: bpf_seq_read+0x56/0x1210 #1: ffff8881106bb858 (sk_lock-AF_INET6){+.+.}-{0:0}, at: bpf_iter_tcp_seq_show+0x32b/0x4b0 #2: ffffffffb435af20 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x46b/0xde0 CPU: 3 UID: 0 PID: 628 Comm: test_progs Tainted: G W 7.2.0+ #65 PREEMPT Tainted: [W]=WARN Call Trace: dump_stack_lvl+0xc1/0xf0 dump_stack+0x10/0x20 __might_resched+0x3d2/0x610 inet_csk_listen_stop+0x7b/0xbf0 tcp_abort+0x23b/0x3b0 bpf_sock_destroy+0xfc/0x140 bpf_prog_448133d24601754f_iter_tcp6_server+0x81/0x8a bpf_iter_run_prog+0x538/0xde0 bpf_iter_tcp_seq_show+0x26b/0x4b0 bpf_seq_read+0x424/0x1210 vfs_read+0x197/0xe40 ksys_read+0x119/0x240 __x64_sys_read+0x72/0xc0 x64_sys_call+0x647/0x27e0 do_syscall_64+0xe5/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fad39b28aca RSP: 002b:00007ffc381c61c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007ffc381c6a88 RCX: 00007fad39b28aca RDX: 0000000000000032 RSI: 00007ffc381c6250 RDI: 0000000000000014 RBP: 00007ffc381c61e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003 R13: 0000000000000000 R14: 000055f077c1bbb0 R15: 00007fad3a0f3000 The commit that added the kfunc already guards lock_sock() in tcp_abort() and udp_abort() with has_current_bpf_ctx(), but missed the listener path. Do the same for the cond_resched(). The loop runs inside the iterator's rcu_read_lock(), it must not reschedule or report a quiescent state there. Fixes: 4ddbcb886268 ("bpf: Add bpf_sock_destroy kfunc") Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260910112736.153710-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit 01b245ba016d44861690594e10f67e026ce8552f Author: Jiayuan Chen Date: Thu Sep 10 19:26:26 2026 +0800 bpf: Fix out-of-bounds read of sk_protocol in bpf_sock_destroy() sk_protocol lives in struct sock, not in struct sock_common. A timewait or request sock handed to bpf_sock_destroy() by the tcp iterator is neither, so reading sk->sk_protocol runs past the object: ================================================================== BUG: KASAN: slab-out-of-bounds in bpf_sock_destroy+0xc7/0xe0 Read of size 2 at addr ffff8881047d11b4 by task test_progs/428 Tainted: [W]=WARN Call Trace: dump_stack_lvl+0x91/0xf0 print_report+0xd1/0x630 kasan_report+0xf3/0x130 __asan_report_load2_noabort+0x14/0x30 bpf_sock_destroy+0xc7/0xe0 bpf_prog_c3dd61f9d9cd9f37_iter_tcp6_timewait+0x9f/0xb7 bpf_iter_run_prog+0x538/0xde0 bpf_iter_tcp_seq_show+0x26b/0x4b0 bpf_seq_read+0x424/0x1210 vfs_read+0x197/0xe40 ksys_read+0x119/0x240 __x64_sys_read+0x72/0xc0 x64_sys_call+0x647/0x27e0 do_syscall_64+0xe5/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Only check sk_protocol on full socks. tcp_abort() already knows how to deal with TIME_WAIT and NEW_SYN_RECV socks. Also fix the comment, it never matched the code. Fixes: 4ddbcb886268 ("bpf: Add bpf_sock_destroy kfunc") Reported-by: Xiang Mei (Microsoft) Closes: https://lore.kernel.org/bpf/20260702224519.800135-1-xmei5@asu.edu/ Signed-off-by: Jiayuan Chen Reviewed-by: Kuniyuki Iwashima Link: https://lore.kernel.org/r/20260910112634.152195-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit f77d21245710690f3fb02d19d8dd4dc17ee58c2c Author: Jiayuan Chen Date: Thu Sep 10 20:22:56 2026 +0800 selftests/bpf: Test BTF walk into a flexible array of zero-sized elements The program stashes a bpf_obj_new() object whose type ends with a flexible array of empty structs, then reads it back as an untrusted kptr. Without the previous patch this divides by zero in btf_struct_walk() instead of being rejected. # ./test_progs -t verifier_btf_flex_array ... #602 verifier_btf_flex_array:OK Summary: 1/1 PASSED, 0 SKIPPED, 0/0 FAILED Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260910122316.186384-2-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit b0b3dc66529676228cb938cbcad66920f735c223 Author: Jiayuan Chen Date: Thu Sep 10 20:22:55 2026 +0800 bpf: Fix divide-by-zero in btf_struct_walk() When an access goes past the struct and the last member is a flexible array, btf_struct_walk() folds the offset back into a single element with (off - moff) % t->size, but never checks that the element type has a size. BTF takes an empty struct, so this in program BTF /* event could be empty */ struct event { #ifdef HAVE_TIMESTAMP __u64 ts; #endif }; struct batch { int nr; struct event events[]; }; divides by zero at prog load time. Getting there needs a PTR_TO_BTF_ID that is not MEM_ALLOC, e.g. a plain read of a local kptr stashed in a map from a sleepable program. Oops: divide error: 0000 [#1] SMP KASAN PTI RIP: 0010:btf_struct_walk+0x53f/0x1570 Call Trace: btf_struct_access+0x42a/0xcd0 check_ptr_to_btf_access+0x4dc/0x1160 check_mem_access+0x3a45/0x8740 check_load_mem+0x36a/0xd10 do_check_common+0x3ef0/0xb210 bpf_check+0x6d3b/0x8580 bpf_prog_load+0xf7c/0x2720 __sys_bpf+0xa83/0x3690 __x64_sys_bpf+0xc7/0x150 x64_sys_call+0x1f3f/0x27e0 do_syscall_64+0xe5/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Reject a zero-sized element type. The fixed array path in the same function already bails out on the same thing: btf_struct_walk() ... /* skip empty array */ if (moff == mtrue_end) continue; msize /= total_nelems; Fixes: 9c5f8a1008a1 ("bpf: Support variable length array in tracing programs") Signed-off-by: Jiayuan Chen Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260910122316.186384-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit 2936aed9b02162df7fbe08fcd6bfbb3270ad9f95 Author: Daniel Borkmann Date: Thu Sep 10 20:56:04 2026 +0200 bpf: Clear scalar delta on narrowing stack spill check_stack_write_fixed_off() breaks the scalar link on a narrowing spill by zeroing the id of the destination stack slot, but leaves the delta in place. save_register_state() has just copied the source register verbatim, so the slot keeps the BPF_ADD_CONST delta of a register it is no longer linked to. This is the same shape as the case addressed in 1b327732c846 ("bpf: Clear delta when clearing reg id for non-{add,sub} ops"). Unlike the latter, no miscomputation seems reachable, so mainly consistency. Signed-off-by: Daniel Borkmann Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260910185604.44949-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov commit a903f145a8914d9ecba009b398d135154e4a5d94 Author: Daniel Borkmann Date: Thu Sep 10 23:35:10 2026 +0200 selftests/bpf: Add tests for the KF_PERFMON gates Add test cases where each one loads with CAP_BPF alone and checks that the program is correctly rejected. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t verifier_kfunc_perfmon [...] #627/1 verifier_kfunc_perfmon/rdonly_cast_noperfmon:OK #627/2 verifier_kfunc_perfmon/rdonly_cast_noperfmon @unpriv:OK #627/3 verifier_kfunc_perfmon/probe_read_kernel_dynptr_noperfmon:OK #627/4 verifier_kfunc_perfmon/probe_read_kernel_dynptr_noperfmon @unpriv:OK #627/5 verifier_kfunc_perfmon/stream_vprintk_noperfmon:OK #627/6 verifier_kfunc_perfmon/stream_vprintk_noperfmon @unpriv:OK #627/7 verifier_kfunc_perfmon/get_kmem_cache_noperfmon:OK #627/8 verifier_kfunc_perfmon/get_kmem_cache_noperfmon @unpriv:OK #627/9 verifier_kfunc_perfmon/arg_untrusted_read_noperfmon:OK #627/10 verifier_kfunc_perfmon/arg_untrusted_read_noperfmon @unpriv:OK #627 verifier_kfunc_perfmon:OK Summary: 1/10 PASSED, 0 SKIPPED, 0/0 FAILED Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260910213510.49358-4-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov commit f9191460cd805e84eace0884c75c67ec719fa1d8 Author: Daniel Borkmann Date: Thu Sep 10 23:35:09 2026 +0200 bpf: Require CAP_PERFMON for untrusted read-only memory reads Marking bpf_rdonly_cast() KF_PERFMON CAP-limits one producer of PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED, but not the type itself. A global subprogram argument tagged __arg_untrusted results in the same register with no kfunc call. Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260910213510.49358-3-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov commit 81c975aae375d2053fa2926ee3730f02e713140c Author: Daniel Borkmann Date: Thu Sep 10 23:35:08 2026 +0200 bpf: Require CAP_PERFMON for kfuncs reading memory Mark fault-safe probe reading kfuncs as KF_PERFMON, similarly as we do for the old-style BPF helper equivalents. bpf_rdonly_cast() is included in this list as well as it returns PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED for an unchecked object and is using fault-safe BPF_PROBE_MEM. Note that only the void form of bpf_rdonly_cast() produced a register that was readable without CAP_PERFMON. For a struct type id the kfunc returns PTR_TO_BTF_ID | PTR_UNTRUSTED, whose dereference has always been gated in check_ptr_to_btf_access(). The flag is not conditional on the type id, so for the latter it only moves the rejection from the dereference to the call itself, which is the better place to report it anyway. The bpf_stream_vprintk() and bpf_stream_print_stack() kfuncs are marked as well. The former ends up in the same bpf_bprintf_prepare() as the bpf_snprintf() helper, where %pks, %pus and %pI4 read through a program- supplied address and %pB resolves one into a symbol. The latter walks the stack and prints each instruction pointer via %pS. Lastly, bpf_get_kmem_cache() takes a raw scalar address that the verifier does not constrain and dereferences the page/slab metadata for it. Field reads on the returned pointer are still blocked (PTR_TO_BTF_ID | PTR_UNTRUSTED -> check_ptr_to_btf_access() results in -EPERM without the CAP), but the NULL/non-NULL result is observable. Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260910213510.49358-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov commit 88ce88e933e40f4ab4b81a5e9d0a10328583f593 Author: Daniel Borkmann Date: Thu Sep 10 23:35:07 2026 +0200 bpf: Add KF_PERFMON kfunc flag Tracing related BPF helpers e.g. under bpf_base_func_proto() are gated behind CAP_PERFMON. However, the same is currently not true for kfuncs and they are accessible via plain CAP_BPF. Add a new KF_PERFMON flag which can be used such that check_kfunc_call() ensures env->allow_ptr_leaks is permitted. This follows similar pattern to existing KF_DESTRUCTIVE flag. The rejection returns -EPERM to match the other CAP_PERFMON gates in the verifier, that is, check_ptr_to_btf_access() and check_ptr_to_map_access(), which report the very same policy to user space. Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260910213510.49358-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov commit 08df884136f1c1197bab2a27814404fd329d9aac Merge: 5897d0546f8abb 5ad0af4f436720 Author: Linus Torvalds Date: Thu Sep 10 14:45:25 2026 -0700 Merge tag 'thermal-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fix from Rafael Wysocki: "Replace snprintf() with scnprintf() in the thermal core sysfs code to avoid compiler warnings about potential truncation of the names of the sysfs attributes (Andy Shevchenko)" * tag 'thermal-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: sysfs: switch to use scnprintf() to suppress truncation warning commit 5897d0546f8abbe5d57ef1e65a096f5b9ed8312f Merge: aa416593f363f9 13b3dcbcfed1d0 Author: Linus Torvalds Date: Thu Sep 10 14:42:46 2026 -0700 Merge tag 'pm-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These harden the cpufreq core against races with sysfs during policy creation, fix two issues in the OPP (Operating Performance Points) library, and make OPP print symbolic error names: - Zero-initialize the policy cpumask and initialize the policy rwsem before exposing the policy sysfs interface (Runyu Xiao and Zhongqiu Han) - Fix potential multiplication overflow when calculating freq in OPP core (Colin Ian King) - Fix use after free in _update_opp_table_clk() (Peter Griffin) - Use %pe to print symbolic error name in OPP (Sumeet Pawnikar)" * tag 'pm-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: opp: fix use after free in _update_opp_table_clk() cpufreq: zero-initialize policy cpumask before sysfs publication cpufreq: initialize policy rwsem before sysfs publication opp: Use %pe to print symbolic error name OPP: of: Fix potential multiplication overflow when calculating freq commit aa416593f363f9b290e21cdbb98e90a0d8c513e1 Merge: 78445023439506 c88a6338ae485e Author: Linus Torvalds Date: Thu Sep 10 14:37:53 2026 -0700 Merge tag 'hwmon-for-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - Core - Fix potential UAF in pec_store - Ensure that 'dev' passed to hwmon_notify_event() is a hwmon device - Document hwmon_notify_event() - applesmc: Fix key backlight workqueue leak on register failure - aspeed-pwm-tacho: Propagate reset deassert errors - asus_rog_ryujin: HID report fixes - chipcap2: Fix channels in humidity alarm notifications - corsair-cpro: debugfs fixes - gpd-fan: Documentation: replace full-width colon by a standard ASCII colon - gpio-fan: Take fan_data->lock in gpio_fan_shutdown(), and fix use-after-free in alarm work - ina2xx: Fix in0 and curr1 alarm handling, and acquire hwmon_lock in shunt_resistor_show() - ltc4282: Fully initializeclk_init_data - mcp9982: Propagate one-shot polling errors - nct6694: Do not expose enable on DTIN temperature channels - PMBus core: Clear generic status alarms with CLEAR_FAULTS - sht4x: Fix return value from heater_enable_store(), and add missing locks * tag 'hwmon-for-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (24 commits) hwmon: (nct6694) do not expose enable on DTIN temperature channels hwmon: (asus_rog_ryujin) Synchronize HID command and report handling hwmon: (asus_rog_ryujin) Validate HID report lengths hwmon: (corsair-cpro) Remove debugfs entries when probe fails hwmon: (aspeed-pwm-tacho) Propagate reset deassert errors hwmon: (gpio-fan) take fan_data->lock in gpio_fan_shutdown() hwmon: (corsair-cpro) Create debugfs entries after hwmon registration hwmon: (pmbus) Clear generic status alarms with CLEAR_FAULTS hwmon: (chipcap2) fix channels in humidity alarm notifications hwmon: (applesmc) fix key backlight workqueue leak on register failure hwmon: (sht4x) Fix return value from heater_enable_store() hwmon: (sht4x) Add missing locks hwmon: (yogafan) fix non-kernel-doc comment Documentation: hwmon: replace full-width colon by a standard ASCII colon hwmon: (ina2xx) Decouple in0 and curr1 alarms hwmon: (ina2xx) Replace masks with enum in alert functions hwmon: (ina2xx) Parameterize ina2xx_data in ina226_alert_read() hwmon: Ensure that 'dev' passed to hwmon_notify_event() is a hwmon device hwmon: (ina2xx) Acquire hwmon_lock in shunt_resistor_show() hwmon: Fix potential UAF in pec_store ... commit 78445023439506ebd83b86d40b1e428a3b309d4a Merge: 0a96d0d726cd38 5096947508b750 Author: Linus Torvalds Date: Thu Sep 10 14:07:48 2026 -0700 Merge tag 'net-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Nothing too exciting, usual stream of fixes. Including fixes from Netfilter, Bluetooth and WPAN. Current release - new code bugs: - Bluetooth: hci_sync: fix not setting CE length properly - eth: enic: match mailbox replies to request numbers Previous releases - regressions: - tunnels: drop stale dst when building an ICMP error for PMTUD - ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings() (bug in the rtnl_lock -> RCU conversion) - eth: bnxt_en: - fix crashes on Thor2 due to OOB coalescing buffer accesses - prevent queue stop with deferred completions Previous releases - always broken: - eth: - ice: don't dereference pointers from TP_printk() - fix OOB writes on ethtool flow rule dump in 3 drivers - mlx5: fix FEC configuration with RS_544_514_INTERLEAVED_QUAD - dsa: tag_brcm: legacy FCS: request needed tailroom Misc: - net: cap tx_queue_len at S16_MAX to prevent oversized ring alloc - ipv6: flowlabel: cap duplicate leases per socket" * tag 'net-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (164 commits) selftests: tc-testing: test action batch failure cleanup net/sched: act_api: release all action references on NEWACTION failure openvswitch: fix wrong flag value in get_ipv6_ext_hdrs() ipmr: account multicast table and route memory net: phy: dp83td510: handle the active-high LED polarity mode net: macb: initialize PTP state before registering clock net: hsr: enable promiscuous mode on interlink port with fwd offload ipv6: fix fib6 walker UAF on seq stop net: stmmac: fix TX descriptor availability check for TSO traffic net/rds: fix tcp stream corruption with large pages net: mana: restore the XDP program pointer when pre-allocation fails net: phy: dp83867: handle the active-high LED polarity mode octeontx2-af: fix PF/CGX debugfs PCI bus lookup net: net_failover: Fix the deadlock in net_failover_slave_name_change() net: phy: mediatek-ge: disable EEE on the MT7530 PHY tcp: reject non zerocopy devmem tx net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support net: dsa: mt7530: populate lpi_interfaces to fix EEE support net: hinic: fix mailbox segment buffer overflow net: sun4i-emac: fix missing of_node_put() for phy_node ... commit 0a96d0d726cd380423ac38e2c28f538db2940a1d Merge: ad724d319c8147 cb26524ef4ac28 Author: Linus Torvalds Date: Thu Sep 10 14:03:48 2026 -0700 Merge tag 'cifs-fixes-7.3-rc3' of https://git.manguebit.org/linux Pull smb client fixes from Paulo Alcantara: - File type corruption fixes in reparse point handling: setting S_IFMT bits without clearing the existing type first corrupted the file mode (e.g. S_IFREG | S_IFCHR == S_IFLNK). Fixed in the WSL, POSIX and native symlink reparse parsers. Also fixes an uninitialized SID structure in the POSIX readdir path when parsing fails. - Ownership mapping fixes: forceuid/forcegid mount options were ignored in several code paths (SID-to-id mapping, WSL extended attributes, POSIX extensions getattr), allowing an untrusted server to dictate local file ownership despite explicit mount overrides. - Heap overflow and overflow fixes in DACL rewriting: replacing short SIDs with long ones could overflow the DACL buffer, and the u16 accumulator for DACL size could wrap around with enough ACEs. - Reference count leak fixes in oplock break and deferred close: duplicate oplock breaks on a queued work item leaked a cifsFileInfo reference, and deferred close had a similar leak when requeueing a running work item. Both cause busy-inode oopses on unmount. - DFS superblock use-after-free fix: the iterator callback stored a raw superblock pointer without pinning it, racing with automount expiry. - One-byte slab OOB read in the native symlink parser when handling share-root relative paths. - Hardening of legacy SMB1 input: reject userspace-crafted cifs.idmap key descriptions that bypass kernel origin checks, and validate DataOffset in CIFSSMBRead() to prevent heap info disclosure from a malicious server. - DFS cache fix: defer metadata updates until target copying succeeds to prevent partial-state cache entries on allocation failure. * tag 'cifs-fixes-7.3-rc3' of https://git.manguebit.org/linux: smb: client: fix one-byte OOB read in smb2_parse_native_symlink() smb: client: fail DACL rewrite when the new DACL exceeds 64K smb: client: fix heap overflow in DACL owner/group rewrite smb: client: fix file type corruption in cifs_reparse_point_to_fattr() smb: client: fix file type corruption in posix_reparse_to_fattr() smb: client: fix file type corruption in wsl_to_fattr() smb: client: avoid using uninitialized SIDs in cifs_posix_to_fattr() smb: client: fix WSL reparse point uid/gid override smb: client: honor forceuid/forcegid when mapping SIDs to uid/gid smb: client: fix uid/gid override in getattr with posix extensions smb: client: fix cifsFileInfo reference leak in deferred close smb: client: avoid leaking refcount when cifs_sb_tlink() fails smb: client: avoid leaking refcount in cifs_queue_oplock_break() smb: client: fill cache fields after populating cache in copy_ref_data() smb: client: pin DFS superblock in iterator callback smb: client: reject userspace cifs.idmap descriptions smb: client: reject out-of-bounds DataOffset in CIFSSMBRead() smb: client: reject short READ responses in CIFSSMBRead() commit a0a34a40ed299c9c7cff6af163a5b883ee9d6d73 Author: Weiming Shi Date: Thu Sep 10 03:10:23 2026 +0800 fbdev: vfb: defer cleanup until the last reference FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released. Fixes: 5e266e2e0e19 ("vfb: fix memory leaks in removal path") Reported-by: co+c25629c98ba36ebe@bugs.sh Cc: stable@kernel.org Closes: https://lore.kernel.org/linux-fbdev/f2Kf9GYn1lKR5S1dbvGVtykMxK1RlgP5z8sW@bugs.sh/ Assisted-by: Codex:gpt-5 Signed-off-by: Weiming Shi Link: https://lore.kernel.org/linux-fbdev/f2Kf9GYn1lKR5S1dbvGVtykMxK1RlgP5z8sW@bugs.sh/ Signed-off-by: Helge Deller commit 5067d4ba713961d8ccea1e06cd4c453793f3121e Author: Jens Axboe Date: Tue Sep 1 19:39:46 2026 +0200 sunvdc: fix -EIO issue due to lack of retries John reports that since commit: a11f6ca9aef9 ("sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN") users of Linux inside Solaris ldom see occasional -EIO errors because the request send loop now times out. The current loop does 10 retries, and inside vio_ldc_send() a further 1000 1usec retries are done as well. Even with 10.5 msec of busy loop retries that's apparently not enough to always succeed. Rather than introduce continued busy looping, requeue the request and have the delayed queue kicking retry the request after another 10ms. This obviously isn't ideal, but there's seemingly no way to wait for this type of event. And if 10ms of busy looping was not enough to make progress, then presumably this is an edge condition and we just need to guarantee to make forward progress at some later point in time. That's more suitably done through letting the CPU tend to other work, rather than sitting in a tight loop retrying. [stian: rebased on top of the cookie-unmap fix, without which every requeued attempt leaks LDC map table entries; tested on an UltraSPARC T4 LDOM where the vdc_tx_trigger failure condition was reproduced and absorbed by the requeue with no I/O error] Reported-by: John Paul Adrian Glaubitz Link: https://lore.kernel.org/all/20251006100226.4246-2-glaubitz@physik.fu-berlin.de/ Link: https://lore.kernel.org/all/418310b3-2b77-4534-b2fd-27dcc11e333c@kernel.dk/ Signed-off-by: Stian Halseth Link: https://patch.msgid.link/20260901173947.3292110-3-stian@itx.no Signed-off-by: Jens Axboe commit 0c6da21fa35e03fc74f09895433ccd6d4a9c3530 Author: Stian Halseth Date: Tue Sep 1 19:39:45 2026 +0200 sunvdc: unmap LDC cookies when the descriptor send fails __send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failure, the reset path (vdc_requeue_inflight(), which walks [cons, prod)) never visits it either. The map table entries are leaked permanently. Since commit a11f6ca9aef9 ("sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN") trigger failures occur in practice under load, so every resulting I/O error also leaks one request's worth of entries from the fixed-size (8192 entries per channel) map table. Because the allocator hands out contiguous ranges, fragmentation makes large multi-segment requests fail first as the table drains, until ldc_map_sg() fails permanently and the disk is dead until reboot. It also makes any retry-based recovery unusable: requeuing the request on -EAGAIN remaps the pages on every attempt, overwriting desc->cookies and orphaning the previous mapping, so the table drains at the retry rate. This is the memory exhaustion observed when the requeue approach was first tested in October 2025. Roll back on failure: unmap the cookies, mark the descriptor FREE again and clear the request entry. If the trigger failed with -ENOTCONN, __vdc_tx_trigger() has already reset the port, which tears down and reallocates both the dring and the LDC channel including its map table - nothing to roll back, and the stale descriptor must not be touched. Fixes: a11f6ca9aef9 ("sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN") Reported-by: John Paul Adrian Glaubitz Link: https://github.com/sparclinux/issues/issues/2 Signed-off-by: Stian Halseth Link: https://patch.msgid.link/20260901173947.3292110-2-stian@itx.no Signed-off-by: Jens Axboe commit b0d8d56b7c93ed767eb4f2be9988e7b9dc023566 Author: David Howells Date: Wed Sep 9 09:06:31 2026 +0100 block: Fix start and length check added to iov_iter_extract_bvecs() Commit 14b007e17881 added an address check using iter_iov_addr() and a length check using iter_iov_len() to iov_iter_extract_bvecs(), but these cannot be used so and are unsafe in this circumstance as the functions have hardwired assumptions about the iterator type. They should only be used with ITER_UBUF or ITER_IOVEC-type iterators; they shouldn't be used with ITER_BVEC, ITER_KVEC, ITER_FOLIOQ, ITER_XARRAY or ITER_DISCARD iterators. This proves to be a problem for cachefiles as an iterator of type ITER_FOLIOQ is passed and iter_iov_addr() and iter_iov_len() both malfunction because iter->__iov in iter_iov() is not pointing to an iovec array. Fix this by using iov_iter_alignment() instead. Fixes: 14b007e17881 ("block: validate user space vectors during extraction") Signed-off-by: David Howells Reviewed-by: Keith Busch cc: Hannes Reinecke cc: Christoph Hellwig cc: Jens Axboe cc: Alexander Viro cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-block@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/1667275.1788941191@warthog.procyon.org.uk Signed-off-by: Jens Axboe commit c4fa55f85c47cd5d54d717fb8170746edb10292e Author: Mahmoud Nagy Adam Date: Wed Sep 9 15:26:03 2026 +0200 selftests: ublk: install test_common.sh and trace/ scripts Every ublk test script sources test_common.sh from its own directory: . "$(cd "$(dirname "$0")" && pwd)"/test_common.sh and test_generic_02/12 additionally run bpftrace against the scripts in trace/. Neither test_common.sh nor trace/ is listed in TEST_FILES, so "make install" does not copy them into the install directory and every ublk test fails when run from there: ./test_generic_02.sh: line 4: .../kselftest_install/ublk/test_common.sh: No such file or directory ./test_generic_02.sh: line 8: _have_program: command not found The bpftrace tests are affected even when bpftrace is installed: the missing trace/*.bt makes bpftrace exit immediately, and the tests then report a skip rather than a failure, which hides the problem. Add both to TEST_FILES, matching how other selftests ship their sourced helpers (see kexec/kexec_common_lib.sh and zram/zram_lib.sh). Fixes: 6aecda00b7d1e1 ("selftests: ublk: add kernel selftests for ublk") Fixes: 723977cab4c0fd ("selftests: ublk: add generic_01 for verifying sequential IO order") Cc: stable@vger.kernel.org # v6.15+ Assisted-by: Kiro:claude-opus-5 Signed-off-by: Mahmoud Nagy Adam Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260909132602.68852-2-mngyadam@amazon.de Signed-off-by: Jens Axboe commit 3934185ba63feca6e80cc8b90f7d7f01cde78223 Author: Linmao Li Date: Thu Aug 27 17:39:48 2026 +0800 fbdev: atafb: Restrict SuperBlitter to supported formats The SuperBlitter operations derive an integer byte count per pixel. The accelerated fill path handles only one-, two- and four-byte pixels. However, the operations are currently installed for every external framebuffer in SuperVidel RAM, including planar 1/2/4/8-bpp and 24-bpp truecolor modes accepted by the external video parser. For 1/2/4-bpp modes, the byte count becomes zero, so accelerated copies do nothing and fills fall through to 32-bit stores. Planar 8-bpp uses an incompatible memory layout. For 24-bpp modes, fills also use 32-bit stores despite advancing addresses by three bytes per pixel. These cases can corrupt the framebuffer beyond the requested rectangle. Enable the SuperBlitter operations only for the layouts they implement: 8-bpp packed pixels and 16/32-bpp truecolor. Keep the existing software operations for all other external formats. Fixes: d463633d63e6 ("fbdev: atafb: Add support for SuperVidel's SuperBlitter") Signed-off-by: Linmao Li Tested-by: Miro Kropáček Reviewed-by: Michael Schmitz Signed-off-by: Helge Deller commit 3fb13d29cf8eb4502837bff06b2873c5435f6ffd Author: Yang Zi <2959243019@qq.com> Date: Tue Aug 25 16:58:15 2026 +0800 fbdev: ssd1307fb: fix NULL pointer dereference on missing match data device_get_match_data() can return NULL, e.g. when the device is matched through the I2C device ID table rather than the OF match table. The returned value is stored in par->device_info and later dereferenced when initializing par->vcomh, causing a NULL pointer dereference. Check the return value right after the assignment and bail out with -ENODEV (releasing the already allocated framebuffer) before any dereference. Signed-off-by: Yang Zi <2959243019@qq.com> Signed-off-by: Helge Deller commit 13b3dcbcfed1d0c8c1d3b5dcfe306f9992452ae9 Merge: e06cb12e1ebf1a 54d37bcf2f4971 Author: Rafael J. Wysocki Date: Thu Sep 10 20:16:37 2026 +0200 Merge branch 'pm-cpufreq' Merge cpufreq fixes for 7.3-rc3: - Zero-initialize policy cpumask and initialize policy rwsem before exposing the policy sysfs interface (Runyu Xiao and Zhongqiu Han) * pm-cpufreq: cpufreq: zero-initialize policy cpumask before sysfs publication cpufreq: initialize policy rwsem before sysfs publication commit 01c8d1f385f788f1bbbbb7687c4386d614281218 Author: Jonghyuk Kim(MalHyuk) Date: Wed Sep 2 10:27:20 2026 +0900 drm/msm: RCU-free the scheduler-containing ring and VM objects Both struct msm_ringbuffer and struct msm_gem_vm embed a struct drm_gpu_scheduler. msm_ringbuffer_destroy() and the VM free callback msm_gem_vm_free() call drm_sched_fini() on the embedded scheduler and then free the containing object with plain kfree(). drm_sched_fence_get_timeline_name() returns fence->sched->name, and the scheduler fence keeps a .release callback so it is not ops-detached on signalling. A finished fence exported to userspace (the submit out-fence, or a VM_BIND fence, via sync_file / drm_syncobj) keeps pointing at the embedded scheduler after the ring/VM is freed, so a later get_timeline_name() -- reachable unprivileged through SYNC_IOC_FILE_INFO -- dereferences freed slab memory (KASAN slab-use-after-free read). Per the dma-fence lifetime contract the exporter must keep the data backing a signalled fence alive for an RCU grace period. Free the scheduler-containing objects with kfree_rcu() instead of kfree(). Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler") Fixes: 92395af63a99 ("drm/msm: Add VM_BIND submitqueue") Cc: stable@vger.kernel.org Signed-off-by: Jonghyuk Kim(MalHyuk) Patchwork: https://patchwork.freedesktop.org/patch/750234/ Message-ID: <20260902012720.880783-1-malhyuk97@gmail.com> Signed-off-by: Rob Clark commit 8061ee61b9426fe38350fa9eead2d9c50b03deb6 Author: Karl Mehltretter Date: Sun Sep 6 19:03:01 2026 +0200 drm/msm/adreno: Fix the skip_gpu parameter description The module parameter is skip_gpu, but its MODULE_PARM_DESC() names no_gpu, so modinfo describes a parameter that does not exist and shows no description for the real one. Use the parameter name in the description. Fixes: 3f17991488af ("drm/msm/adreno: Add a modparam to skip GPU") Assisted-by: LLM Signed-off-by: Karl Mehltretter Patchwork: https://patchwork.freedesktop.org/patch/751406/ Message-ID: <20260906170301.2393-1-kmehltretter@gmail.com> Signed-off-by: Rob Clark commit adf5967331318bcb436fc80069915231ec039352 Author: Karl Mehltretter Date: Sun Sep 6 19:03:47 2026 +0200 drm/msm: Fix the separate_gpu_kms parameter description The module parameter is separate_gpu_kms, but its MODULE_PARM_DESC() names separate_gpu_drm, so modinfo describes a parameter that does not exist and shows no description for the real one. Use the parameter name in the description. Fixes: 217ed15bd399 ("drm/msm: enable separate binding of GPU and display devices") Assisted-by: LLM Signed-off-by: Karl Mehltretter Patchwork: https://patchwork.freedesktop.org/patch/751407/ Message-ID: <20260906170347.2427-1-kmehltretter@gmail.com> Signed-off-by: Rob Clark commit f65d38155aef069c897a64643a03db237dd1e0c8 Author: David Laight Date: Mon Aug 3 10:47:01 2026 +0100 x86/div64: Fix addition of large constants in mul_u64_add_u64_div_u64() Adding constants over 2^31 fails to compile because the ADD instruction only supports 32bit signed immediates. Replace the "irm" constraint with "erm" so that the compiler loads large constants into a register. Found by a patch to drivers/iio/frequency/ad9910.c [ bp: Massage commit message. ] Fixes: 6480241f31f5 ("lib: add mul_u64_add_u64_div_u64() and mul_u64_u64_div_u64_roundup()") Signed-off-by: David Laight Signed-off-by: Borislav Petkov (AMD) Reviewed-by: H. Peter Anvin Link: https://patch.msgid.link/20260803094702.3852-2-david.laight.linux@gmail.com commit a19d4f9b8befdcfcd5a87bab91312fe64af3bbb8 Author: Ethan Nelson-Moore Date: Sat Jun 6 23:40:49 2026 -0700 ata: pata_legacy: remove documentation for removed module parameters Commit 3c4d783f6922 ("ata: pata_legacy: remove VLB support") removed several module parameters from the pata_legacy driver, but neglected to remove their documentation. Remove it. Fixes: 3c4d783f6922 ("ata: pata_legacy: remove VLB support") Cc: stable@vger.kernel.org # 7.0+ Signed-off-by: Ethan Nelson-Moore Reviewed-by: Karl Mehltretter Reviewed-by: Damien Le Moal Reviewed-by: Randy Dunlap Link: https://lore.kernel.org/r/20260607064053.195166-1-enelsonmoore@gmail.com Signed-off-by: Niklas Cassel commit f3c6a8ae601abf2d8476d3f899283cc9a1001f7d Author: Kevin Wang Date: Tue Sep 8 18:15:41 2026 +0800 drm/amd/pm: report energy accumulator for smu 13.0.0 add energy accumulator on pmfw 0x004e8600 and above version. Signed-off-by: Kevin Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit 3a804a5b15c22e4d7a3906ff09035e539785813e) commit 13ddcc7acb9adbed7627e952a61d1d62cd9546fc Author: Kevin Wang Date: Wed Aug 26 09:51:55 2026 +0800 drm/amd/pm: fix gpu metrics energy accumulator for smu 13.0.0/13.0.7 GPU metrics v1.3 defines energy_accumulator as a 64‑bit field. The unsupported‑firmware code path assigns UINT_MAX, which is neither the full‑width invalid value for this field nor its default value. Fixes: 8de9edb35976 ("drm/amd/pm: remove invalid gpu_metrics.energy_accumulator on smu v13.0.x") Signed-off-by: Kevin Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit c2b948c4fe16eb13d98ff5d1371956cb2f55cdc6) Cc: stable@vger.kernel.org commit 8cfd9e22eb5c04b15b82985ff913944f84673d4f Author: Satyajit Roy Date: Sun Aug 30 03:52:13 2026 +0000 drm/amd/display: Rebuild InfoFrames on output color space changes resource_build_info_frame() derives colorimetry and RGB quantization from stream->output_color_space. A Broadcast RGB-only atomic commit updates that field and reprograms the output CSC, but none of the InfoFrame update predicates include output_color_space. The sink can therefore retain the previous AVI InfoFrame range while the source starts transmitting a different pixel range. Treat an output color space change as an InfoFrame change in update classification and in both stream programming paths. Hardware testing on an HDMI 2.1 television confirmed that its automatic black-level selection follows Full to Limited and Limited to Full transitions in SDR, HDR, and HDR with VRR active, without a modeset or visible link blank. Fixes: 6eb4c13a3845 ("drm/amd/display: Support "Broadcast RGB" drm property") Signed-off-by: Satyajit Roy Reviewed-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit d6faca79f5720893843e649e70aeb19147ee0578) Cc: stable@vger.kernel.org commit 7fca7acd60a228b62b4e9efa5f184738041e9564 Author: Satyajit Roy Date: Sun Aug 30 03:52:06 2026 +0000 drm/amd/display: Honor Broadcast RGB for BT.2020 RGB output amdgpu_dm_get_output_color_space() applies the Broadcast RGB connector property to default RGB output, but always selects full-range output for BT.2020 RGB. Consequently, explicitly selecting Limited has no effect on the output CSC or AVI InfoFrame when HDR uses BT.2020 RGB. Select COLOR_SPACE_2020_RGB_LIMITEDRANGE when the output encoding is RGB and Broadcast RGB is Limited. Keep Automatic and Full at full range, and leave YCbCr output unchanged. Add KUnit coverage for limited-range RGB output through both BT.2020 connector colorspace values. Fixes: 6eb4c13a3845 ("drm/amd/display: Support "Broadcast RGB" drm property") Signed-off-by: Satyajit Roy Reviewed-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 022236eaa63bbf65761aa8aec43f661451a94654) Cc: stable@vger.kernel.org commit bdcd0411d7d186225a52458fd42bb70d54ca917a Author: Satyajit Roy Date: Sun Aug 30 03:51:58 2026 +0000 drm/amd/display: Propagate HDMI RGB quantization selectability DC uses dc_edid_caps.qs_bit when constructing the HDMI AVI InfoFrame quantization-range field. Although DRM parses the sink capability into drm_display_info, DM never copies it into the DC EDID capabilities. The field therefore remains zero and the AVI quantization range stays at its default value. Copy rgb_quant_range_selectable for HDMI sinks and extend the existing EDID-capability KUnit test to cover it. Fixes: 6eb4c13a3845 ("drm/amd/display: Support "Broadcast RGB" drm property") Signed-off-by: Satyajit Roy Reviewed-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 892659399f64642e33072562a11ec1b2e7bd2263) Cc: stable@vger.kernel.org commit 829157e762ed043e28ecb2e9f3c7d22b54e5989e Author: Thadeu Lima de Souza Cascardo Date: Tue Sep 8 16:59:51 2026 -0300 Revert "drm/amdgpu: debugfs: avoid extra EOLs in amdgpu_gem_info" This reverts commit c119d05a36a884482decc67e55944648f8cba97e. It removes the newline even when there are no fences attached to a struct dma_resv, leading to multiple BOs being output on the same line, making the debug file less readable, not more as the commit intended. Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Alex Deucher (cherry picked from commit a2aafaeb2be13ed3c893e6a44a3a5d26b251ae6a) Cc: stable@vger.kernel.org commit 1f1d43418d61c8511779e0f63a954a78b9433b43 Author: Prike Liang Date: Mon Aug 31 10:51:04 2026 +0800 drm/amdgpu: skip gfx switch_power_profile during GPU reset During resume from GPU reset, the gfx idle work may invoke switch_power_profile before the reset completes. This causes the following assert error because the register access occurs without first releasing the GPU reset semaphore: [ 1576.768935] CR2: 0000559ea133ead0 CR3: 00000002e6c42000 CR4: 0000000000350ef0 [ 1576.768940] Call Trace: [ 1576.768944] [ 1576.768953] amdgpu_device_rreg+0x21/0x50 [amdgpu] [ 1576.769158] smu_msg_v1_send_msg+0x1a4/0x6e0 [amdgpu] [ 1576.769437] smu_cmn_send_smc_msg_with_params_ext+0xba/0x120 [amdgpu] [ 1576.769721] smu_cmn_send_smc_msg_with_param+0x33/0x40 [amdgpu] [ 1576.769993] smu_v13_0_0_set_power_profile_mode+0x192/0x2b0 [amdgpu] [ 1576.770267] smu_bump_power_profile_mode+0x5d/0x80 [amdgpu] [ 1576.770538] smu_switch_power_profile+0xa4/0xf0 [amdgpu] [ 1576.770839] amdgpu_dpm_switch_power_profile+0x6f/0x90 [amdgpu] [ 1576.771210] amdgpu_gfx_profile_idle_work_handler+0xe9/0x130 [amdgpu] [ 1576.771460] process_one_work+0x23e/0x6f0 [ 1576.771491] worker_thread+0x1c4/0x380 [ 1576.771506] kthread+0x10c/0x150 [ 1576.771512] ? __pfx_worker_thread+0x10/0x10 [ 1576.771518] ? __pfx_kthread+0x10/0x10 [ 1576.771530] ret_from_fork+0x314/0x390 [ 1576.771537] ? __pfx_kthread+0x10/0x10 [ 1576.771546] ret_from_fork_asm+0x1a/0x30 Signed-off-by: Prike Liang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit d93b1ff538ce9750c01e0dd0aa62575579c0fc08) Cc: stable@vger.kernel.org commit 5d7e0cc4afda0cb25c0829dc7c1bb4bedd7886a5 Author: Fangzhi Zuo Date: Wed Aug 26 17:47:41 2026 -0400 drm/amd/display: Fix HF-VSDB DSC bpc detection to be cumulative [Why & How] The HDMI Forum VSDB reports the maximum DSC color depth a sink supports. This maximum is cumulative: a sink that reports 12 bpc also supports 10 and 8 bpc. The previous code used exact "== 10" and "== 12" comparisons chained with else-if, so a 12 bpc sink only set frl_dsc_12bpc and never set frl_dsc_10bpc, incorrectly narrowing the DSC bpc range usable with that sink. Use ">= 10" and a separate ">= 12" check so a sink advertising a higher maximum also enables the lower DSC bit depths it supports. Reviewed-by: Alex Hung Signed-off-by: Fangzhi Zuo Signed-off-by: Ray Wu Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 4523adbf4dca157aea96a6f28b4e7b7ebd4d5eda) commit 3001d2073d6542a9e51fa5bca3a39a078094d3c6 Author: Fangzhi Zuo Date: Thu Aug 27 13:12:46 2026 -0400 drm/amd/display: Exit IPS before connector detection on resume [Why & How] On resume, dm_resume() walks the connector list and, for each connector, calls dc_link_detect_connection_type() at the top of the loop iteration before the per-connector dc_exit_ips_for_hw_access() that sits in the detection branch. There is no dc_exit_ips_for_hw_access() before the loop, so the very first HW access relies on an earlier connector having already taken the display out of IPS. Commit d1d51519bc3b ("drm/amd/display: Skip eDP detection when no sink") skips the eDP connector when no panel is present. On a DCN3.5 APU whose eDP link has no sink, the eDP iteration - which used to bring the HW out of IPS first - is now skipped, so a downstream DP connector becomes the first one processed. Its initial DDC/AUX access then runs while the HW is still idle, the AUX transfers time out (-ETIMEDOUT), and the EDID read fails: [drm:dm_helpers_read_local_edid [amdgpu]] *ERROR* EDID err: 2, on connector: DP-1 amdgpu: [drm] *ERROR* No EDID read. Take the display out of IPS once before the detection loop so the first connector processed no longer touches the AUX/DDC engine while the HW is still in idle power state. This keeps the eDP-skip boot/resume optimization while fixing the DP EDID read failure. Fixes: d1d51519bc3b ("drm/amd/display: Skip eDP detection when no sink") Reviewed-by: Roman Li Signed-off-by: Fangzhi Zuo Signed-off-by: Ray Wu Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 86420fe3093161971b4064e05be11ffff1df76aa) Cc: stable@vger.kernel.org commit 2e8ff3ac79eb09dccbd8f00ee5da1b61e53246be Author: Nathan Chancellor Date: Thu Jun 18 09:52:14 2026 -0700 drm/amd/display: Shorten hdmi_frl_status_polling_workqueue There is a warning when creating the hdmi_frl_status_polling_wq workqueue because "hdmi_frl_status_polling_workqueue" excceds WQ_NAME_LEN: workqueue: name exceeds WQ_NAME_LEN. Truncating to: hdmi_frl_status_polling_workque Shorten the workqueue name to "hdmi_frl_status_polling_wq" like the structure member to avoid the warning. Fixes: 5c9b8b27a883 ("drm/amd/display: Tie FRL support into amdgpu_dm") Reviewed-by: Alex Hung Signed-off-by: Nathan Chancellor Reviewed-by: Tvrtko Ursulin Link: https://patch.msgid.link/20260618-amdgpu-fix-wq_name_len-warning-v2-1-ef0e2e6f5be7@kernel.org Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 767ae341b68193fda5fdbc510b2d77e3e8938039) commit 622b4e8505aa7453a53d17fa3a288871f270fc8b Author: Harry Wentland Date: Tue Jun 16 13:39:21 2026 -0400 dm/amdgpu: fix malformed link_settings debugfs output [Why] dp_link_settings_read() passed strlen() of each format string as the size argument to snprintf() and then advanced rd_buf_ptr by that same fixed amount. The format-string length has no relation to the formatted output length, so snprintf() truncated each field at a NUL it wrote inside the buffer while the pointer was advanced past it. The result is a buffer peppered with embedded NUL bytes and fields that are silently cut short, so the data read back from the debugfs node does not reflect the actual link settings. [How] Use scnprintf() with the real remaining buffer size (rd_buf_size - (rd_buf_ptr - rd_buf)) and advance rd_buf_ptr by its return value, which is the number of characters actually written. This both bounds each write to the space left in rd_buf and keeps the output a single, properly terminated string. The now-unused str_len local is removed. Fixes: 41db5f1931ec ("drm/amd/display: set-read link rate and lane count through debugfs") Assisted-by: Copilot:claude-opus-4.8 Signed-off-by: Harry Wentland Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 43b9f0f18693c7f7b75613f3aeae25fa2b4e2f76) Cc: stable@vger.kernel.org commit 87ceb8cba73d0b3c4025ff42495bccd8164acaed Author: Arunpravin Paneer Selvam Date: Wed Sep 2 18:33:48 2026 +0530 drm/amdgpu: skip the VMID 0 flush for VRAM 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 commit cfdcf5571c3107bf636002fc0c16ce93c19bd671 Author: Michel Dänzer Date: Mon May 18 17:48:09 2026 +0200 drm/amd/display: Consult MCCS FreeSync cap only if requested & supported When the do_mccs parameter is false, we don't call dm_helpers_read_mccs_caps, so sink->mccs_caps.freesync_supported is unlikely to be true. Fixes: 6f71d5dd3206 ("drm/amd/display: Read sink freesync support via mccs") Bug: https://gitlab.freedesktop.org/drm/amd/-/work_items/5286 Signed-off-by: Michel Dänzer Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit ac3aea794fb4156467b4b3b92c3155d95bf435c9) Cc: stable@vger.kernel.org commit ad724d319c81475488794eccc11eb5e27242e1eb Merge: c9a8c0e393d604 353a95f1cd8da8 Author: Linus Torvalds Date: Thu Sep 10 09:36:56 2026 -0700 Merge tag 'sysctl-7.03-fixes-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl Pull sysctl fix from Joel Granados: "This fell through the cracks during the latest merge window. There are no more CONFIG_PROC_SYSCTL uses after this fix: - Replace CONFIG_PROC_SYSCTL with CONFIG_SYSCTL CONFIG_SYSCTL is the config string that controls sysctl subsys" * tag 'sysctl-7.03-fixes-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl: syscall_user_dispatch: Use CONFIG_SYSCTL for sysctl guard commit c9a8c0e393d6043fc29b0b527e654110ba523c36 Merge: 50d05c7c76c96b 01504d14e47b34 Author: Linus Torvalds Date: Thu Sep 10 09:11:17 2026 -0700 Merge tag 'watchdog-for-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull watchdog fixes from Guenter Roeck: - core: Do not start hrtimer when pretimeout is zero - msc313e: Various fixes for issues reported by Sashiko - MAINTAINERS: Update URI for watchdog tree - sunxi_wdt: preserve boot-enabled watchdog * tag 'watchdog-for-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: watchdog: msc313e: Sync timeout value if WDT was running at boot watchdog: msc313e: Fix undefined behavior watchdog: msc313e: Fix spurious reset on suspend watchdog: msc313e: Enable clock before accessing hardware registers watchdog: msc313e: Fix clock leak and spurious timer in settimeout() watchdog: msc313e: Avoid division by zero watchdog: fix hrtimer start when pretimeout is zero MAINTAINERS: Update URI for watchdog tree watchdog: msc313e: Fix NULL pointer dereference in PM callbacks watchdog: sunxi_wdt: preserve boot-enabled watchdog commit 5096947508b750bd4a65a8e61bd2083a44d61bfd Merge: fc266a5dd99c45 2a86bbed9f6070 Author: Jakub Kicinski Date: Thu Sep 10 09:06:07 2026 -0700 Merge branch 'net-sched-fix-action-batch-failure-cleanup' Xuanqiang Luo says: ==================== net/sched: fix action batch failure cleanup Failed batched RTM_NEWACTION requests can leak action references and reserved IDR indices when cleanup encounters a filter-bound action. Patch 1 fixes the failure cleanup. Patch 2 adds tc-testing regression coverage. Failure reproduction (key output excerpts): python3 tdc.py -f tc-tests/actions/gact-rollback.json not ok 1 e3b1 - Failed action batch releases a bound action reference Could not match regex pattern. Verify command output: [...] index 1 ref 3 bind 1 not ok 2 e3b2 - Failed action batch releases entries after a bound action Command exited with 255, expected 0 RTNETLINK answers: Resource temporarily unavailable We have an error talking to the kernel not ok 3 e3b3 - Failed action batch releases repeated references to a bound action Could not match regex pattern. Verify command output: [...] index 1 ref 4 bind 1 ==================== Link: https://patch.msgid.link/20260909070336.32979-1-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski commit 2a86bbed9f60702e97a8194e40f90f4db22d7795 Author: Xuanqiang Luo Date: Wed Sep 9 15:03:36 2026 +0800 selftests: tc-testing: test action batch failure cleanup Add tests for cleanup after a batched RTM_NEWACTION request fails. Replace an existing gact action bound to a filter, then fail a later entry by requesting goto chain without a classifier context. Check that the bound action's reference count returns to its original value. Also cover a successfully initialized new action between the bound action and the failing entry, verifying that its reserved index can be reused. Repeat the bound action in another batch to check that each temporary reference to the same action is released. Signed-off-by: Xuanqiang Luo Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260909070336.32979-3-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski commit 478eb5abb51931a152abab068f8a717b7ff480fd Author: Xuanqiang Luo Date: Wed Sep 9 15:03:35 2026 +0800 net/sched: act_api: release all action references on NEWACTION failure When a batched RTM_NEWACTION request replaces an existing action, tcf_idr_check_alloc() takes a temporary reference on it. If a later action fails to initialize, tcf_action_destroy() uses strict release semantics to clean up the actions initialized so far. For an action bound to a filter, the strict check returns -EPERM without dropping the temporary reference. This error also makes tcf_action_destroy() return before releasing subsequent entries. Any new action initialized between the bound action and the failing entry is leaked together with its reserved IDR slot, preventing reuse of its index. Use tcf_idr_release() to drop each reference held by the batch without rejecting bound actions. This allows cleanup to continue through all initialized entries and preserves the module reference release when an action is destroyed. Explicit action deletion and flushing retain their separate bind-count checks. Fixes: 55334a5db5cd ("net_sched: act: refuse to remove bound action outside") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260909070336.32979-2-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski commit fcfe64715b425262af1b36f498f9197f3537ceed Author: Vadim Nikitushkin Date: Thu Sep 10 17:34:51 2026 +0300 drm/ttm: apply the swapout bulk_move fix to the intended condition Commit 3db7d7d58341 ("drm/ttm: fix swapped-out resources never leaving their bulk_move range") landed in drm-misc-fixes with its one-line change applied to the wrong "if": the "if (ret)" after ttm_resource_try_charge() in ttm_bo_alloc_at_place() became "if (ret > 0)", while the "if (!ret)" after ttm_tt_swapout() in ttm_bo_swapout_cb() that the patch targeted was left untouched. ttm_resource_try_charge() returns 0 or a negative error code, so with "ret > 0" a failed dmem cgroup charge no longer fails the allocation. Restore that check and apply the intended change: ttm_tt_swapout() returns the number of pages swapped out on success, so the bulk_move removal must run for ret > 0. Fixes: 3db7d7d58341 ("drm/ttm: fix swapped-out resources never leaving their bulk_move range") Cc: stable@vger.kernel.org # v7.1+ Signed-off-by: Vadim Nikitushkin Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260910143451.65853-1-bub4z0r@gmail.com commit fc266a5dd99c4584c985b8b687c750598500a7ae Merge: e184a4a6f42355 b8bf9bfda5f62e Author: Jakub Kicinski Date: Thu Sep 10 08:55:12 2026 -0700 Merge branch '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2026-09-08 (idpf, ice) For idpf: Myeonghun Pak adds calls to disable DIM work and PTM to allow for proper cleanup. Josh adds check, and adjustment, for VLAN headers when processing RSC packets. For ice: Jake adds call to xa_destroy for xarray sched_node_ids; also moving it from port_info struct to ice_hw to simplify its lifecycle management. Jakub Kicinski stores trace event data as scalars instead of dereferencing pointers in TP_printk(), preventing use-after-free issues during event printing and eliminating double-dereference warnings. * '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: eth: ice: don't dereference pointers from TP_printk() ice: add missing xa_destroy for sched_node_ids idpf: account for VLAN header when parsing RSC packet header idpf: disable PTM on probe failure and on remove idpf: disable DIM work before freeing q_vectors ==================== Link: https://patch.msgid.link/20260908214502.528440-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski commit e10f2b7e28be3e1ce42a4be8fa9b0684d1d354ac Author: Takashi Iwai Date: Thu Sep 10 16:41:50 2026 +0200 ALSA: hdspm: Add a new PCI device ID (1d18:3fc6) for RME HDSPe AIO PCI express audio The RME HDSPe AIO PCI express audio card has a new PCI vendor ID (1d18) while keeping the same device ID (3fc6). The card seems working fine by just adding the new ID. While we're at it, use the standard macro to cleann up the existing PCI ID entry, too. Reported-by: AtmanActive Closes: https://lore.kernel.org/178674392532.7.10140952469564861620.1550442282@slmail.me Tested-by: AtmanActive Link: https://patch.msgid.link/20260910144204.973359-1-tiwai@suse.de Signed-off-by: Takashi Iwai commit e184a4a6f423550a25adce867036cdb1ff471745 Author: Eelco Chaudron Date: Tue Sep 8 16:15:17 2026 +0200 openvswitch: fix wrong flag value in get_ipv6_ext_hdrs() The ESP and AH cases in get_ipv6_ext_hdrs() used IPPROTO_FRAGMENT instead of OFPIEH12_FRAG when checking for out-of-order extension headers, causing the fragment header to not be recognised as a valid predecessor. The original code used IPPROTO_FRAGMENT (44) as a bitmask constant where OFPIEH12_FRAG (1 << 4 = 16) was intended. IPPROTO_FRAGMENT encodes bits 2, 3 and 5 (OFPIEH12_AUTH | OFPIEH12_DEST | OFPIEH12_ROUTER), but not bit 4 (OFPIEH12_FRAG). This caused incorrect OFPIEH12_UNSEQ verdicts in both the ESP and AH arms: the ESP arm failed to whitelist OFPIEH12_FRAG, while the AH arm accidentally whitelisted OFPIEH12_AUTH. With the fix, a packet with two AH headers now also gets OFPIEH12_UNSEQ in addition to OFPIEH12_UNREP, matching the ESP arm which already sets UNSEQ on a repeat, which is the intended behavior. Fixes: 28a3f0601727 ("net: openvswitch: IPv6: Add IPv6 extension header support") Reported-by: Paolo Abeni Reviewed-by: Aaron Conole Reviewed-by: Ilya Maximets Signed-off-by: Eelco Chaudron Link: https://patch.msgid.link/1b1582eb07550d71f3cbe210e5cb31eeb8d0ad86.1788876917.git.echaudro@redhat.com Signed-off-by: Jakub Kicinski commit b7ee18725f2292ab554aa96a101ae42d45f008bd Author: Zihan Xi Date: Tue Sep 8 11:58:39 2026 +0000 ipmr: account multicast table and route memory A netadmin in a user+net namespace can create many IPv4 and IPv6 multicast routing tables with MRT_TABLE and MRT6_TABLE. Each unseen id allocates an mr_table via the shared mr_table_alloc(), links it into the per-net list, and leaves it until netns teardown. Those objects were not charged to memcg, so the host unreclaimable slab grows with the table count. Account mr_table allocations with GFP_KERNEL_ACCOUNT and mark the IPv4/IPv6 MFC caches SLAB_ACCOUNT. This matches the established handling of IP addresses, routes and alternate interface names. Unresolved MFC entries are still allocated from softIRQ with GFP_ATOMIC and are not charged. They expire after 10 seconds and are bounded by the socket receive queue; see commit 0079ad8e8dc3 ("ipmr: remove hard code cache_resolve_queue_len limit"). Fixes: f0ad0860d01e ("ipv4: ipmr: support multiple tables") Fixes: d1db275dd3f6 ("ipv6: ip6mr: support multiple tables") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zihan Xi Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/050b58f7fc6b45da0fb12768ebb62d18fa46133d.1788784801.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski commit 6ca81bbc31cdc964e4b74d17b86215d4a810a56f Author: Donggeun Yoo Date: Tue Sep 8 19:59:58 2026 +0900 net: phy: dp83td510: handle the active-high LED polarity mode dp83td510_led_polarity_set() only recognizes PHY_LED_ACTIVE_LOW, so PHY_LED_ACTIVE_HIGH falls through to the default case and returns -EINVAL. of_phy_led() propagates the error, of_phy_leds() drops the LEDs registered so far and passes it on, and phy_probe() returns it. A device tree marking a DP83TD510 LED as 'active-high', which leds/common.yaml allows and ethernet-phy.yaml references for led@N nodes, thus leaves the mdio device unbound, so phy_attach_direct() falls back to the genphy driver, which cannot drive this 10BASE-T1L single-mode PHY, so the interface has no usable link. The callback initializes polarity to DP83TD510E_LED_POLARITY(index), which is the active-high setting, so the request is already satisfied and only the case label is missing. Cc: stable@vger.kernel.org Fixes: 5b281fe7e396 ("net: phy: dp83td510: introduce LED framework support") Signed-off-by: Donggeun Yoo Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260908105959.70453-3-donggeunyoo.kernel@gmail.com Signed-off-by: Jakub Kicinski commit e1406330d70e56dd44fa6fbafc86e77e5c80c122 Author: Runyu Xiao Date: Tue Sep 8 18:39:24 2026 +0800 net: macb: initialize PTP state before registering clock gem_ptp_init() registers the PTP clock before initializing bp->tsu_clk_lock and the TSU hardware. Since ptp_clock_register() publishes the PTP character device, userspace may invoke PTP callbacks before the lock and hardware are ready. In addition, gem_ptp_init() is called from both the interface open and resume paths. Reinitializing tsu_clk_lock there can reset the lock while timestamp processing is using it. This race is theoretical and has not been observed in practice. Initialize tsu_clk_lock once during probe and initialize the TSU before registering the PTP clock. Fixes: ab91f0a9b5f4 ("net: macb: Add hardware PTP support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netdev/20260904030439.3994047-1-runyu.xiao@seu.edu.cn/ Reviewed-by: Théo Lebrun Reviewed-by: Vadim Fedorenko Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260908103924.607033-1-runyu.xiao@seu.edu.cn Signed-off-by: Jakub Kicinski commit a2dc179481d18f6df7274522571b64dd50f31e81 Author: MD Danish Anwar Date: Tue Sep 8 14:38:56 2026 +0530 net: hsr: enable promiscuous mode on interlink port with fwd offload hsr_portdev_setup() skips promiscuous mode on non-master ports when hsr->fwd_offloaded is set. fwd_offloaded is derived only from the ring slaves' NETIF_F_HW_HSR_FWD bit, so this also skips it for the interlink port, which never gets forwarding offload. Without promiscuous mode, the interlink NIC drops unicast frames addressed to hsr_dev's MAC (e.g. SAN traffic to the RedBox), breaking RedBox whenever the ring is HW-offloaded. Fixes: 5055cccfc2d1 ("net: hsr: Provide RedBox support (HSR-SAN)") Signed-off-by: MD Danish Anwar Reviewed-by: Simon Horman Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260908090856.2876114-1-danishanwar@ti.com Signed-off-by: Jakub Kicinski commit 19b4ed644d68098cc62ab612727f40d30f43476c Author: Zihan Xi Date: Tue Sep 8 07:42:56 2026 +0000 ipv6: fix fib6 walker UAF on seq stop ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only widens the race. Fixes: 8d2ca1d7b5c3 ("ipv6: avoid high order memory allocations for /proc/net/ipv6_route") Cc: stable@vger.kernel.org Reported-by: Vega Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/89699735763f6c297584d7c2ff106239cc1e8ce0.1788837093.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski commit 5e38d732ec67a5b1f9a56e6c73add480c4b6030a Author: Lorenzo Bianconi Date: Mon Sep 7 23:46:45 2026 +0200 net: stmmac: fix TX descriptor availability check for TSO traffic stmmac_tso_xmit() estimates the number of free TX descriptors required by a TSO skb as: (skb->len - proto_hdr_len) / TSO_MAX_BUFF_SIZE + 1 which assumes the payload is split into TSO_MAX_BUFF_SIZE chunks. This underestimates the descriptors actually consumed by stmmac_tso_allocator(), since each fragment is mapped individually and so it needs at least one descriptor regardless of its size. Moreover, one descriptor is used for the L2/L3/L4 headers and, when the MSS changes, one more is consumed for the MSS context descriptor. For a highly fragmented TSO skb the check can therefore pass even when the ring has too few free slots. stmmac_tso_allocator() then writes past the available descriptors, overwriting descriptors still owned by the DMA engine, corrupting the TX ring. Add stmmac_tso_get_num_desc() to compute the exact number of descriptors needed for the header, the linear payload and each fragment, plus the MSS context descriptor when required, and use it in the availability check. Fixes: f748be531d70 ("stmmac: support new GMAC4") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260907-stmmac-fix-tso-nfrags-check-v1-1-328459906cdb@oss.qualcomm.com Signed-off-by: Jakub Kicinski commit 2ac09b5353fe6858411fdc8c6efa60d832e20f13 Author: Greg Marsden Date: Sat Sep 5 10:00:41 2026 -0700 net/rds: fix tcp stream corruption with large pages rds_message_map_pages() assigns PAGE_SIZE bytes to every scatterlist entry, even when total_len ends in a partial page. The RDS congestion map is defined as 8192 bytes, so on systems with PAGE_SIZE greater than 8192 the scatterlist maps bytes beyond the end of the congestion map. RDS-TCP transmits the SG contents according to those lengths, so the extra bytes become part of the TCP RDS stream and are interpreted as subsequent RDS message headers, corrupting the stream. Limit the final scatterlist mapping to the number of bytes remaining. This has no effect on systems with a 4K page size and allows RDS-TCP to be used on systems with 16K and larger page sizes. The RDS selftest, which previously hung on 16K pages, now passes. Fixes: 7875e18e0996 ("RDS: Message parsing") Signed-off-by: Greg Marsden Reviewed-by: Allison Henderson Link: https://patch.msgid.link/apxJjxvStibPI0AS@oracle.com Signed-off-by: Jakub Kicinski commit 9ff797e516dbc1ecb73701ec4c24055712d44411 Author: Jérémy Jean Date: Tue Sep 8 08:55:20 2026 +0000 RDMA/siw: Bound fragmented header copies by the remaining length siw_get_hdr() can receive an extended DDP/RDMAP header across more than one TCP callback. The first callback may receive most of the header, while the next one still limits the copy to hdrlen - MIN_DDP_HDR instead of the number of missing bytes. This makes the destination move past the end of the header and overwrite the receive state, including fpdu_part_rcvd. A later callback can then use a negative fpdu_part_rcvd value as a copy offset, which creates an OOB write. Use the number of header bytes already received when calculating the next copy length. Fixes: 754209850df8 ("RDMA/siw: Always consume all skbuf data in sk_data_ready() upcall.") Signed-off-by: Jérémy Jean Link: https://patch.msgid.link/20260908085520.1746329-1-Jeremy.Jean@oss.cyber.gouv.fr Assisted-by: Codex:gpt-6 Acked-by: Bernard Metzler Signed-off-by: Leon Romanovsky commit be4219dd98608736e13e0b790ef742b76a13254d Author: Johan Hovold Date: Mon Sep 7 11:51:30 2026 +0200 USB: cdc-acm: fix racy TIOCMIWAIT implementation Check the wakeup condition after adding the task to the waitqueue and updating the task state to avoid missing a racing modem status update or disconnect. Store the old icount on entry and do not update it in the completion handler to avoid missing events or reporting spurious ones (due to modem status changes before TIOCMIWAIT was called). Fixes: 5a6a62bdb925 ("cdc-acm: add TIOCMIWAIT") Cc: stable Cc: Oliver Neukum Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260907095130.130636-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 88c7e458af53ff781a3f1051708395892b325576 Author: Radhey Shyam Pandey Date: Sun Sep 6 18:49:42 2026 +0530 usb: typec: tipd: fix uninitialized typec_partner_desc in cd321x_update_work() cd321x_update_work() passes a stack-allocated typec_partner_desc to typec_register_partner() after initializing only usb_pd, accessory and identity. typec_register_partner() copies attach and deattach from the descriptor into the partner. With those fields left unset, garbage function pointers may be stored and later invoked from typec_partner_link_device() when a USB device is linked to the port. Uninitialized pd_revision and usb_capability similarly leak stack data through partner sysfs. Zero-initialize the descriptor so optional callbacks remain NULL and the remaining fields are zero. Fixes: 82432bbfb9e8 ("usb: typec: tipd: Handle mode transitions for CD321x") Cc: stable # 6.18+ Reviewed-by: Heikki Krogerus Signed-off-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260906131942.83153-3-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman commit c4b27b3605788bbf9e4251f3cd4ab94645ab036f Author: Radhey Shyam Pandey Date: Sun Sep 6 18:49:41 2026 +0530 usb: typec: tipd: fix uninitialized typec_partner_desc in tps6598x_connect() tps6598x_connect() passes a stack-allocated typec_partner_desc to typec_register_partner() after initializing only usb_pd, accessory and identity. typec_register_partner() copies attach and deattach from the descriptor into the partner. With those fields left unset, garbage function pointers may be stored and later invoked from typec_partner_link_device() when a USB device is linked to the port. Uninitialized pd_revision and usb_capability similarly leak stack data through partner sysfs. Zero-initialize the descriptor so optional callbacks remain NULL and the remaining fields are zero. Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Cc: stable # 5.15+ Reviewed-by: Heikki Krogerus Signed-off-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260906131942.83153-2-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman commit 8a0200d14acd9db388b85cd016e68a4e60d900ec Author: Syed Labeeq Sajid Bukhari Date: Thu Sep 10 19:03:43 2026 +0500 usb: storage: sierra_ms: reject short SWoC info transfers sierra_get_swoc_info() requests sizeof(struct swoc_info) (60) bytes from the device via usb_control_msg(), but its callers only treat a negative return value as failure. A device that answers the vendor-specific GetSwocInfo request with a short IN transfer is therefore accepted, leaving the tail of the freshly allocated (kmalloc(), non-zeroing) swoc_info buffer uninitialized. truinst_show() subsequently prints swocInfo->rev, swocInfo->LinuxSKU and swocInfo->LinuxVer from that buffer into the world-readable (0444) "truinst" sysfs attribute. An emulated/malicious USB device (VID 0x1199, PID 0x0fff) can exploit this to disclose up to 5 bytes of stale kernel heap memory (kmalloc-64) to unprivileged userspace, once per sysfs read, indefinitely. On kernels built without init_on_alloc this leaks recently freed heap contents. Only accept the transfer when the full structure was received. sierra_ms_init() already retries failed queries, so well-behaved devices are unaffected. Fixes: 32fe5e393455 ("USB Storage Sierra: TRU-Install feature update") Cc: stable Signed-off-by: Syed Labeeq Sajid Bukhari Assisted-by: Kimi:K2 [Kimi Code CLI] Link: https://patch.msgid.link/20260910140343.49371-1-syedlabeeq@gmail.com Signed-off-by: Greg Kroah-Hartman commit 90156585765b29304f07b0e4a1c56a969876fcfc Author: Amit Sunil Dhamne Date: Thu Sep 3 00:22:21 2026 +0000 usb: typec: tcpm: recover after failure to start the frs ams Reset the port if the tcpm fails to start the FAST_ROLE_SWAP AMS by initiating error recovery on it. This helps in cases where some cables (incorrectly) signal an FRS to an FRS capable port during disconnection. The TCPC autonomously starts sourcing VBUS on detecting the FRS signal. However, the VBUS sourcing is left on when the FAST_ROLE_SWAP AMS fails to start (as tcpm_sink_tx_ok is 0 as CC is open due to the cable disconnect). This is because the code sets the state to INVALID_STATE without resetting the port state. Log snippet before changes: [ 101.401960] AMS FAST_ROLE_SWAP start [ 101.401971] Sink TX No Go [ 101.401982] sourcing vbus [ 101.401987] VBUS on [ 101.402159] VBUS on [ 109.257809] CC1: 0 -> 0, CC2: 5 -> 0 [state SNK_READY, polarity 1, disconnected] [ 111.267442] VBUS on After changes: [ 70.541211] AMS FAST_ROLE_SWAP start [ 70.541220] Sink TX No Go [ 70.541228] state change SNK_READY -> ERROR_RECOVERY [rev3 NONE_AMS] [ 70.541362] VBUS on [ 70.541365] sourcing vbus [ 70.541367] VBUS on [ 70.541374] state change ERROR_RECOVERY -> PORT_RESET [rev3 NONE_AMS] [ 70.541410] disable vbus discharge ret:0 [ 70.543028] Setting usb_comm capable false [ 70.544009] Setting voltage/current limit 0 mV 0 mA [ 70.544034] polarity 0 [ 70.544239] Requesting mux state 0, usb-role 0, orientation 0 [ 70.555550] cc:=0 [ 70.555595] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev3 NONE_AMS] [ 70.555697] VBUS off [ 70.555702] VBUS VSAFE0V [ 70.555762] CC1: 5 -> 0, CC2: 0 -> 0 [state PORT_RESET, polarity 0, disconnected] [ 70.587794] VBUS off [ 70.587799] VBUS VSAFE0V [ 70.655672] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms] [ 70.655682] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [rev3 NONE_AMS] [ 70.655686] Start toggling [ 70.656274] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] Fixes: 0908c5aca31e ("usb: typec: tcpm: AMS and Collision Avoidance") Cc: stable Signed-off-by: Amit Sunil Dhamne Reviewed-by: Badhri Jagan Sridharan Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260903-frs-error-handling-v1-1-ad0fee541847@google.com Signed-off-by: Greg Kroah-Hartman commit fd772af9512cdecb83de34a461801533828e77fd Author: Runyu Xiao Date: Fri Sep 4 14:53:23 2026 +0800 USB: dwc2: shut down wakeup timer before freeing HCD state dwc2_wakeup_detected() accesses the DWC2 host state and can rearm the wakeup timer. dwc2_hcd_free() currently deletes the timer only after freeing host-owned state, and timer_delete() does not synchronize a callback or prevent it from being queued again. Stop and shut down the timer in dwc2_hcd_release(), before the HCD resources are freed. This covers both the HCD initialization error path and normal HCD removal. Fixes: 7359d482eb4d ("staging: HCD files for the DWC2 driver") Cc: stable Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Reviewed-by: Thinh Nguyen Link: https://patch.msgid.link/20260904065323.4047026-1-runyu.xiao@seu.edu.cn Signed-off-by: Greg Kroah-Hartman commit 3d9bbf0ffeb9b7ac1b6ad06b52e037870a7e0c63 Author: Radhey Shyam Pandey Date: Wed Sep 2 20:24:04 2026 +0530 usb: dwc3: am62: Fix runtime PM usage count leak on probe error path dwc3_ti_probe() takes a runtime PM reference with pm_runtime_get_noresume() before creating the dwc3 core child device, and releases it with pm_runtime_put_autosuspend() once probe has succeeded. The err_pm_disable error path only disables runtime PM, so the reference taken a few lines earlier is never dropped. The usage counter lives in struct device and is not reset when the driver is unbound, so the leaked reference outlives the failed probe. If the device is probed again, through a manual rebind or a module reload, the counter starts at one instead of zero and the pm_runtime_put_autosuspend() on the success path can no longer bring it back down. The wrapper then stays runtime resumed for good and autosuspend never kicks in. Drop the reference before disabling runtime PM, matching the ordering already used in dwc3_ti_remove(). Fixes: e8784c0aec03 ("drivers: usb: dwc3: Add AM62 USB wrapper driver") Cc: stable Assisted-by: Claude:claude-opus-5 Signed-off-by: Radhey Shyam Pandey Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260902-dwc3-am62-rpm-fix-v1-1-7a2807e33307@amd.com Signed-off-by: Greg Kroah-Hartman commit aebbc7d63407f843a1c74806041792db65d69a51 Author: Orgad Shaneh Date: Tue Sep 1 19:30:29 2026 +0000 usb: octeon-hcd: sleep on an hrtimer for far-off periodic transfers cvmx_usb_schedule() enables the SOF interrupt whenever any pipe has next_tx_frame in the future, and leaves it enabled until the transfer is due. An interrupt endpoint keeps such a deadline pending permanently, so a single attached hub (status pipe polled every 256ms) costs an interrupt on every SOF - 8000/s in high-speed mode, forever. On a 300MHz CN5020 that is measurably ~20% of one core spent counting frames. The frame counter is resynchronized from HFNUM at the top of every poll, so the driver does not actually need to see every SOF to know when a deadline arrives. Sleep on an hrtimer when the nearest deadline is more than a few frames away (one high-speed frame is 125us) and keep SOF interrupts only for deadlines that are imminent - or far enough away to risk the 16383-frame HFNUM wrap, where the interrupt path still tracks the counter extension. Measured on a CN5020 board with one 4-port hub attached and idle: 8200 -> 4 USB interrupts/s, with no change in enumeration or transfer behavior. Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh Link: https://patch.msgid.link/20260901193100.1352110-3-orgads@gmail.com Signed-off-by: Greg Kroah-Hartman commit 22bce6d2b3fd9e845d71e0037b6929913301462d Author: Orgad Shaneh Date: Tue Sep 1 19:30:28 2026 +0000 usb: octeon-hcd: fail the probe when the USB core does not respond If the USBN clock/PHY setup did not actually bring the core up (wrong board reference-clock configuration, for instance), every USBC CSR reads as all-ones and initialization marches on programming garbage, ending in timeouts or a wedge deep in the FIFO flush. Read GHWCFG3 - a hardwired configuration register that can be neither 0 nor all-ones on a live core - right before core initialization, and give up cleanly if the core is not answering. Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh Link: https://patch.msgid.link/20260901193100.1352110-2-orgads@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4c7a1b9f1f1979f2b3b69428ada12680695159c2 Author: Orgad Shaneh Date: Tue Sep 1 19:30:27 2026 +0000 usb: octeon-hcd: fix the FIFO-flush timeout computation cvmx_wait_tx_rx() computes its 100us deadline from (u64)octeon_get_clock_rate - the address of the function, not its return value; the parentheses have been missing since the CVMX_WAIT_FOR_FIELD32 macro became a function. The cast makes it compile silently, and the resulting deadline is effectively infinite. On a healthy controller the flush bit clears on the first read and nothing is noticed. On a controller whose PHY did not come up (for example when the reference-clock configuration is wrong for the board), txfflsh/rxfflsh never clear and probe spins forever in __delay() - observed as a hard hang with a soft-lockup splat on a CN5020 board, where the board watchdog then resets the system with no console output. Call the function, restoring the 100us timeout the code always intended. Fixes: 3e195a80e096 ("Staging: octeon-usb: Replaces CVMX_WAIT_FOR_FIELD32 macro with a function") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh Link: https://patch.msgid.link/20260901193100.1352110-1-orgads@gmail.com Signed-off-by: Greg Kroah-Hartman commit 29480b05e6e226594dc11ccf2a036fbd5cdd0e42 Author: Lovekesh Solanki Date: Thu Sep 3 16:59:03 2026 +0530 usb: hub: use shorter 120ms post resume hold for SS root hubs Holding a USB3 hub PM runtime reference for 200ms at hub resume triggers an AMD platform issue. Users running Android adb report crashes after adb has been polling and waking up the USB subsystem once a second for some time. Vendors are working on a solution. Disabling USB runtime PM is one way to prevent this issue, but it is also proven that reducing the hold time to 120ms in resume also mitigates it. See Link for more details. Reducing the hold time to 120ms for the USB3 roothub is in itself a valid change and optimization, as the current 200ms is excessive: a root hub has no upstream suspended hub whose wake propagation needs to be accounted for, but still need some time for USB3 link training to complete. Keep the 200ms hold for external hubs that commit 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices behind suspended hubs") is intended for. Reported-by: Mathieu Fluhr Link: https://lore.kernel.org/all/CAPyJwA_D9qw0T72f8zwM1yKjP+To=maVANbcdsWM7yRmbBxYvw@mail.gmail.com/ Cc: stable Fixes: 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices behind suspended hubs") Signed-off-by: Lovekesh Solanki Acked-by: Mathias Nyman Link: https://patch.msgid.link/20260903112903.542719-1-lovekeshsolanki00@gmail.com Signed-off-by: Greg Kroah-Hartman commit c5df31f10880737d13b75eff42faee7accb9f956 Author: Marian Rotariu Date: Thu Aug 6 11:53:02 2026 +0300 usb: typec: tipd: don't send GAID when probe fails in APP mode When probe fails after the chip was already in APP mode (booted from EEPROM), the err_reset_controller path unconditionally calls tps->data->reset(), which for tps25750 sends the GAID 4CC command. GAID transitions the chip from APP back to PTCH, causing a second probe attempt that sees PTCH mode and tries to load the firmware from /lib/firmware, instead of reading the EEPROM as it should. The err_reset_controller path can be triggered by -EPROBE_DEFER from the probe sequence. GAID should only be sent when the controller actually loaded firmware at probe time. The abnormal behavior was seen on a tps25751d that has an EEPROM connected to it. Fixes: d49f90822015 ("usb: typec: tipd: add init and reset functions to tipd_data") Cc: stable Signed-off-by: Marian Rotariu Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260806085302.1307606-1-marian.c.rotariu@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4c46beb807efcc93f5899ebe1f5958248eb296c6 Author: Long Li Date: Fri Sep 4 13:26:40 2026 -0700 net: mana: restore the XDP program pointer when pre-allocation fails mana_xdp_set() publishes the new program into apc->bpf_prog before it allocates anything, because mana_pre_alloc_rxbufs() sizes the buffers from it via mana_get_rxbuf_cfg(). When that allocation fails the function returns the error directly, skipping the err_dealloc_rxbuffs label which is the only place that restores the previous pointer. The attach is reported as failed, so the BPF core drops the reference it held for the caller and the program can be freed, while apc->bpf_prog still points at it. The next consumer of mana_xdp_get() - typically mana_chn_setxdp() from mana_alloc_queues() on the following ifup, or after a TX timeout reset - then calls bpf_prog_add() on freed memory. This is reachable from an ordinary "ip link set dev ethX xdp obj ..." whenever the per-queue RX buffer pre-allocation cannot be satisfied. Restore the previous program on that error path. Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") Signed-off-by: Long Li Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260904202640.3900685-1-longli@microsoft.com Signed-off-by: Jakub Kicinski commit 36a45facedd5c8e73bfb2403f8b0dbff05124c9c Author: Donggeun Yoo Date: Thu Sep 3 11:28:38 2026 +0900 net: phy: dp83867: handle the active-high LED polarity mode Commit a274465cc3be ("net: phy: support 'active-high' property for PHY LEDs") added PHY_LED_ACTIVE_HIGH and made of_phy_led() set the matching bit in the modes mask when a LED node carries the 'active-high' property. dp83867 was not part of that series. dp83867_led_polarity_set() only recognizes PHY_LED_ACTIVE_LOW, so PHY_LED_ACTIVE_HIGH falls through to the default case and returns -EINVAL. of_phy_led() propagates the error, of_phy_leds() drops the LEDs registered so far and passes it on, and phy_probe() fails. A device tree marking a DP83867 LED as 'active-high', which leds/common.yaml allows and ethernet-phy.yaml references for led@N nodes, thus stops the PHY from probing. Active high is what the function programs when no polarity mode is requested at all, so the initial value of polarity already satisfies the request and only the case label is missing. The same series updated mxl-gpy in commit eb89c79c1b8f ("net: phy: mxl-gpy: correctly describe LED polarity") and aquantia in commit 9d55e68b19f2 ("net: phy: aquantia: correctly describe LED polarity override"). Fixes: a274465cc3be ("net: phy: support 'active-high' property for PHY LEDs") Signed-off-by: Donggeun Yoo Link: https://patch.msgid.link/20260903022839.4006614-1-donggeunyoo.kernel@gmail.com Signed-off-by: Jakub Kicinski commit 4f4b743c2d2bbc336cb164d9d3d2ed6956ad8437 Author: Ratheesh Kannoth Date: Fri Sep 4 14:21:13 2026 +0530 octeontx2-af: fix PF/CGX debugfs PCI bus lookup rvu_dbg_rvu_pf_cgx_map_display() locates each RVU PF PCI device via pci_get_domain_bus_and_slot() when printing the PF-to-CGX map. It assumed PF0 always sits on PCI bus 1 and derived other PF bus numbers as pf + 1, but the AF device can be enumerated on a different bus. Use rvu->pdev->bus->number as the base bus instead, so each PF lookup uses pf + start on systems where RVU functions are on contiguous buses but do not start at bus 1. Fixes: e2fb373038654 ("octeontx2-af: Display CGX, NIX and PF map in debugfs.") Signed-off-by: Subbaraya Sundeep Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260904085114.3385530-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski commit e240919ca727776f16a468d3d90686dc82cfe9cb Author: Deepanshu Kartikey Date: Sun Sep 6 20:16:29 2026 +0530 xfs: take hm->lock in xfs_ioc_health_monitor() before insert __xfs_healthmon_insert() asserts that hm->lock is held (lockdep_assert_held), but xfs_ioc_health_monitor() called it right after allocating hm, before ever taking the lock, triggering a lockdep warning. Take hm->lock around the call. Fixes: b3a289a2a9397 ("xfs: create event queuing, formatting, and discovery infrastructure") Reported-by: syzbot+ccdf3469f5f653bff7ac@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ccdf3469f5f653bff7ac Signed-off-by: Deepanshu Kartikey Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino commit 50ba24ccb9a94f61c707209442ca23d98c815052 Author: Anuj Gupta Date: Mon Sep 7 10:27:39 2026 +0300 xfs: set IOMAP_F_INTEGRITY for zoned writes on integrity devices xfs_iomap_set_anon_write does not set IOMAP_F_INTEGRITY based on bdev_has_integrity_csum(), so file system PI generation is silently skipped for zoned writes on integrity-enabled devices, and left to the block layer PI generation. Fixes: 6bbb4d96f797 ("xfs: support T10 protection information") Signed-off-by: Anuj Gupta [hch: ported to the recently introduced xfs_iomap_set_anon_write()] Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino commit 761e015e5a54851043c3b5bb7cfb6f539b01a35e Author: Christoph Hellwig Date: Mon Sep 7 10:33:09 2026 +0300 xfs: avoid extra cache flushes for multi-device file systems in xfs_fsync When xlog_force_lsn sets log_flushed, it has just called xlog_force_iclog through xlog_force_and_check_iclog, which sets XLOG_ICL_NEED_FLUSH before writing out the head iclog. This means that we already flushed the log, data, and (with the recent fix) RT devices before writing out the iclog start record and no extra cache flushed is required. This optimizes the external log case, and fixes a performance regression due to double RT dev flushes with "xfs: also flush the RT device cache in xlog_write_iclog". The explicit flush of the data that the device resides on when no iclog was written out is still required. Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit c84455c683eb0b0397b0f5c5f5ce5cd82572a23f Author: Christoph Hellwig Date: Mon Sep 7 10:33:08 2026 +0300 xfs: don't continue on error in xfs_fsync As soon as we get an error from cache flushing or log forcing, there is no point in continuing as the data integrity is already impacted. Return the error instead of continuing to do more work. Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit ad0033e2dbd3ecc063dfe613060da5cbab9a4970 Author: Christoph Hellwig Date: Mon Sep 7 10:33:07 2026 +0300 xfs: also flush the RT device cache in xlog_write_iclog The cache flush before writing the CIL start record no only needs to ensure any metadata covered by the overwritten part of the log is on stable storage, but also that any data pointed to by metadata logged is on stable storage, as otherwise log recovery could created allocated blocks that point to stale data. Fortunately the code already handles this right for the data device, but it also needs to flush the RT device for this to work for data on the RT device. Also update the comments to explicitly mention this case. This omission goes back to the first days of cache control in XFS. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit eaf580538eb1be3d162400d04c4b7dc4c627296b Author: Darrick J. Wong Date: Tue Sep 8 23:04:19 2026 -0700 xfs: bail out on bitmap errors in xrep_agfl_fill LOLLM also points out that the xagb_bitmap_set call in xrep_agfl_fill can fail, but we don't check the result of xagb_bitmap_walk, so we silently drop the error and proceed with inconsistent incore data. That shouldn't be allowed. Cc: stable@vger.kernel.org # v6.6 Fixes: 014ad53732d2ba ("xfs: use per-AG bitmaps to reap unused AG metadata blocks during repair") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit 3466dfef0a20f842363958deea55be9f1d26818a Author: Darrick J. Wong Date: Tue Sep 8 23:04:04 2026 -0700 xfs: snapshot old AGFL before rewriting it LOLLM complains that we can't undo an attempt at fixing the AGFL if anything goes wrong during the rewrite, so take a snapshot of the whole buffer so that we can restore it. Move the xrep_agfl_update_agf call so that we only update the AGF if the AGFL update is 100% successful. While we're at it, fix leaking the used_extents bitmap if the disunion operation fails. Cc: stable@vger.kernel.org # v4.19 Fixes: 0e93d3f43ec7d3 ("xfs: repair the AGFL") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 341f03865d0793e7df22c4661e04047c092e5ac2 Author: Darrick J. Wong Date: Tue Sep 8 23:03:48 2026 -0700 xfs: remove redundant function declaration Remove this useless code. Signed-off-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit d3dc979a49df6d48f8e137034d19d9b35afd07d8 Author: Darrick J. Wong Date: Tue Sep 8 23:03:33 2026 -0700 xfs: report runtime failures in scrub Add a new counter so that we can track the number of runtime failures encountered during scrubs. Signed-off-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 0ae61c331ec552ad0c278c5c48a1c4ccb90b4bab Author: Darrick J. Wong Date: Tue Sep 8 23:03:17 2026 -0700 xfs: report healthy filesystem events in scrub stats LOLLM also notices that I forgot to expose the "clean bill of health" scrub stats. Fix that. Cc: stable@vger.kernel.org # v6.9 Fixes: a1f3e0cca41036 ("xfs: update health status if we get a clean bill of health") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 568a1588b906780dc3e9be56a61217afb4f7800e Author: Darrick J. Wong Date: Tue Sep 8 23:03:02 2026 -0700 xfs: snapshot scrub stats when rendering them LOLLM complains about concurrency problems in the scrub stats code because xchk_stats_format doesn't synchronize in any way with updates. These stats are only reported through debugfs so I don't think it really matters, but I guess I exist to make bots happy now. Note: We snapshot the entire stats object with a spinlock so that we don't have to worry about users seeing slightly weird numbers (e.g. invocations has incremented but none of the outcomes have been yet) if we race with xchk_stats_merge_one. This isn't a hot path. Cc: stable@vger.kernel.org # v6.6 Fixes: d7a74cad8f4513 ("xfs: track usage statistics of online fsck") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 3db7d7d583419f7b1f2e141e36418802dbb25cf8 Author: Vadim Nikitushkin Date: Wed Sep 9 23:50:28 2026 +0300 drm/ttm: fix swapped-out resources never leaving their bulk_move range ttm_tt_swapout() returns the number of pages swapped out on success and a negative error code on failure; for a populated ttm it never returns zero. Commit b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") moved the bulk_move bookkeeping in ttm_bo_swapout_cb() under "if (!ret)", so the ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() pair is now skipped on every successful swapout. The equivalent change for the shrinker in commit 1d59f36e95f7 ("drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure") tests "lret > 0", which is what was intended here as well. Before b2ed01e7ad3d the resource was taken off the bulk_move before the swapout; since then a swapped-out resource stays inside its BO's bulk_move range (and on the manager LRU) although it is unevictable. When it is later freed or the BO leaves the bulk_move (ttm_resource_free(), ttm_bo_set_bulk_move() via amdgpu_vm_bo_del()), ttm_resource_del_bulk_move() skips it because of its !ttm_resource_unevictable() guard, so a range endpoint in pos->first / pos->last is left pointing at freed memory. The next ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() on that cursor is a use-after-free, seen as the resv WARN in ttm_lru_bulk_move_add(), "list_del corruption" in ttm_resource_move_to_lru_tail() or a NULL dereference in ttm_resource_manager_next() -- minutes to hours after a hibernation, or at process exit / reboot following one. Samuel Ainsworth's analysis of drm/amd issue 5387 (see Link) identified the dangling cursor; the missing removal at swapout time is the reason it dangles. Testing the condition for success restores the removal. On an AMD Phoenix APU (ASUS UM3406GA, gfx1103) running suspend-then-hibernate on a 7.0.y stable kernel carrying the backport (Ubuntu 7.0.0-31) the bug crashed 5 of 18 hibernation cycles; a function profile of one hibernation showed 336 ttm_tt_swapout() calls and zero ttm_resource_del_bulk_move_unevictable() calls. With this change the removal happens for every swapped-out resource and 12 further cycles were clean. Fixes: b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") Cc: stable@vger.kernel.org # v7.1+ Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5387 Link: https://lore.kernel.org/dri-devel/CAHYiNPa6aVacJoLOje-qZ1GyYx-9p0tN4NuP8D_eSL+UJeevXw@mail.gmail.com/ Signed-off-by: Vadim Nikitushkin Reviewed-by: Thomas Hellström Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260909205028.13799-1-bub4z0r@gmail.com commit e22a3627b7151754f07f90ea3d1ab6e85f5d93f4 Author: Leon Romanovsky Date: Thu Sep 10 09:35:13 2026 -0400 RDMA/efa: Keep EQ resources alive while IRQ is registered The completion IRQ handler accesses the EQ state and DMA buffer. Its IRQ was registered before that state was initialized, while teardown released the buffer before free_irq() synchronized the handler. Initialize the EQ without arming it, register the IRQ, and then arm it. Reverse the resource order during teardown by freeing the IRQ before destroying the EQ. Fixes: 2a152512a155 ("RDMA/efa: CQ notifications") Link: https://patch.msgid.link/20260907-use-after-free-of-admin-queue-struct-v1-2-dd9d9267fbf4@nvidia.com Reviewed-by: Michael Margolin Signed-off-by: Leon Romanovsky commit e08aca85c02ff290f785f07acae758f0daf5f49e Author: Leon Romanovsky Date: Thu Sep 10 09:35:13 2026 -0400 RDMA/efa: Keep admin queues alive while IRQ is registered The management IRQ handler accesses both the admin completion queue and the async event queue. The driver registered the IRQ before constructing these queues and destroyed them before freeing the IRQ, so the handler's lifetime was not contained by the resources it accesses. Initialize the queues with interrupts masked, request the IRQ, and then switch to interrupt mode. On removal, reset the device and free the IRQ before destroying the queues. Also reset the device before destroying the queues if IRQ registration fails, because the device already has their DMA addresses. Fixes: b7f5e880f377 ("RDMA/efa: Add the efa module") Link: https://patch.msgid.link/20260907-use-after-free-of-admin-queue-struct-v1-1-dd9d9267fbf4@nvidia.com Reviewed-by: Michael Margolin Signed-off-by: Leon Romanovsky commit 985a663bf00799c1daf1c5789efa6406958780c8 Author: Faicker Mo Date: Tue Sep 8 12:06:29 2026 +0800 net: net_failover: Fix the deadlock in net_failover_slave_name_change() This is a sibling fix of commit b84c5632c7b3 ("net: net_failover: Fix the deadlock in slave register"). There is netdev_lock_ops() in the upper callers, so using netif_open() instead of dev_open(). Call Trace: __schedule+0x2bb/0x650 schedule+0x27/0xb0 schedule_preempt_disabled+0x15/0x30 __mutex_lock.constprop.0+0x550/0xaf0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3b/0x50 dev_open+0x3b/0xe0 net_failover_slave_name_change+0x22/0x40 failover_event+0xd4/0x1e0 notifier_call_chain+0x62/0xf0 raw_notifier_call_chain+0x16/0x30 call_netdevice_notifiers_info+0x50/0x80 netif_change_name+0x200/0x330 do_setlink.isra.0+0xb12/0xdf0 ? security_capable+0x9a/0x1e0 ? ns_capable+0x31/0x60 rtnl_setlink+0x302/0x670 ? netlink_recvmsg+0x296/0x340 ? security_capable+0x9a/0x1e0 ? __pfx_rtnl_setlink+0x10/0x10 rtnetlink_rcv_msg+0x384/0x460 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 netlink_rcv_skb+0x61/0x120 rtnetlink_rcv+0x15/0x30 netlink_unicast+0x28f/0x3c0 netlink_sendmsg+0x216/0x450 __sys_sendto+0x222/0x230 __x64_sys_sendto+0x24/0x40 x64_sys_call+0x1d5d/0x2390 do_syscall_64+0x105/0x5a0 ? do_syscall_64+0x140/0x5a0 ? exc_page_fault+0x94/0x1e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 7e4d784f5810 ("net: hold netdev instance lock during rtnetlink operations") Signed-off-by: Faicker Mo Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260908040708.3972058-1-faicker.mo@gmail.com Signed-off-by: Paolo Abeni commit 7ed1e3070c9b4bbd67d5519e14711038dd53ab13 Author: Alex Bereza Date: Tue Aug 18 09:36:29 2026 +0200 dmaengine: xilinx_dma: Fix hardware buffer descriptor chain after cyclic DMA Using the DMA in cyclic mode modifies the hardware buffer descriptor chain in xilinx_dma_prep_dma_cyclic so that the last descriptor used by the cyclic transfer points back to the first descriptor, but it never restores the original descriptor ring. This breaks using non-cyclic mode after cyclic mode with an error like: xilinx-vdma 86000000.dma: Channel 00000000354d5c8d has errors 100, cdr 6de40000 tdr 6de40400 The only way to get out of this error state is to rebuild the hardware buffer descriptor ring by releasing and re-acquiring the channel. Fix using non-cyclic mode after cyclic mode by always restoring the original buffer descriptor ring in the same manner as it is set up by xilinx_dma_alloc_chan_resources(). Fixes: 23059408b6a3 ("dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario") Signed-off-by: Alex Bereza Reviewed-by: Frank Li Reviewed-by: Suraj Gupta Link: https://patch.msgid.link/20260817-fix-hw-buf-desc-after-cyclic-mode-v1-1-1fe47e701d6c@bereza.email Link: https://patch.msgid.link/20260818-fix-hw-buf-desc-after-cyclic-mode-v2-1-530ff44c6a81@bereza.email Signed-off-by: Vinod Koul commit ccbe7540e4aad0d1c3acc249697350b93ccb8025 Author: Vladislav Karmanov Date: Tue Sep 8 17:52:13 2026 +0300 net: phy: mediatek-ge: disable EEE on the MT7530 PHY The MT7530 internal GE PHY advertises EEE by hardware default, but its EEE support is defective: with EEE advertised, some link partners fail to establish a stable link. On a 2-pair (4-wire) cable where both ends advertise gigabit, 1000BASE-T training cannot succeed, and instead of falling back to 100 Mbps the port loops, so no link or DHCP lease is ever obtained. MediaTek confirms the hardware is the root cause (Landen Chao, 2021): "EEE of the 10-year-old MT7530 internal gephy has many IOT problems, so it is recommended to disable its EEE." mtk_gephy_config_init() used to clear the EEE advertisement early, but commit af3b4b0e59de ("net: phy: mediatek-ge: do not disable EEE advertisement") removed that on the rationale that the DSA subdriver already performs an early disable. That holds for MT7531, whose mt7531_setup() clears MDIO_AN_EEE_ADV on each switch PHY, but not for the MT7530 PHY: neither the MT7621 integrated switch nor the dedicated MT7530 IC ever had such a loop, so removing it left those boards without any working early EEE disable and the link flapping came back. Since the broken hardware is the PHY, fix it in the PHY driver so it covers all users of this PHY, integrated in a switch or standalone: - clear MDIO_AN_EEE_ADV in probe(), as early as possible, before anything can negotiate EEE with the link partner; - clear it again in config_init() and call phy_disable_eee() there. config_init() is what phy_init_hw() replays after a PHY reset, when the register is back at its EEE-advertising hardware default, and it runs after of_set_phy_eee_broken() in phy_probe(), so the eee_disabled_modes mask survives and neither phylib nor userspace can re-enable EEE. dp83867 disables broken EEE from config_init() the same way. Auto-negotiation then falls back to a stable 100 Mbps link instead of looping at gigabit. Tested on ASUS RT-AX53U (MT7621): with a 2-pair cable on the WAN port, a single clean 100 Mbps link comes up and a DHCP lease is obtained, where the unpatched driver loops. Fixes: af3b4b0e59de ("net: phy: mediatek-ge: do not disable EEE advertisement") Suggested-by: Andrew Lunn Signed-off-by: Vladislav Karmanov Link: https://patch.msgid.link/20260908145213.3976508-1-vladislav.karmanov.dev@gmail.com Signed-off-by: Paolo Abeni commit 125755776bc6d4dd53eaf551c87e3d460625d638 Author: Pavel Begunkov Date: Fri Sep 4 14:43:07 2026 +0100 tcp: reject non zerocopy devmem tx Devmem tcp tx doesn't work without zero-copy, however it's not currently enforced if NETIF_F_SG isn't present. In this case, tcp_sendmsg_locked() will try the copy path and try to copy data from an iovec which consists of offsets into the dma-buf and would normally fail. Moreover, d9c56501c72fd ("net: tcp: block mixing readable and unreadable frags") relies on that and assumes that the devmem binding is present IFF we're using the zero-copy path, which can be used to mix net-iov and pages in a single skb, and break invariants. Let's reject devmem tx without zero-copy. Note, the parameter check the patch is modifying is too loose, we can create an io_uring request with dmabuf_id and all ZC flags, but which won't have the binding. We replace it with stricter validation. Fixes: bd61848900bff ("net: devmem: Implement TX path") Fixes: d9c56501c72fd ("net: tcp: block mixing readable and unreadable frags") Signed-off-by: Pavel Begunkov Reviewed-by: Mina Almasry Link: https://patch.msgid.link/fdc2478d8f21268d7078556409887d8e6ba0ad32.1788529053.git.asml.silence@gmail.com Signed-off-by: Paolo Abeni commit c5c95dbdc9011a56359df4dc00be829bbcc0b036 Author: Jon Hunter Date: Fri Aug 21 14:01:24 2026 +0100 soc/tegra: pmc: Fix uninitialised clock rate For legacy 32-bit Tegra devices, the warning in the tegra_pmc_enter_suspend_mode() function is being triggered because the early_pmc->rate variable is never configured and hence, always 0. This issue started occurring after updating the PMC driver to create the PMC context dynamically which causes the 'rate' to be set in the new dynamic context, but missed updating the rate in the early PMC context. Fix this by initialising the early_pmc->rate variable for 32-bit Tegra devices when the rate for the PMC context is initialised. Fixes: 4d61f0342689 ("soc/tegra: pmc: Create PMC context dynamically") Signed-off-by: Jon Hunter [treding@nvidia.com: move assignment to existing #ifdef block] Signed-off-by: Thierry Reding commit 63b269ec537dc0fd26d0bd64872c26860d108c9d Author: Fan Wu Date: Tue Sep 8 06:02:15 2026 +0000 usb: typec: ucsi: glink: fix use-after-free of ucsi on remove The pmic_glink client is released by the devres cleanup, which runs after pmic_glink_ucsi_remove() has returned, so its notification callbacks can queue work until then. Work that runs after ucsi_unregister() has been called touches freed state: it dereferences the connector array that ucsi_unregister() freed, or registers and unregisters the instance a second time. Disable both work items with disable_work_sync() before unregistering, and unregister only if the instance is still registered. This issue was found by an in-house static analysis tool. Fixes: 62b5412b1f4a ("usb: typec: ucsi: add PMIC Glink UCSI driver") Cc: stable Assisted-by: Codex:gpt-5.6 Link: https://lore.kernel.org/r/20260227190430.889-1-nathan.c.rebello@gmail.com Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260908060216.616045-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit f6504be006aa4bb4bd26285f410a885c17920d65 Author: Sascha Hauer Date: Mon Aug 17 22:44:33 2026 +0200 dmaengine: pxa: fix double counting of the hw descriptors pxad_alloc_desc() was converted from kzalloc(struct_size(sw_desc, hw_desc, nb_hw_desc), GFP_NOWAIT) to kzalloc_flex(), which sets the __counted_by() counter sw_desc->nb_desc itself - but only where the compiler has __builtin_counted_by_ref(), so from gcc 15.1 or clang 22.1 on. The loop below it still increments nb_desc, which makes it come out doubled there and correct elsewhere. nb_desc is what pxad_free_desc() iterates over and what set_updater_desc() indexes from, so set it explicitly and drop the increment. The error path has to lower it to the number of descriptors allocated so far, otherwise pxad_free_desc() would free entries that were never allocated. Fixes: 69050f8d6d075 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types") Assisted-by: Claude:claude-opus-5 Signed-off-by: Sascha Hauer Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20260817-dmaengine-pxa-v1-1-850c215c1196@pengutronix.de Link: https://patch.msgid.link/20260817-dmaengine-pxa-v2-1-f42ab0569a48@pengutronix.de Signed-off-by: Vinod Koul commit 310c2d4608d8c1a2baa57db1dfd319c5c40cf4a1 Author: Takashi Iwai Date: Tue Sep 1 16:52:46 2026 +0200 usb: gadget: midi2: Fix the jack descriptor array sizes The jack in/out descriptor arrays in struct f_midi2_usb_config have the size of MAX_CABLES, which look reasonable -- but it turned out to be incorrect. Namely, the entries for those arrays are added from both inputs and outputs, hence for each loop cycle, it adds two, ended up with as twice as the expected size. This inconsistency may result in potential OOB when a large number of jacks are set up via configfs, although the max number of cables (the loop count) is limited to MAX_CABLES. For addressing it, correct the jack_ins & jack_outs array sizes to twice, MAX_CABLES * 2. Fixes: 856fa444b098 ("usb: gadget: midi2: Dynamically create MIDI 1.0 altset descriptors") Cc: stable Reported-by: syzbot+c35f34092a4bc9855be6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c35f34092a4bc9855be6 Link: https://lore.kernel.org/20260826134606.127250-1-eadavis@sina.com Cc: Edward Adam Davis Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260901145512.785142-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 9096bdc8d930147f7c39a493a859acbd3a8485d8 Author: Christian Lugnberg Date: Mon Aug 17 15:51:23 2026 +0200 dmaengine: sun6i: fix undefined behaviour in sun6i_dma_tx_status sun6i_dma_tx_status() calls vchan_find_desc() to look up the virtual descriptor for a given cookie, before checking whether the pointer vd is NULL: vd = vchan_find_desc(&vchan->vc, cookie); txd = to_sun6i_desc(&vd->tx); /* vd may be NULL here */ if (vd) { for (lli = txd->v_lli; ...) vchan_find_desc() returns NULL when the descriptor has already been completed or is in-flight on a physical channel and no longer present in the virtual channel's descriptor list. When vd is NULL, to_sun6i_desc() is called unconditionally on &vd->tx before the NULL check, which is undefined behaviour. Move the call inside the if (vd) guard to ensure it is only reached with a valid pointer. vd = vchan_find_desc(&vchan->vc, cookie); if (vd) { struct sun6i_desc *txd = to_sun6i_desc(&vd->tx); for (lli = txd->v_lli; ...) Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Christian Lugnberg Reviewed-by: Frank Li Link: https://patch.msgid.link/20260817135723.12807-3-christian.lugnberg@soundtrack.io Signed-off-by: Vinod Koul commit c90b6973daa37f4c283342dff881ae001dea4fe6 Author: Christian Lugnberg Date: Mon Aug 17 15:51:22 2026 +0200 dmaengine: sun6i: fix non-atomic read of DMA position registers sun6i_get_chan_size() reads DMA_CHAN_LLI_ADDR and DMA_CHAN_CUR_CNT in two separate readl() calls with no synchronisation between them: pos = readl(pchan->base + DMA_CHAN_LLI_ADDR); bytes = readl(pchan->base + DMA_CHAN_CUR_CNT); DMA_CHAN_LLI_ADDR holds the physical address of the *next* descriptor the engine will load once the current one completes. DMA_CHAN_CUR_CNT holds the remaining byte count for the *current* descriptor. If the DMA engine advances to the next LLI entry between the two reads, pos becomes stale: it still points to what was the next descriptor at the time of the first read, but that descriptor is now the current one and CUR_CNT reflects its initial (full) byte count. The subsequent virtual-chain walk starts one entry too early and accumulates an extra full period's worth of bytes into the residue estimate. Fix this by re-reading DMA_CHAN_LLI_ADDR after DMA_CHAN_CUR_CNT and retrying if the value changed. This double-read pattern guarantees that both registers were sampled during the same descriptor interval. The cost is at most one extra readl() pair per call in the racy case, which occurs only at descriptor boundaries (~every 2 ms) and is negligible. Fixes: a90e173f3faf ("dmaengine: sun6i: Add cyclic capability") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Christian Lugnberg Reviewed-by: Frank Li Link: https://patch.msgid.link/20260817135723.12807-2-christian.lugnberg@soundtrack.io Signed-off-by: Vinod Koul commit cee9c863ee68cb27d66745eb03f60e357f4f8ad2 Author: Alex Bereza Date: Mon Aug 17 11:23:55 2026 +0200 dmaengine: xilinx_dma: Fix hardware buffer descriptor reuse order xilinx_dma_alloc_chan_resources() builds a static ring of hardware buffer descriptors once and the driver uses this ring throughout the lifetime of a channel. This requires the allocation order of hardware buffer descriptors from chan->free_seg_list to stay in sync with the hardware buffer descriptor ring built at channel allocation time by returning oldest descriptors to chan->free_seg_list first. When chan->pending_list is not empty e.g. during xilinx_dma_terminate_all() the chan->free_seg_list and the order of the static hardware buffer descriptor ring get out of sync. Descriptors age in this order: pending -> active -> done. So freeing pending_list first returns the newest buffer descriptors to the chan->free_seg_list first and thus breaks the order required by the static hardware buffer descriptor ring. Then when the channel is reused, after a wrap around of the free_seg_list the DMA will find a hardware buffer descriptor with a length field that is still zeroed and stop with something like this: xilinx-vdma 86000000.dma: Channel 000000003a21d7b8 has errors 10, cdr 6de4c000 tdr 6de4c000 After this no more descriptors are completed and a consumer potentially blocks and waits forever. The only way to get out of this error state is to rebuild the static hardware buffer descriptor ring and the free_seg_list by releasing and re-acquiring the channel. Fix the order in which hardware buffer descriptors are returned to free_seg_list to ensure the mentioned requirement holds. Fixes: 23059408b6a3 ("dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario") Signed-off-by: Alex Bereza Reviewed-by: Frank Li Reviewed-by: Suraj Gupta Link: https://patch.msgid.link/20260817-fix-hw-buf-desc-reuse-v1-1-d79827a844c7@bereza.email Signed-off-by: Vinod Koul commit 08b54e16d547d5c1aa61bf7a3595bb1620975eeb Author: Zhu Ling Date: Fri Sep 4 17:07:46 2026 +0800 mmc: core: Fix OF node reference leak on card add failure mmc_of_find_child_device() returns a device node with its reference count incremented. mmc_add_card() stores the reference before calling device_add(), while the card is marked present only after device_add() succeeds. If device_add() fails, the callers release the card through mmc_remove_card(). However, mmc_remove_card() only drops the OF node reference for a present card, leaking the reference on this error path. Move of_node_put() outside the present-card conditional so the reference is released for both registered cards and card-add failures. Fixes: 25185f3f31c9 ("mmc: Add SDIO function devicetree subnode parsing") Cc: stable@vger.kernel.org Signed-off-by: Zhu Ling Reviewed-by: Shawn Lin Signed-off-by: Ulf Hansson commit 9c182bc5d7817437a7d04ab96133f9191846d93d Author: Florian Maillard Date: Mon Aug 24 08:57:55 2026 +0200 mmc: rtsx_pci_sdmmc: ignore broken write-protect on ThinkPad X260 The Realtek RTS522A card reader in the Lenovo ThinkPad X260 (subsystem 17aa:504a) incorrectly reports inserted SD cards as write-protected. This causes the MMC core to expose the card as read-only: mmcblk0: mmc0:aaaa SN256 238 GiB (ro) and /sys/block/mmcblk0/ro reports 1. Setting MMC_CAP2_NO_WRITE_PROTECT makes the card writable again. Limit the quirk to the affected Lenovo subsystem. Assisted-by: ChatGPT:GPT-5.6 Sol Signed-off-by: Florian Maillard Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson commit 7addb4e5ef1702704914b47bca3f706ef96c1589 Merge: 5d4d9859574348 d876c9cb2d16ed Author: Paolo Abeni Date: Thu Sep 10 13:31:31 2026 +0200 Merge branch 'net-restore-eee-on-mediatek-switches-and-soc-macs' Aleksei Sviridkin says: ==================== net: restore EEE on MediaTek switches and SoC MACs Both drivers fill in phylink_config.lpi_capabilities and lpi_timer_default but never lpi_interfaces. phylink treats a MAC as supporting managed EEE only when the tx_lpi methods are implemented and BOTH bitmaps are non-empty, which phylink_create() decides once and for all, so EEE has been off on every mt753x port and on every mtk_eth_soc MAC that uses mtk_phylink_ops since the two commits named in the Fixes: tags. Because the tx_lpi methods ARE implemented, phylink takes the other branch and calls phy_disable_eee(), which fills eee_disabled_modes - so userspace cannot enable EEE either. On an MT7981B board with an MT7531 switch, before these patches: == lan1 Cannot get EEE settings: Not supported == lan2 Cannot get EEE settings: Not supported == lan3 Cannot get EEE settings: Not supported == lan4 Cannot get EEE settings: Not supported == wan Cannot get EEE settings: Not supported lan1-3 are the MT7531 internal PHYs, lan4 is an EN8811H on switch port 5 whose MAC side runs 2500BASE-X rate matched to a 1 Gbps media link, and wan is the mtk_eth_soc MAC with its directly attached 1 Gbps PHY - so both drivers are covered. Each patch fills lpi_interfaces from supported_interfaces and leaves 2.5 Gbps out of both bitmaps for now. LPI above 1 Gbps is unvalidated rather than unsupported: both MACs fold 2.5 Gbps onto their 1 Gbps speed encoding, so the 1 Gbps EEE force bit is what would govern it. MediaTek's SDK driver sets the force bits for 100 Mbps and 1 Gbps only, EEE signalling on 2500BASE-X is outside 802.3, and the 1 us unit of the wakeup timers is undocumented at 2.5 times the port clock. The SoC MAC patch fills lpi_interfaces only on SoCs carrying a new MTK_GMAC_EEE capability. mtk_mac_enable_tx_lpi() programs wake-up times taken from MT7531's reset values, and the capability marks the SoCs where those have been measured to work: MT7981 for now. The others keep today's behaviour, EEE unreachable from userspace, until someone with the hardware confirms them. Neither driver sets eee_enabled_default, so LPI stays off until userspace asks for it with ethtool --set-eee. The EEE advertisement is a different matter: phylink stops force-clearing it, so a PHY that advertises EEE out of reset advertises it again and the link may negotiate EEE, without this MAC asserting LPI. MT7531's internal PHYs and EN7528 are the exceptions, for the reasons in patch 1. Devicetree eee-broken-* marks act at the PHY level and keep working, so a board that already distrusts its PHYs stays protected: OpenWrt marks all modes broken on MT7621's internal PHYs. The two patches are independent and touch different subsystems; they are sent together because they are the same bug. Targeted at net as a regression fix with an active userspace lockout; can be retargeted at net-next if maintainers prefer. Based on net-next at 91ec20351349. All three files touched are byte identical in net/main and the series applies there unchanged. After the series, all five ports report: EEE status: disabled Tx LPI: disabled Supported EEE link modes: 100baseT/Full 1000baseT/Full Advertised EEE link modes: Not reported No 2.5G mode is offered, which is the narrowed lpi_capabilities, and nothing is advertised until userspace asks. On this board no PHY came out of reset advertising EEE, so the case where the advertisement returns once phylink stops clearing it is not exercised here. Enabling it on lan1, whose partner advertises EEE at both speeds: # ethtool --set-eee lan1 eee on EEE status: enabled - active Advertised EEE link modes: 100baseT/Full 1000baseT/Full Link partner advertised EEE link modes: 100baseT/Full 1000baseT/Full # ethtool --set-eee lan1 eee on tx-lpi on EEE status: enabled - active Tx LPI: 30 (us) With LPI armed, 30 parallel ICMPv6 streams of 1400-byte payload, 300 packets each one second apart - so every gap crosses the LPI threshold and the link enters and leaves LPI thousands of times over 300 s - lost nothing: 300/300 on every stream, tx and rx error counters unchanged, carrier_changes unchanged, and no mac_enable_tx_lpi errors in dmesg. On wan, cabled for this round to a partner that advertises EEE (a BCM5720), the MT7981 GMAC's own LPI was exercised. With tx-lpi armed the wan PHY's MMD 3.1 reads 0x0f44, Tx LPI indication set, so the MAC is asserting LPI; it drops to 0x0044 with tx-lpi off and comes back with it on. The same 30-stream test at 1 Gbps lost nothing over 9000 packets with the link cycling through LPI at every 1 s gap. At 100 Mbps the only losses were the first packet or two of some streams, and those reproduce with EEE disabled on both ends: neighbour discovery for 30 streams starting at once. The 17 and 36 that mtk_mac_enable_tx_lpi() programs therefore hold on MT7981 against this partner at both speeds. Its Tx LPI reads 1000 (us) against lan1's 30; see the note below the scissors of patch 1. lan4 keeps EEE disabled and never arms LPI, which is what dropping 2500BASE-X from lpi_interfaces is for. Forwarding through it was lossless with no carrier change. ==================== Link: https://patch.msgid.link/20260903123644.23800-1-f@lex.la Signed-off-by: Paolo Abeni commit d876c9cb2d16ed259449fe9da08c37a5cb81d724 Author: Aleksei Sviridkin Date: Thu Sep 3 12:36:44 2026 +0000 net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support phylink_create() decides once and for all that a MAC supports managed EEE, and it requires the tx_lpi ops plus non-empty lpi_capabilities and lpi_interfaces. mtk_add_mac() leaves lpi_interfaces empty. So ever since EEE support was added, ethtool has answered "Not supported" on every MAC that uses mtk_phylink_ops, and phy_disable_eee() has locked userspace out of turning EEE on. MT7628 is unaffected, as rt5350_phylink_ops has no tx_lpi methods. Leave 2.5 Gbps out of both bitmaps, and the xGMII modes that mtk_mac_enable_tx_lpi() already refuses. MAC_MCR folds SPEED_2500 onto MAC_MCR_SPEED_1000, so MAC_MCR_EEE1G would govern LPI on such a link, and that is unvalidated rather than known unsupported: MediaTek's SDK driver sets the EEE force bits for 100 Mbps and 1 Gbps only, and the unit of the wakeup timers is undocumented with the port clock at 2.5 times the rate. mtk_mac_enable_tx_lpi() programs wake-up times taken from MT7531's reset values, and the SoC's own field has no reset value to fall back on. Only MT7981 has been seen to exit LPI cleanly with them, so the LPI interfaces sit behind a new MTK_GMAC_EEE capability that only MT7981 sets; every other SoC keeps the current behaviour until it has been confirmed. LPI stays off until userspace enables it, but the EEE advertisement of a PHY that advertises it out of reset comes back, since phylink stops force-clearing it. Fixes: 952d7325362f ("net: ethernet: mediatek: add EEE support") Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123644.23800-3-f@lex.la Signed-off-by: Paolo Abeni commit 3c18e3c9a54e1239b72849502ca4737604bfbb46 Author: Aleksei Sviridkin Date: Thu Sep 3 12:36:43 2026 +0000 net: dsa: mt7530: populate lpi_interfaces to fix EEE support phylink_create() decides once and for all that a MAC supports managed EEE, and it requires the tx_lpi ops plus non-empty lpi_capabilities and lpi_interfaces. mt753x_phylink_get_caps() leaves lpi_interfaces empty. So ever since the conversion to phylink managed EEE, ethtool has answered "Not supported" on every mt753x port, and phy_disable_eee() has locked userspace out of turning EEE on. That undoes what commit 06dfcd4098cf ("net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards") arranged: EEE off by default, but reachable with ethtool. Leave the speeds above 1 Gbps out of both bitmaps. PMCR folds SPEED_2500 and SPEED_10000 onto PMCR_FORCE_SPEED_1000, so PMCR_FORCE_EEE1G would govern LPI on such a link, and that is unvalidated rather than known unsupported: MediaTek's SDK driver sets the EEE force bits for 100 Mbps and 1 Gbps only, and the unit of the wakeup timers is undocumented with the port clock at 2.5 times the rate. LPI stays off until userspace enables it, but the EEE advertisement of a PHY that advertises it out of reset comes back, since phylink stops force-clearing it. Fixes: 9cf21773f535 ("net: dsa: mt7530: convert to phylink managed EEE") Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123644.23800-2-f@lex.la Signed-off-by: Paolo Abeni commit 5d4d985957434867bbe85e4fa5e638f3e48ad522 Author: Aamir Ahmed Date: Mon Sep 7 02:42:34 2026 +0000 net: hinic: fix mailbox segment buffer overflow check_mbox_seq_id_and_seg_len() validates that seq_id does not exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed MBOX_SEG_LEN (48). However, this allows the last segment (seq_id=42) to carry a full 48-byte payload, writing to offset 42*48=2016 for 48 bytes (ending at byte 2064). The receive buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a 16-byte heap buffer overflow. The hinic3 driver already handles this correctly by defining MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it exceeds the remaining buffer space. Apply the same fix to the hinic driver. Fixes: a425b6e1c69b ("hinic: add mailbox function support") Signed-off-by: Aamir Ahmed Link: https://patch.msgid.link/AS8P251MB0001AE870B09020B46B5D7DBC8B22@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Paolo Abeni commit af406abfecad2f48d8f1fc646d3994f0982bac62 Author: Li Youhong Date: Fri Sep 4 16:07:58 2026 +0800 net: sun4i-emac: fix missing of_node_put() for phy_node of_parse_phandle() returns a node pointer with an elevated refcount. Add the missing of_node_put() on the probe error path after register_netdev() fails and in emac_remove(). Fixes: 492205050d77 ("net: Add EMAC ethernet driver found on Allwinner A10 SoC's") Signed-off-by: Li Youhong Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260904080758.2432748-1-dayou5941@163.com Signed-off-by: Paolo Abeni commit dff39930ad5e53d202bfdfb14687d1d2fd753b4d Author: Kuniyuki Iwashima Date: Tue Sep 8 20:55:25 2026 +0000 net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain(). If a netlink socket sends RTM_GETCHAIN requests repeatedly without recv()ing the responses, tc_ctl_chain() hogs CPU and triggers Hung Task splat. [0] As caught in the stack trace, netlink_attachskb() could confuse tc_ctl_chain() by returning -EAGAIN when the userspace netlink socket's receive buffer is full. The replay: label exists since commit 32a4f5ecd738 ("net: sched: introduce chain object to uapi") but was not used initially. Since commit 9f407f1768d3 ("net: sched: introduce chain templates"), the label is needed for RTM_NEWCHAIN because tcf_proto_lookup_ops() may release RTNL to call request_module(). However, the replay logic is unnecessary for RTM_GETCHAIN. Let's apply the replay logic only for RTM_NEWCHAIN. [0]: INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000 Call Trace: ? clockevents_program_event (kernel/time/clockevents.c:372) ? pskb_expand_head (net/core/skbuff.c:615) ? skb_release_data (net/core/skbuff.c:1122) ? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232) ? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499) ? tc_chain_notify (net/sched/cls_api.c:3045) ? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041) ? netlink_unicast (net/netlink/af_netlink.c:1335) ? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tc_ctl_chain (net/sched/cls_api.c:3242) ? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146) ? netlink_unicast (net/netlink/af_netlink.c:1354) ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177) ? netlink_rcv_skb (net/netlink/af_netlink.c:2556) ? netlink_unicast (net/netlink/af_netlink.c:1319) ? netlink_sendmsg (net/netlink/af_netlink.c:1900) ? __sock_sendmsg (net/socket.c:800) ? __sys_sendto (net/socket.c:2281) ? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fixes: 2ed9db3074fc ("net: sched: cls_api: fix dead code in switch") Reported-by: Taras Madan Signed-off-by: Kuniyuki Iwashima Reviewed-by: Jamal Hadi Salim Tested-by: hybris@mojatatu.ai Link: https://patch.msgid.link/20260908205537.863484-1-kuniyu@google.com Signed-off-by: Paolo Abeni commit 4770e9f851b782c0047d617a62897f957e441eca Merge: 00f9fbc1232025 e190a7aabbea4f Author: Paolo Abeni Date: Thu Sep 10 11:27:53 2026 +0200 Merge branch 'net-sched-cls_route-fix-bucket-retention-and-handle-recomputation' Victor Nogueira says: ==================== net/sched: cls_route: fix bucket retention and handle recomputation Patch 1 is the v1 patch, unchanged. route4_change() can move an existing filter to a different top-level bucket, since route4_set_parms() recomputes the handle from TCA_ROUTE4_TO/FROM/IIF. The filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty, so route4_delete() keeps reporting *last=false after the last live filter is gone. That pins the empty tcf_proto and leaks it. The filters linked to a bucket are refcounted now, and the bucket is dropped from head->table[] as soon as the count reaches zero. Reviewing v1, Sashiko pointed out that the duplicate scan in route4_set_parms() compares against the wrong handle [1]. Patches 2 and 3 fix the two symptoms of that. Patch 2 makes the scan compare against nhandle. f->handle is the handle the filter has before the update, not the one it is about to be linked under, so a change that moves a filter into a chain already holding nhandle misses the collision and links a second filter under the same handle. The newcomer is then unreachable: route4_get() returns the incumbent, and route4_classify() stops at the first filter whose f->id matches. Patch 3 handles the mirror case. An in-place replace computes an nhandle that the filter being replaced already carries, so the scan finds that filter and rejects the request with -EEXIST. The older filter is passed to route4_set_parms() and skipped in the scan. Skipping it alone would rename the filter it replaces: the 0x7F00 order bits are carried in no attribute and were folded into nhandle on the create path alone, so an order 1 filter came back as order 0, and a sibling sharing its key could then no longer be replaced at all. They are carried over now whenever the request builds the key the filter already has, which leaves a request that does change the key renaming the filter as before. Patch 4 adds tdc coverage for all three, including the cross-bucket move case Sashiko noted route.json had no test for. [1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260829205422.854785-1-victor%40mojatatu.com ==================== Link: https://patch.msgid.link/20260907192133.2639067-1-victor@mojatatu.com Signed-off-by: Paolo Abeni commit e190a7aabbea4fbfec0e74de134144cb4d040738 Author: Victor Nogueira Date: Mon Sep 7 16:21:33 2026 -0300 selftests/tc-testing: Add cls_route bucket move and change tests Add 4 tdc tests for the cls_route bugs fixed earlier in this series: - Delete a route filter that was moved to another bucket (a7d2): Validates that deleting a filter, and making a bucket empty, does not leave a dangling empty bucket - Try to change a route filter onto an already used handle (c05a): Validates that attempting to change an existing filter's handle to an already taken one fails - Replace a route filter that shares its key with another filter (3f21): Validates that an in-place replace keeps the handle userspace named the filter by, rather than dropping the 0x7F00 bits from it - Replace both route filters sharing a key (9d0e): Validates that replacing one of the two does not make the other one unreplaceable Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260907192133.2639067-5-victor@mojatatu.com Signed-off-by: Paolo Abeni commit 41e85e54e5649a1617698438b0ce64c6f9d83d69 Author: Victor Nogueira Date: Mon Sep 7 16:21:32 2026 -0300 net/sched: cls_route: Fix in-place replace Building on the previous patch, route4_set_parms rejects a duplicate by scanning the destination chain for nhandle, but the scan doesn't exclude the older version it is replacing, so an in-place replace will match the older version's handle and fail. Fix this by passing the older filter as a parameter to route4_set_parms (replacing "new") and skipping it in the scan. Excluding the older version is not enough on its own. nhandle is built out of TCA_ROUTE4_TO, TCA_ROUTE4_FROM and TCA_ROUTE4_IIF alone, while the 0x7F00 bits, which only tell apart filters sharing one key, are folded in on the create path. Letting the replace through would therefore rename the filter it replaces: replacing handle 0x10101 stored it back as 0x10001, and a sibling at 0x10201 could then no longer be replaced at all, since its own nhandle collided with the renamed filter. tc filter add ... handle 0x10101 route from 1 to 1 classid 1:1 tc filter add ... handle 0x10201 route from 1 to 1 classid 1:2 tc filter replace ... handle 0x10101 route from 1 to 1 classid 1:9 ... fh 0x00010001 flowid 1:9 to 1 from 1 ... fh 0x00010201 flowid 1:2 to 1 from 1 tc filter replace ... handle 0x10201 route from 1 to 1 classid 1:8 Error: Handle 10001 is already in use. So carry those bits over when the key the request builds is the key the older filter already has. An in-place replace then keeps the handle userspace named the filter by, while a request that does change the key still renames it, as it did before. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260829205422.854785-1-victor%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260907192133.2639067-4-victor@mojatatu.com Signed-off-by: Paolo Abeni commit b74a8455a2f271f54695b6a8ec1f113824a46c0e Author: Victor Nogueira Date: Mon Sep 7 16:21:31 2026 -0300 net/sched: cls_route: Reject handle aliasing route4_set_parms() rejects a duplicate by scanning the destination chain for f->handle, but f->handle is the handle the filter has before the update, not the one it is about to be linked under. The comparison and the insertion therefore use different handles, which causes breakage. When a change moves the filter to a chain that already holds nhandle, the scan looks for the old handle instead, misses the collision and links a second filter with the same handle: tc filter add dev lo ingress protocol ip pref 100 \ route from 1 to 1 classid 1:1 action ok tc filter add dev lo ingress protocol ip pref 100 \ route from 2 to 2 classid 1:2 action drop tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \ route from 2 to 2 classid 1:1 action ok tc filter show dev lo ingress ... fh 0x00020002 flowid 1:2 to 2 from 2 ... fh 0x00020002 flowid 1:1 to 2 from 2 The newcomer is appended after the incumbent, and both end up with the same f->id. route4_get() returns the first match, so the second filter can no longer be addressed by handle, and route4_classify() stops at the first filter whose f->id matches. The second filter is dumped but is effectively dead. Fix this by comparing against nhandle. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260829205422.854785-1-victor%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260907192133.2639067-3-victor@mojatatu.com Signed-off-by: Paolo Abeni commit 1853f30cf5c84971f99788a76207c6f745380896 Author: Victor Nogueira Date: Mon Sep 7 16:21:30 2026 -0300 net/sched: cls_route: free emptied bucket on filter move route4_change can move an existing filter to a different top-level bucket: route4_set_parms recomputes the handle from TCA_ROUTE4_TO/ FROM/IIF, and the handle-mismatch check is gated on the 'new' flag, so for an existing filter the new handle may differ from the old one and land in a different bucket. When this happens, the filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty. The stale empty bucket remains in head->table[], causing route4_delete to report *last=false even after the last live filter is gone. That pins the empty tcf_proto and causes a leak. Fix this by refcounting the filters linked to a bucket and freeing the bucket when the count drops to zero. The existing scan in route4_delete goes away with it. The count is updated at all sites that link or unlink a filter during add, change and delete, and the bucket is dropped from head->table[] as soon as it reaches zero. Conditions to recreate the bug: CONFIG_NET_CLS_ROUTE4=y, CONFIG_NET_SCH_INGRESS=y, CONFIG_NET_CLS_ACT=y. tc qdisc replace dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \ route from 1 to 2 tc filter del dev lo ingress protocol ip pref 100 handle 0x10002 \ route from 1 to 2 tc filter show dev lo ingress | grep -c 'pref 100 route chain 0 ' Fixes: 1e052be69d04 ("net_sched: destroy proto tp when all filters are gone") Reported-by: Vega Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260907192133.2639067-2-victor@mojatatu.com Signed-off-by: Paolo Abeni commit 00f9fbc12320253bfc576fb7539d860029c82d0f Author: Johan Hovold Date: Mon Sep 7 08:52:35 2026 +0200 net: hso: fix TIOCMIWAIT race The task state must be updated before checking the wakeup condition to avoid missing a racing modem status update. Fixes: 542f54823614 ("tty: Modem functions for the HSO driver") Cc: stable@vger.kernel.org # 2.6.29 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260907065235.100848-1-johan@kernel.org Signed-off-by: Paolo Abeni commit 5a5d26f2cfe13467166219f6bf58099326912ddb Author: Soheil Hassas Yeganeh Date: Mon Aug 31 14:48:44 2026 +0000 x86/cfi: Fix FineIBT hash offset in cfi_get_func_hash() The switch of the FineIBT preamble from "subl $hash, %r10d" to the shorter "subl $hash, %eax" moved the hash immediate from offset 7 to offset 5 of the preamble. fineibt_preamble_hash was updated to match, but the open-coded offset in cfi_get_func_hash() was missed and it still reads the hash at offset 7. cfi_get_func_hash() is used by the BPF JIT to give a struct_ops trampoline the CFI hash of the stub function it stands in for. With FineIBT the trampoline now gets the upper half of the real hash followed by the first two bytes of the next instruction, so the first indirect call from the kernel into a struct_ops program, tcp_init_congestion_control() calling ->init() of a BPF congestion control for example, fails the FineIBT check and the kernel dies with a CFI failure. Move the FineIBT preamble template and its offset defines above cfi_get_func_hash() and use fineibt_preamble_hash there, so every reader of the preamble shares one definition of its layout. The CFI_FINEIBT arm is only built with CONFIG_FINEIBT, the only configuration in which cfi_mode can take that value. cfi_get_func_arity() does not need the same treatment: the __bhi_args call whose displacement it reads still ends at the function address. Fixes: 85a2d4a890dc ("x86,ibt: Use UDB instead of 0xEA") Assisted-by: LLM Signed-off-by: Soheil Hassas Yeganeh Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260831-b4-x86-cfi-fineibt-func-hash-v1-1-6ffc0af5c4ec@gmail.com commit f5741d2b34519d387edf6e9798fc7030c20a35f3 Author: Hui Su Date: Wed Sep 2 23:02:09 2026 +0800 sched/core: Call wq_worker_tick() for the execution context wq_worker_tick() accounts CPU time and detects CPU-intensive work for the kworker that is actually running. With proxy execution, rq->donor is the scheduling context while rq->curr is the execution context. Calling the hook with rq->donor can skip workqueue accounting when a kworker is executing on behalf of a donor task. It can also account a blocked kworker when the donor is a worker but rq->curr is the task actually executing. The former can delay WORKER_CPU_INTENSIVE handling and pool concurrency management, which can delay pending kernel work and userspace operations depending on it. Use rq->curr for the workqueue tick hook while retaining rq->donor for scheduler accounting. Fixes: af0c8b2bf67b ("sched: Split scheduler and execution contexts") Signed-off-by: Hui Su Signed-off-by: Peter Zijlstra (Intel) Acked-by: Tejun Heo Link: https://patch.msgid.link/20260902150208.1209922-2-sh_def@163.com commit c23810313bdf6b02f39a1f2a1464c4b18bd39e31 Author: Hui Su Date: Fri Sep 4 11:47:07 2026 +0800 sched: Account cgroup CPU time to the execution context Proxy execution separates the scheduling context from the execution context. Commit aa4f74dfd42b ("sched: Fix runtime accounting w/ split exec & sched contexts") made per-task and thread-group runtime accounting follow the task that actually executes, while cgroup CPU usage is charged to the donor. When the donor and execution task belong to different cgroups, this makes a task's execution time count against a different cgroup from the one the task belongs to. Cgroup CPU usage should follow the execution context, matching the per-task, thread-group, and cgroup user/system accounting. Keep scheduling state associated with the donor, but charge cgroup CPU usage to rq->curr. A reproducer with the donor and execution task in separate cgroups showed the execution task accumulating runtime while cgroup CPU usage was charged to the donor's cgroup. With this change, the execution task's cgroup accumulates the CPU usage instead. The same behavior was verified with an RT donor and with legacy cpuacct accounting. Fixes: aa4f74dfd42b ("sched: Fix runtime accounting w/ split exec & sched contexts") Suggested-by: Tejun Heo Signed-off-by: Hui Su Signed-off-by: Peter Zijlstra (Intel) Acked-by: Tejun Heo Acked-by: John Stultz Link: https://patch.msgid.link/20260904034707.268416-1-sh_def@163.com commit 51b0e68cfa0ac69e3c3ea9d6753af7e15dfaab22 Author: Vincent Guittot Date: Wed Sep 9 17:05:22 2026 +0200 sched/eevdf: Fix rb augmented with multi fields The eevdf rb tree maintains 3 augmented fields but only one is currently copied when balancing the tree. Add a more generic define that can be used when there are several augmented fields. In this case, we provide a function that takes care of copying all fields. Fixes: aef6987d8954 ("sched/eevdf: Propagate min_slice up the cgroup hierarchy") Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: K Prateek Nayak Tested-by: K Prateek Nayak Link: https://patch.msgid.link/20260909150522.858312-1-vincent.guittot@linaro.org commit 9a8bc9bb4c3fb3218b4f151f98a722fbeb5b5c34 Author: Vincent Guittot Date: Mon Sep 7 14:38:55 2026 +0200 sched/eevdf: Fix augmented max_slice Similarly to se->min_slice, init se->max_slice with se->slice before enqueueing the entity so the augmented callback computes it correctly at parent level. Fixes: 6e3c0a4e1ad1 ("sched/fair: Fix lag clamp") Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: K Prateek Nayak Link: https://patch.msgid.link/20260907123855.1297976-1-vincent.guittot@linaro.org commit a56c03a397e2cd0c4cf8da96dcd6214f7d0e7d8c Author: Dapeng Mi Date: Thu Aug 13 14:43:46 2026 +0800 perf/x86/intel: Prevent drain_pebs() reentry The PEBS buffer is shared by all events on a CPU, so drain_pebs() must not be reentered. If so, one instance may observe stale buffer state and potentially access out-of-bound memory. Most invocations happen in NMI context, which naturally prevents reentry. However, drain_pebs() is also reachable from process context via intel_pmu_drain_pebs_buffer(). In those paths, the PMU is often already disabled, but not guaranteed. For example, __intel_pmu_pebs_disable() only disables the target counter, so other active counters can still raise a PMI and interrupt an in-flight drain_pebs(). Here is an example, __perf_addr_filters_adjust() perf_event_stop() __perf_event_stop() x86_pmu_stop() (event->pmu->stop) intel_pmu_disable_event() intel_pmu_pebs_disable() __intel_pmu_pebs_disable() intel_pmu_drain_large_pebs() intel_pmu_drain_pebs_buffer() Introduce __intel_pmu_quiesce() and __intel_pmu_resume() helpers and use them in intel_pmu_drain_large_pebs() to disable the full PMU around the intel_pmu_drain_pebs_buffer() call, preventing reentry. Also add a warning in intel_pmu_drain_pebs_buffer() when the full PMU is not disabled. Fixes: b752ea0c28e3 ("perf/x86/intel/ds: Flush PEBS DS when changing PEBS_DATA_CFG") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260813064346.335458-1-dapeng1.mi@linux.intel.com commit 88aa1223bfffb1a0a98c639e9e1f71058f0d9178 Author: Dapeng Mi Date: Tue Sep 8 15:51:01 2026 +0800 perf/x86/intel: Correct pt_regs->flags update for PEBS path pt_regs->flags holds the saved CPU FLAGS register. In the PEBS path, it was incorrectly set to PERF_EFLAGS_EXACT instead of being populated from the PEBS flags snapshot. Update pt_regs->flags from PEBS GPR flags if GPRs group is present. Fixes: c22497f5838c ("perf/x86/intel: Support adaptive PEBS v4") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260908075102.540715-1-dapeng1.mi@linux.intel.com commit 59e63416f5153e7d58652c616fbdcb7d5e01fff7 Author: Thomas Richter Date: Tue Sep 8 12:56:37 2026 +0200 perf/core: Allow list_del during perf_event_overflow() A PMU might use perf_sched_cb_inc() and perf_sched_cb_dec() interface to get the PMU call back function pmu::sched_task invoked at schedule in and schedule out. This is achieved by walking along the list anchored by sched_cb_list. The following scenario might lead to a list corruption. perf_pmu_sched_task() for_each_list_entry(..., &sched_cb_list) +--> __perf_pmu_sched_task() +--> event->pmu->sched_task()) +--> PMU_push_sample() +--> perf_event_overflow() +--> __perf_event_overflow() +--> pmu->stop() +--> perf_sched_cb_dec() remove entry from sched_cb_list while list node in use. This happens when ioctl(fd, PERF_EVENT_IOC_REFRESH, xxx) has been invoked and perf_event::event_limit hits zero. Prevent the list corruption and convert for_each_list_entry() to for_each_list_entry_safe(). Fixes: bd2756811766 ("perf: Rewrite core context handling") Signed-off-by: Thomas Richter Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260908105637.627004-1-tmricht@linux.ibm.com commit cbd3dafc2003db679ccd2f6c6a2551db79657049 Author: Thorsten Blum Date: Sun Aug 23 22:50:28 2026 +0200 drm/i915: Fix memory leak in query_perf_config_list() When krealloc() fails, free the original oa_config_ids before returning to avoid a memory leak. Fixes: 4f6ccc74a85c ("drm/i915: add support for perf configuration queries") Signed-off-by: Thorsten Blum Cc: # v5.5+ Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260823205028.178597-2-thorsten.blum@linux.dev (cherry picked from commit 9977e9d84f46d4f12ad35fbbc0ec4638554bce87) Signed-off-by: Jani Nikula commit a894f97318366d12102c15937aa6b63c21aa82b5 Author: Mitul Golani Date: Tue Aug 25 13:02:04 2026 +0530 drm/i915/dp: Gate UHBR SST SDP splitting on sink capability SDP splitting for 128b/132b (UHBR) SST audio must only be enabled when the sink advertises support for it. Previously sdp_split_enable was set for every UHBR SST stream carrying audio, regardless of sink capability. In MST mode SDP splitting is inherently supported, so the sink capability check (DP_SST_SPLIT_SDP_CAP) is applied only to the SST path. Fixes: 8853750dbad8 ("drm/i915: Enable SDP split for DP2.0") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Mitul Golani Reviewed-by: Suraj Kandpal Signed-off-by: Suraj Kandpal Link: https://patch.msgid.link/20260825073204.872441-1-mitulkumar.ajitkumar.golani@intel.com (cherry picked from commit b37921c9f533ca936c5b5a484c1299680c570a7e) Signed-off-by: Jani Nikula commit 9e5c53d75c560a058abef0e4338c5e3e52cb432a Author: Kunwu Chan Date: Wed Jan 17 17:17:06 2024 +0800 powerpc/pasemi: Add a null pointer check to the pas_setup_mce_regs kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. Signed-off-by: Kunwu Chan Reviewed-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20240117091706.153431-1-chentao@kylinos.cn commit 15f3ce3aa218f6d4cece9101f1af4332e8712e39 Author: Sourabh Jain Date: Sat Apr 18 14:42:50 2026 +0530 powerpc/prom: Remove redundant early_init_dt_scan_root() call Commit 554b66233623 ("of/fdt: Scan the root node properties earlier") moved the invocation of early_init_dt_scan_root() into early_init_dt_verify(). early_init_devtree() already calls early_init_dt_verify(), so the root node properties are parsed before reaching the explicit call in this function. Keeping the call here results in scanning the root node twice. Remove the redundant call and rely on the invocation from early_init_dt_verify(). This change keeps the behavior the same and removes an unnecessary duplicate call. Signed-off-by: Sourabh Jain Tested-by: Shivang Upadhyay Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260418091250.134111-1-sourabhjain@linux.ibm.com commit bf1d8287816194457c1a936056ad2d1e1e478944 Author: longlong yan Date: Wed Jul 22 10:34:28 2026 +0800 selftests/powerpc: use MAP_FAILED instead of (void *)-1 in tm-signal-context-force-tm mmap() is documented to return MAP_FAILED on error, but tm-signal-context-force-tm.c compares the return value against (void *)-1. Replace these with the standard MAP_FAILED macro for better readability and type safety. Signed-off-by: longlong yan Tested-by: Venkat Rao Bagalkote Reviewed-by: Amit Machhiwal Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260722023428.932-1-yanlonglong@kylinos.cn commit e58b9d90973e09f1908d2cd00ca2336a8232b9f8 Author: Sourabh Jain Date: Fri Jul 25 18:14:38 2025 +0530 powerpc/kexec_file: print configured kernel command line Kexec with the -d option prints extra logs about the kexec/kdump kernel that help debug kexec and kdump. For example, it shows what kexec segments are loaded, their locations, and sizes. One key piece of information still missing is the kernel command line configured for the kexec/kdump kernel. With this patch included, the kernel will print the kernel command line configured for the kexec/kdump kernel as shown below: kexec --initrd=./initrd ./kernel -lspd --command-line="test1 test2" Loaded elf core header at 0x22e30000, bufsz=0x2000 memsz=0x80000 kexec_elf: Command line: elfcorehdr=0x22e30000 test1 test2 <--- New kexec_elf: Loaded initrd at 0x22eb0000 Signed-off-by: Sourabh Jain Tested-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250725124438.327593-1-sourabhjain@linux.ibm.com commit 1144454ea22290d7c6998a2af6239e5995476afc Author: leixiang Date: Thu Jul 9 13:57:52 2026 +0800 KVM: PPC: Book3S HV: Set irqfd->producer only on success Set irqfd->producer only after kvmppc_set_passthru_irq() succeeds to avoid leaving a dangling pointer on failure. The bypass manager does not register a failed producer, so the pointer is never cleared. Fixes: c57875f5f9be ("KVM: PPC: Book3S HV: Enable IRQ bypass") Suggested-by: Sean Christopherson Cc: stable@vger.kernel.org Signed-off-by: leixiang Reviewed-by: Amit Machhiwal Reviewed-by: Vaibhav Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260709055755.31297-1-leixiang@kylinos.cn commit 10557fe7fc9e09d273f8575274be2bbbe255dbf0 Author: Michail Tatas Date: Tue Aug 4 22:55:23 2026 +0300 powerpc/pseries/htmdump: Fix leak in htmdump_init_debugfs If any allocation fails during init all previous allocations are leaked and the debugfs directory is left. Fix by freeing the allocations that have already happened and also remove the directory that has been created. Signed-off-by: Michail Tatas Reviewed-by: Athira Rajeev Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/anJDq-JckR6j-6EJ@michalis-linux commit ed28b16eab705071d28edaace47189c2eb3aa108 Author: Thibault Ferrante Date: Mon Sep 7 23:54:20 2026 +0200 selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value tcheck() is used to check the current transaction state (active, suspended, doomed) via the "tcheck" instruction, which writes its result into CR field 0. The inline asm declared a GPR output operand for this result but never actually moved the CR into it. Every caller (tcheck_doomed(), tcheck_active(), tcheck_suspended(), tcheck_transactional()) has effectively been testing bits of an unrelated, arbitrary register value since this helper was introduced. The "& 4" mask discards the TDOOMED and TS_lsb (suspended) bits before they ever reach the callers, so tcheck_doomed() and tcheck_suspended() can never return true, and tcheck_transactional() degrades to being equivalent to tcheck_active(). Fix tcheck() to actually move CR into the output register with mfcr, and widen the mask from "& 4" to "& 0xf" so the full CR0 nibble (TDOOMED | TS_msb | TS_lsb | reserved) is preserved for the callers. This bug has been present since tcheck() was introduced. Link: https://bugs.launchpad.net/bugs/2107442 Fixes: 8e03bd4e70b6 ("selftests/powerpc: Add TM tcheck helpers in C") Signed-off-by: Thibault Ferrante Reported-by: Venkat Rao Bagalkote Tested-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/364996ce-aba2-4213-8d20-7dd481b43fe6@linux.ibm.com/ Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260907215420.1258678-1-thibault.ferrante@canonical.com commit 1abd643f3783ea8f8e273c18697ff0413aa92dc7 Author: Christian Brauner Date: Wed Sep 9 11:03:18 2026 +0200 fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot's "WARNING in do_new_mount" saga ntfs_create_inode() creates a new inode via ntfs_new_inode(). It hashes it with insert_inode_locked() and so it's marked as I_NEW until unlock_new_inode(). ntfs 3 calls d_instantiate() in between though... Since the dentry was already hashed by the lookup before the create any path walk finds it without touching the parent's i_rwsem and so can lock the inode. If the inode is a directory unlock_new_inode() calls lockdep_annotate_inode_mutex_key() and marks i_rwsem with the i_mutex_dir_key class. That resets the count and the owner of a lock somebody else may already hold by now... syzbot has been spamming us with the same godforsaken bug "WARNING in do_new_mount" since 2023. I can't take it anymore so I went looking. Afaict, syzbot's executor chdirs into a freshly mounted ntfs3 image, creates a directory and then mounts some pseudofs on it. Everytime the mkdir() takes longer than syzbot waits mount() runs concurrently: mkdir("./sys") mount(NULL, "./sys", "sysfs") ntfs_create_inode() d_instantiate() user_path_at() finds the dentry do_lock_mount() inode_lock(inode) namespace_lock() unlock_new_inode() lockdep_annotate_inode_mutex_key() init_rwsem(&inode->i_rwsem) unlock_mount() inode_unlock(inode) The mount side then releases a lock that according to the rwsem nobody holds: DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && ...): count = 0x0, magic = 0xffff888043a854e8, owner = 0x0, curr 0xffff888000244880, list empty WARNING: CPU: 0 PID: 5346 at kernel/locking/rwsem.c:1368 __up_write Call Trace: inode_unlock include/linux/fs.h:877 [inline] unlock_mount fs/namespace.c:2892 [inline] do_new_mount_fc fs/namespace.c:3828 [inline] do_new_mount+0x777/0xa40 fs/namespace.c:3887 On PREEMPT_RT the same thing shows up as DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) WARNING: kernel/locking/rtmutex_common.h:193 at rt_mutex_slowunlock The up_write() underflows the reset count. A following inode_lock() on that directory then never returns. A path walk into the new directory racing with the mkdir() corrupts the lock the same way via inode_lock_shared() in lookup_slow(). Switch to d_instantiate_new() and drop the trailing unlock_new_inode(). All error paths bail out before that point with I_NEW still set and keep using discard_new_inode(). May we never see this fscking bug report again. Link: https://patch.msgid.link/20260909-work-ntfs3-d_instantiate_new-v1-1-2db697162ce8@kernel.org Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Reviewed-by: Jan Kara Cc: stable@vger.kernel.org # v5.15+ Reported-by: syzbot+2a13ad6914e6fcec716c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a9beced.a5e650b3.26d8a.000b.GAE@google.com Signed-off-by: Christian Brauner (Amutable) commit d59ac79915daa567c69aa93d458d41844676e92a Author: Disha Goel Date: Fri Jul 3 20:37:42 2026 +0530 selftests/filesystems: fix missing and stale TARGETS entries filesystems/eventfd, filesystems/open_tree_ns and filesystems/xattr were never added to TARGETS when introduced. filesystems/openat2 was moved from selftests/openat2/ but the TARGETS entry was never updated, leaving a stale entry pointing at a directory that no longer exists. Fix this by adding the four missing subdirectories to TARGETS and removing the stale openat2 entry. Link: https://lore.kernel.org/20260703150742.58991-1-disgoel@linux.ibm.com Fixes: 7c37857fc23a ("selftests: add eventfd selftests") Fixes: b8f7622aa6e3 ("selftests/open_tree: add OPEN_TREE_NAMESPACE tests") Fixes: 7e28fef5d4db ("selftests/xattr: path-based AF_UNIX socket xattr tests") Fixes: fe087927046c ("selftests: move openat2 tests to selftests/filesystems/") Signed-off-by: Disha Goel Reviewed-by: Christian Brauner (Amutable) Cc: "Darrick J. Wong" Cc: Jan Kara Cc: Jeff Layton Cc: Shuah Khan Cc: Wen Yang Signed-off-by: Andrew Morton Link: https://patch.msgid.link/20260904183659.B81CD1F00A3D@smtp.kernel.org Signed-off-by: Christian Brauner (Amutable) commit 57a78ad2305f299bc3f933ed36b3d402df04784a Author: David Howells Date: Wed Sep 9 09:06:31 2026 +0100 block: Fix start and length check added to iov_iter_extract_bvecs() Commit 14b007e17881 added an address check using iter_iov_addr() and a length check using iter_iov_len() to iov_iter_extract_bvecs(), but these cannot be used so and are unsafe in this circumstance as the functions have hardwired assumptions about the iterator type. They should only be used with ITER_UBUF or ITER_IOVEC-type iterators; they shouldn't be used with ITER_BVEC, ITER_KVEC, ITER_FOLIOQ, ITER_XARRAY or ITER_DISCARD iterators. This proves to be a problem for cachefiles as an iterator of type ITER_FOLIOQ is passed and iter_iov_addr() and iter_iov_len() both malfunction because iter->__iov in iter_iov() is not pointing to an iovec array. Fix this by using iov_iter_alignment() instead. Fixes: 14b007e17881 ("block: validate user space vectors during extraction") Signed-off-by: David Howells Link: https://patch.msgid.link/1667275.1788941191@warthog.procyon.org.uk Reviewed-by: Keith Busch Reviewed-by: Christoph Hellwig cc: Hannes Reinecke cc: Christoph Hellwig cc: Jens Axboe cc: Alexander Viro cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-block@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit ef17515a8ef88c246c342a6c532aa10f9ecdcfaf Author: Athira Rajeev Date: Thu Sep 3 13:10:36 2026 +0530 selftests/powerpc/pmu/ebb: fix lost_exception_test hang with sched yield change commit 79104becf42b ("sched/fair: Forfeit vruntime on yield") changed yield_task_fair() to only bump the deadline when the entity is eligible (vruntime <= avg_vruntime). When the entity is ineligible the yield becomes a complete no-op from scheduling perspective. lost_exception_test calls sched_yield() 100,000 times per iteration to race the EBB exception delivery with a context switch to the eat_cpu companion process. After enough iterations the test process's vruntime races ahead of avg_vruntime (each eligible yield bumps vruntime to deadline, then advances deadline by one slice). Once ineligible, yield_task_fair() does nothing: so the scheduler won't pick the eat_cpu child. No context switch occurs, the PMAO race is never triggered, and ebb_count stays at 0 forever causing the test to hang until timeout. Fix by replacing sched_yield() with nanosleep(0, 1ns). nanosleep() goes through hrtimer_nanosleep() -> do_nanosleep(), which puts the task into TASK_INTERRUPTIBLE and removes it from the run queue entirely. This guarantees the scheduler picks the eat_cpu child, restoring the context-switch guarantee the test requires. The 1ns duration is enough to engage the hrtimer path while keeping the sleep effectively instantaneous; the same race window between PMU overflow and context switch is preserved. Reported-by: Venkat Rao Bagalkote Signed-off-by: Athira Rajeev Tested-by: Venkat Rao Bagalkote Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260903074036.63309-1-atrajeev@linux.ibm.com commit 11ae2e1dc58304a48816fc8ca4afa8f2ef9d1bdf Author: Aboorva Devarajan Date: Fri Sep 4 08:28:30 2026 +0530 powerpc/entry: Fix double accounting of user time on interrupt entry Since the switch to generic entry, an interrupt from user mode accounts user time twice: once in arch_interrupt_enter_prepare() and again in arch_enter_from_user_mode(), which irqentry_enter() invokes for the same interrupt: arch_interrupt_enter_prepare() account_cpu_user_entry() /* first */ irqentry_enter() arch_enter_from_user_mode() account_cpu_user_entry() /* second */ The second call charges the same interval again, because account_cpu_user_entry() accumulates the time spent in user mode since the last return to user space. The two calls come from the GENERIC_ENTRY preparation series, where each step was a no-op on its own. Commit 09a9d3a8499d ("powerpc: introduce arch_enter_from_user_mode") added the hook with the user-time accounting in it, but nothing called it yet. Commit 893082ac769b ("powerpc: Prepare for IRQ entry exit") copied interrupt_enter_prepare() verbatim into entry-common.h as arch_interrupt_enter_prepare(); that copy was equally unused, as handlers still called interrupt_enter_prepare(). Commit bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature") made both live. On the syscall side it did the full conversion: system_call_exception() now accounts once through the hook via syscall_enter_from_user_mode(), rather than calling account_cpu_user_entry() directly. On the interrupt side it switched the handler macros to arch_interrupt_enter_prepare() followed by irqentry_enter(), which also runs the hook, but the accounting in arch_interrupt_enter_prepare() was not removed to match. The double accounting starts with that commit. With CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y this roughly doubles the reported user time of any workload that takes interrupts. The other accounting modes compile account_cpu_user_entry() to an empty stub, so they are not affected. Remove the accounting from arch_interrupt_enter_prepare() and rely on arch_enter_from_user_mode(), which already runs for both syscalls and interrupts. The duplicate account_stolen_time() call is removed the same way. On a pseries LPAR a busy loop reports 6s user time in 3s elapsed (~210% CPU) before the fix, and 3s (~105% CPU) after it: $ python3 -c 'while True: pass' & $ sleep 3; ps -p $! -o etime,time,pcpu ELAPSED TIME %CPU Before 00:03 00:00:06 210 After 00:03 00:00:03 105 A 50% load reports ~70% usr / 30% idle before the fix, and ~49% usr / 51% idle after it: $ taskset -c 6 stress-ng --cpu 1 --cpu-load 50 & $ mpstat -P 6 1 CPU %usr %idle Before 6 69.74 30.26 After 6 48.51 50.50 Fixes: bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature") Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Aboorva Devarajan Tested-by: Venkat Rao Bagalkote Reviewed-by: Amit Machhiwal Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Christophe Leroy (CS GROUP) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260904025831.3439809-1-aboorvad@linux.ibm.com commit 7f26a5e8040b4957ef4dbdfcde6cc7ba2db53937 Author: Carolina Jubran Date: Sun Sep 6 12:07:00 2026 +0300 net/mlx5e: Move representor vnic reporter to eswitch devlink port The representor vnic devlink health reporter is created and destroyed along the representor netdev (un)load path, which is not serialized by the devlink instance lock. Destroying the reporter from there triggers a devl_assert_locked() splat on driver unbind: WARNING: net/devlink/core.c:259 at devl_assert_locked+0x54/0x70, CPU#2: bash/3758 Modules linked in: mlx5_vdpa vringh vdpa mlx5_ib mlx5_fwctl mlx5_core ... CPU: 2 UID: 0 PID: 3758 Comm: bash Tainted: G W 6.19.0+ #1 PREEMPT Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), ... RIP: 0010:devl_assert_locked+0x54/0x70 Call Trace: devl_health_reporter_destroy+0x3a/0x1b0 mlx5e_vport_rep_unload+0x12d/0x2b0 [mlx5_core] mlx5_eswitch_unregister_vport_reps+0x1b8/0x220 [mlx5_core] ? __esw_offloads_unload_rep+0x190/0x190 [mlx5_core] ? kernfs_remove_by_name_ns+0xc3/0xf0 device_release_driver_internal+0x3b2/0x560 unbind_store+0xce/0xf0 Move the reporter's lifecycle to the eswitch devlink port (un)register paths, which are already serialized by the devlink instance lock, and store the handle on mlx5_devlink_port. Use the port's mlx5_vport as the reporter priv since the diagnose callback only needs a device handle and a vport number, and mlx5_vport carries both and is initialized before any representor driver probes. Fixes: cf14af140a5a ("net/mlx5e: Add vnic devlink health reporter to representors") Signed-off-by: Carolina Jubran Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260906090700.3761260-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit 3d676e458fe0c566f5a62753dc696b6a862fc412 Author: Alberto Carboneri Date: Fri Sep 4 13:54:37 2026 +0000 scsi: core: Validate MODE SENSE lengths in scsi_cdl_enable() scsi_cdl_enable() uses length fields returned by MODE SENSE to locate the ATA feature mode page in a 64-byte stack buffer. A target can report a total length shorter than its mode header and block descriptors. The unsigned subtraction used for the MODE SELECT length can wrap, and the separately computed buf_data can point beyond buf. During automatic scan, enable is false, so the read-modify-write of buf_data[4] can clear the low two bits of a target-selected out-of-bounds stack byte. scsi_mode_select() can then copy up to 64 bytes from outside the buffer into the outgoing MODE SELECT payload, disclosing stack contents to the target. This is reachable while scanning a USB storage device that identifies as an ATA device and advertises CDL support. No filesystem mount or userspace access to the block device is required. On upstream commit cee9395acd80 ("Linux 7.3-rc1"), a build-specific, one-vCPU QEMU/Raw Gadget proof using QEMU-only multi-UDC allocator sampling executed a fixed proof command inside the guest and created a UID-0-owned marker during automatic enumeration, with KASLR and NX enabled. The issue was independently found during security research at Drivesec S.r.l. Cap the available length to the buffer size. Validate and consume the mode header and block descriptor lengths before using the page, and require the five bytes needed to access the CDL field. Fixes: 1b22cfb14142 ("scsi: core: Allow enabling and disabling command duration limits") Reported-by: Sashiko AI Review Closes: https://lore.kernel.org/linux-scsi/20260717192313.93D791F000E9@smtp.kernel.org/ Link: https://lore.kernel.org/linux-scsi/20260717222931.AC4EE1F000E9@smtp.kernel.org/ Link: https://lore.kernel.org/linux-scsi/df13ec87ac9b28e3b0a2d9eb26477e276ff0278a.camel@HansenPartnership.com/ Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Pimen Flavian Dei (Drivesec S.r.l.) Signed-off-by: Pimen Flavian Dei (Drivesec S.r.l.) Signed-off-by: Alberto Carboneri (Drivesec S.r.l.) Link: https://lore.kernel.org/linux-scsi/20260717192313.93D791F000E9@smtp.kernel.org/ Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/20260904135410.360314-1-acarboneri@drivesec.com Signed-off-by: Martin K. Petersen (Oracle) commit 0338c68e22abd2ee509ec2e32508a50896618c32 Author: Lorenzo Bianconi Date: Fri Sep 4 12:32:55 2026 +0200 net: stmmac: initialize ptp_lock at probe time priv->ptp_lock is only initialized in stmmac_ptp_register(), which runs during __stmmac_open(). However, the lock is also used while the interface is down and has never been opened: tc_taprio_configure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmac_get_time() takes priv->ptp_lock. Using an uninitialized rwlock is undefined behaviour. Move the rwlock_init() to __stmmac_dvr_probe(), together with the other private locks, so that ptp_lock is always valid regardless of the interface state. Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API") Signed-off-by: Lorenzo Bianconi Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260904-stmmac-fix-ptp-clock-init-v1-1-df70eb1eb04d@oss.qualcomm.com Signed-off-by: Jakub Kicinski commit 113998aa372f4869bf62cfc75c28a2849e8487be Author: Aleksei Sviridkin Date: Fri Sep 4 18:55:40 2026 +0000 net: phylink: initialise link_state before a forced major config phylink_resolve() leaves link_state on the stack unpopulated on its disable and link-failed branches, which set only link_state.link. phylink_apply_manual_flow() then reads the struct's advertising on every mode but MLO_AN_FIXED, and has done so since long before force_major_config existed. force_major_config turns that into a write to the hardware. It is the only trigger for the major-config block that does not require mac_config, so phylink_major_config() programs the MAC for whatever the stack held, a zeroed interface is PHY_INTERFACE_MODE_NA, and the write-back stores it in pl->link_config.interface. phylink_replay_link_end() is the only in-tree setter, and sja1105_static_config_reload() calls it for every port that has a phylink instance, regardless of admin state. On a stopped port phylink_run_resolve() no-ops, so the flag outlives the call. The next resolve consumes it whatever branch it takes; an unpopulated branch is where that does damage. Found while developing a series that attaches a late PHY from a delayed work item and sets this flag there, so the PHY attached after its port was already up. The link stayed down until the port was cycled 29 minutes later. With this patch on the same board the same attach programs the MAC for 2500base-x rather than unknown, and the PHY's interrupt fires without a port bounce where it had stayed at zero throughout the failure. Fixes: 96969b132bf1 ("net: phylink: introduce helpers for replaying link callbacks") Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260904185540.2844261-1-f@lex.la Signed-off-by: Jakub Kicinski commit 0cb1fd924126f1f581621a5e804df98a02be9dff Author: Arun Easi Date: Thu Sep 3 10:55:47 2026 -0700 scsi: fnic: Fix missed link-up when critical IRQ targets offline CPU When CPU Hyper Threading is disabled, sibling CPUs remain present but are reported offline. Managed MSI-X IRQs can still receive affinity masks that include those offline CPUs. If a driver-critical vector is managed, it can be parked on an offline CPU and the driver may miss critical events such as link-up. Keep driver-critical vectors unmanaged so they can be migrated by the IRQ core when their target CPU is offlined. Since HWQ-0 is unmanaged now, in some queue combinations there can be no mappings to it in mq_map. So without the blk-mq fix mentioned below, system may crash during cpu offline/online tests. Fixes: 8a8449ca5e33 ("scsi: fnic: Modify ISRs to support multiqueue (MQ)") Cc: stable@vger.kernel.org Depends-on: commit 10845a105bbc ("blk-mq: skip CPU offline notify on unmapped hctx") Reviewed-by: Sesidhar Baddela Reviewed-by: Arulprabhu Ponnusamy Reviewed-by: Gian Carlo Boffa Reviewed-by: Karan Tilak Kumar Signed-off-by: Arun Easi Reviewed-by: Laurence Oberman Link: https://patch.msgid.link/20260903175547.57971-1-aeasi@cisco.com Signed-off-by: Martin K. Petersen (Oracle) commit 8aaeb56aff2a557a88f83ae866da2c91ad247e59 Author: Qingfang Deng Date: Tue Sep 8 15:21:31 2026 +0800 ppp_synctty: ensure a writeable skb header ppp_sync_txmunge() checks headroom before prepending the address and control bytes, but does not ensure that the skb header is writable. A received skb can reach this function through PPP channel bridging without passing through ppp_start_xmit(), which calls skb_cow_head(). For example, a PPPoE frame may share its buffer with a clone queued to an AF_PACKET socket. If it is bridged to a synchronous tty channel, the address/control bytes can overwrite data still visible to that socket. Use skb_cow_head() to ensure both sufficient headroom and a writable header. Fixes: 4cf476ced45d ("ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls") Signed-off-by: Qingfang Deng Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260908072135.877364-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski commit 1274045b0eda1df5a5cdd3e63ed48cf013b3b4ea Author: Venkat Rao Bagalkote Date: Thu Sep 3 13:13:29 2026 +0530 scsi: ibmvfc: Add Kconfig dependency to fix link failure when NVME_FC=m Building with CONFIG_SCSI_IBMVFC=y and CONFIG_NVME_FC=m results in a link failure: ibmvfc-nvme.o: undefined reference to `nvme_fc_register_localport' ibmvfc-nvme.o: undefined reference to `nvme_fc_register_remoteport' ibmvfc-nvme.o: undefined reference to `nvme_fc_unregister_localport' ibmvfc-nvme.o: undefined reference to `nvme_fc_unregister_remoteport' ibmvfc-core.o: undefined reference to `nvme_fc_rescan_remoteport' IS_ENABLED() evaluates to 1 for both =y and =m, so the nvme_fc_* call sites are kept in the object file. When SCSI_IBMVFC=y (built-in) but NVME_FC=m (loadable module), the linker cannot resolve these symbols at vmlinux link time. Add the same "depends on NVME_FC || NVME_FC=n" constraint already used by SCSI_LPFC to prevent this configuration. Reported-by: Pavithra Closes: https://lore.kernel.org/all/327877a29337aa526cc50ac88fbddb86@linux.ibm.com/ Signed-off-by: Venkat Rao Bagalkote Tested-by: Pavithra Acked-by: Tyrel Datwyler Link: https://patch.msgid.link/20260903074329.6705-1-venkat88@linux.ibm.com Signed-off-by: Martin K. Petersen (Oracle) commit be83178bfc44588f6e3adb827ed874c683193466 Author: Eric Dumazet Date: Sun Sep 6 18:01:04 2026 +0000 vxlan: initialize _md in vxlan_xmit_one() If a VXLAN device is configured with both VXLAN_F_COLLECT_METADATA and VXLAN_F_GBP, and a packet is transmitted through it using an external ip_tunnel_info that lacks the IP_TUNNEL_VXLAN_OPT_BIT flag, md is left pointing to the uninitialized _md stack variable: if (test_bit(IP_TUNNEL_VXLAN_OPT_BIT, info->key.tun_flags)) { if (info->options_len < sizeof(*md)) goto drop; md = ip_tunnel_info_opts(info); } Because IP_TUNNEL_VXLAN_OPT_BIT is not set, md is not updated and remains pointing to _md. Later, vxlan_build_skb() is called with md, which eventually calls vxlan_build_gbp_hdr(): if (vxflags & VXLAN_F_GBP) vxlan_build_gbp_hdr(vxh, md); Inside vxlan_build_gbp_hdr(), md->gbp is read: if (!md->gbp) return; gbp = (struct vxlanhdr_gbp *)vxh; ... if (md->gbp & VXLAN_GBP_DONT_LEARN) gbp->dont_learn = 1; If the stack contains garbage, this causes: 1) VXLAN_HF_GBP flag to be spuriously set in the VXLAN header. 2) gbp->dont_learn and gbp->policy_applied to be set from stack bits. 3) gbp->policy_id to receive 16 bits of uninitialized kernel stack data, leaking it onto the wire. Fix this by zero-initializing _md. If IP_TUNNEL_VXLAN_OPT_BIT is not present, md->gbp remains 0, and vxlan_build_gbp_hdr() returns early without modifying the VXLAN header. Fixes: ee122c79d422 ("vxlan: Flow based tunneling") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260906180111.1973188-2-edumazet@google.com Signed-off-by: Jakub Kicinski commit 779f202a92ef10a426efc07d0f4267918cb07ca3 Author: Karl Mehltretter Date: Sun Sep 6 19:10:09 2026 +0200 scsi: qla2xxx: Fix the ql2xfc2target parameter description The module parameter is ql2xfc2target, but its MODULE_PARM_DESC() names qla2xfc2target, so modinfo describes a parameter that does not exist and shows no description for the real one. Use the parameter name in the description. Fixes: 877b03795fcf ("scsi: qla2xxx: Add option to disable FC2 Target support") Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260906171009.2560-1-kmehltretter@gmail.com Signed-off-by: Martin K. Petersen (Oracle) commit 264bf9655c3d067d775a46f05eb8c871c488a864 Author: Karl Mehltretter Date: Sun Sep 6 19:09:25 2026 +0200 scsi: pm80xx: Fix the use_msix, use_tasklet and read_wwn parameter descriptions The MODULE_PARM_DESC() lines of use_msix, use_tasklet and read_wwn all name a parameter zoned, which does not exist, and the use_tasklet one repeats the use_msix text. modinfo shows three "zoned" entries and no description for the real parameters. Name the right parameters and describe use_tasklet. Fixes: efa1fca45082 ("scsi: pm8001: Remove PM8001_USE_MSIX") Fixes: 205430290ad0 ("scsi: pm8001: Remove PM8001_USE_TASKLET") Fixes: 80975adc79dd ("scsi: pm8001: Remove PM8001_READ_VPD") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/20260906170925.2524-1-kmehltretter@gmail.com Signed-off-by: Martin K. Petersen (Oracle) commit ef39fca8508597fa565cf2be72a884a712fb98af Author: Ratheesh Kannoth Date: Thu Sep 3 07:35:33 2026 +0530 octeontx2-pf: reset HTB scheduler topology before freeing queues HTB offload programs NIX_AF_TLxX_TOPOLOGY on QoS-allocated scheduler queues via otx2_qos_txschq_set_parent_topology(), but teardown freed those queues without clearing TOPOLOGY. The AF only restores PARENT and SCHEDULE on free, so PRIO_ANCHOR/RR_PRIO settings can survive in the shared scheduler pool and affect later allocations. Add otx2_qos_reset_schq_topology() and otx2_qos_free_hw_schq() to zero TL4 through TL2 TOPOLOGY before each schq is returned to the AF during hierarchy teardown and cfg rollback. Skip the aggregation level (TL1): it is a per-tx-link queue shared by the PF, default Tx hierarchy and VFs, and is not freed back to the AF by nix_txschq_free_one(). Fixes: 5e6808b4c68d ("octeontx2-pf: Add support for HTB offload") Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260903020533.3068041-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski commit c88a6338ae485e4d6210cc74cdb7664d6476c925 Author: Ali Ahmet Memis Date: Mon Aug 3 10:21:48 2026 +0000 hwmon: (nct6694) do not expose enable on DTIN temperature channels The driver registers 26 temperature channels, all advertising HWMON_T_ENABLE, and indexes the enable bitmap with the raw channel: data->hwmon_en.tin_en[channel / 8] |= BIT(channel % 8); tin_en is two bytes and only covers the 5 THR and 5 TDP channels (index 0-9). The 16 DTIN channels (index 10-25) are enabled by the firmware and were never meant to carry an enable bit. Because the control structure is packed, writing temp17_enable and above indexes past tin_en into the fin_en bytes that follow it, so it toggles fan enable state instead; nct6694_hwmon_init() then sends the whole structure back to the device, and reads report fan state as temperature state. It stays within the structure, so this is not a memory safety problem, but on a board that uses the fan channels it is not harmless. Give the DTIN channels a temperature config without HWMON_T_ENABLE so the core never creates their enable attribute. The enable path is then reachable only for the first 10 channels, which stay within tin_en, and fin_en is left alone. The DTIN input and limit attributes are unchanged. Fixes: 197e779d29d8 ("hwmon: Add Nuvoton NCT6694 HWMON support") Suggested-by: Ming Yu Link: https://lore.kernel.org/all/20260802124730.20387-1-ali@iusegentoo.com/ Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260803102148.14196-1-ali@iusegentoo.com Signed-off-by: Guenter Roeck commit 06d48355bf41028c1321acda6a4391cd70098be8 Author: Arie Miller Date: Thu Sep 3 22:21:29 2026 -0400 hwmon: (asus_rog_ryujin) Synchronize HID command and report handling rog_ryujin_execute_cmd() holds status_report_request_lock while reinitializing a completion, intending to exclude raw-event handling. However, rog_ryujin_raw_event() does not acquire the lock when it updates the completion. A response can therefore race with reinit_completion() and be lost, leaving the command to time out. Hold the lock while parsing reports and updating their completions. Use the irqsave variants in both paths because raw-event handling may run in interrupt context. Fixes: ed3e03790c5c ("hwmon: Add driver for ASUS ROG RYUJIN II 360 AIO cooler") Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hwmon/20260812104617.858D01F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol sparse Signed-off-by: Arie Miller Link: https://patch.msgid.link/20260904022129.97896-3-renari@arimil.com Signed-off-by: Guenter Roeck commit 8042312e73c50de82634ce63eae7cf219464b481 Author: Arie Miller Date: Thu Sep 3 22:21:28 2026 -0400 hwmon: (asus_rog_ryujin) Validate HID report lengths rog_ryujin_raw_event() parses response headers and payload fields without first checking that they are present in the received report. A short report can therefore make the driver consume uninitialized bytes from the HID transport buffer and expose them as sensor values through sysfs. Validate the response header and the fields used by each response type before parsing them. Fixes: ed3e03790c5c ("hwmon: Add driver for ASUS ROG RYUJIN II 360 AIO cooler") Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hwmon/20260812104617.858D01F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol sparse Signed-off-by: Arie Miller Link: https://patch.msgid.link/20260904022129.97896-2-renari@arimil.com Signed-off-by: Guenter Roeck commit 4ee875c423c66c45d7ef7bbff403cd0e3971e0a2 Author: Linmao Li Date: Fri Aug 28 14:19:49 2026 +0800 hwmon: (corsair-cpro) Remove debugfs entries when probe fails ccp_debugfs_init() registers debugfs files whose private data is the devm allocated ccp. If hwmon_device_register_with_info() fails right after it, ccp_probe() returns without removing them: the HID core then frees ccp, and ccp_remove() is not called for a failed probe, so the files stay behind. Reading one of them dereferences the freed pointer. Remove the debugfs entries on that error path. debugfs_remove_recursive() waits for readers already inside the show callbacks, so ccp is no longer reachable through debugfs by the time probe returns. Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hwmon/20260708031612.BD7E61F000E9@smtp.kernel.org/ Fixes: 5997eb60f896 ("hwmon: (corsair-cpro) Add firmware and bootloader information") Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260828061949.3151191-1-lilinmao@kylinos.cn Signed-off-by: Guenter Roeck commit 09a9e1746a87845d7d8e2b4e23bb613306effdff Author: Pengpeng Hou Date: Sun Aug 30 20:50:44 2026 +0800 hwmon: (aspeed-pwm-tacho) Propagate reset deassert errors aspeed_pwm_tacho_probe() installs its reset cleanup action and configures the controller after an unchecked reset deassertion. Stop probing when the reset controller rejects the transition, before the hwmon device becomes visible. Fixes: 18c514cc0e02 ("hwmon: (aspeed-pwm-tacho) Deassert reset in probe") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260830125044.97718-1-pengpeng@iscas.ac.cn Signed-off-by: Guenter Roeck commit bb2424c3502cc72292eedade46960c331d5f28fb Author: Cong Nguyen Date: Tue Sep 1 22:54:04 2026 +0700 hwmon: (gpio-fan) take fan_data->lock in gpio_fan_shutdown() set_fan_speed() writes the control GPIOs one bit at a time. Every other caller locks around it; gpio_fan_shutdown() doesn't. If it races a locked caller, the GPIO writes can interleave and leave the fan at a speed neither caller asked for. Fixes: b95579cd8795 ("hwmon: (gpio-fan) Add a shutdown handler to poweroff the fans") Reported-by: Sashiko AI review Link: https://lore.kernel.org/r/20260830152150.27F5F1F000E9@smtp.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Link: https://patch.msgid.link/20260901155404.1532092-1-congnt264@gmail.com Signed-off-by: Guenter Roeck commit 508baf1713f32f287bfb4f85d759403ec8ba35a3 Author: Linmao Li Date: Mon Aug 31 09:45:09 2026 +0800 hwmon: (corsair-cpro) Create debugfs entries after hwmon registration ccp_debugfs_init() registers debugfs files whose private data is the devm allocated ccp. It runs before hwmon_device_register_with_info(), so when that registration fails, ccp_probe() returns with the files still in place. The HID core then frees ccp, and ccp_remove() is not called for a failed probe, so nothing removes them later either. Reading one of the files dereferences the freed pointer. Create the debugfs entries only after the hwmon device has been registered, so no failing path can leave them behind. The two version queries stay where they are. They send USB commands without holding ccp->mutex, which is only safe as long as nothing else can call send_usb_cmd(); once the hwmon device is registered its callbacks can do so concurrently. Only the debugfs creation moves, and it is told which queries succeeded. Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hwmon/20260708031612.BD7E61F000E9@smtp.kernel.org/ Suggested-by: Guenter Roeck Fixes: 5997eb60f896 ("hwmon: (corsair-cpro) Add firmware and bootloader information") Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260831014509.3352442-1-lilinmao@kylinos.cn Signed-off-by: Guenter Roeck commit 6d760f8b41aed74de4402440e4db663d261478bd Author: Vishnu Razdan Date: Mon Aug 24 23:58:00 2026 -0700 hwmon: (pmbus) Clear generic status alarms with CLEAR_FAULTS Some hwmon alarms fall back to STATUS_WORD summary bits when no individual limit alarm is available. On PMBus 1.2 and newer devices, pmbus_get_boolean() acknowledges these alarms with the same byte-data write used for detailed status registers. For example, PB_STATUS_INPUT is 0x2000, so it is truncated to zero when passed to _pmbus_write_byte_data(). The resulting write cannot acknowledge the input alarm. PMBus 1.3 Part II, sections 10.2.4 and 10.2.5, excludes ordinary STATUS_BYTE and STATUS_WORD summary bits from individual clearing. Their summary bits clear when the underlying status bits clear, so changing this to a word-data write would not fix the generic input alarm either. Use the existing page CLEAR_FAULTS path for generic STATUS_WORD alarms, including devices whose status accessor uses STATUS_BYTE. Keep individual byte writes for detailed status registers on PMBus 1.2 and newer devices. As with the existing older-device fallback, CLEAR_FAULTS can clear other latched status; an active condition can reassert its status. Fixes: 35f165f08950 ("hwmon: (pmbus) Clear pmbus fault/warning bits after read") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Vishnu Razdan Link: https://patch.msgid.link/20260824-vrazdan-pmbus-status-word-b4-v1-1-2606ecd0c029@openai.com Signed-off-by: Guenter Roeck commit 286b175bb03893949f24621f356abd9d20368b0a Author: Javier Carrasco Date: Sun Aug 23 19:59:01 2026 +0200 hwmon: (chipcap2) fix channels in humidity alarm notifications hwmon_notify_event() expects the channel number as its last argument, taken into account with the type parameter that it is a humidity sensor type. Given that this device only provides one humidity channel, 0 must be passed. The custom construct to enumerate the channels makes wrong assumptions by listing all types together (temperature and humidity). Remove the custom channel enumeration and pass the right channel to hwmon_notify_event() for hwmon_humidity_min_alarm and hwmon_humidity_max_alarm. Fixes: 3af350929e75 ("hwmon: Add support for Amphenol ChipCap 2") Cc: stable@vger.kernel.org Signed-off-by: Javier Carrasco Link: https://patch.msgid.link/20260823-chipcap2_locks-v2-1-6a26c8e9e2fc@gmail.com Signed-off-by: Guenter Roeck commit cb26524ef4ac28fcfa554c0656e8dc412c38a8ff Author: Paulo Alcantara Date: Wed Sep 9 17:02:40 2026 -0300 smb: client: fix one-byte OOB read in smb2_parse_native_symlink() When parsing a share-root relative native symlink, memcpy copies smb_target+1 (skipping the leading separator) but uses strlen(smb_target)+1 as the length, reading one byte past the allocated buffer. This fixes the following KASAN splat when accessing an SMB symlink with a target of '\a\b': BUG: KASAN: slab-out-of-bounds in smb2_parse_native_symlink+0x4f5/0xca0 Read of size 5 at addr ffff88800878fe21 by task netfsfuzz-execu/1 CPU: 1 UID: 0 PID: 1 Comm: netfsfuzz-execu Tainted: G N 7.2.0-11943-g2709dd5ae32f-dirty #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996) Call Trace: dump_stack_lvl+0x7b/0xa0 print_report+0xd0/0x630 kasan_report+0xe5/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 smb2_parse_native_symlink+0x4f5/0xca0 parse_reparse_point+0x68a/0x1530 reparse_info_to_fattr+0x752/0xa20 cifs_get_fattr+0x873/0x15b0 cifs_get_inode_info+0xc0/0x310 cifs_lookup+0x308/0xa70 __lookup_slow+0x122/0x2b0 lookup_slow+0x50/0x70 path_lookupat+0x525/0xaf0 filename_lookup+0x1f2/0x550 vfs_statx+0xd1/0x1a0 vfs_fstatat+0x65/0xc0 __do_sys_newfstatat+0x9a/0x120 do_syscall_64+0xdd/0x4a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported-by: Yuanfu Xie Fixes: 723f4ef90452 ("cifs: Fix parsing native symlinks relative to the export") Suggested-by: Pali Rohar Reviewed-by: Pali Rohar 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 commit 66ef5adb75446627f8b6c26cd04f2adc86d4de56 Author: Marek Vasut Date: Sat Sep 5 15:02:32 2026 +0200 net: ks8851: Fix receiver error in 100BASE-TX mode following software power-down KSZ8851 errata sheet DS80000716D-page 4 Module 3 [1] states that, when issuing a software power-down (PMECR[1:0] = 10) followed by a power-on (PMECR[1:0] = 00), the receiver circuit can fail to start properly preventing communication. The Transmitter will still send data, but no data will be received. The errata sheet also includes a workaround, which states that, it is recommended that the software power-down feature not be used. Implement that workaround and drop the entry into software power-down mode. The ks8851_write_mac_addr() calls entry into normal power-on mode at the very beginning of the function, therefore dropping the second call to enter software power-down mode is sufficient here. The ks8851_net_stop() can only be called after ks8851_net_start() was already called, and ks8851_net_start() also makes the MAC enter normal power-on mode, therefore it is also fine to drop the call to enter software power-down mode from ks8851_net_stop(). This will lead to a slight increase in power consumption, but it also fixes a sporadic reliability problem on at least KSZ8851-16MLL, which is where the problem was reported and this fix was tested. [1] https://ww1.microchip.com/downloads/en/DeviceDoc/80000716D.pdf Fixes: 3ba81f3ece3c ("net: Micrel KS8851 SPI network driver") Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Marek Vasut Link: https://patch.msgid.link/20260905130327.203851-1-marex@nabladev.com Signed-off-by: Jakub Kicinski commit 59fb389ad6bf50916189e56dafcd225ab977f874 Author: Jan Havran (Advantech Czech) Date: Mon Sep 7 15:48:18 2026 +0200 net: dsa: lantiq_gswip: fix GSWIP_MDIO_PHY_FCONTX_EN value Per the GSW145 data sheet, the FCONTX (bits 8:7) and FCONRX (bits 6:5) flow-control fields of the PHY_ADDR_n register both encode 00 = AUTO, 01 = EN, 10 = reserved, 11 = DIS. GSWIP_MDIO_PHY_FCONTX_EN was 0x0100, i.e. field value 10 (the reserved encoding), instead of 0x0080 (01 = EN); FCONRX_EN is already 0x0020 (01). Enabling tx flow control therefore wrote the reserved value. Set FCONTX_EN to 0x0080. The register is shared by all supported parts. Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Jan Havran (Advantech Czech) Reviewed-by: Daniel Golle Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260907134818.16670-4-havran.jan@email.cz Signed-off-by: Jakub Kicinski commit b824476c56a153934c67c9e0f873e1fd967743d6 Author: Yilin Zhang Date: Sat Sep 5 00:28:00 2026 +0800 inet: frags: invalidate queues before flushing them fqdir_pre_exit() flushes the skbs from incomplete queues without changing their completion state. A fragment which found a queue before high_thresh was cleared can then acquire the queue lock and reuse stale reassembly metadata. A queue concurrently killed after fqdir->dead is set can instead become INET_FRAG_COMPLETE|INET_FRAG_HASH_DEAD while still holding its old skbs; skipping it because it is complete leaves those references behind until asynchronous fqdir teardown. For IPv6, stale metadata can make ip6_frag_reasm() use the old nhoffset with a new skb and access memory out of bounds. The resulting heap corruption can be leveraged for local privilege escalation when unprivileged network namespaces are available. Unflushed fragments can also keep conntrack references alive after the conntrack per-net cleanup point. Kill each incomplete queue, then flush every queue still owned by the dying rhashtable. HASH_DEAD identifies that ownership, while complete queues without it are already owned by another destroy path and must be left alone. Releasing a timer reference removed by inet_frag_kill() is deferred to inet_frag_putn(), after the queue lock is dropped. KASAN report: BUG: KASAN: slab-out-of-bounds in ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) Write of size 1 at addr ff110001039c6e00 by task poc/771 Call Trace: ? ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479 (discriminator 5)) ip6_input_finish (net/ipv6/ip6_input.c:534) ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3)) packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) The buggy address belongs to the object at ff110001039c6b40 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 0 bytes to the right of allocated 704-byte region [ff110001039c6b40, ff110001039c6e00) BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) Read of size 1 at addr ff110001039c6e08 by task poc/771 Call Trace: ? ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) ip6_input_finish (net/ipv6/ip6_input.c:534) ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3)) packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) packet_sendmsg (net/packet/af_packet.c:2959 net/packet/af_packet.c:3053 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) The buggy address belongs to the object at ff110001039c6b40 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 8 bytes to the right of allocated 704-byte region [ff110001039c6b40, ff110001039c6e00) Fixes: 006a5035b495 ("inet: frags: flush pending skbs in fqdir_pre_exit()") Cc: stable@vger.kernel.org Reported-by: Kimi Security Team Tested-by: Weiming Shi Reviewed-by: Eric Dumazet Signed-off-by: Yilin Zhang Link: https://patch.msgid.link/20260904162800.1095662-1-yilinzhang@moonshot.ai Signed-off-by: Jakub Kicinski commit d22c3e0088e85be8131f7a9283f759cdbb20726d Author: Sven Schnelle Date: Wed Sep 9 11:29:53 2026 +0200 selftests/ftrace: Fix unique symbol check in kprobe_non_uniq_symbol.tc The current regex also matches symbols in modules, which makes the test fail on s390 where name_show is present only once in the kernel, but also multiple times in modules: 000001b1401cdc20 t name_show 000001b0c05e6c40 t name_show [mdev] 000001b0c0495f30 t name_show [i2c_core] Fix this by changing the regular expression to only match the function name. Link: https://lore.kernel.org/all/20260909092954.2200558-1-svens@linux.ibm.com/ Fixes: 03b80ff8023a ("selftests/ftrace: Add new test case which checks non unique symbol") Signed-off-by: Sven Schnelle Reviewed-by: Steven Rostedt Signed-off-by: Masami Hiramatsu (Google) commit a58cbc8b36ec0cd00d2ba3de7d003de818a27523 Author: Xueqin Luo Date: Tue Sep 1 15:29:54 2026 +0800 power: supply: ds2780: Fix ds2780_get_capacity() returning raw value ds2780_get_capacity() returns the raw register value instead of 0 on success. The capacity is already stored in *capacity, so the function should return 0 to indicate success. Fixes: 275ac74629c4 ("w1: add Maxim/Dallas DS2780 Stand-Alone Fuel Gauge IC support") Signed-off-by: Xueqin Luo Link: https://patch.msgid.link/20260901072954.1953121-1-luoxueqin@kylinos.cn Signed-off-by: Sebastian Reichel commit 45d4af4e80a25881b6b75e8e34872c555c43a41d Author: Karl Mehltretter Date: Wed Sep 9 08:46:23 2026 +0200 power: supply: Fix maintenance charge table kernel-doc struct power_supply_maintenance_charge_table contains charge_safety_timer_minutes, but its kernel-doc describes safety_timer_minutes. This leaves the real member undescribed and adds a nonexistent member to the generated documentation. Use the member's actual name. Fixes: d72ce7d32478 ("power: supply: ab8500: Standardize maintenance charging") Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260909064623.90737-1-kmehltretter@gmail.com Signed-off-by: Sebastian Reichel commit f444a42dce5caf5856b5289c48e0d48e531649d3 Author: Xueqin Luo Date: Tue Sep 1 13:36:52 2026 +0800 power: supply: max17042_battery: Fix vmin assigned instead of vmax in DT parsing The else branch of the "maxim,over-volt" property check assigns the parsed value to chip->vmin instead of chip->vmax, so chip->vmin is overwritten and chip->vmax never gets the DT value. Fixes: 6a3b47a5a5fc ("power: supply: Match DT value types") Signed-off-by: Xueqin Luo Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260901053653.1668492-1-luoxueqin@kylinos.cn Signed-off-by: Sebastian Reichel commit 01504d14e47b34779911250dd308a03f6ef681c2 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:46 2026 +0800 watchdog: msc313e: Sync timeout value if WDT was running at boot If WDT was running at boot, the hardware timeout might be set to values other than the final software timeout. To be consistent, set the hardware timeout to match the final software timeout (i.e., after watchdog_init_timeout()) if WDT was running. Fixes: ffd264bd152c ("watchdog: msc313e: Check if the WDT was running at boot") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-8-tzungbi@kernel.org Signed-off-by: Guenter Roeck commit ab390021b2a3bb4cc875f28a6f76d13de90d7457 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:45 2026 +0800 watchdog: msc313e: Fix undefined behavior readw() returns a u16. Left shifting a u16 by 16 bits yields undefined behavior. Cast to u32 explicitly before the shift. Fixes: ffd264bd152c ("watchdog: msc313e: Check if the WDT was running at boot") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-7-tzungbi@kernel.org Signed-off-by: Guenter Roeck commit 4f6817c9eff4aa1078e16652d82e4b7ef4ffae3e Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:44 2026 +0800 watchdog: msc313e: Fix spurious reset on suspend If the hardware watchdog was started by the bootloader and the device is suspended before userspace opens it, the ping worker (from watchdog core) is frozen and the active hardware timer continues running. This leads to a spurious system reset. Check both watchdog_active() and watchdog_hw_running() when deciding whether to start or stop the watchdog during suspend and resume. Additionally, call watchdog_stop_ping_on_suspend() to ensure the ping worker be correctly paused and restarted during suspend and resume. Fixes: ffd264bd152c ("watchdog: msc313e: Check if the WDT was running at boot") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-6-tzungbi@kernel.org Signed-off-by: Guenter Roeck commit 3db2df24e7f11fb117718f6abe326628d91bc500 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:43 2026 +0800 watchdog: msc313e: Enable clock before accessing hardware registers msc313e_wdt_probe() reads from hardware registers without ensuring the required clock is enabled. Furthermore, if the bootloader leaves the watchdog running, msc313e_wdt_probe() sets WDOG_HW_RUNNING without increasing the clock's reference count. While the clock is currently supplied as a fixed clock by the device tree (`xtal_div2` in arch/arm/boot/dts/sigmastar/mstar-v7.dtsi) which masks the physical issue, this still violates the API usage. Call clk_prepare_enable() before reading WDT registers. If the WDT is running, leave the clock enabled so the CCF reference counter is balanced. Fixes: ffd264bd152c ("watchdog: msc313e: Check if the WDT was running at boot") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-5-tzungbi@kernel.org Signed-off-by: Guenter Roeck commit 3db30f315935c2fb0d95f46b7a593b5b4d3ec3d0 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:42 2026 +0800 watchdog: msc313e: Fix clock leak and spurious timer in settimeout() msc313e_wdt_settimeout() unconditionally calls msc313e_wdt_start() which introduces two severe bugs: 1. If the watchdog is already active, calling start() again will increase the reference count of the clock again. However stop() is only called once, the reference count is unbalance. 2. If the watchdog is stopped, calling settimeout() will start the hardware timer accidentally. Factor out the register-writing logic into a helper function. Only call it in settimeout() if the watchdog is running. Otherwise, simply update `wdev->timeout`. Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-4-tzungbi@kernel.org Signed-off-by: Guenter Roeck commit 3c73a37f5e40972ce26d8eeb98e8b938d719b069 Author: Tzung-Bi Shih Date: Sat Aug 29 00:13:41 2026 +0800 watchdog: msc313e: Avoid division by zero clk_get_rate() could return 0. Avoid a division by zero panic. Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260828161348.13212-3-tzungbi@kernel.org Signed-off-by: Guenter Roeck commit 0fa37512eb747e4ffdcf367274f9e72845f1bca4 Author: David Arcari Date: Thu Sep 3 14:20:29 2026 -0400 watchdog: fix hrtimer start when pretimeout is zero Per the watchdog API, a pretimeout value of 0 disables the feature. However, watchdog_hrtimer_pretimeout_start() fails to verify if the pretimeout is non-zero before arming the timer. This omission inadvertently starts the software pretimeout timer, which could result in the pretimeout handler executing incorrectly when the watchdog timeout is reached. Fix this by adding a check for wdd->pretimeout before calling hrtimer_start(), ensuring the disabled state is respected. Fixes: 7b7d2fdc8c3e ("watchdog: Add hrtimer-based pretimeout feature") Signed-off-by: David Arcari Link: https://patch.msgid.link/20260903182029.936030-1-darcari@redhat.com Signed-off-by: Guenter Roeck commit 9a1599eeb8d18a2113e4cabcbd3bec5a8377dbed Merge: 5be081b83abd3f f01b8275745efe Author: Jakub Kicinski Date: Wed Sep 9 13:32:58 2026 -0700 Merge branch 'mptcp-misc-fixes-for-v7-3-rc1' Matthieu Baerts says: ==================== mptcp: misc fixes for v7.3-rc1 Here are various unrelated fixes: - Patch 1: Do not reschedule the RTX timer for sockets that fell back to TCP. A fix for v5.7. - Patch 2: Avoid copying thmac which will not be used and could be uninitialised. A fix for v5.7. - Patch 3: Re-set the request backup flag when SYN cookies are used. A fix for v5.9. - Patch 4: Drop pending ADD_ADDR when removing ID0, and avoid a WARN. A fix for v5.13. - Patch 5: Handle invalid suboptions where the checksum is requested in the MP_CAPABLE 4th ACK with data, but not added in the option. A fix for v5.14. - Patch 6: Prevent a race between mptcp_disconnect() and the retransmit timer. A fix for v5.17. - Patch 7: Fix a use-after-free in the selftests that could lead to false positive. A fix for v5.17. - Patch 8: Limit new addresses with the userspace PM to avoid an address ID overflow. A fix for v5.19. - Patch 9: Reset the ADD_ADDR retransmission counter when the timer is reused. A fix for v5.19. - Patch 10: Remove unneeded and confusing READ_ONCE() annotations. A fix for v6.13. - Patches 11-12: Get nstat counters for the current test, not since the creation of the netns. A fix for v6.19. - Patch 13: Fix an uninit-value in mptcp_write_data_fin for a corner case now that only a part of the tcp_out_options struct is reset. A fix for v7.1. - Patches 14-15: Two follow-up patches addressing minor comments discovered after the human review. A fix for v7.3-rc1. ==================== Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit f01b8275745efe611284f6c3628099a81a421f0d Author: Paolo Abeni Date: Tue Sep 8 16:07:20 2026 +0200 mptcp: avoid pruning for OoW data Pruning is expansive and destructive, do it only when we expect to accept the skb triggering the cleanup. Fixes: e468d371180d ("mptcp: implemented OoO queue pruning") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-15-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit a4257a91af7a77a8347d33413ec9e54106f7ff48 Author: Paolo Abeni Date: Tue Sep 8 16:07:19 2026 +0200 mptcp: being below memory limit is a likely() condition The current compiler hint annotation is wrong, due to inverted logic in the previous revision of the relevant code. Fixes: e468d371180d ("mptcp: implemented OoO queue pruning") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-14-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit b110f1dd6cb6a9930503354a01a315e0a821eaa7 Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:18 2026 +0200 mptcp: options: fix uninit-value in mptcp_write_data_fin When sending a DATA_FIN without data, and because the DATA_FIN occupies 1 octet of the connection-level sequence space [1], it is then required to add a DSS mapping with specific values. If the checksum has been negotiated, it also needs to be computed, and included in the outgoing packet, and thus the initial csum data needs to be reset to 0 as well. This is no longer the case since commit cfcceb7a39fc ("tcp: shrink per-packet memset in __tcp_transmit_skb()"), because the whole ext_copy structure is no longer zeroed by default. This seems to be the only case where use_map is changed and set afterwards, so initialising the csum field only in this case, along with other fields for this specific case. Fixes: cfcceb7a39fc ("tcp: shrink per-packet memset in __tcp_transmit_skb()") Cc: stable@vger.kernel.org Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.3.3 [1] Link: https://sashiko.dev/#/patchset/20260812-net-next-mptcp-misc-feat-7-3-v1-0-1905a818f6cb%40kernel.org?part=2 Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-13-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit d23c41366e85f149b48323d66adc36c4a9f18cbd Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:17 2026 +0200 selftests: mptcp: lib: get counters for the right test When the value for a MIB counter is required, mptcp_lib_get_counter is called. It tries to use the cache, if available. If not it falls back to calling 'nstat' directly by looking at the absolute counters. That's an issue for tests that don't recreate the netns for each subtest. In this case, 'nstat -a' will look at the counters for the netns. Instead, it should look at the increment for the current test, by using the history recorded in /tmp/.nstat, if available, and not using '-a' which was dumping the absolute values. While at it, rename the previous 'hist' variable to 'cache' as it was used to look at the cache, not the nstat history. Fixes: 71388a9f331d ("selftests: mptcp: lib: get counters from nstat history") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-12-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit e1a56368eac18b3b4b956b794526e8713c48a0ec Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:16 2026 +0200 selftests: mptcp: lib: dump nstat for the right test In case of errors, mptcp_lib_pr_nstat is called to dump the nstat counters, but for some tests, it was dumping the counters for all subtests, not just the current one. That's an issue for tests that don't recreate the netns for each subtest, e.g. mptcp_connect.sh. In this case, 'nstat -a' will look at the absolute counters since the creation of the netns, making debugging harder. Instead, it should dump the counters for the current test, by using the history recorded in /tmp/.nstat if available, and not using '-a' which was dumping the absolute values instead of calculating increments. While at it, rename the previous 'hist' variable to 'cache' as it was used to look at the cache, not the nstat history. Fixes: 658e53141780 ("selftests: mptcp: join: dump stats from history") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-11-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit caa4a79f74f32084ce28aee8653bc04df745970d Author: Paolo Abeni Date: Tue Sep 8 16:07:15 2026 +0200 mptcp: remove unneeded READ_ONCE() annotation The subflow->fully_established flag is always written under the subflow socket lock. Reading such value under the same lock does not require any ONCE annotation. Fixes: 581c8cbfa934 ("mptcp: annotate data-races around subflow->fully_established") Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-10-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit f968190c0b42ea2004dc1426359a53ec365a7a37 Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:14 2026 +0200 mptcp: pm: reset retrans_time when ADD_ADDR entry is reused When an ADD_ADDR entry is reused, the timer is re-armed, because the goal is to re-announce an ADD_ADDR, and eventually retransmit it if needed. In this case, the retransmission counter should be reset as well, so the re-announced address gets its retransmissions back instead of relying on what was left before, and possibly not being able to retransmit it. Fixes: 304ab97f4c7c ("mptcp: allow ADD_ADDR reissuance by userspace PMs") Cc: stable@vger.kernel.org Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-0-b8f496d71664%40kernel.org?part=4 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-9-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit f9f0068e8813d8c10d016b030fc3a320d0b6767c Author: Qing Luo Date: Tue Sep 8 16:07:13 2026 +0200 mptcp: pm: userspace: fix address ID overflow When all MPTCP address IDs (1-255) are exhausted in the userspace PM, find_next_zero_bit() returns MPTCP_PM_MAX_ADDR_ID + 1 (256). This value overflows when stored in the u8 field e->addr.id, resulting in ID 0 being stored and the entry being incorrectly added to the list. ID 0 is reserved for the initial connection in MPTCP, so this overflow can cause address conflicts. Note: the in-kernel PM already has an 'endpoints == MPTCP_PM_MAX_ADDR_ID' check in mptcp_pm_nl_append_new_local_addr() that returns -ERANGE before reaching find_next_zero_bit(), preventing this overflow. So this fix only addresses the userspace PM path. Check the find_next_zero_bit() result against MPTCP_PM_MAX_ADDR_ID and return -ENOSPC if all IDs are truly exhausted. Move the ID allocation check before the memory allocation so that the error path does not need to free the allocated entry. Fixes: 4638de5aefe5 ("mptcp: handle local addrs announced by userspace PMs") Cc: stable@vger.kernel.org Signed-off-by: Qing Luo Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-8-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit 730444f094b12052916ebd7e14fe57bc3d47bf38 Author: Gang Yan Date: Tue Sep 8 16:07:12 2026 +0200 selftests: mptcp: fix an UAF in mptcp_connect.c At the end of 'sock_connect_mptcp()', it calls 'freeaddrinfo(addr)', the 'peer' pointer (which points into 'addr') remains. Later, the main loop uses this peer pointer for reconnection attempts. If the memory has been freed and reused, the address data could be overwritten, resulting in an invalid remote address. This patch keeps the addrinfo list allocated for the whole process lifetime so "peer" remains valid across reconnects; the memory will be released at exit() time. Fixes: 05be5e273c84 ("selftests: mptcp: add disconnect tests") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-7-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit 85c580b0d8590520ae00a15c29e9fb9c99427a3e Author: Paolo Abeni Date: Tue Sep 8 16:07:11 2026 +0200 mptcp: prevent race between disconnect() and rtx Sashiko noted that the two event can race, leading to inconsistent status. Prevent the race using the synchronous timer stop operation. Cc: stable@vger.kernel.org Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation") Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-6-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit ab36b1a80942c78ddb04d006ff38aa7ed3ec0e5e Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:10 2026 +0200 mptcp: options: handle MPC data + csum reqd + no csum Before this modification, a remote peer could send an MP_CAPABLE with data, with the checksum flag set, but without adding the actual 2 bytes of checksum. As a result, uninitialised bytes could be used for the 'csum' field. That was not a critical issue, because this 'csum' field is only used to compare with the expected one, if previously negotiated in the 3WHS. Worst case, the checksum is likely wrong, a fallback is done without a reject if the negotiation was done earlier. That's OK. Yet, better to take the expected path with this case: only look at the checksum flag for MP_CAPABLEs not carrying a data-len. Such packet can be seen as a 3rd or 4th ACK. The RFC8684 mentions [1] that the 3rd packet should have the checksum flag set. When an MPC + ACK contains data, the checksum flag is redundant with the checksum field. It is not clear what should be done for the 4th ACK, nor if the flag has to be set if the checksum field is set. Therefore, it seems fine to only look at the presence of the checksum field, not to break the interaction with stacks that were not setting both. Note that linked to this checksum flag on the 3rd ACK, with the current implementation, we can have a situation where the SYN packets have no checksum flag, but the 3rd ACK has one, and this is the one that will be taken into account. First, that's clearly not directly linked to this patch, but Clashiko forced us to look at that. At the end, that seems fine to act like that: yes that's not how the negotiation should work, but being flexible without introducing side effects is also fine: fixing this would mean increasing the complexity, and that's not worth it. Fixes: 208e8f66926c ("mptcp: receive checksum for MP_CAPABLE with data") Cc: stable@vger.kernel.org Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.1-23 [1] Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-0-b8f496d71664%40kernel.org?part=1 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-5-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit 2ac7d6e620764f1fc79eb4edd3610a7a661981ca Author: Kalpan Jani Date: Tue Sep 8 16:07:09 2026 +0200 mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0 The in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement entry alive when removing the id 0 endpoint. This happens because the id 0 removal path does not tear down pending announcements, unlike the non-zero id path. When the PM later reselects id 0 after adding another signal endpoint, it finds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel()) in mptcp_pm_announced_alloc(). Root cause: asymmetry between removal paths. - Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls mptcp_pm_remove_announced() to clean up. - Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely. Fix by making the id 0 path symmetric: call mptcp_pm_announced_remove() and decrement add_addr_signaled before queuing the RM_ADDR. Subtle detail: signal endpoints are stored in anno_list with port 0, but msk_local carries the connection's local port. In other words, entries linked to ID0 paths should have port == 0. A follow-up patch will ensure that. mptcp_pm_announced_remove() uses use_port=true for comparison. So clear the port before the lookup. Fixes: 740d798e8767 ("mptcp: remove id 0 address") Cc: stable@vger.kernel.org Reported-by: syzbot+55c2a5c871441261ed14@syzkaller.appspotmail.com Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/620 Suggested-by: Tao Cui Signed-off-by: Kalpan Jani Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-4-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit b76c0e28b392620dfbaf92cdeedbf115820b44cb Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:08 2026 +0200 mptcp: syncookies: remember the request backup flag Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both. Fixes: efd340bf3d77 ("mptcp: distinguish rcv vs sent backup flag in requests") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-3-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit 29f641951be0d91036d77edf677807f1447dbe65 Author: Matthieu Baerts (NGI0) Date: Tue Sep 8 16:07:07 2026 +0200 mptcp: subflow: no need to copy thmac during ulp_clone 'thmac' is not used after that point. Indeed, subflow_ulp_clone() is called when the request on the passive side is over, so when the truncated HMAC is no longer needed. Note that in case of SYN cookies, thmac will not be initialised. So better to remove it to avoid a warning from debug tools like KMSAN for reading uninitialised data. Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-2-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit e2ab913f68c7d11e2561b8a8ad0b87ffefcad667 Author: Paolo Abeni Date: Tue Sep 8 16:07:06 2026 +0200 mptcp: do not reschedule the RTX timer for fallback sockets On fallback socket the retrans timer is a quite convoluted no-op, but currently nothing prevents the MPTCP core to keep rescheduling it. Additionally gate RTX timer reset to the msk not being fallen back to TCP yet. To avoid adding multiple tests in fast-path, use a new flags bit for such condition. The RTX enable bit is clear at close time and set before the msk could start retransmitting, with a couple of caveats: - passive sockets inherit the bit from the listener msk; set the bit on such socket to avoid flipping it in the fast-path, even if the listener will obviously never retransmit. - while fastopening (MPTFO), mptcp_sendmsg_fastopen still ends-up calling mptcp_connect via tcp_sendmsg_fastopen -> __inet_stream_connect(ssk->sk_socket), and the first subflow's sk_socket points to the msk one. Fixes: b51f9b80c032 ("mptcp: introduce MPTCP retransmission timer") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-1-df1de70348b6@kernel.org Signed-off-by: Jakub Kicinski commit 5be081b83abd3f17d908953b4bb77279f5a149e3 Author: Weiming Shi Date: Wed Sep 9 00:50:47 2026 +0800 net: dsa: tag_brcm: legacy FCS: request needed tailroom The legacy FCS tagger calculates the CRC over skb->len bytes starting at skb->data. When a nonlinear skb reaches the tagger, this reads past the linear head into unrelated slab memory. The tagger appends an Ethernet FCS but does not declare that tailroom. As a result, DSA leaves NETIF_F_SG and NETIF_F_FRAGLIST enabled on the user port, and nonlinear skbs can reach the CRC calculation. Declare the required tailroom. DSA will then clear those features and the networking core will linearize skbs before the tagger runs. A KASAN-enabled dsa_loop test using this tagger reports: BUG: KASAN: slab-out-of-bounds in crc32_le Read of size 1 at addr ffff8880397086c0 by task exp/135 Call Trace: crc32_le (lib/crc/crc32-main.c:38) brcm_leg_fcs_tag_xmit (net/dsa/tag_brcm.c:343) dsa_user_xmit (net/dsa/user.c:942) dev_hard_start_xmit (net/core/dev.c:3937) __dev_queue_xmit (net/core/dev.c:4926) packet_sendmsg (net/packet/af_packet.c:3110) __sys_sendto (net/socket.c:2281) The buggy address belongs to the object at ffff888039708400 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 0 bytes to the right of allocated 704-byte region [ffff888039708400, ffff8880397086c0) Fixes: ef07df397a62 ("net: dsa: tag_brcm: add support for legacy FCS tags") Cc: stable@vger.kernel.org Reported-by: co+28eef7d8af9428e6@bugs.sh Closes: https://lore.kernel.org/all/jH6u350kaBRuqklDjd3k3BW4nWzp0tYRjq3p%40bugs.sh/ Signed-off-by: Weiming Shi Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260908165047.2786340-1-bestswngs@gmail.com Signed-off-by: Jakub Kicinski commit bbee0759d363d1297d08b285acfec999570158a6 Merge: a401a9d547c50e c93922dd316b72 Author: Jakub Kicinski Date: Wed Sep 9 12:51:52 2026 -0700 Merge tag 'for-net-2026-09-08' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: Core: - hci_sysfs: Fix NULL pointer dereference in device_del() - hci_sync: Fix not setting CE length properly - btqcomsmd: destroy RPMsg endpoints before freeing hci_dev Drivers: - btmtk: Declare MT7920 (MT7961 1a) Bluetooth firmware - btusb: mediatek: Fix leaked runtime PM reference in reset - btusb: Fix leaked runtime PM reference in btusb_reset - btusb: Fix UAF of btusb_data by rx_work - btusb: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform - btintel_pcie: validate packet_len before skb_put_data - btintel_pcie: fix tx_handle bounds off-by-one - btrtl: Don't leak return code when parsing firmware format v2 * tag 'for-net-2026-09-08' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: btusb: Fix leaked runtime PM reference in btusb_reset Bluetooth: btusb: mediatek: Fix leaked runtime PM reference in reset Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev Bluetooth: hci_sysfs: Fix NULL pointer dereference in device_del() Bluetooth: btmtk: Declare MT7920 (MT7961 1a) Bluetooth firmware Bluetooth: hci_sync: Fix not setting CE length properly Bluetooth: btintel_pcie: fix tx_handle bounds off-by-one Bluetooth: btintel_pcie: validate packet_len before skb_put_data Bluetooth: btrtl: Don't leak return code when parsing firmware format v2 Bluetooth: btusb: Fix UAF of btusb_data by rx_work Bluetooth: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform ==================== Link: https://patch.msgid.link/20260908212127.1022197-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski commit e4a62833adff6ef0fe7c0b90393204fe3c26b5c5 Author: Weiming Shi Date: Wed Sep 9 12:08:08 2026 +0800 bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL An LWT_SEG6LOCAL program can invalidate its cached SRH with bpf_lwt_seg6_adjust_srh() and then call bpf_skb_pull_data(). The latter may reallocate skb->head, leaving the per-CPU SRH pointer dangling. Post-program SRH validation then writes through that pointer. Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL programs so the verifier rejects this unsafe helper combination. Other LWT program types continue to expose the helper through lwt_out_func_proto(). Fixes: 004d4b274e2a ("ipv6: sr: Add seg6local action End.BPF") Reported-by: co+adfca3e91be95776@bugs.sh Suggested-by: Alexei Starovoitov Signed-off-by: Weiming Shi Signed-off-by: Daniel Borkmann Reviewed-by: Emil Tsalapatis Closes: https://lore.kernel.org/all/GCy0KRM2IcQGoJQTjJEU9D0maBxXzEDHuQpq@bugs.sh/ Link: https://lore.kernel.org/bpf/DL9COXZQXX4V.1FN45QO2Q77ZH@gmail.com/ Link: https://lore.kernel.org/bpf/20260909040807.3885815-2-bestswngs@gmail.com commit 50d05c7c76c96b90462f24debacca971d2e86713 Merge: 5e1287972b649a d41d0021a6ea3e Author: Linus Torvalds Date: Wed Sep 9 11:00:35 2026 -0700 Merge tag 'landlock-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux Pull Landlock fixes from Mickaël Salaün: "This fixes a use-after-free and a lockdep assert NULL dereferencing, and properly truncates too-long strings printed by a Landlock tracepoint. Most of the changes are brought by new tests" * tag 'landlock-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux: landlock: Test trace path output boundaries landlock: Bound escaped trace path output landlock: Clean up ruleset validation checks selftests/landlock: Test abstract socket trace name limits landlock: Fix use-after-free of the source's parent directory commit 6e33dc90df108c76899dc544a42d17adcba61668 Author: Mike Rapoport (Microsoft) Date: Mon Aug 31 13:21:43 2026 +0300 MAINTAINERS: update memblock tree URLs memblock tree moved into mm/ namespace at git.kernel.org. Update the T: entries for memblock to match it. Link: https://patch.msgid.link/20260831102143.69265-1-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) commit e2d5b01f878d76bd1142e512a0b979a1d3cd0abf Author: Meijing Zhao Date: Wed Sep 2 15:59:44 2026 +0800 mm: memblock: show all region flags in debugfs Commit 493f349e38d0 ("memblock: Add flags and nid info in memblock debugfs") made memblock_debug_show() stop after finding the first set flag. A memblock region can carry multiple flags, so the remaining flags are hidden from debugfs. Walk all bits in the region flags and print every set flag separated by "|". Keep walking beyond flagname[] so that a set flag without a known name is reported as UNKNOWN rather than silently ignored. Fixes: 493f349e38d0 ("memblock: Add flags and nid info in memblock debugfs") Signed-off-by: Meijing Zhao Link: https://patch.msgid.link/20260902075944.3742866-1-zhaomeijing100@gmail.com Signed-off-by: Mike Rapoport (Microsoft) commit e06cb12e1ebf1a3bb3473e1b96991d71d4ba4489 Merge: df2908090cda36 1f6de65e331451 Author: Rafael J. Wysocki Date: Wed Sep 9 19:03:00 2026 +0200 Merge tag 'opp-updates-7.3.rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Merge OPP updates for 7.3-rc3 from Viresh Kumar: "- Fix potential multiplication overflow when calculating freq in OPP core (Colin Ian King). - Fix use after free in _update_opp_table_clk() (Peter Griffin). - Use %pe to print symbolic error name (Sumeet Pawnikar)." * tag 'opp-updates-7.3.rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: opp: fix use after free in _update_opp_table_clk() opp: Use %pe to print symbolic error name OPP: of: Fix potential multiplication overflow when calculating freq commit 3fc9f0558c95152b14d31badd5b27e5978bfb204 Author: Rob Clark Date: Wed Sep 9 07:41:54 2026 -0700 drm/ci: Update xfails for kms_cursor_legacy regression These four started failing with some change not merged thru the msm tree. Update xfails to reflect reality. Signed-off-by: Rob Clark commit 5e1287972b649aab54a894addeaf1fdd6bc23e6b Merge: 4f3989d75d3341 56ea4e86832d8a Author: Linus Torvalds Date: Wed Sep 9 09:38:03 2026 -0700 Merge tag 'vfs-7.3-rc3.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: - netfs: - Fix an uninitialized return value in netfs_unbuffered_write() when preparing the first subrequest fails - For partial unbuffered/DIO writes return the amount transferred rather than an error - Update i_size with the amount actually written when a partial transfer ends in an error - Fix a subrequest reference leak when the io_iter ends up empty - Handle netfs_alloc_subrequest() failure during unbuffered writes - Load all readahead folios into the rolling buffer upfront and drop the readahead references once the first subrequest is dispatched - Mark folios for copy-to-cache while issuing subrequests - Fix read progress reporting - afs: - Add the missing kunmap in the error path of afs_dir_search_bucket() - Fix a double kunmap in afs_edit_dir_remove() - Don't free an existing server's endpoint state when cleaning up a candidate server in afs_lookup_server() - Unbind peers removed from a server's address list - ufs: - Load the cylinder group metadata before creating the root dentry - Validate the cylinder group index and rotor positions before caching them - Treat an unreadable directory block as not empty - exec: - Close the close-on-exec files before taking exec_update_lock Closing a file can block on the filesystem, so a hung filesystem blocked everything that takes exec_update_lock and a FUSE server inspecting the calling process could deadlock - Drop the bprm loader before closing bprm->file in free_bprm() - exit: Hold a reference to thread_pid across proc_flush_pid() - reboot: Fix a use-after-free on cad_pid - nsfs: Keep the namespace tree fields out of the rcu_head used by kfree_rcu() - nstree: Check listing permission before taking a namespace reference in listns() - super: Return 0 when a nested thaw drops its hold while other freezers remain - ext4: Don't set I_METADATA_WRITEBACK during fastcommit replay - adfs: Free s_fs_info in ->kill_sb() - autofs: Free the inode info allocated in autofs_fill_super() when the root inode allocation fails - ovl: Return EINVAL instead of EIO on a user namespace mismatch now that it's a plain refusal and not an internal error - cachefiles: Don't cast the variable-length coherency data to a __be64 in the coherency tracepoint * tag 'vfs-7.3-rc3.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (28 commits) nstree: check listing permission before taking a namespace reference exec: do_close_on_exec() before taking exec_update_lock exit: hold a reference to thread_pid across proc_flush_pid fs: autofs: fix memory leak in autofs_fill_super() exec: Drop bprm loader before closing bprm->file afs: Clear stale peer app data after address list changes afs: Fix incorrect free in candidate cleanup in afs_lookup_server() afs: Fix double-unmap of directory block afs: Fix missing kunmap in afs_dir_search_bucket() ovl: return EINVAL instead of EIO in case of mismatched user_ns reboot: fix cad_pid use-after-free race cachefiles: Fix potential UAF/KASAN warning netfs: Fix read progress reporting netfs: Mark folios with COPY_TO_CACHE whilst issuing subreqs netfs: Fix readahead synchronisation issues by loading all folios upfront netfs: break unbuffered write when netfs_alloc_subrequest() fails netfs: Fix subreq ref leak netfs: Fix i_size update for partial transfer netfs: Fix error vs transferred passed to ->ki_complete() netfs: Fix unbuffered/DIO write partial transfer error return ... commit 47ccc3f1c615a46c25cbf7f3ae60df30b40eb2e6 Author: Caleb Sander Mateos Date: Wed Sep 2 15:01:59 2026 -0600 io_uring/rw: keep CQE flags on iopoll requests when adding kbuf flags io_do_iopoll() assigns the result of io_put_kbuf() to the request's CQE flags upon completion. This overwrites any CQE flags that may have been set by the opcode-specific layer. (For example, if __io_uring_cmd_done() had set IORING_CQE_F_32, it would be cleared.) Switch the = to an |= so the kbuf flags are added to the existing CQE flags rather than replacing them. io_req_rw_complete() does the same with the io_put_kbuf() result. Fixes: e26dca67fde1 ("io_uring: add support for IORING_SETUP_CQE_MIXED") Reported-by: sashiko-bot@kernel.org Link: https://sashiko.dev/#/message/20260827191705.D53C91F000E9%40smtp.kernel.org Signed-off-by: Caleb Sander Mateos Reviewed-by: Anuj Gupta Link: https://patch.msgid.link/20260902210200.2336720-1-csander@purestorage.com Signed-off-by: Jens Axboe commit 6028b543884f8735e057ec9eea4908cd61cab230 Author: Gabriel Krisman Bertazi Date: Wed Sep 2 20:00:41 2026 -0300 io_uring/net: don't overconsume buffers when using MSG_TRUNC When a recv/recvmsg is issued with MSG_TRUNC and the incoming packet is larger than the provided buffer, the net layer returns the full length of the packet rather than the number of bytes actually copied into the buffer. As a result, io_uring advances more of the provided buffer ring than was actually filled. Use the actual filled region size to consume the buffer, but still return the full size to preserve MSG_TRUNC semantics. Take care with multishot, because that seems to already truncate the consumption based on the available payload size. This was reported in https://github.com/axboe/liburing/issues/1619. Fixes: ae98dbf43d75 ("io_uring/kbuf: add support for incremental buffer consumption") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260728191454.1850326-1-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi Link: https://patch.msgid.link/20260902230041.1320658-3-krisman@suse.de [axboe: fold in size_t unsigned fix] Signed-off-by: Jens Axboe commit 4f3989d75d33414389a57e78f4979931a0164df4 Merge: 3f8b8c94a723ab 48a4ee65e67755 Author: Linus Torvalds Date: Wed Sep 9 08:50:05 2026 -0700 Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost Pull virtio fixes from Michael Tsirkin: "Just a ton of small fixes all over the place. Also includes virtio and virtio-rng MAINTAINERS updates" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (27 commits) vduse: return compat ioctl results directly virtio_input: stop callbacks before unregistering input device virtio_input: reset device if input_register_device() fails vhost: invalidate vring access on IOTLB transitions vduse: validate virtqueue alignment vduse: do not take dev->rwsem in the virtqueue kick path vhost-scsi: clamp max_io_vqs module parameter vhost-scsi: use kvzalloc for vq array allocation virtio-pci: return IRQ_HANDLED after non-zero ISR virtio: add Eugenio Pérez as Maintainer vhost: limit outstanding IOTLB misses per virtqueue MAINTAINERS: Add a section for virtio-rng vdpa_sim_net: check TX pull result before RX copy vdpa_sim_blk: reject out-of-range sector starts virtio-vdpa: Use queue id when setting vq affinity vdpa: octeon_ep: Check dev_set_name() in dev add vdpa: ifcvf: Put device on unsupported feature error vdpa: solidrun: Free IRQs after request failure vdpa: alibaba: Keep DRIVER_OK clear if IRQ setup fails vdpa/pds: check virtqueue notify mapping ... commit f5fcf7e638b904397ec0f66d3ea6766ef0cfe25b Author: Thomas Hellström Date: Thu Sep 3 13:45:52 2026 +0200 drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to flush the L2/HDC data cache before fence signalling, but it never requests a flush of the LSC untyped L1 data cache via the 'Untyped Data-Port Cache Flush Enable' bit in PIPE_CONTROL DWord0[11]. Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to also flush/invalidate the untyped L1 cache, but only depending on how HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling between HDC Pipeline Flush and the untyped L1 cache flush no longer holds in practice, regardless of how HDC_CHICKEN0 is programmed, so relying on it is not safe on newer platforms such as BMG. Mesa's Vulkan driver (anv) has been assuming the kernel flushes both caches between submissions, and hit user-visible corruption in apps such as Llama.cpp because of this gap; it now works around it by flushing both caches again from userspace at the end of every command buffer. Correctness between submissions on the same queue is userspace's responsibility and belongs in Mesa, not the kernel. However, for security we must ensure stale data can't leak through the untyped L1 dataport cache once memory is reclaimed or evicted, which requires the KMD to flush it before releasing memory for reuse. Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline Flush coupled to the untyped L1 cache flush, so those platforms are unaffected. Mesa's own anv driver found that on MTL the HW disconnected the two independently of how HDC_CHICKEN0 is programmed, and could not bring the old behavior back even by writing the register by hand; see Mesa commit 7c2ff46a4fc3 ("anv: don't prevent L1 untyped cache flush in 3D mode"). The kernel can't reliably request the flush from the CS on MTL either, so restrict the new PIPE_CONTROL bit to GRAPHICS_VERx100 >= 2000 (Xe2 and later), where it can be relied on. Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on Xe2 and later, so the L1 data cache is known clean before memory is released for reuse, without depending on undocumented platform-specific HDC_CHICKEN0 behavior. Bspec: 56551 Link: https://gitlab.freedesktop.org/mesa/mesa/-/commit/7c2ff46a4fc3e537573ac9503057e0cd29b6fff3 Fixes: 9f8f93bee3ef ("drm/xe: Emit a render cache flush after each rcs/ccs batch") Reported-by: Lionel Landwerlin Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/8909 Cc: José Roberto de Souza Cc: intel-xe@lists.freedesktop.org Cc: # v6.8+ Assisted-by: GitHub_Copilot:claude-sonnet-5 Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20260903114552.48634-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 434514b6fe731e873808297c268fc52cdf4a1ce6) Signed-off-by: Rodrigo Vivi commit 20fce5b34b21a995839743b4917a1edd2fd503ba Author: Varun Gupta Date: Mon Sep 7 10:30:12 2026 +0530 drm/xe: Guard page-fault worker with runtime PM check During VM teardown, the VM's runtime PM reference is dropped asynchronously, allowing the device to autosuspend while stale page faults belonging to the now-dead VM are still queued. When the page-fault worker later tries to ack one of these, it calls into guc_ct_send_locked() on an already-suspended device, tripping:   Assertion `!xe_pm_runtime_suspended(xe)` failed!   WARNING at xe_device.c:1267 xe_device_assert_mem_access+0x11c/0x140 [xe] A live VM/exec queue always holds a PM reference while it has outstanding work, so if the device is suspended at ack time, the owning context is already gone and the fault is stale. Take a runtime PM reference across the entire pagefault queue worker to safely deliver acks for torn-down VMs. v3: - Move PM ref to the generic xe_pagefault_queue_work using guard(xe_pm_runtime)(xe) instead of tracking it in the GuC backend(Matt Brost). v2: - Hold PM ref across the entire batch (begin/end) instead of per-ack. This prevents the device from autosuspending mid-batch, which would leave write_only acks written but the end flush skipped, and skip counter++, desyncing the cadence check.(Himal) - Add a comment explaining stale faults.(Himal) Fixes: f289f7807119 ("drm/xe: Add xe_guc_pagefault layer") Signed-off-by: Varun Gupta Reviewed-by: Matthew Brost Reviewed-by: Tejas Upadhyay Link: https://patch.msgid.link/20260907050011.497181-2-varun.gupta@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit fcc2431d2213dc4d04250c4f1ae87d9c3ae0d455) Signed-off-by: Rodrigo Vivi [Rodrigo: Added xe_device struct for compatibility while cherry-picking] commit 4600b4d1a9ee730d03ddac5ce409cd2730ce8c0c Author: Esben Haabendal Date: Mon Aug 31 14:21:32 2026 +0200 drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work() The error handling of sn65dsi83_reset_pipe() in sn65dsi83_reset_work() has seen a couple of changes that seems to cause a bit of confusion. While sn65dsi83_reset_work() has implemented an early exit if sn65dsi83_reset_pipe() fails since it was added, when a commit from Maxime Ripard switched to use drm_bridge_helper_reset_crtc() [1] the sn65dsi83_reset_pipe() function would no longer return an error code, so the early exit was then a no-op, and even on sn65dsi83_reset_pipe() failure, enable_irq() has been called. When drm_bridge_enter()/drm_bridge_exit() resource protection was added, the drm_bridge_exit() incidentally was always called, which is the correct approach. But only because the early exit in sn65dsi83_reset_pipe() was never hit because sn65dsi83_reset_pipe() always returns 0. In order get back to a situation where enable_irq() is not called on sn65dsi83_reset_pipe() failure, which should help protect against irq storms, we need to reintroduce a non-zero return value from sn65dsi83_reset_pipe() on error, and fix sn65dsi83_reset_work() so that we always exit the DRM bridge critical section with drm_bridge_exit(). [1] commit e17fadff7ab9 ("drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc") [2] commit d2e8d1bc840b ("drm/bridge: ti-sn65dsi83: protect device resources on unplug") Fixes: e17fadff7ab9 ("drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc") Cc: stable@vger.kernel.org Signed-off-by: Esben Haabendal Reviewed-by: Herve Codina Reviewed-by: Luca Ceresoli Tested-by: Luca Ceresoli Link: https://patch.msgid.link/20260831-ti-sn65dsi83-fixes-v5-1-e712765d6c4f@geanix.com Signed-off-by: Luca Ceresoli commit d05045177a855386bca5e1909e08d06290e6e3b3 Author: Bjoern Doebel Date: Tue Sep 8 16:10:01 2026 +0000 smb: client: fail DACL rewrite when the new DACL exceeds 64K replace_sids_and_copy_aces() and set_chmod_dacl() accumulate the size of the DACL they build in a u16. That accumulator can wrap. validate_dacl() caps num_aces at (dacl_size - sizeof(struct smb_acl)) / 20, i.e. 3276 for a maximally sized DACL, while each rewritten ACE can grow to sizeof(struct smb_ace) (76 bytes) once its SID is replaced with one carrying SID_MAX_SUB_AUTHORITIES sub-authorities. The worst case is therefore sizeof(struct smb_acl) + 3276 * 76 = 248984 bytes, far beyond what a u16 can hold. A wraparound is reached with 863 ACEs. After the wraparound, ndacl_ptr->size becomes meaningless and the offset will point anywhere in the ACE array. As a result, we will see corruption of the DACL, which then gets sent to the server. This is not an out-of-bounds write as the allocation now covers the worst-case expansion, so writes will always go into the buffer. Adjust the code to use a u32 internally and return -EOVERFLOW in the overflow case. The operation must be refused, because a DACL can only hold 2^16-1 bytes on the wire and larger DACLs cannot be represented. set_chmod_dacl() carries the same pattern and is fixed the same way. It only wraps once the source DACL comes within roughly 380 bytes of the 64K ceiling, but the failure mode is identical. Suggested-by: Namjae Jeon Cc: stable@vger.kernel.org Fixes: f5065508897a ("cifs: Retain old ACEs when converting between mode bits and ACL.") Assisted-by: Kiro:claude-opus-5 Signed-off-by: Bjoern Doebel Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 0ee150794c75bcd0be0e24ff3394f433cbae18cc Author: Bjoern Doebel Date: Tue Sep 8 16:10:00 2026 +0000 smb: client: fix heap overflow in DACL owner/group rewrite When id_mode_to_cifs_acl rewrites an existing DACL, it allocates a buffer sized according to the on-disk DACL length reported by dacl_ptr->size. However, replace_sids_and_copy_aces may rewrite each ACE with a new owner/group SID obtained from the cifs.idmap upcall. Those SIDs can have up to SID_MAX_SUB_AUTHORITIES (15) sub-authorities, making each ACE up to 76 bytes (sizeof(struct smb_ace)). If the original DACL contains short SIDs (e.g., 1 sub-authority) while the replacement SIDs are long, the rewritten ACEs overflow the allocation. Fix this by always budgeting for worst-case SID expansion: allocate sizeof(struct smb_acl) plus num_aces * sizeof(struct smb_ace), which covers the smb_acl header and room for every ACE at maximum SID size. This replaces the previous split logic that used dacl_ptr->size for cifsacl mounts but num_aces * sizeof(struct smb_ace) for mode_from_sid mounts: both paths can trigger the same rewrite and need the same headroom. KASAN reports this as: BUG: KASAN: slab-out-of-bounds in build_sec_desc+0x1e8a/0x2680 [cifs] Write of size 4 at addr ffff8881a5e25374 by task chown/5298 ... The buggy address is located 0 bytes to the right of allocated 884-byte region [ffff8881a5e25000, ffff8881a5e25374) Cc: stable@vger.kernel.org Fixes: bc3e9dd9d104 ("cifs: Change SIDs in ACEs while transferring file ownership.") Assisted-by: Kiro:claude-opus-4.6 Signed-off-by: Bjoern Doebel Reviewed-by: Namjae Jeon Fixes: 5c3564852c58 ("cifs: Minimize the number of cifs_acl memory allocations") Signed-off-by: Paulo Alcantara commit 3f8b8c94a723ab6c0a62005e69a0872717f01709 Merge: 893e11787f78e4 a76f015d424e19 Author: Linus Torvalds Date: Wed Sep 9 07:06:18 2026 -0700 Merge tag 'printk-for-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux Pull printk fixes from Petr Mladek: - Use lazy irq_work for waking printk kthreads - Flush pending irq_work before destroying printk kthreads - Remove redundant WARN() when a printk kthread can't be created - Typo fix * tag 'printk-for-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux: printk/nbcon: Change nbcon_irq_work to IRQ_WORK_LAZY printk/nbcon: Flush nbcon_irq_work in nbcon_free() console: fix /dev/kmsg reference in flags kernel doc printk: Don't WARN on kthread_run failure. commit d144a494d81fcf2d1c5cf58b01c655bb8bafc701 Author: Gabriel Windlin Date: Tue Sep 8 22:34:11 2026 +0200 MAINTAINERS: fix sysfs-platform-ayaneo-ec documentation path The documentation file for the AYANEO platform EC driver was added as Documentation/ABI/testing/sysfs-platform-ayaneo-ec, but MAINTAINERS references it without the '-ec' suffix, causing 'make refcheckdocs' to report a broken reference. Update the file entry to point to the correct file name. Signed-off-by: Gabriel Windlin Link: https://patch.msgid.link/20260908203412.608606-1-gawindlin@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 6bb147bc470f36d9edd8f564dc952bb78c65fdbc Merge: 7284788743121e 7e125889f1705f Author: Takashi Iwai Date: Wed Sep 9 15:09:55 2026 +0200 Merge tag 'asoc-fix-v7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v7.3 An unusually large batch of fixes here, partly due to me not sending a pull request last week and partly due to Linus' fixes for the Ericsson systems. I'm fairly sure he's the only user there so it seemed low risk to handle as fixes. We also have a batch of error handling fixes from Cezary and issues with uninitialised stream_config->type from Shuming both of which had user error reports attached. Otherwise everything is a fairly normal combination of quirks and device specific fixes. commit 9bc184a2eda8b773c88ecbff934001ad649b9cc1 Author: Yuxiao Wang Date: Wed Sep 9 12:44:00 2026 +0000 nitro_enclaves: fix use-after-free on SLOT_ALLOC failure When ne_create_vm_ioctl() fails the SLOT_ALLOC request after anon_inode_getfile() has succeeded, the error path calls fput(enclave_file) and then frees ne_enclave. In normal userspace context, fput() defers the final __fput() via task_work. ne_enclave_release() therefore runs after ne_enclave has already been freed and dereferences ne_enclave->slot_uid, causing a use-after-free: KASAN: slab-use-after-free in ne_enclave_release. The enclave has no slot allocated and is not yet linked into the enclaves list on this error path, so ne_enclave_release() is expected to return early when slot_uid is zero. However, reading slot_uid already accesses the freed object. Clear enclave_file->private_data before fput() on the error path. ne_enclave_release() then returns immediately when private_data is NULL, leaving the ioctl error path as the sole owner of ne_enclave. This is safe because the file has not been fd_install()'d yet. Tested on an AWS EC2 m5.2xlarge with CONFIG_KASAN=y. Without the patch, the reproducer triggers a KASAN slab-use-after-free on every SLOT_ALLOC failure. With the patch, no KASAN report is produced and the SLOT_ALLOC error is still returned. Normal enclave creation and teardown are unaffected. Fixes: 9c8eb50fe9e2 ("nitro_enclaves: Add logic for terminating an enclave") Cc: stable@vger.kernel.org Co-developed-by: Zhaofeng Chen Signed-off-by: Zhaofeng Chen Signed-off-by: Yuxiao Wang Reviewed-by: Alexander Graf Link: https://patch.msgid.link/20260909124400.27857-1-graf@amazon.com Signed-off-by: Greg Kroah-Hartman commit 50d3d79dc0743b616afb00d01a626c76758721f7 Author: Johannes Berg Date: Tue Sep 8 14:28:21 2026 +0200 wifi: mac80211: set up the TX info early to fix failure paths The previous commit 2c51457d930f ("wifi: mac80211: free ack status frame on TX header build failure") cleaned up the leak, but still left the code a bit messy and the failed SKB didn't get reported to userspace. Fix this up by initialising skb->cb[] earlier, which allows using ieee80211_free_txskb() and therefore reports it for the failure in ieee80211_build_hdr(), and unifies the ieee80211_skb_resize() failure path with it. Assisted-by: LLM Fixes: c3e7724b6bc2 ("mac80211: use ieee80211_free_txskb to fix possible skb leaks") Link: https://patch.msgid.link/20260908122838.201719-22-johannes@sipsolutions.net Signed-off-by: Johannes Berg commit ae97fff6495a8764bc0ef281cfe5444f701e527f Author: Johannes Berg Date: Tue Sep 8 14:28:20 2026 +0200 wifi: mac80211: mesh: release the channel if start fails ieee80211_join_mesh() acquires a channel context and then calls ieee80211_start_mesh(), which can fail. In that case, the chanctx isn't released then interface removal will attempt to unassign it after it's removed from the driver, hitting: wlan0: Failed check-sdata-in-driver check, flags: 0x0 WARNING: net/mac80211/driver-ops.c:366 at drv_unassign_vif_chanctx ieee80211_assign_link_chanctx __ieee80211_link_release_channel ieee80211_link_release_channel ieee80211_teardown_sdata unregister_netdevice_many_notify _cfg80211_unregister_wdev ieee80211_remove_interfaces ieee80211_unregister_hw mac80211_hwsim_del_radio hwsim_exit_net Correctly release the channel on start failures. Assisted-by: LLM Reported-by: syzbot+63a84ea9c0f57d6133fa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=63a84ea9c0f57d6133fa Fixes: 2b5e19677592 ("mac80211: cache mesh beacon") Link: https://patch.msgid.link/20260908122838.201719-21-johannes@sipsolutions.net Signed-off-by: Johannes Berg commit 860134b3af77970e006feab7e5decb8c84771c7f Author: Johannes Berg Date: Tue Sep 8 14:28:19 2026 +0200 wifi: mac80211: mesh: reset the CSA state when leaving ifmsh->csa is allocated in ieee80211_mesh_csa_beacon() and only freed in ieee80211_mesh_finish_csa(), i.e. when the channel switch completes. Leaving the mesh while a switch is still pending therefore leaks it. Additionally, ifmsh->csa_role and ifmsh->chsw_ttl have their state leak in this case, so things can get mixed up in addition to the memory leak. Refactor the reset and call it in ieee80211_stop_mesh() to fix it all. Assisted-by: LLM Reported-by: syzbot+f5752cd6b94fe38be666@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f5752cd6b94fe38be666 Fixes: b8456a14e9d2 ("{nl,cfg,mac}80211: implement mesh channel switch userspace API") Link: https://patch.msgid.link/20260908122838.201719-20-johannes@sipsolutions.net Signed-off-by: Johannes Berg commit cd54bf333f5631d3630bab0a832e9ae648f73515 Author: Johannes Berg Date: Tue Sep 8 14:28:18 2026 +0200 wifi: mac80211: add HE 6 GHz capability in the scan elems len The HE 6 GHz Band Capability element is in the probe request for every band if 6 GHz is supported, so add the size to scan_ies_len. Otherwise, building probe request elements can fail, triggering the WARN_ON in __ieee80211_start_scan(). Assisted-by: LLM Fixes: 2ad2274c58ee ("mac80211: Add HE 6GHz capabilities element to probe request") Reported-by: syzbot+f961b9f94edbc266f1f8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f961b9f94edbc266f1f8 Link: https://patch.msgid.link/20260908122838.201719-19-johannes@sipsolutions.net Signed-off-by: Johannes Berg commit 0b1de9feeb8651f7a3bb53ed7c9006e3b5298c01 Author: Johannes Berg Date: Tue Sep 8 14:28:17 2026 +0200 wifi: mac80211: don't access the TSF of a down interface The tsf debugfs files call the driver even if the interface isn't up, tgriggering check-sdata-in-driver warnings. Reject the access in that case. Assisted-by: LLM Fixes: 37a41b4affa3 ("mac80211: add ieee80211_vif param to tsf functions") Reported-by: syzbot+1c8c45017f784e646b47@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1c8c45017f784e646b47 Link: https://patch.msgid.link/20260908122838.201719-18-johannes@sipsolutions.net Signed-off-by: Johannes Berg commit b481e64e4498e2c053d5954f546ee02338f6ab63 Author: Johannes Berg Date: Tue Sep 8 14:28:16 2026 +0200 wifi: mac80211: don't RCU-dereference the mesh CSA settings we just set In the error path of ieee80211_mesh_csa_beacon() the settings that were just assigned are read back with rcu_dereference(), which lockdep then complains about. There's no need to read the pointer at all, tmp_csa_settings still is the right value anyway. Assisted-by: LLM Fixes: b8456a14e9d2 ("{nl,cfg,mac}80211: implement mesh channel switch userspace API") Reported-by: syzbot+b59873f5699e941717ca@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b59873f5699e941717ca Link: https://patch.msgid.link/20260908122838.201719-17-johannes@sipsolutions.net Signed-off-by: Johannes Berg commit 370872d30349d81dec519e15ea2949fd63511cf7 Author: Johannes Berg Date: Tue Sep 8 14:28:15 2026 +0200 wifi: mac80211: don't allow link changes when iface is down ieee80211_set_active_links() only checks that the interface is running in the inner __ieee80211_set_active_links(), after drv_can_activate_links() was already called, so using active_links on an interface that's down triggers the check-sdata-in-driver warning. Add the missing check in the debugfs file. Assisted-by: LLM Fixes: 3d9011029227 ("wifi: mac80211: implement link switching") Reported-by: syzbot+582469b3a9ef5f13606b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=582469b3a9ef5f13606b Link: https://patch.msgid.link/20260908122838.201719-16-johannes@sipsolutions.net Signed-off-by: Johannes Berg commit 038e1d126304fd25d507fd4e671232df57bd1799 Author: Johannes Berg Date: Tue Sep 8 14:28:14 2026 +0200 wifi: mac80211: require a peer station for TDLS setup confirm It's nonsense for the setup confirm to go to station that doesn't even exist, and it hits a warning when building the frame: WARN_ON_ONCE(!sta || !ap_sta) Only accept WLAN_TDLS_SETUP_CONFIRM when the station is already there as a TDLS station. Need to copy the call to ieee80211_tdls_prep_mgmt_packet() since the existing WLAN_TDLS_DISCOVERY_REQUEST already falls through to it. Assisted-by: LLM Fixes: 6f7eaa47e1de ("mac80211: add TDLS QoS param IE on setup-confirm") Reported-by: syzbot+e55106f8389651870be0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e55106f8389651870be0 Link: https://patch.msgid.link/20260908122838.201719-15-johannes@sipsolutions.net Signed-off-by: Johannes Berg commit 4504f3960dc4501c73be9f99eabda2e26e9db41e Author: Johannes Berg Date: Tue Sep 8 14:28:13 2026 +0200 wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown On ifup, AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from the AP interface, but it's never decremented again unless the AP is also brought down. Thus, bringing the same AP_VLAN up again will increment the counter again and eventually hit the sanity check: WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt != master->crypto_tx_tailroom_needed_cnt); Reset it on ifdown to avoid that. Assisted-by: LLM Fixes: f9dca80b98ca ("mac80211: fix AP_VLAN crypto tailroom calculation") Reported-by: syzbot+de3ee5362db09487ea37@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=de3ee5362db09487ea37 Link: https://patch.msgid.link/20260908122838.201719-14-johannes@sipsolutions.net Signed-off-by: Johannes Berg commit e14bf37bb2b3853012ff160131d1c6233f7a9cc9 Author: Johannes Berg Date: Tue Sep 8 14:28:12 2026 +0200 wifi: mac80211: don't allow injecting frames wider than the chanctx Frames injected on a monitor interface can carry a radiotap field requesting a bandwidth, which mac80211 passes down to the driver regardless of the the actual operational bandwidth. If the bandwidth requested is too wide, that triggers a warning in hwsim: WARN_ON(hwsim_get_chanwidth(bw) > hwsim_get_chanwidth(confbw)) Drop such frames entirely instead since they cannot be sent. Assisted-by: LLM Fixes: 646e76bb5daf ("mac80211: parse VHT info in injected frames") Reported-by: syzbot+435fdb053cf98bfa5778@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=435fdb053cf98bfa5778 Link: https://patch.msgid.link/20260908122838.201719-13-johannes@sipsolutions.net Signed-off-by: Johannes Berg commit c1ba7f7f18465e259cf1b4d9c73fc73853d7f790 Author: Tianchu Chen Date: Fri Sep 4 13:39:34 2026 +0000 wifi: wilc1000: fix RX buffer OOB-write in wilc_wlan_handle_isr_ext() wilc_wlan_handle_isr_ext() takes the RX transfer size from the device-reported interrupt status register (a 15-bit field shifted left by 2, up to 131068 bytes) and reads that many bytes from the device into rx_buffer, which is only WILC_RX_BUFF_SIZE (96K) large. The wrap check only handles the current offset; the size itself is never compared against the buffer, so a bogus SDIO device can make the driver OOB-write rx_buffer by up to ~32K with data it controls. The oversized transfer also leaves rx_buffer_offset past the end of the buffer, after which the unsigned wrap check stops working and the overflow can repeat. Drop any transfer whose size exceeds the RX buffer, acknowledging the data interrupt and re-arming the RX engine so the bogus frame is discarded and reception can continue. This also restores the rx_buffer_offset <= WILC_RX_BUFF_SIZE invariant the wrap check relies on. This is not expected to change driver behavior in most cases: without this check, an oversized transfer would most likely corrupt neighboring kernel memory instead of completing anyway, and the drop path performs the same interrupt acknowledgment and RX engine re-arming as the normal path, so subsequent transfers are received unaffected. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/7c971924c6bdccf6c2f75704a5a746e9303aaf64@linux.dev Signed-off-by: Johannes Berg commit e6c5ed7a98d7bc8b0f7918246f1c90ddb3f79dfa Author: Tianchu Chen Date: Fri Sep 4 14:24:45 2026 +0000 wifi: rsi: fix heap OOB write on key removal When a key is removed (data == NULL), rsi_hal_load_key() runs: memset(&set_key[FRAME_DESC_SZ], 0, frame_len - FRAME_DESC_SZ); set_key is a struct rsi_set_key *, so the subscript is scaled by sizeof(struct rsi_set_key) (160 bytes): &set_key[FRAME_DESC_SZ] is skb->data + 2560, and the memset writes 144 zero bytes starting 2.4KB past the end of the 160-byte skb data buffer, corrupting unrelated heap objects. The intended byte offset would have been (u8 *)set_key + FRAME_DESC_SZ. The write fires on every DISABLE_KEY callback, so plain disconnects, roams and interface teardowns trigger it on real networks. The memset is redundant: the whole buffer is zeroed right after allocation, so the frame sent to the device is byte-identical without it. Drop the else branch; normal operation is unaffected. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: dad0d04fa7ba ("rsi: Add RS9113 wireless driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/90bb2b07007942064c04aa3729cedd9eb1e930b1@linux.dev Signed-off-by: Johannes Berg commit 87840d4a3a21b1c19b867a80e16ba69dff284de2 Author: Johannes Berg Date: Fri Sep 4 17:01:35 2026 +0200 wifi: mac80211_hwsim: don't hand frames to mac80211 while stopping The code checks ->started for frames coming from wmediumd, but the radio can be stopped after the check and before frame delivery, causing mac80211 to hit the WARN_ON(!local->started). Expand the mutex for this case and synchronise against it when the radio is stopped to avoid being able to hit the warning with hwsim. Drop the error print that would've complicated the error path, it only triggers for allocation failures (already noisy) and malformed frames anyway. Assisted-by: LLM Fixes: 7882513bacb1 ("mac80211_hwsim driver support userspace frame tx/rx") Reported-by: syzbot+b4aa2b672b18f1d4dc5f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b4aa2b672b18f1d4dc5f Link: https://patch.msgid.link/20260904170140.5f69a10d606b.I4a7921d00643f69e439c7a3b221d104f66a3dcdc@changeid Signed-off-by: Johannes Berg commit 4635b1a1c1d693178a537446a6e09963f0fdae52 Author: Johannes Berg Date: Fri Sep 4 17:02:02 2026 +0200 wifi: cfg80211: get the wiphy out of a dying network namespace When a network namespace is destroyed, cfg80211_pernet_exit() moves any wiphy back to the initial namespace, and just warns if that fails. But moving an interface can fail (due to allocation failures), and then the wiphy is left behind with a garbage netns pointer: Kernel mode fault at addr 0x30 genlmsg_multicast_netns.constprop.0+0x46/0xcf [cfg80211] nl80211_notify_wiphy+0xcd/0xe8 [cfg80211] wiphy_unregister+0x169/0x3fc [cfg80211] Note that commit debac3a20dec ("net: Remove conflicting altnames for dying netns in __dev_change_net_namespace().") fixed another path that could reach it without allocation failures. Remove interfaces that cannot be moved instead of failing the switch, so that the wiphy always ends up in the initial namespace. In this case the netdev core will unregister the interfaces anyway. Assisted-by: LLM Reported-by: syzbot+c5f8a81e794d4a4f2014@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c5f8a81e794d4a4f2014 Fixes: 463d018323851 ("cfg80211: make aware of net namespaces") Link: https://patch.msgid.link/20260904170220.7f3edc6d9992.I5e57921011244d3d8ef14d89e738aa19a5d972a0@changeid Signed-off-by: Johannes Berg commit eee2efd82867b623982ac51925b5a1812a74c50d Author: Johannes Berg Date: Fri Sep 4 17:02:01 2026 +0200 wifi: mac80211: unlist vifs when their netdev is unregistered mac80211 only removes vifs from the local->interfaces list when an interface is removed via ieee80211_if_remove(), before it unregisters the netdev. However, it's possible for a netdev to be unregistered without going through that: When the netns that holds the wiphy is destroyed, the wiphy is supposed to move to the init_ns, but that can run into allocation failures. Then, mac80211 has an interface listed that doesn't exist, and will eventually hit BUG: failure at net/wireless/core.h:141/wiphy_to_rdev()! ... _cfg80211_unregister_wdev+0x24/0x36a [cfg80211] cfg80211_unregister_wdev+0x15/0x1d [cfg80211] ieee80211_remove_interfaces+0x1ff/0x257 [mac80211] ieee80211_unregister_hw+0x73/0x1d1 [mac80211] mac80211_hwsim_del_radio+0x114/0x166 [mac80211_hwsim] Remove the interface from the list in ->ndo_uninit if it's still around to avoid this. Assisted-by: LLM Fixes: 463d018323851 ("cfg80211: make aware of net namespaces") Link: https://patch.msgid.link/20260904170220.038ad73e6c04.I990abca78483e058746b6f42b4796717c3028164@changeid Signed-off-by: Johannes Berg commit a41bd1938a9bfe226d444172a7e20e4bd5097960 Author: Johannes Berg Date: Fri Sep 4 17:02:00 2026 +0200 wifi: cfg80211: undo netns switch if renaming the wiphy fails Once all the interfaces have been moved, cfg80211_switch_netns() moves the wiphy itself by setting its network namespace and then renaming it, which makes sysfs move it. The rename can fail (but only on allocation failures), leaving things mixed up and hitting the warning there. Ignoring it isn't great, undo the move and let the change fail in this case. If undo fails then WARN, then things would again be stuck in two different network namespaces. Assisted-by: LLM Reported-by: syzbot+3515319a302224e081b4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3515319a302224e081b4 Fixes: 463d018323851 ("cfg80211: make aware of net namespaces") Link: https://patch.msgid.link/20260904170220.7966cc705e33.Ib398351113bbd3cab85302467060cab378564421@changeid Signed-off-by: Johannes Berg commit eeee52cfd1d639774c9812e8890631404a057dd2 Author: Johannes Berg Date: Fri Sep 4 17:01:59 2026 +0200 wifi: cfg80211: restore netns_immutable on failures Switching a wiphy's netns has to clear netns_immutable before moving interfaces, but then if any of the interfaces fails to move, it gets netns_immutable cleared forever. Then userspace can move it by itself, breaking the assumption that they all move together. Fix the order here and always reset netns_immutable after attempting the move. Assisted-by: LLM Fixes: 463d018323851 ("cfg80211: make aware of net namespaces") Link: https://patch.msgid.link/20260904170220.7ea88157dcbc.Id868585a790be8b9ece9b39b0db464a5963faaf3@changeid Signed-off-by: Johannes Berg commit 6f0a100df8539ce90f37c14e1945f396ca2410bc Author: Johannes Berg Date: Fri Sep 4 16:57:14 2026 +0200 wifi: mac80211: only operate on TDLS peers in the TDLS code ieee80211_tdls_oper() can operate on the AP station, which then yields various warnings when the AP station is removed then or at a later point in time after being confused for a TDLS peer. Always check that the station is a TDLS peer. Assisted-by: LLM Fixes: dfe018bf9953 ("mac80211: handle TDLS high-level commands and frames") Fixes: 17e6a59a365a ("mac80211: cleanup TDLS state during failed setup") Reported-by: syzbot+a59b5291776979816910@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a59b5291776979816910 Link: https://patch.msgid.link/20260904165722.3bad8b79679b.I99618745e83cbe9b9804179387be15fcd3505ae3@changeid Signed-off-by: Johannes Berg commit 78183e8331958fda11cd2b6850bb424a9747c4b2 Author: Johannes Berg Date: Fri Sep 4 16:57:13 2026 +0200 wifi: mac80211: reset the LED state when ifup fails When the first interface comes up, the radio LED is turned on. This can start the TPT trigger timer, which continues running. But if bringing up the interface fails then the timer keeps running and won't be stopped by anything, eventually it can be freed: ODEBUG: free active (active state 0) object: ffff888127e12130 object type: timer_list hint: tpt_trig_timer+0x0/0x300 net/mac80211/led.c:145 WARNING: CPU: 0 PID: 5923 at lib/debugobjects.c:612 debug_print_object+0x1a2/0x2b0 debug_check_no_obj_freed+0x4b7/0x600 lib/debugobjects.c:1129 kfree+0x436/0x670 mm/slub.c:6818 ieee80211_led_exit+0x162/0x1c0 net/mac80211/led.c:210 ieee80211_unregister_hw+0x27e/0x3a0 net/mac80211/main.c:1706 rt2x00lib_remove_dev+0x55b/0x670 Undo the LED state in the error path. Assisted-by: LLM Fixes: 67408c8c7b9d ("mac80211: selective throughput LED trigger active") Reported-by: syzbot+e84ecca6d1fa09a9b3d9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e84ecca6d1fa09a9b3d9 Link: https://patch.msgid.link/20260904165722.044aa432f873.I601a67a2cd558b8ef8416a07554ae7efe896e9d8@changeid Signed-off-by: Johannes Berg commit 3f28551d0241254a75626d868041c6340285088b Author: Johannes Berg Date: Fri Sep 4 16:57:12 2026 +0200 wifi: mac80211: reset state when starting AP fails ieee80211_start_ap() can set enable_beacon (and beacon_int) and fail later, leaving it set forever. Scanning can then attempt to restore beaconing on such an interface, leading to: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:mac80211_hwsim_link_info_changed+0xca7/0xf00 Call Trace: drv_link_info_changed+0x413/0x860 net/mac80211/driver-ops.c:495 ieee80211_link_info_change_notify+0x24b/0x3c0 net/mac80211/main.c:427 ieee80211_offchannel_return+0x381/0x580 net/mac80211/offchannel.c:160 __ieee80211_scan_completed+0x993/0xe30 net/mac80211/scan.c:519 ieee80211_scan_work+0x472/0x2010 net/mac80211/scan.c:1193 cfg80211_wiphy_work+0x2b7/0x550 net/wireless/core.c:538 in hwsim. Also, cfg80211 then allows changing the interface type, and the off-channel path getgs confused about beaconing as well, leading to another warning: WARNING: net/mac80211/driver-ops.c:468 at drv_link_info_changed+0x583/0x880 ieee80211_link_info_change_notify+0x24b/0x3c0 net/mac80211/main.c:427 ieee80211_offchannel_stop_vifs+0x328/0x5c0 net/mac80211/offchannel.c:122 ieee80211_start_sw_scan net/mac80211/scan.c:583 [inline] __ieee80211_start_scan+0xfb6/0x1af0 net/mac80211/scan.c:882 Reset the state on failures to always have it correct. Assisted-by: LLM Fixes: d6a83228823f ("mac80211: track enable_beacon explicitly") Reported-by: syzbot+ca7a2759caaa6cd4e3db@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ca7a2759caaa6cd4e3db Reported-by: syzbot+c4686c3eb8b64032618f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c4686c3eb8b64032618f Link: https://patch.msgid.link/20260904165722.9629429a5221.I7f599412bfe12a09d41ea4901be9ad165d07d133@changeid Signed-off-by: Johannes Berg commit ac7472a24bd433b81c06582835dd1d5547c10da9 Author: Johannes Berg Date: Fri Sep 4 16:57:11 2026 +0200 wifi: mac80211: abort chanswitch when leaving a mesh The code in ieee80211_stop_mesh() leaves CSA active, but leaving the mesh released the channel context, so the CSA finalize work crashes: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003 KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] RIP: 0010:ieee80211_put_srates_elem+0x42/0x640 net/mac80211/util.c:3272 Call Trace: ieee80211_mesh_build_beacon+0xa83/0x1b50 net/mac80211/mesh.c:1093 ieee80211_mesh_rebuild_beacon+0xc7/0x170 net/mac80211/mesh.c:1147 ieee80211_mesh_finish_csa+0x131/0x210 net/mac80211/mesh.c:1542 ieee80211_set_after_csa_beacon net/mac80211/cfg.c:4085 [inline] __ieee80211_csa_finalize net/mac80211/cfg.c:4133 [inline] ieee80211_csa_finalize+0x633/0x1150 net/mac80211/cfg.c:4155 cfg80211_wiphy_work+0x2ab/0x450 net/wireless/core.c:438 Abort the channel switch properly. Assisted-by: LLM Fixes: b8456a14e9d2 ("{nl,cfg,mac}80211: implement mesh channel switch userspace API") Reported-by: syzbot+81cd9dc1596563141d19@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=81cd9dc1596563141d19 Link: https://patch.msgid.link/20260904165722.d0b87eee08aa.I80550d6127e0bb26efb49a5fbe95be1aef1cd0cb@changeid Signed-off-by: Johannes Berg commit bf29d085e0eba92388518719d044f4702a8c6644 Author: Johannes Berg Date: Fri Sep 4 16:57:10 2026 +0200 wifi: mac80211: suppress chanctx warning for debugfs reset Before suspend all the channel contexts should removed, so the warning makes sense and should be there, but during reset the same code is called without first removing. Limit the check to the real suspend case. Assisted-by: LLM Fixes: 12e7f517029d ("mac80211: cleanup generic suspend/resume procedures") Reported-by: syzbot+56a1a45a9a2c04d425ff@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=56a1a45a9a2c04d425ff Link: https://patch.msgid.link/20260904165722.fe46395e310b.Ic4aaa95bd9d0ceb6a3cd7d84c425afee7d7d3dd7@changeid Signed-off-by: Johannes Berg commit 362bd5bce29ed0f6fd3d39a7065567777d70606e Author: Johannes Berg Date: Fri Sep 4 16:57:09 2026 +0200 wifi: mac80211: don't offload TC setup on AP_VLAN interfaces AP_VLAN interfaces are purely virtual, so don't try to offload TC setup to drivers. We can't really use the AP interface either since we may not know it all the time, and it could technically even change. Just reject the TC offload so things get done in software. Assisted-by: LLM Fixes: 61587f1556fe ("wifi: mac80211: add support for letting drivers register tc offload support") Reported-by: syzbot+f1ba58d6b55abd13239e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f1ba58d6b55abd13239e Link: https://patch.msgid.link/20260904165722.726cc076cecb.Iccfd88b13635425e850ce031376eb60a4ce5f4f8@changeid Signed-off-by: Johannes Berg commit a7491b7efbd9136b120a12ed72af9c12121dd134 Author: Johannes Berg Date: Fri Sep 4 16:57:08 2026 +0200 wifi: mac80211: don't warn when an IBSS has no channel to scan ieee80211_request_ibss_scan() warns when regulatory leaves no allowed channel, but that can happen as the regdomain can change while IBSS is operating, and it can continue to operate briefly during the 60s grace period until it's shut down. Just remove the warning in this case. Assisted-by: LLM Fixes: 34bcf7150241 ("mac80211: fix ibss scanning") Reported-by: syzbot+1634c5399e29d8b66789@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1634c5399e29d8b66789 Link: https://patch.msgid.link/20260904165722.fe380c27fef4.I0e8bee2e12a40d240851a4bc724d47753af46159@changeid Signed-off-by: Johannes Berg commit 733f0fde95392ed5f61a4e36aee661ea8d0e8581 Author: Johannes Berg Date: Fri Sep 4 16:57:07 2026 +0200 wifi: mac80211: don't start a ROC while scanning The ROC work can be pending when a scan starts (which requires ROC list to be empty, but that's possible), and then a new ROC can be added to the list and the work will pick it up. Avoid starting that ROC if a scan made it between things, as otherwise we'll hit a warning later: WARNING: net/mac80211/offchannel.c:404 at ieee80211_start_next_roc+0x256/0x2d0 Workqueue: events_unbound cfg80211_wiphy_work Call Trace: __ieee80211_scan_completed+0x4fd/0xe40 net/mac80211/scan.c:537 ieee80211_scan_work+0x472/0x1ff0 net/mac80211/scan.c:1193 cfg80211_wiphy_work+0x410/0x570 net/wireless/core.c:513 Assisted-by: LLM Fixes: aaa016ccd5df ("mac80211: rewrite remain-on-channel logic") Reported-by: syzbot+c3a167b5615df4ccd7fb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c3a167b5615df4ccd7fb Link: https://patch.msgid.link/20260904165722.f9d5b150edd8.I61bc9de8c8d089096ad695213b9c85c7df38c3bd@changeid Signed-off-by: Johannes Berg commit 23c68b4aaf5e18ab95532fc6714b737d5b7c701c Author: Johannes Berg Date: Fri Sep 4 16:57:06 2026 +0200 wifi: mac80211: don't drop scan probe requests for lack of peer rates While software scanning, ieee80211_tx_h_rate_ctrl() warns and drops the frame if the target station has no usable bitrate on the band that's currently being scanned. But that's really meant for data frames, not if we happen to scan for the BSSID on the wrong band, which can be constructed easily. Skip the check for IEEE80211_TX_CTRL_DONT_USE_RATE_MASK, the previous commit also ignored the station rate mask for such frames as well. Assisted-by: LLM Reported-by: syzbot+0d516b33238bd97ee864@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0d516b33238bd97ee864 Link: https://patch.msgid.link/20260904165722.b57ea4ab82d3.Id6c9c42d5cef5901bfac88853647b03ba4077b3e@changeid Signed-off-by: Johannes Berg commit f5dd0626d2b07c6f5c8c763d75d13c6307393bca Author: Johannes Berg Date: Fri Sep 4 16:57:05 2026 +0200 wifi: mac80211: don't apply peer rates to off-channel frames All the off-channel frames (including scan) aren't really part of the connection, so don't apply the station rates even if they're being sent to the station in question (e.g. by accident). They don't use the rate mask via IEEE80211_TX_CTRL_DONT_USE_RATE_MASK, but the station might not have rates of them either, hitting the warning found by syzbot. Assisted-by: LLM Reported-by: syzbot+34463a129786910405dd@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=34463a129786910405dd Link: https://patch.msgid.link/20260904165722.ade6b07421b8.I59b7ea810eb021a7a68b3090828a757b6dd85e57@changeid Signed-off-by: Johannes Berg commit f4e72e3758072d7b063e0d8b93419eb915b69c2c Author: Johannes Berg Date: Fri Sep 4 16:55:08 2026 +0200 wifi: cfg80211: reduce RTNL holding in regulatory enforcement Regulatory enforcement in reg_check_chans_work() does all work with the RTNL held, which can block the RTNL for a long time, which syzbot can hit and report hung tasks. Except for NAN, we don't need the RTNL for the enforcement, and the list iteration can be done with RCU instead. Split the enforcement off into new work structs: for NAN, we have to have the RTNL to close dependent NAN_DATA interfaces, everything else can use cfg80211_leave_locked() in a wiphy work. It'd be doable to use just a single work with RTNL, but then the RTNL would end up being used all the time, and really it only needs to be used for NAN. Assisted-by: LLM Reported-by: syzbot+adeb8550754921fece20@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=adeb8550754921fece20 Reported-by: syzbot+101224300649c3eb8af4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=101224300649c3eb8af4 Link: https://patch.msgid.link/20260904165614.f65bd4d9fa35.I82dac71371d87f39e459fce931b0e5321e4f9767@changeid Signed-off-by: Johannes Berg commit 17a5f8571d1d40c88b78cfc154a7da0d60f13f37 Author: Johannes Berg Date: Fri Sep 4 16:55:07 2026 +0200 wifi: cfg80211: fix NAN regulatory enforcement reg_wdev_chan_valid() returns early for any wdev that has no netdev, which is fine for P2P originally (and later PD still), but NAN has no netdev and yet enforcement code was added and is needed, but is dead code right now. Use wdev_running() instead so that netdev-less wdevs aren't skipped. P2P/PD don't do anything in the later switch, but NAN code can now be reached. Assisted-by: LLM Fixes: 0e8ec738a71e ("wifi: cfg80211: add support for NAN data interface") Link: https://patch.msgid.link/20260904165614.6abc075b5401.Ib90696e3fa49b1698c27d64db5360d51f6f187a9@changeid Signed-off-by: Johannes Berg commit 708f9d43d6a2eb9c6b83fe62af628de9dffd9314 Author: Johannes Berg Date: Fri Sep 4 16:55:06 2026 +0200 wifi: cfg80211: ibss: ref BSS entry for joined event When the IBSS is joined, we only record the BSSID/channel in the event and look up the BSS entry when processing it. However, that's racy, e.g. a new scan with NL80211_SCAN_FLAG_FLUSH can remove it, causing a warning in the event work: !bss WARNING: net/wireless/ibss.c:37 at __cfg80211_ibss_joined+0x3d3/0x440 Workqueue: cfg80211 cfg80211_event_work cfg80211_process_wdev_events+0x39f/0x5b0 net/wireless/util.c:1144 cfg80211_process_rdev_events+0xa1/0x110 net/wireless/util.c:1179 cfg80211_event_work+0x2f/0x40 net/wireless/core.c:393 Do the lookup early (the driver is expected to only join an IBSS that has a BSS entry) and keep a reference to it. Assisted-by: LLM Fixes: 667503ddcb96 ("cfg80211: fix locking") Reported-by: syzbot+7f064ba1704c2466e36d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7f064ba1704c2466e36d Link: https://patch.msgid.link/20260904165614.f49a213f0e49.I192bfe738750ebb5f2c4faa3019a428da64cd3ec@changeid Signed-off-by: Johannes Berg commit b377e1000d963e7182a987082b4b06580bd7ac84 Author: Johannes Berg Date: Fri Sep 4 16:55:05 2026 +0200 wifi: cfg80211: don't filter by BSS type when removing stale entries When an assoc AP switches to a channel that already has a BSS entry, cfg80211_update_assoc_bss_entry() removes that entry before rehashing the real one, since the two would otherwise collide in the BSS rbtree. The lookup for that entry also required it to match the connection's BSS type, so an entry advertising e.g. the IBSS capability bit was left in place, and the following cfg80211_rehash_bss() then ran into it: WARN_ON(!cmp) Changing the type shouldn't really happen, but can be triggered by a rogue AP/device, so drop the check and remove any entries matching the comparison. Assisted-by: LLM Fixes: 0afd425b1b64 ("cfg80211: fix duplicated scan entries after channel switch") Reported-by: syzbot+dc6f4dce0d707900cdea@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=dc6f4dce0d707900cdea Link: https://patch.msgid.link/20260904165614.1f05dae1c546.Ib52d57b57caa912efee020f9d4a033a5160617ce@changeid Signed-off-by: Johannes Berg commit 068843ed0902c552a13860c5ec6b2ca65b57a065 Author: Johannes Berg Date: Fri Sep 4 16:55:04 2026 +0200 wifi: cfg80211: only group hidden BSSes with beacon entries When a probe response for an unknown BSS comes in, __cfg80211_bss_update() looks for an existing entry with the same BSSID and a hidden (zero-length or NUL-filled) SSID, and if it finds one it groups them, using the beacon IEs from the existing entry. But that could find another entry without a beacon, if it was also from a probe response (with SSID), so there's a group without beacon elements. If a beacon with a hidden SSID for that BSSID arrives later, cfg80211_combine_bsses() goes looking for the probe response entries that belong to it - i.e. entries with the same BSSID and channel that have no beacon IEs - and finds those two. They are already grouped with each other, so it hits its WARN_ON_ONCE(bss->pub.hidden_beacon_bss) WARN_ON_ONCE(!list_empty(&bss->hidden_list)) which are there because an entry without beacon elements is not supposed to be part of a group yet. Only combine entries when a beacon was already received, ones that are kept separate will be combined when a beacon arrives. Assisted-by: LLM Fixes: 4593c4cbe1c9 ("cfg80211: fix BSS list hidden SSID lookup") Reported-by: syzbot+1a797e1c81be78a2ace7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1a797e1c81be78a2ace7 Link: https://patch.msgid.link/20260904165614.bcfa64715745.Iad740347c86de56d4ff4f96a95f3c3afc47c42de@changeid Signed-off-by: Johannes Berg commit 955d86e5f3b95b731991fdb84966c50b16314629 Author: Bradley Morgan Date: Sun Aug 9 21:36:15 2026 +0000 arm64: hibernate: pass HVC_SET_VECTORS args to the resume hvc swsusp_arch_suspend_exit() reinstalls the restored kernel's hyp stub vectors with an hvc, but never passes the arguments. x0 is not set to HVC_SET_VECTORS and x1 is not set to the vector address, so the stub dispatch falls through and returns without writing vbar_el2. EL2 is left pointing at the trans_pgd copy of the vectors, a page that swsusp_free() releases right after resume. Set the arguments up the same way __hyp_set_vectors() does. Without this fix, Vladimir was able to trigger a hang when resuming from hibernation with CONFIG_PAGE_POISONING=y and page_poison=on. Fixes: 788bfdd97434 ("arm64: trans_pgd: hibernate: Add trans_pgd_copy_el2_vectors") Cc: stable@vger.kernel.org Signed-off-by: Bradley Morgan Reviewed-by: Vladimir Murzin Tested-by: Vladimir Murzin Acked-by: Mark Rutland Signed-off-by: Will Deacon commit dab68a74e90b8e07f08ed9deaa5884857a3cfe89 Author: Johannes Berg Date: Fri Sep 4 16:55:03 2026 +0200 wifi: cfg80211: don't free driver-owned scan requests When an interface goes down while a scan is running, cfg80211 completes the scan towards userspace and frees the scan request. However, the driver can be convinced that it owns the request, since the cancellation is (intended to be) asynchronous. The WARN_ON() in the netdev notifier was meant to catch this, but it's not actually avoidable, so it triggers and we get a UAF in scan_done(). There doesn't seem to be a great way around it, so just track that the driver is still convinced it owns the request, and then just free it on completion if it was already cancelled. Also remove the warnings since they can trigger in the intended architecture. Assisted-by: LLM Fixes: 4a58e7c38443 ("cfg80211: don't "leak" uncompleted scans") Reported-by: syzbot+189dcafc06865d38178d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=189dcafc06865d38178d Link: https://patch.msgid.link/20260904165614.375e543228b1.I03cbb5a54cb02d6bba5034286af1ed73aba134d1@changeid Signed-off-by: Johannes Berg commit dc750422170a563c7a81f6e49d36bb02c62ae37f Author: Shivank Garg Date: Sat Aug 22 19:22:06 2026 +0000 dmaengine: wait for RCU readers before releasing dma_device dma_issue_pending_all() walks the dma_device_list with list_for_each_entry_rcu() under rcu_read_lock(). dma_device_release() unlinks the device with list_del_rcu() and then calls device->device_release() (which in many drivers, such as plx_dma.c, directly calls kfree()). Because there is no grace period between unlinking the device and freeing it, concurrent RCU readers in dma_issue_pending_all() can access the device after it has been freed. The lockless walk originally relied on clients holding a dmaengine reference to pin the provider module, and therefore the device, for as long as they might traverse the list. Commit 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") decoupled the dma_device lifetime from the module reference, so the device can now be released while a reader is still walking the list. Add synchronize_rcu() before the device is freed, so RCU readers are guaranteed to have finished. Keep it unconditional: providers that do not implement device_release() free the device themselves once dma_async_device_unregister() returns. This call will delay for a grace period with dma_list_mutex held, which is safe and only teardown path is delayed. Fixes: 2ba05622b8b1 ("dmaengine: provide a common 'issue_pending_all' implementation") Suggested-by: Sashiko Link: https://sashiko.dev/#/patchset/20260526-dmaengine-kref-fix-v2-0-3df60afac01d@amd.com Reviewed-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-4-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul commit e873c74132f0c5f1452816cd9bb26208f0bba1e1 Author: Shivank Garg Date: Sat Aug 22 19:22:05 2026 +0000 dmaengine: fix use-after-free in dma_chan_put() and dma_release_channel() When dma_device_put() drops the last reference on chan->device->ref, dma_device_release() runs and may free the dma_device along with its channels. dma_chan_put() then still reads chan->device->owner via dma_chan_to_owner() for the trailing module_put(). KASAN catches it: slab-use-after-free in dma_chan_put+0x3e6/0x4c0 Read of size 8 by task insmod/6319 Freed by task 6319: kfree+0x225/0x470 dma_chan_put+0x395/0x4c0 dmaengine_put+0xf8/0x160 Cache the module owner in dma_chan_put() before the put so the trailing module_put() does not need chan->device. Fixes: 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") Suggested-by: Sashiko Link: https://sashiko.dev/#/patchset/20260518-dmaengine-kref-fix-v1-1-4d6125048fb7@amd.com Reviewed-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-3-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul commit 44dab659064eb5c10adb0306510eebe848ed592d Author: Shivank Garg Date: Sat Aug 22 19:22:04 2026 +0000 dmaengine: Fix device kref underflow in dma_chan_put() dma_chan_get() takes chan->device->ref only on the slow path: /* no kref on fast path */ if (chan->client_count) { __module_get(owner); chan->client_count++; return 0; } if (!try_module_get(owner)) return -ENODEV; if (!dma_device_get(chan->device)) { // calls kref_get_unless_zero() dma_chan_put() drops the ref unconditionally, so every fast-path get/put pair drops one extra device reference. The bug fires when two conditions hold together: a non-private provider has a persistent client holding chan->client_count > 0 and another client cycles dmaengine_get()/dmaengine_put(). When the kref hits zero, the subsequent dma_find_channel() returns NULL even though the provider module is still loaded. Fix this by dropping device->ref only on the last put, matching the single slow-path get. Fixes: 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") Reviewed-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-2-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul commit 424103642d009f5a7dc33300a49d5606d1bf4fb5 Author: Shivank Garg Date: Sat Aug 22 19:22:03 2026 +0000 dmaengine: add dma_device_get() helper Add dma_device_get() helper to match dma_device_put() to make code symmetric. It wraps open-coded kref_get_unless_zero() and asserts that dma_list_mutex is held, matching its put counterpart. No functional change intended. Suggested-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-1-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul commit 6ea92f0109dd7f86ac9787f1634ee68be1185721 Merge: df2908090cda36 e6df180e976fd0 Author: Greg Kroah-Hartman Date: Wed Sep 9 14:14:16 2026 +0200 Merge tag 'thunderbolt-for-v7.3-rc3' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-linus Mika writes: thunderbolt: Fixes for v7.3-rc3 This includes following USB4/Thunderbolt fixes: - Fix various issues around asynchronous DisplayPort tunnel activation when there is no graphics driver doing doing the capability exchange. - Fix potential NULL pointer dereference when XDomain connection is removed. - Fix use-after-free when control channel request is canceled. - Fix lockdep false positive. - Revert a commit that causes XDomain properties ping-pong. All these have been in linux-next with no reported issues. * tag 'thunderbolt-for-v7.3-rc3' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: Revert "thunderbolt: xdomain: Notify peers after enumeration" thunderbolt: Use separate lock class for each ring thunderbolt: Fix KASAN reported use-after-free when request is canceled thunderbolt: Fix NULL dereference in tb_remove_work() thunderbolt: Tear down inactive DP tunnels when the domain is stopped thunderbolt: Mark discovered tunnels as active thunderbolt: Don't access a DP tunnel after its DPRX read was canceled thunderbolt: Fix domain reference leak when DPRX read is canceled thunderbolt: Make the DP tunnel activation callback mandatory thunderbolt: Hold a router reference for each allocated HopID commit 53823e25793a97d07e6e98e0904bbf74cac8bc76 Author: Felix Gu Date: Sat Aug 22 02:58:47 2026 +0800 mmc: sdio_uart: fix xmit_fifo leak when the port table is full sdio_uart_add_port() allocates the transmit fifo before claiming a slot in sdio_uart_table[]. When all UART_NR slots are taken, it returns -EBUSY with the fifo still allocated, but the probe error path only kfree()s the port, leaking the transmit fifo. Free the fifo in the failure path of sdio_uart_add_port() itself so the function retains nothing on error. Fixes: 8b197a5ce7a7 ("sdio_uart: Use kfifo instead of the messy circ stuff") Signed-off-by: Felix Gu Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson commit 92c6a8d6470f7e7aa86c1f144818d8fa4fcbd5aa Author: Donggeun Yoo Date: Mon Sep 7 21:01:24 2026 +0900 dma-mapping: don't trace the DMA address when the allocation fails dma_alloc_attrs() passes *dma_handle to trace_dma_alloc() without checking whether the allocation succeeded. No backend writes it on failure: dma_direct_alloc(), iommu_dma_alloc() and the dma_map_ops instances assign it only on the path that returns a buffer. Callers usually pass an uninitialized automatic variable, so a failed allocation records whatever the stack held, next to the virt_addr=(null) that marks the record as an error: dma_alloc: dmatrace dir=BIDIRECTIONAL dma_addr=deadbeefdeadbeef size=1099511627776 virt_addr=0000000000000000 The device coherent pool path reaches the same call: a non-zero return from dma_alloc_from_dev_coherent() means the request was handled, not that it succeeded, so cpu_addr is NULL and dma_handle is untouched once the pool runs out. For an allocation event a NULL virt_addr already means the request failed, so the address field carries nothing. Report 0 for it in the event class rather than at each call site, which covers dma_alloc_pages() and dma_alloc_sgt_err() as well. Fixes: 038eb433dc14 ("dma-mapping: add tracing for dma-mapping API calls") Fixes: 68b6dbf1f441 ("dma-mapping: trace more error paths") Suggested-by: Marek Szyprowski Signed-off-by: Donggeun Yoo Link: https://lore.kernel.org/r/20260907120124.603373-1-donggeunyoo.kernel@gmail.com Reviewed-by: Sean Anderson Signed-off-by: Marek Szyprowski commit ed761e0693950fcb4f6b0f60387a3961b972adf3 Author: Leonardo Costa Date: Mon Jul 6 10:24:17 2026 -0300 drm/bridge: tc358768: Enforce input bus flags via atomic_check The tc358768 declares static bridge timings requiring pixel data to be sampled on the positive clock edge. However, the DRM core default propagation simply copies the output-side bus flags, coming from the next bridge, connector or panel, to the input side. If the propagated flags are incompatible with the bridge ones, the data is wrongly sampled, typically resulting in visual artifacts on the panel. Implement the atomic_check hook, replacing the mutually exclusive mode_fixup, and set the bridge state input bus flags to the ones required by the tc358768. The sync polarity defaulting previously done in mode_fixup is carried over into atomic_check unchanged. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Cc: stable@vger.kernel.org Signed-off-by: Leonardo Costa Reviewed-by: Francesco Dolcini Reviewed-by: Swamil Jain Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20260706132440.1594239-1-leoreis.costa@gmail.com Signed-off-by: Luca Ceresoli commit d12c6a6f0c8fd5b5b41120f7be319f743dae3b4f Author: blaze <1466528493@qq.com> Date: Wed Sep 9 12:42:59 2026 +0800 arc: kernel: Fix clk reference leak in show_cpuinfo() In show_cpuinfo(), clk_get() acquires a reference to the CPU clock, but clk_put() is never called to release it. Since show_cpuinfo() is the seq_file show callback for /proc/cpuinfo, this causes a clock reference count leak every time /proc/cpuinfo is read. The frequency is extracted via clk_get_rate() into a local variable, so the clock reference can be safely released immediately after. Fix this by calling clk_put(cpu_clk) right after clk_get_rate(). Fixes: 98f2892607c5 ("ARC: [cpuinfo] Add clk info in /proc/cpuinfo") Signed-off-by: blaze <1466528493@qq.com> Signed-off-by: Vineet Gupta commit 04eb7b5e043fbccf83d27a9be5c3973c2dbb110f Author: Anthony Iliopoulos Date: Thu Aug 20 15:13:39 2026 +0200 arc: remove unused profile.h includes None of the code in these files uses declarations provided by profile.h. Remove the unnecessary header includes across the various files to clean up dependencies and reduce include bloat. Signed-off-by: Anthony Iliopoulos Signed-off-by: Vineet Gupta commit 86ad6489e38c76c06c0b4a4229391a794023b5e0 Author: Julian Braha Date: Sun Aug 16 15:22:07 2026 +0100 ARC: cleanup dead ARC_CANT_LLSC option in Kconfig Currently, the ARC_CANT_LLSC config option can never be enabled. It is also not referenced anywhere else. So let's remove this dead code. Note that I have only compile-tested these changes, because I do not have the hardware to runtime test. This dead code was found by kconfirm, a static analysis tool for Kconfig. Signed-off-by: Julian Braha Signed-off-by: Vineet Gupta commit 56ea4e86832d8abe8930394473566c194d189f85 Author: Norbert Szetei Date: Mon Sep 7 16:22:17 2026 +0200 nstree: check listing permission before taking a namespace reference legitimize_ns() takes a reference on the candidate namespace before may_list_ns() has decided whether the caller may see it. The __free(ns_put) cleanup on the denied path can drop the last reference to a mount namespace while we still hold the rcu read lock, and put_mnt_ns() may sleep there. This is the same problem commit 2ec2aff3c8e2 ("ns: make sure reference are dropped outside of rcu lock") fixed for the put_user() path. Neither ns_requested() nor may_list_ns() needs a reference, both only look at the namespace type and at the caller's own namespaces, so do the checks first and take the reference last. Splat: Voluntary context switch within RCU read-side critical section! WARNING: kernel/rcu/tree_plugin.h:332 at rcu_note_context_switch+0x238/0x2a0, CPU#5: a/3442 CPU: 5 UID: 1000 PID: 3442 Comm: a Not tainted 7.0.0-30-generic #30-Ubuntu PREEMPT(lazy) RIP: 0010:rcu_note_context_switch+0x238/0x2a0 Call Trace: __schedule+0xcf/0x650 schedule+0x27/0x90 schedule_preempt_disabled+0x15/0x30 __mutex_lock.constprop.0+0x550/0xaf0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3b/0x50 exp_funnel_lock+0xb2/0x260 synchronize_rcu_expedited+0xe7/0x220 namespace_unlock+0x26a/0x320 put_mnt_ns+0xd3/0x120 mntns_put+0xe/0x20 do_listns+0x13e/0x560 __do_sys_listns+0x126/0x2d0 __x64_sys_listns+0x20/0x30 x64_sys_call+0x2366/0x2390 do_syscall_64+0x105/0x5a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 76b6f5dfb3fd ("nstree: add listns()") Signed-off-by: Norbert Szetei Link: https://patch.msgid.link/ABA32239-733B-438C-B95A-B13ED69FF0F3@doyensec.com Reviewed-by: Bradley Morgan Signed-off-by: Christian Brauner (Amutable) commit a76f015d424e1956e7be9ead2224ab9816be5d79 Merge: 560f4deda32785 ffe0486b139e45 Author: Petr Mladek Date: Wed Sep 9 09:52:21 2026 +0200 Merge branch 'for-7.4-trivial' into for-linus commit e780259b54e618ceb4763fbc21314acf3565e813 Author: Jann Horn Date: Mon Sep 7 23:26:32 2026 +0200 exec: do_close_on_exec() before taking exec_update_lock do_close_on_exec() currently happens while holding the exec_update_lock, which is used in a lot of places that access process state to synchronize access checks. I recently added another such use of exec_update_lock, causing a regression. do_close_on_exec() can block waiting for a reply from a filesystem. That means a hung filesystem can block codepaths that use exec_update_lock; and it also means that a FUSE filesystem which attempts to inspect the calling process can deadlock. To avoid such problems, move do_close_on_exec() before the exec_update_lock is taken, but after the FD table has been copied if necessary. I have looked through all the calls between the old and new position of the do_close_on_exec() call; there seems to be no file descriptor table access in between. Reported-by: Benjamin Peterson Closes: https://lore.kernel.org/r/f5e8166a-88be-46c5-8939-1e5227ffe4c2@app.fastmail.com Fixes: 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260907-cloexec-before-exec-update-lock-v1-1-8018c201a7df@google.com Tested-by: Benjamin Peterson Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit f7491d7c81db0e7c304a7bd757a76d2fbeaff80e Author: Vernon Yang Date: Thu Sep 3 11:16:08 2026 +0800 x86/mm: Fix user-space data loss with MADV_FREE and THP Some of users of Polars (a data analytics library) have lost production data from this bug. They seem to have just the right combination of huge pages, MADV_FREE and heavy reclaim pressure. pmd_modify() masks the old value with (_HPAGE_CHG_MASK & ~_PAGE_DIRTY), silently discarding the hardware dirty bit. The subsequent pmd_mksaveddirty() call is supposed to transfer _PAGE_DIRTY into _PAGE_SAVED_DIRTY when write-protecting, but the dirty bit was already stripped from the value, so there is nothing left to transfer. Contrast with pte_modify(), which keeps _PAGE_DIRTY_BITS in its mask, and pud_modify(), which keeps _HPAGE_CHG_MASK untouched: pmd_modify() is the odd one out. Any pmd_modify() on a writable, dirty PMD loses the dirty state. One visible consequence is data loss with MADV_FREE on PMD-mapped THP: memset(buf, 0x5A, size); // PMD-mapped THP, PMD dirty madvise(buf, size, MADV_FREE); // PMD cleaned but left writable, // folio marked lazyfree memset(buf, 0x5A, size); // hardware sets _PAGE_DIRTY again mprotect(buf, size, PROT_READ); // pmd_modify() drops the dirty bit mprotect(buf, size, PROT_READ|PROT_WRITE); // ... memory pressure ... Reclaim (e.g. under memcg pressure) then finds the lazyfree folio with no dirty bit set anywhere and frees it in __discard_anon_folio_pmd_locked(), even though the data was rewritten after MADV_FREE; subsequent reads fault in fresh zero pages. NUMA hinting alone can trigger the same loss, as do_huge_pmd_numa_page() restores the PMD through pmd_modify() as well. PMD-mapped file THPs are affected too: mprotect()/NUMA hinting dropping the dirty bit means rewritten data is never written back. Fix it by keeping _PAGE_DIRTY in the preserved mask, exactly like pte_modify() and pud_modify() do. The existing pmd_mksaveddirty()/pmd_clear_saveddirty() pair then performs the hardware-dirty <-> saved-dirty transition based on the write bit, preserving the shadow-stack encoding rules. Fixes: bb3aadf7d446 ("x86/mm: Start actually marking _PAGE_SAVED_DIRTY") Closes: https://lore.kernel.org/r/CAJxLxMUGu1-L+O_nAONOwOXnS=cNbNApCWqdthRjd76LThtSPg@mail.gmail.com/ Reported-by: Orson Peters Signed-off-by: Vernon Yang Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Reviewed-by: Rick Edgecombe Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260903031608.1194238-1-vernon2gm@gmail.com commit 9e4a3ec3411bb6bb59e3c1f29b75609f1e87aac4 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 12:01:27 2026 +0300 x86/mm/pat: Allocate split page tables as kernel page tables A PTE is allocated directly without going through the standard page table allocation routines (such as pte_alloc_one_kernel()) when the CPA code splits a large page (__split_large_page()). This means the page table constructor is never called nor is the page table marked as a kernel page table. The former results in the folio associated with the page table not being marked as a page table (__pagetable_ctor() is never called thus neither is __folio_set_pgtable()) nor are statistics updated to reflect it (lruvec_stat_add_folio() is never called). The latter issue of failing to mark the page table as a kernel page table (ptdesc_set_kernel() is never called) is far more problematic. Since commit: 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables") kernel page table freeing has been batched and since the subsequent commit: e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for kernel address space") IOTLB cache entries for kernel page tables have been invalidated upon being freed. Since split page tables are freed without this invalidation, the IOTLB can contain stale entries for them. Resolve the issue by using the ordinary PTE allocation API at split time. This results in these kernel page tables invoking a page table constructor, and thus requires a page table destructor. Destructors are not always present, like for early allocated direct map page tables). Conditionally call pagetable_dtor_free() if the PG_table folio flag for the ptdesc is set, otherwise we free the page table via pagetable_free(). Regardless of which path is taken page tables marked as kernel page tables, which now includes split page tables, take the correct route through pagetable_free_kernel(). There is a user-visible side effect in that split page tables will appear in nr_page_table_pages in /proc/vmstat (as do other kernel page tables allocated after early boot), however this is a positive change. This issue started being markedly problematic after commit: 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables") so choose this as the Fixes target. [ dhansen: rephrase in imperative mood ] Fixes: 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Acked-by: Vishal Moola Tested-by: Atish Patra Tested-by: Nikunj A Dadhania Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260813-cpa-fixes-v2-4-39b4ff90f91d@kernel.org commit 1587d3394e254639cc36516256031334095e6ef3 Author: Pedro Falcato Date: Thu Aug 13 12:01:26 2026 +0300 x86/alternatives: Exclude text poking against change_page_attr() From time to time, the following BUG can be observed in the x86 alternatives patching code [0]: > kernel BUG at arch/x86/kernel/alternative.c:2576! > Oops: invalid opcode: 0000 [#1] SMP NOPTI > CPU: 0 UID: 0 PID: 355 Comm: (udev-worker) Not tainted 7.1.3-1-default #1 PREEMPT(full) openSUSE Tumbleweed 8c1795b03ec64f997e57a8ad38b1161e3b98da64 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 > RIP: 0010:__text_poke+0x2aa/0x450 > Call Trace: > > smp_text_poke_batch_finish+0x2a7/0x320 > __static_call_transform+0xb7/0x220 > arch_static_call_transform+0x5b/0xb0 > __static_call_init+0xe9/0x270 > static_call_module_notify+0x11f/0x150 > notifier_call_chain+0x61/0xe0 > blocking_notifier_call_chain_robust+0x63/0xc0 > load_module+0x1c92/0x20c0 > init_module_from_file+0xd8/0x140 > idempotent_init_module+0x100/0x2f0 > __x64_sys_finit_module+0x71/0xe0 > do_syscall_64+0xe1/0x610 > entry_SYSCALL_64_after_hwframe+0x76/0x7e which matches the following BUG_ON() in alternative.c: /* * If something went wrong, crash and burn since recovery paths are not * implemented. */ BUG_ON(!pages[0] || (cross_page_boundary && !pages[1])); This can happen if vmalloc_to_page() fails, for any reason. Such can happen if text poking races with CPA, which can possibly result in the collapsing of page tables (or breaking of PMD hugepages). It is not a problem for most users of vmalloc_to_page() (they solely own the vmalloc'd range) but, when CONFIG_ARCH_HAS_EXECMEM_ROX=y, various modules own a single execmem vmalloc range, and can call set_memory_*() in parallel on it. This can happen to race against __text_poke and cause havoc in vmalloc_to_page(). Fix it by excluding against CPA using the init_mm mmap read lock. [ dhansen: Fix up SoB ordering. The actual code flow here was: Pedro=>Lorenzo=>Mike=>Me which is reflected in the SoB chain now. I *believe* Mike simply picked up Lorenzo's update to Pedro's post from the Link ] Fixes: 64f6a4e10c05 ("x86: re-enable EXECMEM_ROX support") Reported-by: Jiri Slaby Reported-by: Steffen Dirkwinkel Signed-off-by: Pedro Falcato Signed-off-by: Lorenzo Stoakes (ARM) Co-developed-by: Lorenzo Stoakes (ARM) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Tested-by: Jiri Slaby Tested-by: Atish Patra Tested-by: Nikunj A Dadhania Cc: stable@vger.kernel.org Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1271202 [0] Link: https://lore.kernel.org/linux-mm/555ea1d43a12c30a8f1eaf10c899b3790d728f33.camel@dirkwinkel.cc/ Link: https://patch.msgid.link/20260813-cpa-fixes-v2-3-39b4ff90f91d@kernel.org commit d5d8b8662e6e5a565b47a0388640e88402f23274 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 12:01:25 2026 +0300 x86/mm/pat: Acquire init_mm read lock on attribute changes to avoid UAF A previous commit protected against races between ptdump and CPA collapse, however one still exists between attribute changes and collapse as reported by Denis V. Lunev (linked). When an attribute change arises, a lockless page table walker obtains a PTE entry, which is later written to via set_pte_atomic(): ... -> change_page_attr_set_clr() -> __change_page_attr_set_clr() -> __change_page_attr() -> _lookup_address_cpa() -> lookup_address_in_pgd_attr() -> [ lockless page table walker ] -> set_pte_atomic() There is nothing preventing a concurrent CPA collapse which can free the PTE that was retrieved here, resulting in a use-after-free. With the mmap write lock taken on init_mm over CPA collapse, resolve this race by acquiring an mmap read lock on init_mm over __change_page_attr_set_clr(). This locks across the whole operation over which the walk and the PTE entry write occurs, solving the race. It is safe to do this here, as no spinlocks are held upon entry to __change_page_attr_set_clr(). However, the lock must not be held over an allocation, as allocation can trigger reclaim and shrinkers may call into CPA recursively, making deadlocks possible (init_mm -> ... -> fs_reclaim -> init_mm). A page table is allocated when a huge page needs to be split: -> change_page_attr_set_clr() -> __change_page_attr_set_clr() -> __change_page_attr() -> split_large_page() [ pagetable_alloc() ] -> __split_large_page() Avoid deadlocks by dropping the mmap lock across pagetable_alloc() in split_large_page() and track whether this is needed by adding a new 'init_mm_read_locked' flag to struct cpa_data. This is safe as __split_large_page() (called with locks re-established) revalidates that the page table entry is the same as it was prior to the locks being dropped and __change_page_attr() repeats the entire page table walk whenever a split occurs, so concurrent split and collapse are accounted for. Concurrent ptdump is also safe as the lock is only dropped over page table allocation during which time the page table has not yet been modified. The CPA_COLLAPSE flag is only set by set_memory_rox(), which exclusively operates upon vmalloc ranges, and on x86 only within the module mapping space. This is important, because some callers directly invoke __change_page_attr_set_clr(), bypassing this lock. However, none of these operate within the module mapping space. * cpa_process_alias() - a recursive helper called by __change_page_attr_set_clr(). * __set_memory_enc_pgtable() - operates on the direct mapping and (via __vmbus_establish_gpadl()) the vmalloc mapping space. * __set_pages_[n]p() - called by set_direct_map_[invalid, default, valid]_noflush(), __kernel_map_pages() - operates on the direct map. * kernel_[un]map_pages_in_pgd() - operates on EFI ranges. This work is based upon Denis V. Lunev's excellent analysis of the bug with gratitude. [ dhansen: move to imperative voice in changelog ] Fixes: 41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Tested-by: Atish Patra Tested-by: Nikunj A Dadhania Link: https://lore.kernel.org/all/20260626163213.2284080-1-den@openvz.org/ Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20260813-cpa-fixes-v2-2-39b4ff90f91d@kernel.org commit a1c7570cedd03372812a5b693732880867babbca Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 12:01:24 2026 +0300 x86/mm/pat: Acquire init_mm write lock on collapse to avoid UAF x86 implements page attribute modification using its Change Page Attributes (CPA) mechanism. This tracks properties of ranges such as cache mode through x86 page attributes, and as part of that logic manipulates kernel page tables. Since commit: 41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation") ranges of kernel page table entries can be collapsed into huge page table entries as part of this logic. As part of this collapse, it frees the page tables which the collapsed entries previously pointed to, and it does so without any relevant locks being held to preclude concurrent kernel page table walkers. The only way this code can be reached is if CPA_COLLAPSE is specified, and this is only set in set_memory_rox() via: set_memory_rox() -> change_page_attr_set_clr() -> cpa_flush() -> cpa_collapse_large_pages() Notable users of this are execmem and BPF when manipulating executable mappings. However, this is problematic for ptdump as it walks ranges it does not own and thus runs the risk of a use-after-free on page tables freed underneath it. In addition, concurrent CPA collapse operations are possible which can also cause races. Resolve the issue by acquiring the mmap write lock on init_mm across the whole operation. It is safe to acquire a sleeping lock as all the callers invoke set_memory_rox() from process context and in any case, change_page_attr_set_clr() calls vm_unmap_alias() which ultimately takes a mutex, disallowing atomic context here. Fixes: 41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: Kiryl Shutsemau (Meta) Reviewed-by: David Hildenbrand (Arm) Reviewed-by: Dave Hansen Reviewed-by: Will Deacon Reviewed-by: David Carlier Tested-by: Atish Patra Tested-by: Nikunj A Dadhania Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20260813-cpa-fixes-v2-1-39b4ff90f91d@kernel.org commit b7d7914a9ae3097e63d113007e4fb44d33d515b1 Author: Donggeun Yoo Date: Sat Sep 5 17:42:10 2026 +0900 swiotlb: use the adjusted address for the highmem page lookup swiotlb_bounce() reads the page frame number from the slot's recorded orig_addr, then advances orig_addr by tlb_offset to reach the address the caller asked about. The highmem branch mixes the two: the offset within the page comes from the adjusted address, the page from the value before it. Once the adjustment crosses a page boundary the pair no longer describes one location, and the whole copy lands one page below the intended one for a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE writes the device data over the wrong page and leaves the intended one stale, DMA_TO_DEVICE feeds the device from a page the mapping may not cover. Partial syncs through dma_sync_single_range_for_*() are what make tlb_offset non-zero. The branch test is picked the same way, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path then hands a highmem address to phys_to_virt(). Take both from orig_addr once it is final and keep pfn in the branch that uses it. PhysHighMem() asks the question straight from the address, as dma-debug already does. Fixes: 5f89468e2f06 ("swiotlb: manipulate orig_addr when tlb_addr has offset") Cc: stable@vger.kernel.org Signed-off-by: Donggeun Yoo Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20260905084210.148255-1-donggeunyoo.kernel@gmail.com Signed-off-by: Marek Szyprowski commit 504981db4f69bdd28054fb98c96a3a67f7248dde Author: Donggeun Yoo Date: Sat Sep 5 16:47:27 2026 +0900 dma-coherent: report a failed reserved memory assignment rmem_dma_device_init() drops the return value of dma_assign_coherent_memory() and always reports success. That call fails with -EBUSY when the device already has a coherent pool, and the file allows only "*one* such region of memory" per device. of_reserved_mem_device_init_by_idx() reads the zero as success. It logs "assigned reserved memory node" for a region that was not assigned and records the pairing, so of_reserved_mem_device_release() later runs rmem_dma_device_release() for it. That clears dev->dma_mem without looking at which region it was called for, dropping the pool the device did get and leaving it on ordinary memory. dma_declare_coherent_memory() checks the same call and releases the memory on failure, and rmem_swiotlb_device_init() propagates its own errors. Return the error here as well, so a device tree that assigns two pools to one device fails the probe instead of half working. Fixes: 7bfa5ab6fa1b ("drivers: dma-coherent: add initialization from device tree") Signed-off-by: Donggeun Yoo Link: https://lore.kernel.org/r/20260905074727.108029-1-donggeunyoo.kernel@gmail.com Signed-off-by: Marek Szyprowski commit 7891fbb9512f127826e1d5dbf380ee212bd15eb0 Author: Ackerley Tng Date: Tue Sep 1 20:38:40 2026 -0700 mm/folio: EXPORT_SYMBOL_FOR_KVM(lru_cache_drain_for_folio) To simplify independent development in the KVM and MM subsystems, now export to KVM the lru_cache_drain_for_folio() which MM added in 7.3-rc1. Link: https://lore.kernel.org/lkml/bd6c9c74-e374-a9d3-ba1f-8b6f430894fc@google.com/T/#u Link: https://lore.kernel.org/02876cea-5727-2ca4-bead-73659ea6fec4@google.com Signed-off-by: Ackerley Tng Signed-off-by: Hugh Dickins Acked-by: Vlastimil Babka (SUSE) Suggested-by: David Hildenbrand Reviewed-by: Fuad Tabba Reviewed-by: Binbin Wu Cc: Matthew Wilcox (Oracle) Cc: Sean Christopherson Signed-off-by: Andrew Morton commit 932cfb25e7ce98d1f93895671ec186a3087e4f80 Author: Jiayuan Chen Date: Wed Sep 2 15:37:59 2026 +0800 mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem With cgroup.memory=nokmem, shrinker_memcg_alloc() bails out early and never allocates an id, so shrinker->id keeps the 0 it got from the kzalloc() in shrinker_alloc(). __list_lru_init() then copies that 0 into lru->shrinker_id, where it looks like a valid bit index. Nothing calls expand_shrinker_info() on nokmem either, so shrinker_nr_max stays 0 and every memcg ends up with an empty map (map_nr_max == 0). deferred_split_folio() hands a real memcg to __list_lru_add() regardless of whether the lru is memcg aware, so the first THP queued in a cgroup does set_shrinker_bit(memcg, nid, 0) and trips the bounds check: WARNING: mm/shrinker.c:212 at set_shrinker_bit+0x7d/0x90, CPU#126 Call Trace: deferred_split_folio+0x18c/0x220 map_anon_folio_pmd_nopf+0xdd/0x130 map_anon_folio_pmd_pf+0x14/0xb0 do_huge_pmd_anonymous_page+0x1a1/0x620 __handle_mm_fault+0xea9/0x10d0 handle_mm_fault+0xe5/0x320 do_user_addr_fault+0x1cc/0x870 exc_page_fault+0x81/0x1b0 asm_exc_page_fault+0x27/0x30 Harmless, the WARN_ON_ONCE() is what keeps the out of bounds unit[] read from happening, but the id should not look valid in the first place. Clear it before returning. Two other spots could paper over this: drop the id in __list_lru_init() when nokmem turns memcg_aware off, or make deferred_split_folio() pass NULL like list_lru_add_obj() does. Both leave shrinker->id lying around for the next caller, so fix it where the id is handed out. Link: https://lore.kernel.org/20260902073800.305481-1-jiayuan.chen@linux.dev Fixes: fafaeceb89a5 ("mm: switch deferred split shrinker to list_lru") Signed-off-by: Jiayuan Chen Acked-by: Shakeel Butt Cc: Usama Arif Cc: Dave Chinner Cc: Johannes Weiner Cc: Kairui Song Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton commit 6cc27d82196385fe06853319f74312a7d8019726 Author: Lorenzo Stoakes (ARM) Date: Wed Sep 2 19:08:08 2026 +0100 mm/vma: correctly unaccount on mmap_prepare() failure __mmap_setup() accounts memory for relevant mappings via: security_vm_enough_memory_mm() -> __vm_enough_memory() -> vm_acct_memory() If __mmap_setup() fails, this indicates that this accounting did not take place, and thus it's appropriate for __mmap_region() to jump to abort_munmap. However if call_mmap_prepare() fails, it also jumps there and any accounted memory is not correctly unaccounted. Fix this by handling each error separately. Link: https://lore.kernel.org/20260902-fix-unaccount-mmap_prepare-v1-1-ea070189fdfb@kernel.org Fixes: c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file callback") Signed-off-by: Lorenzo Stoakes (ARM) Cc: Jann Horn Cc: Liam R. Howlett Cc: Pedro Falcato Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton commit 1f6de65e3314519ce462bfd3a1d29e918f97e4e5 Author: Peter Griffin Date: Tue Sep 8 12:37:27 2026 +0000 opp: fix use after free in _update_opp_table_clk() dev_pm_opp_put_opp_table() frees the opp_table which is subsquently used by dev_err_probe(). This causes an Oops during boot on gs101-oriole. cpu cpu0: error 000000006b6b6b6b: Couldn't find clock Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cd3 ... Hardware name: Oriole (DT) pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _of_add_table_indexed+0x80/0xbb0 lr : _of_add_table_indexed+0x6c/0xbb0 ... Call trace: _of_add_table_indexed+0x80/0xbb0 (P) dev_pm_opp_of_cpumask_add_table+0x70/0x120 dt_cpufreq_probe+0x23c/0x480 platform_probe+0x64/0xb8 Fixes: 84f05af0975c9 ("opp: Use clk_get_optional() to avoid leaving opp_table->clk as an error pointer") Signed-off-by: Peter Griffin Reviewed-by: Tudor Ambarus [ Viresh: use return value of dev_err_probe() ] Signed-off-by: Viresh Kumar commit dcbd1c054848848a1937ca0768ce2bdbc31ae621 Author: Gabriel Krisman Bertazi Date: Wed Sep 2 20:00:40 2026 -0300 io_uring/net: let io_recv_buf_select return the length of the buffer region In preparation to using this field as an upper limit to truncation, return the size of the allocated region. Fixes: ae98dbf43d75 ("io_uring/kbuf: add support for incremental buffer consumption") Cc: stable@vger.kernel.org Signed-off-by: Gabriel Krisman Bertazi Link: https://patch.msgid.link/20260902230041.1320658-2-krisman@suse.de Signed-off-by: Jens Axboe commit 796aa0547557e63338657ed1c487906f9fac4c73 Author: Jens Axboe Date: Tue Sep 8 17:53:20 2026 -0600 io_uring/rw: end write accounting from ->ki_complete Commit b000145e9907 moved both the fsnotify calls and the write accounting out of the kiocb completion handler and into the io_req_rw_complete() task_work. However, only the fsnotify part actually needed to move as it may sleep. Ending the write accounting is just a percpu_up_read() on the superblock writers sem. Deferring it is a problem, because it makes dropping SB_FREEZE_WRITE protection depend on the ring owner getting to running task_work. But the task may be blocked in freeze_super(), causing it to never get to that: task io-wq worker -------------------------------------------------------------- io_write() io_kiocb_start_write() (takes sb_writers, hidden from lockdep by __sb_writers_release) write_iter() -> -EIOCBQUEUED ioctl(FS_IOC_SHUTDOWN) bdev_freeze() freeze_super() percpu_down_write() <- waits for the reader above io_write() kiocb_start_write() percpu_down_read() <- queued behind the writer io_complete_rw() queues io_req_rw_complete() <- never runs, task is in D state End the write from io_complete_rw() instead, and leave only the fsnotify calls in task_work. Reported-by: syzbot+2eb3d983669d3e49d4fa@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Fixes: b000145e9907 ("io_uring/rw: defer fsnotify calls to task context") Signed-off-by: Jens Axboe commit a401a9d547c50ef34db1088cc1fb9a201a7af657 Merge: 7a49e6b16f36b8 382a373d9ea7a6 Author: Jakub Kicinski Date: Tue Sep 8 17:52:09 2026 -0700 Merge branch 'net-macb-fix-two-probe-path-leaks' Nicolai Buchwitz says: ==================== net: macb: fix two probe path leaks Two independent leaks on macb probe paths, both noticed while reviewing the fixed-link unbind crash fix [1]. Patch 1 destroys the phylink instance when probe fails after macb_mii_init() has succeeded. Patch 2 drops the "mdio" child node reference on the success path of macb_mii_init(). [1] https://lore.kernel.org/netdev/20260902102836.2019355-1-vineeth.karumanchi@amd.com/ ==================== Link: https://patch.msgid.link/20260907210856.1673589-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski commit 382a373d9ea7a6ac4de9c022385b6217f65ae3cc Author: Nicolai Buchwitz Date: Mon Sep 7 23:08:56 2026 +0200 net: macb: put the "mdio" child node reference on success macb_mii_init() holds the reference returned by of_get_child_by_name() for macb_mdiobus_register() and drops it only on the error paths, so every successful probe leaks a node reference. On a CM5, overlay removal after four bind cycles reports OF: ERROR: memory leak, expected refcount 1 instead of 5 Drop the reference after registration, where __mdiobus_register() has already taken its own for the lifetime of the bus. Fixes: 8a6631f1cece ("net: macb: avoid redundant lookup for "mdio" child node in MDIO setup") Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260907210856.1673589-3-nb@tipi-net.de Signed-off-by: Jakub Kicinski commit 7d059f390750152b9bd69df934198651b94fc26d Author: Nicolai Buchwitz Date: Mon Sep 7 23:08:55 2026 +0200 net: macb: destroy the phylink instance on the probe error path macb_mii_init() creates a phylink instance on both of its success paths, but the probe unwind frees the netdev without destroying it, so a failing macb_alloc_tieoff() or register_netdev() leaks the instance. Destroy it at err_out_unregister_mdio, which is only reachable once macb_mii_init() has succeeded, so bp->phylink is valid there. Fixes: 7897b071ac3b ("net: macb: convert to phylink") Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260907210856.1673589-2-nb@tipi-net.de Signed-off-by: Jakub Kicinski commit 7a49e6b16f36b8e085521699adbca3e321b6dd0c Author: Zhiling Zou Date: Thu Sep 3 14:56:14 2026 +0800 net: bridge: use option bits for CFM/MRP frame handlers CFM and MRP register a global br_frame_type whose hlist_node is linked into the per-bridge frame_type_list when the first MEP/MRP instance is created. Enabling the protocol on multiple bridges therefore inserts the same node into multiple lists. Unregistering it on one bridge then corrupts list state belonging to another. These handlers can only be installed once per bridge, and they are uncommon. Track their per-bridge enable state with net_bridge option bits, which already live on the Rx hot cache line, and dispatch the matching handler directly from the receive path. Check both bits together first as an unlikely case. Remove the generic frame_type_list and br_frame_type helpers, which have had no other users since CFM and MRP were added. That shrinks struct net_bridge by 8 bytes and drops the list walk from the fast path. When neither protocol is compiled in, BR_CFM_MRP_OPTS is 0 and the compiler prunes the branch. Fixes: 90c628dd47ff ("net: bridge: extend the process of special frames") Fixes: dc32cbb3dbd7 ("bridge: cfm: Kernel space implementation of CFM. CCM frame RX added.") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Nikolay Aleksandrov Co-developed-by: Yilin Zhu Signed-off-by: Yilin Zhu Signed-off-by: Zhiling Zou Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/0345b9d5aa60ba416f6738ff1b87140f0a749cb8.1788417901.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski commit ba4ba11ed6eb8972c69070417fc27b48deb002e8 Author: Norbert Szetei Date: Sun Sep 6 10:21:09 2026 +0200 net: openvswitch: fix use-after-free of the flow table mask array tbl_mask_array_realloc() retires the old mask_array before it stops being reachable: old = ovsl_dereference(tbl->mask_array); if (old) { ... call_rcu(&old->rcu, mask_array_rcu_cb); } rcu_assign_pointer(tbl->mask_array, new); call_rcu() only waits for read-side critical sections already in flight. tbl->mask_array still points at old between the call_rcu() and the rcu_assign_pointer(), so a reader entering ovs_flow_tbl_lookup_stats() in that window picks up old in a fresh critical section that the pending grace period does not cover. tbl_mask_array_realloc() runs in process context under ovs_mutex, so the window is preemptible and can outlast the grace period. Then mask_array_rcu_cb() frees old before the swap runs: BUG: KASAN: slab-use-after-free in flow_lookup.constprop.0+0x2bf/0x2f0 Read of size 8 at addr ffff888020b3e018 by task poc/741 flow_lookup.constprop.0+0x2bf/0x2f0 ovs_flow_tbl_lookup_stats+0x4a3/0x5c0 ovs_dp_process_packet+0x19c/0x710 ovs_vport_receive+0x243/0x390 internal_dev_xmit+0x81/0x170 Freed by task 728: kfree+0x16a/0x4e0 rcu_core+0x853/0x1030 Publish the new array before retiring the old one. The kfree_rcu() that call_rcu() replaced ran after the swap. Fixes: eac87c413bf9 ("net: openvswitch: reorder masks array based on usage") Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Acked-by: Eelco Chaudron echaudro@redhat.com Link: https://patch.msgid.link/DE115F9C-2545-423E-A702-986FC952FD62@doyensec.com Signed-off-by: Jakub Kicinski commit cdca92eddc025fdb90071be97738f7d55a65f8dd Author: Naman Gulati Date: Fri Sep 4 18:06:44 2026 +0000 ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings() syzbot reported a null-ptr-deref in __ip6_del_rt_siblings() [0]. The stack trace hinted towards a null dereference of rt->fib6_node when fn->leaf is accessed in __ip6_del_rt_siblings(). With RTNL_FLAG_DOIT_UNLOCKED set, inet6_rtm_delroute() operations run concurrently without acquiring the RTNL lock. In ip6_route_del(), the route lookup happens under rcu_read_lock() without acquiring table->tb6_lock. Between ip6_route_del() looking up the route and __ip6_del_rt_siblings() acquiring table->tb6_lock, another thread can modify the routing table. For example, when an ECMP route is replaced via RTM_NEWROUTE with NLM_F_REPLACE, fib6_add_rt2node() unlinks all old siblings and sets iter->fib6_node = NULL. A reproducer was found that triggers this [1]. Add a check to ensure rt->fib6_node is non-null before accessing it. [0] KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__ip6_del_rt_siblings+0x31e/0x7c0 net/ipv6/route.c:4056 Call Trace: ip6_route_del+0x1054/0x1110 net/ipv6/route.c:4232 inet6_rtm_delroute+0x5d7/0x6d0 net/ipv6/route.c:5669 rtnetlink_rcv_msg+0x802/0xc00 net/core/rtnetlink.c:7132 netlink_rcv_skb+0x226/0x4a0 net/netlink/af_netlink.c:2556 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x7f5/0x990 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1900 sock_sendmsg_nosec+0x13a/0x180 net/socket.c:800 __sock_sendmsg net/socket.c:815 [inline] ____sys_sendmsg+0x565/0x870 net/socket.c:2713 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2767 __sys_sendmsg net/socket.c:2799 [inline] __do_sys_sendmsg net/socket.c:2804 [inline] __se_sys_sendmsg net/socket.c:2802 [inline] __x64_sys_sendmsg+0x1b7/0x290 net/socket.c:2802 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f [1] https://gist.github.com/NamanGulati/0766a1159b6ca61928faaf87425ff899 Fixes: bd11ff421d36 ("ipv6: Get rid of RTNL for SIOCDELRT and RTM_DELROUTE.") Reported-by: syzbot+a73e5ee0fd534fed75bd@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a9b03f9.04649fcc.10325f.0003.GAE@google.com Signed-off-by: Naman Gulati Reviewed-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Reviewed-by: Fernando Fernandez Mancera Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260904180645.706425-1-namangulati@google.com Signed-off-by: Jakub Kicinski commit e24279bffec6c9aa3fef7e3c64bd4000aca9d698 Author: Karl Mehltretter Date: Sat Sep 5 12:06:08 2026 +0200 MAINTAINERS: Update the so_txtime selftest path in SOCKET TIMESTAMPING Commit 5c6baef3885c ("selftests: drv-net: convert so_txtime to drv-net") moved the test to tools/testing/selftests/drivers/net/, but the SOCKET TIMESTAMPING entry still lists the old path and scripts/get_maintainer.pl --self-test=patterns reports it as matching nothing. Point the pattern at the new location. Signed-off-by: Karl Mehltretter Reviewed-by: Jason Xing Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260905100608.42539-1-kmehltretter@gmail.com Signed-off-by: Jakub Kicinski commit 8dc5d98a16fa23c00999aecf10018c9f69fa5bf4 Author: Vlatko Kosturjak Date: Thu Sep 3 08:21:29 2026 +0200 ppp_async: drop the errored frame instead of resetting its headroom ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: *(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: err: if (skb) { /* make skb appear as freshly allocated */ skb_trim(skb, 0); skb_reserve(skb, - skb_headroom(skb)); } ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev: kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied. Fixes: 6722e78c9005 ("[PPP]: handle misaligned accesses") Suggested-by: Eric Dumazet Signed-off-by: Vlatko Kosturjak Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/apkR6ZU+tqP2C3Fl@griffin.linux.hr Signed-off-by: Jakub Kicinski commit f6d61fe4c19cf448e5cba6d8767b4e6966f58606 Author: Long Li Date: Wed Sep 2 10:51:53 2026 -0700 net: mana: Clear RDMA teardown and suspend state in mana_rdma_probe() mana_rdma_remove() sets gd->rdma_teardown to stop mana_rdma_service_handle() from acting on servicing events, but nothing ever clears it. A hardware service reset (GDMA_EQE_HWC_RESET_REQUEST) goes through mana_gd_suspend() -> mana_rdma_remove() and mana_gd_resume() -> mana_rdma_probe(), so from the first reset onwards every GDMA_EQE_HWC_SOC_SERVICE event returns early and RDMA suspend/resume servicing is silently dropped for the life of the device. gd->is_suspended has the same problem: it is set when servicing removes the adev and is cleared only by a matching resume. A reset while RDMA is suspended re-adds the adev but leaves is_suspended set, so a later resume event calls add_adev() on top of a live gd->adev and leaks it. This is currently masked by the rdma_teardown bug. Clear both in mana_rdma_probe(). On the reset path mana_rdma_remove() has closed the gate and drained the service workqueue, so clear is_suspended first and re-open the gate with smp_store_release(), paired with smp_load_acquire() in the handler, so the handler cannot observe an open gate with a stale is_suspended. On the initial probe path the gate was never closed and both flags are already clear. This does not order gd->adev, which add_adev() publishes afterwards. A servicing event arriving in that window is still dropped, as it is in mainline today on the initial probe path; closing it needs probe and the handler to be serialized and is left to a separate change. Fixes: 505cc26bcae0 ("net: mana: Add support for auxiliary device servicing events") Signed-off-by: Long Li Link: https://patch.msgid.link/20260902175153.3410560-1-longli@microsoft.com Signed-off-by: Jakub Kicinski commit f4c3e38111fd84c2c7ae5785755f4a4d476e1cba Author: Miguel Ojeda Date: Tue Sep 8 19:05:39 2026 +0200 rust: allow `unknown_lints` in generated bindings for Rust < 1.88 Starting with bindgen 0.73.2 [1], `#[allow(unnecessary_transmutes)]` are used, even when `--rust-target 1.85` is passed. However, the lint was introduced in Rust 1.88.0. Thus building with older Rust versions warns like: error: unknown lint: `unnecessary_transmutes` --> rust/uapi/uapi_generated.rs:26294:13 | 26294 | #[allow(unnecessary_transmutes)] | ^^^^^^^^^^^^^^^^^^^^^^ | = note: `-D unknown-lints` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unknown_lints)]` Thus allow `unknown_lints` in the generated bindings -- only when building with older Rust versions. I have asked upstream if this is intentional [1], i.e. if we are supposed to always allow unknown lints in case `bindgen` uses such attributes, or whether it is an oversight. [ Emilio said it wasn't intentional -- we will work around it for now on the kernel side. - Miguel ] Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Emilio Cobos Álvarez Link: https://github.com/rust-lang/rust-bindgen/pull/3455#issuecomment-5588526559 [1] Assisted-by: LLM Link: https://patch.msgid.link/20260908170539.345207-1-ojeda@kernel.org [ Removed the `cfg` for `allow(unnecessary_transmutes)` as suggested by Gary. - Miguel ] Signed-off-by: Miguel Ojeda commit c93922dd316b7273a8667d29084632066fa8a2d3 Author: Jiajia Liu Date: Fri Sep 4 16:03:51 2026 +0800 Bluetooth: btusb: Fix leaked runtime PM reference in btusb_reset btusb_reset calls usb_autopm_get_interface to resume the device before queuing a reset of it, but never calls the matching usb_autopm_put_interface. usb_queue_reset_device ends up in usb_reset_device(), and since btusb provides no pre_reset/post_reset callbacks the interface is merely unbound and rebound: the interface device object survives this cycle, and so does its PM usage count, which is not cleared when the driver is unbound. As a result every reset permanently leaks a PM usage reference, preventing the interface from being runtime suspended again until it is unbound. Set BTUSB_RESET flag before usb_queue_reset_device so that btusb_disconnect drops the reference. If the flag is already set, drop one reference. Fixes: c9209b269afd ("Bluetooth: btusb: Introduce generic USB reset") Assisted-by: Claude:qwen3.8-max Signed-off-by: Jiajia Liu Signed-off-by: Luiz Augusto von Dentz commit e486a891c412d9d82ee865987f4eead6196e1f96 Author: Jiajia Liu Date: Fri Sep 4 16:03:50 2026 +0800 Bluetooth: btusb: mediatek: Fix leaked runtime PM reference in reset MT7925 on HP Pro Mini 260 sometimes timed out during reloading driver and reset usb device. btusb_suspend is not called again after closing bluetooth interface. usbcore: registered new interface driver btusb Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20260605184935 Bluetooth: hci0: Execution of wmt command timed out Bluetooth: hci0: Failed to send wmt patch dwnld (-110) Bluetooth: hci0: Failed to set up firmware (-110) usb 3-10: reset high-speed USB device number 4 using xhci_hcd Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20260605184935 Bluetooth: hci0: Device setup in 1856545 usecs Bluetooth: hci0: AOSP extensions version v1.00 Bluetooth: hci0: AOSP quality report is supported Bluetooth: MGMT ver 1.23 btusb_mtk_reset calls usb_autopm_get_interface to resume the device before driving the hardware reset, but never calls the matching usb_autopm_put_interface. Every hardware reset therefore leaks a PM usage reference of the interface, preventing the device from being runtime suspended again until it is unbound. Add the BTUSB_RESET flag. It is set before usb_queue_reset_device and is cleared in btusb_disconnect, which drops the reference as well. If the flag is already set when a new reset is requested, drop one reference. Also clear BTMTK_HW_RESET_ACTIVE if usb_autopm_get_interface fails, otherwise no further reset could ever be attempted. Fixes: 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work") Assisted-by: Claude:qwen3.8-max Signed-off-by: Jiajia Liu Signed-off-by: Luiz Augusto von Dentz commit f5a427b16e45210dee656b0860728f3d496dee85 Author: Xu Rao Date: Fri Sep 4 10:54:57 2026 +0800 Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev The command and ACL RPMsg endpoints store struct btqcomsmd as their callback private data. The receive callbacks dereference btq->hdev without taking an hci_dev reference. The current teardown order frees the hci_dev before destroying the RPMsg endpoints in both the hci_register_dev() error path and the driver remove path. If WCNSS delivers data in that window, the endpoint callback can run with an already freed hci_dev and pass it to the Bluetooth core. For qcom_smd endpoints, rpmsg_destroy_ept() closes the channel and clears the callback under the channel recv_lock. The receive path holds the same lock while invoking the callback, so destroying the endpoints first both prevents new callbacks and serializes with any callback already running. Destroy the command and ACL endpoints before hci_free_dev(). Keep hci_unregister_dev() first during remove so the HCI core stops issuing operations before the transport endpoints are shut down. In the full registration-error cleanup path, return directly after freeing the hci_dev to avoid falling through to the partial-construction labels and destroying the endpoints twice. Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg") Fixes: 9a39a927be01 ("Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the probe function") Cc: stable@vger.kernel.org Acked-by: Bartosz Golaszewski Reviewed-by: Dmitry Baryshkov Signed-off-by: Xu Rao Signed-off-by: Luiz Augusto von Dentz commit 9b851b09b392da68bd715601f10a5adb2d8d19b8 Author: Krystian Kaniewski Date: Fri Sep 4 12:24:22 2026 +0000 Bluetooth: hci_sysfs: Fix NULL pointer dereference in device_del() A NULL pointer dereference in klist_put() occurs when a child device (such as a BNEP network device in bnep_session) is concurrently being unregistered while hci_conn_del_sysfs() reparents child devices. This is caused by a race condition between hci_conn_del_sysfs() and concurrent child device unregistration (e.g. bnep_session calling unregister_netdev()). During device unregistration, device_del() snapshots a non-NULL parent pointer. Concurrently, hci_conn_del_sysfs() finds the child device using device_find_any_child() and calls device_move() to reparent it to NULL, which removes the node from its parent's klist and clears knode_parent. Subsequently, device_del() calls klist_del(&dev->p->knode_parent) using the stale parent snapshot, causing klist_put() to dereference knode_klist(n)->put on an already removed node, resulting in a NULL pointer dereference. This race was introduced by commit 27aabf27fd01 ("Bluetooth: fix use-after-free in device_for_each_child()"), which replaced device_find_child(..., __match_tty) with device_find_any_child() in hci_conn_del_sysfs(). That change was intended to avoid a use-after-free where conn->dev outlived its parent hdev->dev when child devices held references to conn->dev, because conn->dev only held a reference to hdev->dev while registered in sysfs. Fix the issue properly by taking an explicit reference to the parent device with get_device(&hdev->dev) in hci_conn_init_sysfs() and dropping it with put_device(parent) in bt_link_release() when the conn device is freed. This ensures that hdev->dev remains valid for the entire lifecycle of conn->dev, resolving the underlying use-after-free. With the parent reference held properly, restore the __match_tty filter in hci_conn_del_sysfs() so that device_move() is only invoked on persistent RFCOMM TTY devices as originally intended, eliminating the race condition with unregistering network devices. Fixes: 27aabf27fd01 ("Bluetooth: fix use-after-free in device_for_each_child()") Assisted-by: Gemini:gemini-3.7-flash syzbot Reported-by: syzbot+6df45dd3d03e1a9aca96@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6df45dd3d03e1a9aca96 Link: https://syzkaller.appspot.com/ai_job?id=f1c0e740-db21-40af-a9ff-84db0fd8b8bd Signed-off-by: Krystian Kaniewski Signed-off-by: Luiz Augusto von Dentz commit 3d8a8e81ea8ad8813d4c82a12ba53ecb597b217d Author: Ivan Hu Date: Fri Sep 4 13:30:07 2026 +0800 Bluetooth: btmtk: Declare MT7920 (MT7961 1a) Bluetooth firmware btmtk_fw_get_filename() constructs the firmware name at runtime, so for the MT7920 variant (dev_id 0x7961 with fw_flavor set) it requests "mediatek/BT_RAM_CODE_MT7961_1a_2_hdr.bin" without ever declaring it via MODULE_FIRMWARE(). Tools that select firmware from module metadata (e.g. "modinfo -F firmware") therefore omit this blob, so request_firmware() fails and Bluetooth does not initialise on MT7920, even though the file is present in linux-firmware. Declare it with MODULE_FIRMWARE(), as the mt76 driver already does for the corresponding MT7920 wifi firmware. Fixes: 1cb63d80fff6 ("Bluetooth: btusb: Add support Mediatek MT7920") Signed-off-by: Ivan Hu Signed-off-by: Luiz Augusto von Dentz commit 3621f78d43b0a9563d5ade68370434c532eea259 Author: Luiz Augusto von Dentz Date: Wed Sep 2 13:16:26 2026 -0400 Bluetooth: hci_sync: Fix not setting CE length properly Both hci_le_set_def_rate_sync() and hci_le_conn_rate_request_sync() were leaving Min_CE_Length and Max_CE_Length set to 0x0000, but the connection event length recommended in requests by a Peripheral has a valid range of 0x0001 to 0x7CFF (Time = N * 125 us, Time Range: 0.125 ms to 3.999875 s), so 0x0000 cannot be used. Set both to the minimum valid value, which is safe since the Controller is not required to use these values: BLUETOOTH CORE SPECIFICATION Version 6.2 | Vol 4, Part E 7.8.157. LE Connection Rate Request command 7.8.158. LE Set Default Rate Parameters command The Min_CE_Length and Max_CE_Length parameters provide the Controller with the expected minimum and maximum length of the connection events. The Controller is not required to use these values. Fixes: 2f8784cfe8a9 ("Bluetooth: Add support for Shorter Connection Interval (SCI) feature") Signed-off-by: Luiz Augusto von Dentz commit 3dd1b41f96aad08444be1b7626c89de2b9f2abd4 Author: Kiran K Date: Thu Sep 3 20:21:02 2026 +0530 Bluetooth: btintel_pcie: fix tx_handle bounds off-by-one Valid indices into txq->urbd0s/tfds/bufs are 0..txq->count-1, so tfd_index == txq->count is already out of range. Change the guard in btintel_pcie_msix_tx_handle() from '> txq->count' to '>= txq->count'. This issue was reported by Claude Mythos. Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz commit 6436e1b5331b1aebf905c13e0880a37032719b75 Author: Kiran K Date: Thu Sep 3 20:21:01 2026 +0530 Bluetooth: btintel_pcie: validate packet_len before skb_put_data btintel_pcie_submit_rx_work() reads packet_len from rfh_hdr without checking if it exceeds the RX buffer size. An oversized packet_len can lead to an out-of-bounds read in skb_put_data(). Validate packet_len to ensure it is non-zero and does not exceed BTINTEL_PCIE_BUFFER_SIZE - sizeof(*rfh_hdr), logging an error when invalid. This issue was reported by Claude Mythos. It can be simulated either by using customized firmware configured to return an invalid packet_len or by modifying rfh_hdr->packet_len in the driver before calling btintel_pcie_submit_rx_work(). Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz commit 83e3e515fd261600ed8491fb0a8bcdfb115c904e Author: Rong Zhang Date: Thu Sep 3 03:18:59 2026 +0800 Bluetooth: btrtl: Don't leak return code when parsing firmware format v2 When key_id from chip is zero, rtlbt_parse_firmware_v2() intentionally ignores all security headers. However, the implementation simply breaks from a switch statement and leaks uninitialized return code `rc' (if the first section is a security one) or the previous section's `rc'. Fix it by really skipping a loop with `continue'. For consistency and readability, also do the same for the default case. Fixes: 9a24ce5e29b1 ("Bluetooth: btrtl: Firmware format v2 support") Cc: stable@vger.kernel.org Signed-off-by: Rong Zhang Signed-off-by: Luiz Augusto von Dentz commit 1c12c3117639e78940959d956519c758c57d0849 Author: Luiz Augusto von Dentz Date: Mon Aug 31 12:13:10 2026 -0400 Bluetooth: btusb: Fix UAF of btusb_data by rx_work btusb_close() and btusb_flush() cancel data->rx_work with the asynchronous cancel_delayed_work(), so if btusb_rx_work() is already running on another CPU it keeps running after the cancel returns. btusb_disconnect() calls hci_unregister_dev(), which invokes btusb_close(), and then frees the btusb_data. A still running btusb_rx_work() then dereferences the freed data: while ((skb = skb_dequeue(&data->acl_q))) data->recv_acl(data->hdev, skb); Use cancel_delayed_work_sync() instead. In btusb_close() the cancel also has to happen after btusb_stop_traffic(), otherwise an URB completion racing with the cancel can requeue the work right after it has been waited for. Fixes: 800fe5ec302e ("Bluetooth: btusb: Add support for queuing during polling interval") Signed-off-by: Luiz Augusto von Dentz commit dcaf83ead130d3067862599089b0999b3da140a4 Author: Rong Zhang Date: Wed Sep 2 02:19:18 2026 +0800 Bluetooth: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform It is reported that a remote wakeup could cause MT7922/MT7925's btusb interface completely unresponsive. Resetting the xHCI root hub doesn't help at all, and recovering from such a state needs a power cycle. All reports seen to be relevant to Ryzen-based laptops. These NICs are usually used as OEM components thanks to some sort of reference designs. Their popularity on other platforms is unclear. While there is still a chance that the quirk may exist on other platforms, be cautious and only apply the quirk to direct children of Ryzen platforms's root hubs for the time being. In most cases the root hub is on the SoC or PCH, which needs the quirk. Unfortunately, this can't distinguish root hubs on PCIe add-in cards. Such roughness should be acceptable, as PCIe USB controller add-in cards are less commonly used nowadays. On the other hand, applying the quirk doesn't hurt any functionalities either, as the device can still be used as a wakeup source if desired. Theoretically, we could retrieve the root hub's PCI vendor ID with some hierarchy magic, but that's too intrusive... Meanwhile, though device_set_wakeup_capable(false) is the correct fix for other NICs with fake remote wakeup capabilities, doing so for MT7922/MT7925 effectively prevents it from being used as wakeup sources as per userspace requests. Hence, return -EBUSY on runtime suspend to prevent the interface from being autosuspended while it's still opened, which has the same effect as device_set_wakeup_capable(false), since disabling remote wakeup simply causes the USB core to gate runtime autosuspend as well due to needs_remote_wakeup == 1. The interface can be safely autosuspended as long as remote wakeup is disabled, i.e., after closing the HCI device. Specifically, the interface may still take the advantage of remote wakeup in order to wake up the system from sleep if userspace has enabled it as a wakeup source. Fixes: e31d761628ad ("Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925") Tested-by: Rafael Passos Signed-off-by: Rong Zhang Signed-off-by: Luiz Augusto von Dentz commit 1b8e56030d52cd3e52c9ad4df1985ad0440be67d Merge: e0554c6276da95 7a099b347fef53 Author: Jakub Kicinski Date: Tue Sep 8 13:53:16 2026 -0700 Merge tag 'nf-26-09-07' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Pablo Neira Ayuso says: ==================== Netfilter/IPVS fixes for net The following patchset contains Netfilter/IPVS fixes for net: 1) Reject malformed messages in IPVS sync, from Kyle Zeng. 2) Fix possible stale infoleak in IPVS sync, also from Kyle Zeng. 3) Out-of-bound read in the SIP conntrack helper, from Joas Antonio dos Santos. 4) UaF on cttimeout module removal, from Chengfeng Ye. 5) Unregister nf_loggers before netns teardown to fix UaF, also from Chengfeng Ye. 6) Fix race in nfnetlink_log due to concurrent instance destruction, from Florian Westphal. 7) Remove arp_table 32bit compat interface, this is already off in many distributions, from Florian Westphal. 8) Set IP6T_F_PROTO flag is e->ipv6.proto is set on to deal with insufficient validation of xtables extensions when used from legacy ip6tables, from Florian. 9) Set on the NLM_F_DUMP_FILTERED flag when all is filtering out in ctnetlink, from Ilya Maximets. * tag 'nf-26-09-07' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: report NLM_F_DUMP_FILTERED when all is filtered out netfilter: ip6_tables: set F_PROTO when proto value is nonzero netfilter: arp_tables: remove the 32bit compat interface netfilter: nfnetlink_log: cope with concurrent instance destruction netfilter: nf_log: unregister loggers before per-net teardown netfilter: cttimeout: prevent UAF during module unload netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() ipvs: fix reversed sequence option serialization ipvs: reject invalid states in connection template sync records ==================== Link: https://patch.msgid.link/20260907171732.1407739-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski commit b8bf9bfda5f62e11444e483c2b4aaff90c5cfc6b Author: Jakub Kicinski Date: Thu Aug 20 19:02:01 2026 -0700 eth: ice: don't dereference pointers from TP_printk() After forwarding net-next during the v7.3 merge window we started seeing: TRACE EVENT ERROR: Event ice_tx_dim_work has double dereference in TP_printk: REC->q_vector->tx.tx_ring->q_index WARNING: kernel/trace/trace_events.c:420 at test_double_dereference.cold+0x39/0x4b this is due to extra checks added in tracing subsystem in commit b5cc230af5e5 ("tracing: Warn when an event dereferences a pointer in TP_printk()"). Printing happens long after the event was recorded, by which point the pointers may be invalid (the ring or the dim instance). Copy the eight scalars into the event instead. Fixes: 3089cf6d3caa ("ice: add tracepoints") Signed-off-by: Jakub Kicinski Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen commit 53432c4c3e869076350aef319534431af8ba99c1 Author: Jacob Keller Date: Mon Jul 6 16:31:17 2026 -0700 ice: add missing xa_destroy for sched_node_ids Commit 16dfa49406bc ("ice: Introduce new parameters in ice_sched_node") added a sched_node_ids xarray to the port info structure, but never called xa_destroy on it. Since xarrays can allocate internal memory, this can result in a memory leak even if every element in the xarray has been removed. The xarray is currently embedded in the port_info structure. This appears to have been done because its use is within functions that take the port_info as a primary argument. However, this complicates managing the lifecycle of the field. The port_info structure is allocated in ice_init_hw() using devm, and it is not released until the devm cleanup when the driver is unloaded. The ice_init_hw() function is called in many places, including devlink reload, and possibly during DDP load after updating the Tx scheduler layout. Adding a call of xa_destroy to the ice_deinit_hw() causes Sashiko to raise multiple concerns due to potential ordering issues and possible ways that port_info could be a dangling reference. To handle this, move the sched_node_ids out of port_info and into the hw structure. All users of the array already have a pointer to hw anyways, and there is only one sched_node_ids per adapter. While here, remove the overly verbose comment explaining the nature of the sched_node_ids xarray. Add the missing xa_destroy to the cleanup path and to ice_deinit_hw(), ensuring that we properly release the xarray memory. This was caught by Sashiko during development of unrelated code. Fixes: 16dfa49406bc ("ice: Introduce new parameters in ice_sched_node") Signed-off-by: Jacob Keller Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen commit cc6d60ef92278a31ffc2e94966a0921b9646af18 Author: Joshua Hay Date: Mon Jul 27 16:08:48 2026 -0700 idpf: account for VLAN header when parsing RSC packet header While parsing the header of a Receive Side Coalesced (RSC) packet, check if a VLAN tag is present and adjust the header parsing accordingly. Otherwise, Rx TCP traffic is completely broken for any VLAN interface whose underlying interface has RSC (rx-gro-hw) enabled. We only need to worry about one VLAN header since Rx packets with multiple VLAN headers are not candidates for RSC. Fixes: 3a8845af66edb ("idpf: add RX splitq napi poll support") Signed-off-by: Joshua Hay Reviewed-by: Emil Tantilov Reviewed-by: Aleksandr Loktionov Tested-by: Samuel Salin Signed-off-by: Tony Nguyen commit 650f197d8ea6ebbc9ce1c9fb0358258b65e74291 Author: Myeonghun Pak Date: Mon Jul 20 23:35:10 2026 +0900 idpf: disable PTM on probe failure and on remove idpf_probe() enables PCIe Precision Time Measurement with pci_enable_ptm(), which takes a reference on the device and on every PTM-capable device up the path to the PTM Root. Neither the probe error path nor idpf_remove() drops that reference, so the PTM enable counts of this device and of its upstream path stay elevated with no bound driver, and the device's PTM control bits remain set. pcim_enable_device() only arranges for pci_disable_device() and does not undo the PTM enable. Add the matching pci_disable_ptm() to the common unwind path. pci_enable_ptm() failure is not fatal here, so guard the call with pcie_ptm_enabled(): pci_disable_ptm() decrements dev->ptm_enable_cnt unconditionally and then recurses upstream, so calling it after a failed enable would drive this device's count negative and wrongly decrement parents shared with other endpoints. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 8d5e12c5921c ("idpf: add initial PTP support") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Aleksandr Loktionov Tested-by: Samuel Salin [TN moved call due to commit 6b284aa2ddf3 ("idpf: refactor idpf to use libie_pci APIs")] Signed-off-by: Tony Nguyen commit 7dd4c829bac2916be98a3e34b41daaba7f42b4c4 Author: Myeonghun Pak Date: Mon Jul 20 22:58:46 2026 +0900 idpf: disable DIM work before freeing q_vectors idpf never drains the Tx/Rx DIM works before freeing the memory they live in. tx_dim and rx_dim are embedded in struct idpf_q_vector, they are queued from the NAPI poll via net_dim(), and idpf_vport_intr_rel() ends with kfree(rsrc->q_vectors). Nothing in the driver cancels them. idpf_tx_dim_work() and idpf_rx_dim_work() then run on freed memory: idpf_vport_intr_write_itr() writes the ITR register through q_vector->intr_reg.tx_itr / rx_itr, void __iomem pointers loaded out of the freed q_vector. No configuration is needed to get there -- IDPF_ITR_IS_DYNAMIC() is defined as (itr_mode) and idpf_vport_alloc() initialises both modes to IDPF_ITR_DYNAMIC. Draining after idpf_vport_intr_napi_dis_all() is not enough on its own. idpf_net_dim() is called from inside the "if (napi_complete_done(napi, work_done))" branch of the poll, and napi_complete_done() has already cleared NAPIF_STATE_SCHED by then. napi_disable_locked() waits only while (val & (NAPIF_STATE_SCHED | NAPIF_STATE_NPSVC)), so napi_disable() can return while the poll tail is still queueing the work, and a plain cancel_work_sync() would be re-armed behind the drain. Use disable_work_sync(): schedule_work() on a work with a non-zero disable count is dropped by clear_pending_if_disabled() before __queue_work() is reached. Move idpf_init_dim() to idpf_vport_intr_alloc() so the works are initialised on every path that can reach the drain -- the three "goto intr_deinit" sites between idpf_vport_intr_init() and idpf_vport_intr_ena() get there without the enable side having run. Nothing re-enables them: rsrc->q_vectors is freed on every exit from idpf_vport_open() and on every idpf_vport_stop(), so the count dies with the object. It is a race, not a deterministic failure -- net_dim() only schedules once DIM_NEVENTS events have accumulated and the profile index changes. A KASAN ifup/ifdown loop under load is the way to see it. Fixes: c2d548cad150 ("idpf: add TX splitq napi poll support") Fixes: 3a8845af66ed ("idpf: add RX splitq napi poll support") Cc: # see patch description, needs adjustments for <= 6.9 Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Tested-by: Samuel Salin Signed-off-by: Tony Nguyen commit 8544e0da1a04c77b98e2e313a423a5c72e48ea32 Merge: cee9395acd8043 3bb3e80faf21e4 44caf1844a2585 Author: Sudeep Holla Date: Tue Sep 8 21:04:42 2026 +0100 Merge branches 'for-next/ffa/fixes' and 'for-next/scmi/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux * 'for-next/ffa/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_ffa: Tear down driver during shutdown * 'for-next/scmi/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Fix typo "upto" in comment clk: scpi: use PLATFORM_DEVID_NONE for scpi-cpufreq clk: scpi: register scpi-cpufreq once and clear on failure clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS firmware: arm_scpi: fix device_node leak in scpi_dev_domain_id commit 893e11787f78e43b534e252249ac3fff4d1333f8 Merge: 5acbae5f7eb3d5 d2929113b15bfc Author: Linus Torvalds Date: Tue Sep 8 12:54:56 2026 -0700 Merge tag 'x86_urgent_for_7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Dave Hansen: "These are fixes for some older AMD device topology and machine check issues. But, they are issues that are affecting real users and aren't just cleaning up AI drive-by reports. These is coming a wee bit later than the usual Sundays because of a late breaking issue with one of the patches which is now temporarily kicked out" * tag 'x86_urgent_for_7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/MCE/AMD: Fix inverted interrupt enablement during storm handling x86/amd_node: Fix potential NULL pointer dereference x86/amd_node: Avoid divide by zero on virtualized systems commit dd519eb8f66eaa205bbbdcb753588138a1d18414 Author: Hans de Goede Date: Tue Sep 8 20:55:17 2026 +0200 platform/x86: x86-android-tablets: fix gpio_secondary_fwnode_init() not working acpi_bus_find_device_by_name() call returns a pointer to the device object on the ACPI bus, aka the ACPI companion device. gpio_secondary_fwnode_init() then continues with setting the secondary fwnode on this device. But this is not the actual physical device for the GPIO controller (e.g. the GPIO controller platform bus device). This mismatch is causing GPIO lookups by secondary fwnode to not work. Modify gpio_secondary_fwnode_init() to instead set the secondary fwnode of the first physical device associated with the ACPI companion device. This fixes the GPIO lookups not working. Fixes: 1448c2d2ca5c ("platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips") Reviewed-by: Dmitry Torokhov Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20260908185517.49047-1-johannes.goede@oss.qualcomm.com Signed-off-by: Ilpo Järvinen commit 0f70fd6f4c1d6c1f2ea298d8dd07c4a4d5dff9af Author: Conor Dooley Date: Fri Sep 4 18:22:55 2026 +0100 riscv: dts: microchip: beaglev-fire: remove double definition of gpio interrupts When the irq-mux and its interrupt-map were added to the mpfs devicetree, the gpio interrupts became fixed at the SoC level rather than dependant on the design - the interrupt-map is now what varies. The beaglev-fire should have had its dts copy of the interrupts removed but did not. As a result, the mcp3564 driver does not probe, because even though it doesn't use the interrupt at present, the SPI core still looks it up. This lookup fails because the second copy of the interrupts property doesn't resolve to something valid when passed via the interrupt-map. Remove the second/incorrect set of interrupts properties. Fixes: b0258f69f1e0 ("riscv: dts: microchip: update mpfs gpio interrupts to better match the SoC") CC: stable@vger.kernel.org Signed-off-by: Conor Dooley commit 8b0cc8707f65e0f51912e764e1b309b2559db1ec Author: Xu Rao Date: Tue Aug 18 19:31:53 2026 +0800 mmc: spi: reset bytes_xfered before retrying CRC failures mmc_spi_data_do() updates data->bytes_xfered after each block has been transferred successfully. If a later block in the same data request fails with a CRC error, data->bytes_xfered may therefore contain the number of bytes completed before the failing block. mmc_spi_request() has a private recovery path for such CRC failures. It sends STOP_TRANSMISSION, clears data->error and jumps back to crc_recover to issue the same command and data request again. However, it does not clear data->bytes_xfered before the retry. If the retry succeeds, the request is completed with the bytes from the failed attempt still included in data->bytes_xfered. For a multi-block request this can make the completed request report more bytes than were transferred by the successful retry, and can even exceed the request size when most blocks completed before the CRC error. This is most likely to be observed on MMC-over-SPI systems where long multi-block transfers occasionally hit a data CRC error but the mmc_spi-internal retry succeeds. The data itself is retried, but the completion accounting is not. Clear data->bytes_xfered together with data->error before repeating the request so the final completion reports only the bytes transferred by the successful attempt. Fixes: 061c6c847eeb ("mmc_spi: Recover from CRC errors for r/w operation over SPI.") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Ulf Hansson commit 159720704d9d652b64390c11fb971e15b0a78d23 Author: Sunil Khatri Date: Tue Sep 8 14:47:29 2026 +0530 drm/drm_exec: fix up contended obj when num_objects is 0 drm_exec_prepare_array() silently returns success without calling drm_exec_lock_contended() when num_objects is zero. This breaks the invariant upheld by drm_exec_lock_obj(), where every entry point into the locking sequence must first attempt to lock any previously contended object before proceeding. Drivers that chain multiple drm_exec_prepare_array() calls per drm_exec_until_all_locked() iteration (e.g. amdgpu's userq signal/wait ioctls, which prepare separate read and write BO arrays) can pass an empty array for one of the two calls. If contention is hit while preparing the non-empty array, exec->contended is set and the loop retries; on retry, the empty-array call preceding it is a no-op that never clears exec->contended, so drm_exec_retry_on_contention() immediately jumps back to the top of the loop without ever reaching the call that would resolve the contention. This spins forever. Fix it by having drm_exec_prepare_array() call drm_exec_lock_contended() directly when num_objects is zero, so a pending contended object dont loop infinitely. Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") CC: stable@vger.kernel.org # v6.6+ Signed-off-by: Sunil Khatri Link: https://lore.kernel.org/r/20260908091729.2749399-1-sunil.khatri@amd.com Reviewed-by: Christian König Signed-off-by: Christian König commit f77de4c33f0edbb33411f92a35d7196965597e6d Author: Jia Wang Date: Mon Sep 7 17:54:44 2026 +0800 spi: dt-bindings: snps,dw-apb-ssi: Add compatible for UltraRISC DP1000 SoC Add the SoC-specific compatible string and use the generic one as fallback for the UltraRISC DP1000 SPI controller. The DP1000 integrates two SPI controllers. SPI0 supports standard, dual and quad transfers with three native chip-select signals. SPI1 supports standard transfers with four native chip-select signals. Both controllers have one register range and separate reference and APB interface clocks. Signed-off-by: Jia Wang Acked-by: Conor Dooley Link: https://patch.msgid.link/20260907-ultrarisc-dts-v2-5-5eb4c97477c5@ultrarisc.com Signed-off-by: Mark Brown commit 5acbae5f7eb3d5275120abfe698c394b7325dcec Merge: 7daadf5131ed48 45a5f7285f835a Author: Linus Torvalds Date: Tue Sep 8 07:59:12 2026 -0700 Merge tag 'powerpc-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Madhavan Srinivasan: - Clear TIF_SYSCALL_RET before syscall error return - Don't drop _TIF_RESTOREALL on syscall restart - Do not restore KUAP in arch_exit_to_user_mode_prepare() - pci-ioda: Fix the stale irq chip reference - Use inclusive range checks in add_usable_mem() and excluded memory - Fix irq_soft_mask corruption on replayed interrupt exit - MAINTAINERS: powerpc: Add Ritesh and Shrikanth - Misc fixes and cleanups Thanks to Amit Machhiwal, Christophe Leroy (CS GROUP), Gautam Menghani, Harsh Prateek Bora, Jiangshan Yi, Mukesh Kumar Chaurasiya (IBM), Ritesh Harjani (IBM), Shivaprasad G Bhat, Shrikanth Hegde, Sourabh Jain, Tasmiya Nalatwad, Thorsten Blum, and Venkat Rao Bagalkote. * tag 'powerpc-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: MAINTAINERS: powerpc: Add Ritesh and Shrikanth powerpc/ps3: Fix repository.c build failure powerpc/entry: Fix irq_soft_mask corruption on replayed interrupt exit powerpc/pseries/pci: Fix misleading VF limit error message powerpc/kexec_file: Use inclusive range checks for excluded memory powerpc/kexec: Simplify kdump_extra_elfcorehdr_size() powerpc/kexec_file: Use inclusive range checks in add_usable_mem() powerpc/rtas_pci: No hotplug on permanently removed device on pSeries powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver powerpc: pci-ioda: Fix the stale irq chip reference powerpc: Do not restore KUAP in arch_exit_to_user_mode_prepare() powerpc: Don't drop _TIF_RESTOREALL on syscall restart powerpc/entry: Clear TIF_SYSCALL_RET before syscall error return commit 7e125889f1705fc6326679a3db3b4159f7a8c87e Author: Yorick Rommers Date: Mon Sep 7 14:12:28 2026 +0200 ASoC: amd: acp-da7219-max98357a: don't bind on Raven/Picasso boards The "AMDI5682" ACPI HID is matched by two AMD ASoC machine drivers: cz-da7219-max98357a (this driver, Carrizo/Stoney) and acp3x-alc5682-max98357 (Raven/Picasso). cz-da7219-max98357a is linked first and probes the platform device first; its DAI links reference the Stoney ACP, which is absent on Raven/Picasso, so its card can never be instantiated there. This was harmless until commit 42d99857d6f0 ("ASoC: core: Move all users to deferrable card binding"): devm_snd_soc_register_card() now returns 0 for a card left pending instead of propagating -EPROBE_DEFER, so cz_probe() succeeds and permanently binds AMDI5682. acp3x-alc5682-max98357 never binds and the internal speakers and headphone jack get no card. Detect Raven/Picasso (and later) by the ACP3.x audio coprocessor's dedicated PCI function (1022:15e2); Carrizo/Stoney reach the ACP through the GPU driver and have no such device. Return -ENODEV so the driver core continues probing AMDI5682 with acp3x-alc5682-max98357. Fixes: 42d99857d6f0 ("ASoC: core: Move all users to deferrable card binding") Cc: stable@vger.kernel.org Signed-off-by: Yorick Rommers Tested-by: Yorick Rommers Link: https://patch.msgid.link/20260907121228.13754-1-yorick-rommers@hotmail.com Signed-off-by: Mark Brown commit 7daadf5131ed488037cc4540797e53c7f2c5d3ec Merge: 28924df2a08f44 60892a384aa1e6 Author: Linus Torvalds Date: Tue Sep 8 07:55:40 2026 -0700 Merge tag 'v7.3-p3' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This adds missing vzeroupper instructions to x86/aria" * tag 'v7.3-p3' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: x86/aria - add missing vzeroupper in AVX-512 code crypto: x86/aria - add missing vzeroupper in AVX2 code commit 6bd360447941357e959414a525aa62576a448116 Author: Paulo Alcantara Date: Sun Sep 6 16:01:24 2026 -0300 smb: client: fix file type corruption in cifs_reparse_point_to_fattr() Setting the file type in cf_mode without clearing the existing S_IFMT bits first is wrong as it corrupts the file type when cf_mode already has type bits set (e.g. S_IFREG | S_IFLNK == S_IFDIR | S_IFREG). Clear S_IFMT before setting S_IFLNK for native and SMB1 symlinks. 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 commit 65d5dbdc089be42fc48a6f77bc6b648307f34b17 Author: Paulo Alcantara Date: Sun Sep 6 16:01:16 2026 -0300 smb: client: fix file type corruption in posix_reparse_to_fattr() Setting the file type in cf_mode without clearing the existing S_IFMT bits first is wrong as it corrupts the file type when cf_mode already has type bits set (e.g. S_IFREG | S_IFCHR == S_IFLNK). Use a local ftype variable to collect the new file type and apply it after validation succeeds, clearing S_IFMT and setting the new type in a single assignment. This avoids stripping cf_mode on malformed reparse points where the function returns false early. Closes: https://sashiko.dev/#/patchset/20260906172005.627163-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 commit fa7a2cfcf1e6117fc478cae6809c66c518740969 Author: Paulo Alcantara Date: Sun Sep 6 16:01:04 2026 -0300 smb: client: fix file type corruption in wsl_to_fattr() Setting the file type in cf_mode without clearing the existing S_IFMT bits first is wrong as it corrupts the file type when cf_mode already has type bits set (e.g. S_IFREG | S_IFCHR == S_IFLNK). Clear S_IFMT before the switch statement. Closes: https://sashiko.dev/#/patchset/20260906172005.627163-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 commit da6e25842431982d5a53cf00d925b98c690f4467 Author: Paulo Alcantara Date: Sun Sep 6 14:40:39 2026 -0300 smb: client: avoid using uninitialized SIDs in cifs_posix_to_fattr() 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 commit cd2b2b57921d4caa7875e83198bb2aa71254328b Author: Paulo Alcantara Date: Sun Sep 6 14:40:23 2026 -0300 smb: client: fix WSL reparse point uid/gid override wsl_to_fattr() unconditionally overwrites cf_uid/cf_gid with values from WSL extended attributes ($LXUID/$LXGID), ignoring the forceuid and forcegid mount options. Fix this by initializing cf_uid/cf_gid to the mount defaults and gating the $LXUID/$LXGID EA parsing on forceuid/forcegid. Closes: https://sashiko.dev/#/patchset/20260906190803.667489-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 commit 18a72975e9f35aadecc75b031f693f2d1f49308f Author: Paulo Alcantara Date: Sun Sep 6 14:40:04 2026 -0300 smb: client: honor forceuid/forcegid when mapping SIDs to uid/gid 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 commit cf4d35896621b7298eef51b7a465e5c0cb22f670 Author: Paulo Alcantara Date: Sun Sep 6 14:39:44 2026 -0300 smb: client: fix uid/gid override in getattr with posix extensions When mounting with 'multiuser,posix' options, cifs_getattr() overrides the server-provided uid/gid with the current process's fsuid/fsgid. This is because the condition only checks for unix extensions (tcon->unix_ext) but not posix extensions (tcon->posix_extensions). With SMB3 POSIX extensions, the server provides real uid/gid values just like with unix extensions, so they should be preserved rather than replaced with the caller's credentials. Add a tcon->posix_extensions check to the condition so that uid/gid from the server are properly reported in stat results. Reported-by: Arthur Lesuisse Closes: https://lore.kernel.org/r/DB9P190MB2012266F6B8DECBE5D26A1798DB52@DB9P190MB2012.EURP190.PROD.OUTLOOK.COM Suggested-by: Arthur Lesuisse 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 commit 7284788743121ec8bed556b00f830dc52ad9955d Author: HyeongJun An Date: Tue Sep 8 22:41:53 2026 +0900 ALSA: hda: Report a change when only the channel status bytes move The put() callback of "IEC958 Playback Default" returns whether the converted register value moved. The convert_from_spdif_status() helper reads part of the first two channel status bytes and none of the last two, while the get() callback returns all four. So a write that lands only in the bits it does not read changes what userspace reads back and reports no change. Of the 31 bits above the mode bit, 20 are such bits in consumer mode and 29 in professional mode. The core notifies only on a positive return. Toggling status[2] bit 0 on an HDA HDMI codec moves the read-back from 04 00 00 00 to 04 00 01 00 with no event. Toggling the non-audio bit in status[0] gives one. Compare the stored status as well, the way the ac97 code does. The write to the codec stays gated on the converted value. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-5 Link: https://patch.msgid.link/20260908134153.1614273-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai commit 71c610aeb1770302ac9c9e0b9a4ecd37f1311928 Author: Kazuki Hanai Date: Tue Sep 8 20:00:53 2026 +0900 ALSA: us122l: Prevent write upgrades for read mappings The hwdep mmap callback rejects read-buffer mappings that are initially writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ. A process that can open the hwdep node O_RDWR can later use mprotect() to make the mapping writable. The read allocation begins with struct usb_stream. Its read_size member is used by the fault handler to decide which pages belong to the read buffer. The read VMA intentionally remains expandable because pcm_usb_stream uses mremap() after reading that size. Changing read_size first can therefore map and access pages beyond the allocation. The same member is also consumed by usb_stream_free(), where changing it can make free_pages_exact() release pages outside the allocation. Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially writable VMA. This keeps the separate output-buffer mapping writable while preventing later permission upgrades. Fixes: 030a07e44129 ("ALSA: Add USB US122L driver") Cc: stable@vger.kernel.org Signed-off-by: Kazuki Hanai Link: https://patch.msgid.link/20260908110053.2950767-1-hnkz.64@gmail.com Signed-off-by: Takashi Iwai commit 126f16e0a1b353c2ba5c7e2c8626cfa865934f9f Author: Orgad Shaneh Date: Tue Sep 1 19:33:55 2026 +0000 MIPS: Octeon: apply USB FDT fixups also when USB is modular The uctl/usbn device-tree fixups in octeon_prune_device_tree() - which set the board's USB reference-clock frequency and type from __cvmx_helper_board_usb_get_clock_type() - are guarded by "#ifdef CONFIG_USB", which is false when USB is built as a module. The fixups then silently disappear and octeon-hcd sees whatever default the DTS carries (12MHz crystal in octeon_3xxx.dts), leaving the PHY dead or the bus erroring on boards with a different reference clock. Use IS_ENABLED() so USB=m gets the same fixups as USB=y. Fixes: 7fd57ab9d9cf ("MIPS: Octeon: Fix compile error when USB is not enabled.") Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh Signed-off-by: Thomas Bogendoerfer commit bbc448c541ed90d52f9ec22f17394304e3bf170e Author: Théo Lebrun Date: Fri Aug 28 16:07:33 2026 +0200 mips: select CONFIG_WEAK_REORDERING_BEYOND_LLSC from CONFIG_EYEQ On I6500 CPU cores, lld and scd give no ordering guarantees (same as all other instructions). To respect the assumption that arch_cmpxchg() is fully ordered, we must inject sync instructions above and below our lld/scd loops using the already in place WEAK_REORDERING_BEYOND_LLSC infrastructure. Otherwise, bad things can happen: [ 34.054496] CPU 3 Unable to handle kernel paging request at virtual address 0000000000000000, epc == a80000080838e01c, ra == a80000080838dfc4 [ 34.054559] Oops[#1]: [ 34.069561] CPU: 3 UID: 0 PID: 170 Comm: pipe_race Not tainted 7.2.0-rc6-01553-gb73c35220968-dirty #103 VOLUNTARY [ 34.079932] Hardware name: Mobile EyeQ5 MP5 Evaluation board [ 34.085592] $ 0 : 0000000000000000 0000000000000001 0000000000000000 0000000000000000 [ 34.093616] $ 4 : a800000808ee2618 000000000b7a879d 0000000000001000 0000000000000000 [ 34.101638] $ 8 : 0000000000e3f2c9 0000000000000000 a800000808a2a9f8 0000000000000000 [ 34.109660] $12 : a8000008139ffcd8 ffffffff84080018 a80000080837fae0 7878787878787878 [ 34.117682] $16 : a800000807e82940 0000000000001000 0000000000000000 0000000000000000 [ 34.125704] $20 : a800000802920e00 a8000008139ffdf8 a800000802649400 0000000000e3f2c9 [ 34.133726] $24 : 0000000000000006 00000001200406e0 [ 34.141783] $28 : a8000008139fc000 a8000008139ffd10 0000000000e3f2c8 a80000080838dfc4 [ 34.149837] epc : a80000080838e01c anon_pipe_read+0xd4/0x428 [ 34.155697] ra : a80000080838dfc4 anon_pipe_read+0x7c/0x428 [ 34.161549] Status: 140000e3 KX SX UX KERNEL EXL IE [ 34.166551] Cause : 40800408 (ExcCode 02) [ 34.170574] BadVA : 0000000000000000 [ 34.174161] PrId : 0001b028 (MIPS I6500) [ 34.178183] Process pipe_race (pid: 170, threadinfo=000000005ca35720, task=00000000e1013890, tls=000000014ebbb780) [ 34.188568] Stack : a800000802649400 0000000000000000 0000000000000000 a8000008139ffdd0 [ 34.196623] 0000000000000fba a800000808ee0000 0000000000000001 a8000008130c3e80 [ 34.204676] a8000008080d1280 a8000008139ffd58 a8000008139ffd58 1dbd2b22ea1dd500 [ 34.212729] a800000802649400 a800000808ee0000 ffffffffffffffea 0000000000000001 [ 34.220783] 0000000000001000 0000000000000000 00000001200ae518 ffffffffffffffff [ 34.228836] 000000fffbe0e530 a80000080837edf4 000000fffbe0e530 0000000000000000 [ 34.236890] 0000000000000000 0000000000000000 000000014ebb55a0 0000000000001000 [ 34.244943] 0000000000000001 a800000802649400 0000000000000000 0000000000000000 [ 34.252996] 0000000000000000 0000400400000000 0000000000000000 1dbd2b22ea1dd500 [ 34.261049] 00000000140000e3 a800000802649400 a800000802649400 a800000808ee0000 [ 34.269103] ... [ 34.271568] Call Trace: [ 34.274026] [] anon_pipe_read+0xd4/0x428 [ 34.279533] [] vfs_read+0x25c/0x318 [ 34.284607] [] ksys_read+0x104/0x138 [ 34.289763] [] syscall_common+0x44/0x68 [ 34.295187] [ 34.296689] Code: f84000cf 02209825 de020010 d8400004 02002825 0040f809 02802025 f84000c3 [ 34.306504] [ 34.308099] ---[ end trace 0000000000000000 ]--- My initial reproducer was the xdp-tools test suite. A standalone reproducer would be an lld/scd loop that, when the read is reordered by the CPU, triggers a fault. We can achieve this from userspace by stressing an anonymous pipe, which uses a mutex. Program used: // SPDX-License-Identifier: GPL-2.0 // pipe_race.c - reproducer for MIPS LL/SC reordering vs fs/pipe.c // // Two userspace processes on an anonymous pipe: // parent = writer: tight write() loop // child = reader: tight read() loop #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include #include int main(void) { long wrsize = 70; // bytes per write() long rdsize = 4096; // bytes per read() int pfd[2]; char *buf; pid_t pid; int ret; ret = pipe(pfd); assert(!ret); pid = fork(); assert(pid >= 0); if (pid == 0) { /* reader */ close(pfd[1]); buf = malloc(rdsize); assert(buf); for (;;) { ssize_t n = read(pfd[0], buf, rdsize); if (n < 0 && errno == EINTR) continue; if (n <= 0) _exit(n < 0 ? 1 : 0); } } close(pfd[0]); /* writer */ buf = malloc(wrsize); assert(buf); memset(buf, 'x', wrsize); for (;;) { ssize_t n = write(pfd[1], buf, wrsize); if (n < 0 && errno == EINTR) continue; if (n != wrsize) break; } kill(pid, SIGKILL); wait(NULL); return 0; } Fixes: fbe0fae601b7 ("MIPS: mobileye: Add EyeQ6H support") Cc: stable@vger.kernel.org Signed-off-by: Théo Lebrun Reviewed-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer commit e261bfd3c042bccd25c82b04de079bdf8bdd8c3a Author: Caleb James DeLisle Date: Mon Aug 17 22:03:44 2026 +0000 MIPS: config: Add EcoNet EN751221 defconfig Add config based on OpenWrt for EN751221 boards. Of note: EcoNet bootloader has a 7.2MB kernel size limit so ZBOOT is assumed to be needed in all cases. Signed-off-by: Caleb James DeLisle Tested-by: Randy Dunlap Signed-off-by: Thomas Bogendoerfer commit fb5a08026a68be0ec5f660588311fb1091bf5d58 Author: Julian Braha Date: Sun Aug 16 00:51:09 2026 +0100 mips: econet: fix unmet dependencies for ECONET ECONET selects EARLY_PRINTK_8250, SERIAL_OF_PLATFORM, and SERIAL_8250 without ensuring their dependencies, EARLY_PRINTK and TTY are met. This causes unmet dependencies: WARNING: unmet direct dependencies detected for SERIAL_8250 Depends on [n]: TTY [=n] && HAS_IOMEM [=y] && !S390 Selected by [y]: - ECONET [=y] WARNING: unmet direct dependencies detected for EARLY_PRINTK_8250 Depends on [n]: EARLY_PRINTK [=n] && USE_GENERIC_EARLY_PRINTK_8250 [=y] Selected by [y]: - ECONET [=y] WARNING: unmet direct dependencies detected for SERIAL_OF_PLATFORM Depends on [n]: TTY [=n] && HAS_IOMEM [=y] && SERIAL_8250 [=y] && OF [=y] Selected by [y]: - ECONET [=y] However, in the discussion of v1 of this patch, Arnd pointed out that these selects don't belong here in the first place. [1] Let's remove them to resolve the unmet dependencies. These unmet dependencies were found by kconfirm, a static analysis tool for Kconfig. Fixes: 79ee1d20e37c ("mips: econet: Fix incorrect Kconfig dependencies") Fixes: 35fb26f94dfa ("mips: Add EcoNet MIPS platform support") Suggested-by: Arnd Bergmann Signed-off-by: Julian Braha Tested-by: Caleb James DeLisle Signed-off-by: Thomas Bogendoerfer commit dc2136341be9835e70ba7c6b36904cf3683fd029 Author: Heiko Carstens Date: Mon Aug 31 10:38:38 2026 +0200 s390/crypto: Enable CONTEXT_ANALYSIS Enable CONTEXT_ANALYSIS since s390's crypto code compiles now without warnings. Reviewed-by: Harald Freudenberger Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 7a08507ea5b4d06ad8d269287913573f34467565 Author: Harald Freudenberger Date: Mon Aug 31 10:38:37 2026 +0200 s390/crypto: Map EBUSY to EIO when key conversion fails repeatedly When hardware persistently returns -EBUSY after exhausting retries, the error propagates to crypto_finalize_*_request(). The crypto API's completion wrapper treats -EBUSY as a queueing status and swallows it, preventing the completion callback from firing. This causes callers using crypto_wait_req() to block indefinitely. Translate persistent -EBUSY to -EIO after retry exhaustion to ensure proper error propagation and callback invocation. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit ac1481320110b803ab9b79ab4d2ca11a74fc05f2 Author: Harald Freudenberger Date: Mon Aug 31 10:38:36 2026 +0200 s390/crypto: Fix wrong return code to engine in asynch callbacks When crypto_finalize_hash_request() or crypto_finalize_skcipher_request() explicitly completes a request, the do_one_request callback must return 0 to indicate successful handling. Returning a negative error code causes the crypto engine to assume the driver failed to take ownership and triggers a second completion via crypto_request_complete(), resulting in a double completion. This pattern occurs in paes_s390.c 4 times and once in phmac_s390.c. Fixed in phmac_do_one_request() and all four paes do_one_request callbacks (ecb, cbc, ctr, xts) by returning 0 after explicit finalization instead of propagating the error code. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 330148371401de474b656eaf521861f12ec1a1ce Author: Harald Freudenberger Date: Mon Aug 31 10:38:35 2026 +0200 s390/crypto: Fix handling of EBUSY in PHMAC when req is pushed to crypto engine When a request is transferred to the engine via crypto_transfer_hash_request_to_engine() there are two return codes signaling a successful transfer: EINPROGRESS and EBUSY. However the correct handling of EBUSY was missing and has been added as a return code indicating a successful transfer to the crypto engine. Fixes: cbbc675506cc ("crypto: s390 - New s390 specific protected key hash phmac") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.17+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 3fec882c33d9b61983ee31456777f623dccd1a35 Author: Harald Freudenberger Date: Mon Aug 31 10:38:34 2026 +0200 s390/crypto: Fix handling of EBUSY in PAES when req is pushed to crypto engine When a request is transferred to the engine via crypto_transfer_skcipher_request_to_engine() there are two return codes signaling a successful transfer: EINPROGRESS and EBUSY. However the correct handling of EBUSY was missing and has been added as a return code indicating a successful transfer to the crypto engine. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 5b97b969030c099333d973be420edef0d6452e0f Author: Harald Freudenberger Date: Mon Aug 31 10:38:33 2026 +0200 s390/crypto: Fix missing cra_flags in paes_s390 The 4 algorithms implemented in paes_s390 never had any cra_flags set. So add code which sets the cra_flag to CRYPTO_ALG_ASYNC and CRYPTO_ALG_NO_FALLBACK. Fixes: 4ccd065a69df ("crypto: ahash - Add support for drivers with no fallback") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.17+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 749990db95d45cc3d96aab999ac7f110259b200c Author: Harald Freudenberger Date: Mon Aug 31 10:38:32 2026 +0200 s390/crypto: Fix use of mutex in atomic context in PAES The PAES CTR implementation used a mutex to lock one page of exclusive memory for fast CTR processing. Unfortunately a mutex is not save to use in atomic or interrupt context. So use a binary semaphore instead which is save to use in such environments. Furthermore rework the code to get rid of conditional locking. So restructure the PAES CRT code by extracting the main loop into a separate function and just give in information about the (locked) page can be used or not (is not locked). Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 19a218b46b2471d370c11fb52040f36ac8d05d23 Author: Harald Freudenberger Date: Mon Aug 31 10:38:31 2026 +0200 s390/crypto: Fix missing scrub of temp buffers with PAES algorithm In function ctr_paes_do_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. Rework the code to explicitly scrub the buffer at the end of the function to avoid exposure of maybe sensitive data. In function __xts_2keys_prep_param() change the existing scrub to clean the whole param block instead of just the key field. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 403648373816ae8eb76fe4a393836b0d65fa8f85 Author: Harald Freudenberger Date: Mon Aug 31 10:38:30 2026 +0200 s390/crypto: Fix return code handling at skcipher_walk_done in PAES algorithms All the 4 PAES cipher processing loops were not checking the return value of skcipher_walk_done() immediately after calling it. This could lead to error masking when both the walk operation failed and a subsequent key conversion was needed (k < n condition). Add immediate error checks after skcipher_walk_done() in all main processing loops (ECB, CBC, CTR, XTS modes) to ensure walk errors are properly propagated and not masked by subsequent operations. With that comes a slight rework around the skcipher_walk_done() invocation. It is now necessary to check if the walk has already been finalized (walk->nbytes is then 0) or not to avoid double de-allocation of resources held by the walk. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit d1c44a7d085473173bb360b7218a43699c3f56c7 Author: Harald Freudenberger Date: Mon Aug 31 10:37:35 2026 +0200 s390/crypto: Fix use of mutex in atomic context The AES CTR implementation used a mutex to lock one page of exclusive memory for fast CTR processing. Unfortunately a mutex is not save to use in atomic or interrupt context. So use a binary semaphore instead which is save to use in such environments. Furthermore rework the code to get rid of conditional locking. So restructure the AES CRT code by extracting the main loop into a separate function and just give in information about the (locked) page can be used or not (is not locked). Fixes: 7988fb2c03c8 ("crypto: s390/aes - convert to skcipher API") Suggested-by: Heiko Carstens Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 5.5+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 8b7c3b6914f19caf648d05726a86af6326d3c2c6 Author: Harald Freudenberger Date: Mon Aug 31 10:37:34 2026 +0200 s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out. Fixes: d07f951903fa ("crypto: s390/aes - Fix buffer overread in CTR mode") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.8+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 15fa028589c3a2545f0bff355eff06d5844196bf Author: Harald Freudenberger Date: Mon Aug 31 10:37:33 2026 +0200 s390/crypto: Fix skcipher_walk return code handling in aes_s390 The return codes from skcipher_walk_virt() were not properly checked before entering the processing loops in ecb_aes_crypt() and ctr_aes_crypt(). If skcipher_walk_virt() fails, the walk structure may be in an undefined state, and attempting to process data could lead to incorrect behavior or accessing uninitialized memory. Add proper return code checking to ensure correct handling of the walk initialization and walk advance and eventually return to the caller with that return code. Fixes: 7988fb2c03c8 ("crypto: s390/aes - convert to skcipher API") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 5.5+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 0945285e6cd67ee87e9313fb10221aba5bd69c6a Author: Mikhail Zaslonko Date: Thu Sep 3 15:07:33 2026 +0200 s390/debug: Fix race between debug area resize and event logging Trace functions check for non-NULL id->areas without lock to minimize overhead. This opens a race window where a NULL pointer dereference occurs if id->areas is set to NULL (e.g. via echo 0 > ../pages) after the check and before id->lock is taken. Fix this by rechecking id->areas under lock. Signed-off-by: Mikhail Zaslonko Reviewed-by: Peter Oberparleiter Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 22d4210bf988047bd30803cd6ef5177f113e4004 Author: Mikhail Zaslonko Date: Thu Sep 3 15:07:32 2026 +0200 s390/debug: Do not repeat parameter override notice on debug_set_level() Commit a2cec6863709 ("s390/debug: Add s390dbf kernel parameter") calls debug_get_param() from both debug_info_create() and debug_set_level(). Since debug_get_param() emits the override notice unconditionally, and drivers typically call debug_set_level() right after debug_register(), the same line is printed twice per debug area: s390dbf: 0.0.1234: override level to 6 s390dbf: 0.0.1234: override level to 6 For areas registered per device this is multiplied by the device count. With 's390dbf=0.0.*:6' a system with many DASDs emits a large number of redundant lines during boot. Add a quiet parameter to debug_get_param() and pass quiet=true from debug_set_level(), where the override has already been announced during registration. The remaining callers keep printing the notice. Signed-off-by: Mikhail Zaslonko Reviewed-by: Peter Oberparleiter Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit b1eb31d533cdfcae1011ed53850d52f36afe5774 Author: Mikhail Zaslonko Date: Thu Sep 3 15:07:31 2026 +0200 s390/debug: Fix NULL pointer dereference in debug_set_level() Commit a2cec6863709 ("s390/debug: Add s390dbf kernel parameter") incorrectly removed a null-id check from debug_set_level(), introducing a possible NULL pointer dereference for debug-API users that put debug_register() results unchecked into debug_set_level(). Fix this by moving the check from the internal _debug_set_level() variant back to the external debug_set_level() wrapper. Fixes: a2cec6863709 ("s390/debug: Add s390dbf kernel parameter") Signed-off-by: Mikhail Zaslonko Reviewed-by: Peter Oberparleiter Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 9ecc4d033879f7761f2df07e20cd2fbec00fd90b Author: Thomas Richter Date: Tue Sep 1 14:33:20 2026 +0200 s390/pai: Support CPU hotplug for PMU PAI The command 'perf stat -e pai_crypto/CRYPTO_ALL/ -- ' crashes the kernel when CPUs are hotplug added during that run. Root cause is the missing allocation of per-CPU data structures for that new CPU. The allocation is dynamic and the first event that has task context creates such a structure for each online CPU. This is not sufficient. CPUs may be offline during event creation and can be set online during the perf run time. For example commands # echo 0 > /sys/devices/system/cpu/cpu1/online # perf stat -e cycles -i -- stress-ng -t10s --matrix X # sleep 1 # echo 1 > /sys/devices/system/cpu/cpu1/online Currently without a CPU hotplug handler, that new CPU has no per-CPU data infrastructure. The scheduler runs PMU call back function pai_add() to install the PMU support for that CPU before the task is being scheduled on that new CPU. In pai_add() instructions mp = this_cpu_ptr(pai_root[idx].mapptr); cpump = mp->mapptr; return a NULL pointer and the result is a kernel panic as variable cpump is used inside that function. Add CPU hotplug support for CPU add and delete and create the necessary per-CPU data infrastructure during CPU hotplug add processing. Same for CPU hotplug remove. This is done when the CPU is offline to ensure the data structures are available when CPU is made online and tasks are scheduled on it. [hca@linux.ibm.com: fixup error path in pai_init()] Cc: stable@vger.kernel.org # v6.19 Fixes: 582cc1b28e8c ("s390/pai_ext: Enable per-task and system-wide sampling event") Fixes: 9f66572f2889 ("s390/pai_crypto: Enable per-task and system-wide sampling event") Signed-off-by: Thomas Richter Reviewed-by: Jan Polensky Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit e8df39dacb7d98d2b2aea431ca652d9fadf5efa3 Author: Thomas Richter Date: Tue Sep 1 14:33:19 2026 +0200 s390/pai: Move locking to event init and delete Move mutex locking from per CPU allocation to event allocation. No functional change. Signed-off-by: Thomas Richter Reviewed-by: Sumanth Korikkar Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit 4eef4ab3aa3a32725e5bc79032c722f9f4a90172 Author: Thomas Richter Date: Tue Sep 1 14:33:18 2026 +0200 s390/pai: Use PAI PMU index as parameter replacing event Use PAI PMU index value as function argument instead of pointer to struct perf_event. Only that index value is used inside functions pai_alloc_cpu() and pai_event_destroy_cpu(). No functional change. Signed-off-by: Thomas Richter Reviewed-by: Sumanth Korikkar Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik commit aba7b41faeecb7692458095ce6fafc341fe0b80e Author: Bard Liao Date: Tue Sep 1 11:10:19 2026 +0800 soundwire: cadence_master: wait and cancel cdns->work before clock stop A peripheral event could happen during the clock stop process. We need to wait for the event be handled before stopping the bus clock. Otherwise, we will get the IO transfer timed out issue. Fixes: af4cc917826f ("soundwire: cadence: mask Slave interrupt before stopping clock") Signed-off-by: Bard Liao Reviewed-by: David Lin Reviewed-by: Shuming Fan Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260901031019.233254-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul commit f97802dd98b27e45c04293f9926f07642578b23f Author: Karl Mehltretter Date: Sat Sep 5 10:03:44 2026 +0200 drm/logicvc: Drop the select of the nonexistent CONFIG_DRM_KMS_DMA_HELPER CONFIG_DRM_KMS_CMA_HELPER was removed by commit 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option"). When commit 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") later renamed the select in this Kconfig to CONFIG_DRM_KMS_DMA_HELPER, no symbol of that name existed, and git log -S finds no Kconfig file that has defined one since. The select is silently ignored. The driver already selects CONFIG_DRM_GEM_DMA_HELPER, which is what it needs. Remove the dead line. Fixes: 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260905080344.34077-1-kmehltretter@gmail.com commit fedf002d7d08bee36693aacd1ade2ba39351ea91 Author: Karl Mehltretter Date: Sat Sep 5 10:04:26 2026 +0200 drm/adp: Drop the select of the nonexistent CONFIG_DRM_KMS_DMA_HELPER There is no Kconfig symbol CONFIG_DRM_KMS_DMA_HELPER. The former CONFIG_DRM_KMS_CMA_HELPER was removed by commit 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option") before this driver was added, so the select does nothing. The driver already selects CONFIG_DRM_GEM_DMA_HELPER, which is what it needs. Remove the dead line. Fixes: 332122eba628 ("drm: adp: Add Apple Display Pipe driver") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260905080426.34224-1-kmehltretter@gmail.com commit 09f7fc4e8e307fcdaa506b3a06cd7b1acffd2584 Author: Qinyun Tan Date: Tue Sep 1 16:32:34 2026 +0800 drm/vboxvideo: create blend mode property on planes Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. Both the vboxvideo primary and cursor planes expose ARGB8888 and trip this on driver load. VirtualBox draws the cursor through the host windowing system, which treats the guest-supplied pointer shape as straight (non-pre-multiplied) alpha: the host frontend loads the pixels verbatim into an unpremultiplied ARGB image before handing them to the host cursor APIs. This corresponds to DRM_MODE_BLEND_COVERAGE. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_COVERAGE to make these semantics explicit and silence the warning. The primary plane's alpha channel is ignored by the host (opaque blit) and it is the bottom-most plane anyway; advertise the same value there for consistency. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Acked-by: Thomas Zimmermann Signed-off-by: Qinyun Tan Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260901083234.1828755-5-qinyuntan@linux.alibaba.com commit f2e64f450c1665732505dae8ee34b399da5a5100 Author: Qinyun Tan Date: Tue Sep 1 16:32:33 2026 +0800 drm/virtio: create blend mode property on cursor plane Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. The virtio-gpu cursor plane (HOST_ARGB8888) trips this. The virtio-gpu specification does not define the cursor alpha semantics. The host forwards the cursor pixels verbatim to its display frontends, and the remote cursor protocols among them (SPICE alpha cursors, the VNC "Cursor With Alpha" encoding) both define pre-multiplied alpha, matching what userspace has always assumed when the property is not attached. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_PREMULTI to make these semantics explicit and silence the warning. The primary plane only exposes HOST_XRGB8888, so the call is gated to the cursor. No functional change. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Reviewed-by: Thomas Zimmermann Signed-off-by: Qinyun Tan Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260901083234.1828755-4-qinyuntan@linux.alibaba.com commit b67f408a0c2427d5d7c682cfbdad87c4ff73265b Author: Qinyun Tan Date: Tue Sep 1 16:32:32 2026 +0800 drm/qxl: create blend mode property on primary and cursor planes Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. Both the qxl primary and cursor planes expose ARGB8888 and trip this on driver load. qxl submits cursors as SPICE_CURSOR_TYPE_ALPHA, which the SPICE protocol explicitly defines as a "pre-multiplied ARGB8888 pixmap" (Spice Protocol, "Cursor channel definition" section [1]). This matches the blend mode userspace has always assumed when the property is not attached. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_PREMULTI to make these semantics explicit and silence the warning. The primary plane is the bottom-most plane so its blend mode has no visible effect; advertise the same value there for consistency. No functional change. [1] https://www.spice-space.org/spice-protocol.html Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Reviewed-by: Thomas Zimmermann Signed-off-by: Qinyun Tan Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260901083234.1828755-3-qinyuntan@linux.alibaba.com commit 313f798f52a5e46b0e419d05f977d40aaeac4106 Author: Qinyun Tan Date: Tue Sep 1 16:32:31 2026 +0800 drm/ast: create blend mode property on cursor plane Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. The ast cursor plane (ARGB4444, ARGB8888) trips this on driver load: [PLANE:37:plane-1] pixel format with alpha exposed but blend mode not setup WARNING: drivers/gpu/drm/drm_mode_config.c:872 at drm_mode_config_validate+0x48f/0x510 [drm] ... Call Trace: drm_dev_register+0x1ce/0x290 [drm] ast_pci_probe+0x19d/0x3f0 [ast] local_pci_probe+0x41/0x90 Per Thomas Zimmermann's review, the ASPEED documentation describes the hardware cursor as blending with straight (non-pre-multiplied) alpha, which corresponds to DRM_MODE_BLEND_COVERAGE. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_COVERAGE to make the hardware semantics explicit and silence the warning. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Suggested-by: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Tested-by: Thomas Zimmermann Signed-off-by: Qinyun Tan Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260901083234.1828755-2-qinyuntan@linux.alibaba.com commit 28cc4d5a75bb07d0eb2fa178db355b04483f5aca Author: Shixiong Ou Date: Tue Sep 8 13:59:41 2026 +0800 drm/sched: Create a fake device for KUnit tests The DRM scheduler KUnit tests pass NULL for the dev field in drm_sched_init_args, which NULL-pointer dereferences in the drm_sched_job trace event via dev_name() on sched->dev. Give the mock scheduler a device with kunit_device_register(), which is also cleaned up at test exit. A per-function counter keeps the device names unique, since some tests create several mock schedulers. Fixes: 5a99350794fe ("drm/sched: Add scheduler unit testing infrastructure and some basic tests") Cc: stable@vger.kernel.org Signed-off-by: Shixiong Ou Acked-by: Maxime Ripard [phasta: removed static variable init to 0 again] Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260908055941.351486-1-oushixiong1025@163.com commit a8916759a451918c2a95633390d3428640858087 Merge: 95bf070f3225dc df2908090cda36 Author: Thomas Zimmermann Date: Tue Sep 8 13:32:08 2026 +0200 Merge drm/drm-fixes into drm-misc-fixes Backmerging to get drm-misc-fixes up to v7.3-rc2. Signed-off-by: Thomas Zimmermann commit 48b2c5c628b09cf36cbeca53e0432fc2a7518be7 Author: Johannes Berg Date: Fri Sep 4 16:55:02 2026 +0200 wifi: cfg80211: check IP header size in cfg80211_classify8021d() A frame that looks like IP can be transmitted, but be too short, so the DS field is read incorrectly: BUG: KMSAN: uninit-value in cfg80211_classify8021d+0x99d/0x12b0 net/wireless/util.c:1027 cfg80211_classify8021d+0x99d/0x12b0 net/wireless/util.c:1027 ieee80211_select_queue+0x37a/0x9e0 net/mac80211/wme.c:180 __ieee80211_subif_start_xmit+0x60f/0x1d90 net/mac80211/tx.c:4304 ieee80211_subif_start_xmit+0xa8/0x6d0 net/mac80211/tx.c:4538 ... packet_sendmsg+0x9173/0xa2a0 net/packet/af_packet.c:3108 Use skb_header_pointer() like the MPLS case. Assisted-by: LLM Fixes: e31a16d6f64e ("wireless: move some utility functions from mac80211 to cfg80211") Reported-by: syzbot+878ddc3962f792e9af59@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=878ddc3962f792e9af59 Link: https://patch.msgid.link/20260904165614.5e61a4c80b92.I37d68d3f406cb3b90b32e6943418d66070b65197@changeid Signed-off-by: Johannes Berg commit a7783e585360ee05dfe21d3173dbbe985c94f29e Author: Johannes Berg Date: Fri Sep 4 16:55:01 2026 +0200 wifi: cfg80211: don't get the radio mask for netdev-less wdevs cfg80211_calculate_bi_data() calls rdev_get_radio_mask() with wdev->netdev, which can be NULL and then crashes in mac80211. To avoid that, invert the order of checks since wdev->netdev is always valid for beaconing interfaces. Assisted-by: LLM Fixes: abb4cfe3661a ("wifi: cfg80211: extend interface combination check for multi-radio") Reported-by: syzbot+abff43d2d045e37c0bb2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=abff43d2d045e37c0bb2 Link: https://patch.msgid.link/20260904165614.2056a8b7dc91.I7412c5062d8166ad6c81ee7252cec49dea19a60f@changeid Signed-off-by: Johannes Berg commit e0554c6276da957b6e72849520c70a97404cd1ae Merge: c51fe228121ee3 e89e88ad41d9f3 Author: Paolo Abeni Date: Tue Sep 8 12:35:23 2026 +0200 Merge branch 'net-ethernet-cortina-fix-rx-budget-accounting' Linus Walleij says: ==================== net: ethernet: cortina: Fix RX budget accounting Finish RX updates before releasing NAPI ownership, report actual NAPI work, charge dropped frames to the poll budget, and drive free-queue refills from consumed RX descriptors. Track RX drop state across descriptor chains so discarded frames are counted exactly once. Tested on the D-Link DIR-685. Hi Sashiko, yes there are more latent issues I will get to them, but my LLM thinks those are on the top of the list. Assisted-by: LLM Signed-off-by: Linus Walleij ==================== Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-0-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni commit e89e88ad41d9f31c829c2af39c48313e8e48d5b0 Author: Linus Walleij Date: Thu Sep 3 23:45:33 2026 +0200 net: ethernet: cortina: Count RX descriptors for freeq refill The software free queue provides one buffer fragment for every descriptor moved to an RX queue. The refill heuristic instead advances by NAPI work, which counts frames. A fragmented or discarded frame can consume several queue entries while adding only one to the refill count. Count the RX descriptors as they are consumed and report that separately from NAPI work. Use the descriptor count to drive free queue refills. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Assisted-by: LLM Reviewed-by: Joe Damato Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-5-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni commit 6520198c430c81bcc367f0dd5e32f2fb740b9d51 Author: Linus Walleij Date: Thu Sep 3 23:45:32 2026 +0200 net: ethernet: cortina: Count RX drops once per frame The absence of a partial skb means either that the driver is not assembling a frame or that the current frame was already dropped. Consequently, repeated descriptor errors can increment rx_dropped more than once, while an orphaned descriptor chain can reach EOF without being counted at all. Track the dropping state across NAPI polls. Clear it at frame boundaries and route mapping failures and orphaned continuations through the common drop path so each discarded frame is counted exactly once. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Reported-by: Joe Damato Closes: https://lore.kernel.org/netdev/apdK5aMmvYssz35F@devvm20253.cco0.facebook.com/ Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-4-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni commit b856c552f556bc0341c1dbe0bf88e630fd1dc4b7 Author: Linus Walleij Date: Thu Sep 3 23:45:31 2026 +0200 net: ethernet: cortina: Count dropped frames as NAPI work The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-3-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni commit baa26841cb9a2cdc7e0e99d6854a4e3359bf7393 Author: Linus Walleij Date: Thu Sep 3 23:45:30 2026 +0200 net: ethernet: cortina: Finish RX updates before NAPI completion napi_complete_done() releases ownership of the NAPI instance, but the Gemini poll keeps the RX statistics writer section open and updates the free queue after calling it. A new poll can therefore start while the old writer is still active. Finish the statistics and free queue updates before releasing ownership. Only re-enable RX interrupts when napi_complete_done() reports successful completion. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Suggested-by: Joe Damato Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-2-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni commit a0de06d0da78a3db53de65dfd7452cc6d111f703 Author: Linus Walleij Date: Thu Sep 3 23:45:29 2026 +0200 net: ethernet: cortina: Fix budget accounting The gmac_rx() function returns the remaining NAPI budget, but its caller treats the return value as the number of packets received. An idle poll therefore reports a full budget and remains scheduled. Return the number of received packets instead. Preserve the existing free queue refill accounting by adding that count directly; continuing to subtract it from the budget would invert the refill behavior. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Link: https://lore.kernel.org/r/20260509-gemini-ethernet-fixes-v1-4-6c5d20ddc35b@kernel.org Link: https://lore.kernel.org/r/20260512131456.189452-1-pabeni@redhat.com Assisted-by: LLM Reviewed-by: Joe Damato Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260903-gemini-ethernet-fixes-v2-1-2bbbd598ca6e@kernel.org Signed-off-by: Paolo Abeni commit d41d0021a6ea3e9fcd14126a00fead47f981c46e Author: Mickaël Salaün Date: Mon Sep 7 17:43:59 2026 +0200 landlock: Test trace path output boundaries Use focused KUnit tests to exercise the renderer's internal boundary and composition contracts with synthetic scratch states, including both sibling-helper evaluation orders. Check the exact output and reservation boundaries, including a four-byte octal escape accepted at exact capacity and rejected one byte short. Also verify an unchanged cursor on failure, that bracketed process names and embedded NUL bytes remain data, and that input ellipsis bytes are escaped rather than mistaken for the raw truncation marker. The composition test requires generic trace output helpers. Enable CONFIG_FTRACE and CONFIG_SCHED_TRACER because the latter selects the otherwise-hidden CONFIG_TRACING support required by trace_print_flags_seq(). Use kselftests to exercise the complete tracefs path for both affected filesystem events. A valid path containing 2640 spaces exceeds the scratch output budget. Require its escaped prefix to end in the raw UTF-8 ellipsis while access_rights and blockers remain intact. This division keeps the exact safety contract compiler-independent while proving that real tracepoints preserve their surrounding symbolic fields. The end-to-end assertions fail after a full fix revert with both GCC and Clang, while the composition KUnit test fails if the scratch reserve is removed. Cc: Günther Noack Link: https://patch.msgid.link/20260907154401.124362-2-mic@digikod.net Signed-off-by: Mickaël Salaün commit 3125751cd1de76a01b18daef399d6b88d159bd17 Author: Mickaël Salaün Date: Mon Sep 7 17:43:58 2026 +0200 landlock: Bound escaped trace path output Filesystem paths may expand fourfold when trace text escapes spaces and other untrusted bytes. A sufficiently long representation can exhaust the shared scratch sequence. A sibling __print_flags() helper may then return an unterminated one-past pointer because TP_printk() argument ordering is unspecified. Use a fixed budget rather than the scratch space available at call time, so output does not vary with sibling evaluation order. Limit an untrusted string to three quarters of the trace sequence, leaving the rest for sibling helpers and final event metadata. Compute and commit complete escaped output transactionally so an exact fill cannot consume the terminating NUL or poison the scratch sequence. For strings that exceed the limit, retain the largest prefix ending at a complete escape unit, then append a raw UTF-8 ellipsis. Keep the helper's existing octal fallback so complete values remain unchanged. Hex fallback would consume the same four bytes per escaped byte without increasing the prefix or strengthening the marker. ESCAPE_NAP renders every non-ASCII input byte in octal, so legitimate data cannot reproduce the marker without being escaped. Cc: Günther Noack Link: https://patch.msgid.link/20260907154401.124362-1-mic@digikod.net Signed-off-by: Mickaël Salaün commit d3df7ed4683f8c1b35672a40bf20af6a08ef8ca9 Author: Mickaël Salaün Date: Mon Sep 7 12:36:08 2026 +0200 landlock: Clean up ruleset validation checks landlock_merge_ruleset() checks for a NULL ruleset after dereferencing it in lockdep_assert_held(). Move the assertion after the check so the defensive path remains effective. The mask-validation comment originated in landlock_add_fs_access_mask() to explain that its WARN_ON_ONCE() checked a caller invariant. It became self-referential when this helper and its network and scope counterparts were inlined into landlock_create_ruleset(). Restate the invariant without naming the caller. Keep both as defensive callee checks. Moving the assertion preserves the NULL check's ability to warn and return -EINVAL, while invalid masks remain warned about and masked. Reported-by: Günther Noack Closes: https://patch.msgid.link/aobYhIt3vcs2xN0b@google.com Closes: https://patch.msgid.link/aobasxUDQ8b7GYXl@google.com Reviewed-by: Günther Noack Link: https://patch.msgid.link/20260907103609.113325-1-mic@digikod.net Signed-off-by: Mickaël Salaün commit c51fe228121ee32d3a81242119a4195bed027b95 Merge: ae20d47d2678b4 2b6c0e25a3d713 Author: Paolo Abeni Date: Tue Sep 8 11:46:36 2026 +0200 Merge branch 'net-macb-fix-the-link-speed-the-taprio-setup-reads' Aleksei Sviridkin says: ==================== net: macb: fix the link speed the taprio setup reads Two small fixes in macb_taprio_setup_replace(), both in how it obtains the link speed it scales the schedule with. The first: it hands phylink_ethtool_ksettings_get() a stack variable it never zeroed, while phylink fills only what the link mode provides and even reads one field back from the caller. The second: the speed check is written as "<= 0" on a u32, so SPEED_UNKNOWN passes it and turns into a 1 ns hardware limit that every entry then exceeds. Compile-tested against net; the driver has no test surface, and no macb board here. ==================== Link: https://patch.msgid.link/20260903123652.23900-1-f@lex.la Signed-off-by: Paolo Abeni commit 2b6c0e25a3d713c4032e45f212bdd9e14c50f8a0 Author: Aleksei Sviridkin Date: Thu Sep 3 12:36:52 2026 +0000 net: macb: reject an unknown link speed in the taprio setup speed is a u32, so SPEED_UNKNOWN arrives as 0xffffffff and passes the "speed <= 0" check, which only ever catches zero. That is what an autonegotiating link reports while it is down: the limit derived from the speed collapses to a nanosecond at most and the first entry fails with a misleading "exceeds hardware limit". Zero stays covered, it is what an interface that was never opened reports, and enst_max_hw_interval() divides by it. Say which case it was in the error. Fixes: 89934dbf169e ("net: macb: Add TAPRIO traffic scheduling support") Assisted-by: LLM Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123652.23900-3-f@lex.la Signed-off-by: Paolo Abeni commit 0523d5c52a450590bf5992bd6925394f3cc403e8 Author: Aleksei Sviridkin Date: Thu Sep 3 12:36:51 2026 +0000 net: macb: zero the link settings taprio reads back macb_taprio_setup_replace() calls phylink_ethtool_ksettings_get() with an uninitialised kset, and kset is not only an out-parameter. On a fixed link, or an in-band link with no PHY, phylink writes speed and duplex only if kset->base.rate_matching already reads RATE_MATCH_NONE, a field it never writes itself; in PHY mode before the PHY is attached it writes port and supported and nothing more. Either way the speed read back afterwards can be stack garbage. The ethtool core zeroes the structure on every path into the op, which is why its callers never see this; taprio is the only in-kernel caller passing its own variable. Fixes: 89934dbf169e ("net: macb: Add TAPRIO traffic scheduling support") Assisted-by: LLM Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123652.23900-2-f@lex.la Signed-off-by: Paolo Abeni commit ae0e61d95677efa778379853e495d748e6efbf95 Author: Johan Hovold Date: Thu Sep 3 18:31:46 2026 +0200 USB: serial: fix ioctl hangup race The tty ioctls can race with hangup and end up calling into a tty driver for a device that is already gone or powered down. Serialise the callbacks using the tty port mutex and add the missing checks to make sure the port has not been hung up before accessing port driver data or hardware. This specifically avoids dereferencing a NULL-pointer if a device is disconnected during lengthy break signalling. Note that TIOCGICOUNT and TIOCMIWAIT do not access port driver data or hardware and are therefore not affected by the race. Fixes: f34d7a5b7010 ("tty: The big operations rework") Reported-by: Nick Bowler Link: https://lore.kernel.org/all/CADyTPExB2kYOOwkO0JqGhKaYVDqO9uS9WCw0J=MCTdVhcGOogA@mail.gmail.com/ Reported-by: syzbot+473d7477c523b41d4046@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/6a9087a4.4d659fcc.734b4.0013.GAE@google.com Cc: stable@vger.kernel.org # 2.6.26 Signed-off-by: Johan Hovold commit 8fe535227455db566bcaf40fd83db50b16dce935 Author: Johan Hovold Date: Fri Aug 21 17:45:46 2026 +0200 USB: serial: use iterator for driver deregistration Use the new serial driver iterator variable also when deregistering serial drivers to improve readability. Signed-off-by: Johan Hovold commit 646e5b28b4fdbc1b828a2398d6ced2c1dd308a46 Author: Johan Hovold Date: Fri Aug 21 17:45:45 2026 +0200 USB: serial: fix driver deregistration order USB serial driver modules register one driver for the USB bus and one or more drivers for the ports on the USB serial bus. When unloading a driver module, the USB driver must be deregistered before the USB serial bus drivers so that I/O is stopped before unbinding the ports to avoid use-after-free in completion handlers accessing port data. Note that the "new_id" attributes must first be removed to prevent new ids from being added and triggering a probe of the USB driver after it has been deregistered. Fixes: 765e0ba62613 ("usb-serial: new API for driver registration") Cc: stable@vger.kernel.org # 3.4 Cc: Alan Stern Signed-off-by: Johan Hovold commit 63594e8ffe097bc0b7639936f33799a7653dded2 Author: Johan Hovold Date: Fri Aug 21 17:45:44 2026 +0200 USB: serial: fix dynamic id driver deregistration race Only free the dynamic ids after having deregistered the driver and removed the "new_id" attribute to avoid leaking any id added by a racing write to the attribute. Fixes: 93bacefc4cc0 ("USB serial: add dynamic id support to usb-serial core") Cc: stable@vger.kernel.org # 2.6.21 Signed-off-by: Johan Hovold commit 33c920f7c5952dfc42d1b8ea6efe16b1f0bb0c5b Author: Johan Hovold Date: Fri Aug 21 17:45:43 2026 +0200 USB: serial: fix port tear down use-after-free Some drivers for multiport devices access port driver data from completion handlers of shared URBs submitted at attach() or first open() and stopped at disconnect() or last close(), respectively. A simple NULL check before accessing the driver data makes sure that a port state container has at least been allocated, but a completion handler can still race with port tear down. Reorder the disconnect handling so that ports are not deregistered (and their driver data freed) until after all ports have been hung up and the driver disconnect() callback has run so that all I/O has been stopped. Fixes: 2d93148ab698 ("USB: serial: fix lifetime and locking problems") Reported-by: syzbot+e5e28c3e953b2eebb16e@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/6a7e6fb9.ec5dc6cc.21cb3f.00c0.GAE@google.com/ Cc: stable@vger.kernel.org # 2.6.30 Cc: Alan Stern Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold commit b51faf3f2e307f114854bbe6d495f03cd5370686 Author: Ian Lin Date: Fri Sep 4 16:00:46 2026 +0800 USB: serial: option: add Compal EXC-T1 support The Compal EXC-T1 is a Qualcomm MDM9207-based LTE modem which reports "EXC-x1" as its USB product string. It exposes diagnostic, modem, AT, and NMEA ports as vendor-specific interfaces with subclass 0x10 and protocols 0x01 through 0x04. Add exact interface matches for these four ports, leaving the ff/ff/ff interface unbound. Relevant output from usb-devices: T: Bus=03 Lev=02 Prnt=03 Port=03 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=04b7 ProdID=4d22 Rev=03.18 S: Manufacturer=CEI S: Product=EXC-x1 C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=10 Prot=01 Driver=option I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=10 Prot=02 Driver=option I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=10 Prot=03 Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=10 Prot=04 Driver=option I: If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=10 Prot=05 Driver=qmi_wwan Tested on a Compal EXC-T1 modem using an Ubuntu kernel build. The four serial interfaces bound to option and exposed ttyUSB3 through ttyUSB6. Assisted-by: Codex:GPT-5 Signed-off-by: Ian Lin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold commit ae20d47d2678b48905a4d6cfcf2228075327551e Merge: 8d6cd188508513 c0aceaf65b70b3 Author: Paolo Abeni Date: Tue Sep 8 10:47:06 2026 +0200 Merge branch 'fix-a-variety-of-tpa-bugs' Joe Damato says: ==================== Fix a variety of TPA bugs I am sending this series as an extension to my v4 [1] which was just 1 patch. Note that patch 5 of this series can now cause the device to fail closed if memory is tight; bnxt_init_nic propagates an error that was previously swallowed and fails closed instead of succeeding in a degraded state. If the maintainers want the device to come up with a partially populated rx_tpa[], then patch 5 can be dropped and this series can still be applied and will otherwise work as intended. This series addresses a variety of bugs orbiting the TPA code in the bnxt driver that Sashiko (or Clashiko or whatever) pointed out and the series ends with the patch from the v4 [1]. A lot of the noise generated by the AIs while reviewing my v4 are unrelated bugs with different fixes tags that, IMHO, distract a bit from the crash at boot that is currently occurring with Thor2 hardware on recent kernels. That said, I've tried to wrangle this series together which I hope will solve most of the important bugs the AIs are feeling something about. I do not know what other rabbit holes the AIs will find when I submit this series, but if there is some reasonable stop-gap that we can get applied to fix the crashes on Thor2 (while I iterate on the rest of the bugs at the pleasure of the AIs) that would be excellent. I boot tested this on a Thor1 and a Thor2 machine and there were no crashes at boot. [1]: https://lore.kernel.org/all/20260828190900.1767611-1-joe@dama.to/ ==================== Link: https://patch.msgid.link/20260902015652.2421609-1-joe@dama.to Signed-off-by: Paolo Abeni commit c0aceaf65b70b3c000e70dd867f3a673015f24ca Author: Joe Damato Date: Tue Sep 1 18:56:49 2026 -0700 bnxt_en: Bound SW TPA IDs to prevent crashes FW supports up to 1024 concurrent TPAs, so the FW TPA ID is in the range 0..1023 (see commit ec4d8e7cf024 ("bnxt_en: Add TPA ID mapping logic for 57500 chips.")). bnxt_alloc_agg_idx is intended to wrap the FW ID down to a software ID which is used to index rxr->rx_tpa, and to generate a mapping between FW IDs and the wrapped software ID. On a 57608 with firmware version 233, the firmware advertises 32 concurrent TPAs. As of the commit under fixes, bp->max_tpa on this NIC is set to 32. If the software ID from bnxt_alloc_agg_idx is above 31, this results in an invalid address being loaded on this line: tpa_info = &rxr->rx_tpa[agg_id]; because rx_tpa is allocated with only bp->max_tpa (32) entries. Writes to tpa_info later in the code are out of bounds. This bug results in a crash at boot: Oops: general protection fault, kernel NULL pointer dereference 0x8: 0000 [#1] SMP NOPTI RIP: 0010:bnxt_rx_pkt+0xc0/0x1560 RSP: 0018:ffffc900009b8c78 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000048 RCX: 0000000206682516 RDX: ffffc900009b8db4 RSI: 0000000000000000 RDI: 01ffffff038fe1c0 RBP: ffffc9006e687480 R08: ffffc9006e687000 R09: 0000000000003048 R10: 0000000000000480 R11: ffff8881c6083900 R12: 0000000006682516 R13: ffff8881c6095400 R14: 0000000000000016 R15: ffff8881c6b66680 FS: 0000000000000000(0000) GS:ffff88fef3c77000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc8bda40584 CR3: 000000807c812001 CR4: 0000000008772ef0 PKRU: 55555554 Call Trace: ? __netif_receive_skb_list_core+0x1ca/0x250 __bnxt_poll_work+0x152/0x280 bnxt_poll_p5+0x1cd/0x480 __napi_poll+0x30/0x180 net_rx_action+0x20b/0x3b0 ? note_gp_changes+0x53/0xe0 ? tick_setup_sched_timer+0x180/0x180 ? __napi_schedule+0x9a/0xb0 ? bnxt_msix+0x24/0x30 handle_softirqs+0xdd/0x2c0 __irq_exit_rcu.llvm.3171231171502365008+0x47/0xf0 common_interrupt+0x85/0x90 asm_common_interrupt+0x22/0x40 This stack trace is from a crash triggered when an out of bounds rx_tpa is dereferenced. The invalid write mentioned above is silent in this particular crash. Fix this by allocating rx_tpa with bp->max_tpa rounded up to the next power of 2 (bp->max_tpa_roundup_size) entries and masking the FW TPA ID with that size, so the wrapped ID can never index past the end of the array. Fixes: 54c28fab2fa5 ("bnxt_en: Set bp->max_tpa according to what the FW supports") Reported-by: Raphael Cardoso Fernandes Suggested-by: Michael Chan Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-7-joe@dama.to Signed-off-by: Paolo Abeni commit 8e6a850c0746bb4be167aedf1ee57469fcda09a9 Author: Joe Damato Date: Tue Sep 1 18:56:48 2026 -0700 bnxt_en: Propagate RX ring init failures in bnxt_init_nic() bnxt_init_rx_rings() returns an error when bnxt_alloc_one_rx_ring() fails, but bnxt_init_nic() discards that return value and calls bnxt_init_chip(), which enables TPA. If an allocation fails, this could leave rxr->rx_tpa[] partially zeroed and TPA would be enabled over an array with zeroed entries. This would lead to a zeroed DMA address being handed out if the agg_idx is translated to a SW index at a zeroed entry. Fix this by propagating the error out of bnxt_init_nic(). Both callers already check its return value and unwind with bnxt_free_skbs() and bnxt_free_mem(), which tolerate a partially initialized RX ring. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-6-joe@dama.to Signed-off-by: Paolo Abeni commit 961e2a17c5e3559b3f8654d2daabdd25a42e770a Author: Joe Damato Date: Tue Sep 1 18:56:47 2026 -0700 bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed. Fixes: 8fbf58e17dce ("bnxt_en: Implement RX ring reset in response to buffer errors.") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-5-joe@dama.to Signed-off-by: Paolo Abeni commit b814dfbfeb0a68c9a52073f2caa05a2d5247a329 Author: Joe Damato Date: Tue Sep 1 18:56:46 2026 -0700 bnxt_en: Propagate TPA buffer allocation failures in bnxt_queue_mem_alloc() bnxt_alloc_one_tpa_info_data() returns -ENOMEM as soon as one allocation fails. This leaves the remaining rxr->rx_tpa[] entries zeroed. bnxt_queue_mem_alloc() discards that return value, so the partially initialized ring is installed by bnxt_queue_start(). Since the agg_id is picked by the hardware and bnxt_alloc_agg_idx maps it to a SW index in rxr->rx_tpa[], it is possible that an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by checking the return value of bnxt_alloc_one_tpa_info_data and unwinding, freeing the ring buffers. Fixes: bd649c5cc958 ("bnxt_en: handle tpa_info in queue API implementation") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-4-joe@dama.to Signed-off-by: Paolo Abeni commit 5ce7f36c334d723954855ac769ede2fe0e8f89c8 Author: Joe Damato Date: Tue Sep 1 18:56:45 2026 -0700 bnxt_en: Don't free the live ring's TPA state on queue restart failure bnxt_queue_mem_alloc() shallow copies the live RX ring into the clone: memcpy(clone, rxr, sizeof(*rxr)); the code currently clears pointers that the clone owns (such as rx_agg_bmap), but rx_tpa and rx_tpa_idx_map are left pointing at memory of the live ring that was cloned. If an allocation failure happens later and the err_free_tpa_info label is taken, the live ring's memory can be freed while still in use. Fix this by initializing the clone's pointers to NULL to prevent live ring state from being freed inadvertently. Fixes: bd649c5cc958 ("bnxt_en: handle tpa_info in queue API implementation") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-3-joe@dama.to Signed-off-by: Paolo Abeni commit 4e17b5007b6664559cdad2b2fe270526cf786b5b Author: Joe Damato Date: Tue Sep 1 18:56:44 2026 -0700 bnxt_en: Only restore LRO if the device supports TPA With a P5+ device with firmware that reports max_aggs_supported == 0, it is possible to make LRO settable by attaching and detaching an XDP program even though the device does not support TPA. Fix this by testing BNXT_SUPPORTS_TPA before restoring the feature bit. Fixes: f0aa6a37a3db ("eth: bnxt: always recalculate features after XDP clearing, fix null-deref") Reported-by: Sashiko Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260828190900.1767611-1-joe%40dama.to Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902015652.2421609-2-joe@dama.to Signed-off-by: Paolo Abeni commit 48a4ee65e677559776349128e6a81a6041986c99 Author: Linfeng Sun Date: Tue Sep 8 15:31:51 2026 +0800 vduse: return compat ioctl results directly The compat handler handles VDUSE_IOTLB_GET_FD and VDUSE_VQ_GET_INFO, but then calls the native handler. Their different command sizes make native dispatch return -ENOIOCTLCMD. For GET_FD, this overwrites receive_fd()'s return value after the descriptor is installed, leaking one fd per call. Return handled compat results directly and use native dispatch only for other commands. Fixes: 455a2a1af926 ("vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO") Signed-off-by: Linfeng Sun Signed-off-by: Michael S. Tsirkin Message-ID: <20260908-fix-vduse_dev_compat_ioctl-v1-1-62264d9bfb8d@gmail.com> commit d2929113b15bfc06793b852aeba3d2db6d79fcc9 Author: Jasjeet Rangi Date: Wed Aug 12 16:15:13 2026 -0600 x86/MCE/AMD: Fix inverted interrupt enablement during storm handling mce_amd_handle_storm() currently does the opposite of what storm handling needs: it enables thresholding interrupts when a storm is detected and disables them when the storm subsides. Flip the "on" function argument before passing it to threshold_restart_bank() as it should have been done. To clarify: "on" to mce_handle_storm() means, the storm is on now when "on" is true, and off when "on" is false. [ bp: Simplify. ] Fixes: 5c4663ed1eac ("x86/mce: Handle AMD threshold interrupt storms") Signed-off-by: Jasjeet Rangi Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260812221514.598842-2-jrangi@purestorage.com commit aefdbd574a362dcf7569bada6d72f64a006b9fb9 Author: Jason Andryuk Date: Tue Aug 25 17:48:03 2026 -0400 x86/amd_node: Fix potential NULL pointer dereference amd_smn_read/write() are exported functions around __amd_smn_rw(), so they are always available even if amd_smn_init() fails. In that case, 'amd_roots' is NULL and __amd_smn_rw() will access uninitialized memory. Then, commit: 83518453074d ("x86/amd_node: Add SMN offsets to exclusive region access") added the 'smn_exclusive' flag, which indicated the calls to pci_request_config_region_exclusive() succeeded, to prevent concurrent userspace access. Commit: 0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching") re-ordered initialization so pci_request_config_region_exclusive() is called earlier and a failure exits amd_smn_init() before allocating 'amd_roots'. The setting of 'smn_exclusive' moved to the end of amd_smn_init(), after 'amd_roots' is allocated. It became redundant and can be removed. Replace 'smn_exclusive' with directly checking 'amd_roots', to fix a potential NULL pointer dereference and to simplify the logic. [ bp: Reorg commit message, touchup comment. ] [ mingo: Rebase & further touchups. ] Fixes: 77466b798d59 ("x86/amd_node: Remove dependency on AMD_NB") Signed-off-by: Jason Andryuk Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Reviewed-by: Yazen Ghannam Reviewed-by: Mario Limonciello (AMD) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260825214805.39148-3-jason.andryuk@amd.com commit fcf57d066444dfa5cb46080b1b61cde517249530 Author: Ruairi Anthony Date: Mon Sep 7 12:59:42 2026 +0100 ALSA: hda/realtek: Add quirk for HP Elite Dragonfly Max G2 speaker The HP Elite Dragonfly Max G2 Notebook PC (SSID 103c:8890) uses an ALC285 codec but is missing from the existing HP quirk table, unlike the related "HP Elite Dragonfly G2" entry (SSID 103c:8716). Without the quirk the right speaker amplifier's GPIO is never initialized, leaving it silent while the left speaker plays normally. Apply the existing ALC285_FIXUP_HP_GPIO_AMP_INIT fixup used by the 103c:8716 entry, which resolves the issue. Verified with speaker-test on both channels and confirmed correct routing to both the downward- firing woofer and upward-firing tweeter on each side via the board's passive crossover. Signed-off-by: Ruairi Anthony Link: https://patch.msgid.link/20260907115942.19286-1-ruairi@ruairi.uk Signed-off-by: Takashi Iwai commit 9868f5c077dfe0b606331f2e782484f91a5789a5 Author: Dinh Nguyen Date: Wed Jun 17 11:43:03 2026 -0500 EDAC/altera: Use parent device for devres in altr_portb_setup() Anchor the devres group and the devm-managed IRQ requests in altr_portb_setup() to the actual parent device (device->edac->dev) instead of the embedded struct device inside the copied per-port altr_edac_device_dev. This keeps devres_open_group(), devm_request_irq(), devres_remove_group() and devres_release_group() all referring to the same long-lived device so the group and the resources allocated inside it are torn down together. Fixes: 911049845d70 ("EDAC, altera: Add Arria10 SD-MMC EDAC support") Closes: https://sashiko.dev/#/patchset/20260503212558.2811480-1-dbgh9129%40gmail.com Assisted-by: LLM Signed-off-by: Dinh Nguyen Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260617164303.585555-1-dinguyen@kernel.org commit 8d6cd188508513503805c156165de38e4e4a8615 Author: Zhiling Zou Date: Thu Sep 3 14:23:03 2026 +0800 ipv6: flowlabel: cap duplicate leases per socket ipv6_flowlabel_get() allocates an ipv6_fl_socklist entry for every successful GET. The recheck path for a compatible existing flowlabel links another lease without applying any lease admission check. Repeated GET requests for one shareable label can therefore grow a socket's lease list without bound. Reject a new unprivileged lease once the socket already holds FL_MAX_PER_SOCK leases. Check this on the shared recheck path so reuse of a globally interned label, including the fl_intern() collision path, is covered as well. New-label admission remains under the existing mem_check() policy. Use capable(CAP_NET_ADMIN) rather than ns_capable(), matching mem_check(). An unprivileged user must not bypass the cap by creating a user namespace and a netns where they have CAP_NET_ADMIN, which would still consume host memory. Check the capability only when the socket reaches the limit, so successful unprivileged GET requests below the cap do not generate a capability audit. Do the admission check before updating linger and expires so a rejected GET does not refresh the shared label, matching the existing socket-list allocation failure path. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Ido Schimmel Signed-off-by: Zhiling Zou Reviewed-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/83f8535972ff6e3741548476a1d50dec24c758be.1788415194.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski commit b7c0f8436f077e7f66c9f07714bd57068e2a0c31 Author: Paul Hollinsky Date: Fri Aug 21 01:13:25 2026 -0700 drm/msm/adreno: Only check for PAS when a zap shader is present Commit 0be72be03ca7 ("drm/msm: Switch to generic PAS TZ APIs") replaced the qcom_scm_is_available() check in adreno_zap_shader_load() with qcom_pas_is_available(). These are not equivalent: the former reports whether the SCM transport is up, the latter whether the TrustZone firmware implements the peripheral authentication service. On SC7180 Chromebooks (trogdor) TZ does not implement PAS at all. SCM call-availability queries return 0 for every PAS command while other services answer normally: svc 0x06 cmd 0x01 IS_CALL_AVAIL -> 1 svc 0x02 cmd 0x01 PAS_INIT_IMAGE -> 0 svc 0x02 cmd 0x05 PAS_AUTH_RESET -> 0 svc 0x02 cmd 0x07 PAS_IS_SUPPORTED -> 0 svc 0x0c cmd 0x16 MP_ASSIGN -> 1 svc 0x05 cmd 0x01 IO_READ -> 1 so qcom_scm_probe() never registers a PAS backend and qcom_pas_is_available() is false for the lifetime of the boot. That on its own need not matter, because sc7180-trogdor.dtsi does /delete-node/ &gpu_zap_shader;, and the intended path for such a board is for zap_shader_load_mdt() to find no zap-shader child, clear zap_available, return -ENODEV, and let the caller fall back to SECVID_TRUST_CNTL. The problem is the ordering. zap_available is a static initialised to true and is only ever cleared inside zap_shader_load_mdt(), but adreno_zap_shader_load() consults PAS before calling it. The discovery that decides whether a zap shader is needed at all can therefore never run, the flag is never cleared, and every call returns -EPROBE_DEFER: adreno 5000000.gpu: [drm:adreno_zap_shader_load] *ERROR* PAS is not available msm_dpu ae01000.display-controller: [drm:adreno_load_gpu] *ERROR* gpu hw init failed: -517 Nothing retries that deferral, either. adreno_zap_shader_load() is called from a6xx_hw_init() rather than from probe, so the -EPROBE_DEFER is not a probe return value: it propagates up until adreno_load_gpu() returns NULL. load_gpu() re-attempts on every DRM open while priv->gpu is NULL, each open fails identically, and PAS cannot become available in between - which is why the error repeats and userspace stays on llvmpipe. Move the availability check into zap_shader_load_mdt(), behind the zap-shader node lookup, so the driver only consults PAS once it knows it needs PAS. Boards with no zap-shader node take the intended -ENODEV fallback without ever asking, and boards that do have one keep the qcom_pas_is_available() gate. Fixes: 0be72be03ca7 ("drm/msm: Switch to generic PAS TZ APIs") Link: https://lore.kernel.org/r/20260808034716.58888-1-phollinsky@holtechnik.com Signed-off-by: Paul Hollinsky Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/747583/ Message-ID: <20260821081325.89088-1-phollinsky@holtechnik.com> Signed-off-by: Rob Clark commit 15e2565f1c43771af0bc5324971cabaad79ac286 Author: Daniel Borkmann Date: Mon Sep 7 14:10:25 2026 +0200 selftests/bpf: Add test for bpf_skb_change_tail on csum partial skbs Add a test which builds an ICMP error out of a TCP segment. A tcx prog on the client's egress side trims the first data segment down to the target size and pushes the ICMP error headers in front of it to then reflect the packet back to the sender. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t tc_change_tail [...] #509 tc_change_tail:OK #510 tc_change_tail_pmtu:OK Summary: 2/0 PASSED, 0 SKIPPED, 0/0 FAILED Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260907121025.1923656-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov commit 3b55f350c68a0aceff108f47f9d31f47ebffaf7b Author: Daniel Borkmann Date: Mon Sep 7 14:10:24 2026 +0200 bpf: Fix bpf_skb_change_tail wrt csum partial skbs Cilium generates ICMP "frag needed" replies from BPF when a LB DSR packet exceeds the egress MTU. The reply is built by first trimming the packet down to target size via bpf_skb_change_tail(), and then pushing the ICMP error headers in front of it. The trim is rejected for skbs which carry a checksum offload, e.g. TCP packets aggregated by GRO on ingress where tcp_gro_complete() leaves the skb as CHECKSUM_PARTIAL. __bpf_skb_min_len() raises the minimum length to the end of the L4 checksum field, so a trim to 42 bytes bails out with -EINVAL given a min_len of 52 in this case, and due to that the ICMP generator fails. This is not the case if GRO is turned off. Fix this bpf_skb_change_tail() restriction and drop the checksum offload when the new length no longer covers the checksum field. The BPF program rewrites the skb into an ICMP error and computes the checksum itself anyway. Fixes: 5293efe62df8 ("bpf: add bpf_skb_change_tail helper") Reported-by: Tom Hadlaw Reported-by: Yusuke Suzuki Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260907121025.1923656-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov commit 4ff75f130d1b84f65a6f35a8a0cbca52130127ef Author: Sebastian Sjoholm Date: Thu Sep 3 20:00:44 2026 +0200 net: usb: qmi_wwan: add Quectel RG660QB Add support for the Quectel RG660QB 5G module (USB ID 2c7c:013d). Its QMI interface (interface 4) uses class/subclass/protocol ff/ff/ff like the other recent Quectel modules, so match it the same way. The remaining interfaces are handled by the option driver. Tested with an early sample of the module on a Quectel 5G EVB connected over USB 3 to a Raspberry Pi 5: qmicli talks to the module via /dev/cdc-wdm0. Signed-off-by: Sebastian Sjoholm Link: https://patch.msgid.link/20260903180044.6179-1-sebastian.sjoholm@gmail.com Signed-off-by: Jakub Kicinski commit 7473a66d3af33a4f01ee8dba34e257da95361f04 Merge: dead0c41db3f2a 199271ebc71c1e Author: Jakub Kicinski Date: Mon Sep 7 17:13:57 2026 -0700 Merge branch 'fix-udp-length-overflow-in-edge-cases' Alice Mikityanska says: ==================== Fix UDP length overflow in edge cases These are fixes for rare edge cases of 16-bit UDP length field overflow that might happen on netdevs with MTU >= 64k. Exposed by the new WARN added to udp_set_len_short, reported by syzbot. ==================== Link: https://patch.msgid.link/20260901195714.673548-1-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski commit 199271ebc71c1e0913b2fad988a7bff330a8828a Author: Alice Mikityanska Date: Tue Sep 1 22:57:14 2026 +0300 net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forward Commit 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward") dropped the IP6_MAX_MTU clamp that used to be present in ip6_mtu(). A similar IPv4 commit ac6627a28dbf ("net: ipv4: Consolidate ipv4_mtu and ip_dst_mtu_maybe_forward") preserves the IP_MAX_MTU clamp. Restore the upper bound in the IPv6 flow to avoid potential 16-bit overflows in forwarding paths. Fixes: 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward") Signed-off-by: Alice Mikityanska Suggested-by: Willem de Bruijn Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260901195714.673548-5-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski commit 18a9a4342136c5ae954b37d961c374d369615de2 Author: Alice Mikityanska Date: Tue Sep 1 22:57:13 2026 +0300 selftests: net: Test UDP length overflow with PMTU discover and big MTU Two previous commits fixed overflow of UDP length when setsockopt IP(V6)_MTU_DISCOVER is set to IPV6_PMTUDISC_DO or IP(V6)_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU. This commit adds the selftests that replicate the described steps to reproduce for IPv6 and IPv4, and also one more test that ensures that sending UDP jumbograms over a raw socket is still possible after the fix. Signed-off-by: Alice Mikityanska Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260901195714.673548-4-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski commit 0ae10b6be49b425827659b23bcce498f80eb7182 Author: Alice Mikityanska Date: Tue Sep 1 22:57:12 2026 +0300 net: ipv6: Fix UDP length overflow with PMTU discover and big MTU This commit bounds cork->base.fragsize to IP6_MAX_MTU for UDP sockets to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IPV6_MTU_DISCOVER is set to IPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU. Steps to reproduce (included in the new selftest): 1. Set device MTU bigger than IP6_MAX_MTU. cork->base.fragsize will be set to that MTU in ip6_setup_cork. 2. Set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_PROBE or IPV6_PMTUDISC_DO. It lets maxnonfragsize be set to device MTU (cork->fragsize) in __ip6_append_data, rather than to IP6_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +40 bytes of IPv6 header). Device MTU allows it (it's only one byte bigger than IP6_MAX_MTU, and the device MTU is bigger than that). 4. The UDP length in the built packet is 65536, which overflows the 16-bit length field and triggers the WARN in udp_set_len_short. To avoid breaking sending UDP jumbograms over raw IPv6 sockets, limit the change to UDP sockets only. The original overflow bug with IPv6 and IPV6_PMTUDISC_DO seems to predate git history (verified reproduction on 2.6.21), was fixed later, and then reappeared in commit 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward"), which is chosen as the Fixes tag here. The overflow with IPV6_PMTUDISC_PROBE reproduces since its introduction in commit 628a5c561890 ("[INET]: Add IP(V6)_PMTUDISC_RPOBE"). Fixes: 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward") Reported-by: syzbot+ce13c07d96d04716eaa2@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a6a966c.86abc875.e5c3d.0054.GAE@google.com/ Signed-off-by: Alice Mikityanska Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260901195714.673548-3-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski commit b83641e0ab8b20eefcc4cdc5a059f897375291a2 Author: Alice Mikityanska Date: Tue Sep 1 22:57:11 2026 +0300 net: ipv4: Fix UDP length overflow with PMTU discover and big MTU This commit bounds cork->base.fragsize to IP_MAX_MTU to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IP_MTU_DISCOVER is set to IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU. Steps to reproduce: 1. Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will be set to that MTU in ip_setup_cork. 2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be set to device MTU (cork->fragsize) in __ip_append_data, rather than to IP_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +20 bytes of IPv4 header). Device MTU allows it (it's only one byte bigger than IP_MAX_MTU + IPv4 header, and the device MTU is bigger than that). 4. The UDP length in the built packet is 65536, which overflows the 16-bit length field and triggers the WARN in udp_set_len_short. Note: IP_PMTUDISC_DO with IPv4 is safe, because ip_dst_mtu_maybe_forward always clamps at IP_MAX_MTU, unlike ip6_dst_mtu_maybe_forward. The Fixes tag points at the first commit where I could reproduce the overflow with IPv4 and IP_PMTUDISC_PROBE. Fixes: daba287b299e ("ipv4: fix DO and PROBE pmtu mode regarding local fragmentation with UFO/CORK") Reported-by: syzbot+ce13c07d96d04716eaa2@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a6a966c.86abc875.e5c3d.0054.GAE@google.com/ Signed-off-by: Alice Mikityanska Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260901195714.673548-2-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski commit dead0c41db3f2acd39cfdb469a83472af6f1fb6e Merge: 74f27fc8642b7e ca0b0a86873e8d Author: Jakub Kicinski Date: Mon Sep 7 16:58:45 2026 -0700 Merge branch 'af_unix-minor-fixes-for-msg_oob-and-msg_peek' Kuniyuki Iwashima says: ==================== af_unix: Minor fixes for MSG_OOB and MSG_PEEK. Fahad Alharbi reported blocking recv(MSG_PEEK) could hog CPU due to OOB skb. Patch 1 and 2 fixes the issues and Patch 3 adds tests. ==================== Link: https://patch.msgid.link/20260902202202.892676-1-kuniyu@google.com Signed-off-by: Jakub Kicinski commit ca0b0a86873e8ded39b7fb196dbdc615d9a9a0e4 Author: Kuniyuki Iwashima Date: Wed Sep 2 20:21:52 2026 +0000 selftest: af_unix: Add zero-buffer test for msg_oob.c The previous patches fixed two issues related to zero-length buffer with MSG_PEEK for MSG_OOB skb. Let's add corresponding tests in msg_oob.c. Without this series: # FAILED: 50 / 60 tests passed. # Totals: pass:50 fail:10 xfail:0 xpass:0 skip:0 error:0 With this series: # PASSED: 60 / 60 tests passed. # Totals: pass:60 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260902202202.892676-4-kuniyu@google.com Signed-off-by: Jakub Kicinski commit 6e5ee08eb5858d175da6768d75d163817b6a9d4a Author: Kuniyuki Iwashima Date: Wed Sep 2 20:21:51 2026 +0000 af_unix: Return immediately when manage_oob() returns NULL for 0-length buffer. Fahad Alharbi reported that recv(0, MSG_PEEK) triggers busy-wait in unix_stream_read_generic() if recv() is blocking and the last skb in the queue is MSG_OOB skb. In such a situation, TCP returns 0 immediately regardless of blocking or non-blocking. Let's follow the behaviour. Fixes: 314001f0bf92 ("af_unix: Add OOB support") Reported-by: Fahad Alharbi Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260902202202.892676-3-kuniyu@google.com Signed-off-by: Jakub Kicinski commit 94fd4debd2e3a69cf93e766c8b328a810c228119 Author: Kuniyuki Iwashima Date: Wed Sep 2 20:21:50 2026 +0000 af_unix: Update last skb marker in manage_oob(). Fahad Alharbi reported that blocking recv(MSG_PEEK) could hog CPU due to OOB skb. In the following cases, manage_oob() skips OOB skb(s) and returns NULL for the last recv(MSG_PEEK): socketpair(AF_UNIX, SOCK_STREAM, 0, sk); 1) skb -> OOB skb -> NULL send(sk[0], "ab", 2, MSG_OOB); recv(sk[1], buf, 0, MSG_PEEK); 2) skb -> consumed OOB skb -> NULL send(sk[0], "ab", 2, MSG_OOB); recv(sk[1], buf, 1, MSG_OOB); recv(sk[1], buf, 0, MSG_PEEK); 3) consumed OOB skb -> OOB skb -> NULL send(sk[0], "a", 1, MSG_OOB); recv(sk[1], buf, 0, MSG_OOB); send(sk[0], "b", 1, MSG_OOB); recv(sk[1], buf, 1, MSG_PEEK); Then, @copied is 0 in unix_stream_read_generic() (zero-length buffer, or non-OOB skb is not yet consumed), and unix_stream_data_wait() is called. However, it returns immediately because @last is not updated in unix_stream_read_generic(), and the thread busy-waits for a new skb. Let's update @last in manage_oob(). For MSG_PEEK, @last is updated with the skipped OOB, and for the non-peek case, @last matches the returned value (when !copied) because OOB is unlinked. Note that manage_oob() is inlined and no stack canary is added. Fixes: 22dd70eb2c3d ("af_unix: Don't peek OOB data without MSG_OOB.") Reported-by: Fahad Alharbi Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260902202202.892676-2-kuniyu@google.com Signed-off-by: Jakub Kicinski commit 74f27fc8642b7e8d139796f8c18ee46df393c2b2 Author: Nagamani PV Date: Tue Sep 1 17:53:44 2026 +0200 s390/qeth: allow bridgeport queries despite OS_MISMATCH When HiperSockets interfaces on the same VCHID span different OS families, reads of the sysfs attributes bridge_role and bridge_state fail with -EPERM if bridge port ownership belongs to another OS family. As a result, userspace tools such as 'lszdev -ii' cannot retrieve bridge_role and bridge_state, even though firmware returns valid bridge port data for QUERY_BRIDGE_PORTS requests. The firmware reports IPA_RC_SBP_IQD_OS_MISMATCH (0x0010) to indicate that bridge port ownership belongs to a different OS family. For QUERY_BRIDGE_PORTS operations, firmware still returns valid bridge port data (role=none, state=inactive) together with a primary return code of 0x0000 (success). Allow QUERY_BRIDGE_PORTS requests to return the bridge port data provided by the firmware despite OS_MISMATCH. To make the OS family mismatch visible to userspace, represent the firmware-reported role "none" as "none (OS family mismatch)" while preserving the reported bridge_state. The behavior for non-QUERY bridge port commands is unchanged; SET operations continue to return -EPERM when another OS family owns the bridge port. This restores readability of bridge_role and bridge_state. Fixes: 1b05cf6285c1 ("qeth: Include error message for "OS Mismatch"") Cc: stable@vger.kernel.org Suggested-by: Halil Pasic Reviewed-by: Alexandra Winter Signed-off-by: Nagamani PV Link: https://patch.msgid.link/20260901155344.3561483-1-nagamani@linux.ibm.com Signed-off-by: Jakub Kicinski commit 883e78c9e6007c91be96e99a36c35baf41bc8ed5 Author: Richard Fitzgerald Date: Mon Sep 7 10:36:45 2026 +0100 ASoC: cs35l56: Fix race between kexec and snd_soc_register_component() Use a reboot notifier and a mutex to prevent snd_soc_register_component() from racing with a kexec reboot. This prevents snd_soc_register_component() from manipulating device lists while device_shutdown() is walking them. Commit 1d80a4792f1de ("ASoC: cs35l56: Fix probe deadlock waiting for SoundWire enumeration") moved snd_soc_register_component() out of probe() into a workqueue item. See the description in that commit for a detailed explanation. That change introduces a race between snd_soc_register_component() and kexec. The reboot notifier and mutex prevent the shutdown race. There is one remaining race with KEXEC_JUMP because it does not invoke reboot notifiers or freeze freezable workqueues. But KEXEC_JUMP is rarely used and is supported on only two architectures (x86 and SuperH). It does not appear to be enabled by default in any distro. It is also unlikely there will be a KEXEC_JUMP before snd_soc_register_component() has had the opportunity to execute. Fixing this can be deferred to a future patch. Fixes: 1d80a4792f1de ("ASoC: cs35l56: Fix probe deadlock waiting for SoundWire enumeration") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260907093645.27407-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit d7808b37da0a619cf1fa541c2384e783fecc2480 Author: Karl Mehltretter Date: Sat Sep 5 17:20:58 2026 +0200 virtio_input: stop callbacks before unregistering input device virtinput_remove() unregisters the input device before resetting the virtio device. virtinput_recv_events() drops vi->lock around input_event(), so clearing vi->ready does not stop a callback that passed the entry check. It can still use vi->idev, requeue buffers and kick the queue. Reset first, as virtinput_freeze() already does. With the preceding core change, reset waits for callbacks before input_unregister_device() can free vi->idev. Recheck vi->ready after taking the lock again: keep draining completed events so an input packet is not truncated, but stop requeueing buffers and kicking the queue. With evdev attached, input_unregister_handle() currently waits for an RCU grace period, which also waits out IRQ callbacks. This masks the lifetime bug on PCI and MMIO, but does not protect sleepable callbacks on other transports. Fixes: 271c865161c5 ("Add virtio-input driver.") Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Michael S. Tsirkin Message-ID: <20260905152059.89560-3-kmehltretter@gmail.com> commit 81489b32a21c9360f8750d1fb600155d27452e19 Author: Xiong Weimin Date: Wed Aug 5 11:29:31 2026 +0800 virtio_input: reset device if input_register_device() fails Probe marks the device DRIVER_OK with virtio_device_ready() before calling input_register_device(). If registration fails, the error path cleared vi->ready and called del_vqs() while the device was still live, so the device could keep DMA to queues that were already torn down. Match remove/freeze: call virtio_reset_device() on that path before tearing down the virtqueues. Fixes: 271c865161c5 ("Add virtio-input driver.") Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <20260805032931.1606652-1-xiongweimin@kylinos.cn> commit e4f4761879a230aa59e569102a6ab9851847d833 Author: Jia Jia Date: Fri Aug 28 16:57:21 2026 +0800 vhost: invalidate vring access on IOTLB transitions 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> commit fa2c25b4add57888acfa89e398389e267bff3dcf Author: Jia Jia Date: Sun Aug 30 10:33:54 2026 +0800 vduse: validate virtqueue alignment 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> commit 7474f3a61043934e9c351febc56f4d85cd5ddc96 Author: Nikhil Date: Sun Aug 30 04:24:57 2026 +0530 vduse: do not take dev->rwsem in the virtqueue kick path vduse_vq_kick() runs in the context of the vdpa .kick_vq callback. With the virtio_vdpa bus driver that callback is invoked by virtqueue_notify() from the virtio device driver, which may be an atomic context: virtio-blk kicks from ->queue_rq(), which blk-mq dispatches under rcu_read_lock() (the tag set does not use BLK_MQ_F_BLOCKING), and virtio-net kicks from its xmit path with the tx queue lock held. Commit b282418bc366 ("vduse: Add suspend") made vduse_vq_kick() take dev->rwsem for reading in order to check dev->suspended. down_read() may sleep, so with CONFIG_DEBUG_ATOMIC_SLEEP the first I/O on a VDUSE-backed virtio-blk device bound to virtio_vdpa now triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1573 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 27, name: kworker/1:0H preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 3 locks held by kworker/1:0H/27: #0: ((wq_completion)kblockd){+.+.}-{0:0}, at: process_one_work+0xac7/0xcf0 #1: ((work_completion)(&(&hctx->run_work)->work)){+.+.}-{0:0}, at: process_one_work+0x51f/0xcf0 #2: (rcu_read_lock){....}-{1:3}, at: blk_mq_run_work_fn+0x119/0x220 Workqueue: kblockd blk_mq_run_work_fn Call Trace: dump_stack_lvl+0x80/0xa0 __might_resched+0x231/0x370 down_read+0x73/0x330 vduse_vq_kick+0x30/0x120 virtio_vdpa_notify+0x63/0x80 virtqueue_notify+0x45/0x70 virtio_queue_rq+0x19d/0x300 blk_mq_dispatch_rq_list+0x269/0xe20 __blk_mq_sched_dispatch_requests+0x761/0xa60 blk_mq_sched_dispatch_requests+0x6b/0xc0 blk_mq_run_work_fn+0x143/0x220 process_one_work+0x581/0xcf0 worker_thread+0x2fc/0x5a0 kthread+0x1cc/0x210 ret_from_fork+0x3c4/0x540 ret_from_fork_asm+0x1a/0x30 Without CONFIG_DEBUG_ATOMIC_SLEEP, a kick that finds the rwsem write-locked by vduse_dev_reset() or vduse_vdpa_suspend() blocks inside an RCU read-side critical section. The vhost_vdpa path kicks from the vhost worker, i.e. process context, which is why this went unnoticed. Check dev->suspended under vq->kick_lock instead, which the kick path already takes, and have vduse_vdpa_suspend() cycle every virtqueue's kick_lock after setting the flag. A kick that observed suspended == false has thus finished signalling before suspend returns, which is the guarantee the rwsem used to provide. The flag is now also read outside the rwsem, so access it with READ_ONCE()/WRITE_ONCE(). Fixes: b282418bc366 ("vduse: Add suspend") Signed-off-by: Nikhil Signed-off-by: Michael S. Tsirkin Message-ID: <20260829225457.1037867-1-nikhilljatt@gmail.com> commit 4e3ec5b1b427e02082e8b3491731f8c3bcf85c53 Author: Dongli Zhang Date: Sun Aug 2 10:24:56 2026 -0700 vhost-scsi: clamp max_io_vqs module parameter max_io_vqs is currently validated only when a vhost-scsi device is opened. This allows sysfs to show values larger than the driver will actually use, e.g. writing 2048 succeeds even though vhost_scsi_open() later clamps it to VHOST_SCSI_MAX_IO_VQ. This makes the sysfs value differ from the value that will actually be used. hv# echo 2048 > /sys/module/vhost_scsi/parameters/max_io_vqs hv# cat /sys/module/vhost_scsi/parameters/max_io_vqs 2048 [ 315.630495] Invalid max_io_vqs of 2048. Using 1024. Keep accepting out-of-range values for compatibility, but clamp them in the module parameter setter and store the effective value. This preserves the existing behavior that invalid values do not make module loading or sysfs writes fail. It also makes reads report the value that will actually be used. With the parameter value kept in range, remove the duplicate validation from vhost_scsi_open(). Signed-off-by: Dongli Zhang Reviewed-by: Mike Christie Reviewed-by: Stefan Hajnoczi Signed-off-by: Michael S. Tsirkin Message-ID: <20260802172534.260047-3-dongli.zhang@oracle.com> commit c952e607cb4aa3640e5ae07243d3f609dac94424 Author: Dongli Zhang Date: Sun Aug 2 10:24:55 2026 -0700 vhost-scsi: use kvzalloc for vq array allocation vhost_scsi_open() allocates one "struct vhost_scsi_virtqueue" for each virtqueue. With large max_io_vqs values, this array can require a high-order contiguous allocation and trigger a page allocator warning. hv# cat /sys/module/vhost_scsi/parameters/max_io_vqs 256 [ 766.075787] ------------[ cut here ]------------ [ 766.077030] WARNING: mm/page_alloc.c:5280 at __alloc_frozen_pages_noprof+0x32c/0x15c0, CPU#23: qemu-system-x86/5964 ... ... [ 766.080351] RIP: 0010:__alloc_frozen_pages_noprof+0x32c/0x15c0 ... ... [ 766.085813] Call Trace: [ 766.085969] [ 766.086098] ? srso_alias_return_thunk+0x5/0xfbef5 [ 766.086365] ? context_struct_compute_av+0x38a/0x4b0 [ 766.086652] alloc_pages_mpol+0x9f/0x170 [ 766.086883] ___kmalloc_large_node+0xb6/0xd0 [ 766.087124] ? srso_alias_return_thunk+0x5/0xfbef5 [ 766.087389] __kmalloc_large_node_noprof+0x18/0xa0 [ 766.087655] __kmalloc_noprof+0x3a0/0x440 [ 766.087877] ? vhost_scsi_open+0xcb/0x2d0 [vhost_scsi] [ 766.088162] vhost_scsi_open+0xcb/0x2d0 [vhost_scsi] [ 766.088449] misc_open+0x123/0x160 [ 766.088679] chrdev_open+0xb1/0x230 [ 766.088885] ? __pfx_chrdev_open+0x10/0x10 [ 766.089157] do_dentry_open+0x11a/0x470 [ 766.089389] vfs_open+0x29/0xf0 [ 766.089596] path_openat+0x7c0/0x1100 [ 766.089821] do_file_open+0xdd/0x190 [ 766.090032] ? srso_alias_return_thunk+0x5/0xfbef5 [ 766.090332] do_sys_openat2+0x7e/0x100 [ 766.090601] __x64_sys_openat+0x51/0xa0 [ 766.090857] do_syscall_64+0xfe/0x590 [ 766.091087] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 766.091411] RIP: 0033:0x7f9525a11fa6 The array does not require physical contiguity, so allocate it with kvzalloc_objs() and free it with kvfree(). Signed-off-by: Dongli Zhang Reviewed-by: Mike Christie Reviewed-by: Stefan Hajnoczi Signed-off-by: Michael S. Tsirkin Message-ID: <20260802172534.260047-2-dongli.zhang@oracle.com> commit 93fa09455fb1a9624b73d42ac1f83771f4818e80 Author: Andrew Stellman Date: Fri Sep 4 10:13:18 2026 -0400 virtio-pci: return IRQ_HANDLED after non-zero ISR vp_interrupt() reads the ISR before dispatching config-change and vring handling. Reading the ISR also clears it, so once the read returns non-zero the interrupt was from this device and has already been consumed. Currently vp_interrupt() returns the result of vp_vring_interrupt(). For a config-change interrupt with no vring work, that can return IRQ_NONE even though the ISR was non-zero and the interrupt was handled. Call vp_vring_interrupt() for any queue work, but once the ISR is non-zero return IRQ_HANDLED. Tested with QEMU virtio-blk-pci forced to INTx using vectors=0 and pci=nomsi. On an idle device, 200 config-change interrupts were generated using QMP block_resize. Before this change, irq_handler_exit reported ret=unhandled and /proc/irq/11/spurious increased from 0 to 200 unhandled interrupts. After this change, irq_handler_exit reported ret=handled and the unhandled count remained at 0. The issue was found during an LLM-assisted Quality Playbook review. Fixes: 77cf524654a8 ("virtio_pci: split up vp_interrupt") Suggested-by: Michael S. Tsirkin Assisted-by: LLM Signed-off-by: Andrew Stellman Message-ID: <20260904141318.30278-1-astellman@stellman-greene.com> Signed-off-by: Michael S. Tsirkin commit 8dd505a45de0e63829d8bb4116b1d66db64813be Author: Eugenio Pérez Date: Thu Sep 3 10:18:31 2026 +0200 virtio: add Eugenio Pérez as Maintainer Signed-off-by: Eugenio Pérez Reviewed-by: Stefano Garzarella Signed-off-by: Michael S. Tsirkin Message-ID: <20260903081831.2129729-1-eperezma@redhat.com> commit 84cd1f879968ae75da15c25de4cb390428e89e6d Author: Linfeng Sun Date: Thu Sep 3 12:13:33 2026 +0800 vhost: limit outstanding IOTLB misses per virtqueue vhost allocates a message node whenever address translation misses. If userspace reads these messages without resolving them, repeated virtqueue kicks can grow the pending message list until the host runs out of memory. Virtqueue processing stops at the first translation miss and cannot make progress until userspace installs a mapping. Keep a pointer to that outstanding message in the virtqueue and suppress additional misses until the node is resolved or discarded. The pointer remains set while the message is queued for reading, copied to userspace, or waiting on the pending list. Clear it under the IOTLB lock when the owning node is freed. This bounds outstanding miss messages by the fixed number of virtqueues without introducing an arbitrary queue limit. Signed-off-by: Linfeng Sun Signed-off-by: Michael S. Tsirkin Message-ID: <20260903-fix-kernel-panic-in-vhost_iotlb_miss_pending_list-v1-1-39b8cd427978@gmail.com> commit 7034e6c8dadaf4a2c95669890095ebafa8d9cee7 Author: Laurent Vivier Date: Tue Aug 18 15:39:13 2026 +0200 MAINTAINERS: Add a section for virtio-rng At Michael's request, add a MAINTAINERS entry for the virtio-rng driver and list myself as its maintainer. I already maintain the corresponding QEMU implementation. Cc: Michael S. Tsirkin Signed-off-by: Laurent Vivier Signed-off-by: Michael S. Tsirkin Message-ID: <20260818133913.162471-1-lvivier@redhat.com> commit 0d195797a80b77f2ec56718cd26d3ee65d0093e8 Author: Linfeng Sun Date: Tue Sep 1 17:48:42 2026 +0800 vdpa_sim_net: check TX pull result before RX copy vringh_iov_pull_iotlb() returns a signed byte count. A failed TX pull is currently added to the unsigned byte counter and then passed as a size_t length to receive_filter() and vringh_iov_push_iotlb(). A negative error can therefore become a large length in the RX path. Handle non-positive pull results before every length use. Count the TX error and complete the consumed TX descriptor with zero bytes. I found this bug myself, though the patch was written with AI assistance. Fixes: cfe226892913 ("vdpa_sim: filter destination mac address") Assisted-by: OpenAI-Codex:GPT-5 Signed-off-by: Linfeng Sun Signed-off-by: Michael S. Tsirkin Message-ID: <20260901094842.25875-1-linfeng.sun.dev@gmail.com> commit 0a8693f00c408d85f086ad85d29e7030bf1e2055 Author: Linfeng Sun Date: Tue Sep 1 17:48:00 2026 +0800 vdpa_sim_blk: reject out-of-range sector starts vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance. Fixes: 7d189f617f83 ("vdpa_sim_blk: implement ramdisk behaviour") Assisted-by: OpenAI-Codex:GPT-5 Signed-off-by: Linfeng Sun Signed-off-by: Michael S. Tsirkin Message-ID: <20260901094800.25475-1-linfeng.sun.dev@gmail.com> commit ca2c2165a02e499b591a367224346a7e52664d9c Author: Xiong Weimin Date: Tue Aug 4 17:26:49 2026 +0800 virtio-vdpa: Use queue id when setting vq affinity When optional queues are skipped, pass the compressed vDPA queue id to set_vq_affinity() so affinity is applied to the queue that was actually created. Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <20260804092649.1344478-1-xiongweimin@kylinos.cn> commit 6519ca235131c3281a83cc9e8b05af709ab98a89 Author: Xiong Weimin Date: Tue Aug 4 17:26:36 2026 +0800 vdpa: octeon_ep: Check dev_set_name() in dev add Handle dev_set_name() failures before registering the vDPA device so allocation is unwound through the existing put_device() path. Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <20260804092636.1344431-1-xiongweimin@kylinos.cn> commit 4d470be71196ca0ce302e6623454533dc31b465b Author: Xiong Weimin Date: Wed Aug 5 09:51:52 2026 +0800 vdpa: ifcvf: Put device on unsupported feature error Route unsupported provisioned features through the common error path after vdpa_alloc_device() so the allocated device and adapter pointer are released consistently. Fixes: 46fc0917bbab ("vDPA/ifcvf: implement features provisioning") Cc: stable@vger.kernel.org # v6.3+ Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <178589471294.1556376.4816776800128323034@kylinos.cn> commit e847542ab0545c73354849126150206c29d83929 Author: Xiong Weimin Date: Wed Aug 5 09:51:53 2026 +0800 vdpa: solidrun: Free IRQs after request failure Unwind IRQs already requested by snet_request_irqs() before returning a VQ IRQ request error so a later DRIVER_OK retry starts from a clean state. The IRQs are requested and freed while the PCI device remains bound, so the driver cannot wait for devres cleanup at detach time. Fixes: 51a8f9d7f587 ("virtio: vdpa: new SolidNET DPU driver.") Cc: stable@vger.kernel.org # v6.3+ Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <178589471328.1556376.15570536900532373521@kylinos.cn> commit 9ab9b4f4eb4288588707ec359ac3d5b7ccf07fa6 Author: Xiong Weimin Date: Tue Aug 4 17:26:07 2026 +0800 vdpa: alibaba: Keep DRIVER_OK clear if IRQ setup fails If requesting MSI-X interrupts fails while DRIVER_OK is being set, leave the device status unchanged instead of advertising a ready device without working interrupts. Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <20260804092608.1344269-1-xiongweimin@kylinos.cn> commit 6601d5a00899e7fa7e6b2d18113cee385ed3801b Author: Xiong Weimin Date: Thu Aug 6 08:58:09 2026 +0800 vdpa/pds: check virtqueue notify mapping vp_modern_map_vq_notify() can fail and return NULL. Check the notify mapping while adding a pds vDPA device and use the existing teardown path instead of storing a NULL doorbell pointer in the virtqueue state. Signed-off-by: Xiong Weimin Reviewed-by: Brett Creeley Signed-off-by: Michael S. Tsirkin Message-ID: <20260806005809.1875257-1-xiongweimin@kylinos.cn> commit d14d693adb055e98ca705822ba6daebc18602d9a Author: Xiong Weimin Date: Wed Aug 5 11:29:37 2026 +0800 virtio_mmio: disable IRQ wake before free_irq When the DT node has "wakeup-source", vm_find_vqs() calls enable_irq_wake() on the shared IRQ, but vm_del_vqs() freed that IRQ without a matching disable_irq_wake(). That leaves a wake reference behind and can warn on later free_irq()/request_irq() cycles. Record whether enable_irq_wake() succeeded, and disable it in vm_del_vqs() before free_irq(). Fixes: 02213273f72a ("virtio_mmio: add support to set IRQ of a virtio device as wakeup source") Cc: stable@vger.kernel.org Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <20260805032937.1606737-1-xiongweimin@kylinos.cn> commit 62be4e3e5f5f947fbf765b914cebdc478f715d12 Author: Yu Zhang Date: Fri Aug 7 20:00:25 2026 +1000 vhost-vdpa: protect config_ctx from being freed under the config callback vhost_vdpa_config_cb() loads v->config_ctx and signals it without taking a reference and without holding any lock: struct eventfd_ctx *config_ctx = v->config_ctx; if (config_ctx) eventfd_signal(config_ctx); VHOST_VDPA_SET_CONFIG_CALL replaces that field and drops what is normally the last reference to the old context: swap(ctx, v->config_ctx); if (ctx) eventfd_ctx_put(ctx); eventfd_ctx_put() drops the last kref and frees the context immediately, with no RCU grace period, so a callback that has already loaded the pointer goes on to dereference freed memory. The two sides share no lock: the ioctl runs under vhost_dev.mutex, while the parent invokes the callback from its own interrupt or workqueue context. This is not the reopen refcount underflow fixed by commit f6bbf0010ba0 ("vhost-vdpa: fix use-after-free of v->config_ctx"), which was about vhost_vdpa_config_put() leaving a stale pointer behind. Here the pointer is maintained correctly and it is the read side that is unprotected. With VDUSE as the parent this is reachable from userspace with access to /dev/vduse (root by default). VDUSE_DEV_INJECT_CONFIG_IRQ queues dev->inject, and vduse_dev_irq_inject() runs the callback under VDUSE's own dev->irq_lock, which vhost does not hold. vduse_dev_reset() does flush_work(&dev->inject), but VHOST_VDPA_SET_CONFIG_CALL never goes through reset, so an inject already in flight is not waited for. A process that injects config interrupts on the VDUSE fd while another thread swaps the call fd on the vhost-vdpa fd hits it in seconds: BUG: KASAN: slab-use-after-free in native_queued_spin_lock_slowpath Read of size 4 at addr ffff888107d21808 by task kworker/u17:1/2993 Workqueue: vduse-irq vduse_dev_irq_inject Call Trace: native_queued_spin_lock_slowpath+0x97/0x5b0 _raw_spin_lock_irqsave+0xd4/0xe0 eventfd_signal_mask+0x69/0x120 vhost_vdpa_config_cb+0x34/0x50 vduse_dev_irq_inject+0x46/0x60 process_one_work+0x468/0x950 Allocated by task 2992: do_eventfd+0x50/0x200 __x64_sys_eventfd2+0x2e/0x40 Freed by task 2992: eventfd_ctx_put+0xb9/0xc0 vhost_vdpa_unlocked_ioctl+0x116c/0x2190 Add a spinlock covering every access to config_ctx, so the callback either signals a context that is still alive or observes NULL, and the put happens only once no callback can reach the old value. Clearing the parent's callback before the put would not be enough: of the in-tree set_config_cb() implementations only VDUSE takes a lock, the rest store the pointer unlocked, so that would not order against an in-flight invocation. Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa") Signed-off-by: Yu Zhang Signed-off-by: Michael S. Tsirkin Message-ID: <20260807100025.19750-3-yuz08559@gmail.com> commit e74a9fa50749b9940b4fb13199652325e08d3c4a Author: Yu Zhang Date: Fri Aug 7 20:00:24 2026 +1000 vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value into v->config_ctx before checking it, so on failure the field briefly holds an ERR_PTR: ctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); swap(ctx, v->config_ctx); if (!IS_ERR_OR_NULL(ctx)) eventfd_ctx_put(ctx); if (IS_ERR(v->config_ctx)) { long ret = PTR_ERR(v->config_ctx); v->config_ctx = NULL; return ret; } Commit 0bde59c1723a ("vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails") added that clearing, and spelled out the invariant the rest of the file relies on: "we consider 'v->config_ctx' valid if it is not NULL". The window between the swap and the clearing still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config interrupt delivered inside the window hands the ERR_PTR to eventfd_signal(). Check the fd before installing it instead. That closes the window and matches how vhost_vring_ioctl() handles the same failure for the vq call fd. It also stops a rejected fd from tearing down a config interrupt that was working: until now the swap replaced the live context and put it, so after an EBADF the device silently stopped delivering config interrupts until userspace installed a new fd. Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa") Signed-off-by: Yu Zhang Signed-off-by: Michael S. Tsirkin Message-ID: <20260807100025.19750-2-yuz08559@gmail.com> commit ccb1dc7c527f8c925925cf92afc76ae590dac311 Author: Jia Jia Date: Mon Aug 10 09:03:00 2026 +0800 vhost/vdpa: reject VRING_NUM larger than device max vhost_vring_set_num() accepts any non-zero power-of-two queue size that fits in 16 bits. vhost-vdpa then passes that value to set_vq_num() without comparing it with get_vq_num_max(). A process with access to /dev/vhost-vdpa-* can therefore configure a queue larger than the device advertises. With vdpa_sim, the worker can walk descriptors beyond the mapped descriptor ring. KASAN reports a 16-byte out-of-bounds read, corresponding to one vring_desc, in the vringh IOTLB path: BUG: KASAN: out-of-bounds in _copy_from_iter Read of size 16 copy_from_iotlb copydesc_iotlb vringh_getdesc_iotlb vdpasim_net_work Cache get_vq_num_max() immediately after reset. Some backends derive it from writable queue-size state, so querying it after SET_NUM may return the current size instead of the device capability. Invalidate the cached value before reset so a failed reset leaves SET_NUM disabled. For VHOST_SET_VRING_NUM, copy the complete vring state once and use the same index and size for validation, vq->num, and set_vq_num(). This ensures that validation and use operate on the same copied values. Fixes: 4c8cf31885f6 ("vhost: introduce vDPA-based backend") Signed-off-by: Jia Jia Signed-off-by: Michael S. Tsirkin Message-ID: <20260810010300.132959-1-physicalmtea@gmail.com> commit 894f98e73983f37354214a89a3a7fd35bf9e3072 Author: Jia Jia Date: Wed Aug 19 10:12:30 2026 +0800 virtio_console: do not free control-out buffers on remove __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): free_buf remove_vqs virtcons_remove unbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it. Fixes: a7a69ec0d8e4 ("virtio_console: free buffers after reset") Signed-off-by: Jia Jia Signed-off-by: Michael S. Tsirkin Message-ID: <20260819021230.292696-1-physicalmtea@gmail.com> commit 3f9a0fceb730f5107d52421ead5568eae25a0049 Author: Karl Mehltretter Date: Fri Aug 21 23:39:53 2026 +0200 virtio: fix use-after-free in unregister_virtio_device() device_unregister() is device_del() plus put_device(). When the caller holds no extra reference, that drops the last one and runs the release callback, which for several transports frees the memory the embedded struct virtio_device sits in. unregister_virtio_device() then calls virtio_debug_device_exit(), which reads dev->debugfs_dir out of the freed object. Affected transports are the ones whose release callback frees and whose remove path takes no reference: virtio_mmio, virtio_vdpa, virtio_uml, mlxbf-tmfifo and virtio_ccw. virtio_pci is unaffected because virtio_pci_remove() brackets the call with get_device() and put_device(). Remove the debugfs entries before the device can go away. They are only accessed through the protected debugfs interface, so debugfs_remove_recursive() waits for in-progress file operations before returning. Tearing them down while the device is still alive is therefore safe. Reproduced on User-Mode Linux with CONFIG_KASAN and CONFIG_VIRTIO_DEBUG by unbinding a virtio-uml device: BUG: KASAN: slab-use-after-free in virtio_debug_device_exit+0x36/0x4d Read of size 8 at addr 00000000616e0b10 by task init/1 __asan_report_load8_noabort virtio_debug_device_exit+0x36/0x4d unregister_virtio_device+0x48/0x75 virtio_uml_remove platform_remove device_release_driver_internal unbind_store Freed by task 1: kfree virtio_uml_release_dev device_release kobject_put put_device device_unregister With this applied, the report is gone and unbind is clean. Fixes: 96a8326d69ff ("virtio: add debugfs infrastructure to allow to debug virtio features") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Signed-off-by: Michael S. Tsirkin Message-ID: <20260821213953.76906-1-kmehltretter@gmail.com> commit 75d276e5bb68778b2916f98a2bc30f142ebadc64 Author: Alexander Graf Date: Mon Aug 17 22:32:29 2026 +0000 virtio_ring: fix stale descriptor flags after a failed packed add 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> commit 22728415a9cc8da859c7b95b49eb405fb3debd6a Author: Aaron Welwood Date: Sun Sep 6 21:17:38 2026 -0600 ASoC: amd: yc: add quirk for Acer Nitro AN17-41 internal mic The Acer Nitro AN17-41 uses "RB" as its board vendor and has no entry in yc_acp_quirk_table, so acp6x_probe() finds no DMI match, registers no card, and the internal digital microphone records only silence. Add a quirk entry for it so the DMIC is enabled. Signed-off-by: Aaron Welwood Link: https://patch.msgid.link/20260907031738.17257-1-abwelwood@gmail.com Signed-off-by: Mark Brown commit 1017911fcc03584b6854b1b8f0aafeb25f5a8d25 Author: Sascha Bischoff Date: Mon Sep 7 16:49:50 2026 +0000 irqchip/gic-v5: Preserve ICC_CR0_EL1 state In addition to EN, ICC_CR0_EL1 contains other fields, such as LINK and LINK_IDLE. The driver only needs to modify EN, and must preserve the values of all other fields when enabling or disabling the CPU interface. Define the missing LINK and LINK_IDLE fields, and use read-modify-write accesses to update EN without affecting the rest of ICC_CR0_EL1. Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support") Reported-by: Sashiko Signed-off-by: Sascha Bischoff Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260907164945.714545-1-sascha.bischoff@arm.com Closes: https://lore.kernel.org/r/20260807121703.D4B7A1F00A3A@smtp.kernel.org commit 9c3882ec10399c14c59b7e4599d33c4395367c37 Author: hpp.iscas Date: Sat Sep 5 21:32:10 2026 +0800 ASoC: mt6351: Publish the OF module alias The MT6351 codec platform driver uses mt6351_of_match to bind devices with compatible mediatek,mt6351-sound. The codec can be a separate module, but the OF table is not exported to module alias metadata. Publish the existing table without changing codec matching, register access or the machine-driver configuration. Fixes: a74d51ba0e17 ("ASoC: add mt6351 codec driver") Signed-off-by: hpp.iscas Link: https://patch.msgid.link/20260905133210.63803-1-hppiscas@163.com Signed-off-by: Mark Brown commit 28924df2a08f440c73991b83028032c901de2ae4 Merge: c297ed90fbba72 aadea57f532882 Author: Linus Torvalds Date: Mon Sep 7 10:26:56 2026 -0700 Merge tag 'perf-tools-fixes-for-v7.3-2026-09-07' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools Pull perf tools fixes from Namhyung Kim: "Two simple fixes for this cycle: - Do not use separate debug files for Intel PT decoding - Fix size of raw data in the PowerPC VPA DTL samples" * tag 'perf-tools-fixes-for-v7.3-2026-09-07' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: perf powerpc-vpadtl: Fix raw_size of DTL samples perf symbol: Do not use debug file as the binary type commit f3e6ef13e24c9f26dca0d35de57fcdf04f78e378 Author: Donggeun Yoo Date: Fri Sep 4 19:56:24 2026 +0900 regulator: pf1550: fix which regulator is notified The interrupt handler distinguishes the rail that reported the fault, but the body ignores it. Every SW interrupt walks the regulator array looking for the name "SW3" and every LDO interrupt looks for "LDO3", so an over-current on SW1 is reported to the consumers of SW3 while the consumers of SW1 hear nothing. The lookup itself is unreliable as well. rdev_get_name() returns the device tree regulator-name property whenever the board supplies one, and only falls back to the name in the driver descriptor when it does not. The binding example for this device sets regulator-name to "sw3" and "ldo3", which strcmp() does not match against the upper case literals used here, so a board that follows the documentation gets no over-current notification at all. A board that names its rails after the schematic does not match either. No other driver in the tree selects a notification target this way. Replace the name lookup with rdev_get_id(), which returns the descriptor id set by the driver and cannot be overridden from the device tree, and take both the id and the event from a table indexed by the interrupt. The die temperature interrupts keep notifying every regulator since they report a chip wide condition. Fixes: 7320d41c29bb ("regulator: pf1550: Add support for regulator") Signed-off-by: Donggeun Yoo Link: https://patch.msgid.link/20260904105624.48577-1-donggeunyoo.kernel@gmail.com Signed-off-by: Mark Brown commit c297ed90fbba72d32b7759aae362b36d15b2db1f Merge: df2908090cda36 f06c2d26d1999d Author: Linus Torvalds Date: Mon Sep 7 10:01:38 2026 -0700 Merge tag 'configfs-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/leitao/linux Pull configfs fixes from Breno Leitao: - A symlink racing with rmdir of its target could reach a freed ->ci_dentry. The reference that get_target() takes pins the config_item, not its dentry; the dentry is pinned by DCACHE_PERSISTENT, which configfs_remove_dir() drops while the item is still alive. Take the target's configfs_dirent under ->d_lock instead of chasing ->ci_dentry. - configfs_rmdir() left the dentry hashed across the final put of the item, and configfs_get_config_item() treats a hashed dentry as proof of a live item. A concurrent symlink could therefore resurrect a dying item and hit a use-after-free. Unhash in configfs_remove_dir(), while the item is still guaranteed to be there. Both issues were found by syzbot. * tag 'configfs-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/leitao/linux: configfs: unhash the dentry before dropping the item in rmdir configfs: pin the symlink target's dirent instead of chasing ->ci_dentry commit 7a099b347fef536a84068076e2d384f044e5cfc5 Author: Ilya Maximets Date: Tue Aug 25 17:27:24 2026 +0200 netfilter: report NLM_F_DUMP_FILTERED when all is filtered out NLM_F_DUMP_FILTERED is only set on data elements in the conntrack dump. But when everything is filtered out it is confusing for the user space, since the flag is not reported anymore and it looks like the table was empty, which may or may not be the case. 'answer_flags' were introduced precisely for this use case, and the conntrack dump should set the flag in there in case the filtering was applied. This is important, for example, to be able to tell if the filters are supported or not by the kernel without modifying the kernel state. With the proper reporting of NLM_F_DUMP_FILTERED on NLMSG_DONE, an application in user space can just try and dump with an arbitrary filter without worrying that there could be no matching entry. The reported flag will signal that the filtering was applied and therefore supported. Fixes: cb8aa9a3affb ("netfilter: ctnetlink: add kernel side filtering for dump") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso commit da4afc5a956d407443988e97a4d4ca14c2e999c7 Author: Florian Westphal Date: Tue Aug 25 15:11:24 2026 +0200 netfilter: ip6_tables: set F_PROTO when proto value is nonzero The ip6tables traverser doesn't search the extension header chain unless userspace did set the IP6T_F_PROTO flag. This also means that userspace that sets the e->ipv6.proto flag can bypass the protocol check for the rule by not setting this flag. That in turn means that all ip6_tables modules and targets that want to reject rules without '-p' flag MUST also check for that flag. Not all do, likely because they got copied from iptables which lacks this flag (no extension headers). Instead of fixing up all the relevant targets, emulate ip6tables behaviour in the kernel (like nft_compat.c) and set the flag if the protocol is set. Reported-by: Zhiling Zou Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso commit 0bd7ed1a3263c26cf38fffc035b539a70d88667b Author: Florian Westphal Date: Tue Aug 25 12:28:36 2026 +0200 netfilter: arp_tables: remove the 32bit compat interface This feature is required to use 32bit arptables binary on 64bit kernels. It's already off in many distributions including Debian and Fedora for many years. Zap arptables first, it's the most esoteric of the 4 flavors. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso commit 387d744fa7e499d2c3748a4e60e02ebb24e7fb16 Author: Florian Westphal Date: Tue Aug 25 03:36:03 2026 +0200 netfilter: nfnetlink_log: cope with concurrent instance destruction Instances are refcounted. However, only memory release happens on the 1 -> 0 transition; the unlink from hashes can occur with any refcount. Uncooperative userspace can force a situation where a queue is pending for destruction from netlink event while a different socket with same portid processes an UNBIND request. With right timing, this will unhash the instance again: Oops: general protection fault, [..] Call Trace: nfulnl_recv_config+0x31a/0xd50 nfnetlink_rcv_msg+0x7c2/0xeb0 Fixes: 0597f2680d66 ("[NETFILTER]: Add new "nfnetlink_log" userspace packet logging facility") Reported-by: Eulgyu Kim Reported-by: Jaeyoung Chung Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso commit 09f1294ee2abee7fe1c2d600671498b7642e0fe0 Author: Filipe Manana Date: Thu Sep 3 17:24:16 2026 +0100 btrfs: tree-checker: validate name length for extref items We are validating the name length of inode ref items, but we miss the same validation for extref items. Sashiko pointed this out while reviewing other patch. Add the missing validation, similar to what was done in commit 3dc22abc21f5 ("btrfs: tree-checker: validate INODE_REF's namelen"). Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba commit b18f0f8334e6d7e4ed4baf1f404658537659cb57 Author: Filipe Manana Date: Thu Sep 3 16:24:43 2026 +0100 btrfs: tree-checker: validate parent field for inode extref items For a subvolume tree, the parent field of an inode extref item corresponds to an inode number, and that must always be within the range: [ BTRFS_FIRST_FREE_OBJECTID (256), BTRFS_LAST_FREE_OBJECTID (-256) ] Add a check for that in check_inode_extref(). Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba commit 2a4513ab53361360329b7ad1496d666b7433289e Author: Filipe Manana Date: Thu Sep 3 16:16:32 2026 +0100 btrfs: tree-checker: validate key offset for inode ref keys For a subvolume tree, the offset of an inode ref key corresponds to an inode number, and that must always be within the range: [ BTRFS_FIRST_FREE_OBJECTID (256), BTRFS_LAST_FREE_OBJECTID (-256) ] Add a check for that in check_inode_ref(). Sashiko complained about such check missing in another unrelated patch. Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba commit 36f9aafa46f5b9fecf92d9218c5574f1ef6b4907 Author: Filipe Manana Date: Thu Sep 3 13:15:46 2026 +0100 btrfs: fix unnecessary transaction commit fallback from btrfs_log_all_parents() When btrfs_log_all_parents() returns without doing any work (because all parent directories were already logged), it returns 1, which is propagated up the fsync call chain up to btrfs_log_dentry_safe(), and that causes btrfs_sync_file() to trigger am unnecessary transaction commit. This all happens because the call to btrfs_search_slot() in btrfs_log_all_parents() always returns 1, as there can not be any inode ref keys with an offset 0 (an invalid inode number), so if the while loop below it does not do any work because all parent directories were already logged, the 'ret' variable remains with a value of 1, which is then returned up the call chain to btrfs_sync_file(). Fix this by setting 'ret' to 0 after the call to btrfs_search_slot(). Fixes: 0f24ea456ae1 ("btrfs: tracepoints: add trace event for btrfs_log_all_parents()") Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba commit 776924b2d9c451fc9dcc40673d17ff255bbc0fef Author: Johannes Thumshirn Date: Mon Aug 24 18:47:58 2026 +0200 btrfs: set space_info before adding new free space in btrfs_make_block_group() btrfs_make_block_group() calls btrfs_add_new_free_space() before assigning cache->space_info. On a zoned filesystem that ends up in __btrfs_add_free_space_zoned(), which dereferences block_group->space_info and thus hits a NULL pointer dereference when a non-initial free space range is added (e.g. during relocation). Assign cache->space_info before the btrfs_add_new_free_space() call. Reviewed-by: Boris Burkov Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba commit d112159df5c6cc5ee6ab91cc32bf6ed29939df38 Author: hpp.iscas Date: Sat Sep 5 21:31:33 2026 +0800 ASoC: Intel: SST: Publish the PCI module aliases The legacy SST PCI driver matches Intel Tangier devices using intel_sst_ids, but its only explicit module alias is "sst". That alias does not match PCI modalias events when this driver is built as a module. Publish its PCI table. The independently configurable SOF driver does not provide aliases for the legacy SST module. Fixes: f533a035e4da ("ASoC: Intel: mrfld - create separate module for pci part") Signed-off-by: hpp.iscas Link: https://patch.msgid.link/20260905133133.63661-1-hppiscas@163.com Signed-off-by: Mark Brown commit f06c2d26d1999d37e93299db0ecead04ca7d0b9f Author: Vasileios Almpanis Date: Thu Jul 30 11:30:25 2026 +0200 configfs: unhash the dentry before dropping the item in rmdir configfs_get_config_item() treats a hashed dentry as proof that sd->s_element is a live config_item. configfs_rmdir() breaks that: simple_rmdir() leaves the dentry hashed, the last reference to the item is dropped right after, and the dentry is only unhashed by d_delete() once ->rmdir() has returned. configfs_symlink() resolves its target holding no lock on it, so get_target() can land in that window: BUG: KASAN: slab-use-after-free in config_item_get+0x26/0x90 get_target fs/configfs/symlink.c:128 [inline] configfs_symlink+0x4ab/0x1030 fs/configfs/symlink.c:185 Unhash in configfs_remove_dir(), while the item is still guaranteed to be there. A reference obtained just before that stays harmless, as create_link() rechecks CONFIGFS_USET_DROPPING, already set by configfs_detach_prep(). Both configfs_unregister_subsystem() paths d_drop() after detaching, so this only makes rmdir match them. Reported-by: syzbot+6b16e3d085833cbf3e25@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6b16e3d085833cbf3e25 Fixes: 7063fbf22611 ("[PATCH] configfs: User-driven configuration filesystem") Cc: stable@vger.kernel.org Signed-off-by: Vasileios Almpanis Tested-by: Breno Leitao Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260730093435.195441-3-vasilisalmpanis@gmail.com Signed-off-by: Breno Leitao commit a7c1290eef60711c10289c056ad32ed1f2b47b12 Author: Vasileios Almpanis Date: Thu Jul 30 11:30:24 2026 +0200 configfs: pin the symlink target's dirent instead of chasing ->ci_dentry create_link() reads the target's configfs_dirent from item->ci_dentry->d_fsdata, relying on the item reference taken by get_target(). That reference pins the item, not its dentry: the dentry is pinned by DCACHE_PERSISTENT, which configfs_remove_dir() releases via simple_rmdir() while the item is still alive. A symlink racing with rmdir of its target can therefore find ->ci_dentry freed and its dirent released, triggering WARN_ON(!atomic_read(&sd->s_count)) in configfs_get(). Take the dirent in get_target() as well, under ->d_lock and atomically with the item reference, and pass it down to create_link(). A hashed dentry has not been killed yet, so its ->d_fsdata reference keeps the dirent alive there. Cc: stable@vger.kernel.org Fixes: 7063fbf22611 ("[PATCH] configfs: User-driven configuration filesystem") Signed-off-by: Vasileios Almpanis Tested-by: Breno Leitao Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260730093435.195441-2-vasilisalmpanis@gmail.com Signed-off-by: Breno Leitao commit 32689f0fc54fd801f1cd11637666e534984cb04a Author: hpp.iscas Date: Sat Sep 5 21:31:03 2026 +0800 ASoC: bcm: bcm63xx: Publish the OF module aliases The BCM63xx I2S platform driver matches brcm,bcm63xx-i2s using snd_soc_bcm_audio_match. With SND_BCM63XX_I2S_WHISTLER=m, the platform bus emits an OF modalias but snd-soc-63xx does not publish that table. Export the existing OF IDs for module autoloading. The PCM companion and the probe path remain unchanged. Fixes: 88eb404ccc3e ("ASoC: brcm: Add DSL/PON SoC audio driver") Signed-off-by: hpp.iscas Link: https://patch.msgid.link/20260905133103.63432-1-hppiscas@163.com Signed-off-by: Mark Brown commit 5a0aacaa2d593d7582ecfe289529b937b6dc5d3c Author: Cong Nguyen Date: Fri Aug 28 17:54:13 2026 +0700 hwmon: (applesmc) fix key backlight workqueue leak on register failure applesmc_create_key_backlight() allocates applesmc_led_wq before calling led_classdev_register(). When register fails, the error is returned to applesmc_init(), which jumps to out_light_sysfs and skips applesmc_release_key_backlight(), leaking the workqueue. Destroy the workqueue on the register failure path. The bug was introduced when the inline init block was refactored into a helper that returns errors directly, dropping the old out_light_wq unwind label. Fixes: 0b0b5dff8967 ("hwmon: (applesmc) Simplify feature sysfs handling") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Link: https://patch.msgid.link/20260828105413.2401385-1-congnt264@gmail.com Signed-off-by: Guenter Roeck commit 70c33e211b2b78830f76c908e5236b77ffde63a0 Author: Guenter Roeck Date: Fri Aug 21 07:49:16 2026 -0700 hwmon: (sht4x) Fix return value from heater_enable_store() Sashiko reports: The return value in heater_enable_store() causes an unexpected write failure in user-space. When the heater is successfully enabled, the function returns 0 instead of count: drivers/hwmon/sht4x.c:heater_enable_store() { ... data->heating_complete = jiffies + msecs_to_jiffies(heating_time_bound); data->data_pending = true; return 0; } Returning 0 signals to VFS that no bytes were processed. Standard user-space tools will retry the write with the remaining bytes. On the retry, time_before(jiffies, data->heating_complete) evaluates to true, and the function immediately fails with -EBUSY. Return count as expected to fix the problem. Fixes: 0eed6fc3d2b9e ("hwmon: (sht4x): add heater support") Cc: Antoni Pokusinski Cc: Alessandro Zini Signed-off-by: Guenter Roeck Link: https://patch.msgid.link/20260821144916.2889031-2-linux@roeck-us.net commit 06b7cf395b1fb652a50db39674a759658fbfba0d Author: Guenter Roeck Date: Fri Aug 21 07:49:15 2026 -0700 hwmon: (sht4x) Add missing locks Sashiko reports: Heater sysfs callbacks (heater_enable_store, heater_power_store, and heater_time_store) are exposed to data races without the hwmon lock. If a user-space process reads hwmon data while another process enables the heater, heater_enable_store() executes without holding hwmon_lock(dev). This can interleave I2C commands and mutate shared state (data->heating_complete and data->data_pending) concurrently with sht4x_read_values(), leading to corrupted I2C sequences. Fixes: 53dfa12299c1 ("hwmon: (sht4x) Rely on subsystem locking") Cc: Alessandro Zini Signed-off-by: Guenter Roeck Link: https://patch.msgid.link/20260821144916.2889031-1-linux@roeck-us.net commit 100eb7c7d0b28c52ad1b25d51c316fdc46c27c71 Author: hanzhijian Date: Fri Aug 21 19:57:20 2026 +0800 hwmon: (yogafan) fix non-kernel-doc comment The file description comment starts with "/**" which is reserved for kernel-doc comments, triggering a kernel-doc checker warning. Change it to a plain "/*" comment since it does not document any function or struct. Fixes: c67c248ca406a ("hwmon: (yogafan) Add support for Lenovo Yoga/Legion fan monitoring") Signed-off-by: hanzhijian Link: https://patch.msgid.link/20260821115720.2017516-1-hanzhijian1991@gmail.com Signed-off-by: Guenter Roeck commit 013c5a93e8062014177d68af799e8867cf03958d Author: Antonin Godard Date: Tue Aug 18 10:08:40 2026 +0200 Documentation: hwmon: replace full-width colon by a standard ASCII colon It prevented the pdfdocs target to complete, prompting the following error: Latexmk: ====Problematic refs and citations with line #s in .tex file: Missing character: There is no ： (U+FF1A) in font DejaVu Serif/OT:script=latn;l Fixes: 69001f21ded78 ("hwmon: document: add gpd-fan") Signed-off-by: Antonin Godard Link: https://patch.msgid.link/20260818-doc-hwmon-remove-confusable-v2-1-c1dff1ec01cd@bootlin.com Signed-off-by: Guenter Roeck commit 35760f5efd7bfa7a44a3831f47e19fe9cbafc905 Author: Jared Kangas Date: Thu Aug 20 06:09:24 2026 -0700 hwmon: (ina2xx) Decouple in0 and curr1 alarms INA2XX current limits are converted into shunt voltage limits internally using the shunt resistor value. Once a current limit's corresponding voltage limit is written to the hardware, shunt voltage and current alarms are indistinguishable from each other. This causes two issues: 1. in0/curr1 alarms may be unintentionally cleared by reading from the opposite input's alarm. 2. When a limit for either in0 (shunt voltage) or curr1 (current) is set, both of their alarms are triggered, and both of their limits read nonzero. An example of this behavior on an INA231: # cd /sys/class/hwmon/hwmon0 # head {curr1,in0}_input ==> curr1_input <== 1713 ==> in0_input <== 2 # echo 1800 >curr1_lcrit # head {curr1,in0}_lcrit_alarm ==> curr1_lcrit_alarm <== 1 ==> in0_lcrit_alarm <== 0 # head {in0,curr1}_lcrit_alarm ==> in0_lcrit_alarm <== 1 ==> curr1_lcrit_alarm <== 0 # head {in0,curr1}_lcrit_alarm ==> in0_lcrit_alarm <== 1 ==> curr1_lcrit_alarm <== 1 This is because curr1 uses the same underlying masks (INA226_SHUNT_*_VOLTAGE_MASK) as in0 on the hardware. As a result, ina2xx_{curr,in}_read() both read the shunt voltage alarms/limits without considering whether the voltage or current is currently set. To fix this, track the active alarm type in ina2xx_data and guard alarm/limit reads with a check that returns zero if the active alarm is for a different type. The new field is initialized based on the MASK_ENABLE register's set function, assuming voltage instead of current when the shunt voltage mask is set. After this fix, the alarms only read back 1 if their corresponding limit is set: # echo 0 >curr1_lcrit # head {curr1,in0}_lcrit_alarm ==> curr1_lcrit_alarm <== 0 ==> in0_lcrit_alarm <== 0 # echo 9999 >curr1_lcrit # head {curr1,in0}_lcrit_alarm ==> curr1_lcrit_alarm <== 1 ==> in0_lcrit_alarm <== 0 # echo 9999 >in0_lcrit # head {curr1,in0}_lcrit_alarm ==> curr1_lcrit_alarm <== 0 ==> in0_lcrit_alarm <== 1 Fixes: 4d5c2d986757 ("hwmon: (ina2xx) Add support for current limits") Signed-off-by: Jared Kangas Link: https://patch.msgid.link/20260820-upstream-ina2xx-in0-curr1-alarms-v2-4-fdce35abc41e@redhat.com Signed-off-by: Guenter Roeck commit e92b9208415a90e9cc1d923c5d8c058dde77be68 Author: Jared Kangas Date: Thu Aug 20 06:09:23 2026 -0700 hwmon: (ina2xx) Replace masks with enum in alert functions Instead of passing an explicit mask to alert/limit functions like ina226_alert_read(), introduce an enum ina2xx_alert_type that can be converted to a mask internally. This semantically separates current from shunt voltage in helpers that use function masks, which previously saw the same mask for the two functions. Signed-off-by: Jared Kangas Link: https://patch.msgid.link/20260820-upstream-ina2xx-in0-curr1-alarms-v2-3-fdce35abc41e@redhat.com Signed-off-by: Guenter Roeck commit 3d44ab826e0244a8b9eaf0f1f604f4cb8b890325 Author: Jared Kangas Date: Thu Aug 20 06:09:22 2026 -0700 hwmon: (ina2xx) Parameterize ina2xx_data in ina226_alert_read() Mirror ina226_alert_limit_read/write and use struct ina2xx_data instead of struct regmap in ina226_alert_read's parameters. Signed-off-by: Jared Kangas Link: https://patch.msgid.link/20260820-upstream-ina2xx-in0-curr1-alarms-v2-2-fdce35abc41e@redhat.com Signed-off-by: Guenter Roeck commit 2bf98a6af10388215398a30d723ff1f6ff5ce4f7 Author: Guenter Roeck Date: Thu Aug 20 22:19:13 2026 -0700 hwmon: Ensure that 'dev' passed to hwmon_notify_event() is a hwmon device The device parameter of hwmon_notify_event() must be a hardware monitoring device. Since this is easy to get wrong, and since passing a non-hwmon device may result in a crash, generate a warning traceback and abort if a wrong device class is passed as parameter. Signed-off-by: Guenter Roeck commit 8afc94bfb0ffdfc4a168081785820aa4818d1d23 Author: Jared Kangas Date: Thu Aug 20 06:09:21 2026 -0700 hwmon: (ina2xx) Acquire hwmon_lock in shunt_resistor_show() shunt_resistor_store() currently acquires hwmon_lock to set data->rshunt, but the corresponding access in shunt_resistor_show() is unprotected. Acquire the lock in shunt_resistor_show() as well to ensure proper synchronization. Fixes: 3ad867001c91 ("hwmon: (ina2xx) fix sysfs shunt resistor read access") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260729162836.89BDF1F00A3A@smtp.kernel.org/ Signed-off-by: Jared Kangas Link: https://patch.msgid.link/20260820-upstream-ina2xx-in0-curr1-alarms-v2-1-fdce35abc41e@redhat.com Signed-off-by: Guenter Roeck commit 354ccc99b2dc8ba0cf6d4de34e520bcf6ecca5c2 Author: Guenter Roeck Date: Thu Aug 20 10:51:50 2026 -0700 hwmon: Fix potential UAF in pec_store Sashiko reports: In pec_store(), a guard(mutex)(&hwdev->lock) is taken. If the chip write operation returns an error other than -EOPNOTSUPP, the code jumps to the put label, which calls put_device(hdev). If this drops the final reference, the device is freed. When the function then returns, the guard cleanup function runs and attempts to unlock the freed mutex. Use scoped_guard() instead of guard() to avoid the problem. Fixes: 3ad2a7b9b15d5 ("hwmon: Serialize accesses in hwmon core") Signed-off-by: Guenter Roeck commit b4fffa75c1d6f87e6dc6191dec900f2b5bd23a1c Author: Guenter Roeck Date: Thu Aug 20 21:40:48 2026 -0700 Documentation/hwmon: Document hwmon_notify_event() The hwmon core provides hwmon_notify_event() for drivers to report events such as alarm or fault conditions to userspace via sysfs notifications and uevents, as well as to the thermal subsystem for temperature sensors. However, this function is not documented in the hwmon kernel API guide. Add the function prototype and description of hwmon_notify_event() to Documentation/hwmon/hwmon-kernel-api.rst. Cc: Kalesh AP Reviewed-by: Kalesh AP Fixes: 1597b374af222 ("hwmon: Add notification support") Signed-off-by: Guenter Roeck commit a2471ed17b0e6ff7bfb6b2ea8e6e5b04c309d293 Author: Fan Wu Date: Wed Aug 19 03:33:17 2026 +0000 hwmon: (gpio-fan) Fix use-after-free in alarm work fan_alarm_irq_handler() queues fan_data->alarm_work, but nothing cancels it. fan_alarm_notify() dereferences fan_data and its hwmon device. On unbind, devres frees the interrupt, which only waits for the handler itself, and then releases the hwmon device and fan_data, so a pending fan_alarm_notify() can run after those frees. Replace INIT_WORK() with devm_work_autocancel(), registered before devm_request_irq(). The devres cleanup then frees the interrupt first, so no new work can be queued, and cancels the work while fan_data and the hwmon device are still alive. This issue was found by an in-house static analysis tool. Fixes: d6fe1360f42e ("hwmon: add generic GPIO fan driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260819033317.446191-1-fanwu01@zju.edu.cn Signed-off-by: Guenter Roeck commit 9607c245ca6674955e5e43e3606db410ae9e0b90 Author: Nikhil Gurudasani Date: Wed Aug 19 23:37:01 2026 +0530 hwmon: (mcp9982) Propagate one-shot polling errors When a device is in standby, the driver starts a one-shot conversion and polls the BUSY flag before reading temperature, alarm, or fault data. The poll result is currently ignored. Therefore, a timeout or a status-register read failure can be hidden by a later successful read, causing stale data to be returned as valid. Return the polling error before reading the requested attribute. Fixes: e2fe950f34e5 ("hwmon: add support for MCP998X") Cc: stable@vger.kernel.org Signed-off-by: Nikhil Gurudasani Link: https://patch.msgid.link/20260819180701.34797-1-nikhilgurudasani314@gmail.com Signed-off-by: Guenter Roeck commit e317326d1755ea054b98e7a4833b929157461c35 Author: Geert Uytterhoeven Date: Wed Aug 19 21:05:17 2026 +0200 hwmon: (ltc4282) Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. ltc428_clk_provider_setup() does not fill in any parent clocks, and assumes that init.num_parents is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: cbc29538dbf7d740 ("hwmon: Add driver for LTC4282") Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/8ec3c5cbd2df675a938f090470f5da5f22008517.1787165329.git.geert+renesas@glider.be Reviewed-by: Brian Masney Signed-off-by: Guenter Roeck commit cdb669a3b8f844aca71fc3224990157d61562165 Author: Junjie Cao Date: Mon Aug 24 11:14:19 2026 +0800 HID: quirks: add ALWAYS_POLL quirk for SDINNOVATION gaming keyboard The SDINNOVATION gaming keyboard (USB ID 36ae:feab) stops reporting input events after its RGB lighting mode is switched about twice. Disabling USB autosuspend and unbinding the other HID interfaces make no difference; the issue does not occur on Windows. HID_QUIRK_ALWAYS_POLL alone resolves it, verified on 7.1.8 via usbhid.quirks=0x36ae:0xfeab:0x400. Reported-by: Marco Carvalho Link: https://bugzilla.redhat.com/show_bug.cgi?id=2514627 Cc: stable@vger.kernel.org Signed-off-by: Junjie Cao Signed-off-by: Benjamin Tissoires commit adbd8a08208dc64bb1381f51b4f11ffdce1343fa Author: Daasaradhi Mannava Date: Sat Sep 5 15:49:00 2026 +0000 MAINTAINERS: Drop the nonexistent vsi-iommu.h file entry Commit 917ace84b770 ("iommu: Add verisilicon IOMMU driver") added the VERISILICON IOMMU DRIVER section, including a file entry for include/linux/vsi-iommu.h. That header is not present in the tree and no file includes it; the driver in drivers/iommu/vsi-iommu.c is self-contained. scripts/get_maintainer.pl --self-test=patterns reports the pattern as matching no file. Drop the stale entry so the section only lists files that exist. Assisted-by: LLM Signed-off-by: Daasaradhi Mannava Reviewed-by: Benjamin Gaignard Signed-off-by: Joerg Roedel commit fa5c0827f0b7bac6d0a188f10118151769ae68fd Author: Hemanth Selam Date: Tue Aug 25 15:35:54 2026 +0530 iommu/amd: Fix ineffective error check in nested domain allocation amd_iommu_pdom_id_alloc() returns an int: a domain ID on success, or the negative errno from ida_alloc_range() when the ID space is exhausted or memory is short. amd_iommu_alloc_domain_nested() stores that return value in gdom_info->hdom_id, which is a u32, and only then tests it: gdom_info->hdom_id = amd_iommu_pdom_id_alloc(); if (gdom_info->hdom_id <= 0) { The assignment discards the sign, so -ENOSPC becomes 0xffffffe4 and the test never fires. The nested domain is then set up with a host domain ID that was never allocated, instead of the allocation failing with -ENOSPC. Keep the value in an int, test it there, and store it only once it is known to be valid, which is what the other amd_iommu_pdom_id_alloc() callers already do. Fixes: 757d2b1fdf5b ("iommu/amd: Introduce gDomID-to-hDomID Mapping and handle parent domain invalidation") Signed-off-by: Hemanth Selam Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel commit eb29b7bbc8ba28bbb0b9fdd655e931e1d1fa625c Author: Vasant Hegde Date: Mon Aug 24 06:29:07 2026 +0000 iommu/amd: Fix premature break in init_iommu_one() again Commit 283d245468a2 ("iommu/amd: Fix premature break in init_iommu_one()") unintentionally broke older platforms - such as the ASRockRack B550D4-4L - where the BIOS advertises incorrect IOMMU features. Move the HATDis check ahead of the GASup check, and re-introduce the break inside the GASup check to restore correct behavior on affected platforms. This is a short-term fix to resolve the regression. Longer term, we should rework how EFRs are tracked and prioritize the MMIO-advertised EFR over the one reported via IVRS. That requires more extensive changes and will be addressed separately. Fixes: 283d245468a2 ("iommu/amd: Fix premature break in init_iommu_one()") Reported-by: Andreas Juch Closes: https://lore.kernel.org/linux-iommu/07b2d390-f7a0-47e2-bc2c-eb0853acf52e@juch.cc/ Tested-by: Andreas Juch Signed-off-by: Vasant Hegde Signed-off-by: Joerg Roedel commit 00a7dd64888d6dd72110b40e2824a088cf7b7386 Author: Karl Mehltretter Date: Wed Aug 19 05:23:49 2026 +0200 iommu/amd: Do not reallocate GA log buffers on resume Commit c5e1a1eb9279 ("iommu/amd: Simplify and Consolidate Virtual APIC (AVIC) Enablement") moved the GA log allocation from iommu_init_pci() to enable_iommus_vapic(), which is called on every resume. iommu_init_ga_log() assigns iommu->ga_log and iommu->ga_log_tail unconditionally. Each resume therefore replaces the boot-time pointers and leaks both old allocations. The function also uses GFP_KERNEL from a syscore resume callback, where interrupts are disabled and the non-boot CPUs are offline. Return early if both buffers are already allocated. Clear the pointers in free_ga_log() so a partial allocation failure cannot leave ga_log dangling. Fixes: c5e1a1eb9279 ("iommu/amd: Simplify and Consolidate Virtual APIC (AVIC) Enablement") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Reviewed-by: Vasant Hegde Reviewed-by: Ankit Soni Signed-off-by: Joerg Roedel commit 20db6573301e66cd65ebf6c130b6563c69374d9d Author: Niklas Schnelle Date: Tue Aug 18 21:13:17 2026 +0200 iommu/s390: Fix NULL dereference in iova_to_phys() with ZPCI_TABLE_TYPE_RFX When using a 5-level translation table via ZPCI_TABLE_TYPE_RFX get_rso_from_iova() returns NULL when the region-first entry is invalid. Yet in get_rto_from_iova() the region-second origin rso is not checked to be non-NULL before accessing rso[rsx] leading to a NULL pointer dereference instead of a NULL return when iova_to_phys() is called on a unmapped IOVA. Fix this by adding the missing NULL check. Cc: stable@vger.kernel.org Fixes: 81244074b518 ("iommu/s390: allow larger region tables") Signed-off-by: Niklas Schnelle Reviewed-by: Benjamin Block Reviewed-by: Matthew Rosato Reviewed-by: Farhan Ali Signed-off-by: Joerg Roedel commit 4c50bec3d54288230aafb7fe3d2930d42beb14fd Author: Fangyu Yu Date: Tue Sep 1 21:39:20 2026 +0800 iommu/riscv: Avoid waiting on failed command enqueue Do not wait for IOFENCE.C completion when the command failed to enter the queue. The command was not published to hardware, so waiting for its producer index can only report a misleading execution timeout. Fixes: 856c0cfe5c5f ("iommu/riscv: Command and fault queue support") Signed-off-by: Fangyu Yu Signed-off-by: Joerg Roedel commit ca58afa40946acd252a50fa4d4a86f15847a3d7d Author: Fangyu Yu Date: Tue Sep 1 21:39:19 2026 +0800 iommu/riscv: Serialize command queue publishing 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 commit d5bcf9ccaa357396089bbfa47fc82b093f109b1e Author: Fangyu Yu Date: Tue Sep 1 21:39:18 2026 +0800 iommu/riscv: Add command queue lock Add a raw spinlock to the RISC-V IOMMU queue state so command queue publishing can be serialized by a later change. Fixes: 856c0cfe5c5f ("iommu/riscv: Command and fault queue support") Signed-off-by: Fangyu Yu Reviewed-by: Nutty Liu Signed-off-by: Joerg Roedel commit 353a95f1cd8da8a5436a3f070be07d2f484486cd Author: Karl Mehltretter Date: Sat Aug 22 09:23:25 2026 +0200 syscall_user_dispatch: Use CONFIG_SYSCTL for sysctl guard Commit 8d75c338f0bc ("sysctl: remove CONFIG_PROC_SYSCTL, it just mirrors CONFIG_SYSCTL") removed CONFIG_PROC_SYSCTL, but the sysctl added by commit 5b6e32ba7b59 ("syscall_user_dispatch: Add kernel.syscall_user_dispatch sysctl") is still guarded by it. Now that both commits are merged, kernel.syscall_user_dispatch is no longer registered. syscall_user_dispatch_allowed defaults to true. SUD therefore remains available, but administrators cannot disable new activations. Use CONFIG_SYSCTL for the guard and documentation. Fixes: 5b6e32ba7b59 ("syscall_user_dispatch: Add kernel.syscall_user_dispatch sysctl") Assisted-by: Codex:gpt-5.6-sol Acked-by: Oleg Nesterov Reviewed-by: Joel Granados Signed-off-by: Karl Mehltretter Acked-by: Randy Dunlap Reviewed-by: Bradley Morgan Signed-off-by: Joel Granados commit e7557b9ef7a87570cbd0873a163de05bde80c39b Author: Mickaël Salaün Date: Mon Sep 7 12:35:01 2026 +0200 selftests/landlock: Test abstract socket trace name limits The landlock_deny_scope_abstract_unix_socket event captures binary socket names with __string_len(), whose dynamic field reserves an extra byte for the NUL terminator. The printer subtracts this byte before escaping the content. Exercise the minimum accepted address length, which has no name content, and the maximum sockaddr_un length, which has 107 content bytes. Check the exact trace output at both boundaries. The existing stream and datagram variants share this event, so the boundary variants only need the stream path. Because these boundary names are fixed, run the fixture in a private network namespace. Abstract UNIX socket names are scoped by network namespace, preventing concurrent bind() calls from colliding. The lower-bound test confirms that the subtraction recovers zero instead of underflowing. Cc: Günther Noack Link: https://patch.msgid.link/CAL4aGcVcT0VWVFmGi_vLqxxZ9KdOHfGXYZtKjBdvoUyFjbu5=A@mail.gmail.com Link: https://patch.msgid.link/20260907103503.109461-1-mic@digikod.net Signed-off-by: Mickaël Salaün commit 96bf9831fbf423b8104f7948cd8fe7007ecfb46c Author: Chengyu Zhu Date: Mon Sep 7 16:33:19 2026 +0800 erofs: delimit inode_share cache key components Previously, inode_share keys were encoded as follows: fingerprint || domain_id It would be better to have a separator between the fingerprint and domain ID so that the fingerprint won't be parsed as part of a domain ID. Change the key encoding as follows: domain_id || '\0' || fingerprint Since domain_id is a NUL-terminated string, this makes the in-memory key indices unambiguous. Signed-off-by: Chengyu Zhu Reviewed-by: Gao Xiang Fixes: e0bf7d1c074d ("erofs: support user-defined fingerprint name") Signed-off-by: Gao Xiang commit 2c6dc792538260a8087ac5b22c31b3b8e47c85d6 Author: Norbert Szetei Date: Sat Aug 22 14:29:00 2026 +0200 landlock: Fix use-after-free of the source's parent directory current_check_refer_path() reads old_dentry->d_parent without holding a reference nor a lock on it, and then dereferences it in collect_domain_accesses() and in the audit record. A reference on a child does not pin its parent: __d_move() reassigns dentry->d_parent and drops the reference the child held on its former parent. hook_path_rename() is not affected because the rename path calls lock_rename() before the hook, so the source cannot be reparented under it. hook_path_link() has no such protection: filename_linkat() holds a reference on the source dentry but neither locks nor references its parent, so a concurrent rename(2) can reparent the source while security_path_link() runs, and the former parent can then be removed and freed while the hook walks it. A process can trigger this after entering a Landlock domain that handles at least one filesystem access right. The process can then race a linkat(2) loop against rename(2) and rmdir(2): BUG: KASAN: slab-use-after-free in collect_domain_accesses+0x278/0x290 Read of size 4 at addr ffff888160bd53f4 by task llrepro2/549 collect_domain_accesses+0x278/0x290 current_check_refer_path+0x952/0x1120 security_path_link+0x1be/0x320 filename_linkat+0x342/0x6d0 __x64_sys_linkat+0xfa/0x150 Freed by task 562: kmem_cache_free+0x139/0x4c0 i_callback+0x4b/0x80 rcu_core+0x7dc/0x10a0 Take a reference on the dentry selected as the source parent, using dget() for the common-mount-root case and dget_parent() otherwise. Release it after the hierarchy walk and synchronous audit logging. Cc: stable@vger.kernel.org Fixes: b91c3e4ea756 ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER") Signed-off-by: Norbert Szetei Reviewed-by: Günther Noack Tested-by: Günther Noack Link: https://patch.msgid.link/E9CDD9E6-E960-4DE2-B1AC-5667D52ABB3E@doyensec.com [mic: Clarify the caller, reachability, and reference handling] Signed-off-by: Mickaël Salaün commit 954f7a48fa2ae7310c67729fb556caf726783436 Author: Thomas Gleixner Date: Sat Sep 5 10:43:57 2026 +0200 entry: Guard syscall_enter_audit() invocation with CONFIG_AUDITSYSCALL A bunch of older cross compilers notably RISCV64 and S390 fail to eliminate the dead code when CONFIG_AUDITSYSCALL=n. The code in question is: if (unlikely(audit_context()) syscall_enter_audit(regs); and in case of CONFIG_AUDITSYSCALL=n: static inline struct audit_context *audit_context(void) { return NULL; } which should make the compiler eliminate the syscall_enter_audit() call. But a RISV64 GCC12 cross compiler translates that into: if (unlikely(audit_context())) 1c34: 00000097 auipc ra,0x0 1c38: 000080e7 jalr ra # 1c34 <.L785> 1c3c: c511 beqz a0,1c48 <.L787> syscall_enter_audit(regs); 1c3e: 8526 mv a0,s1 1c40: 00000097 auipc ra,0x0 1c44: 000080e7 jalr ra # 1c40 <.L785+0xc> and then claims in the failing link: include/asm-generic/preempt.h:54:(.noinstr.text+0x1a20): undefined reference to 'syscall_enter_audit' which is obviously hallucination. Add an explicit IS_ENABLED(CONFIG_AUDITSYSCALL) check into the condition to cure this compiler madness. Fixes: 6f25517010dd ("entry: Rework syscall_audit_enter()") Reported-by: kernel test robot Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/87tso45bqq.ffs@fw13 Closes: https://lore.kernel.org/oe-kbuild-all/202609031938.ZvZZaRQy-lkp@intel.com/ commit 113a9796effe3376d2ec5aabcca1fef4fef4cd62 Author: Thomas Gleixner Date: Mon Aug 12 16:19:48 2024 +0200 tick/broadcast: Plug clockevents replacement race 朱恺乾 reported and decoded the following race condition when a broadcast device is replaced: CPUA CPUB __tick_broadcast_oneshot_control() bc = tick_broadcast_device.evtdev; tick_install_broadcast_device(dev) clockevents_exchange_device(cur, dev) shutdown(cur); detach(cur); cur->handler = noop; tick_broadcast_device.evtdev = dev; tick_broadcast_set_event(bc, next_event); <- FAIL: arms a detached device. If the original broadcast device has a restricted interrupt affinity mask and the last CPU in that mask goes offline then the BUG() in tick_cleanup_dead_cpu() triggers because the clockevent device is not in detached state. The reason for this is that tick_install_broadcast_device() is not serialized vs. tick broadcast operations. The obvious cure is to serialize tick_install_broadcast_device() with tick_broadcast_lock against a concurrent tick broadcast operation. That requires to split clockevents_exchange_device() into two parts, one which does the exchange, shutdown and detach operation and the other which drops the module reference count. This is required because the module reference cannot be dropped while holding tick_broadcast_lock. Let clockevents_exchange_device() do both operations as before, but let the broadcast device code take the two step approach and do the device exchange under tick_broadcast_lock and drop the module reference count after releasing it. Fixes: f8381cba04ba ("[PATCH] tick-management: broadcast functionality") Reported-by: 朱恺乾 Signed-off-by: Thomas Gleixner Signed-off-by: Thomas Gleixner Reviewed-by: Bradley Morgan Tested-by: 刘术高 Cc: stable@vger.kernel.org Link: https://patch.msgid.link/87cymdsu0r.ffs@tglx commit 818103dc7f5998a0d7957fb71d4deecdf4d579e1 Author: hpp.iscas Date: Sat Sep 5 21:43:40 2026 +0800 pinctrl: qcom: ipq5210: Publish the OF module alias The IPQ5210 TLMM platform driver can be a module and matches through ipq5210_tlmm_of_match. This table is not published for OF modalias matching. Publish the existing table, preserving arch_initcall ordering and the shared MSM pinctrl probe. Fixes: a549fe22376f ("pinctrl: qcom: Introduce IPQ5210 TLMM driver") Signed-off-by: hpp.iscas Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260905134340.67477-1-hppiscas@163.com Signed-off-by: Bartosz Golaszewski commit ad7265b29995ff12b2ce834a6a6162d616462362 Author: Johannes Berg Date: Mon Sep 7 09:55:44 2026 +0200 .get_maintainer.ignore: add myself Since I've touched so many things all over I get CC'ed on far too many things - add myself here to avoid that. I'm also listed in MAINTAINERS for the right things. Signed-off-by: Johannes Berg commit fbfd6d0d3596d072f7546b25228e4eb599f68a95 Author: Shawn Guo Date: Sun Aug 30 11:02:01 2026 +0800 pinctrl: qcom: nord: Split QUP1 SE2/SE3 into lane-pair functions QUP1 SE2 and SE3 pack all four of their lanes pair-wise onto only two pins each: lanes 0/1 (I2C SDA/SCL) at mux value 2 and lanes 2/3 (UART TX/RX) at mux value 1, on gpio127/gpio128 and gpio129/gpio130 respectively. Both mux values were named "qup1_se2" (respectively "qup1_se3"), so the two distinct lane pairs became indistinguishable. msm_pinmux_set_mux() stops at the first entry matching the requested function, which means mux value 1 was always selected and the I2C lanes could never be muxed out. In practice i2c9 and i2c10 got the UART lanes and did not work, while uart9 and uart10 happened to be muxed correctly. Give each lane pair its own function, following the _01/_23 naming already used for the same hardware arrangement by the shikra, eliza, hawi and maili TLMM drivers. Both functions still cover the full pin pair, so a single pinctrl state per protocol remains sufficient. Drop gpio129/gpio130 from the SE2 group list, since those pins belong to SE3 and were never reachable through the SE2 function. Also rename QUP1 SE2/SE3 functions in the binding doc accordingly. While at it, add missing "gpio", "qup3_se0_mira" and "qup3_se0_mirb" to the binding function enum to get the list complete. Fixes: c24dd0826f06 ("pinctrl: qcom: add the TLMM driver for the Nord platforms") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Shawn Guo Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260830030201.135637-1-shengchao.guo@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit b7313376809292f0e6bf2d5750225c8b66e9ccda Author: Nick Pegg Date: Sun Sep 6 08:55:37 2026 -0700 ALSA: usb-audio: Add quirk flags for Behringer UV1 The Behringer UV1 is a microphone audio processor with a USB audio interface, which experiences periodic stutters unless implicit_fb is used. This seems to be a similar device to the Behringer UMC series, so I copied the quirks from those. I've confirmed that my own UV1 works great with these flags set. Signed-off-by: Nick Pegg Link: https://patch.msgid.link/20260906155616.1625465-1-nick@nickpegg.com Signed-off-by: Takashi Iwai commit 37bef2170d4c88fc3d708eecf3ef0f4032bc1372 Author: Michael Bommarito Date: Tue Jun 16 22:19:05 2026 -0400 media: mediatek: vcodec: bound AV1 tile-start copy to the array capacity vdec_av1_slice_setup_tile() copies tile_cols + 1 / tile_rows + 1 entries into mi_col_starts[] / mi_row_starts[] from the bitstream tile_info. Bound the copy to the array capacity. Fixes: 0934d3759615 ("media: mediatek: vcodec: separate decoder and encoder") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Signed-off-by: Hans Verkuil commit 367db8b23c26a913d76ed70457bbcd781c422b49 Author: Michael Bommarito Date: Tue Jun 16 22:19:04 2026 -0400 media: verisilicon: rockchip: reject AV1 frames exceeding the tile capacity rockchip_vpu981_av1_dec_set_tile_info() indexes the tile group entry array by tile1 * tile_cols + tile0, reading up to tile_cols * tile_rows entries, lays out one descriptor per tile in the AV1_MAX_TILES tile_info buffer, and programs the real tile_cols / tile_rows into the hardware. The tile group entry control is a dynamic array sized to the number of entries userspace submitted, independent of tile_cols / tile_rows, so a frame that claims more tiles than entries reads past the array. A frame that claims more than AV1_MAX_TILES tiles also leaves the hardware programmed for more tiles than the descriptor buffer holds. Reject both in prepare_run(): tile_cols * tile_rows must not exceed the submitted entry count or AV1_MAX_TILES. The entry count is read via v4l2_ctrl_find() (ctrl->elems). This mirrors the bound the mediatek AV1 decoder already enforces. Fixes: 727a400686a2 ("media: verisilicon: Add Rockchip AV1 decoder") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil commit b84f6533a8ed2fd7b282fc7ab4b8efadc745a89c Author: Michael Bommarito Date: Tue Jun 16 22:19:03 2026 -0400 media: verisilicon: rockchip: guard VPU981 AV1 divisor and tile buffer rockchip_vpu981_av1_dec_set_tile_info() divides context_update_tile_id by tile_info->tile_cols and writes one descriptor per tile into the tile_info DMA buffer, which holds AV1_MAX_TILES entries; tile_cols and tile_rows come from the bitstream. Guard the division against a zero tile_cols by initialising the context-update values to zero and computing them only when tile_cols is non-zero, and stop the descriptor writes once the tile_info buffer is full. The tile geometry written to the hardware registers is left unmodified; the per-dimension and total tile bounds are enforced by the control validation. Fixes: 727a400686a2 ("media: verisilicon: Add Rockchip AV1 decoder") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil commit 06236b094c899c22c12ac5097935eb6719293de8 Author: Michael Bommarito Date: Tue Jun 16 22:19:02 2026 -0400 media: verisilicon: hantro: bound G2 HEVC tile loop to the buffer capacity prepare_tile_info_buffer() writes one entry per tile into the tile_sizes DMA buffer, sized for a grid equal to the PPS uAPI array capacity. Use the bounded v4l2_hevc_pps_num_tile_columns() / v4l2_hevc_pps_num_tile_rows() helpers so the loops stay inside the buffer. Fixes: cb5dd5a0fa51 ("media: hantro: Introduce G2/HEVC decoder") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil commit 81ad46bb33d8fd279aaa33af5296c648814c964b Author: Michael Bommarito Date: Tue Jun 16 22:19:01 2026 -0400 media: rkvdec: bound HEVC tile loops and PPS id to the array capacity compute_tiles_uniform() and compute_tiles_non_uniform() loop over num_tile_columns_minus1 + 1 / num_tile_rows_minus1 + 1 entries, and assemble_hw_pps() writes one COLUMN_WIDTH / ROW_HEIGHT register per tile and indexes priv_tbl->param_set[] by pic_parameter_set_id, all taken from the untrusted PPS. Use the bounded v4l2_hevc_pps_num_tile_columns() / v4l2_hevc_pps_num_tile_rows() helpers for the tile loops, and bail out of assemble_hw_pps() before indexing priv_tbl->param_set[] with an out-of-range pic_parameter_set_id, so the writes stay within the hardware tables. Fixes: 3595375c2301 ("media: rkvdec: Add HEVC backend") Fixes: c9a59dc2acc7 ("media: rkvdec: Add HEVC support for the VDPU381 variant") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Signed-off-by: Hans Verkuil commit 592dd4f8442a13bed6e946d73d3164ba38b33bbd Author: Michael Bommarito Date: Tue Jun 16 22:19:00 2026 -0400 media: hevc: add bounded tile-count helpers The stateless HEVC decoders compute the number of tile columns and rows from num_tile_columns_minus1 / num_tile_rows_minus1 and clamp it to the column_width_minus1[] / row_height_minus1[] capacity before using it as a loop bound. Add shared helpers in a new so the rkvdec and hantro drivers do not each open-code the min_t() clamp. Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-8 Fixes: 256fa3920874 ("media: v4l: Add definitions for HEVC stateless decoding") Cc: stable@vger.kernel.org Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil commit 439058ced617fbb3febc017b9e93bb7387f309e0 Author: Michael Bommarito Date: Tue Jun 16 22:18:59 2026 -0400 media: v4l2-ctrls: validate AV1 tile counts The stateless AV1 decoders use tile_info.tile_cols and tile_rows as loop bounds and as indices into the mi_*_starts[] and *_in_sbs_minus_1[] arrays, as the divisor for context_update_tile_id, and their product bounds the per-tile descriptor buffers, but std_validate_compound() does not bound these u8 fields. Reject a V4L2_CTRL_TYPE_AV1_FRAME whose tile_cols or tile_rows exceeds V4L2_AV1_MAX_TILE_COLS / _ROWS, or whose product exceeds V4L2_AV1_MAX_TILE_COUNT. A zero tile count is left to the consuming driver so the zero-initialised control that existing userspace submits is still accepted. Fixes: 9de30f579980 ("media: Add AV1 uAPI") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil commit dc694a9929f7cb9c88ef91e45eb982b7bbe5a477 Author: Michael Bommarito Date: Tue Jun 16 22:18:58 2026 -0400 media: v4l2-ctrls: validate HEVC tile counts The stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from column_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[] and use them as tile-loop bounds, but std_validate_compound() does not bound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks. Fixes: 256fa3920874 ("media: v4l: Add definitions for HEVC stateless decoding") Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil commit 10e59fbdef13597836bd6459095caa02c80af3d7 Author: Haotian Zhang Date: Tue Sep 1 10:23:09 2026 +0800 media: v4l2-h264: Fix memcmp() size in B1 reference list comparison In v4l2_h264_build_b_ref_lists(), the B0/B1 list equality check passes the entry count builder->num_valid to memcmp() instead of a byte size. Since struct v4l2_h264_reference is two bytes (fields and index), only half of each list is compared, so distinct lists can be wrongly treated as equal and trigger an incorrect swap(b1_reflist[0], b1_reflist[1]). Change the memcmp() size argument to sizeof(b1_reflist[0]) * builder->num_valid so that the full byte length of both reference lists is compared. Fixes: 624922a2739b ("media: v4l2-core: Add helpers to build the H264 P/B0/B1 reflists") Suggested-by: Nicolas Dufresne Cc: stable@vger.kernel.org Signed-off-by: Haotian Zhang Reviewed-by: Nicolas Dufresne Signed-off-by: Hans Verkuil commit 45a5f7285f835adb3b74c9344c09a7bd2c4fb664 Author: Madhavan Srinivasan Date: Tue Aug 18 09:20:37 2026 +0530 MAINTAINERS: powerpc: Add Ritesh and Shrikanth Ritesh and Shrikanth has been helping in the powerpc mailing list patch reviews, adding them as reviewers. Acked-by: Shrikanth Hegde Acked-by: Ritesh Harjani (IBM) Acked-by: Christophe Leroy (CS GROUP) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260818035037.613186-1-maddy@linux.ibm.com commit 157dcb8230a4e882e099ec4d1cb1957b0b2c9b26 Author: Zizhi Wo Date: Sat Sep 5 09:03:54 2026 +0800 xfs: remove several unused and never-implemented declarations Over time a number of function declarations in various headers have become stale: either their implementations were removed when their last callers went away, or they were never implemented in the first place. None of them refer to anything anymore. Remove the following dead declarations and the unused stub: - xlog_assign_tail_lsn() and xlog_assign_tail_lsn_locked() - xfs_iext_realloc() - xfs_buf_iodone() - xfs_scrub_tester() and xfs_scrub_setup_inode_bmap_data() (never implemented placeholders) - the !CONFIG_XFS_ONLINE_REPAIR stub of xrep_tempfile_iolock_both() Signed-off-by: Zizhi Wo Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 95bf070f3225dc7175725438c916ad321d42fe45 Author: Dawid Osuchowski Date: Tue Sep 1 14:57:49 2026 +0200 accel/ivpu: Limit firmware log name prints to field size The name in struct vpu_tracing_buffer_header is a fixed-size array populated by the NPU firmware. It is expected to be NUL-terminated, but nothing on the host side enforces this, so printing it with an unbounded string conversion would read past the field if the terminator is ever missing and expose adjacent bytes of the shared tracing BO through dmesg and the debugfs FW log output. Print at most as many characters as the name field holds, so the output never runs past it even if the string is not NUL-terminated. Cc: stable@vger.kernel.org Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260827102339.281799-1-dawid.osuchowski@linux.intel.com?part=2 Fixes: d4e4257afa6e ("accel/ivpu: Add firmware tracing support") Signed-off-by: Dawid Osuchowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260901125749.404338-4-dawid.osuchowski@linux.intel.com commit 0724afc55c77c36c7feb9a7264b02aa7593c5c2d Author: Magdalena Schulfer Date: Tue Sep 1 14:57:48 2026 +0200 accel/ivpu: Validate firmware log buffer metadata The tracing log headers parsed by fw_log_print_buffer() reside in DMA-shared BOs that the NPU firmware can write to. fw_log_from_bo() validated log->header_size and log->size, but fw_log_print_buffer() re-read those same fields from shared memory afterwards, allowing a TOCTOU where firmware changes them between the check and the use, and making the host dereference out-of-bounds addresses while printing logs. Snapshot the validated values once with READ_ONCE() and pass them down explicitly in a new struct ivpu_fw_log_desc instead of re-reading them from the shared struct. Cc: stable@vger.kernel.org Fixes: d4e4257afa6e ("accel/ivpu: Add firmware tracing support") Signed-off-by: Magdalena Schulfer Signed-off-by: Dawid Osuchowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260901125749.404338-3-dawid.osuchowski@linux.intel.com commit 3837c3f29fbc3b8c12bebf5c62741e2befe3482a Author: Magdalena Schulfer Date: Tue Sep 1 14:57:47 2026 +0200 accel/ivpu: Validate full buffer range in ivpu_to_cpu_addr Add a size parameter to ivpu_to_cpu_addr() and validate that the whole [vpu_addr, vpu_addr + size) range stays within the BO. Cc: stable@vger.kernel.org Fixes: 647371a6609d ("accel/ivpu: Add GEM buffer object management") Signed-off-by: Magdalena Schulfer Signed-off-by: Dawid Osuchowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260901125749.404338-2-dawid.osuchowski@linux.intel.com commit 4d0624679ae29b469016f1ce4714be58582ed06a Author: Darrick J. Wong Date: Wed Sep 2 22:52:23 2026 -0700 xfs: count escaped corruption errors in scrub stats The main scrub code will quietly turn bubbled-up EFSCORRUPTED and EFSBADCRC errors into corruption errors. These aren't recorded in the scrub stats code (says LOLLM) so do that now. Cc: stable@vger.kernel.org # v6.6 Fixes: d7a74cad8f4513 ("xfs: track usage statistics of online fsck") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 6b760b3232b3efc8bcc7c165e76300bc1c9140c5 Author: Darrick J. Wong Date: Wed Sep 2 22:52:07 2026 -0700 xfs: make the rtsummary repair fix the file size too LOLLM noticed that the rtsummary repair code will create a new rtsummary with the correct file size, but it won't force the new file size to be set on the existing rtsummary file, leaving the rtsummary corrupt. Fix this by setting up the tempfile mapping-exchange to run to the end of both files, which is the magic offset needed to reset the file size. Cc: stable@vger.kernel.org # v6.10 Fixes: abf039e2e4afde ("xfs: online repair of realtime summaries") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 3f9fd694fa429e89fe6de51b22b0ed5fb8b2daf4 Author: Darrick J. Wong Date: Wed Sep 2 22:51:52 2026 -0700 xfs: fix rtrefcount btree block counting in scrub LOLLM started on a long tangent about how xchk_refcount_xref_rmap shouldn't nope out if sc->sa.rmap_cur isn't set, because nothing ever sets that field. It's right about the condition, but misses the bigger problem, which is that to count the rtrefcount btree blocks, we have to walk all rmap records in each AG in the data section. That was papered over by the incorrect !sc->sa.rmap_cur test. In other words, we need a perag iteration loop here. Restructure the code to do that, and now it'll all work properly. Fix the confusing function name prefix. Cc: stable@vger.kernel.org # v6.14 Fixes: c27929670de144 ("xfs: scrub the realtime refcount btree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 0d43368844a75ad13561a1198a3b027940730756 Author: Darrick J. Wong Date: Wed Sep 2 22:51:36 2026 -0700 xfs: strengthen the "is cow staging" helpers in scrub LOLLM pointed out a bug in both of the refcount scrub predicates that determine if a range of blocks is marked as CoW staging in the btree. While it compares blockcount < len, this isn't enough to determine that the CoW staging record is at least as large as the range passed into the helper. Fix both of them. Cc: stable@vger.kernel.org # v4.16 Fixes: f6d5fc21fdc713 ("xfs: cross-reference refcount btree during scrub") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit c3085f6c7cca7c162248519ce8d763047cdd8acd Author: Darrick J. Wong Date: Wed Sep 2 22:51:21 2026 -0700 xfs: use the rtgroup extent count to find rtrefcount gaps LOLLM noticed an anachronism from the early days of rtrefcount where the refcount btree would handle 64-bit block numbers -- we pass rtblocks into the gap finder, but rtrefcount btrees are sharded by rtgroup now. This isn't really a problem for us since we're only looking for overlapping rtrmap records to flag, but let's fix this sillyness. Also fix some stale comments. Cc: stable@vger.kernel.org # v6.14 Fixes: 30f47950dc2eba ("xfs: check reference counts of gaps between rt refcount records") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 79ab1af2034b2ad10c5f18910937b938d2ad2219 Author: Darrick J. Wong Date: Wed Sep 2 22:51:05 2026 -0700 xfs: cross-reference the rtgroup superblock extent, not block LOLLM noticed that when libxfs creates a realtime superblock, it will create an rtrmapbt record covering the entire rtextent in which the superblock lives. However, the cross-referencing checks only look for the first block, which means that we can miss a corrupt rtrmap record. That will get picked up by the rtrmap scrubber, but we should make the rgsuper scrubber more robust anyway. Cc: stable@vger.kernel.org # v6.13 Fixes: 3f1bdf50ab1b9c ("xfs: scrub the realtime group superblock") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit e8b01aaafffe6b852325debdf1ef4b13ccea1cd7 Author: Darrick J. Wong Date: Tue Sep 1 22:49:47 2026 -0700 xfs: fix backwards mergeability logic in refcount scrubber When we start the refcount or rtrefcount btree scanners, prev_rec is initialized to all zeroes. This is done so that the record mergeability checks skip the first record because you must have two records to compare. Unfortunately, I got the logic backwards, so scrub has never complained about mergeable refcountbt records. Fix this bug that LOLLM noticed. Cc: stable@vger.kernel.org # v6.4 Fixes: db0502b39c21d1 ("xfs: flag refcount btree records that could be merged") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit d7f97be48cbe3751e44a45373c0e91e93b976f98 Author: Darrick J. Wong Date: Tue Sep 1 22:49:32 2026 -0700 xfs: fix backwards skipping logic in xrep_quota_block LOLLM complains about the logic in xrep_quota_block that skips reinitializing the ondisk dquot if there aren't any problems that would impede a dqiterate walk later. I got the type checking logic backwards, which is the source of the problem. Fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: a5b91555403e3a ("xfs: repair quotas") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit de20f7014917d661afc03d9a1c157d0ae2775b49 Author: Darrick J. Wong Date: Wed Sep 2 22:49:52 2026 -0700 xfs: compute dquot checksum after resetting dd_lsn in repair LOLLM complains that xrep_quota_block updates dd_lsn after calculating the crc of the ondisk dquot. That's clearly broken, so fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: a5b91555403e3a ("xfs: repair quotas") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 0fc67528f54bb91dac22093749b425207c0fc245 Author: Darrick J. Wong Date: Tue Sep 1 22:49:01 2026 -0700 xfs: truncate quota file correctly when repairing quota file LOLLM noticed that xrep_quota_data_fork screws up the unit handling when it computes the offset at which to start truncating the quota file. max_dquid_off is the file block offset containing the highest possible dquot, and xfs_bunmapi_range takes the starting file block offset. Therefore, it makes no sense to multiply max_dquid_off by the blocksize; all we need to do is start truncating at the next block. Cc: stable@vger.kernel.org # v6.8 Fixes: a5b91555403e3a ("xfs: repair quotas") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 8c71ad4d4f3e20c30b663bd292526fcbc4d3913f Author: Darrick J. Wong Date: Tue Sep 1 22:48:45 2026 -0700 xfs: signal inode btree xref error if get_rec returns an error LOLLM points out that xchk_finobt_xref_inobt and xchk_inobt_xref_finobt both ignore errors being returned from the xfs_btree_get_rec function and proceed with a (possibly stale) "true" value for has_record. If the *simple* btree record checks fail during cross-referencing, we can immediately conclude that there's a cross-referncing error in the other btree. On those grounds, we can bubble up the returned error instead of wasting time cross-referencing with garbage. Cc: stable@vger.kernel.org # v6.4 Fixes: bc0f3b55467e1b ("xfs: directly cross-reference the inode btrees with each other") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 1a441c6842da75c5b862cc1c9f7969d6a93b54b9 Author: Darrick J. Wong Date: Tue Sep 1 22:48:30 2026 -0700 xfs: destroy seen inode bitmap when we fail to add a dirpath LOLLM observes a memory leak in xchk_dirtree_create_path if we create the directory path object but appending the name to the path fails. When this happens, we don't tear down the (empty) seen inode bitmap. This is a pretty trivial error, but let's not leave logic bombs. Do the same for a similar bug in xrep_dirtree_create_adoption_path. Cc: stable@vger.kernel.org # v6.10 Fixes: 928b721a11789a ("xfs: teach online scrub to find directory tree structure problems") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 014c1aff607a839b8ddc732da919b94560ae58c2 Author: Darrick J. Wong Date: Tue Sep 1 22:48:14 2026 -0700 xfs: report nonexistent parents as a filesystem corruption LOLLM noticed that when the directory tree scrubber tries to walk up a parent pointer but the parent inumber doesn't point to an allocated inode, we allow the EINVAL/ENOENT error code to bubble up to userspace. That's not right, we should be reporting that as a cross-referencing error so that someone runs the parent pointer checker. Also add a termination check to xchk_dirpath_step_up because it's a loop body function. Cc: stable@vger.kernel.org # v6.10 Fixes: 928b721a11789a ("xfs: teach online scrub to find directory tree structure problems") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 295f2cfd3e2c814c2ecd2c1d522bc31c5288e414 Author: Darrick J. Wong Date: Tue Sep 1 22:47:59 2026 -0700 xfs: bump lost_prev_errors if we lose even the healthmon lost event LOLLM observes that we don't bump xfs_healthmon::lost_prev_event even if we can't allocate or queue a LOST event, which means that events can disappear silently when things are going very wrong. Bump the counter to avoid this problem. Cc: stable@vger.kernel.org # v7.0 Fixes: b3a289a2a9397b ("xfs: create event queuing, formatting, and discovery infrastructure") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 74eeb68a628dbc4a8f976351ad2f1ef5463513ee Author: Darrick J. Wong Date: Tue Sep 1 22:47:43 2026 -0700 xfs: check healthmon outbuffer space correctly LOLLM notices that the outbuf space check in xfs_healthmon_format_pop isn't quite correct -- it checks that there's enough space to write a xfs_healthmon_event object, but the outbuffer is supposed to contain xfs_health_monitor_event objects. Fix this by adding a helper, and refactoring all three outbuf size checks to use it. Cc: stable@vger.kernel.org # v7.0 Fixes: b3a289a2a9397b ("xfs: create event queuing, formatting, and discovery infrastructure") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 4c98464e12fcfe3a71646f8efa5d3f7f1b5e2bed Author: Darrick J. Wong Date: Tue Sep 1 22:47:28 2026 -0700 xfs: merge healthmon insert/push helpers These functions are basically the same except for where in the queue the new event is added. Refactor them as a single function that takes an action verb to tell us where; and rename the tracepoints to describe directly what happens. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 9097f5c03f038cea83d174b6d322d7b2678a3c99 Author: Darrick J. Wong Date: Tue Sep 1 22:47:12 2026 -0700 xfs: port healthmon event list to list_head Simplify the healthmon codebase by porting the single-link event list to a standard list_head. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 10b1d5fd7189986a0cdd90dde181089b4b2fe40e Author: Darrick J. Wong Date: Tue Sep 1 22:46:56 2026 -0700 xfs: move healthmon event merge tracepoint Move the tracepoint into the predicate function so that the list conversion in the next patch is easier. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 58a0c7578b25b578c16dea7db2493cfa3a08ecc2 Author: Darrick J. Wong Date: Tue Sep 1 22:46:41 2026 -0700 xfs: always set xfs_healthmon::first_event when inserting at front of list LOLLM complains that while __xfs_healthmon_insert is supposed to insert an event at the head of the list, it doesn't do that correctly if the list isn't empty. In that case it *should* make our new event point to the current head, and then make the head point to the new event, but it doesn't actually update the head so we never see the new event. Fix this by always reassigning first_event. A subsequent patch will clean this up to use a standard list_head, but I felt it important to call out the bug fix first. Cc: stable@vger.kernel.org # v7.0 Fixes: b3a289a2a9397b ("xfs: create event queuing, formatting, and discovery infrastructure") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Reviewed-by: Anuj Gupta Signed-off-by: Carlos Maiolino commit c83d1ef97ee3b0b92797d4b4932a3a813ba05b86 Author: Darrick J. Wong Date: Tue Sep 1 22:44:52 2026 -0700 xfs: fix bnobt repair space reservation disposal failure LOLLM complains that we don't bubble failures from xrep_abt_dispose_one upwards in the callstack. A failure to clean up the space used (or reserved but not used) by the new bnobt/cntbt should be reported. Cc: stable@vger.kernel.org # v6.8 Fixes: 4bdfd7d15747b1 ("xfs: repair free space btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 365fe37e10ea75840165f13322aa8481ea11dfef Author: Darrick J. Wong Date: Tue Sep 1 22:44:37 2026 -0700 xfs: don't modify file attributes or poke fsnotify for dry runs I noticed that we shouldn't be removing file privileges when doing a dry run of an exchange-range operation. LOLLM also points out that a dry run shouldn't poke fsnotify because we don't actually change the files. Fix both by gating them on !DRY_RUN. Cc: stable@vger.kernel.org # v6.10 Fixes: 42672471f938cd ("xfs: bind together the front and back ends of the file range exchange code") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit b71ae66863e4320a3b7313b53bb4d65f1718d58b Author: Darrick J. Wong Date: Tue Sep 1 22:44:21 2026 -0700 xfs: actually recover intended file sizes in xfs_xmi_item_recover_intent LOLLM points out that xfs_xmi_item_recover_intent doesn't actually restore the isize1 and isize2 fields that were recovered from an unfinished exchmaps log intent item. Instead, xfs_exchmaps_init_intent sets the wrong isize values from the recovered inodes, with the result that the file sizes are not set correctly when item recovery finishes. Fix this by restoring isize[12] from the log item. Cc: stable@vger.kernel.org # v6.10 Fixes: 966ceafc7a4371 ("xfs: create deferred log items for file mapping exchanges") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit f1930bc578095409c2dcfca6e4e898b24f0f0de6 Author: Darrick J. Wong Date: Tue Sep 1 22:44:05 2026 -0700 xfs: don't leak new_bp if xfs_btree_bload_drop_buf fails LOLLM observes that in xfs_btree_bload_prep_block, xfs_btree_bload_drop_buf can hit an IO error if writing the delwri buffer list to disk fails. In this case, we fail to release new_bp, which means we lose a locked buffer. Fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: e069d549705e49 ("xfs: constrain dirty buffers while formatting a staged btree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 5287e56cba3be4a64bff9f73bce5964fda2590dc Author: Darrick J. Wong Date: Tue Sep 1 22:43:50 2026 -0700 xfs: preserve owner on in-memory btree creation LOLLM points out a minor bug where a higher level function creating an in-memory btree is required to pass in an owner number, but the creation function erases that. In-memory btrees are ephemeral so this really doesn't matter except for debugging. But let's fix this papercut. Cc: stable@vger.kernel.org # v6.9 Fixes: a095686a238352 ("xfs: support in-memory btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 022d5f5fce7f0b6125d404eb74044e6238aef369 Author: Darrick J. Wong Date: Tue Sep 1 22:43:34 2026 -0700 xfs: fix xfs_rtrmapbt_mem_cursor for non-rmap filesystems It's possible to construct an in-memory rtrmap btree for filesystems that don't have the rmap feature enabled. The kernel doesn't do this, but xfs_repair will, if asked to reindex a filesystem that has rtreflink enabled but not rtrmap. Therefore, we must create the cursor with enough levels to handle a maximally sized btree possible. Note that the rtrmapbt btree cursor slab creates objects large enough to handle xfs_rtrmap_maxlevels_ondisk() levels, so setting bc_nlevels to the same value isn't costing us any extra memory. Cc: stable@vger.kernel.org # v6.14 Fixes: 4a61f12eb11958 ("xfs: create a shadow rmap btree during realtime rmap repair") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit aa301322f72f82f26e4ba0826018d41388ab9896 Author: Darrick J. Wong Date: Tue Sep 1 22:43:02 2026 -0700 xfs: fix the rtrmap and rtrefcount _maxlevels_ondisk functions The _maxlevels_ondisk functions are used to compute the size of in-memory btree cursors for each btree type. Unfortunately, LOLLM noticed that the rtrmap and rtrefcount versions of these functions forget to account for the inode root, which means that we could access beyond the end of the cursor given a sufficiently large btree. Fix this. Cc: stable@vger.kernel.org # v6.14 Fixes: 9abe03a0e4f978 ("xfs: introduce realtime refcount btree ondisk definitions") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 2eac8d01d2c776fc26b0ac74aebdf91bc4490891 Author: Darrick J. Wong Date: Tue Sep 1 22:42:47 2026 -0700 xfs: don't leak dqacct if rhashtable insertion fails LOLLM observes that xqcheck_mod_live_ino_dqtrx doesn't free the newly allocated dqa object if rhashtable insertion fails. Fix this leak. Cc: stable@vger.kernel.org # v6.9 Fixes: 200491875ce144 ("xfs: track quota updates during live quotacheck") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 72d0a3e4405c1353869bfbbc67c7b8a29df7afd0 Author: Darrick J. Wong Date: Tue Sep 1 22:42:31 2026 -0700 xfs: fix name string recording in slowpath pptr tracepoints LOLLM observes that we memcpy from the xfs_name object, not the name string pointed to by the xfs_name. Fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: b961c8bf1fc3d0 ("xfs: deferred scrub of dirents") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit eacb8479507756c3305994e87fb2fb1183827e98 Author: Darrick J. Wong Date: Tue Sep 1 22:42:15 2026 -0700 xfs: fix short ifork reaping computation in xreap_bmapi_binval LOLLM got really confused about the update to imap->br_blockcount in xreap_bmapi_binval if xreap_inc_binval returns false. The intent of this code is that we shorten the imap to whatever length of space we invalidated so that the next iteration through the loop will start wherever we left off. Unfortunately, the calculation sets br_blockcount to the amount of *unfinished* work, which means that we pointlessly re-scan blocks that we already reaped. This is benign, but we should fix the computation anyway. Cc: stable@vger.kernel.org # v6.10 Fixes: 5befb047b9f4de ("xfs: add the ability to reap entire inode forks") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 05cff7c2b79f76c7cfe90613a60e16aaaa051ef7 Author: Darrick J. Wong Date: Tue Sep 1 22:41:59 2026 -0700 xfs: fix unit conversions in per_binval computation LOLLM noticed that we're doing the unit conversion in the per_binval computation backwards -- xfs_buf_inval_log_space's second parameter is supposed to be in bytes, but max_binval is in units of fsblocks. Hence the conversion should be FSB -> B, not the other way around. Cc: stable@vger.kernel.org # v6.18 Fixes: b2311ec6778fcd ("xfs: compute per-AG extent reap limits dynamically") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 48d2b8351bae6d40b44f544fe5540868a55872b2 Author: Anuj Gupta Date: Tue Sep 1 11:13:48 2026 +0530 xfs: release alleged child inode on metapath unlink error If xchk_metapath_ilock_parent_and_child() fails after xchk_iget() succeeds, release the inode reference before returning. Fixes: 0d2c636e489c ("xfs: repair metadata directory file path connectivity") Cc: stable@vger.kernel.org # v6.13 Signed-off-by: Anuj Gupta Reviewed-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit 5344402f2c65984cee01a053fd1fa92c44b6aa7d Author: Eric Sandeen Date: Fri Aug 21 17:26:39 2026 -0500 xfs: mark slab-allocated xfs_buf backing memory as __GFP_RECLAIMABLE xfs_bufs have a shrinker and are therefore reclaimable, as is the memory backing them. Mark slab-allocated backing memory as __GFP_RECLAIMABLE in the kmalloc path so that it is accounted properly. Signed-off-by: Eric Sandeen Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 4164b1e3d728c7cc05e0c1171068aa046542ecc3 Author: Eric Sandeen Date: Fri Aug 21 17:03:37 2026 -0500 xfs: fix reclaimed page accounting in xfs_buf_free To obtain nr. of pages in "size" bytes, we need howmany(size, PAGE_SIZE) not howmany(size, PAGE_SHIFT). This over-reports reclaim by orders of magnitude, up to 4096x on a 64k page system. Fixes: e2874632a621 ("xfs: use vmalloc instead of vm_map_area for buffer backing memory") Cc: stable@vger.kernel.org # v6.15+ Signed-off-by: Eric Sandeen Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino commit 7538ba528cfd6f176076186c1b1678fdca1c197b Author: Darrick J. Wong Date: Wed Aug 26 22:32:28 2026 -0700 xfs: lock the healthmon when inserting unmount event LOLLM complains that xfs_healthmon_unmount does an unlocked insert of the unmount event into the health monitor's event list. Fix that. Cc: stable@vger.kernel.org # v7.0 Fixes: 25ca57fa3624ca ("xfs: convey filesystem unmount events to the health monitor") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 9dd6cc92a736a7943dd29776b6eb1938c7f9b94c Author: Darrick J. Wong Date: Wed Aug 26 22:32:12 2026 -0700 xfs: handle reconnecting metadir subdirectories A longstanding weakness of the metapath repair code is that it can only reattach non-directories to the metadata directory tree. Let's fix that by allowing reconnection of subdirectories. Note that with the initial users of metadir (rtgroups and quota), there's no way to mount a filesystem with broken /rtgroups or /quota subdirectories, so this code won't be all that useful until something adds deeper directory trees. But we shouldn't leave a logic bomb for those futures users wherein we get the link count wrong for a subdir. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit cdc4a083adf7bf15a0722c5bd292a35e00112006 Author: Darrick J. Wong Date: Wed Aug 26 22:31:56 2026 -0700 xfs: fix parent rec lookup initialization in xrep_metapath_unlink LOLLM notices that xrep_metapath_unlink looks for a parent pointer in the child metafile that it's removing, but initializes the parent handle using the child. This is obviously incorrect, so fix that. Cc: stable@vger.kernel.org # v6.13 Fixes: 0d2c636e489c11 ("xfs: repair metadata directory file path connectivity") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit ed799148e0d63ef41ab60ce98963a1dc423090d3 Author: Darrick J. Wong Date: Wed Aug 26 22:31:41 2026 -0700 xfs: log the tempip after we convert it to extents format LOLLM points out that xrep_symlink_swap_prep converts sc->tempip to an extents format file prior to the atomic swap, but incorrectly logs sc->ip immediately afterwards. Fix that, and the other problem that we're supposed to tell xfs_trans_log_inode what to log and don't. Cc: stable@vger.kernel.org # v6.10 Fixes: 2651923d8d8db0 ("xfs: online repair of symbolic links") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 865b751e75039fc07838b3200f9740256653da9a Author: Darrick J. Wong Date: Wed Aug 26 22:31:25 2026 -0700 xfs: don't stash removename operations with unknown ftype LOLLM notices that the behavior of xrep_dir_replay_update changes based on the ftype recorded in the stashed removename information. It also notices that the unlink iops sometimes set that ftype to FT_UNKNOWN because the regular directory tree update code paths don't need to know the ftype of the child. Unfortunately, this results in incorrect link counts, which eventually trips link count errors in later phases of xfs_scrub, or in xfs_repair. Fix this by creating a second xfs_name with the type set correctly. Cc: stable@vger.kernel.org # v6.10 Fixes: 8559b21a64d983 ("xfs: implement live updates for directory repairs") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 9f84792b40d0c96833341602144574bf0bd14a6a Author: Darrick J. Wong Date: Wed Aug 26 22:31:10 2026 -0700 xfs: don't spin forever on zero-length dirents when salvaging them LOLLM noticed that xrep_dir_recover_data can spin forever if it encounters an unused dirent that claims to have length zero. Fix that, and prevent the same thing from happening with a zero-length entry. Cc: stable@vger.kernel.org # v6.10 Fixes: b1991ee3e7cf85 ("xfs: online repair of directories") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 0fe77e57588b989450d668f7c978bb0264c5c340 Author: Javier Tia Date: Mon Aug 10 17:06:18 2026 -0600 xfs: assert the reservation covers each da fork growth xfs_da_grow_inode_int() subtracts the blocks it just allocated from args->total, the caller's remaining block reservation. The subtraction is unsigned, so a caller that reaches it with too small a total wraps the field instead of failing, and every allocation afterwards runs with a bogus reservation. Assert the remaining reservation still covers the step, so an under-reserved or uninitialised total trips in debug builds instead of silently wrapping. Suggested-by: Darrick J. Wong Signed-off-by: Javier Tia Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino commit 8e4ebb6afaa34bd2e8ce52da231003d24111c2d6 Author: Javier Tia Date: Mon Aug 10 17:06:17 2026 -0600 xfs: initialise args->total for parent pointer updates xfs_parent_da_args_init() builds an xfs_da_args from a zeroed xfs_parent_args (kmem_cache_zalloc), leaving args->total == 0. xfs_da_grow_inode_int() treats that field as a running block reservation and subtracts from it; because it is an xfs_extlen_t (uint32_t), the first attr-fork growth wraps it to ~0U. That defeats the free-space check in xfs_alloc_space_available(), and when it coincides with an AG that has exactly zero available blocks the allocation is clamped to maxlen 0 and returns -ENOSPC, which xfs_defer_finish_noroll() escalates to a filesystem shutdown. Set args->total the way the log recovery path does (xfs_attri_recover_work(), xfs_attr_item.c:706), in the add and replace paths that can grow the fork. Removals and lookups never grow it, so they leave the field alone, matching that switch. Fixes: b7c62d90c12c ("xfs: parent pointer attribute creation") Cc: stable@vger.kernel.org # v6.10 Signed-off-by: Javier Tia Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino commit 6c0fc3cb4e879927b338b4fcb6de6a25c0a67608 Author: Javier Tia Date: Mon Aug 10 17:06:16 2026 -0600 xfs: correct the parent pointer space reservation comment The comment on xfs_parent_calc_space_res() claims parent pointers are "always the first attr in an attr tree". They are not: a parent pointer is recorded per dirent, so by the Nth hardlink the attr fork is already in leaf or node format. The reservation is still correct, because XFS_DAENTER_SPACE_RES() covers a split at every level of a maximum-depth attr dabtree whatever format the fork is in, but anyone auditing a shortfall here is led by the comment to look for a bug that is not there. Rewrite the comment to state what actually bounds the result, and record why the double split allowance and the extent-add term differ from xfs_attr_calc_size(). Signed-off-by: Javier Tia Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino commit d058f24b163a8d63866ac6bbe5f06b41aabe97d7 Author: Javier Tia Date: Mon Aug 10 17:06:15 2026 -0600 xfs: report the error that made deferred work shut down the fs When a deferred operation fails and shuts the filesystem down, xfs_defer_finish_noroll() reports neither the errno nor which operation originated it, so the log cannot tell a transient -ENOSPC from real corruption. Report the operation type, errno and remaining reservation. trace_xfs_defer_finish_error() runs after xfs_force_shutdown(), which BUGs under fs.xfs.panic_mask and so never fires for the first failure; move it ahead of the shutdown and mirror it to xfs_alert() for systems without tracing armed. Capture the op name while the item is live (dfp is freed once its work list drains) and suppress the alert once the fs is already down. Signed-off-by: Javier Tia Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino commit 91c15cee394e9958898ef1ed55d9ced4c26e2800 Author: Javier Tia Date: Mon Aug 10 17:06:14 2026 -0600 xfs: give the deferred barrier op type a name xfs_barrier_defer_type is the only xfs_defer_op_type with no .name. Every other one carries a short string used for tracing and reporting: attr, bmap, extent_free, agfl_free, rtextent_free, refcount, rtrefcount, rmap, rtrmap and exchmaps. That has been harmless because nothing dereferences the field, but it leaves a NULL in a table where every other entry is populated, so the first caller to print it gets "(null)" in the kernel and undefined behaviour in the userspace libxfs build of this file, where xfs_alert lands in fprintf. xfs_defer_add() already treats a missing member of this table as worth shutting the filesystem down for, so an unpopulated one is out of step with how the file handles its own ops tables. Signed-off-by: Javier Tia Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino commit 6176d21d7bd609632c5b7e87a3adb9be29ec1e72 Author: Javier Tia Date: Mon Aug 10 17:06:13 2026 -0600 xfs: initialise error in xfs_defer_finish_one() xfs_defer_finish_one() declares error without an initialiser and only assigns it inside the loop over dfp->dfp_work. When that list is empty the loop body never runs, control falls through to the "Done with the dfp, free it" path, and the function returns an indeterminate value. An item-less pending item reaches this through xfs_defer_add_barrier(), which xfs_reap_ag_blocks() uses on any CONFIG_XFS_ONLINE_REPAIR kernel. xfs_defer_finish_noroll() treats any non-EAGAIN return as fatal, so a non-zero stack value turns a successful barrier into a SHUTDOWN_CORRUPT_INCORE in the middle of a repair. Zero is the correct result: reaching the free path means the item loop drained without a non-zero error. Fixes: 3f3cec031099 ("xfs: force small EFIs for reaping btree extents") Cc: stable@vger.kernel.org Signed-off-by: Javier Tia Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino commit ed4abd8617ba348802575a0ae8e01e6c0f7eb2cf Author: Christoph Hellwig Date: Mon Jul 20 11:45:45 2026 +0200 xfs: add lock annotations to xfs_ail_delete* Pass up the __must_hold as clang requires it, and also fix the formatting of the __must_hold on xfs_ail_check to match how we do it elsewhere. Signed-off-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit 166089a856859d5f3e2b85c6ffd70da084238439 Author: Christoph Hellwig Date: Mon Jul 20 11:45:44 2026 +0200 xfs: add a lock annotation to xlog_cil_push_background This is required to make the clang context analysis happy, which is more strict than the old sparse lock context tracking. Signed-off-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit 2d1b21fcc9f9463f939103d13d6a0bf05a529901 Author: Christoph Hellwig Date: Mon Jul 20 11:45:43 2026 +0200 xfs: add lock annotations to xlog_state_shutdown_callbacks Sparse used to get away without these despite dropping and reacquiring l_icloglock Signed-off-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit 912a5b8e344ad1e3cb6aefedf243404d522ad822 Author: Christoph Hellwig Date: Mon Jul 20 11:45:42 2026 +0200 xfs: add lock annotations to xfs_try_open_zone Improve the __acquires and __releases annotations so that the new clang code that is a bit more picky than sparse is happy. Signed-off-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit 64e1f211d97b42f6e12bef8e6decc207f8871a2d Author: Christoph Hellwig Date: Mon Jul 20 11:45:41 2026 +0200 xfs: improve lock annotations in the log code Improve the __acquires and __releases annotations so that the new clang code that is a bit more picky than sparse is happy. This involves passing an explicit struct xlog argument in a few places because alias analysis can't figure out it is the same lock when dereferencing changing iclogs. Signed-off-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit b2ae7f243583e795b1eb3f8977cccfd7e37a8dfc Author: Christoph Hellwig Date: Mon Jul 20 11:45:40 2026 +0200 xfs: fix the lock annotation in xfs_mru_cache_lookup Name the actual lock. Unlike sparse, clang wants the annotation to be correct. Signed-off-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit 2078c2d6e1748df6c4c2b28f06797cba4ecda85c Author: Christoph Hellwig Date: Mon Jul 20 11:45:39 2026 +0200 xfs: fix the lock annotation in xfs_extent_busy_update_extent Name the correct lock. Signed-off-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit cf3a01684f323dd905d83230b7cb705fabdbcb7b Author: Christoph Hellwig Date: Mon Jul 20 11:45:38 2026 +0200 xfs: fix the lock annotation on xfs_iget_cache_hit The newer clang context analysis requires __releases_shared for the RCU pseudo-lock. Signed-off-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit a23eca88448e52eb1a81549862df7adce794fafb Author: Lin Jiapeng Date: Tue Jul 28 15:19:10 2026 +0800 xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN When exchanging two full-file ranges, xmi_can_exchange_reflink_flags() can move the reflink inode flag from the file that currently has it to the other file, as long as exactly one side is marked. This assumes that the file contents, and therefore all shared extents, are exchanged. That assumption is not true when XFS_EXCHMAPS_INO1_WRITTEN is set. xfs_exchmaps_can_skip_mapping() can skip hole and unwritten mappings from file1, so an exchange can complete without moving every mapping that the earlier flag-swap decision accounted for. In that case the post-operation cleanup can clear the reflink flag from an inode that still owns shared written extents. Later writes then take the non-reflink write path and may update blocks that should still have been protected by CoW, which shows up as data corruption between reflink-related files. Fix this by disabling the reflink flag exchange whenever XFS_EXCHMAPS_INO1_WRITTEN is requested. The contents exchange can still proceed; the conservative outcome is that both inodes keep the reflink flag. The regular reflink flag cleanup path can drop the extra flag later once the inode no longer has shared extents. Reported-by: Lin Jiapeng (TencentOS Red Team) Fixes: 966ceafc7a43 ("xfs: create deferred log items for file mapping exchanges") Cc: stable@vger.kernel.org # v6.10 Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Lin Jiapeng Signed-off-by: Carlos Maiolino commit ff99a5f6cbcc9c4810a8dac46fe76473539513f9 Author: Hans Holmberg Date: Wed Aug 26 14:32:19 2026 +0200 xfs: prevent race in zoned space reservations xfs_zoned_add_available() checks whether the reservation list is empty before adding blocks to the available-space counter. This check is not serialized against a task adding itself to the reservation list however. This allows the space provider to observe an empty list, after which a reserver can enqueue itself and retry the counter before the new space is added. The provider then adds the space and returns without waking the now-eligible reserver, leaving it asleep until GC or another event provides a wakeup, potentially adding seconds to max write latency. Take the reservation lock before updating the counter and checking the list. Use list_empty() because the list is now inspected under its lock. Taking a per-mount lock when handing back space is far from ideal, but benchmarking with null_blk showed no measurable performance regression. Fixes: 0bb2193056b5 ("xfs: add support for zoned space reservations") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260609075655.1698743-1-hch@lst.de?part=2 Signed-off-by: Hans Holmberg Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit f789d291bbdac6bc02d9d77e0141e138626c17a8 Author: Darrick J. Wong Date: Thu Aug 20 20:58:06 2026 -0700 xfs: fix media verification ioctl for internal rt volumes A media scan of a filesystem containing an internal rt volume produced an error in xfs_scrub phase 6 complaining about a truncated realtime device. The rt device wasn't truncated, but the media scan code thought we were trying to start a scan past the end of m_rtdev_targp. That in turn is an alias for m_ddev_targp, but in xfs_configure_buftarg we set nr_sectors to the size of the data section. We don't account for an internal realtime section, so the kernel doesn't scan any part of it. Oops. Reproducer: # mkfs.xfs -f /dev/sda -r zoned=1 -d rtinherit=1 # mount /dev/sda /mnt # dd if=/dev/zero of=/mnt/a bs=1024k count=100 # sync # xfs_info /mnt meta-data=/dev/sda isize=512 agcount=4, agsize=32768 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=0 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=131072, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =internal extsz=4096 blocks=1114112, rtextents=1114112 = rgcount=17 rgsize=65536 extents = zoned=1 start=131072 reserved=53248 IOWS: 512M data volume, 3.1G internal rt section. Now let's try some media verification: # xfs_io -c 'verifymedia -d' -c 'verifymedia -r' /mnt verified 536870912/536870912 bytes at offset 0 512 MiB, 1 ops; 0.0496 sec (10.067 GiB/sec and 20.1345 ops/sec) verified 536870912/536870912 bytes at offset 0 512 MiB, 1 ops; 0.0409 sec (12.222 GiB/sec and 24.4439 ops/sec) Notice how xfs_io says we only verified 512M of the rt volume? If you run btrace in the background you'll see that we read the first 512M of the volume (aka the data section) twice and never read anything from the rt section. An earlier fix tried messing with the buftarg geometry, but I've decided on a more targetted fix for the media verification code. All we have to do is calculate the starting and ending daddr for the device that we're verifying, and clamp the user's input values to that range. This leads to some bogosity in the output reporting: # xfs_io -c 'verifymedia -d' -c 'verifymedia -r' /mnt/t verified 536870912/536870912 bytes at offset 0 512 MiB, 1 ops; 0.0606 sec (8.248 GiB/sec and 16.4968 ops/sec) verified 5100273664/5100273664 bytes at offset 0 4.750 GiB, 1 ops; 0.3329 sec (14.267 GiB/sec and 3.0035 ops/sec) Because we don't have a way to report that we didn't really do anything at all for that first 512M of address space of the rt "device". But at least we're no longer ignoring real media. (Note that the fsmap/bmap/fiemap calls all report physical addresses for the internal rt volume as offsets from the start of the data device, and the media verifier call consumes the same. We baked that into the user-visible behavior in 6.15, so we're stuck with that sparse hole at the beginning.) Cc: stable@vger.kernel.org # v6.15 Fixes: bdc03eb5f98f6f ("xfs: allow internal RT devices for zoned mode") Signed-off-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 5ba79d37403d86082ab4083b0f51ec3008a942cb Author: Thorsten Blum Date: Fri Jul 3 18:58:35 2026 +0200 powerpc/ps3: Fix repository.c build failure GCC fails to build ps3_defconfig with the following errors: arch/powerpc/platforms/ps3/repository.c: In function ‘make_first_field.constprop’: arch/powerpc/platforms/ps3/repository.c:78:9: error: ‘strnlen’ specified bound 8 exceeds source size 3 [-Werror=stringop-overread] 78 | memcpy((char *)&n, text, strnlen(text, sizeof(n))); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/platforms/ps3/repository.c: In function ‘make_first_field.constprop’: arch/powerpc/platforms/ps3/repository.c:78:9: error: ‘strnlen’ specified bound 8 exceeds source size 4 [-Werror=stringop-overread] 78 | memcpy((char *)&n, text, strnlen(text, sizeof(n))); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The current use of strnlen(text, sizeof(n)) triggers -Wstringop-overread when text is a short string literal that is smaller than sizeof(n), such as "bi" or "bus". Use strlen(text) instead and clamp the copy length to sizeof(n) before memcpy(). Drop the redundant char * cast while at it. Fixes: f94a84a09148 ("powerpc/ps3: refactor strncpy usage") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260703165834.137242-2-thorsten.blum@linux.dev commit 7d38af8f20239a66e90de7632a79c9425256c574 Author: Salah Triki Date: Mon Aug 24 05:29:07 2026 +0100 iio: proximity: vcnl3020: fix ISR bitmask check in IRQ handler The threaded IRQ handler contained multiple issues in handling interrupt events and clearing status flags: 1. ISR bit check: The handler incorrectly checked the Interrupt Status Register (VCNL_ISR) against VCNL_ICR_THRES_EN (BIT(1)), which is a bitmask meant for the Control Register (VCNL_PS_ICR). In VCNL_ISR, BIT(1) corresponds only to low-threshold interrupts. A high-threshold interrupt (VCNL_INT_TH_HI, BIT(0)) on its own was completely ignored and returned IRQ_NONE. 2. Event direction & channel index: The handler unconditionally pushed a RISING event code on channel index 1. The driver only registers a single proximity channel (index 0), and low-threshold interrupts should be reported with IIO_EV_DIR_FALLING. 3. ISR clearing: The write-back to acknowledge the interrupt only preserved BIT(1) instead of masking against both valid status bits. Fix this by checking both VCNL_INT_TH_HI and VCNL_INT_TH_LOW bits in VCNL_ISR, pushing separate IIO events with the correct direction and channel index (0), and properly clearing handled status bits. Fixes: 3363fbbe19e5 ("iio: proximity: vcnl3020: add periodic mode") Signed-off-by: Salah Triki Reviewed-by: Ivan Mikhaylov Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit e24328974a88aa8541e94e8bb8dfa2ade1b3c45d Author: Donggeun Yoo Date: Wed Sep 2 00:21:26 2026 +0900 iio: proximity: vl53l0x-i2c: claim direct mode for raw reads vl53l0x_read_raw() starts a single-shot ranging measurement and reads back the result. Once the triggered buffer is enabled the sensor runs in continuous mode and its data-ready interrupt is routed to the trigger, so a concurrent in_distance_raw read disturbs the streaming setup and never gets its completion, returning -ETIMEDOUT. The original submission claimed direct mode here, but it was dropped during review because the driver had no buffer support at the time [1]. Continuous (buffered) mode was later added without restoring the claim [2], reintroducing the conflict. Reject direct reads while buffered capture is active by claiming direct mode around the measurement, as the vl53l1x sibling already does. Fixes: 762186c6e7b1 ("iio: proximity: vl53l0x-i2c: Added continuous mode support") Link: https://lore.kernel.org/linux-iio/20180911160300.GA9212@himanshu-Vostro-3559/ [1] Link: https://lore.kernel.org/linux-iio/20240909101508.263085-3-abhashkumarjha123@gmail.com/ [2] Signed-off-by: Donggeun Yoo Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit 2ac74c6db40adaa29c50cbb281ae9a6f63de18e1 Author: John Hubbard Date: Sun Sep 6 14:58:22 2026 -0700 rust: allow `clippy::as_underscore` in the generated bindings A CLIPPY=1 build emitted about 15000 `as _` conversion warnings, all of them in bindgen's generated output and none in hand-written code. [ The lint messages look like: error: using `as _` conversion --> rust/bindings/bindings_generated.rs:18947:9 | 18947 | self._bitfield_1.get_const::<0usize, 16u8>() as u32 as _ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^- | | | help: consider giving the type explicitly: `u32` | = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.98.0/index.html#as_underscore = note: `-D clippy::as-underscore` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::as_underscore)]` - Miguel ] bindgen 0.73 returns each bitfield read through a trailing `as _`, and 0.72 returns it through a transmute, which the lint ignores. The bindings and uapi crates allow `clippy::all` over the generated code. That group does not cover `clippy::as_underscore`, a restriction lint. Allow `clippy::as_underscore` by name in the bindings and uapi crates. Assisted-by: LLM Signed-off-by: John Hubbard Link: https://patch.msgid.link/20260906215822.1201022-1-jhubbard@nvidia.com Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). [ Removed CI sentence. - Miguel ] Signed-off-by: Miguel Ojeda commit 89ff16f0713917303210c560eec5cd0c13bd651f Author: Tejun Heo Date: Sat Sep 5 12:53:44 2026 -1000 sched_ext: scx_qmap: Fix pending partition work handoff qmap can leave partition work pending with no runner. The effective-cap callback publishes its request after failing to acquire part_busy, while redistribute() checks for pending work before releasing it. Either ordering can miss a request arriving as the current runner finishes, delaying the update until the round-robin timer runs. Publish requests before trying to become the runner and release part_busy before checking for more work. Have all holders drain pending requests after releasing it, including the stats flush. Distinguish mask refreshes from repartitions so an effective-cap update only rebuilds the partition when a repartition was also requested. Fixes: e9151ed5c944 ("tools/sched_ext: scx_qmap - Expand hierarchical sub-scheduling") Reported-by: Andrea Righi Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit df2908090cda368b01ff43709f51890076c56157 Author: Linus Torvalds Date: Sun Sep 6 15:07:20 2026 -0700 Linux 7.3-rc2 commit ef7707c1b7c7bcd09298114fa64d1494727e20b1 Author: Tuna Kılıç Date: Fri Sep 4 12:25:17 2026 +0000 iio: dac: mcp47a1: Allow full-scale output The MCP47A1 has 64 resistors but exposes 65 wiper positions. The valid DAC codes are 0 through 64, and code 64 selects VREF. The driver currently advertises 0 through 63 and uses 64 as the length argument to in_range(), which also rejects 64. Therefore userspace cannot select full-scale output. Advertise code 64 and make validation cover all 65 codes. Keep 64 as the scale denominator because the output voltage is VREF multiplied by the code and divided by 64. Fixes: 350d1fb9204b ("iio: dac: mcp47a1: add support for new device") Signed-off-by: Tuna Kılıç Reviewed-by: Joshua Crofts Tested-by: Joshua Crofts Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit e65e128b51a37dd1a9056ac3d1705d805a5c8bb0 Author: Matti Vaittinen Date: Wed Sep 2 11:49:05 2026 +0300 iio: accel: kionix-kx022a: Prevent memory leak and fix state The driver allocates memory for samples at buffer enable path. If regmap operation fails in the kx022a_fifo_enable() at the buffer enable path, the allocated memory is never freed. Furthermore, the state information and previous hardware configuration(s) aren't undone, potentially leaving WMI interrupts and buffers enabled, or driver state flags wrong. Free the memory and revert the hardware configuration and state flags on error path. Fixes: e7123a4dfcd7 ("iio: accel: kionix-kx022a: Refactor driver and add chip_info structure") Signed-off-by: Matti Vaittinen Reviewed-by: Mehdi Djait Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit 8065a6c02f629187131f3136bedb26f9080e3cca Author: Matti Vaittinen Date: Wed Sep 2 11:48:46 2026 +0300 iio: light: rohm-bu27034: Fix infinite delay on error When reading an integration-time fails, the code will use error code to compute the sleep time. Fix this by using the smallest integration time as a default if reading fails. Fixes: e52afbd61039 ("iio: light: ROHM BU27034 Ambient Light Sensor") Suggested-by: Jonathan Cameron Signed-off-by: Matti Vaittinen Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit b1e00ffaf91c41eb752a1c200295c9ab7abfae1d Merge: 2beb1b31a12b57 d80e12156f1fd4 Author: Linus Torvalds Date: Sun Sep 6 14:21:24 2026 -0700 Merge tag 'trace-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Fix several tracefs files that did not take the trace_array reference A trace instance can be created and destroyed in the tracefs "instances" directory via mkdir and rmdir respectively. The instance is represented by a trace_array descriptor. Most tracefs files pass the trace_array as the private data of the inode to the open/read/write functions. Since there is no locking between the time a task opens a file and the deletion of the instance (and the freeing of the trace_array), each open needs to get a reference to the trace_array and each close must remove it. An instance can't be removed if there's any reference taken on its trace_array. The open function uses trace_array_get() that takes a lock (preventing removal of instances) and iterates the list of all existing trace_arrays and if it finds a match, it takes the reference and releases the lock. If it doesn't find a match, it causes the open to return -ENODEV. There were some added files that did not take the trace_array reference on open that needed to be fixed. Sashiko also correctly pointed out that there were some files that took an address of an field or element of the trace_array which had a pointer back to the trace_array to take its reference on open. But this leaves a slight race between referencing this element to get the trace_array as the element itself could be freed. To solve this, some helper functions were created to look for trace_arrays with this field or element in the search so that the element did not have to be dereferenced before the trace_array's reference was taken. - Add a lock around ftrace_ops initialization When a ftrace_ops is first used by ftrace, some internal initialization is performed on the ops. But if multiple tasks were calling functions that did this initialization, it could race and perform doing the initialization more than once, corrupting the internal data. Add a lock in the initialization code to prevent this from happening. - Fix splice reads on mmapped buffers The logic in the ring buffer splice code for mmapped buffers is supposed to do a copy of the memory as the mapped buffers can't be given to splice. But there was an if statement within the copy code that would return a -1 if a request for a full page was done and it wasn't a partial read. This is because this logic was written before mmapped buffers existed and this case didn't make sense at the time. For mmapped buffers it makes perfect sense and by returning early can drop a lot of pages unnecessarily. - Have the persistent ring buffer validation check nr_subbufs Sashiko reported that the validation code was relying on the saved nr_subbufs to match the calculated nr_pages + 1 and if they were off, that the code could cause corruption. Sashiko is correct, and the saved nr_subbufs should be validated before assuming it is correct. - Do not allow more than one instance with the same name on cmdline If an admin were to add more than one trace instances with the same name they all would be created, but only the first one would be accessible via tracefs. This used to not be allowed but some restructuring of code has since made it possible. - Fix the race between subbuf resize and trace_pipe_raw readers If a task was reading trace_pipe_raw while another task was changing the ring buffer subbuf size, it could crash the reader. The trace_pipe_raw readers do get their own copy of the page from the buffer, but the code needs some restructuring to not have the resize of the subbuffers cause issues. - Cap the size of the mapped (static) ring buffer nr_pages The meta data used for ring buffer mapped buffers is 32 bit in size. A normal ring buffer could (in theory) have more than 4 billion pages. But this is not allowed by mapped buffers, so enforce it. * tag 'trace-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: ring-buffer: Use a macro for static buffer bits tracing: Fix comment in tracing_buffers_splice_read() ring-buffer: Prevent truncation of nr_pages / nr_subbufs ring-buffer: Cap static ring buffer nr_pages tracing: Fix subbuf resize races with trace_pipe_raw readers tracing: Fix to avoid creating trace instances with duplicate names ring-buffer: Add checking nr_subbufs to persistent ring buffer validation ring-buffer: Allow splice reads on static buffers tracing: Take trace_array reference when opening options file ftrace: Synchronize the initialization of ftrace_ops ftrace: Take trace_array reference before accessing its ftrace_ops tracing: Have show_event_filters/triggers files take trace array ref commit 2beb1b31a12b57e19cd5c82ea6d54e56520605e8 Merge: 88405f0ad1d5c6 536b523b407397 Author: Linus Torvalds Date: Sun Sep 6 13:49:44 2026 -0700 Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Pull bpf fixes from Alexei Starovoitov: "This mainly contains verifier fixes that address bugs reported by Nicholas Carlini. - Fix incorrect non-NULL inference in pointer comparisons: pointer types that may be NULL at runtime, pointers with unbounded offsets, JMP32 comparisons with zero, and imprecise zero registers (Eduard Zingerman) - Fix precision tracking for half-dead zero spills, ld_abs/ld_ind implicit subprog exit, bpf_loop() callbacks, linked scalar ids and NULL call arguments (Eduard Zingerman) - Reject BPF_PSEUDO_FUNC reference to the main program, fix zero extension of arena 32-bit cmpxchg, don't rewrite bpf_fastcall patterns entered by a jump (Eduard Zingerman) - Fix percpu map update and BPF_F_CPU validation with sparse CPU IDs (Hui Su) - Fix NULL-ptr-derefs in bpf_snprintf_btf() for void and VAR types, and reject key-less BTF for hash maps (Jiayuan Chen) - Various fixes (Kumar Kartikeya Dwivedi): - Fix out-of-bounds access in disassembler on invalid LDSX instruction - mark siginfo of signal tracepoints as scalar and sched_process_wait argument as nullable - mark faultable stack helpers as sleepable - reject tail calls and legacy packet loads from callbacks - enforce rbtree callback lock restrictions for resilient locks - require MEM_PERCPU for percpu kptr stores - clear NON_OWN_REF after RCU protection ends - mark NULL kptr stores precise - preserve inner map identity in callback frames - reject non-scalar bpf_loop() iteration counts - Fix trampoline allocation slowdown on x86 by using EXECMEM_MODULE_DATA (Mike Rapoport) - Keep bpf_refcount_acquire() nullable for borrowed RCU kptrs and reject untrusted allocated-object pointers (Ning Ding) - Fix special fields handling in recycled rhtab elements (Nuoqi Gui, Yuan Chen)" * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: (86 commits) bpf, riscv: Make arena support depend on ZACAS selftests/bpf: Test pointer bpf_loop iteration count rejection bpf: Reject non-scalar bpf_loop iteration counts bpf: use mark_arg_precision() in check_mem_size_reg() bpf: propagate mark_chain_precision() errors out of loop_flag_is_zero() selftests/bpf: precision of a NULL global subprogram BTF_ID argument bpf: mark a NULL BTF_ID argument of a global subprogram precise selftests/bpf: precision of a NULL kfunc argument bpf: mark a NULL kfunc argument precise selftests/bpf: precision of a NULL global subprogram memory argument bpf: mark a NULL memory argument of a call precise selftests/bpf: precision of a NULL helper argument bpf: mark a NULL call argument precise selftests/bpf: Test inner map identities in callbacks bpf: Preserve inner map identity in callback frames selftests/bpf: Test imprecise scalar kptr stores bpf: Mark NULL kptr stores precise selftests/bpf: Test rhtab kptr cancellation semantics bpf: Cancel special fields when recycling rhtab elements selftests/bpf: Test timer field on recycled rhtab element ... commit 88405f0ad1d5c680afe3ea0ce9345fa9e1deaac8 Merge: c4a3928e7d0c08 f0d243a96f2684 Author: Linus Torvalds Date: Sun Sep 6 11:08:44 2026 -0700 Merge tag 'sched-urgent-2026-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Ingo Molnar: - Fix a timestamping bug in pick_task_fair() and yield_task_fair() (Zhan Xusheng) - Skip migrate-disabled tasks when picking a push candidate in the RT and DL schedulers (Seiji Nishikawa) - Skip rq->avg_idle update without a valid idle_stamp (Shubhang Kaushik) - Fix throttling bug in throttle_cfs_rq(), caused by the recent single-runqueue conversion (Wanwu Li) - Fix bandwidth calculation bug in distribute_cfs_runtime(), caused by the single-runqueue conversion (Wanwu Li) - Don't make x86 ITMT enablement depend on debugfs (Mario Limonciello) - Avoid creating misfits during cache-aware load-balancing on hybrid systems (Tim Chen) * tag 'sched-urgent-2026-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/fair: Avoid creating misfits during cache-aware balancing x86/itmt: Don't make ITMT enablement depend on debugfs sched/fair: Use cfs_rq->h_curr in distribute_cfs_runtime() sched/fair: Use cfs_rq->h_curr in throttle_cfs_rq() sched/core: Skip rq->avg_idle update without a valid idle_stamp sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate sched/fair: Use update_curr_eevdf() for the remaining root cfs_rq callers commit c4a3928e7d0c08f2946ec3cf2814ba7738a08347 Merge: c8990f3179e563 58a8108bc73de0 Author: Linus Torvalds Date: Sun Sep 6 11:06:09 2026 -0700 Merge tag 'perf-urgent-2026-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf events fixes from Ingo Molnar: - Skip empty AUX records with only format flags (Leo Yan) - Fix use-after-free when perf mmap() revival races with the last munmap() (Yilin Zhang, Weiming Shi) * tag 'perf-urgent-2026-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Fix use-after-free when perf mmap() revival races with the last munmap() perf/core: Skip empty AUX records with only format flags commit c8990f3179e5636832fc22e6a262de5d50c797e3 Merge: b4851319955447 a3b8d46fe401cb Author: Linus Torvalds Date: Sun Sep 6 10:45:46 2026 -0700 Merge tag 'locking-urgent-2026-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fixes from Ingo Molnar: - Fix a softirq processing delay bug in local_interrupt_disable(), which should mostly only affect the Rust runtime (Boqun Feng) - Remove the hardirq_disable_count() function which caused the previous bug and is now unused & unnecessary (Boqun Feng) - lockdep: Invalidate stale class_cache entries for zapped classes (Eric Dumazet) - Fix rt_mutex specific futex scheduling helpers (Sebastian Andrzej Siewior) - Fix rcuwait use-after-free race during futex requeue PI (Yao Kai) * tag 'locking-urgent-2026-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: futex: Prevent rcuwait use-after-free during requeue PI futex: Provide rt_mutex_.*_schedule() equivalents for futex scheduling locking/lockdep: Invalidate stale class_cache entries for zapped classes preempt: Remove hardirq_disable_count() interrupt: Disable interrupt before modifying hardirq_disable counter commit b485131995544741ba6dcc313d7eb573bca7bebc Merge: d3cbb9af724287 d31fbbade43f88 Author: Linus Torvalds Date: Sun Sep 6 10:35:24 2026 -0700 Merge tag 'irq-urgent-2026-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull IRQ subsystem fixes from Ingo Molnar: - Revert a commit to the mbigen irqchip driver that caused a regression on two-port Hi1616 chips (Caina) - Fix a too-long-preemption-off bug in the stm32mp-exti irqchip driver, caused by a time unit ambiguity & mismatch (Ju Nan) - Remove the now completely unused irq_domain_add_linear() inline function (Jiri Slaby) * tag 'irq-urgent-2026-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/stm32mp-exti: Fix the unit of the hwspinlock timeout Revert "irqchip/mbigen: Fix mbigen node address layout" irqdomain: Delete irq_domain_add_linear() commit 2cdc7ef31827db4fbc6283750420639569e1f0e9 Author: Felix Gu Date: Sun Sep 6 23:58:35 2026 +0800 iio: adc: sun4i-gpadc-iio: clean up on thermal zone registration failure If devm_thermal_of_zone_register() fails, probe returns without unregistering the IIO map array or disabling runtime PM. Jump to err_map to release them. Fixes: b0a242894f11 ("iio: adc: sun4i-gpadc-iio: register in the thermal after registering in pm") Signed-off-by: Felix Gu Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit 8b958dd214ad0c003f56549e9e039cb8067dc1a2 Author: Felix Gu Date: Sun Sep 6 23:58:34 2026 +0800 iio: adc: sun4i-gpadc-iio: drop underflowing pm_runtime_put() calls Neither the error path in sun4i_gpadc_probe() nor sun4i_gpadc_remove() ever holds a runtime PM usage count. So the pm_runtime_put() in both places always triggers the "Runtime PM usage count underflow!" warning on every failed probe and every unbind. Drop both calls. Fixes: d1caa9905538 ("iio: adc: add support for Allwinner SoCs ADC") Signed-off-by: Felix Gu Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit d3cbb9af7242873aae6fc2b7e8a991101a322201 Merge: bf979ab8f24657 b144dc5a24149b Author: Linus Torvalds Date: Sun Sep 6 09:55:20 2026 -0700 Merge tag 'tty-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull virtio console fix from Greg KH: "Here is a single virtio console fix for 7.3-rc2 to fix a much reported regression in 7.3-rc1, sorry about that. It's not been in linux-next, but it has been sent by many different developers to resolve the issue and is 'obviously' correct" * tag 'tty-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: virtio_console: allocate the port_buffer with the caller's gfp commit bf979ab8f24657ebc6193183cfef1669029e84a5 Merge: 65538a8f02fe6e cc7cd2a9228175 Author: Linus Torvalds Date: Sun Sep 6 09:49:06 2026 -0700 Merge tag 'staging-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging driver fixes from Greg KH: "Here are some small staging driver fixes to resolve some reported bugs that have been found, and tested, in a few staging drivers in 7.3-rc1. Included in here are: - OOB read problem fixes in the rtl8723bs driver - fbtft driver fix - sm750fb driver fix All of these have been in linux-next this week with no reported problems" * tag 'staging-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: sm750fb: fix mono image source stride mismatch in lynxfb_ops_imageblit() staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie() staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() staging: fbtft: make dirty_lock IRQ-safe commit 65538a8f02fe6e4f07228a816529b039b544f051 Merge: 1fc5a74b108fc9 c9273c83885835 Author: Linus Torvalds Date: Sun Sep 6 08:50:20 2026 -0700 Merge tag 'usb-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Here are some small USB driver fixes for reported problems and regressions. Include in here are: - xhci driver fixes - cdns3 driver fixes - usb gadget driver fixes for syzbot found problems - typec driver fixes for broken hardware and other bugs found - kernel data leaks in mdc800 driver - usb storage driver fixes - other small USB driver fixes All of these have been in linux-next this week with no reported issues" * tag 'usb-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (25 commits) usb: typec: qcom-pmic-typec: drain cc_debounce_dwork if port_start() fails usb: typec: qcom-pmic-typec: disable cc_debounce_dwork on stop usb: gadget: fix null pointer dereference in usb_put_function_instance() usb: typec: qcom-pmic: cancel reset_work on stop usb: gadget: f_mass_storage: fix null pointer dereference in fsg_common_set_num_buffers() usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns() usb: storage: realtek_cr: fix use-after-free on disconnect usb: cdnsp: fix wakeup from S3 after controller context loss usb-storage: ene_ub6250: fix race between scan work and probe USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() usb: gadget: f_midi: initialize work in f_midi_alloc() usb: gadget: f_midi2: fix use-after-free in string attribute show path usb: typec: tipd: Fix Thunderbolt altmode VDOs for cd321x usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs usb: typec: hd3ss3220: track VBUS enable state per consumer usb: dwc3: clear forceRM when issuing EndTransfer usb: dwc3: google: Initialise probe properties with DWC3_DEFAULT_PROPERTIES usb: typec: mux: avoid duplicated mux switches usb: typec: mux: Fix typec_switch_match() usb: image: mdc800: change kmalloc() to kzalloc() ... commit 536b523b407397c8d3967c020ce7aad70a0ea030 Author: Chen Pei Date: Wed Sep 2 14:14:51 2026 +0800 bpf, riscv: Make arena support depend on ZACAS The arena range tree allocates its nodes with kmalloc_nolock() since commit f8c67d8550ee ("bpf: Use kmalloc_nolock() in range tree"). kmalloc_nolock() requires slab caches with cmpxchg128 support (__CMPXCHG_DOUBLE); on riscv cmpxchg128 is provided by the ZACAS extension. On systems without ZACAS every arena map creation fails with a misleading -ENOMEM. Report the missing support instead: make bpf_jit_supports_arena() return system_has_cmpxchg128() where it is defined, so arena map creation fails with -EOPNOTSUPP on systems without ZACAS. The macro is only defined when both CONFIG_RISCV_ISA_ZACAS and CONFIG_TOOLCHAIN_HAS_ZACAS are enabled, so guard it with #ifdef the same way mm/slab.h consumes it, and reject arena otherwise. This matches how arena BPF_CMPXCHG instructions are already gated on ZACAS in bpf_jit_supports_insn(). Fixes: f8c67d8550ee ("bpf: Use kmalloc_nolock() in range tree") Signed-off-by: Chen Pei Acked-by: Pu Lehui Acked-by: Björn Töpel Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260902061451.1416-1-cp0613@linux.alibaba.com Signed-off-by: Kumar Kartikeya Dwivedi commit 33fb59da49c4c3f5c2ec9f9d4447a56857a02c02 Author: Jeffin Philip Date: Fri Sep 4 18:44:37 2026 +0530 RDMA/core: fix refcount bug in iwpm_get_nlmsg_request() iwpm_get_nlmsg_request() initializes refcount _after_ list_add_tail() making it accessible to global list where another CPU can kref_get() on nlmsg_request causing a refcount "addition on 0" bug. Fix this by initializing kref _before_ list_add_tail() so refcount for nlmsg_request can be incremented/decremented normally. In addition, also initialize every field before list_add_tail(). Reported-by: syzbot+bd317784d628820741b5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bd317784d628820741b5 Fixes: 30dc5e63d6a5 ("RDMA/core: Add support for iWARP Port Mapper user space service") Cc: stable@vger.kernel.org Signed-off-by: Jeffin Philip Link: https://patch.msgid.link/20260904131437.12917-1-jeffinphilip14@gmail.com Signed-off-by: Leon Romanovsky commit 45b5beb60bf7bd41c55ef17f6f2d28b351fad6c0 Author: Sebastian Dalfuß Date: Sat Sep 5 14:11:12 2026 +0200 ALSA: usb-audio: Add boot quirk for Behringer CM1A After a power cycle and reenumeration, the Behringer CM1A* leaves its MIDI endpoint inoperative. USB enumeration and driver binding complete successfully, but MIDI outputs remain pending. A GET_DESCRIPTOR request for the device descriptor, issued after USB configuration, makes the endpoint operational. Add a one time boot quirk to perform that request before ALSA initializes the device. * ID 1397:1234 BEHRINGER International GmbH CM1A Signed-off-by: Sebastian Dalfuß Link: https://patch.msgid.link/apwG4DRfNyvmRzyb@sedf.de Signed-off-by: Takashi Iwai commit 12cba0ce111c2caabf4ff24dc5538959813664c0 Author: Krish Gulati Date: Sun Sep 6 03:56:56 2026 +0530 ALSA: hda/realtek: Add quirk for HP Omen 16-wd0xxx mute LED Add SND_PCI_QUIRK entry for HP Omen 16-wd0xxx (PCI SSID 103c:8ba9) using ALC245_FIXUP_HP_MUTE_LED_V1_COEFBIT, which controls the mute LED via a COEF bit write on the ALC245 codec. Without this quirk, the mute LED does not reflect mute state on this model. Tested on the affected hardware; mute LED now toggles correctly. Signed-off-by: Krish Gulati Link: https://patch.msgid.link/20260905222659.10247-1-krishgulati7@gmail.com Signed-off-by: Takashi Iwai commit 8f5ef203abda9dd36b2af473c7b737d544f807bd Author: Tristan Madani Date: Fri Sep 4 20:58:26 2026 +0000 ALSA: usbusx2y: validate URB actual_length in interrupt callback i_usx2y_in04_int() processes the interrupt URB data without checking urb->actual_length. A short transfer from a malfunctioning device would cause the handler to process uninitialized heap data from the kmalloc-allocated in04_buf, which is then copied to the mmap-accessible ctl_snapshot[] array. Fix by using kzalloc() for in04_buf to zero-initialize the buffer, and adding an actual_length check to skip processing on short transfers while still resubmitting the URB. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Link: https://patch.msgid.link/20260904205826.4071119-2-tristmd@gmail.com Signed-off-by: Takashi Iwai commit 861111a14740e12c36d363e9830f8daa734279c9 Author: Tristan Madani Date: Fri Sep 4 20:58:25 2026 +0000 ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf The in04_last array in struct usx2ydev is declared as char[24], but in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes. In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization path): memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last)); This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes past the end of the source object. Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct us428_ctls) and use it consistently for the in04_last array, the in04_buf allocation, the URB transfer length, and the comparison loop, replacing the bare 24 and 21 literals throughout. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Link: https://patch.msgid.link/20260904205826.4071119-1-tristmd@gmail.com Signed-off-by: Takashi Iwai commit b26a7a80e6bbf8dd17dacb127d12435d79375cf2 Author: Roman Prucha Date: Thu Sep 3 23:14:44 2026 +0200 ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough dao_rsc_init() encodes the DAIO configuration as conf = (desc->msr & 0x7) | (desc->passthru << 3); S/PDIF passthrough uses msr=1 and passthru=1, resulting in conf=9. daio_mgr_dao_init() masks conf with 0xf, but handles only values 1, 2, 4 and 8 when programming ATXCTL_NUC. As a result, conf=9 falls through to the default case and leaves NUC at its previous setting. On a Creative X-Fi Titanium HD SB1270 (CA20K2), this breaks AC3 IEC61937 passthrough when snd_ctxfi runs with reference_rate=48000,multiple=2. The receiver detects a non-audio stream but cannot decode the AC3 payload. With the unmodified driver, multiple=1 makes the same stream work. Handle conf=9 through the same NUC=0 path as conf=1. The change was runtime tested on the SB1270 with multiple=2 using IEC958 stereo PCM, pre-encoded AC3 IEC61937 passthrough and ALSA A52 live 5.1 encoding. Fixes: 26a9630c72eb ("ALSA: ctxfi: cthw20k2: fix mask on conf to allow 4 bits") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Roman Prucha Link: https://patch.msgid.link/20260903-ctxfi-spdif-conf9-fix-v1-1-5e4e3e1f801c@gmail.com Signed-off-by: Takashi Iwai commit 9fe49dbc023e82dfaee7b245997d820d01742a9a Author: Takashi Iwai Date: Thu Sep 3 18:04:39 2026 +0200 ALSA: usb: 6fire: Avoid embedded URBs The USB 6fire driver uses URBs embedded in different structs for PCM, MIDI and communication, and this is basically a buggy implementation nowadays; since a URB is managed with a refcount, this may lead to a UAF when the URB is released asynchronously. For addressing the problem, this patch converts those embedded URBs to ones that are properly allocated via usb_alloc_urb(). The pcm_urb.packets[] is gone, as it's allocated by usb_alloc_urb(), hence it's found in urb.iso_frame_desc[] instead. The conversions are rather straightforward; each embedded struct urb is changed to a pointer, and its callers are updated accordingly. The resource for those structs are released in the common destructor functions (usb6fire_comm_free(), etc), which are called at both the init error path and the disconnect. No functional changes, only compile-tested. Link: https://lore.kernel.org/20260903130757.0668310a.michal.pecio@gmail.com Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260903160458.1938392-4-tiwai@suse.de commit 7a8e247dab54a42aeec0240153c55da286ac5aef Author: Takashi Iwai Date: Thu Sep 3 18:04:38 2026 +0200 ALSA: usb: hiface: Avoid embedded URBs The hiface driver uses URBs embedded in struct pcm_urb, and this is basically a buggy implementation nowadays; since a URB is managed with a refcount, this may lead to a UAF when the URB is released asynchronously. For addressing the problem, this patch converts the embedded URBs to ones that are properly allocated via usb_alloc_urb(). The conversion is rather straightforward; pcm_urb.instance became a pointer, assigned/freed via usb_alloc_urb() and usb_free_urb(), and the call with this is corrected accordingly. Along with it, the resource release is done in the common destructor that is called from both at the error path and the disconnect. No functional changes, only compile-tested. Link: https://lore.kernel.org/20260903130757.0668310a.michal.pecio@gmail.com Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260903160458.1938392-3-tiwai@suse.de commit 07b01b0d8ac4b5f89cbe74e52376221f21db260d Author: Takashi Iwai Date: Thu Sep 3 18:04:37 2026 +0200 ALSA: usb: ua101: Avoid embedded URBs UA101 driver uses URBs embedded in struct ua101, and this is basically a buggy implementation nowadays; since a URB is managed with a refcount, this may lead to a UAF when the URB is released asynchronously. For addressing the problem, this patch converts the embedded URBs to ones that are properly allocated via usb_alloc_urb(). The iso_frame_desc[] is gone, as it's allocated together by usb_alloc_urb(). Along with the dynamic allocation of each URB, the ua101.urbs[] becomes a static array of struct ua101_urb, and struct ua101_urb contains the pointer to struct ua101. Those are needed to handle the ready_list linked list in the complete callback. No functional changes, only compile-tested. Link: https://lore.kernel.org/20260903130757.0668310a.michal.pecio@gmail.com Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260903160458.1938392-2-tiwai@suse.de commit 402a9d6aab7ac787ab075adeb562c3db8b8f564b Author: Edward Adam Davis Date: Thu Sep 3 21:05:21 2026 +0800 ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev The epq_in_urb object belonging to the caiaq device is coupled within the struct snd_usb_caiaqdev. After usb_submit_urb(epq_in_urb, GFP_KERNEL) executes successfully, epq_in_urb is successfully added to the urbp_list queue of the dummy HCD driver (userspace specifies dummy_hcd as the HCD layer driver for the caiaq USB device). When init_card() calls snd_usb_caiaq_send_command() which subsequently fails due to a timeout, and proceeds to call snd_card_free() to release the card, the embedded ep1_in_urb object is also freed. When the dummy HCD driver detects that the URB has been unlinked, it returns the URB (by usb_hcd_giveback_urb()), which triggers [1]. Decouple the ep1_in_urb object from the struct snd_usb_caiaqdev and switch to using a pointer instead. Separately allocate and manage the memory for ep1_in_urb to prevent the release of the snd_card memory object from interfering with it. midi_out_urb has the same issue as ep1_in_urb and is handled in the same way. [1] BUG: KASAN: slab-use-after-free in usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 Write of size 4 at addr ffff88803cee1050 by task ktimers/1/29 Call Trace: usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 dummy_timer+0xaac/0x4d50 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x3eb/0xaf0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1e1/0x2e0 kernel/time/hrtimer.c:2141 Allocated by task 36: snd_card_new+0x7b/0x110 sound/core/init.c:184 create_card sound/usb/caiaq/device.c:429 [inline] snd_probe+0x236/0x1af0 sound/usb/caiaq/device.c:544 Freed by task 36: snd_card_free_when_closed sound/core/init.c:630 [inline] snd_card_free+0x138/0x1d0 sound/core/init.c:662 snd_probe+0x162b/0x1af0 sound/usb/caiaq/device.c:553 Fixes: 523f1dce3743 ("[ALSA] Add Native Instrument usb audio device support") Reported-by: syzbot+832ce9fa3face1b7d44d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=832ce9fa3face1b7d44d Tested-by: syzbot+832ce9fa3face1b7d44d@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Link: https://patch.msgid.link/20260903130521.554840-1-eadavis@sina.com Signed-off-by: Takashi Iwai commit 9a141d3dc869d18b2eab35e999f4790a9b84e40f Author: Carolina Jubran Date: Wed Sep 2 17:06:32 2026 +0300 IB/IPoIB: Avoid restoring OPER_UP after multicast flush ipoib_ib_dev_flush_light() temporarily clears IPOIB_FLAG_OPER_UP to prevent multicast joins while ipoib_mcast_dev_flush() is running, and restores the flag afterwards if it was previously set. This restore races with ipoib_ib_dev_down(). If the interface is brought down while the flush is in progress, ipoib_ib_dev_down() clears IPOIB_FLAG_OPER_UP, but the flush path may set it again after the device has already gone down. Since commit 894021a75291 ("IB/ipoib: Make the carrier_on_task race aware"), ipoib_mcast_carrier_on_task() relies on IPOIB_FLAG_OPER_UP being cleared to terminate its rtnl_trylock() retry loop. If the flag is left set after shutdown, the workqueue retries forever, causing teardown to deadlock when ipoib_ndo_uninit() waits in destroy_workqueue() while holding RTNL. Instead of overloading IPOIB_FLAG_OPER_UP to block multicast joins during a light flush, introduce a dedicated IPOIB_FLAG_MCAST_FLUSH flag. Use it together with IPOIB_FLAG_OPER_UP to determine whether multicast joins are allowed, avoiding the race with device shutdown. Fixes: 344bacca8cd8 ("IB/ipoib: Don't allow MC joins during light MC flush") Reported-by: Ben Davies Signed-off-by: Carolina Jubran Reviewed-by: Cosmin Ratiu Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260902-avoid-rest-oper-up-v1-1-04fcd4916cae@nvidia.com Signed-off-by: Leon Romanovsky commit 662ade4de9ff5eceb0820a9f8e9fac70ba6a815b Author: Quanye Yang Date: Mon Aug 31 20:30:58 2026 +0800 RDMA/ucma: Serialize join and leave on copy_to_user failure rdma_join_multicast() queues RoCE work that later reads the ucma_multicast through event->param.ud.private_data, then list_add()s the CMA multicast at the head of id_priv->mc_list. rdma_leave_multicast() matches only by sockaddr and destroys the first hit. ucma_process_join() used to drop ctx->mutex after a successful join and retake it only if copy_to_user() failed. Two concurrent JOIN_MCAST calls with the same address can therefore insert a second CMA entry before the first thread's leave. leave then cancels the newer work and the older worker still dereferences the ucma_multicast that the first thread frees. Keep ctx->mutex held from rdma_join_multicast() through copy_to_user() and, on -EFAULT, through rdma_leave_multicast() so leave cannot miss this join. Do not leave if join itself failed: that path never published this address on mc_list, and a leave-by-addr would destroy an earlier successful join. Reported-by: syzbot+a6ffe86390c8a6afc818@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a6ffe86390c8a6afc818 Fixes: fe454dc31e84 ("RDMA/ucma: Fix use-after-free bug in ucma_create_uevent") Cc: stable@vger.kernel.org Signed-off-by: Quanye Yang Link: https://patch.msgid.link/20260831-rdma-ucma-mc-uaf-v1-1-b8eeb7046aff@proton.me Signed-off-by: Leon Romanovsky commit fd5348b434c53c34de5a9b3c67a1516309b6a73c Merge: b75a000f2ac15f bde8901ea14244 Author: Eduard Zingerman Date: Sat Sep 5 20:50:13 2026 -0700 Merge branch 'fix-bpf_loop-syzbot-report' Kumar Kartikeya Dwivedi says: ==================== Fix bpf_loop syzbot report Needs Eduard's ack. Fix for the report in https://lore.kernel.org/bpf/6a9ad24c.b5d4176b.238c3e.0001.GAE@google.com. ==================== Link: https://patch.msgid.link/20260905014735.1452988-1-memxor@gmail.com Signed-off-by: Eduard Zingerman commit bde8901ea14244e7195a2d6b6aa2023b28d4233c Author: Kumar Kartikeya Dwivedi Date: Sat Sep 5 03:47:34 2026 +0200 selftests/bpf: Test pointer bpf_loop iteration count rejection Add a verifier test that leaves the raw tracepoint context pointer in R1 when calling bpf_loop(). This is the smallest trigger for the incorrect precision backtracking: it reuses an existing callback and needs no maps or userspace setup. Expect an ordinary scalar-type rejection. Without the verifier fix, the test instead reaches precision backtracking and reports an internal "backtracking misuse" error. Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://patch.msgid.link/20260905014735.1452988-3-memxor@gmail.com Signed-off-by: Eduard Zingerman commit c3fd8e5fd100f122bad503bdc0e9277219533253 Author: Kumar Kartikeya Dwivedi Date: Sat Sep 5 03:47:33 2026 +0200 bpf: Reject non-scalar bpf_loop iteration counts bpf_loop() declares its nr_loops argument as ARG_ANYTHING. Privileged programs may pass pointer values to such arguments, so check_func_arg() lets a pointer-valued R1 reach the helper-specific checks. Since commit bb124da69c47 ("bpf: keep track of max number of bpf_loop callback iterations"), the verifier marks R1 precise and reads its upper bound to limit callback simulation. Precision backtracking only accepts scalar registers, so passing a pointer instead triggers the "backtracking misuse" verifier warning. Kernels with panic_on_warn enabled subsequently panic. Introduce ARG_SCALAR for helper arguments that only accept scalar values and use it for bpf_loop() nr_loops. Generic helper argument validation then rejects pointers before loop inlining and precision processing. Fixes: bb124da69c47 ("bpf: keep track of max number of bpf_loop callback iterations") Reported-by: syzbot+7b47f87674e9a1569110@syzkaller.appspotmail.com Signed-off-by: Kumar Kartikeya Dwivedi Link: https://patch.msgid.link/20260905014735.1452988-2-memxor@gmail.com Closes: https://lore.kernel.org/bpf/6a9ad24c.b5d4176b.238c3e.0001.GAE@google.com/ Signed-off-by: Eduard Zingerman commit 1fc5a74b108fc90951890ec513ac81869f5eaff1 Merge: 9f0346dcbea363 3a2c4d55e32ad6 Author: Linus Torvalds Date: Sat Sep 5 20:45:18 2026 -0700 Merge tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull kmalloc_obj conversions from Kees Cook: "Another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci" * tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: treewide: refresh kmalloc_obj() conversions drm/amd/display: Fix harmless type mismatch in allocation commit c6709d5e14072d0e3d02f291daee46a199e5dad3 Author: Younes Akhouayri Date: Sat Sep 5 17:16:51 2026 +0200 rust: num: seal Integer Bounded relies on Integer implementations to describe primitive integer semantics correctly. In particular, it uses Integer::BITS and Signedness to justify unchecked operations. Integer is currently safe and externally implementable, so an implementation can violate those assumptions and make safe Bounded operations reach undefined behavior. For example, an Integer implementation for a u8 wrapper can report BITS = 16. Safe code can then cast a Bounded containing 256 to that wrapper. Its TryFrom implementation returns Err, and Bounded::cast() calls unwrap_unchecked() on it, causing undefined behavior. Seal Integer so only the primitive implementations provided by the kernel crate can satisfy it. Fixes: 01e345e82ec3 ("rust: num: add Bounded integer wrapping type") Reported-by: Miguel Ojeda Closes: https://lore.kernel.org/rust-for-linux/CANiq72mOfR33s4y+Ueivd5NrC5yre+Pcp57ZOBz0msw9A4AP1Q@mail.gmail.com/ Cc: stable@vger.kernel.org Suggested-by: Miguel Ojeda Signed-off-by: Younes Akhouayri Acked-by: Alexandre Courbot Link: https://patch.msgid.link/20260905-feature-rust-num-seal-integer-v2-1-f1311ffbe6e7@younes.io Signed-off-by: Miguel Ojeda commit 63b4ff622244483e7c530e97d787a3d6c2c38a33 Author: Tejun Heo Date: Sat Sep 5 06:09:58 2026 -1000 sched_ext: scx_qmap: Place only on cids whose caps are in effect qmap decides placements from self_cids, which redistribute() derives from the caps view at ops.sub_caps_updated() time. That view runs ahead of the cpus: a granted cid can be in self_cids before its cpu has reported the caps in effect through ops.sub_ecaps_updated(). ops.update_idle() only comes once BASE is in effect, so the idle-gated placements reach such a cid only through an idle bit left over from an earlier hold. The highpri scan has no gate at all: parent cpu Y, qmap cpu X grants ENQ on X to qmap sub_caps_updated() adds X to self_cids highpri scan moves a task to X with PREEMPT caps not in effect, move denied, task bounced with REENQ_CAP reject drain, enqueue the scan moves it to X again denied again dispatch syncs ecaps, sub_ecaps_updated(X) Every highpri move to X in that window is denied and bounced. The two callbacks are meant to split the roles: ops.sub_caps_updated() tracks what the node holds and drives what it delegates to its children, while ops.sub_ecaps_updated() says whether a task can run on a cpu now. qmap used the first for both. Track the caps in effect from ops.sub_ecaps_updated() as avail_cids and place only on self_cids & avail_cids, so that self_cids stays the delegation split and avail_cids gates the placement. The stranded tests keep self_cids, as they ask whether the split gives the task anywhere at all. A highpri task whose self_cids lack caps in effect waits for them instead of being moved and bounced. Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit a0d356696f87700c8c2934e3881277b0d37f0b71 Author: Tejun Heo Date: Sat Sep 5 06:09:57 2026 -1000 sched_ext: scx_qmap: Do not add IMMED to rescue inserts qmap's stranded fallback forces a task that can run on none of its self cids onto its first allowed cid with SCX_ENQ_RESCUE, and adds SCX_ENQ_IMMED when that cid is a time-share it holds. On such a cid the insert stops being a rescue request: 1. A task is enqueued while none of its allowed cids is in self_cids. At attach self_cids is still empty. 2. qmap inserts it into cid 0's local DSQ with SCX_ENQ_RESCUE | SCX_ENQ_IMMED. 3. The kernel finds ENQ_IMMED held on cid 0, admits the insert and skips the rescue diversion. 4. cid 0's cpu is busy, so the IMMED task is bounced back to qmap with SCX_ENQ_REENQ. 5. qmap's enqueue sees the same inputs and repeats step 2. Nothing runs in between. 6. The reenqueue limit ejects qmap with SCX_EXIT_ERROR_REENQ. The caps granted during the parent's ops.sub_attach() are delivered after the sub already holds its tasks, while the per-cid effective caps that mark the time-shares are delivered from the first dispatch after bypass lifts, so every attach that receives a time-share on a task's first allowed cid starts the loop. Drop IMMED from the rescue inserts so that step 3 diverts to the rescue path. Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit 90f19b2816f5d243a8daf36ca83d9d9d04f00e4c Author: Tejun Heo Date: Sat Sep 5 06:09:56 2026 -1000 sched_ext: Use @prev's scheduler for the keep decisions in dispatch_one() dispatch_one() tests ops flags and bypass state against the root scheduler in both places where it decides to keep running @prev: the early keep of a @prev with slice left tests the root's bypass state, and the keep-last at the end tests the root's SCX_OPS_ENQ_LAST and bypass state. Both are properties of the scheduler @prev belongs to, and put_prev_task_scx(), which acts on the outcome, reads them from that scheduler. When @prev belongs to a sub-scheduler the two sides disagree. The keep-last case is visible. The root set SCX_OPS_ENQ_LAST, so a lone @prev of a sub-scheduler is not kept and is enqueued with SCX_ENQ_LAST to a sub-scheduler that never opted in. This trips the WARN_ON_ONCE in put_prev_task_scx() for the missing flag, and the sub-scheduler queues the task like any other and triggers no follow-up scheduling event, which can lead to stalls. Test SCX_OPS_ENQ_LAST and bypass state on @prev's sched in both places and charge SCX_EV_DISPATCH_KEEP_LAST to it. Read the sched at each decision, as the dispatch in between can drop the rq lock. Fixes: 88234b075c3f ("sched_ext: Introduce scx_task_sched[_rcu]()") Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit 3265ef0b670180b0b946d73ee9825d6d91e98a08 Author: Tejun Heo Date: Sat Sep 5 06:09:55 2026 -1000 sched_ext: Rename sch to root_sch in dispatch_one() dispatch_one() uses the root scheduler for everything it does, including the two decisions to keep running @prev, which are wrong when @prev belongs to a sub-scheduler. The function has to deal with @prev's scheduler too. Rename the root's local from sch to root_sch for clarity and to make room for it. No functional change. Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi commit 38b6be101006d3e7af972999f45d4f1e8250587a Author: Vineeth Karumanchi Date: Wed Sep 2 15:58:36 2026 +0530 net: macb: fix NULL pointer dereference on unbind with fixed-link When the device tree describes a fixed-link and has no "mdio" child node, macb_mii_init() returns early without allocating the MDIO bus, leaving bp->mii_bus as NULL. Two cleanup paths then dereference this NULL bus: 1. On driver unbind, macb_remove() unconditionally calls mdiobus_unregister(bp->mii_bus), which oopses: Unable to handle kernel NULL pointer dereference at virtual address 00000000000004a8 pc : mdiobus_unregister+0x14/0xa4 lr : macb_remove+0x38/0xa4 Call trace: mdiobus_unregister+0x14/0xa4 (P) macb_remove+0x38/0xa4 platform_remove+0x20/0x30 device_release_driver_internal+0x1c8/0x224 unbind_store+0xb4/0xbc 2. On the probe error path in macb_probe(), reached when macb_mii_init() has succeeded but a subsequent step fails, the err_out_unregister_mdio label runs the same unconditional cleanup. mdiobus_unregister() and mdiobus_free() do not guard against a NULL bus, so guard the calls in both macb_remove() and the probe error path. Fixes: d0c3601f2c4e ("net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-link PHY") Signed-off-by: Vineeth Karumanchi Reviewed-by: Xuanqiang Luo Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260902102836.2019355-1-vineeth.karumanchi@amd.com Signed-off-by: Jakub Kicinski commit e7c93ad4bd51d2c38da48dcdd8ce27bfb2c3771b Merge: df99553f840e4c 8f0229bef3cba9 Author: Jakub Kicinski Date: Sat Sep 5 13:47:32 2026 -0700 Merge branch 'net-sched-clamp-quantum-psched_mtu-in-change-paths' Jamal Hadi Salim says: ==================== net/sched: clamp quantum/psched_mtu in change paths This is a followup to commit 709f34f7c28d ("net/sched: fq: add overflow bounds to quantum and initial quantum"). The quantum_backlog_overflow series and the five siblings that followed clamped the init-path quantum in fq, fq_codel, fq_pie, hhf, sfq. The change() paths were not clamped but it is the same pattern, same writer of q->quantum, same privilege level (CAP_NET_ADMIN in a user namespace). A user can override the init clamp via tc qdisc change, restoring the small-quantum deficit spin that the init clamp was meant to prevent. This series also covers two siblings that were missed entirely by the original series: sch_dualpi2 and sch_pie call psched_mtu() without any clamp at all. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Each patch fixes one qdisc with its own Fixes: tag so they can be backported independently - the commits they fix shift differently in the git tree. Patch 1: fq - clamp TCA_FQ_QUANTUM and TCA_FQ_INITIAL_QUANTUM in change Patch 2: fq_pie - clamp quantum in change path Patch 3: sfq - clamp quantum and reject > 1<<20 in change path Patch 4: hhf - clamp quantum in change and init paths Patch 5: dualpi2 - clamp psched_mtu at all 3 call sites Patch 6: pie - clamp psched_mtu in pie_drop_early Patch 7: drr - clamp quantum in change class Patch 8: ets - clamp quantum in parse and fallback paths Patch 9: selftests - update ETS test 41f5 for clamped quanta Conditions to recreate (applies to all): create the qdisc, then tc qdisc change ... quantum 1 with a STAB size table inflating qdisc_pkt_len. Requires CAP_NET_ADMIN in a user namespace (unshare -Urn). ==================== Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com Signed-off-by: Jakub Kicinski commit 8f0229bef3cba996bd40e40aafc512150016b696 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:30 2026 -0400 selftests: tc-testing: update ETS test 41f5 for clamped quanta Commit "net/sched: ets: clamp quantum in parse and fallback paths" moved the quantum floor into ets_quantum_parse(), so every explicitly configured quantum is now clamped to [256, 1 << 20], not just the psched_mtu() fallback. Test 41f5 passes "quanta 4294967294 1 1" and matches the values back verbatim, so all three bands now differ from what it expects: before: bands 3 quanta 4294967294 1 1 after: bands 3 quanta 1048576 256 256 Update the match pattern accordingly. Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.10 Signed-off-by: Jakub Kicinski commit 1c38487f46b243bfeefec0c0c86023a3904f2214 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:29 2026 -0400 net/sched: ets: clamp quantum in parse and fallback paths ets_qdisc_change() falls back to psched_mtu() with no floor for bands without an explicit quantum. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so a zero psched_mtu on a headerless device makes the deficit-refill loop spin under the qdisc lock. Move the floor into ets_quantum_parse() so explicitly configured quanta are also clamped to [256, 1<<20], not just the fallback path. Conditions to recreate the bug: CONFIG_NET_SCH_ETS=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root ets bands 3 strict 2 quanta 1 1 Fixes: dcc68b4d8084 ("net: sch_ets: Add a new Qdisc") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.9 Signed-off-by: Jakub Kicinski commit 8382abec0f1568d0a5590d75a3df92f23fcf5196 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:28 2026 -0400 net/sched: drr: clamp quantum in change class drr_change_class() rejects explicit quantum==0 but falls back to psched_mtu() with no floor. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes the deficit-refill loop spin under the qdisc lock. Add clamp_t(u32, quantum, 256, 1<<20) after the zero reject and on the fallback path. The explicit-zero reject is preserved. Conditions to recreate the bug: CONFIG_NET_SCH_DRR=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root drr tc class add dev dummy0 parent 1: classid 1:1 drr quantum 1 Fixes: 13d2a1d2b032 ("pkt_sched: add DRR scheduler") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.8 Signed-off-by: Jakub Kicinski commit 54370e44c002770ae61fc889f28f699e91616ffc Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:27 2026 -0400 net/sched: pie: clamp psched_mtu in pie_drop_early pie_drop_early() calls psched_mtu() with no clamp. With mtu=0x80000000 the bytemode divide silently zeroes the drop probability, disabling AQM. Clamp to [1, 1<<20]. Conditions to recreate the bug: CONFIG_NET_SCH_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root pie tc qdisc change dev dummy0 root pie stab data 32768 size_log 15 cell_log 0 Fixes: d4b36210c2e6 ("net: pkt_sched: PIE AQM scheme") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.7 Signed-off-by: Jakub Kicinski commit 3c01f1ca5dfc6d6911b0e5b37f5062b1dc451b94 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:26 2026 -0400 net/sched: dualpi2: clamp psched_mtu at all call sites dualpi2_calculate_c_protection(), must_drop(), and get_memory_limit() call psched_mtu() with no clamp. A huge MTU makes (s32)psched_mtu() overflow in the signed multiply for c_protection_init, and 2 * psched_mtu() wraps in get_memory_limit(). With a crafted size table qdisc_pkt_len reaches ~2 GiB, causing a soft lockup / denial of service. Clamp psched_mtu() to [1, 1<<20] at all three call sites. Conditions to recreate the bug: CONFIG_NET_SCH_DUALPI2=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root dualpi2 tc qdisc change dev dummy0 root dualpi2 stab data 32768 size_log 15 cell_log 0 Fixes: 320d031ad6e4 ("sched: Struct definition and parsing of dualpi2 qdisc") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.6 Signed-off-by: Jakub Kicinski commit eb56a495f59baf6cad5ed80e3ffb9078098b1346 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:25 2026 -0400 net/sched: hhf: clamp quantum in change and init paths hhf_change() accepts any quantum from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) in hhf_change() matching fq_codel_change(). Clamp hhf_init() to [256, 1<<20] matching the siblings, and remove the old fallback that only set quantum=256 on overflow. Conditions to recreate the bug: CONFIG_NET_SCH_HHF=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root hhf tc qdisc change dev dummy0 root hhf quantum 1 stab data 32768 size_log 15 cell_log 0 Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.5 Signed-off-by: Jakub Kicinski commit fb9f88a33c516ea5c0bcd9a22ca288b246b34567 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:24 2026 -0400 net/sched: sfq: clamp quantum in change path sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp. Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 size_log 15 cell_log 0 Fixes: e4650d7ae425 ("net_sched: sch_sfq: handle bigger packets") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.4 Signed-off-by: Jakub Kicinski commit 4864f58c53eb47257d55e01f47d4a9f355f7f970 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:23 2026 -0400 net/sched: fq_pie: clamp quantum in change path fq_pie_change() accepts any quantum value from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Conditions to recreate the bug: CONFIG_NET_SCH_FQ_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq_pie tc qdisc change dev dummy0 root fq_pie quantum 1 stab data 32768 size_log 15 cell_log 0 Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.3 Signed-off-by: Jakub Kicinski commit 094cc07f98dfe70a34e2a1923af17fd29b8cf622 Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:22 2026 -0400 net/sched: fq: clamp quantum and initial_quantum in change path The fq change path accepts TCA_FQ_QUANTUM in [1, INT_MAX] and TCA_FQ_INITIAL_QUANTUM up to INT_MAX, while fq_init() already clamps to [1, 1<<20]. A user can override the init clamp via tc qdisc change, restoring the small-quantum deficit spin that the init clamp prevents. Narrow iq_range.max to 1<<20 so TCA_FQ_INITIAL_QUANTUM is rejected at parse time. Clamp TCA_FQ_QUANTUM to [256, 1<<20] in fq_change() and fq_init() quantum to [256, 1<<20] for tiny-MTU devices. Conditions to recreate the bug: CONFIG_NET_SCH_FQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq tc qdisc change dev dummy0 root fq quantum 1 stab data 32768 size_log 15 cell_log 0 Fixes: 709f34f7c28d ("net/sched: fq: add overflow bounds to quantum and initial quantum") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.2 Signed-off-by: Jakub Kicinski commit df99553f840e4c529c1ba4c29bd39396466ca11a Author: Carolina Jubran Date: Wed Sep 2 22:37:31 2026 +0300 net/mlx5e: Keep HW timestamp stats monotonic across reconfiguration `mlx5e_stats_ts_get()` currently selects either DMA or port timestamp counters based on `tx_ptp_opened`. This flag is intentionally kept set once the PTP TX queues have been opened so their statistics remain available after queue teardown. As a result, DMA timestamps are no longer reported after switching from port timestamping back to DMA timestamping. The function also reads statistics only from the currently active channels and TCs. Reducing the number of channels or TCs can therefore drop previously accumulated timestamp counters from the reported value. Read the persistent channel statistics instead and always include DMA timestamp counters. Once the PTP TX queues have been opened, also include the port timestamp counters. This also drops state_lock. It previously protected live channel/PTP pointers, the new code only reads persistent channel_stats and ptp_stats via mlx5e_stats_nch_read(), which is already safe for lockless stats access. Fixes: 3579032c08c1 ("net/mlx5e: Implement ethtool hardware timestamping statistics") Signed-off-by: Carolina Jubran Reviewed-by: Shahar Shitrit Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193731.3668958-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit c0c6f4ba8a37688f7b4d4044898d88f0450d44c2 Author: Lama Kayal Date: Wed Sep 2 22:38:54 2026 +0300 net/mlx5: E-Switch, prevent mc_list repopulation during vport disable In mlx5_esw_vport_disable(), move esw_apply_vport_rx_mode() ahead of esw_vport_change_handle_locked() so vport->allmulti_rule is NULL before the change handler observes it. During FW-fatal recovery the disable runs while dev->state == INTERNAL_ERROR. The promisc query inside esw_update_vport_rx_mode() fails and returns early, leaving vport->allmulti_rule intact, so esw_update_vport_mc_promisc() runs and adds MLX5_ACTION_ADD entries to vport->mc_list whose flow rules are then installed in the FDB by esw_add_mc_addr(). esw_destroy_legacy_table() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flow_rule pointers in vport->mc_list. Two-stage failure on `echo 1 > /sys/bus/pci/devices//reset`: refcount_t: underflow; use-after-free. tree_put_node+0xef/0x110 [mlx5_core] clean_tree+0x44/0xd0 [mlx5_core] (x5) mlx5_fs_core_cleanup+0x57/0x1c0 [mlx5_core] mlx5_unload+0x65/0xd0 [mlx5_core] ... mlx5_health_try_recover BUG: unable to handle page fault for address: 0000000003000055 down_write+0x1c/0x60 mlx5_del_flow_rules+0x33/0x1f0 [mlx5_core] esw_del_mc_addr+0x7b/0x170 [mlx5_core] esw_apply_vport_addr_list+0x56/0xf0 [mlx5_core] esw_vport_change_handle_locked+0x28b/0x310 [mlx5_core] mlx5_esw_vport_enable+0x270/0x4a0 [mlx5_core] ... mlx5_load ... mlx5_health_try_recover esw_apply_vport_rx_mode(false, false) clears vport->allmulti_rule via its local state machine even when the FW del fails. With the rule NULL the !IS_ERR_OR_NULL(allmulti_rule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mc_list. Fixes: 922f56e9a795 ("net/mlx5: Fix steering rules cleanup") Signed-off-by: Lama Kayal Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193854.3669035-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit 7ee07f601f8f507c9faf25c68a49396ab8950596 Author: Yael Chemla Date: Wed Sep 2 22:35:14 2026 +0300 net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put In mlx5_eswitch_termtbl_put(), the zero-ref cleanup check reads tt->ref_count after termtbl_mutex has been released. Two concurrent callers on the same mlx5_termtbl_handle race: one decrements ref_count to zero, removes the hash entry, and calls kfree(tt) while the other has already dropped the mutex and is about to evaluate if (!tt->ref_count), producing a use-after-free. Fix this by capturing the result of the decrement into a stack-local last variable before dropping the mutex. The cleanup decision is now made entirely under termtbl_mutex, and tt is not touched after kfree. Fixes: 10caabdaad5a ("net/mlx5e: Use termination table for VLAN push actions") Signed-off-by: Yael Chemla Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193514.3668880-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit af3aef0245abbab5e9f6302e7a7d6407187afb71 Author: Carolina Jubran Date: Wed Sep 2 22:33:41 2026 +0300 net/mlx5e: Fix use-after-free race in sample_restore_put() Concurrent teardown of TC sample rules sharing the same restore context may re-read restore->count after dropping restore_lock. At that point another thread may already have completed cleanup and freed the restore object. Use the result of the refcount decrement while holding restore_lock to determine whether cleanup is needed. Fixes: 36a3196256bf ("net/mlx5e: TC, Add sampler restore handle API") Signed-off-by: Carolina Jubran Reviewed-by: Shahar Shitrit Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193341.3668809-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit e7ee89740800a1cf253713e9249c3ee9203ebe91 Author: Carolina Jubran Date: Wed Sep 2 22:32:24 2026 +0300 net/mlx5e: Fix ETS zero BW reporting when one TC holds 100% When ETS TCs with zero bandwidth are configured, the driver programs the firmware using an alternate representation. On get, it needs to recognize that representation so those TCs can be translated back and reported as 0% bandwidth. The existing detection relied on the programmed bandwidth because it was enough to identify this representation. However, when a single ETS TC owns 100% of the bandwidth, its firmware representation becomes the same as a strict-priority TC, causing zero-bandwidth ETS TCs to be reported with non-zero bandwidth values. Use the cached TSA instead to distinguish the ETS and strict-priority cases. Fixes: be0f161ef141 ("net/mlx5e: DCBNL, Implement tc with ets type and zero bandwidth") Signed-off-by: Carolina Jubran Reviewed-by: Alex Lazar Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902193224.3668743-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit b3c79dee5038c5e8460c59d7d01cb1450bdf5ecb Author: Akiva Goldberger Date: Wed Sep 2 22:27:40 2026 +0300 net/mlx5: LAG, use local tracker to update active ports The CREATE_LAG command is handled asynchronously by queuing a work, which stores a local copy of ldev->tracker. When the work is processed, it is possible that the values of the local copy and ldev->tracker have diverged. A single CREATE_LAG command programs two related fields into the firmware: the v2p (virtual-to-physical) map, which selects the physical egress port for each hash bucket, and the active_port bitmask, which tells the firmware which physical ports are currently up so it can redirect QP/TIS away from inactive ports. For the firmware to steer traffic correctly, both must be derived from the same view of the ports' link state. The v2p map is computed by mlx5_infer_tx_affinity_mapping() from the local tracker snapshot, but lag_active_port_bits() called mlx5_infer_tx_enabled() on the live ldev->tracker instead. If ldev->tracker changed between the snapshot and command execution, the two fields reflect different port states: the v2p map may steer a bucket to a port that the active_port mask marks as inactive (or vice versa). The firmware then receives a self-contradictory configuration and can redirect or drop traffic on a port the mapping still points at, until a later event happens to reconcile the state. Update lag_active_port_bits so that it receives the local version of the tracker from when the work was queued, effectively closing the window for injecting an inconsistency. Fixes: c5c13b456cb8 ("net/mlx5: Lag, set active ports if support bypass port select flow table") Signed-off-by: Akiva Goldberger Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902192740.3665435-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit 502381cf7310a87275897a5a0a0a2e628179f00e Merge: e6662f2100f8d3 c84ce45a7a3f3f Author: Jakub Kicinski Date: Sat Sep 5 13:14:51 2026 -0700 Merge branch 'net-mlx5e-rs-fec-variant-fixes' Tariq Toukan says: ==================== net/mlx5e: RS FEC variant fixes This series by Shahar fixes three related bugs in the RS FEC handling for mlx5e, all stemming from incomplete coverage of the three RS FEC hardware variants: RS_528_514 (bit 2), RS_544_514_INTERLEAVED_QUAD (bit 4), and RS_544_514 (bit 7). ==================== Link: https://patch.msgid.link/20260902164634.3657606-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit c84ce45a7a3f3f024502c7f53308db9c76e4ae71 Author: Shahar Shitrit Date: Wed Sep 2 19:46:34 2026 +0300 net/mlx5e: Fix reporting support for all RS FEC variants get_fec_supported_advertised() populates the FEC modes reported as supported to userspace. The MLX5E_ADVERTISE_SUPPORTED_FEC macro only checked MLX5E_FEC_RS_528_514, causing devices that support only the other RS variants (RS_544_514_INTERLEAVED_QUAD or RS_544_514) to not advertise RS as supported to ethtool at all. Introduce MLX5E_FEC_RS_MASK covering all three RS bit positions, update the macro to accept a bitmask directly rather than a single enum value, and pass MLX5E_FEC_RS_MASK for the RS entry. Fixes: b5ede32d3329 ("net/mlx5e: Add support for FEC modes based on 50G per lane links") Fixes: 4e343c11efbb ("net/mlx5e: Support FEC settings for 200G per lane link modes") Signed-off-by: Shahar Shitrit Reviewed-by: Dragos Tatulea Reviewed-by: Yael Chemla Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902164634.3657606-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit b9d755c5a37519fb1354034db1dfeb30e1ba6856 Author: Shahar Shitrit Date: Wed Sep 2 19:46:33 2026 +0300 net/mlx5e: Fix setting RS FEC after remapping When a user sets a FEC mode via ethtool, the driver maps the ethtool FEC type to the lowest mlx5 bit of that type. For RS FEC, this is MLX5E_FEC_RS_528_514 (bit 2). The driver then checks whether this bit is supported by at least one link mode by inspecting the fec_override_cap fields via mlx5e_fec_in_caps(), and returns -EOPNOTSUPP if not. This check is incorrect. RS FEC has three supported hardware variants: RS_528_514 (bit 2), RS_544_514_INTERLEAVED_QUAD (bit 4), and RS_544_514 (bit 7). mlx5e_remap_fec_conf_mode() already remaps bit 2 to the appropriate RS variant per link mode when writing the admin fields, but the early capability check is done against the raw unmapped bit. As a result, a device that supports RS_544_514 or RS_544_514_INTERLEAVED_QUAD but not RS_528_514 will incorrectly reject the user's RS FEC request. Remove the early support check from mlx5e_set_fec_mode() and fold it into the existing write loop, checking caps against the remapped policy per link mode. Return -EOPNOTSUPP before the final register write if no link mode accepted the policy. Fixes: 2608a2f831c4 ("net/mlx5e: Fix return status when setting unsupported FEC mode") Signed-off-by: Shahar Shitrit Reviewed-by: Dragos Tatulea Reviewed-by: Yael Chemla Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902164634.3657606-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit 802eedcc0b25bb3e1b492f0600ab74325274d53b Author: Shahar Shitrit Date: Wed Sep 2 19:46:32 2026 +0300 net/mlx5e: Fix missing FEC mode mapping for RS_544_514_INTERLEAVED_QUAD MLX5E_FEC_RS_544_514_INTERLEAVED_QUAD is missing from pplm_fec_2_ethtool_linkmodes[], leaving index 4 zero-initialized. As a result, when this FEC mode is active, find_first_bit() returns index 4, causing __set_bit() to set bit 0 (ETHTOOL_LINK_MODE_10baseT_Half_BIT) instead of ETHTOOL_LINK_MODE_FEC_RS_BIT. Consequently, ethtool reports: Advertised FEC modes: Not reported Add the missing mapping to ETHTOOL_LINK_MODE_FEC_RS_BIT. Fixes: 4e343c11efbb ("net/mlx5e: Support FEC settings for 200G per lane link modes") Signed-off-by: Shahar Shitrit Reviewed-by: Dragos Tatulea Reviewed-by: Yael Chemla Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260902164634.3657606-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit e6662f2100f8d33b0f4d0047c219efd6bba186ea Author: Weiming Shi Date: Wed Sep 2 23:52:31 2026 +0800 net/sched: defer qdisc freeing after failed creation An RTM_NEWQDISC request can make clsact bind a populated shared ingress block during ->init(), publishing an embedded mini_Qdisc to lockless readers. If the same request has an invalid TCA_RATE, estimator setup fails after ->init(); the unwind removes the pointer but synchronously frees its containing qdisc while tc_run() may still hold it. Retire failed qdiscs through the same RCU helper as normal destruction. Inline the synchronous free into the callback now that no direct callers remain. Fixes: 51ab2994c387 ("net: sched: allow ingress and clsact qdiscs to share filter blocks") Reported-by: Xiang Mei Link: https://lore.kernel.org/netdev/20260805102505.740806-1-david.lee@trailofbits.com/ Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260902155231.2149915-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski commit 9f0346dcbea363787186c94ef94dd01aaa215afa Merge: 214f4aeb2255f2 f6d752278c1383 Author: Linus Torvalds Date: Sat Sep 5 11:59:05 2026 -0700 Merge tag 'driver-core-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core fixes from Danilo Krummrich: - Fix kernfs listxattr() not returning security xattr names (e.g. SELinux labels) when the kernfs node has no allocated kernfs_iattrs - Fix silent truncation of IRQ vector indices in the Rust PCI abstractions - Don't select OF from DRIVER_PE_KUNIT_TEST; skip the test when OF is disabled instead of silently enabling extra kernel functionality - Russ Weight is retiring from kernel development; update the Firmware Loader sysfs contact to the driver-core mailing list, add a CREDITS entry for Firmware Upload, and update MAINTAINERS accordingly * tag 'driver-core-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: MAINTAINERS: Remove Russ Weight from Firmware Loader CREDITS: Add CREDITS entry for Firmware Upload firmware_loader: Change contact for sysfs nodes rust: pci: reject IRQ vector indices that do not fit in u32 kernfs: preserve security xattrs without allocating iattrs drivers: base: test: DRIVER_PE_KUNIT_TEST should not select OF commit e14a3454806468b086fe2e4ca2e1bff95b528531 Author: Shakeel Butt Date: Tue Sep 1 11:01:09 2026 -0700 mm/mlock: use the IRQ-safe accessor for NR_MLOCK in __munlock_folio() NR_MLOCK is updated from interrupt context. __free_pages_prepare() clears a stray PG_mlocked and adjusts NR_MLOCK, and a folio can reach it with the flag still set from a bio completion handler: __free_pages_ok+0x6af/0x7a0 __bio_release_pages+0xde/0x260 __iomap_dio_bio_end_io+0x16e/0x1a0 blk_update_request+0x14b/0x3d0 blk_mq_end_request+0x18/0x30 blk_done_softirq+0x49/0x60 The folio gets there like this. A MAP_SHARED file mapping is mlocked, so its page cache folios carry PG_mlocked, and an O_DIRECT write sourced from that mapping GUP-pins those same folios. munlock() then runs mlock_vma_pages_range(), which clears VM_LOCKED before walking the page tables to munlock each folio. A concurrent hole punch reaches the folio through the rmap (i_mmap_rwsem, not mmap_lock) and can land inside that window: __folio_remove_rmap() -> munlock_vma_folio() sees VM_LOCKED already clear, so it neither queues the folio on the mlock batch nor takes a reference, and the pte it clears makes the pending mlock_pte_range() walk skip the folio at its !pte_present() check. filemap_remove_folio() then drops the page cache reference, leaving the bio's pin as the last one, released from the completion handler above. So __zone_stat_mod_folio() here needs interrupts disabled, not merely preemption, and __munlock_folio() has a path where they are not: when the folio has already been taken off the LRU by somebody else the function jumps straight to the counter update without taking the lruvec lock. The read-modify-write of the per-CPU NR_MLOCK diff can then be interrupted by the softirq above, and one of the two decrements is lost, leaving Mlocked in /proc/meminfo permanently overstated. Use zone_stat_mod_folio(). mod_zone_state()'s this_cpu_try_cmpxchg() is atomic against a same-CPU interrupt and retries, and on the path where the lruvec lock is held its cost is negligible next to the lock itself. The UNEVICTABLE_PG* events are deliberately left on the __ accessors: they occupy different vm_event_states slots from the UNEVICTABLE_PGCLEARED that __free_pages_prepare() bumps, and nothing updates those two from interrupt context. Link: https://lore.kernel.org/20260901180109.3797944-1-shakeel.butt@linux.dev Fixes: 2fbb0c10d1e8 ("mm/munlock: mlock_page() munlock_page() batch by pagevec") Signed-off-by: Shakeel Butt Reported-by: syzbot+cd2073ee6d958a8d0fcd@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-mm/6a931c5a.08e933ee.dbf97.0093.GAE@google.com/ Acked-by: Hugh Dickins Cc: Jann Horn Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Pedro Falcato Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton commit 0791a234b35d4b72187c497e05817f2c9019c3ab Author: Andrew Morton Date: Tue Sep 1 13:09:29 2026 -0700 remove old lib/alloc_tag.c This was moved into mm/, but the original lib/ file somehow remained. Remove it. Reported-by: Suren Baghdasaryan Cc: Lorenzo Stoakes Signed-off-by: Andrew Morton commit 8e2b8614039853e68d5338e37821e8bcee9fc05f Author: Seunguk Shin Date: Mon Aug 3 13:34:55 2026 +0100 fs/dax: check zero or empty entry before converting xarray entry Calling dax_to_folio() with empty entry causes kernel panic below when booting a VM with DAX enabled storage. This patch checks empty entry before calling dax_to_folio() on dax_associate_entry(), dax_disassociate_entry(), and dax_busy_page(). Commit 98c183a4fccf ("fs/dax: don't disassociate zero page entries") added guards in the associate and disassociate paths, but the guards still come after dax_to_folio(), and dax_busy_page() still has the same problem. [ 0.737679] EXT4-fs (pmem0p1): mounted filesystem 79676804-7c8b-491a-b2a6-9bae3c72af70 ro with ordered data mode. Quota mode: disabled. [ 0.737891] VFS: Mounted root (ext4 filesystem) readonly on device 259:1. [ 0.739119] devtmpfs: mounted [ 0.739476] Freeing unused kernel memory: 1920K [ 0.740156] Run /sbin/init as init process [ 0.740229] with arguments: [ 0.740286] /sbin/init [ 0.740321] with environment: [ 0.740369] HOME=/ [ 0.740400] TERM=linux [ 0.743162] Unable to handle kernel paging request at virtual address fffffdffbf000008 [ 0.743285] Mem abort info: [ 0.743316] ESR = 0x0000000096000006 [ 0.743371] EC = 0x25: DABT (current EL), IL = 32 bits [ 0.743444] SET = 0, FnV = 0 [ 0.743489] EA = 0, S1PTW = 0 [ 0.743545] FSC = 0x06: level 2 translation fault [ 0.743610] Data abort info: [ 0.743656] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 0.743720] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 0.743785] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 0.743848] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000b9d17000 [ 0.743931] [fffffdffbf000008] pgd=10000000bfa3d403, p4d=10000000bfa3d403, pud=1000000040bfe403, pmd=0000000000000000 [ 0.744070] Internal error: Oops: 0000000096000006 [#1] SMP [ 0.748888] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 6.18.4 #1 NONE [ 0.749421] pstate: 004000c5 (nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.749969] pc : dax_disassociate_entry.constprop.0+0x20/0x50 [ 0.750444] lr : dax_insert_entry+0xcc/0x408 [ 0.750802] sp : ffff80008000b9e0 [ 0.751083] x29: ffff80008000b9e0 x28: 0000000000000000 x27: 0000000000000000 [ 0.751682] x26: 0000000001963d01 x25: ffff0000004f7d90 x24: 0000000000000000 [ 0.752264] x23: 0000000000000000 x22: ffff80008000bcc8 x21: 0000000000000011 [ 0.752836] x20: ffff80008000ba90 x19: 0000000001963d01 x18: 0000000000000000 [ 0.753407] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 0.753970] x14: ffffbf3154b9ae70 x13: 0000000000000000 x12: ffffbf3154b9ae70 [ 0.754548] x11: ffffffffffffffff x10: 0000000000000000 x9 : 0000000000000000 [ 0.755122] x8 : 000000000000000d x7 : 000000000000001f x6 : 0000000000000000 [ 0.755707] x5 : 0000000000000000 x4 : 0000000000000000 x3 : fffffdffc0000000 [ 0.756287] x2 : 0000000000000008 x1 : 0000000040000000 x0 : fffffdffbf000000 [ 0.756871] Call trace: [ 0.757107] dax_disassociate_entry.constprop.0+0x20/0x50 (P) [ 0.757592] dax_iomap_pte_fault+0x4fc/0x808 [ 0.757951] dax_iomap_fault+0x28/0x30 [ 0.758258] ext4_dax_huge_fault+0x80/0x2dc [ 0.758594] ext4_dax_fault+0x10/0x3c [ 0.758892] __do_fault+0x38/0x12c [ 0.759175] __handle_mm_fault+0x530/0xcf0 [ 0.759518] handle_mm_fault+0xe4/0x230 [ 0.759833] do_page_fault+0x17c/0x4dc [ 0.760144] do_translation_fault+0x30/0x38 [ 0.760483] do_mem_abort+0x40/0x8c [ 0.760771] el0_ia+0x4c/0x170 [ 0.761032] el0t_64_sync_handler+0xd8/0xdc [ 0.761371] el0t_64_sync+0x168/0x16c [ 0.761677] Code: f9453021 f2dfbfe3 cb813080 8b001860 (f9400401) [ 0.762168] ---[ end trace 0000000000000000 ]--- [ 0.762550] note: init[1] exited with irqs disabled [ 0.762631] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Link: https://lore.kernel.org/m2y0enxtzk.fsf@arm.com Fixes: 38607c62b34b ("fs/dax: properly refcount fs dax pages") Signed-off-by: Seunguk Shin Reviewed-by: Jan Kara Reviewed-by: Alistair Popple Reported-by: Kiara Grouwstra Cc: Al Viro Cc: Christian Brauner Cc: Matthew Wilcox (Oracle) Cc: Signed-off-by: Andrew Morton commit 641aade99f06df0037e52b5c81645461b7132947 Author: Qi Zheng Date: Mon Aug 17 17:03:25 2026 +0800 fs: fix missed removal of super_fs_objects_eligible() Commit 0ef8faff490be ("fs: push nr_cached_objects memcg gating into individual filesystems") was meant to drop the blanket memcg gate in fs/super.c and let each ->nr_cached_objects() implementation decide for itself whether it is meaningful in per-memcg reclaim. However, when that patch was applied the removal of super_fs_objects_eligible() and its two call sites in super_cache_scan() / super_cache_count() was lost, so the helper is still gating every ->nr_cached_objects() hook and 0ef8faff490be is effectively a no-op. Consequences of the leftover gate: - XFS's inode-reclaim hook, which is intentionally driven from per-memcg contexts to free memcg-charged slab, is still short-circuited in fs/super.c exactly the regression from commit 0baad6f9b997 ("fs/super: skip non-memcg-aware nr_cached_objects in memcg slab shrink") that 0ef8faff490be was written to undo. Memcg-charged XFS inode slab therefore keeps piling up under per-memcg pressure until global reclaim kicks in. - Any future ->nr_cached_objects()/->free_cached_objects() that grows memcg awareness is likewise blocked before it can run, so filesystems cannot opt in to per-memcg reclaim on their own defeating the whole point of pushing the gating decision down into the callbacks. Drop the leftover helper and its call sites so the intent of 0ef8faff490be actually takes effect. Link: https://lore.kernel.org/cover.1786955972.git.zhengqi.arch@bytedance.com Link: https://lore.kernel.org/3b038d373c70ebac7cdabfb0035bb91d1d6e6cfe.1786955972.git.zhengqi.arch@bytedance.com Link: https://lore.kernel.org/all/20260715103516.2410175-1-usama.arif@linux.dev/ [0] Fixes: 0ef8faff490b ("fs: push nr_cached_objects memcg gating into individual filesystems") Signed-off-by: Qi Zheng Acked-by: Usama Arif Cc: Baolin Wang Cc: Christian Brauner Cc: David Hildenbrand Cc: Hugh Dickins Cc: Johannes Weiner Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton commit 848d2ce2fce15fbdc083fbf9691bfa72911033c4 Author: Wenjie Qi Date: Sun Aug 30 01:36:12 2026 +0800 mm: filemap: retain mapped dropbehind folios Fault-around can map ready dropbehind folios without going through the normal page-cache lookup that clears dropbehind. A mapping represents a competing cached user, so retain the folio instead of forcibly unmapping it when writeback completes. For a mapped folio, folio_unmap_invalidate() can call unmap_mapping_folio(), which takes i_mmap_rwsem and may sleep. Retaining mapped folios avoids this path when folio_end_dropbehind() runs in non-preemptible task context. Tal was able to trigger a sleeping-in-atomic warning due to this [1]. Unmapped dropbehind folios continue through the existing invalidation path. Link: https://lore.kernel.org/4aba05e1a2c3b61cb337d373eb9b7a8db4ddd822.1788024049.git.qiwenjie@xiaomi.com Link: https://lore.kernel.org/076bb01b-6fcf-4691-be8c-0e8507c9fe64@columbia.edu [1] Fixes: fb7d3bc41493 ("mm/filemap: drop streaming/uncached pages when writeback completes") Signed-off-by: Wenjie Qi Reviewed-by: Matthew Wilcox (Oracle) Reviewed-by: Tal Zussman Tested-by: Tal Zussman Cc: Barry Song Cc: Jan Kara Cc: Jens Axboe Cc: Trond Myklebust Cc: Signed-off-by: Andrew Morton commit e1d469a8d6c63032a5aed3679a13a086b61bd5cc Author: Christopher Obbard Date: Sat Aug 29 12:28:23 2026 +0100 mailmap: update entry for Christopher Obbard I have changed employer; update my mailmap entry to point at my new email address. Link: https://lore.kernel.org/20260829-update-mail-oss-qualcomm-v2-1-1670c515f225@oss.qualcomm.com Signed-off-by: Christopher Obbard Signed-off-by: Andrew Morton commit 6e673d0879ef78c395cfe0d3ba316690a60055d8 Author: Shakeel Butt Date: Fri Aug 28 19:32:51 2026 -0700 memcg: avoid charging the root memcg from obj_cgroup_charge_pages() obj_cgroup_charge_pages() resolves the objcg to its memcg and calls try_charge_memcg(), which does not short circuit the root memcg. That memcg can be the root memcg: obj_cgroup_is_root() reflects the memcg the objcg was created for and is never updated, while memcg_reparent_objcgs() does redirect objcg->memcg to the parent on rmdir. An objcg of a dying child of root therefore passes every obj_cgroup_is_root() filter but resolves to the root memcg. Folios keep the objcg they were charged with, so this is easy to reach through zswap: allocate anon memory in a cgroup, move the task out, remove the cgroup, then write to the root cgroup's memory.reclaim. The reclaimed folios are charged through the reparented objcg and end up in refill_stock() with the root memcg: WARNING: mm/memcontrol.c:2198 at refill_stock+0x644/0x940 refill_stock+0x644/0x940 try_charge_memcg+0x12d6/0x1570 __obj_cgroup_charge+0x35/0xf0 obj_cgroup_charge+0x1de/0x210 obj_cgroup_charge_zswap+0x83/0x270 zswap_store+0x1620/0x2000 swap_writeout+0x94c/0x14c0 shrink_folio_list+0x3388/0x52b0 [...] try_to_free_mem_cgroup_pages+0x30d/0x830 user_proactive_reclaim+0x504/0x840 memory_reclaim+0x1f/0x30 Beyond the warning, the charge is asymmetric: obj_cgroup_uncharge_pages() skips refill_stock() for the root memcg, so the root's page counter grows and is never uncharged. It is not user visible, since memory.current is not exposed on the root, but it is a leak. Use try_charge(), which returns early for the root memcg, restoring the symmetry with obj_cgroup_uncharge_pages(). The above sequence was scripted into a standalone reproducer (zswap on, swap on a virtio disk, 512MB of anon memory faulted in inside a child of the root cgroup, the task then migrated to the root cgroup, the child removed, followed by "echo 600M swappiness=max > memory.reclaim" on the root) and run in a CONFIG_DEBUG_VM=y VM. It reproduces the splat on the first zswap store of a reparented folio, with the same call chain as the report. With this patch applied the splat is gone while the zswap store count over the run is unchanged, so the same path is still exercised. cgroup selftests test_zswap, test_kmem and test_memcontrol show no new failures. Link: https://lore.kernel.org/20260829023251.474083-1-shakeel.butt@linux.dev Fixes: 20d6c1725228 ("memcg: avoid refill_stock for root memcg") Signed-off-by: Shakeel Butt Reported-by: Farhad Alemi Closes: https://lore.kernel.org/all/CA+0ovCgWzUMK+nNbbtH7eV65Ca=fDN4Ozu7iASgryjvv8Tk8zQ@mail.gmail.com/ Reviewed-by: Muchun Song Reviewed-by: Johannes Weiner Cc: Michal Hocko Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton commit 12e9ac7bc5b254048f886bf421e3a15491106c1f Author: Nhat Pham Date: Fri Aug 28 12:14:33 2026 -0700 mm, swap: fix SWAP_USAGE_OFFLIST_BIT collision with real usage count SWAP_USAGE_OFFLIST_BIT is embedded in the si->inuse_pages usage counter, and is meant to sit above any value that counter can reach. However, it is defined from BITS_PER_TYPE(atomic_t), so it is bit 30. On a system with 4 KiB pages the flag collides with the usage count once that count reaches 4 TiB. swap_usage_in_pages() masks bit 30 out, so whenever the real count has that bit set, every caller of it reads 4 TiB low: * /proc/swaps understates Used by 4 TiB. * A raw count of exactly 2^30 masks to zero, so try_to_unuse() takes its "if (!swap_usage_in_pages(si)) goto success;" early exit and swapoff tears the device down while pages are still swapped out. Nothing in the rest of swapoff aborts the teardown, so those pages are lost. Independently of swapoff, the collision also corrupts the counter and the plist. On a device in normal use, a free that leaves bit 30 set in the count makes swap_usage_sub() see the flag where there is only count, and call add_to_avail_list(). It clears the bit with fetch_and(~SWAP_USAGE_OFFLIST_BIT), leaving the stored count 4 TiB below the real one, and calls plist_add() on a device that is already listed, tripping the WARN_ON(!plist_node_empty(node)) in plist_add() and linking the node a second time. Change the definition of SWAP_USAGE_OFFLIST_BIT to be based on atomic_long_t instead. Note that the usage counter field itself is of this same type, so it is still a valid bit. Link: https://lore.kernel.org/20260828191433.3304458-1-nphamcs@gmail.com Fixes: b228386cf237 ("mm, swap: clean up plist removal and adding") Signed-off-by: Nhat Pham Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260825153238.2695446-1-nphamcs%40gmail.com Suggested-by: Andrew Morton Reviewed-by: Andrew Morton Acked-by: Kairui Song Cc: Baoquan He Cc: Barry Song Cc: Chris Li Cc: Gregory Price Cc: Johannes Weiner Cc: Joshua Hahn Cc: Kemeng Shi Cc: Shakeel Butt Cc: Youngjun Park Cc: Signed-off-by: Andrew Morton commit e1d56f046507befa20a5e0837d8075abdf5848fd Author: Coiby Xu Date: Fri Aug 28 16:41:06 2026 +0800 mailmap: map Coiby Xu's address Point to my gmail address as I've left Red Hat. Link: https://lore.kernel.org/20260828084106.1494733-1-coiby.xu@gmail.com Signed-off-by: Coiby Xu Signed-off-by: Andrew Morton commit 397432cab17bccb600fd6c16ed593f1149042268 Author: Lorenzo Stoakes (ARM) Date: Fri Aug 28 12:20:37 2026 +0100 mm/mremap: account mm->locked_vm correctly for MREMAP_DONTUNMAP When a VMA is mremap()'d with MREMAP_DONTUNMAP set, that results in the VMA being copied, but the source VMA not being unmapped. If the VMA is mlock()'d this is a legal operation, though the source VMA has its VMA_LOCKED_BIT cleared. However this is done in dontunmap_complete(), after mm->locked_vm was incremented via vrm_stat_account(), resulting in double-counting. Worse, this is not even corrected when source VMA is unmapped, due to the VMA_LOCKED_BIT flag having been cleared. This all works fine in the usual mremap() case (without MREMAP_DONTUNMAP), as the source VMA is unmapped with VMA_LOCKED_BIT intact, at which time mm->locked_vm is decremented accordingly. Resolve the issue by invoking vrm_stat_account() only after dontunmap_complete() has run. Note that MREMAP_DONTUNMAP requires old_len == new_len, so no need to account for a delta in size in this case. The bug was introduced by commit b714ccb02a76 ("mm/mremap: complete refactor of move_vma()") which incorrectly reordered the accounting and the clearing of the VMA_LOCKED_BIT flag. Link: https://lore.kernel.org/20260828-mremap-fix-locked-vm-v1-1-c80be7505d1e@kernel.org Fixes: b714ccb02a76 ("mm/mremap: complete refactor of move_vma()") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260825-fix-mremap-dontunmap-pgoff-v1-1-39a40b2c98b3@kernel.org Reported-by: Kunwu Chan Closes: https://lore.kernel.org/all/20260828094823.594279-1-kunwu.chan@linux.dev/ Acked-by: Vlastimil Babka (SUSE) Tested-by: Kunwu Chan Reviewed-by: Kunwu Chan Cc: Jann Horn Cc: Liam R. Howlett Cc: Pedro Falcato Cc: Signed-off-by: Andrew Morton commit e384abeb559d10d6505aec053ede9368d81d4c71 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 27 20:55:57 2026 +0100 mm/huge_memory: bypass THP tuneables for huge pfnmap mappings The sysfs THP tuneables at /sys/kernel/mm/transparent_huge_pages/ rather confusingly only control the behaviour of THP in some instances. They are not applicable to MADV_COLLAPSE operations, nor to DAX mappings. Long-term, THP is predicated upon compaction being able to obtain large folios to populate THP ranges. However, vm_normal_folio() returns NULL for PFN map mappings, thus their reference count is maintained by the driver, not core mm. As a consequence, the folios are not subject to reclaim nor compaction, so are not truly part of the THP mechanism at all. However, since commit 5dd40721f147 ("mm: allow THP orders for PFNMAPs") introduced the ability to establish huge PFN maps, they have been subject to THP tuneables. This is incorrect - if a huge PFN map is available (defined by vma->vm_ops->huge_fault being non-NULL for a VMA_PFNMAP_BIT VMA), then it should be mapped huge upon fault-in. Correct this by explicitly checking for this while ensuring that smaps continues to accurately report THPeligible statistics. While here, abstract the entire file-backed THP check in vma_can_map_huge_file(), with sensible separation of logic into helper functions. Note that drm_gem_shmem_mmap() and panthor_gem_mmap() establish huge PFN maps of shmem folios, however they are marked unevictable in drm_gem_get_pages(), and in any case would fail the reference check in __remove_mapping() even if they weren't. Failing to map huge PFN maps has resulted in significant real-world performance degradation, see links for details. [ziy@nvidia.com: rename some functions] Link: https://lore.kernel.org/DL1HIHWYJ7TB.1CY76SJS0V03L@nvidia.com Link: https://lore.kernel.org/20260827-hugepfn-allowable-orders-v1-1-94819c8807c8@kernel.org Fixes: 5dd40721f147 ("mm: allow THP orders for PFNMAPs") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Zi Yan Reported-by: Cedric Le Goater Closes: https://lore.kernel.org/linux-mm/20260805055544.1568534-1-clg@redhat.com/ Reported-by: Saravanan D Closes: https://lore.kernel.org/linux-mm/20260821070520.25759-1-saravanand@crusoe.ai/ Reviewed-by: Zi Yan Tested-by: Saravanan D Tested-by: Lance Yang Reviewed-by: SJ Park Reviewed-by: Baolin Wang Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Jason Gunthorpe Cc: Liam R. Howlett Cc: Peter Xu Cc: Ryan Roberts Cc: Signed-off-by: Andrew Morton commit 214f4aeb2255f2f9b5f5de1a15f650a429c43490 Merge: d9d80a859bc45c a2628ce4ddb687 Author: Linus Torvalds Date: Sat Sep 5 10:45:51 2026 -0700 Merge tag 'loongarch-fixes-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch fixes from Huacai Chen: - Fix build errors when RUST and KASAN enabled - fix a typo in comment of vmlinux.lds.S - fix several bugs in Kprobes, BPF JIT and KVM support * tag 'loongarch-fixes-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: perf build: Add clang and rust target flags for LoongArch LoongArch: KVM: Fix TOCTOU race on pv_features LoongArch: KVM: Validate MSI data before routing it to EIOINTC LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY LoongArch: KVM: Remove unused function kvm_arch_flush_remote_tlbs_memslot() LoongArch: KVM: Fix resource leak in kvm_loongarch_env_init() error path LoongArch: KVM: Add unregister helpers for the KVM interrupt devices LoongArch: KVM: Free init resources if kvm_init() fails LoongArch: BPF: Fix off-by-one error for insn_is_cast_user() LoongArch: Avoid preempt count underflow without probe LoongArch: Do not save/restore percpu base register in rethook trampoline LoongArch: Remove unused setup_profiling_timer() function LoongArch: Fix typo "avaliable" in comment of vmlinux.lds.S LoongArch: Do not select HAVE_RUST when KASAN is enabled commit b144dc5a24149ba9a0cb2197001973a74b8c93b2 Author: Breno Leitao Date: Mon Aug 10 09:40:00 2026 -0700 virtio_console: allocate the port_buffer with the caller's gfp put_chars() runs from the hvc console write path with preemption disabled, so it asks alloc_buf() for GFP_ATOMIC. Only the data buffer gets it: the struct port_buffer itself keeps the GFP_KERNEL default, so the allocation can enter direct reclaim and sleep. A write to /dev/kmsg on a CONFIG_DEBUG_ATOMIC_SLEEP kernel splats: BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:320 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: virtme-ng-init preempt_count: 1, expected: 0 Preemption disabled at: [] vprintk_emit+0x17d/0x510 Call Trace: dump_stack_lvl+0x69/0xa0 __might_resched+0x37a/0x4d0 __kmalloc_cache_noprof+0x94/0x5f0 put_chars+0x209/0x3e0 hvc_console_print+0x234/0x640 console_flush_all+0x4fc/0x950 console_unlock+0xbf/0x1b0 vprintk_emit+0x312/0x510 devkmsg_emit+0xba/0x110 devkmsg_write+0x21b/0x2e0 vfs_write+0x4dc/0x9d0 ksys_write+0x108/0x1e0 do_syscall_64+0xfa/0x460 Pass gfp on to that allocation too. Fixes: fc220d6be3c7 ("virtio_console: refactor __send_to_port() buffer ownership") Signed-off-by: Breno Leitao Acked-by: Sungho Bae Tested-by: Florian Westphal Link: https://patch.msgid.link/20260810-serial-v1-1-abbe51602c13@debian.org Signed-off-by: Greg Kroah-Hartman commit d9d80a859bc45ca022abc13afdd11d1c812a1034 Merge: 0d9ff90a5422cc 6a7a45b1d94799 Author: Linus Torvalds Date: Sat Sep 5 10:18:21 2026 -0700 Merge tag 'for-7.3-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - preserve inode compression level when changing attributes - fix lost wakeup when waiting for a zstd workspace - fix bio context leaks after ordered extent processing errors - in send, handle unexpected extents for non-regular inodes - handle edge case in creation of reloc tree with enabled quotas - in scrub report the exact failing offset, not the stripe base - error handling fixes - error code propagation in send, zoned mode and raid-stripe-tree - restore active device pointer after seeding device addition error - transaction abort fixups - update Chris' email address * tag 'for-7.3-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: MAINTAINERS: update Chris Mason's email address btrfs: tests: do not touch page cache if root/inode allocation failed btrfs: zstd: fix lost wakeup when waiting for a workspace btrfs: do not force reloc root creation during qgroup_account_snapshot() btrfs: send: fix lost error return value in will_overwrite_ref() btrfs: abort transaction before releasing tree_log_mutex on commit failure btrfs: zoned: propagate do_zone_finish() error in btrfs_zone_finish_endio() btrfs: zoned: finish active block group cleanup if call_zone_finish() fails btrfs: send: reject extents for non-regular inodes btrfs: return proper negative error code for update_raid_extent_item() btrfs: fix the possible bioc_list memory leak during error btrfs: fix transaction use-after-free in raid stripe insertion btrfs: scrub: report the failing sector's address, not the stripe base btrfs: preserve the compression property when other inode flags change btrfs: restore active device pointers after failed sprout btrfs: detach failed sprout device from transaction update list btrfs: clean up target device if block group marking fails commit 5520e89a5a4f834bced64cf2ac927001cc513a40 Author: Fan Wu Date: Fri Sep 4 13:48:11 2026 +0000 smb: client: fix cifsFileInfo reference leak in deferred close When cifs_close() defers a close, it hands the cifsFileInfo reference of the closing struct file to the queued work. Each execution of smb2_deferred_work_close() drops one such reference. deferred_close_scheduled can be false while the work is pending: the workqueue clears PENDING when the callback starts to run, before the callback clears the flag under deferred_lock. A close in that interval requeues the running work, and the callback then clears the flag, leaving the requeued work pending with the flag down. A later cifs_open() can reuse the handle and its cifs_close() reaches the same branch: queue_delayed_work() fails because the work is still pending, but cifs_close() returns without dropping the closing file's reference. The cifsFileInfo count stays pinned and its tlink, dentry and server handle are leaked. Check the return value and hand off the reference only when work was actually queued. Otherwise, use the shared _cifsFileInfo_put(), like the mod_delayed_work() branch above: the pending execution already owns its reference. This issue was found by an in-house static analysis tool. Fixes: c3f207ab29f7 ("cifs: Deferred close for files") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Signed-off-by: Paulo Alcantara commit 23b26f4408ac3f35a482d2e5cf6fc865d4201b71 Author: Bjoern Doebel Date: Fri Sep 4 10:42:36 2026 +0000 smb: client: avoid leaking refcount when cifs_sb_tlink() fails cifs_oplock_break() takes over the reference that cifs_queue_oplock_break() acquired when it queued the work, and drops it with _cifsFileInfo_put() once the break has been processed. Only in setups with "-o multiuser", cifs_sb_tlink() may fail, at which point cifs_oplock_break() returns without putting the file reference, mirroring the reference leak we already fixed in the companion patch to cifs_queue_oplock_break(). This would trigger a crash due to busy inodes on the next unmount: BUG: Dentry ... still in use (1) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) Drop the reference on that path as well. Doing so before the out label mirrors the normal path, which also puts the reference before cifs_done_oplock_break(). Found by Sashiko code review. The failure path was not exercised at runtime. Fixes: e8f5f849ffce2 ("cifs: fix potential oops in cifs_oplock_break") Cc: stable@vger.kernel.org Assisted-by: Kiro:claude-opus-5 Signed-off-by: Bjoern Doebel Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 9f2e63f1b2d5fc5b5423424902c091123e220e7e Author: Bjoern Doebel Date: Thu Sep 3 21:28:58 2026 +0000 smb: client: avoid leaking refcount in cifs_queue_oplock_break() cifs_queue_oplock_break() unconditionally takes a reference on the target file before queueing cifs_oplock_break(). Only that work item decreases the reference counter again. If another oplock break arrives while that work is still queued, queue_work() will return false and not queue this second work item. As a result, we will never reach the point to drop the file reference again and are leaking this reference. This can be triggered when interacting with a slow-responding server. As a result, later unmount operations for this file system will fail with BUG: Dentry ... still in use (1) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) kernel BUG at fs/super.c:777! Fix this by only incrementing the reference count if the work has been queued successfully. Taking it after queue_work() is safe because all three callers hold tcon->open_file_lock across the call and _cifsFileInfo_put() decrements under that same lock, so a worker that starts the handler in the window cannot drop the reference before it has been taken. Fixes: b98749cac4a69 ("CIFS: keep FileInfo handle live during oplock break") Cc: stable@vger.kernel.org Assisted-by: Kiro:claude-opus-5 Signed-off-by: Bjoern Doebel Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 0d9ff90a5422cc7509258aaaba1e7481df4d332a Merge: d0fc310b4dfd33 af8c27375733fb Author: Linus Torvalds Date: Sat Sep 5 09:25:50 2026 -0700 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Two enhancements to add support and MCQ for additional Intel 4.0 controller types. The rest are all driver fixes, the largest of which is the mpi3mr target use after free fix, follwed by a similar TOCTOU fix for io_uring passthrough in bsg" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: megaraid_sas: Limit NVMe request size to the PRP chain frame scsi: bsg: Fix TOCTOU in io_uring passthrough command setup scsi: bsg: Cap io_uring sense copy to max_response_len scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() scsi: mpi3mr: Fix use-after-free on tgt_dev->starget during target device refresh/update scsi: target: iscsi: Reserve a terminator byte for the login payload scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands scsi: ufs: ufs-pci: Add MCQ support for Intel UFS 4.0 controllers scsi: ufs: ufs-pci: Add support for Intel UFS 4.0 HS-Gear5 scsi: sg: Report request-table problems when any status is set scsi: mpi3mr: Fix target device refcount leak in mpi3mr_sas_port_add() scsi: mpi3mr: Fix NULL pointer dereference in mpi3mr_sas_port_add() scsi: ufs: ufs-qcom: Fix sequential read variance scsi: ufs: ufs-qcom: Restore HS/LS link startup mode for Qualcomm UFS controller v6.2+ scsi: ibmvfc: Document protocol parameter of ibmvfc_alloc_target() scsi: ibmvfc: Fix kernel-doc name for ibmvfc_scsi_relogin() scsi: pm8001: Use rollback index when freeing MSI-X vectors scsi: fnic: Initialize the NVMe local port info before registering commit d0fc310b4dfd334023b90d2423818044190c0f68 Merge: 4d7d9486c04d91 00ef2248c5dae0 Author: Linus Torvalds Date: Sat Sep 5 08:58:55 2026 -0700 Merge tag 'block-7.3-20260905' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull block fixes from Jens Axboe: - NVMe fixes via Keith: - nvme-tcp fixes for an out-of-bounds write on an over-long PDU - nvmet-tcp, nvmet-rdma and nvme-rdma leak and cleanup-ordering fixes - FDP placement id array racy access fix - nvme-fc double free of fabrics options on nvme_add_ctrl() failure, and a secret leak failure - Fault injection opcode filtering - stale namespace removal during scan - Various other smaller fixes and cleanups - Flag zoned disks with GENHD_FL_NO_PART - Save the page offset gaps in a cloned bio - Fix dma_alignment for large or unreported limits in loop and zloop - Clear VM_MAYWRITE on a read-only ublk char device mmap * tag 'block-7.3-20260905' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: (25 commits) nvme-tcp.h: drop kernel-doc comments, fix a few descriptions nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails nvmet: reject namespace enable without device path nvmet-auth: Synchronize timeout work during SQ teardown MAINTAINERS: update nvme entry nvmet-tcp: reject unsolicited H2CData PDUs nvme-tcp: defer TLS inline send to io_work nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvme-tcp: return -EPROTO for a C2HData on a write nvmet: print namespace IDs as unsigned 32bit value nvme: print namespace IDs as unsigned 32bit value nvme: remove stale namespaces by NSID range during scan nvme: add missing SRCU grace period in error path nvme-fabrics: fix DHCHAP secret leak on parse failure ublk: clear VM_MAYWRITE on read-only ublk char device mmap loop, zloop: fix dma_alignment for large or unreported limits block: save page offset gaps in cloned bio block: flag zoned disks with GENHD_FL_NO_PART nvmet-rdma: fix queue leak when connect backlog is exceeded nvme: add opcode filtering for fault injection ... commit 63a7531ca31f9f097d9cc1cc3fe86ae683cdabdd Author: Mukesh Kumar Chaurasiya (IBM) Date: Fri Sep 4 14:38:58 2026 +0530 powerpc/entry: Fix irq_soft_mask corruption on replayed interrupt exit When __replay_soft_interrupts() replays a pending interrupt (e.g. PACA_IRQ_DEC -> timer_interrupt), it calls the handler directly with a synthetic pt_regs. The DEFINE_INTERRUPT_HANDLER_ASYNC wrapper around each handler calls arch_interrupt_async_exit_prepare() on the way out, which calls arch_interrupt_exit_prepare() -> local_irq_disable() -> arch_local_irq_disable(), which does: irq_soft_mask_set(IRQS_DISABLED) /* 0x1 */ This unconditionally overwrites irq_soft_mask with IRQS_DISABLED (0x1), stripping the IRQS_PMI_DISABLED (0x2) bit. The result is that irq_soft_mask is 0x1 instead of IRQS_ALL_DISABLED (0x3) when the handler returns to __replay_soft_interrupts(). For a normally-taken interrupt this is harmless: the next interrupt always enters through arch_interrupt_enter_prepare() which unconditionally sets irq_soft_mask to IRQS_ALL_DISABLED. But during replay, next_interrupt() is called directly between replayed handlers without going back through arch_interrupt_enter_prepare(), so the stripped bit is never restored. next_interrupt() then fires a WARNING: WARNING: arch/powerpc/kernel/irq_64.c:75 WARN_ON(irq_soft_mask_return() != IRQS_ALL_DISABLED) The warning was observed early in boot on a POWER10 pseries guest during kmem_cache_init_late(), where a spinlock release triggers interrupt replay that processes a pending timer interrupt. Debugger state confirming the bug: Before timer_interrupt(®s): irq_soft_mask = 0x3 (IRQS_ALL_DISABLED) correct irq_happened = 0x41 (HARD_DIS|REPLAYING) correct After timer_interrupt(®s) returns: irq_soft_mask = 0x1 (IRQS_DISABLED) WRONG - PMI bit stripped irq_happened = 0x41 unchanged The fix is to replace local_irq_disable() with hard_irq_disable(). hard_irq_disable() is the right primitive here for two reasons: 1. On PPC64 (hw_irq.h:301) it calls irq_soft_mask_set_return(IRQS_ALL_DISABLED), setting the soft mask to 0x3 (both IRQS_DISABLED and IRQS_PMI_DISABLED), which preserves the PMI bit and fixes the WARNING. The additional work it does (__hard_irq_disable(), PACA_IRQ_HARD_DIS |=) is redundant but safe since both are already set at this point in the exit path; the trace_hardirqs_off() inside is guarded by if (!arch_irqs_disabled_flags(flags)) so it will not double-fire. 2. On PPC32 (hw_irq.h:467) hard_irq_disable() maps to arch_local_irq_disable() -> __hard_irq_disable(), which clears MSR[EE] in hardware. This is exactly correct: PPC32 has no soft-mask PACA mechanism, so the hardware disable is the right way to satisfy irqentry_exit()'s requirement. This also fixes a build error on PPC32 where irq_soft_mask_set() is only defined under CONFIG_PPC64: arch/powerpc/include/asm/entry-common.h:273: error: implicit declaration of function 'irq_soft_mask_set' Using hard_irq_disable() requires no #ifdef and is consistent with how the rest of the entry code (e.g. entry-common.h:463) handles the same PPC32/PPC64 split. Fixes: 334f3f6d7a16 ("powerpc/entry: Disable interrupts before irqentry_exit") Reported-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/6f9bfb0f-b14c-468e-bb9f-c157d120d0dc@linux.ibm.com/ Tested-by: Venkat Rao Bagalkote Reviewed-by: Shrikanth Hegde Signed-off-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260904090858.128563-1-mkchauras@gmail.com commit 2b4707a149a55e8fa75c9ef32b359d60f470a566 Author: XingWang Xiang Date: Wed Sep 2 15:01:18 2026 +0900 net: mctp: i3c: serialize probe with bus removal mctp_i3c_probe() drops busdevs_lock after finding the matching bus. A concurrent I3C_NOTIFY_BUS_REMOVE can then unregister and free the bus netdev before probe passes its private data to mctp_i3c_add_device(). The latter consequently adds a list node through a freed mbus pointer. Keep busdevs_lock held until the device has been added. This also satisfies the __must_hold annotation on mctp_i3c_add_device(). Fixes: c8755b29b58e ("mctp i3c: MCTP I3C driver") Signed-off-by: XingWang Xiang Acked-by: Matt Johnston Signed-off-by: David S. Miller commit b1824233b19c1dffdb5e81283805a9e52e763caa Author: Jiangshan Yi Date: Thu Aug 13 14:37:31 2026 +0800 powerpc/pseries/pci: Fix misleading VF limit error message When the number of requested VFs exceeds MAX_VFS_FOR_MAP_PE, the message prints that limit but labels it "Configurable VFs". Report the configurable VF limit and the PE mapping limit with separate error messages. Suggested-by: Christophe Leroy Signed-off-by: Jiangshan Yi Reviewed-by: Christophe Leroy [Maddy: Fixed Christophe's reviewed by tag] Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260813063731.399598-1-yijiangshan@kylinos.cn commit 449f60f99f8f3cbe80a9bd2242945e827c5ed003 Author: Thorsten Blum Date: Mon Aug 10 16:58:27 2026 +0200 powerpc/kexec_file: Use inclusive range checks for excluded memory arch_check_excluded_range() checks if a kexec segment overlaps an excluded memory range. Both ranges use inclusive end addresses, but the overlap check uses exclusive comparisons. This skips ranges with start == ->ranges[i].end or end == ->ranges[i].start. Use inclusive comparisons instead. Fixes: 6e5250eaa665 ("powerpc/crash: use generic APIs to locate memory hole for kdump") Signed-off-by: Thorsten Blum Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260810145827.157972-3-thorsten.blum@linux.dev commit 68832eb08751b4ce23e90bd90e9414a465a99da3 Author: Thorsten Blum Date: Thu Jul 30 15:19:40 2026 +0200 powerpc/kexec: Simplify kdump_extra_elfcorehdr_size() Return the size directly and drop the extra_sz variable to simplify kdump_extra_elfcorehdr_size(). The two warning paths now fall through to the existing return 0 at the end of the function. Signed-off-by: Thorsten Blum Reviewed-by: Christophe Leroy (CS GROUP) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260730131940.597739-2-thorsten.blum@linux.dev commit c6755be4838d6ccd641effbcdc3d917b82631ff9 Author: Thorsten Blum Date: Sun Aug 9 18:24:01 2026 +0200 powerpc/kexec_file: Use inclusive range checks in add_usable_mem() add_usable_mem() adds usable memory ranges for the kdump kernel. The ranges are inclusive, but the partial overlap check uses exclusive comparisons. This skips ranges with base == loc_end or end == loc_base. Use inclusive comparisons instead. Fixes: 7c64e21a1c5a ("powerpc/kexec_file: Restrict memory usage of kdump kernel") Signed-off-by: Thorsten Blum Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260809162403.18142-2-thorsten.blum@linux.dev commit 8a4978c17a144a6583478cce933bcb2dbb25298d Author: Shivaprasad G Bhat Date: Fri Jun 26 09:13:03 2026 +0000 powerpc/rtas_pci: No hotplug on permanently removed device on pSeries The eeh_driver disables and offlines the PE permanently when it exceeds the freeze count beyond eeh_max_freeze within the last hour. The PE is only offline, so the device tree entries, eeh device references are all intact till the real unplug of the device from the guest/host takes place. On pSeries, with a new hotplug of any PCI device, the drmgr initiates a system-wide PCI rescan, which finds devices offlined by the eeh_driver and there will be attempts to bring them online. This leads to recurring EEHs either at the config read time itself or a bit later depending on the type of the problem. For PowerNV, the commit d2b0f6f77ee5 ("powerpc/eeh: No hotplug on permanently removed dev") introduced the EEH_DEV_REMOVED flag to prevent such inadvertent rescans on hierarchical toplogies relavent in Baremetal setups. For pSeries, such topologies don't really make sense as the devices are either part of the same PE OR exposed as independent devices on multiple virtual PHBs. However, the inadvertent rescans are still a possibility with either hotplug of a new device or otherwise with manual system-wide pci bus rescan attempts. So the patch checks for EEH_DEV_REMOVED before allowing config space access just like PowerNV, making the PCI core omit the PE, and thus preventing subsequent EEH recurances. The patch is tested on PowerVM and KVM machines with single and multi-function devices, and on the devices behind a switch. The unplug of the affected devices post EEH removal is also working fine as expected. Signed-off-by: Shivaprasad G Bhat Reported-by: Tasmiya Nalatwad Tested-by: Tasmiya Nalatwad Reviewed-by: Harsh Prateek Bora References: d2b0f6f77ee5 ("powerpc/eeh: No hotplug on permanently removed dev") Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/178246517230.1267.12206176311111155505.stgit@linux.ibm.com commit c5e68706527968282e49de205cc2b935823cb88a Author: Shivaprasad G Bhat Date: Tue Jul 14 17:16:23 2026 +0000 powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver The commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18 The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no error handlers like slot_reset(), resume() etc defined). Fixes: 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") Cc: stable Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Shivaprasad G Bhat Reviewed-by: Amit Machhiwal Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/178404937381.913.2759874335293830160.stgit@linux.ibm.com commit d96171d911e3b89ca2957c04264019cf2f96287b Author: Shivaprasad G Bhat Date: Wed Aug 19 17:58:22 2026 +0000 powerpc: pci-ioda: Fix the stale irq chip reference The commit f0ac60e6e311 ("powerpc/powernv/pci: Switch to use msi_create_parent_irq_domain()") removed the legacy MSI irq chip pnv_pci_msi_irq_chip but left behind the static definition of it and its reference in is_pnv_opal_msi(). The KVM IRQ bypass for vfio devices is broken because the comparision in is_pnv_opal_msi() fails on the comparision with stale unused variable showing the below errors in dmesg. kvmppc_set_passthru_irq_hv: Could not assign IRQ map for (X,Y) kvmppc_set_passthru_irq (irq X, gsi Y) fails: -2 vfio-pci A:B:C.D irq bypass producer (eventfd Z) registration fails: -2 The patch removes the stale variable definition and fixes the is_pnv_opal_msi() by comparing against the chip name prefix. Fixes: f0ac60e6e311 ("powerpc/powernv/pci: Switch to use msi_create_parent_irq_domain()") Cc: stable@kernel.org Signed-off-by: Shivaprasad G Bhat Tested-by: Gautam Menghani Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/178716225364.1437.6201568081502251835.stgit@linux.ibm.com commit 3a2c4d55e32ad65efebdb6de44eef3bfa08bb49d Author: Kees Cook Date: Wed Sep 2 15:31:14 2026 -0700 treewide: refresh kmalloc_obj() conversions This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook commit 4d7d9486c04d917265f64c55bd23b2cc4fe7749c Merge: 654ae5d73c05bd 6903878d4654bd Author: Linus Torvalds Date: Fri Sep 4 19:36:11 2026 -0700 Merge tag 'integrity-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity Pull IMA fixes from Mimi Zohar: - Instantiating the ima_file_truncate and ima_path_truncate LSM hooks resulted in configfs locking issues. configfs files should not be measured, appraised, or audited in the first place, so the builtin policies are updated to exclude them. - IMA audit messages include the filename, which could result in a page fault when the filename doesn't exist - Un-hide the IMA_MEASURE_PCR_IDX Kconfig prompt * tag 'integrity-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: ima: allow users to specify the pcr index with IMA_MEASURE_PCR_IDX ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() ima: don't measure/appraise files on configfs configfs: move CONFIGFS_MAGIC definition to magic.h commit 0f300db7b7315b2c7ea0e2d4437b88de162d191f Author: Vladyslav Ivashchenko Date: Fri Sep 4 15:31:55 2026 +0200 iio: adc: axp288: Add TS bias override for Haier HV103H The Haier HV103H firmware configures the AXP288 TS pin bias current to 60 uA. This causes the battery temperature reading to cross the charging temperature threshold under load, incorrectly stopping battery charging. Setting the TS bias current to 80 uA fixes the temperature measurement and prevents charging from being incorrectly disabled. Add a DMI quirk to use the 80 uA TS bias current on the Haier HV103H. Fixes: 9bcf15f75cac ("iio: adc: axp288: Fix TS-pin handling") Fixes: 048058399f19 ("iio: adc: axp288: Override TS pin bias current for some models") # Add necessary infrastructure Signed-off-by: Vladyslav Ivashchenko Reviewed-by: Hans de Goede Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit 80dd7e754b3aa9637a0758ad93fa209f9650ec48 Author: Sahil Chandna Date: Tue Sep 1 07:17:58 2026 -0500 net: mana: Reserve extra CQ slot for the fence completion CQE The RX completion queue is sized to hold exactly one CQE per posted RX WQE. MANA_FENCE_RQ makes hardware post an additional CQE_RX_OBJECT_FENCE after the packet CQEs. The current sizing reserves no extra slot for it and in rare cases, CQ has no guaranteed slot for the fence CQE when it is full of packet CQEs. This can lead to dropping the fence completion while the driver waits holding RTNL lock throughout the timeout duration. Reserve one extra CQE slot for CQE_RX_OBJECT_FENCE. mana_gd_alloc_memory() requires queue_size to be a power-of-two and at least MANA_PAGE_SIZE; the reservation pushes cq_size past a power-of-two, so round up the CQ size in mana_create_rxq(). Cc: stable@vger.kernel.org Fixes: 6cc74443a773 ("net: mana: Add RX fencing") Signed-off-by: Sahil Chandna Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/20260901121837.3503240-1-sahilchandna@linux.microsoft.com Signed-off-by: Jakub Kicinski commit b75a000f2ac15f4778ddd6d9298d60b24ad776fa Merge: 519f858317afc5 cf2475616b11c0 Author: Alexei Starovoitov Date: Fri Sep 4 18:17:31 2026 -0700 Merge branch 'bpf-add-missing-precision-propagation-after-bpf_register_is_null-calls' Eduard Zingerman says: ==================== bpf: add missing precision propagation after bpf_register_is_null calls Fix [1] uncovered a host of locations where the call to bpf_register_is_null() is not followed by a call to bpf_mark_chain_precision(). check_map_kptr_access() is omitted as it is handled [2] by another series. [1] https://lore.kernel.org/bpf/20260904083325.2083493-7-eddyz87@gmail.com/ [2] https://lore.kernel.org/bpf/20260904104203.345917-6-memxor@gmail.com/ --- ==================== Link: https://patch.msgid.link/20260904-register-is-null-precise-fixes-v1-0-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov commit cf2475616b11c0efefdd969d42913f56ca39f918 Author: Eduard Zingerman Date: Fri Sep 4 17:06:01 2026 -0700 bpf: use mark_arg_precision() in check_mem_size_reg() Use newly added mark_arg_precision() helper in check_mem_size_reg(). Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-10-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov commit 1d7f8f191c06f967a85922c4652dc33c132b585d Author: Eduard Zingerman Date: Fri Sep 4 17:06:00 2026 -0700 bpf: propagate mark_chain_precision() errors out of loop_flag_is_zero() Stop verification if mark_chain_precision() fails when called from loop_flag_is_zero(). No functional change intended for the paths where backtracking succeeds. Fixes: 1ade23711971 ("bpf: Inline calls to bpf_loop when callback is known") Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-9-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov commit 91957791663f49561848c40e982061799b8f86b0 Author: Eduard Zingerman Date: Fri Sep 4 17:05:59 2026 -0700 selftests/bpf: precision of a NULL global subprogram BTF_ID argument Check that mark_chain_precision() is called for a NULL pointer passed as an __arg_trusted __arg_nullable argument of a global subprogram. Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-8-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov commit e726fc6b9afe6b3a446a31d0f0767b7b9cb5085e Author: Eduard Zingerman Date: Fri Sep 4 17:05:58 2026 -0700 bpf: mark a NULL BTF_ID argument of a global subprogram precise btf_check_func_arg_match() accepts a NULL register for an ARG_PTR_TO_BTF_ID argument tagged __arg_nullable and skips check_reg_type() and check_func_arg_reg_off() without marking the register precise. Hence a checkpoint created on such a path would prune against arbitrary scalar value. Fixes: e2b3c4ff5d18 ("bpf: add __arg_trusted global func arg tag") Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-7-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov commit 562d266d3fae571617e72417753df648db261c56 Author: Eduard Zingerman Date: Fri Sep 4 17:05:57 2026 -0700 selftests/bpf: precision of a NULL kfunc argument Check that mark_chain_precision() is called for a NULL pointer passed as a __nullable kfunc memory argument. Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-6-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov commit 506ada89629ec7059b96ecfb0dc7d33ece0103ca Author: Eduard Zingerman Date: Fri Sep 4 17:05:56 2026 -0700 bpf: mark a NULL kfunc argument precise check_kfunc_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. Fixes: 3bda08b63670 ("bpf: Allow NULL buffers in bpf_dynptr_slice(_rw)") Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-5-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov commit 100f4cc0d59be88d2b4d6eb42e51910ea2548d04 Author: Eduard Zingerman Date: Fri Sep 4 17:05:55 2026 -0700 selftests/bpf: precision of a NULL global subprogram memory argument Check that mark_chain_precision() is called for a NULL pointer passed as a nullable pointer argument of a global subprogram. (Pointer arguments of the global subprograms are nullable by default). Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-4-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov commit f1e418129f2ebb5376df2f1cd19720fa80f8adb4 Author: Eduard Zingerman Date: Fri Sep 4 17:05:54 2026 -0700 bpf: mark a NULL memory argument of a call precise check_mem_reg() 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. The argument may live on the stack rather than in a register when a call has more than MAX_BPF_FUNC_REG_ARGS arguments, hence the new mark_arg_precision() helper. Fixes: e5069b9c23b3 ("bpf: Support pointers in global func args") Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-3-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov commit 593c8eb0fb91a24c39244a7f9e7d04412d750544 Author: Eduard Zingerman Date: Fri Sep 4 17:05:53 2026 -0700 selftests/bpf: precision of a NULL helper argument Check that mark_chain_precision() is called for a NULL nullable memory argument and for the zero flags argument of bpf_get_local_storage(). Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-2-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov commit 1a3a10b030c96ea88868ccc060a16827c01eaa5a Author: Eduard Zingerman Date: Fri Sep 4 17:05:52 2026 -0700 bpf: mark a NULL call argument precise 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 commit db88216424a37e9209bb7834453c568e7f4604f5 Merge: 6262acad9db197 73608de7e59246 Author: Jakub Kicinski Date: Fri Sep 4 18:07:40 2026 -0700 Merge branch 'pds_core-fixes-for-the-pci-reset-path' Nikhil P. Rao says: ==================== pds_core: fixes for the PCI reset path [part] Patch 1 is the v2 patch with the pdsc_core_init() and pdsc_identify_ver() checks removed. Those checks are dead code. commit cd09971dcc1c ("pds_core: keep the health thread stopped during reset") disables health_work across the reset, so the health thread can no longer reach pdsc_setup() with the BARs unmapped. The only other callers are probe and pdsc_reset_done(), and both map the BARs earlier in the same call, so cmd_regs cannot be NULL by the time they get there. The pdsc_core_init() check is also worse than what it replaces. Its bail-out jumps to err_out_uninit, which ends up in pdsc_intr_free() and writes to pdsc->intr_ctrl, also NULL at that point. On v2 I said I would convert pdsc_identify() and pdsc_core_init() to pdsc_devcmd_with_data() once the PLDM series landed. Dropping that: the helper has no read-back path and both callers need one, and giving them an -ENXIO return means hardening pdsc_intr_free() against a NULL intr_ctrl on the err_out_uninit path. That is a lot of churn to deduplicate two call sites. Patch 2 is the VF pci_release_regions() fix, older than the cmd_regs race, so it carries its own Fixes tag. The v2 changelog claim that pdsc_unmap_bars() clears db_pages was wrong. It clears info_regs, cmd_regs, intr_status and intr_ctrl; db_pages is never mapped. v2: https://lore.kernel.org/20260804235946.177762-1-nikhil.rao@amd.com v1: https://lore.kernel.org/20260729055258.1416225-1-nikhil.rao@amd.com ==================== Link: https://patch.msgid.link/20260901044219.1361466-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski commit 73608de7e59246b4b533c1ffaee158a7048e186e Author: Nikhil P. Rao Date: Tue Sep 1 04:42:18 2026 +0000 pds_core: don't release PCI regions for VFs on reset pdsc_reset_prepare() called pci_release_regions() unconditionally, but only PFs call pci_request_regions() (pdsc_init_pf). On a VF FLR this makes the kernel warn "Trying to free nonexistent resource". Fixes: ffa55858330f ("pds_core: implement pci reset handlers") Reported-by: sashiko-bot Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260804235946.177762-1-nikhil.rao%40amd.com Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260901044219.1361466-3-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski commit 7980325b2f71e3f65c1323c39792e2455da6fab6 Author: Nikhil P. Rao Date: Tue Sep 1 04:42:17 2026 +0000 pds_core: fix cmd_regs access racing BAR unmap on reset pdsc_reset_prepare() and pdsc_reset_done()'s pdsc_map_bars() error path clear/iounmap cmd_regs without devcmd_lock, and pdsc_legacy_firmware_update()'s download loop derefs cmd_regs after dropping and retaking the lock without re-checking. An FLR concurrent with a devlink flash can unmap cmd_regs under an in-flight devcmd, causing a NULL deref or a write to unmapped MMIO. Take devcmd_lock across the BAR unmap/remap, and re-check cmd_regs in the download loop. Only the PF maps cmd_regs and runs devcmd, so skip the unmap on a VF, as pdsc_remove() and pdsc_reset_done() already do. A reset that completes entirely within the unlocked window is not a correctness problem for the image: the device clears its update session, so a resumed download is rejected, and it verifies the staged image before writing a flash slot, reporting PDS_RC_BAD_FW rather than activating it. pdsc_unmap_bars() also clears info_regs, intr_status and intr_ctrl. The interrupt and start/stop readers of those are quiesced before the unmap by pdsc_fw_down(), which frees the interrupts and tears down the queues. The debugfs readers are not, since those files outlive a reset; that is pre-existing and out of scope here. Fixes: e96094c1d11c ("pds_core: Clear BARs on reset") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260708212222.296202-1-nikhil.rao%40amd.com?part=3 Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260901044219.1361466-2-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski commit 6262acad9db197b5ed12e3b245d2e6d0c80fb960 Merge: 98fc57d167446b 0a7252d7f85478 Author: Jakub Kicinski Date: Fri Sep 4 16:30:53 2026 -0700 Merge branch 'net-cap-tx_queue_len-at-s16_max-to-prevent-oversized-ring-allocations' Jamal Hadi Salim says: ==================== net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations An unprivileged user (via unshare -Urn) can set a huge tx_queue_len and exhaust global memory through ring allocations sized from it (pfifo_fast skb_arrays, tun/tap ptr_rings). The reproducer from vega@nebusec.ai set the following params for illustration: txqlen of 500000 -> ~32 GiB/ring attempts, 1.6 GB tun, ~960 MB tap. Gets worse when you consider qdiscs like mq. What we fix: every path an unprivileged user can use to install an oversized tx_queue_len is rejected with -ERANGE before any ring is allocated; per-ring memory is bounded at 256 KiB. This is for you sashikos: What we deliberately _do not fix_ bound the NUMBER of rings. With the cap in place the worst case moves from "one knob" to the aggregate of ring x queues x devices, example: ip link add v0 numtxqueues 4096 txqueuelen 32767 type veth tc qdisc add dev v0 root mq -> 4096 * 3 * 32767 * 8 = ~3.0 GiB (one command) 50 tun devices x 256 queues x 32767 x 8 = ~3.1 GiB Unfortunately tx_queue_len is a bit ambigious in meaning: In some cases it means a ring size (which is pre-allocated, ex: tun, tap, and pfifo_fast); a cap of 4096 seems reasonable here. but in other cases it is used to indicate a queue limit ex: the qdisc consumers that allocate nothing (pfifo/bfifo/gred/plug/sfb, htb direct_qlen, qfq, teql). 32767 is a legitimate high-BDP queue length, so we are going to keep that value. Getting back to you sashikos, after this is merged and shows up in net-next we will send followup patches as follows: this series is not misread as "closes the OOM class"): a) Per-site ring limits at six identified locations - pfifo_fast init/resize, - tun attach/resize, - tap minor/resize) if you can spot more in your review we will take care of those as well. b) memcg accounting (GFP_KERNEL_ACCOUNT) for those ring allocations: contains a memcg-limited container's ring memory. Not GFP_KERNEL_ACCOUNT has no effect on the unshare attacker but will protect against containers (memory.max in its cgroup) ==================== Link: https://patch.msgid.link/QDISC-2899.v2.20260901233641@mojatatu.com Signed-off-by: Jakub Kicinski commit 0a7252d7f85478080385de4c1072085e30849fe3 Author: Jamal Hadi Salim Date: Wed Sep 2 17:29:10 2026 -0400 selftests: tc-testing: add tx_queue_len cap regression tests Add nine test cases for the S16_MAX tx_queue_len cap to the pfifo_fast suite. Netlink cases exercise the ifla_policy bound (2/3); the two new sysfs cases exercise the netif_change_tx_queue_len() choke point that 1/3 owns (SIOCSIFTXQLEN shares it; the ioctl is not portably reachable from tdc): - dbe3: set txqueuelen 32767 (S16_MAX) - accepted, pins the exact boundary value. - b50e: set txqueuelen 32768 - rejected with -ERANGE. - 40f8: write 32768 to /sys/class/net/*/tx_queue_len - rejected (covers patch 1/3 directly; netlink cannot reach this path). - 4b6e: write 32767 via sysfs - accepted, boundary positive control for the patch-1 path. - b90d: create a dummy with txqueuelen 32767 - accepted. - 57ab: create a dummy with txqueuelen 32768 - rejected at netlink parse time. - e777: create a dummy with txqueuelen 500000 - rejected (the v1 bypass path flagged by review). - 31ac: create a veth with an oversized txqueuelen on the peer nest - rejected (the peer nest is parsed against ifla_policy too). - b567: create a veth with txqueuelen on both ends within the cap - accepted (positive control for the peer nest). The three negative-creation verifies assert device absence ("ip -o link show" must not contain the device), not merely absence of a qlen pattern - the device does not exist when creation fails, so the exit code carries the signal and the verify adds content. The v1 04b5 "resize rollback" case is dropped: with the cap checked first, netif_change_tx_queue_len() returns -ERANGE before the write, the notifier or any qdisc resize, so the case exercised no resize and no rollback. It was also nondeterministic: pre-patch, the resize issues three ~11 MB kvmallocs for qlen 500000 which normally succeed, so the case passed on an unfixed kernel only under memory pressure - its outcome depended on the test host's free memory. Test commands run inside the netns, but nsPlugin creates the veth peer in the root namespace, so the teardown deletes the in-ns end only; deleting the peer via the pair is implicit. Note: iproute2 treats "txqueuelen" appearing after "type X" as a link-type attribute and silently drops it, so the creation cases place it before "type" to actually reach the kernel. Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-2899.v2.20260901233641@mojatatu.com.3 Signed-off-by: Jakub Kicinski commit 1aa9e143bf51405665a793d4cc925e1c4f0c5922 Author: Jamal Hadi Salim Date: Wed Sep 2 17:29:09 2026 -0400 net: reject oversized tx_queue_len at netlink parse time rtnl_create_link() assigns IFLA_TXQLEN directly to dev->tx_queue_len without going through netif_change_tx_queue_len(), so a device created with "ip link add ... txqueuelen 500000" bypasses the S16_MAX cap and still triggers the oversized ring allocations in pfifo_fast, tun and tap. The veth peer nest (rtnl_nla_parse_ifinfomsg()) and the RTM_NEWLINK-on-existing-device path reach the same sinks. Enforce the cap in ifla_policy instead: IFLA_TXQLEN becomes NLA_POLICY_FULL_RANGE(NLA_U32, &txqlen_range) with txqlen_range = { .min = 0, .max = S16_MAX }. All netlink consumers parse against this policy - rtnl_setlink(), rtnl_newlink() (create and change), and the veth peer nest - so every netlink path is capped at parse time and rejects the attribute with -ERANGE plus a proper "integer out of range" extack message before any device state is modified (the RTM_SETLINK half-application wart is gone with it). Document the bound in the rt-link.yaml netlink spec. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn): ip link add v0 txqueuelen 500000 type veth peer name v1 -> on the fixed kernel this is rejected with -ERANGE ("integer out of range" extack) instead of installing an oversized tx_queue_len that later inflates pfifo_fast/tun/tap ring allocations. - ip link set v0 txqueuelen 500000 is likewise rejected at parse time. Fixes: 38f7b870d4a6 ("[RTNETLINK]: Link creation API") Reported-by: Vega Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-2899.v2.20260901233641@mojatatu.com.2 Signed-off-by: Jakub Kicinski commit 66ab4c59b74db7ab53a1c9083feaaede393a96a0 Author: Jamal Hadi Salim Date: Wed Sep 2 17:29:08 2026 -0400 net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations Several subsystems allocate ring buffers sized by dev->tx_queue_len with no upper bound. An unprivileged user (via unshare -Urn) can set a huge tx_queue_len and exhaust global memory with ring allocations: - pfifo_fast: pfifo_fast_init() and pfifo_fast_change_tx_queue_len() allocate 3 skb_array rings of tx_queue_len entries each. - tun: tun_queue_resize() and the queue-attach path resize ptr_rings to tx_queue_len on the NETDEV_CHANGE_TX_QUEUE_LEN notifier. - tap (macvtap/ipvtap): tap_queue_resize() and tap_init() resize/init ptr_rings to tx_queue_len on the same notifier. netif_change_tx_queue_len() is the single entry point for IFLA_TXQLEN, sysfs, and the SIOCSIFTXQLEN ioctl. Cap new_len at S16_MAX (32767) there so the oversized value is rejected at set time. This takes effect whether the device is up or down, before dev->tx_queue_len is written, before any notifier fires, and before any ring is allocated. The "> S16_MAX" check also subsumes the previous unsigned-long truncation test, and a negative ifr_qlen from the ioctl lands far above the cap after conversion, so both old failure modes are covered by the one comparison. tx_queue_len is ambigious: both a per-ring sizing multiplier and a default queue-length/limit knob for consumers that allocate nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb direct_qlen, qfq max_classes, teql). 32767 is chosen as the largest value NLA_POLICY_FULL_RANGE can express for the u32 IFLA_TXQLEN policy in patch 2/3 while staying a legitimate queue length on high-BDP paths; the ring-memory trade-off of a shared knob is disclosed below. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn). - pfifo_fast: create veth pairs, set tx_queue_len to 500000, attach mq+pfifo_fast. ~28 iterations OOMs a 2GB guest. - tun: create 50 tun devices with IFF_MULTI_QUEUE, set tx_queue_len to 500000, open 8 queues each. ~1.6GB of ptr_ring allocations OOMs a 512MB guest. - tap: same as tun with IFF_TAP. ~960MB OOMs a 512MB guest. - On the fixed kernel the oversized tx_queue_len is rejected with -ERANGE at set time (all four paths: RTM_SETLINK, RTM_NEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively). Fixes: 6a643ddb5624 ("net: introduce helper dev_change_tx_queue_len()") Reported-by: Vega Closes: https://lore.kernel.org/netdev/20260828121902.66837-1-jhs@mojatatu.com/ Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-2899.v2.20260901233641@mojatatu.com Signed-off-by: Jakub Kicinski commit 98fc57d167446b95b4e719815fe79edef93f8e7a Author: Seungwon Bae Date: Thu Sep 3 00:59:56 2026 +0900 vxlan: reject dynamic fdb entries that reference a nexthop id The commit cited in the Fixes tag allowed VXLAN FDB entries to point to FDB nexthops so that overlay traffic could be load balanced across multiple VTEPs. Such entries can only be configured from user space, cannot be learned and cannot roam. They only make sense with a user space control plane such as E-VPN where data plane learning is disabled. Despite that, the VXLAN driver does not currently prevent such entries from being configured with the "dynamic" flag. The per-nexthop FDB list is only protected by the per-device hash lock, which is not sufficient when two VXLAN devices point to the same FDB nexthop and therefore share the list. Aging runs in softirq context without RTNL, so an entry deleted by one device can race with an addition or deletion from the other, leading to list corruption: list_del corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65 __list_del_entry_valid_or_report+0x1aa/0x210 ... vxlan_fdb_destroy+0x5b8/0xad0 vxlan_cleanup+0x328/0x450 call_timer_fn+0x2a/0x1c0 run_timer_softirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy Fix this by rejecting the bogus configuration of dynamic FDB entries that point to FDB nexthops, both when created and when an existing entry is updated. As such, the per-nexthop FDB list is only ever mutated under the RTNL lock. Add test cases to make sure that this does not regress in the future. Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") Suggested-by: Ido Schimmel Signed-off-by: Seungwon Bae Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260902155956.296699-1-qotmddnjs@ajou.ac.kr Signed-off-by: Jakub Kicinski commit 907a56ab3eb8a58500a58daa76087f17bb2b6826 Author: Alexandra Winter Date: Wed Sep 2 16:37:33 2026 +0200 s390/ism: folio_put() after error dmb->cpu_addr was allocated via folio_alloc(). Use folio_put() instead of kfree() in the error exit of ism_alloc_dmb() to avoid slab allocator corruption. While at it, reset dmb->cpu_addr after folio_put to avoid unintentional UAF by future callers. Fixes: 83781384a96b ("s390/ism: Properly fix receive message buffer allocation") Signed-off-by: Alexandra Winter Reviewed-by: Gerd Bayer Link: https://patch.msgid.link/20260902143733.433574-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski commit 1668a31e3b1ad358d981ddb6dbd3db1fe0533621 Author: Alexandra Winter Date: Wed Sep 2 16:34:38 2026 +0200 dibs: Unregister dibs_class after error In case dibs_loopback_init() fails, e.g. because of -ENOMEM, dibs_init() must unregister dibs_class. Otherwise dibs_class and /sys/class/dibs exist even though the functionality is not available. A retry to load the module fails with -EEXIST. Unregister dibs_class in the error path of dibs_init. Note that before commit ad3dfa80be76 ("dibs: change dibs_class to a const struct") class_destroy(dibs_class) is required instead of class_unregister(&dibs_class). Fixes: 804737349813 ("dibs: Create class dibs") Signed-off-by: Alexandra Winter Link: https://patch.msgid.link/20260902143438.426664-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski commit 5d50e90add8b4a978395e893e81954d19d58a7c5 Author: Jason Winter Date: Wed Sep 2 10:40:41 2026 +0200 net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is } else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB "frame" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check. Fixes: ca139d76b0d9 ("cx82310_eth: re-enable ethernet mode after router reboot") Signed-off-by: Jason Winter Link: https://patch.msgid.link/BESP194MB283265DDDC63B6B78D8D34FBB8B72@BESP194MB2832.EURP194.PROD.OUTLOOK.COM Signed-off-by: Jakub Kicinski commit 78a86d75a70e1e227711c72865c59b1422d0a5ae Author: Fourie Zhang Date: Wed Sep 2 17:27:12 2026 +0800 net: mpls: clear inner_protocol when the last label is popped skb_mpls_push() records the pre-encapsulation network header once, gated on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it outlives the encapsulation it describes. Open vSwitch can then re-push MPLS onto a packet whose inner_network_header still points at the older, deeper offset: push a label, pop every label, recirculate (ovs_flow_key_update() re-derives key->eth.type and resets network_header, but leaves inner_*), then push again. ovs_fragment() trusts the record: skb->network_header = skb->inner_network_header; so skb_network_offset() goes negative. The bound check is signed: if (skb_network_offset(skb) > MAX_L2_LEN) a negative offset passes it, and prepare_frag() widens the value: unsigned int hlen = skb_network_offset(skb); memcpy(&data->l2_data, skb->data, hlen); which is a ~4GiB memcpy out of a 30-byte per-CPU buffer. Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8): BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 prepare_frag+0x3df/0x4e0 ovs_fragment+0x589/0x7e0 do_output+0x4ce/0x5e0 do_execute_actions+0x55d2/0x7b30 ovs_execute_actions+0xea/0x450 Same root-cause shape as commit 975b5b067f52 ("ipv6: sr: restore network header before routing and forwarding"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path. Clear inner_protocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/act_mpls.c is the only other skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and restores inner_protocol around fragmentation in the same way OVS does. Fixes: 48d2ab609b6b ("net: mpls: Fixups for GSO") Cc: stable@vger.kernel.org Signed-off-by: Fourie Zhang Acked-by: Jiri Benc Link: https://patch.msgid.link/20260902092719.2874481-1-fouriezhang@tencent.com Signed-off-by: Jakub Kicinski commit c91b4d6e5cc30ceea3f23ebe29aec012709a065f Author: Nikhil P. Rao Date: Tue Sep 1 05:56:27 2026 +0000 ionic: use netif_txq_maybe_stop() in ionic_tx() Commit 061b9bedbef1 ("ionic: Rework Tx start/stop flow") replaced ionic_maybe_stop_tx() with netif_txq_maybe_stop() to get the memory barriers around the stop/start bits right, but did not cover the stop in ionic_tx() added by commit 138506ab249b ("ionic: Check stop no restart"). Convert the remaining site. netif_txq_maybe_stop() requires the ring indexes to be updated before it is invoked, so the post has to come first. But ring_dbell comes from __netdev_tx_sent_queue(), which runs after that and reads the stop bit, so it is not known in time to pass to ionic_txq_post(). Post without the doorbell and ring it separately. The stop condition is unchanged. The re-check only clears the stop bit when space has become available, so the doorbell starvation fixed by commit 138506ab249b ("ionic: Check stop no restart") cannot recur. Fixes: 138506ab249b ("ionic: Check stop no restart") Signed-off-by: Nikhil P. Rao Reviewed-by: Brett Creeley Link: https://patch.msgid.link/20260901055627.1373129-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski commit 1f29543126dde307e8b5fb6a740c54e59deaa2ff Author: Viswajith Murali Date: Tue Sep 1 15:13:17 2026 +0530 octeontx2-af: mcs: Clear stale X2P calibration state before calibration Some firmware versions leave MCSX_MIL_GLOBAL bit 5 set on boot. If the bit is already set when the driver attempts X2P calibration, the hardware sees no rising edge and calibration never triggers. Clear the bit and wait briefly before starting calibration to ensure a clean rising edge. Fixes: ca7f49ff8846 ("octeontx2-af: cn10k: Introduce driver for macsec block.") Signed-off-by: Nitin Shetty J Signed-off-by: Viswajith Murali Link: https://patch.msgid.link/20260901094318.1395356-1-nshettyj@marvell.com Signed-off-by: Jakub Kicinski commit 4b772869a1e5f9da5cef5b9c722ec0aa424ee0a0 Author: Nikolay Aleksandrov Date: Thu Sep 3 12:38:51 2026 +0300 net: bridge: mcast: properly convert mglist to rcu Sashiko reported a bug [1] that br_multicast_del_port_group unlists the port group not using proper rcu helper that preserves the next pointer and after that immediately frees the port group without waiting for rcu grace period. The only rcu walker of mglist is br_multicast_list_adjacent() and it turns out that function has always been buggy because mglist was never properly converted to RCU. Fix it by converting it to rcu and moving its initialization after eth_addr's. Initializing p->next can use RCU_INIT_POINTER because we have a barrier from the hlist_add_head_rcu call later, besides we're initializing an unpublished structure anyway. [1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260826014200.362304-1-littleddfu%40gmail.com Fixes: 07f8ac4a1e26 ("bridge: add export of multicast database adjacent to net_dev") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260903093851.1494297-1-razor@blackwall.org Signed-off-by: Jakub Kicinski commit 742b94967d55f5e9237dc7ac52761809b6d86b4c Merge: 1746ef2e2df2ad 47a582b2b0e7bb Author: Jakub Kicinski Date: Fri Sep 4 15:20:00 2026 -0700 Merge branch 'eth-fix-bugs-in-ntuple-filter-reporting' Jakub Kicinski says: ==================== eth: fix bugs in ntuple filter reporting Looking thru some reports prompted by: Add new way to add BPF LSM hooks https://lore.kernel.org/20260831110934.241898-1-a.s.protopopov@gmail.com I/Claude noticed 3 drivers with buggy n-tuple filter dump. Fix these drivers, add a hopefully clearer mention in the doc. ==================== Link: https://patch.msgid.link/20260903032611.3000029-1-kuba@kernel.org Signed-off-by: Jakub Kicinski commit 47a582b2b0e7bb5753e4803988e150a405b57f51 Author: Jakub Kicinski Date: Wed Sep 2 20:26:11 2026 -0700 ethtool: document that GRXCLSRLALL rule_cnt is a caller-provided limit Three drivers have shipped a get_rxnfc() which dumps its entire rule table into rule_locs, reading rule_cnt as "how many rules do I have" rather than "how many entries did the caller allocate". Nothing in the callback's documentation contradicted that reading. The distinction only matters because the ioctl lets an unprivileged caller pick rule_cnt directly, so getting it wrong is a heap overflow rather than a truncated dump. Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260903032611.3000029-6-kuba@kernel.org Signed-off-by: Jakub Kicinski commit b1fffc273112e7284c5b705e186b43b5770cd3d5 Author: Jakub Kicinski Date: Wed Sep 2 20:26:10 2026 -0700 net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer size mv88e6xxx_get_rxnfc() uses rxnfc->rule_cnt as the write index while dumping the policy IDR, clobbering the input value before it has been looked at. That input is the number of entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed policy rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Count into a local so the caller's limit survives the walk, and stop with -EMSGSIZE once it is reached. Fixes: da7dc8755304 ("net: dsa: mv88e6xxx: add RXNFC support") Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260903032611.3000029-5-kuba@kernel.org Signed-off-by: Jakub Kicinski commit 108bb2142e3a12c9ad625ad662973127a113ddc6 Author: Jakub Kicinski Date: Wed Sep 2 20:26:09 2026 -0700 eth: nfp: drop the replaced rule from the list when reprogramming fails nfp_net_fs_add() replaces an existing rule by deleting it from the hardware, decrementing nn->fs.count and programming the new one. If nfp_net_fs_add_hw() fails the old entry stays on nn->fs.list - only the success path reaches list_replace() - so the list is one longer than nn->fs.count, and it advertises a rule whose hardware entry has already been torn down. nn->fs.count is what ETHTOOL_GRXCLSRLCNT reports, so userspace then sizes its buffer one entry short of what the GRXCLSRLALL walk wants to write. That used to overwrite one u32 past the allocation; since the walk is bounded it is a permanent -EMSGSIZE instead, as nothing ever resyncs the counter. Fixes: 9eb03bb1c035 ("nfp: add ethtool flow steering callbacks") Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260903032611.3000029-4-kuba@kernel.org Signed-off-by: Jakub Kicinski commit f1986bf87b0709c95126fe196cf39e5b8c8453a1 Author: Jakub Kicinski Date: Wed Sep 2 20:26:08 2026 -0700 eth: nfp: bound the ntuple rule dump by the caller's buffer size nfp_net_get_fs_loc() dumps every entry of nn->fs.list into rule_locs[] without consulting cmd->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed flow steering rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Bail out with -EMSGSIZE when the buffer fills up, the way the other ntuple capable drivers do, and report how many locations were filled so a shrinking rule list does not leave the caller reading stale slots. Reported-by: VEGA Fixes: 9eb03bb1c035 ("nfp: add ethtool flow steering callbacks") Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260903032611.3000029-3-kuba@kernel.org Signed-off-by: Jakub Kicinski commit cdb719f4b8596d9ccee2d56d204c2c4dce982f46 Author: Jakub Kicinski Date: Wed Sep 2 20:26:07 2026 -0700 net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size bcm_sf2_cfp_rule_get_all() walks the whole cfp.unique bitmap into rule_locs[] without consulting nfc->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed CFP rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Fixes: 7318166cacad ("net: dsa: bcm_sf2: Add support for ethtool::rxnfc") Reviewed-by: Jonas Gorski Reviewed-by: Florian Fainelli Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260903032611.3000029-2-kuba@kernel.org Signed-off-by: Jakub Kicinski commit 1746ef2e2df2ad71c66eca56364d56bde284523b Author: Eric Dumazet Date: Thu Sep 3 14:39:40 2026 +0000 bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit() In bond_do_alb_xmit() and rlb_arp_xmit(), make sure to unclone skb head via skb_cow_head() before modifying the source MAC address (Ethernet header and ARP payload) to avoid silent corruption if the skb is shared or cloned. Avoid caching the header pointers across skb_cow_head(). In rlb_arp_xmit(), only modify arp->mac_src if it differs from tx_slave->dev->dev_addr to avoid an unnecessary copy and head reallocation. Also, we should not assume mac header is set in output path. Use skb_eth_hdr() instead of eth_hdr() to fix the issue, and remove now redundant skb_reset_mac_header() calls. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Cc: Jay Vosburgh Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260903143940.1180513-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit 5bd9e4e7cdaa03879e9b73b12ab52cceb1edd55b Author: Ido Schimmel Date: Thu Sep 3 11:02:59 2026 +0300 nexthop: Initialize extack in remove_nh_grp_entry() remove_nh_grp_entry() prints the extack message when a listener fails to replace the reduced nexthop group. However, extack is not initialized and listeners are not required to set a message when returning an error. Neither netdevsim nor mlxsw do so when an allocation fails, resulting in the dereference of an uninitialized stack pointer. Fix by zero-initializing extack, as was done in commit 6347c5314cee ("nexthop: initialize extack in nh_res_bucket_migrate()"). Fixes: 833a1065eeb1 ("nexthop: Emit a notification when a nexthop group is reduced") Signed-off-by: Ido Schimmel Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260903080259.10378-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski commit fb3088dc5811a27dcc4775eaf44bd85ade265762 Merge: 641d03105cc0d2 2f37fba846c9fd Author: Jakub Kicinski Date: Fri Sep 4 15:16:28 2026 -0700 Merge tag 'ieee802154-for-net-2026-09-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan Stefan Schmidt says: ==================== pull-request: ieee802154 for net 2026-09-03 Zhiling Zou fixed a NULL deref when coming from a TUN device. Fan Wu fixed a UAF in the cc2520 driver. Chenguang Zhao fixed up some out of date comments in 6lowpan. David Carlier fixed a potential double free in the hwsim driver. Ibrahim Hashimov reworked the queuing in the RX path to fix a UAF on beacon and MAC frames. * tag 'ieee802154-for-net-2026-09-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan: mac802154: fix use-after-free of sdata via queued RX frames ieee802154: hwsim: serialize pib updates to fix double-free ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink ieee802154: cc2520: fix FIFOP work use-after-free net: 6lowpan: fix mismatched comments ==================== Link: https://patch.msgid.link/20260903093012.4032586-1-stefan@datenfreihafen.org Signed-off-by: Jakub Kicinski commit 654ae5d73c05bd2943d65636ce6cd0aa46e62f18 Merge: 3f17a52d47ed39 c96294afbcb573 Author: Linus Torvalds Date: Fri Sep 4 13:42:16 2026 -0700 Merge tag 'drm-fixes-2026-09-05' of https://gitlab.freedesktop.org/drm/kernel Pull drm fixes from Dave Airlie: "Lots of scattered fixes: nouveau has a bunch of display fixes for blackwell GPUs that should mean we light up monitors properly and fix some desktop rendering problems, amdgpu and intel display changes as usual. There also changes to the core pagemap, then the usual amouny of AI inspired validation fixes. core: - Fix drm_crtc_commit leak when PAGE_FLIP_EVENT is used dma-buf: - Publish the dma-buf only after copy_to_user succeeds - fix some kernel-doc warnings atomic-state-helpers: - set pixel_blend_mode to prop default on reset sysfb: - Fix integer overflow - fix constant comparison bug pagemap: - Prevent double migration of device pages - Reset migration page count on eviction retry - dma-unmap pages before handling migration errors - use after free fixes prime: - fix prime exports tracing amdgpu: - Fix for drm_amdgpu_info_device with mixed 64 bit kernel and 32 bit userspace - plane blend mode fixes - SR-IOV fix - GFX8 fix - MES queue reset fix - GPUVM fixes - DCN 6 warning fix - DCN 3.5/3.6 fix - DML fix - Backlight fix - Colorop fix - DC get_estimated_bw() fix - devcoredump fix - Userq fixes - APU PSP fix - Cursor fix amdkfd: - MES queue eviction fix - MQD debugfs fix xe: - oa uapi error handling fix - drm info message to report FLAT_CSS base misalignment i915: - Drop an accidentally duplicated panel fitter call in DP MST - Fix DDI clock programming for Cx0 and LT PHY - Fix PTL CDCLK handling at probe, causing a glitch - Fix dg2_power_well_count() return type - Fix a NULL pointer deref at forced probe - Fix selective fetch disable amdxdna: - out-of-bounds access fix - reject commands chains with no commands - handle chained mapping BO failures - refuse to flush an imported BO ethosu: - handle mmio mapping failures - handle storage modes only on hardware that supports it - fix job completion fence cleanup fastrpc: - Publish the dma-buf only after copy_to_user succeeds gud: - Improve TV modes and rotation handling nouveau: - use-after-free fixes - add missing scanline position support - HDMI and DP fixes - null pointer dereference fix - dmem accounting fixes for large folios - use write-combined maps for coherent qaic: - out-of-bounds access fix tegra: - Add blend mode properties virtio: - exit path and error handling fixes * tag 'drm-fixes-2026-09-05' of https://gitlab.freedesktop.org/drm/kernel: (83 commits) drm/xe/vram: report FLAT_CCS base misalignment MAINTAINERS, mailmap: use Aditya Garg's linux.dev account drm/amd/display: use plane color_mgmt_changed to track colorop changes drm/amdgpu/userq: fix struct drm_amdgpu_info_device padding for 32bit compile drm/amd/display: Fix cursor disable with horizontally split planes drm/amdgpu/userq: dont overwrite the error of subsequent map call drm/amdgpu: Skip accessing psp rum time db for APUs drm/amdgpu: update the fw version for gfx12 userqueues drm/amdgpu: update the fw version for gfx11 userqueues drm/amdgpu: fix byte/dword unit mismatch in coredump IB dump drm/amdkfd: fix scope of mqd_mgr dereference in pqm_debugfs_mqds drm/amd/display: fix division by zero in get_estimated_bw() drm/amd/display: use halving distribution for all encode-to-linear curves drm/amd/display: Fix backlight control for luminance-capable OLED drm/amd/display: Remove const Qualifier From Non-Pointer Fields drm/amd/display: Set gpuvm min page size to 4K on dcn35/36 drm/amd/display: Fix DCN5/6 DML2 compilation warnings drm/amdgpu: fix Idle BOs list in VM debugfs status info drm/amdgpu: use AMDGPU_GPU_PAGE_SHIFT instead of PAGE_SHIFT drm/amdgpu: Update queue reset support version ... commit 3f17a52d47ed39c89cc8429307cf246e781ec979 Merge: 408802f1e61dad 5445d641996269 Author: Linus Torvalds Date: Fri Sep 4 13:32:46 2026 -0700 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "Nothing Earth-shattering, but worthwhile fixes nonetheless: - Disable interrupts during page-table walk in show_pte() - Fix kexec_file_load() with 52-bit capable kernels on machines without 52-bit addressing - Fix MIDR matching in CPU errata handling for KVM guests - Avoid reading MTE-specific ID registers when MTE support is disabled" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Don't read GMID_EL1 when MTE is disabled arm64: errata: pass REVIDR when matching target implementation CPUs arm64: trans_pgd: clone only the linear map that exists at runtime arm64: mm: Fix the lockless page-table walk in show_pte() commit 408802f1e61dad400ed5d2504165579189cc183f Merge: 986c24e0fe44f8 dc173b37415e8f Author: Linus Torvalds Date: Fri Sep 4 13:27:58 2026 -0700 Merge tag 'ceph-for-7.3-rc2' of https://github.com/ceph/ceph-client Pull ceph fixes from Ilya Dryomov: "A small fixup for the new nearfull_sync mount option, a potential use-after-free fix (marked for stable) and a patch that eliminates the last use of PageWriteback macro in the tree" * tag 'ceph-for-7.3-rc2' of https://github.com/ceph/ceph-client: ceph: apply nearfull_sync option on remount libceph: remove pinning assertion in ceph_msg_data_iter_next() ceph: lock mutex in ceph_mds_check_access() commit d80e12156f1fd490adf29a8d28489725a3ac817a Author: Steven Rostedt Date: Fri Sep 4 15:16:41 2026 -0400 ring-buffer: Use a macro for static buffer bits Instead of hard coding 30 for the number of bits used for the static buffer ids in two places, create a macro. This way if it changes in the future, it will change in all the locations that use it. Link: https://patch.msgid.link/20260904151641.17eae0aa@gandalf.local.home Signed-off-by: Steven Rostedt commit 5cbea500775dd1944995f23320af030b9b24b24b Author: Steven Rostedt Date: Fri Sep 4 14:49:02 2026 -0400 tracing: Fix comment in tracing_buffers_splice_read() The comment about returning an error if the read fails on the first iteration is slightly incorrect. It makes it sound like the only reason it could fail on a later iteration is if the subbuf order changed. That is incorrect, it could also fail if the length passed in was not a multiple of the subbuf size. Fix the comment. Link: https://lore.kernel.org/all/20260904143527.40e73d36@gandalf.local.home/ Link: https://patch.msgid.link/20260904144902.506862a1@gandalf.local.home Fixes: dae8dda341d2 ("tracing: Fix subbuf resize races with trace_pipe_raw readers") Signed-off-by: Steven Rostedt commit c843fd3c73c94cb90b01c6bfe8d83796e652864d Author: Vincent Donnefort Date: Fri Sep 4 17:44:50 2026 +0100 ring-buffer: Prevent truncation of nr_pages / nr_subbufs Although ring_buffer_per_cpu::nr_pages is defined as unsigned long, it is capped to 32-bits in a few places, limiting the operations possible on a very large buffer. Use `unsigned long` where appropriate and prevent truncation of values using nr_pages (or nr_subbufs). While at it, subbuf_size must be at least `unsigned int`. Note that persistent, remote and user-mapped ring buffers are capping the number of pages to 30 bits already, making "int" safe in many places. Link: https://patch.msgid.link/20260904164450.1345852-5-vdonnefort@google.com Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt commit f2b2b645595c82b4e824880f6cb987e077a8da19 Author: Vincent Donnefort Date: Fri Sep 4 17:44:49 2026 +0100 ring-buffer: Cap static ring buffer nr_pages Static ring buffers (i.e. persistent, user-mapped and remote) rely on the bpage::id field. The number of pages for those ring buffers must fit into that variable. Enforce this limit on ring buffer creation or user-mapping. While at it, prevent nr_pages underflow when allocating a persistent buffer. Link: https://patch.msgid.link/20260904164450.1345852-4-vdonnefort@google.com Fixes: be68d63a139b ("ring-buffer: Add ring_buffer_alloc_range()") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt commit dae8dda341d2d9034a90d59e8a7d502e1263813f Author: Vincent Donnefort Date: Fri Sep 4 17:44:48 2026 +0100 tracing: Fix subbuf resize races with trace_pipe_raw readers 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 commit 519f858317afc52e986817ad63fd68172dd38b6c Merge: 5e8c349bc8d790 e615b9fd4d9df6 Author: Alexei Starovoitov Date: Fri Sep 4 12:24:25 2026 -0700 Merge branch 'misc-bug-fixes-part-4' Kumar Kartikeya Dwivedi says: ==================== Misc bug fixes - part 4 A set of miscellaneous fixes for bugs reported by Nicholas, and GPT-5.6 when analyzing those fixes, batched together again. See commit logs for details. Related rhtab fixes from Yuan Chen and Nuoqi Gui have been folded into the series. ==================== Link: https://patch.msgid.link/20260904104203.345917-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit e615b9fd4d9df602030d9b57a5eca206abbb0aff Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 12:41:59 2026 +0200 selftests/bpf: Test inner map identities in callbacks Add load-only timer_mim coverage for inner map identities propagated through nested timer and bpf_for_each_map_elem() callbacks. The negative case initializes a timer in the second inner map with the map saved from the first inner map timer callback. The positive case pairs the timer value with the map supplied to the same for-each callback. Without the verifier fix, the mismatched-map program is accepted while the same-map control is rejected. Preserving map_uid reverses both verdicts. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904104203.345917-9-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit b90c5d770dad910fb89e6c1b15052a8a1e8db752 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 12:41:58 2026 +0200 bpf: Preserve inner map identity in callback frames 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 commit 9dcddf30ac1a14f18c3221db9292bcaa0735ee2f Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 12:41:57 2026 +0200 selftests/bpf: Test imprecise scalar kptr stores Add a verifier regression where an imprecise zero scalar reaches a kptr store first and a nonzero scalar reaches the same instruction on a second path. Without the corresponding verifier fix, the second path is pruned and the program is unexpectedly accepted. With the fix, the scalar range is compared and the invalid store is rejected. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904104203.345917-7-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit ecdc5043794c9184aa8e6c814603899479c46b35 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 12:41:56 2026 +0200 bpf: Mark NULL kptr stores precise 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 commit 2b97956af60810cd382b86b9ce9aea421b889861 Author: Nuoqi Gui Date: Fri Sep 4 12:41:55 2026 +0200 selftests/bpf: Test rhtab kptr cancellation semantics Resizable hash-map updates and deletions must not perform full special-field destruction in their caller context. In particular, a referenced kptr must remain attached to the allocation until the memory allocator destructor can release it safely. Add separate coverage for both affected paths. The update test stores a task kptr, replaces the ordinary value bytes with BPF_EXIST, and verifies that the kptr survived. The delete test removes an element and exchanges its kptr through the still-valid map-value pointer before the allocation is reclaimed. Both cases observe a NULL kptr when rhtab uses bpf_obj_free_fields(). They recover and release the reference after rhtab switches to cancellation semantics. Signed-off-by: Nuoqi Gui [ kkd: Split update and delete coverage and rewrote the commit log ] Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904104203.345917-5-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 65cc95eba9e8b46312cac38c227473605a4b996a Author: Nuoqi Gui Date: Fri Sep 4 12:41:54 2026 +0200 bpf: Cancel special fields when recycling rhtab elements rhtab_map_update_existing() and rhtab_delete_elem() call bpf_obj_free_fields() when replacing or deleting a value. These map operations can run from BPF programs in NMI context, where releasing a referenced kptr or another complex field is not generally safe. Array and hash maps avoid that problem by cancelling only the asynchronous fields which can be stopped safely in the caller context. Other ownership state remains attached to the allocation until its memory allocator destructor performs the final cleanup. Use bpf_obj_cancel_fields() for the corresponding rhtab paths as well. This cancels timers, workqueues, and task work while allowing rhtab_mem_dtor() to release referenced kptrs when the allocation is eventually destroyed. Fixes: 6905f8601298 ("bpf: Allow special fields in resizable hashtab") Signed-off-by: Nuoqi Gui Acked-by: Mykyta Yatsenko [ kkd: Rebased, used direct helper calls, and rewrote the commit log ] Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904104203.345917-4-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit dbf6806dc81553edbab72fcec9a6d637dedff2f4 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 12:41:53 2026 +0200 selftests/bpf: Test timer field on recycled rhtab element Exercise the rhtab special-field lifecycle with the sequence from the original report. A bpf_for_each_map_elem() callback deletes the sole element, then initializes and arms a timer through the callback value pointer while it remains valid. Use a one-element map and pin userspace and BPF execution to one CPU. Repeated delete-and-replace cycles drain the per-CPU allocator cache, and periodic RCU synchronization makes the deleted units available for recycling. After each replacement, a second BPF program calls bpf_timer_cancel() on its value. A successful cancellation proves both that a timer-bearing unit was recycled and that insertion preserved the timer field. Without the fix, insertion clears that field and cancellation keeps returning -EINVAL. A long expiration keeps the timer callback out of the test, so the regression is detected without accessing freed memory. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904104203.345917-3-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 5df46ddcb7b36878c1b691e9057a0509042a2567 Author: Yuan Chen Date: Fri Sep 4 12:41:52 2026 +0200 bpf: Preserve special fields in recycled rhtab elements rhtab_map_update_elem() initializes special fields after obtaining an element from bpf_mem_cache_alloc(). The allocator can return a fresh, zeroed unit, or recycle one from its RCU-pending lists before the registered destructor has run. A BPF program can retain a map-value pointer after deleting its element and initialize and arm a timer through that pointer. If the deleted unit is recycled, check_and_init_map_value() clears the only pointer to the timer. Neither a later deletion nor rhtab_mem_dtor() can then cancel it, and the callback can run with its key and value pointing into freed memory. Do not reinitialize special fields on insertion. Fresh allocator units are already zeroed. For recycled units, the special fields are ownership state that must remain visible to the eventual destructor. copy_map_value() already skips those fields, matching the non-preallocated hash-map path and the lifecycle established by commit 275c30bcee66 ("bpf: Don't reinit map value in prealloc_lru_pop"). Fixes: 6905f8601298 ("bpf: Allow special fields in resizable hashtab") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Yuan Chen [ kkd: Split out the fix and rewrote the commit log ] Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904104203.345917-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 21f027016b1290d13c30b198ae7a00e6b3d1d5a5 Author: Runyu Xiao Date: Wed Sep 2 15:05:42 2026 +0800 mtd: rawnand: cadence: Initialize IRQ state before requesting IRQ The Cadence NAND interrupt handler uses both the IRQ lock and completion object. Registering the IRQ before initializing them leaves a window in which a pending interrupt can access uninitialized synchronization state. Initialize them before registering the handler. Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Signed-off-by: Miquel Raynal commit 68fe2faf5c69d0e21f94cd695d28f0ba677d484f Author: Mehmet Fide Date: Tue Sep 1 09:39:07 2026 +0200 mtd: rawnand: vf610_nfc: fix false bitflips on reads of erased pages When the ECC engine fails to decode a page, the driver re-reads the OOB area with the engine bypassed, but runs the erased-page check for the data area on the buffer left in the controller SRAM by the failed transfer. That buffer does not hold what is on the flash: the failing engine writes a bogus single-bit "correction" into it. In the 60-byte ECC mode the all-0xff content of an erased page always decodes to the same error location, so every erased page shows one stale zero bit at data offset 0x5FD, which the erased-page check then reports as a corrected bitflip. Edward Karpicz discovered this behaviour and identified the offset on a Colibri VF61; the analysis and the fix build on his finding. Measured with an instrumented driver on a Colibri VF50 (MX30LF1G18AC, 32-bit ECC): reading a 126 MiB partition with nanddump increased the corrected counter by 18035, exactly one per erased page, while raw reads of the same pages return clean 0xff. A v4.4 kernel on the VF61 (MX30LF4G28AC) accumulates the same false counts, so the behaviour follows the controller rather than the chip or the driver generation. Neither the Vybrid reference manual nor the published mask set errata (VFXXX_2N02G) document it. The 45-byte ECC mode is not affected. Restoring the known byte is not enough: on pages that fail to decode with content other than all-0xff the engine writes its correction wherever the syndrome points (measured at a different offset on such a page), so the check has to run on what the flash holds. Re-read the data area with the ECC engine bypassed, exactly as already done for the OOB area. The corrected counter then stays at zero on both boards. Reported-by: Edward Karpicz Link: https://community.toradex.com/t/colibri-vf50-vf61-on-the-current-bsp-mainline-u-boot-v2026-07-and-linux-6-18-lts/30735 Signed-off-by: Mehmet Fide Signed-off-by: Miquel Raynal commit 37adc9c5789c76db3b1ee7aeec3999b8503020d0 Author: Mehmet Fide Date: Tue Sep 1 09:39:06 2026 +0200 mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of OOB The controller transfers 64 spare bytes per page and the driver only implements the matching 64-byte ECC layout, so attach_chip() shrinks mtd->oobsize when the chip provides more. That clamp does not survive: nand_scan_tail() runs nanddev_init() after ->attach_chip(), and it restores mtd->oobsize from the memory organization, which still holds the value detected from the chip. The driver then transfers writesize plus the chip's full OOB size, the hardware ECC parity ends up at a different offset than the layout the controller was set up for, and every ECC-protected read fails with -EBADMSG. Measured on a Colibri VF61 (MX30LF4G28AC, 2048-byte pages, 112 bytes of OOB): with the clamp lost, UBI cannot read the erase counter headers of the pages U-Boot has just written, and the on-flash bad block table written by an older kernel reads back with ECC errors, so the board does not boot. Kernels before commit a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") are not affected because nothing overwrote the clamp there, which is why the same chip works with a v4.4 kernel and with U-Boot, whose copy of this driver has no memory organization to restore the value from. Edward Karpicz reported that the clamp no longer takes effect on this chip; see the link below. Instead of modifying the memory organization, keep the detected OOB size and give the driver its own mtd_ooblayout_ops: the same layout the NAND core uses for large pages, but computed on the first 64 OOB bytes instead of the whole OOB, so the ECC bytes stay where U-Boot and the old kernels put them. The data paths transfer writesize plus those 64 bytes, as the controller always has. Since mtd->oobsize now reports the chip's real spare size, fill the tail of oob_poi with 0xff after the 64 transferred bytes on ECC page reads: the core may copy the full mtd->oobsize from it, which would otherwise expose whatever the buffer held before. 0xff also matches what a raw read returns from flash, since the write path only ever programs the first 64 spare bytes. Reported-by: Edward Karpicz Link: https://community.toradex.com/t/colibri-vf50-vf61-on-the-current-bsp-mainline-u-boot-v2026-07-and-linux-6-18-lts/30735 Suggested-by: Miquel Raynal Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") Cc: stable@vger.kernel.org Signed-off-by: Mehmet Fide Signed-off-by: Miquel Raynal commit 636fe10d8f3559210ff63108a208d39ea2e9c3bd Author: Nuno Sá Date: Mon Aug 31 16:07:18 2026 +0100 mtd: spinand: fix zero oobavail when no ECC engine is used Commit 00c15b78b4b4 ("mtd: spinand: Allow the case where there is no ECC engine") made the OOB free bytes count conditional on having an ECC engine so that probing would not fail when none is requested. However mtd->oobavail is still assigned from ret just after that block, and ret is 0 there, so the device ends up advertising no available OOB bytes at all. mtd_oobavail() returns mtd->oobavail for MTD_OPS_AUTO_OOB, so a zero value makes every automatic OOB access fail with -EINVAL. JFFS2 fares worse: it keeps its cleanmarker in the OOB area on NAND and refuses to mount outright, reporting "inconsistent device description". No ECC engine also means no ooblayout was ever installed, which would make the count return -ENOTSUPP, so install the same fallback layout the on-die path already uses before counting unconditionally. Fixes: 00c15b78b4b4 ("mtd: spinand: Allow the case where there is no ECC engine") Cc: stable@vger.kernel.org Signed-off-by: Nuno Sá Signed-off-by: Miquel Raynal commit b890e6163761ddb580cc74f43e15f8bbde15647e Author: Nuno Sá Date: Mon Aug 31 16:07:17 2026 +0100 mtd: spinand: fix NULL pointer dereference with no ECC engine When "nand-no-ecc-engine" is set in DT, nanddev_get_ecc_engine() takes the NAND_ECC_ENGINE_TYPE_NONE path and returns success while leaving nand->ecc.engine NULL. The SPI-NAND code nevertheless dereferences it unconditionally to test for a pipelined engine, so probing such a device oopses immediately. Rather than open-coding the test three times, add a nand_ecc_is_pipelined() helper to the NAND core that folds the NULL check into the integration comparison, and use it everywhere. Future callers then cannot reintroduce the problem. Fixes: f9d7c7265bcf ("mtd: spinand: Create direct mapping descriptors for ECC operations") Cc: stable@vger.kernel.org Signed-off-by: Nuno Sá Signed-off-by: Miquel Raynal commit 200c32e3cd53132fbf99f1e2a5751f556755cf6d Author: Menachem Adin Date: Thu Aug 27 08:11:56 2026 +0300 mtd: mtd_intel_dg: reset poll counter for each erase The non-posted erase polling counter is initialized only once per MTD erase request. Large requests therefore share the polling budget across all 4K erase commands and can fail with -ETIME even though no individual command timed out. Reset the counter for each 4K erase command so every operation gets the intended completion timeout. Cc: stable@vger.kernel.org Fixes: a1c940cbf505 ("drm/xe/nvm: add support for non-posted erase") Signed-off-by: Menachem Adin Signed-off-by: Alexander Usyskin Signed-off-by: Miquel Raynal commit 6903878d4654bdef4e08e38cdf1ae306ce7de5f9 Author: Julian Braha Date: Fri Sep 4 12:09:11 2026 +0100 ima: allow users to specify the pcr index with IMA_MEASURE_PCR_IDX The IMA_MEASURE_PCR_IDX option is currently not visible in the kconfig frontend, so it always uses its default, 10. This means that the 'range 8 14' is dead code, and users are unable to specify the pcr index value. In a previous discussion, Mimi explained that users should be able to use this config option to specify the pcr index. [1] Let's add a prompt for users to specify the pcr index, when EXPERT is enabled. This dead range was found by kconfirm, a static analysis tool for Kconfig. Link: https://lore.kernel.org/all/1feff118-4afa-4b9c-86f1-271a7a88208f@gmail.com/T/#mc4efa2491b4937eb7c9e532c29ffba516a70e662 [1] Signed-off-by: Julian Braha Signed-off-by: Mimi Zohar commit f76017a7663c4ce5e379f8a8d39f032bdb1fd865 Author: Jeff Layton Date: Tue Apr 14 07:18:05 2026 -0700 nfsd: fix handling of NFSEXP_PNFS in the netlink codepath The rework of how block layouts were checked moved the check for NFSEXP_PNFS out of nfsd4_setup_layout_type() and into the callers. That patch didn't account for the new call in nfsd4_setup_layout_type(). Cc: Christoph Hellwig Fixes: da9baa5470dc ("exportfs,nfsd: rework checking for layout-based block device access support") Cc: stable@vger.kernel.org Reported-by: Olga Kornievskaia Signed-off-by: Jeff Layton Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260414-pnfs-exp-fix-v1-1-9face14c16c2@kernel.org Signed-off-by: Chuck Lever commit 39b975ff208610301bc400460ec245caeffa4ee0 Author: Karl Mehltretter Date: Mon Aug 24 03:47:03 2026 +0200 mtd: cfi_cmdset_0001: shrink do_write_buffer() stack frame arm32 allmodconfig fails to build with gcc: drivers/mtd/chips/cfi_cmdset_0001.c:1883:1: error: the frame size of 1296 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] With MTD_MAP_BANK_WIDTH_32 a map_word is 32 bytes, and with KASAN_STACK every temporary gets its own redzoned slot. do_write_buffer() builds a map_word for each of the twelve commands it issues, and those temporaries dominate its frame. Issue the commands through a small noinline helper that takes the command as a plain value and builds the map_word in its own frame. The sequence of reads and writes to the chip is unchanged. The helper must not be inlined, and reusing one map_word local is not enough: clang cannot assume the callee does not observe the local, so it still returns each CMD() into a per-call-site temporary, and the frame grows (1760 -> 1824 bytes in cfi_intelext_writev(), into which clang inlines do_write_buffer()). Frame sizes with MTD_MAP_BANK_WIDTH_32 and KASAN_STACK: gcc 15.2 do_write_buffer() 1296 -> 520 clang 21 cfi_intelext_writev() 1760 -> 896 The helper itself takes 168 (gcc) / 160 (clang) bytes. Reported-by: Andy Shevchenko Closes: https://lore.kernel.org/all/20260408211407.2295175-1-andriy.shevchenko@linux.intel.com/ Suggested-by: Miquel Raynal Link: https://lore.kernel.org/all/87ik9cfm6g.fsf@bootlin.com/ Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Miquel Raynal commit 12b31d1acd20b3185bb5f0748db0cf6874c8e9d1 Author: Karl Mehltretter Date: Sun Aug 16 18:30:58 2026 +0200 mtd: core: call _get_device() with the master MTD __get_mtd_device() calls the master's _get_device() callback with mtd, which may be a partition. __put_mtd_device() passes the master. This breaks gluebi partitions because gluebi_get_device() uses container_of() and therefore requires the master MTD. Pass the master to _get_device(), matching _put_device(). Fixes: 46b5889cc2c5 ("mtd: implement proper partition handling") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Karl Mehltretter Signed-off-by: Miquel Raynal commit 26300879cd8e4612dce66bb8f6ff7cd35fcf3e59 Author: Karl Mehltretter Date: Sun Aug 16 18:30:27 2026 +0200 mtd: core: avoid double-free of OTP NVMEM device If factory OTP setup fails after the user OTP NVMEM device has been registered, mtd_otp_nvmem_add() unregisters the user device but leaves mtd->otp_user_nvmem set. On an error, the caller unregisters it again. For -EOPNOTSUPP, registration continues and normal teardown unregisters it again. Clear mtd->otp_user_nvmem after unregistering it. Fixes: e0489f6e221f ("mtd: core: fix error path for nvmem provider") Fixes: fe0b8213c012 ("mtd: core: Don't fail mtd_otp_nvmem_add() if OTP is unsupported") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Karl Mehltretter Signed-off-by: Miquel Raynal commit 63d6cace2c4a7f36c1cb44f1bb5e0f3ef19e5c7f Author: Han Xu Date: Thu Aug 13 08:07:24 2026 -0500 mtd: spinand: Enable QE on all dies The QUAD ENABLE (QE) bit is stored in a per-die configuration register on some SPI-NAND devices. When a device contains multiple dies, updating the QE bit only on the currently selected die can leave the remaining dies operating in non-quad mode.   Iterate over all targets and update the QE setting on each die during initialization to ensure consistent quad I/O operation across the entire device. Tested on ISSI IS38SMW04G8B. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by: Han Xu Signed-off-by: Miquel Raynal commit b5965c4221165045e19736794ca5f48ae3d67142 Author: Pei Xiao Date: Thu Aug 13 10:48:12 2026 +0800 mtd: block2mtd: Fix divide error when erase_size is zero The erase size is parsed from the "block2mtd" module parameter and can be set to zero. add_device() then evaluates if (size % erase_size) with a zero divisor, which triggers a divide error: divide error: 0000 [#1] PREEMPT SMP PTI RIP: 0010:add_device drivers/mtd/devices/block2mtd.c:296 [inline] RIP: 0010:block2mtd_setup2+0x592/0xda0 drivers/mtd/devices/block2mtd.c:459 Call Trace: block2mtd_setup+0x27/0xe0 drivers/mtd/devices/block2mtd.c:476 param_attr_store+0x214/0x310 kernel/params.c:589 module_attr_store+0x65/0x90 kernel/params.c:904 kernfs_fop_write_iter+0x3a4/0x540 fs/kernfs/file.c:345 ... Reject a zero erase size before performing the modulo operation so the existing "erasesize must be a divisor of device size" error path reports the invalid argument and frees the device. Fixes: ea6d833a3fdd ("mtd: block2mtd: check device size") Reported-by: syzbot+b320a4d5f65a61dbbf89@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/6a7b58ba.ac361c09.22ff0a.0045.GAE@google.com/ Suggested-by: Jörn Engel Cc: stable@vger.kernel.org Signed-off-by: Pei Xiao Signed-off-by: Miquel Raynal commit 5e8c349bc8d790fe031a4332e502f5d4f9878644 Author: Jiayuan Chen Date: Fri Sep 4 15:37:39 2026 +0800 selftests/bpf: Fix flaky bpf_nf test when random NAT port is 0 The bpf_nf test allocs a ct, sets snat and dnat with random addr and port via bpf_ct_set_nat_info(), then looks the ct up and checks the reply tuple against what was set. The port comes from bpf_get_prandom_u32() and can be 0. For bpf_ct_set_nat_info(), port 0 means "port not specified", so only the addr is mapped and the kernel keeps the original port. The check then compares that port with 0 and fails, which shows up as a flaky "Test for source natting" failure in CI [1][2]. Keep the random port in 1..65535 so it is always specified. [1] https://github.com/kernel-patches/bpf/actions/runs/33830002889/job/100893868791 [2] https://github.com/kernel-patches/bpf/actions/runs/33829976794/job/100893220999 Fixes: b06b45e82b59 ("selftests/bpf: add tests for bpf_ct_set_nat_info kfunc") Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260904073745.363314-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit c1e01ea35093777d59c12128d549ff5016c38cec Author: Zhang Yi Date: Fri Sep 4 18:41:41 2026 +0800 ASoC: codecs: ES8389: Prevent enable_count underflow in clk_core_disable To prevent enable_count underflow in clk_core_disable, I replaced the direct call to `es8389_set_bias_level(component, SND_SOC_BIAS_STANDBY);` in the code with a helper function. Signed-off-by: Zhang Yi Link: https://patch.msgid.link/20260904104141.3885-1-zhangyi@everest-semi.com Signed-off-by: Mark Brown commit 90feea391c64fc43bf44184fcf2b243ab991ce47 Author: Kees Cook Date: Thu Sep 3 11:05:58 2026 -0700 drm/amd/display: Fix harmless type mismatch in allocation While converting to kmalloc_obj() API, a type assignment mismatch was found between the desired struct dcn42_resource_pool and the allocated struct dcn401_resource_pool. Fix the type (it is harmless: the objects have the same contents and size). Signed-off-by: Kees Cook --- Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Simona Vetter Cc: Dan Wheeler Cc: Roman Li Cc: Ovidiu Bunea Cc: Charlene Liu Cc: Leo Chen Cc: Ivan Lipski Cc: Gaghik Khachatrian Cc: Cc: commit cff381508c1826ed93f7291372c81a50474d5565 Author: Shuming Fan Date: Fri Sep 4 15:58:34 2026 +0800 ASoC: rt722: fix uninitialized stream_config->type The stream_config variable was not initialized before being passed to sdw_stream_add_slave(). This may cause unexpected behavior when configuring the SoundWire stream. Signed-off-by: Shuming Fan Link: https://patch.msgid.link/20260904075835.130778-1-shumingf@realtek.com Signed-off-by: Mark Brown commit 0e17e50b993043cf3e21512a43ca63d176b46459 Author: Shuming Fan Date: Fri Sep 4 15:58:26 2026 +0800 ASoC: rt721: fix uninitialized stream_config->type The stream_config variable was not initialized before being passed to sdw_stream_add_slave(). This may cause unexpected behavior when configuring the SoundWire stream. Signed-off-by: Shuming Fan Link: https://patch.msgid.link/20260904075826.130751-1-shumingf@realtek.com Signed-off-by: Mark Brown commit c966210ed5f218d0297e94fb1002fba59e831c64 Author: Shuming Fan Date: Fri Sep 4 15:58:18 2026 +0800 ASoC: rt1318: fix uninitialized stream_config->type The stream_config variable was not initialized before being passed to sdw_stream_add_slave(). This may cause unexpected behavior when configuring the SoundWire stream. Signed-off-by: Shuming Fan Link: https://patch.msgid.link/20260904075818.130215-1-shumingf@realtek.com Signed-off-by: Mark Brown commit 2c68c4a0e57063a30a8139fa8bcb689323a45f16 Author: Shuming Fan Date: Fri Sep 4 15:58:10 2026 +0800 ASoC: rt1320: fix uninitialized stream_config->type The stream_config variable was not initialized before being passed to sdw_stream_add_slave(). This may cause unexpected behavior when configuring the SoundWire stream. Signed-off-by: Shuming Fan Link: https://patch.msgid.link/20260904075810.121467-1-shumingf@realtek.com Signed-off-by: Mark Brown commit 0a9bce8a4ff8357f3b0022e9aeee5db3e9326de5 Author: Shuming Fan Date: Fri Sep 4 15:57:57 2026 +0800 ASoC: rt712: fix uninitialized stream_config->type The stream_config variable was not initialized before being passed to sdw_stream_add_slave(). This may cause unexpected behavior when configuring the SoundWire stream. Signed-off-by: Shuming Fan Link: https://patch.msgid.link/20260904075757.108427-1-shumingf@realtek.com Signed-off-by: Mark Brown commit 4e3bd70facac5b7c412271d0e9cd6c18a3cef6c6 Author: Shuming Fan Date: Fri Sep 4 15:57:37 2026 +0800 ASoC: rt766: fix uninitialized stream_config->type The stream_config variable was not initialized before being passed to sdw_stream_add_slave(). This may cause unexpected behavior when configuring the SoundWire stream. Signed-off-by: Shuming Fan Link: https://patch.msgid.link/20260904075737.86525-1-shumingf@realtek.com Signed-off-by: Mark Brown commit 986c24e0fe44f844b44d365b71ce831947f50298 Merge: 36ec09e2637c34 9cdc7e6dc7a99a Author: Linus Torvalds Date: Fri Sep 4 09:25:38 2026 -0700 Merge tag 'hid-for-linus-2026090401' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Benjamin Tissoires: - hid-hyperv build fixes on certain configs (Jiri Kosina) - HID-BPF fix and selftests now that the bpf verifier is more restrictive (Benjamin Tissoires) - Some AI detected fixes for OOB, errors and validation (Ibrahim Hashimov, Shen Yongchao, Wei Jie Law) - various device fixes (Dave Carey and Vadim Klishko) * tag 'hid-for-linus-2026090401' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: bpf: serialize device reference release in struct_ops destroy path HID: rmi: fix OOB access with undersized RMI reports selftests/hid: prepare test_rdesc_fixup_get_data_overflow for the new verifier selftests/hid: Add a test to ensure we can write fields in hid_device HID: bpf: mark struct hid_device as safe BPF pointer HID: wacom: validate report length in wacom_intuos_pro2_bt_irq HID: multitouch: Fix stale MT slots when contact count drops to zero HID: i2c-hid: Add a quirk for a Cirque I2C device. HID: hyperv: make pointer arithmetics understandable for FORTIFY_SOURCE HID: hyperv: fix build breakage with certain configs commit 36ec09e2637c3430acb8ec8fc3c303d9f1a24837 Merge: 3e66602704746d 3b26ceef88c110 Author: Linus Torvalds Date: Fri Sep 4 09:17:05 2026 -0700 Merge tag 'sound-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of small fixes since 7.3-rc1. Quite a few fixes are for ALSA core for issues that have been detected by the things you know well. Additionally a series of hardening for runtime PM, and usual quirk updates, and some other misc driver fixes are included. Core: - Fixes for PCM races - UMP parser NULL dereference fix - Fix error handling in rawmidi ioctl USB- and HD-audio: - Implement missing runtime PM guards across multiple interfaces - Fix for OOB access in US-122L MIDI driver - Double-free fix for CAIAQ driver - Quirks for HD-audio Realtek & Cirrus codecs, Conexant S3-resume, USB Audient devices Others: - Fix of logical mistakes in dummy driver mixer and selftest code - Lock init fix in the legacy harmony driver" * tag 'sound-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (23 commits) ALSA: caiaq: Fix potential double-free at error path selftests/alsa: Fix the step check for INTEGER controls ALSA: hda/realtek: Fix cold-boot headset misdetection on Acer Aspire A515-57G ALSA: rawmidi: Return the error from snd_rawmidi_input_params() ALSA: ump: do not touch legacy_rmidi before it exists ALSA: hda/cs420x: Add CS4208 fixup for MacBookAir 7,2 ALSA: dummy: Report a change when one capture switch channel moves ALSA: usb-audio: Add mixer map quirk for Audient iD24 ALSA: hda: restore MFG widget enumeration after core split ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF ALSA: harmony: initialize locks before requesting IRQ ALSA: hda/realtek: Add quirk for VAIO VJS131 ALSA: pcm: Fix race between non-atomic ops and trigger-start ALSA: hda/realtek: Add quirk for Acer Predator PHN16-72 ALSA: hda/realtek: Add quirk for Lenovo Yoga Slim 9 14ILL10 ALSA: hda/conexant:Fix abnormal Mic/Speaker functionality on SN6140 after S3 wake-up ALSA: usb-audio: Guard FCP protocol transfers ALSA: usb-audio: Add PM guards to RME Digiface controls ALSA: usb-audio: Guard Scarlett2 protocol transfers ... commit 3e66602704746dd59543b62820a3b86ec19218a5 Merge: 58f93a4b73a21d 6d81700ad7c487 Author: Linus Torvalds Date: Fri Sep 4 09:00:03 2026 -0700 Merge tag 'ata-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fixes from Niklas Cassel: - Work around lost interrupts on Marvell 88SE61xx The Marvell AHCI controller requires you to clear interrupts in the opposite order from what is specified in the AHCI specification in order to not lose interrupts (Hajo) - Do not raise UNIT ATTENTION for depopulation commands The libata completion function unconditionally sets sense data with sense key UNIT ATTENTION (UA) for depopulation commands. The SCSI layer will fail a command when seeing this sense data. UA is only supposed to be raised if the capacity actually changed. Since these commands are currently only supported as passthrough commands, the user is expected to revalidate the device, which will detect a capacity change anyway. Thus drop the unconditional UA until a better solution has been implemented (Damien) * tag 'ata-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: libata-scsi: do not raise UA for storage element depopulation and restoration ata: ahci: work around lost interrupts on Marvell 88SE61xx commit 54d37bcf2f497140b9207968557ddb484058e749 Author: Zhongqiu Han Date: Tue Sep 1 22:36:35 2026 +0800 cpufreq: zero-initialize policy cpumask before sysfs publication cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(), i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate kmalloc_node() allocation, so its bitmap holds whatever the slab allocator left behind: cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */ kobject_init_and_add() /* policy%u/ appears in sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(cpu)) /* first valid value */ This leaves a window in which the sysfs attributes are already reachable while policy->cpus is still garbage. show()/store() gate on policy_is_inactive(), i.e. cpumask_empty(policy->cpus), so a non-zero bitmap makes them run the attribute callbacks on a policy that is not initialized yet. Fix this by using zalloc_cpumask_var() for policy->cpus. Fixes: 2fc3384dc75b ("cpufreq: Initialize policy->kobj while allocating policy") Cc: All applicable Signed-off-by: Zhongqiu Han Acked-by: Viresh Kumar Link: https://patch.msgid.link/20260901143635.4106960-1-zhongqiu.han@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki commit d7dbdd2ee01e12211046d4a535623ac732b749fb Author: Masami Hiramatsu (Google) Date: Fri Sep 4 08:25:04 2026 +0900 tracing: Fix to avoid creating trace instances with duplicate names Since commit e645535a954a ("tracing: Add option to use memmapped memory for trace boot instance") changed trace_array_get_by_name() to trace_array_create_systems(), enable_instances() does not reuse the same name instance. Therefore, if an administrator mistakenly specifies multiple `trace_instance=` options with duplicate names, all are created but only the first is accessible via tracefs. Check whether an instance with the same name already exists before creating a new one, and reject duplicates with a warning. Link: https://patch.msgid.link/178847790399.283263.5313150997200138426.stgit@devnote2 Fixes: e645535a954a ("tracing: Add option to use memmapped memory for trace boot instance") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt commit 58f93a4b73a21d1c54457e4ff654d60029464c76 Merge: 421066905cbcec b5ec6c462aab10 Author: Linus Torvalds Date: Fri Sep 4 08:42:14 2026 -0700 Merge tag 'ksmbd-for-7.3-rc2-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/smb Pull smb server fixes from Namjae Jeon: - Fix a tree connection use-after-free in smb2_tree_connect() by balancing references across concurrent connect, disconnect, and session logoff paths. - Validate source and target ranges in COPYCHUNK requests before range locking and copy operations. - Fix an oplock break notification UAF by acquiring a connection reference under ksmbd_inode lock and releasing it after the notification work completes. - Fix the sparc build by using an unsigned int for the atomic work state, ensuring xchg() uses a supported four-byte operation. * tag 'ksmbd-for-7.3-rc2-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/smb: ksmbd: fix tree connection use-after-free in smb2_tree_connect() ksmbd: validate COPYCHUNK source and target ranges ksmbd: fix use-after-free in oplock break notification ksmbd: fix sparc build with atomic work state commit d599822bdb66aeec5ec76297b0fc6efaaeefe07c Merge: 786262be6048de f47190b08b71e8 Author: Paolo Bonzini Date: Fri Sep 4 17:34:28 2026 +0200 Merge tag 'kvm-s390-master-7.3-1' of https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD KVM: s390: Misc fixes A bunch of fixes to bugs found in the past weeks. commit 421066905cbceca1f78cba5f7d92b4980317ab2b Merge: 65119e86fe463c 0c4256196b3a10 Author: Linus Torvalds Date: Fri Sep 4 08:24:09 2026 -0700 Merge tag 'probes-fixes-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull probes fixes from Masami Hiramatsu: - Protect kprobe_blacklist with RCU RCU-protect kprobe_blacklist and use kfree_rcu() to prevent UAF races during module unloading and enable safe atomic lookups. - Fix multi-probe field use-after-free Duplicate field and type strings on trace_probe_event to prevent UAF when freeing primary probe - Fix probe BTF member lookup: Check the containing inner struct/union kflag when resolving anonymous members to ensure correct bitfield offset calculation Prevent unnamed bitfields from being pushed to anon_stack in btf_find_struct_member(), avoiding false lookup errors Fix code block indentation in get_bitoffset_of_field() - uprobes error pointer safety Guard free_trace_uprobe() with IS_ERR_OR_NULL() to avoid crashing during automatic cleanup when an error pointer is returned * tag 'probes-fixes-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: kprobes: Protect kprobe_blacklist with RCU tracing/probes: Fix use-after-free on field name/type of events with multiple probes tracing/probes: Fix code indent in get_bitoffset_of_field() tracing/probes: Fix BTF kflag check for anonymous struct member access tracing/probes: Fix anon_stack check for unnamed bitfields in btf_find_struct_member uprobes: guard trace cleanup against error pointers commit 65119e86fe463cdc96455539020fa75b02f2cf91 Merge: bc35965f6940a9 2b0ac85512b7f6 Author: Linus Torvalds Date: Fri Sep 4 08:17:41 2026 -0700 Merge tag 'pmdomain-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm Pull pmdomain and cpuidle fixes from Ulf Hansson: "pmdomain providers: - mediatek: Fix Kconfig for Airoha power domains - qcom: Revert adding the missing power domains for Eliza cpuidle: - psci: Fix support for probe deferral by dropping the faux device - dt_idle_genpd: Free the original name allocation" * tag 'pmdomain-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm: cpuidle: dt_idle_genpd: kfree() the original name allocation pmdomain: airoha: fix unselectable AIROHA_CPU_PM_DOMAIN kconfig cpuidle: psci: Fix support for probe deferral by dropping the faux device Revert "pmdomain: qcom: rpmhpd: Add missing MXC and MMCX power domains for Eliza" commit 3e5d1bf4bd687beb2cb4e32a07af695455925588 Author: Runyu Xiao Date: Wed Sep 2 12:19:15 2026 +0800 cpufreq: initialize policy rwsem before sysfs publication cpufreq_policy_alloc() initializes policy->rwsem after kobject_init_and_add() has created the policy sysfs directory and its default attributes. A sysfs access can therefore reach a policy callback before the semaphore has been initialized. Initialize policy->rwsem before publishing the policy kobject so sysfs callbacks always see an initialized semaphore. Fixes: 2fc3384dc75b ("cpufreq: Initialize policy->kobj while allocating policy") Cc: All Applicable Link: https://lore.kernel.org/all/20260830155301.2713780-1-runyu.xiao@seu.edu.cn/ Reviewed-by: Zhongqiu Han Signed-off-by: Runyu Xiao Acked-by: Viresh Kumar Link: https://patch.msgid.link/20260902041915.3453421-1-runyu.xiao@seu.edu.cn Signed-off-by: Rafael J. Wysocki commit 41e6f03658adfa9df68642750b53a046f1abdea9 Merge: 6b31560c6bc1a8 9492baf8532ca2 Author: Alexei Starovoitov Date: Fri Sep 4 07:58:36 2026 -0700 Merge branch 'misc-bug-fixes-part-3' Kumar Kartikeya Dwivedi says: ==================== Misc bug fixes - part 3 A set of miscellaneous fixes for bugs reported by Nicholas, batched together again. See commit logs for details. Some of this was caught and posted by Ning before, but AI raised some concerns, so I'm resolving those issues and commandeering their patches now. Changelog: ---------- v1 -> v2 v1: https://lore.kernel.org/bpf/20260904063650.3877826-1-memxor@gmail.com * Fix GCC-BPF failure due to missed BTF emission for a type. ==================== Link: https://patch.msgid.link/20260904084325.52250-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 9492baf8532ca285c58b82a269acd7a57e205ae9 Author: Ning Ding Date: Fri Sep 4 10:43:21 2026 +0200 selftests/bpf: Reject refcount acquisition after RCU unlock Add a sleepable verifier test that loads a refcount-only local kptr in an explicit RCU read-side critical section, ends the section, and passes the pointer to bpf_refcount_acquire(). The loaded pointer never carries NON_OWN_REF. After RCU unlock it retains MEM_ALLOC while becoming PTR_UNTRUSTED, which previously made the kfunc argument check accept it as a live allocated object. Expect verification to reject the untrusted argument instead. Signed-off-by: Ning Ding [ kkd: Rewrote commit log ] Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904084325.52250-9-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 7441ee8276641bddaf1cba7bb75ef9c1458ceb3b Author: Ning Ding Date: Fri Sep 4 10:43:20 2026 +0200 bpf: Reject untrusted allocated-object pointers When the final RCU read-side critical section ends, a local kptr is demoted to PTR_UNTRUSTED but retains MEM_ALLOC. The pointer may be NULL or may refer to an object whose lifetime is no longer protected. type_is_ptr_alloc_obj() nevertheless recognizes any PTR_TO_BTF_ID with MEM_ALLOC as a live allocated object. In particular, a refcount-only local kptr never carries NON_OWN_REF, so it still passes the bpf_refcount_acquire() argument check after RCU protection ends. The kfunc can then dereference NULL or stale memory. Make type_is_ptr_alloc_obj() reject PTR_UNTRUSTED pointers. Since type_is_non_owning_ref() is based on the same predicate, graph kfunc arguments obey the same live-object requirement. Fault-protected reads of the demoted pointer remain valid: writes are already rejected, and read fixups use bpf_may_fault_on_deref() rather than this predicate. 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-8-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 6668ed271eaefaa63e686bdfbedaeb7b8e492722 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 10:43:19 2026 +0200 selftests/bpf: Reject graph kptr use after RCU unlock Add a sleepable verifier test that loads a graph-node local kptr in an explicit RCU read-side critical section, then passes its node to bpf_rbtree_remove() after the section ends. Before the verifier fix, the stale NON_OWN_REF flag makes the node look like a live borrowed reference and the program is accepted. After the fix, the pointer is demoted without NON_OWN_REF and the graph kfunc argument is rejected. Also exercise a graph kptr loaded while a spin lock provides implicit RCU protection. The pointer must be invalidated when the lock is released, which guards the required ordering between non-owning-reference invalidation and RCU demotion. Update the existing fault-protected load test state description. The post-unlock pointer no longer carries NON_OWN_REF, but remains readable because the load is rewritten to use BPF_PROBE_MEM. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904084325.52250-7-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit cd6f72d7f38e10aa82fcbc745a6a9e58e0d8e366 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 10:43:18 2026 +0200 bpf: Clear NON_OWN_REF after RCU protection ends A local kptr load of an object containing a graph node is marked MEM_RCU and NON_OWN_REF while protected by RCU. When the last RCU read-side critical section ends, invalidate_rcu_protected_refs() removes MEM_RCU and marks the pointer PTR_UNTRUSTED, but leaves NON_OWN_REF set. The stale flag lets graph kfunc argument checks continue treating the pointer as a live borrowed reference. In particular, bpf_rbtree_remove() can accept a pointer after its protection ended and return it as a new owning reference, even though the object may already have been freed. Clear NON_OWN_REF when an RCU-protected pointer is demoted. A spin lock also provides implicit RCU protection, so invalidate non-owning references before demoting RCU-protected pointers when releasing the lock. Otherwise the demotion would clear the flag before invalidate_non_owning_refs() can find and invalidate those aliases. The demoted pointer remains available for fault-protected reads. Exempt such reads from the allocated-object reference-state assertion; writes through a fault-prone pointer are already rejected, and bpf_may_fault_on_deref() makes the surviving loads use BPF_PROBE_MEM. 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: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904084325.52250-6-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 2edd8339468e4bf0feecb3398aaad25fd7b84286 Author: Ning Ding Date: Fri Sep 4 10:43:17 2026 +0200 selftests/bpf: Test borrowed refcount acquisition nullability Add verifier coverage for the distinction between owning and borrowed arguments to bpf_refcount_acquire(). An owning pointer returned by bpf_obj_new() must continue producing a non-NULL result without an extra check. An RCU-loaded local kptr is only borrowed, so a checked result must load successfully while passing an unchecked result to bpf_obj_drop() must be rejected as possibly NULL. Use a sleepable syscall program for the borrowed cases so the explicit RCU critical section is what permits the local kptr load. Without the verifier fix, the unchecked case is incorrectly accepted. With it, the verifier rejects the possibly NULL argument. Signed-off-by: Ning Ding [ kkd: Rewrote commit log ] Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904084325.52250-5-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit dc36739e5cc9f60485418a910b42bc95339218d2 Author: Ning Ding Date: Fri Sep 4 10:43:16 2026 +0200 bpf: Keep refcount_acquire nullable for borrowed RCU kptrs 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 commit 17487b31f479c85eda3685e8e44242358bd68f23 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 10:43:15 2026 +0200 selftests/bpf: Reject non-percpu values in percpu kptr fields Add verifier coverage for the two ways a non-percpu pointer can be stored in a __percpu_kptr field: a program-BTF local allocation returned by bpf_obj_new(), and a referenced kernel-BTF task_struct pointer. Without the verifier fix, both programs are unexpectedly accepted and the negative tests fail. Requiring MEM_PERCPU makes both programs fail verification with the expected invalid-kptr diagnostic. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904084325.52250-3-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 048029ba1c793f8cabc4ad5eea765da01903f8f1 Author: Kumar Kartikeya Dwivedi Date: Fri Sep 4 10:43:14 2026 +0200 bpf: Require MEM_PERCPU for percpu kptr stores map_kptr_match_type() treats perm_flags as the set of register type flags that a kptr field permits. Adding MEM_PERCPU to that set for BPF_KPTR_PERCPU does not require the source register to carry it, however. The subset test consequently accepts both a plain bpf_obj_new() allocation and a referenced kernel pointer into a __percpu_kptr map field. Loads from the field are always marked MEM_PERCPU. Consumers then treat the stored value as the cookie returned by bpf_percpu_obj_new(): per-CPU pointer helpers relocate it, and map teardown selects the per-CPU free path. A plain allocation can therefore provide an arbitrary kernel read/write, while a kernel pointer can be relocated into an invalid address or sent through a missing destructor. Require the source MEM_PERCPU flag to match the destination field kind. This preserves valid bpf_percpu_obj_new() stores and rejects both the program-BTF and kernel-BTF variants. Fixes: 36d8bdf75a93 ("bpf: Add alloc/xchg/direct_access support for local percpu kptr") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260904084325.52250-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit d31fbbade43f880b7e59e2b3a72722fe2725d93f Author: Ju Nan Date: Fri Aug 21 10:47:57 2026 +0800 irqchip/stm32mp-exti: Fix the unit of the hwspinlock timeout HWSPNLCK_TIMEOUT is passed to hwspin_lock_timeout_in_atomic(), whose timeout argument is in milliseconds, not microseconds: atomic_delay += HWSPINLOCK_RETRY_DELAY_US; if (atomic_delay > to * 1000) return -ETIMEDOUT; So stm32mp_exti_set_type() asks for a 1 second timeout where the comment next to the macro says it wants 1 millisecond. The semaphore is polled with udelay() from a section that holds chip_data->rlock, a raw_spinlock_t, so preemption stays disabled for the whole wait on every configuration, PREEMPT_RT included. The hwspinlock core documents this explicitly: If the mode is HWLOCK_IN_ATOMIC (called from an atomic context) the timeout is handled with busy-waiting delays, hence shall not exceed few msecs. Fixes: 5257169ade8c ("irqchip/stm32-exti: Use the hwspin_lock_timeout_in_atomic() API") Signed-off-by: Ju Nan Signed-off-by: Thomas Gleixner Reviewed-by: Radu Rendec Reviewed-by: Antonio Borneo Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260821024756.24927-2-junan76@163.com commit e67091609cf85962f64391c1b0f93d4cbfcd4e22 Author: caina Date: Fri Aug 21 17:17:20 2026 +0800 Revert "irqchip/mbigen: Fix mbigen node address layout" This reverts commit 6be6cba9c4371d27f78d900ccfe34bb880d9ee20. Commit 6be6cba9c437 ("irqchip/mbigen: Fix mbigen node address layout") appears to cause a regression on Hi1616. On-board hns NIC has two ports, enahisic2i0 and enahisic2i1, both behind mbigen-v2. Port 0 works; port 1 cannot pass any traffic. Their interrupt pins fall on different mbigen nodes: enahisic2i0: pins 1152-1198 -> all in node 9 enahisic2i1: pins 1200-1246 -> node 9 (1200-1215) + node 10 (1216-1246) (nid = (hwirq - 64) / 128 + 1; pin 1215 = node 9, pin 1216 = node 10) /proc/interrupts shows the break happens exactly at the node boundary: enahisic2i1-rx0 pin 1200 count 102 <- node 9 enahisic2i1-rx5 pin 1215 count 1 <- node 9, last pin enahisic2i1-tx5 pin 1216 count 0 <- node 10, first pin enahisic2i1-rx6 pin 1218 count 0 <- node 10 ...all node 10 pins stay at zero. Port 0 (entirely node 9) is unaffected. Reverting the commit restores normal operation. The commit assumes CLEAR occupies a full 4 KB page at [0xa000, 0xb000) and collides with node 10, so node 10+ gets shifted by 0x1000. But get_mbigen_clear_reg() uses flat, chip-wide addressing -- it never multiplies by the node ID: *addr = (hwirq / 32) * 4 + REG_MBIGEN_CLEAR_OFFSET; /* 0xa000 */ Over the valid hwirq range [64, 1407], CLEAR only spans 0xa008-0xa0af (168 bytes). Node 10's registers are: TYPE: 0xa000-0xa00f (16 B) overlaps CLEAR by 8 B (0xa008-0xa00f) VEC: 0xa200-0xa3ff (512 B) no overlap with CLEAR Shifting the whole page moves VEC from 0xa200 to 0xb200. The hardware reads the event ID from the fixed silicon address 0xa200 on interrupt firing, but software wrote it to 0xb200 -- so the hardware gets an uninitialised value and the interrupt is lost. The only real overlap is 8 bytes of TYPE. It can only trigger when a single mbigen instance has devices on both node 1 (CLEAR 0xa008) and node 10 (TYPE 0xa008). On Hi1616 those nodes are on separate mbigen instances, so it never triggers. Fixes: 6be6cba9c4371d27f78d900ccfe34bb880d9ee20 ("irqchip/mbigen: Fix mbigen node address layout") Suggested-by: Marc Zyngier Signed-off-by: caina Signed-off-by: Thomas Gleixner Acked-by: Yipeng Zou Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260821091720.16665-1-caina@uniontech.com commit 5ad0af4f4367202b1bc71813052fe39b5116cdb9 Author: Andy Shevchenko Date: Mon Aug 17 12:33:24 2026 +0200 thermal: sysfs: switch to use scnprintf() to suppress truncation warning Switch the sysfs code to use scnprintf() to avoid warnings about potential truncation of the names of the sysfs attributes. We can't increase the buffer size because the size is the part of an ABI for some reason. Note, with the current size of buffer the affected attributes have a room for up to 1000 names, which ought to be enough for all cases. There is no functional change, as the same limitation was implied before. Fixes: c56f5c0342df ("Thermal: Make Thermal trip points writeable") Signed-off-by: Andy Shevchenko Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/20260817103324.1020212-1-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki commit a2628ce4ddb6873e35380a42396d17a66e704a1a Author: Haiyong Sun Date: Fri Sep 4 21:45:27 2026 +0800 perf build: Add clang and rust target flags for LoongArch Add missing CLANG_TARGET_FLAGS_loongarch and RUST_TARGET_FLAGS_loongarch so that perf can be built with clang and enable rust cross compilation. Cc: stable@vger.kernel.org Acked-by: Miguel Ojeda Acked-by: Dmitrii Dolgov <9erthalion6@gmail.com> Signed-off-by: Haiyong Sun Signed-off-by: WANG Rui Signed-off-by: Huacai Chen commit 9296375902579f9b0e456bbb76e5cf179e5a4e0b Author: Tao Cui Date: Fri Sep 4 21:45:13 2026 +0800 LoongArch: KVM: Fix TOCTOU race on pv_features In kvm_loongarch_cpucfg_set_attr() the check-then-set on kvm->arch.pv_features is lockless, so two vCPUs can race past the validation and set different values. Add a spinlock to protect it. Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao Signed-off-by: Tao Cui Signed-off-by: Huacai Chen commit 501514d6ebd2111c353a1296f25dbe22fbd64657 Author: Zeng Chi Date: Fri Sep 4 21:45:13 2026 +0800 LoongArch: KVM: Validate MSI data before routing it to EIOINTC 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 commit 27a9bfee3bbcb3cabb77797354f07e0e44e49831 Author: Zeng Chi Date: Fri Sep 4 21:45:13 2026 +0800 LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE, only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every other change. But the generic code allocates a zeroed memslot for every change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update, e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active memslot has arch.flags == 0. With both flags clear, fault_supports_huge_mapping() falls through to the alignment check on the HVA range alone, which no longer verifies that the GPA and HVA have the same offset within a PMD. A memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can then be mapped with PMD entries on read faults, and since kvm_map_page() aligns the gfn and the pfn independently, the guest ends up accessing the wrong host pages, exactly the "d -> f, e -> g" case described in the comment above the check. Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY, as the GPA, HVA and size are guaranteed to be unchanged for that case. Cc: stable@vger.kernel.org Fixes: 7ab6fb505b2a ("LoongArch: KVM: Optimization for memslot hugepage checking") Tested-by: Tao Cui Reviewed-by: Tao Cui Reviewed-by: Bibo Mao Signed-off-by: Zeng Chi Signed-off-by: Huacai Chen commit 40bdbb4bfa730400e8b383d6f5931f90aebb5f54 Author: Bibo Mao Date: Fri Sep 4 21:44:54 2026 +0800 LoongArch: KVM: Remove unused function kvm_arch_flush_remote_tlbs_memslot() Function kvm_arch_flush_remote_tlbs_memslot() is not called any more, so remove this API. Reviewed-by: Tao Cui Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen commit 910132bc7d72f26a8b288c2a38c32445a48d5be0 Author: Chaithanya Lagisetty Date: Fri Sep 4 21:44:54 2026 +0800 LoongArch: KVM: Fix resource leak in kvm_loongarch_env_init() error path kvm_loongarch_env_init() allocates the per-CPU kvm_context (vmcs) and kvm_loongarch_ops, registers the perf callbacks, and then registers the IPI/EIOINTC/PCH-PIC/DMSINTC KVM devices. If any of those device registrations fails, the function returned the error directly, leaving everything acquired so far in place: vmcs and kvm_loongarch_ops are never freed, the perf callbacks stay registered, and all previously registered KVM device operations remain registered. kvm_loongarch_init() propagates the errors without calling kvm_loongarch_env_exit(), so nothing else cleans up either. Unwind the error path in reverse order of registration, so that each failure only undoes what had actually been set up. Use the same helpers in kvm_loongarch_env_exit() to remove the device registrations during normal teardown as well. Cc: stable@vger.kernel.org Fixes: c532de5a67a7 ("LoongArch: KVM: Add IPI device support") Reviewed-by: Bibo Mao Signed-off-by: Chaithanya Lagisetty Signed-off-by: Huacai Chen commit 4af22177032ab2357bf551fbfcdebc8fd9f2502d Author: Chaithanya Lagisetty Date: Fri Sep 4 21:44:53 2026 +0800 LoongArch: KVM: Add unregister helpers for the KVM interrupt devices The IPI/EIOINTC/PCH-PIC/DMSINTC KVM devices each have a helper that registers their kvm_device_ops, but there is no counterpart to remove them, so a caller that needs to undo a registration has to open-code kvm_unregister_device_ops() with the matching device type. Add kvm_loongarch_unregister_{ipi,eiointc,pch_pic,dmsintc}_device() next to the existing register helpers. kvm_unregister_device_ops() is a no-op when the corresponding device type is not currently registered. No functional change, as there are no callers yet. Cc: stable@vger.kernel.org Suggested-by: Bibo Mao Reviewed-by: Bibo Mao Signed-off-by: Chaithanya Lagisetty Signed-off-by: Huacai Chen commit f7a1064cce3b100b54780c68529176232d8eb01e Author: Chaithanya Lagisetty Date: Fri Sep 4 21:44:53 2026 +0800 LoongArch: KVM: Free init resources if kvm_init() fails kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the perf callbacks, and then calls kvm_init(). If kvm_init() fails its result is returned directly, but since module_init() does not run the module_exit() stuff on failure, so kvm_loongarch_env_exit() is never called and those resources are leaked. So call kvm_loongarch_env_exit() when kvm_init() fails, matching the teardown-on-failure pattern used by riscv_kvm_init(). Cc: stable@vger.kernel.org Fixes: 2bd6ac687261 ("LoongArch: KVM: Implement kvm module related interface") Reviewed-by: Bibo Mao Signed-off-by: Chaithanya Lagisetty Signed-off-by: Huacai Chen commit 30419a0aa128135a81be917eaa3bd2f1a10c9ca3 Author: Tiezhu Yang Date: Fri Sep 4 21:44:43 2026 +0800 LoongArch: BPF: Fix off-by-one error for insn_is_cast_user() In the LoongArch BPF JIT code, the branch offset represents the number of instructions. An offset of 1 means the target of the "beq" is the current PC plus 1 instruction (PC + 4 bytes). This matches the exact same path as the sequential non-branch execution, the "or" instruction is always executed for the cast_user JIT arm in build_insn(). If the pointer is not NULL, there is no side effect. But if the pointer is NULL, it is incorrectly combined with the base address and turns into a non-zero address, meaning a zero arena offset no longer casts to NULL. Fix this by changing the branch offset from 1 to 2, which properly skips the "or" instruction and jumps directly to the "move_reg" instruction if the pointer is NULL, ensuring the destination register is safely cleared to 0. Cc: stable@vger.kernel.org Fixes: 4fdb5dd8aeba ("LoongArch: BPF: Implement bpf_addr_space_cast instruction") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen commit 72ce4b24676e8b3b75376c4c559dd81c1ac52d5a Author: Jérémy Jean Date: Fri Sep 4 21:44:43 2026 +0800 LoongArch: Avoid preempt count underflow without probe LoongArch uses break 11 for the breakpoint placed after an instruction that Kprobes executes out of line. Since userspace can issue the same break instruction, do_bp() can reach kprobe_singlestep_handler() when there is no current probe. The handler actually returns false in this case, but it first calls preempt_enable_no_resched(). The corresponding preempt_disable() is done by kprobe_breakpoint_handler() on a real Kprobe hit, so it has not run here. As a result, an ordinary userspace breakpoint (code 11) underflows the current task's preempt count. This also makes in_interrupt() return true until the task schedules. One visible consequence is the socket cgroup attribution: cgroup_sk_alloc() treats the allocation as interrupt context and assigns the socket to the root cgroup. A socket opened from the SIGTRAP handler can then avoid a BPF_CGROUP_INET_SOCK_CREATE policy attached to the task's own cgroup. Return as soon as kprobe_running() reports no active probe. The same check has appeared in [PATCH v10 2/4] of the original LoongArch Kprobes series, but was dropped before the feature reached mainline. Cc: stable@vger.kernel.org Fixes: 6d4cc40fb5f5 ("LoongArch: Add kprobes support") Link: https://lore.kernel.org/loongarch/1670575981-14389-3-git-send-email-yangtiezhu@loongson.cn/ Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Huacai Chen commit c3f2feace5e4f4b01b68b9f947b19adb4155c32e Author: Wentao Guan Date: Fri Sep 4 21:44:43 2026 +0800 LoongArch: Do not save/restore percpu base register in rethook trampoline The rethook trampoline saves $r21 ($u0), the percpu base, into its frame at entry and restores it at exit. Inbetween rethook_trampoline_handler() may schedule via preempt_enable_notrace(). If the task migrates to another CPU, the frame's $r21 holds the old CPU's percpu base, and restoring it poisons $r21 on the new CPU. Until the next user->kernel transition heals $r21, all this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) hit the wrong CPU's percpu area. Under kretprobe-heavy preemptible load this can corrupt scheduler and timer state: scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and CPUs parking in the idle loop with the constant timer never re-armed (hard lockup). Reproduces on a Loongson-3A6000 with kretprobes on VFS paths plus heavy file churn (OS install / unsquashfs). By convention $r21 always holds the current CPU's percpu base in kernel mode: SAVE_SOME() at exception entry reloads it only when coming from user mode, and RESTORE_SOME() restores it only when returning to user mode; the context-switch path never writes it. Therefore the live $r21 at trampoline exit is already correct, and nothing inbetween can change it legitimately (kernel C code cannot write a global register variable). The same flaw existed even in the pre-rethook kretprobe trampoline since v6.3; it was carried over when rethook replaced it. Drop both the save and the restore here. Drop the restore is enough to solve the issue, and drop the save is to keep the code tidy and no need to clear it. Cc: stable@vger.kernel.org # v6.3+ Fixes: 3f5536860086d ("LoongArch: Add kretprobes support") Assisted-by: Kimi:Kimi-K3 # debug and root-cause analysis Signed-off-by: Wentao Guan Signed-off-by: Huacai Chen commit 3e1b64bd8cd2bc15c514d90b3dd0a55c53302f3a Author: Anthony Iliopoulos Date: Fri Sep 4 21:44:43 2026 +0800 LoongArch: Remove unused setup_profiling_timer() function setup_profiling_timer() is not used by any code at this point. Since a default weak implementation exists, there is no need to still keep this arch-specific definition around. Remove it along with the now-redundant profile header includes. Signed-off-by: Anthony Iliopoulos Signed-off-by: Huacai Chen commit 20a9e97137caaa3fbb27f22f83a5ad80cbd03b01 Author: Hemanth Selam Date: Fri Sep 4 21:44:24 2026 +0800 LoongArch: Fix typo "avaliable" in comment of vmlinux.lds.S Correct "avaliable" to "available", reported by scripts/checkpatch.pl using the misspelling list in scripts/spelling.txt. It only touches the comments, no code changes. Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam Signed-off-by: Huacai Chen commit 63b6a48c951d63bf39d44603ada48a987ccf66eb Author: Nathan Chancellor Date: Fri Sep 4 21:44:23 2026 +0800 LoongArch: Do not select HAVE_RUST when KASAN is enabled After commit 2625480a1bf7 ("hardening: Default randstruct off with rust for better allmodconfig support"), which allows Rust to be enabled for allmodconfig, ARCH=loongarch allmodconfig starts failing with: error: kernel-address sanitizer is not supported for this target error: aborting due to 1 previous error make[4]: *** [rust/Makefile:741: rust/core.o] Error 1 For the same reason as the commit 84a0f7caafc679f7 ("ARM: Do not select HAVE_RUST when KASAN is enabled"), do not select HAVE_RUST when KASAN is enabled until the loongarch64-unknown-none-softfloat target in rustc supports KASAN. Cc: stable@vger.kernel.org Fixes: 90868ff9cade ("LoongArch: Enable initial Rust support") Acked-by: Miguel Ojeda Signed-off-by: Nathan Chancellor Signed-off-by: Huacai Chen commit 44caf1844a258534e891d2c4071b011097e19235 Author: Hemanth Selam Date: Fri Sep 4 16:07:31 2026 +0530 firmware: arm_scmi: Fix typo "upto" in comment Correct "upto" to "up to", reported by scripts/checkpatch.pl using the misspelling list in scripts/spelling.txt. Only touches comments, no code changes. Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam Link: https://patch.msgid.link/20260904103732.7320-1-hemanth.selam@gmail.com Signed-off-by: Sudeep Holla commit 6b31560c6bc1a8a7a70792c7b3ca4c1ea322063b Author: Eduard Zingerman Date: Fri Sep 4 01:33:25 2026 -0700 selftests/bpf: No non-NULL inference from an imprecise zero register Check that a register-form NULL check does not lift PTR_MAYBE_NULL on a path where the compared register is non-zero. W/o the previous patch the program is accepted. Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260904083325.2083493-8-eddyz87@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit 6aed0134d3cda6382385a734ae0158eb7df6b142 Author: Eduard Zingerman Date: Fri Sep 4 01:33:24 2026 -0700 bpf: Mark the zero register precise for a register-form NULL check check_cond_jmp_op() accepts "if rA rB" as a NULL check for a nullable pointer rA when rB is a scalar known to be zero, lifts PTR_MAYBE_NULL from rA in the corresponding branch and does not mark rB precise. Consider the following program: r0 = bpf_get_prandom_u32(); r6 = 1; /* the r6 == 0 path is explored first */ if (r0 == 0) goto 1f; r6 = 0; 1: r0 = bpf_map_lookup_elem(map, &0); /* absent, NULL at runtime */ if (r0 == r6) goto 2f; /* taken as a NULL check for r0 */ *(u8 *)(r0 + 0); /* verifier: map value; runtime: zero */ 2: return 0; The r6 == 0 path is explored first and the dereference is accepted. The r6 == 1 path is pruned at the checkpoint recorded for (1), so the comparison is never verified with a non-zero r6. At runtime a failed lookup returns NULL, NULL != 1 takes the non-NULL edge and the program dereferences a pointer that is zero. Fixes: 2f4cb53eed44 ("bpf: detect non null pointer with register operand in JEQ/JNE.") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260904083325.2083493-7-eddyz87@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit 836b2fe544a5e9b5ce116622cb36fba33838c6fd Author: Eduard Zingerman Date: Fri Sep 4 01:33:23 2026 -0700 selftests/bpf: Check that JMP32 pointer vs zero jumps are not predicted Add jmp32_ptr_vs_zero_jne: the fall-through of the 32-bit compare, which the verifier used to skip, contains an out of bounds map value access, hence w/o the previous patch the program is accepted. See previous patch for detailed description. Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260904083325.2083493-6-eddyz87@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit e51179a4e09846f8fd0f26a05068520de2b301bf Author: Eduard Zingerman Date: Fri Sep 4 01:33:22 2026 -0700 bpf: Don't predict JMP32 pointer vs zero comparisons Consider the following program: r1 = map_value; /* low 32 bits are zero at runtime */ r6 = 0xdead000000000000; if w1 != 0 goto l1; l0: r1 += r6; r2 = *(u64 *)(r1 + 0); exit; l1: r6 = 0; goto l0; At the moment is_branch_taken() reports the jump as always taken, because it does not distinguish between BPF_JMP and BPF_JMP32 comparisons when processing 'if w1 != 0 ...'. Fixes: cac616db39c2 ("bpf: Verifier track null pointer branch_taken with JNE and JEQ") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260904083325.2083493-5-eddyz87@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit bc412b3fb185540112fcc99ac91a14e57418d28e Author: Eduard Zingerman Date: Fri Sep 4 01:33:21 2026 -0700 selftests/bpf: Check the linked regs cap for the compared register linked_regs_too_many_regs checks that collect_linked_regs() ties at most LINKED_REGS_MAX registers for a single jump. Compare r5 instead of r0, so that the register the jump compares is itself the member that does not fit, and check that it comes out of the jump unlinked. W/o the previous patch env->{false,true}_reg{1,2} bring r5's id back and insn 7 is logged as "R5=scalar(id=1,...)". Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260904083325.2083493-4-eddyz87@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit 73a98f96811e2cb0f4210b1caa8cb322f92f2a2b Author: Eduard Zingerman Date: Fri Sep 4 01:33:20 2026 -0700 bpf: Don't resurrect a scalar id dropped by collect_linked_regs() check_cond_jmp_op() copies the compared registers into env->{false,true}_reg{1,2} before collect_linked_regs() runs and copies those snapshots back into both branch states afterwards. collect_linked_regs() records at most LINKED_REGS_MAX members of a linked registers group in the jump history and calls clear_scalar_id() for every member that does not fit. The compared register is not exempt from that. As a consequence, sync_linked_regs() might adjust ranges for more registers than bpf_bt_sync_linked_regs() can propagate precision to. Collect the linked registers before the snapshots are taken instead. This might lead to some unnecessary clear_scalar_id's, but from previous testing situations with many linked registers are extremely rare. Fixes: ec1d77cb0ee9 ("bpf: Use bpf_verifier_env buffers for reg_set_min_max") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260904083325.2083493-3-eddyz87@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit 6752b90ccfb378e311e428932facf37c8625abae Author: Eduard Zingerman Date: Fri Sep 4 01:33:19 2026 -0700 selftests/bpf: No non-NULL inference from unbounded offset pointers Check that a comparison against a pointer whose offset is not bounded from above does not make the verifier infer that a nullable pointer is not NULL, and that a bounded offset still does. W/o the previous patch the first test is accepted. Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260904083325.2083493-2-eddyz87@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi commit 67b529f521a6676cdfc78b91b0217d7eaa84216b 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 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 commit c96294afbcb5737da18229e788ca45a5d534abc5 Merge: 7f78fe856eb647 0e68c74e44da81 Author: Dave Airlie Date: Fri Sep 4 20:36:09 2026 +1000 Merge tag 'drm-xe-fixes-2026-09-03' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes A small fix on the error handling of an OA uapi and the addition of a drm_info message to report FLAT_CSS base misalignment. Signed-off-by: Dave Airlie From: Rodrigo Vivi Link: https://patch.msgid.link/apnVOtDv4WAIoj_X@intel.com commit 7f78fe856eb64723c436c636a1479c27608aaced Merge: 5ff6e2f8a779f7 13af55f71399f5 Author: Dave Airlie Date: Fri Sep 4 17:04:53 2026 +1000 Merge tag 'amd-drm-fixes-7.3-2026-09-03' of https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.3-2026-09-03: amdgpu: - SR-IOV fix - GFX8 fix - MES queue reset fix - GPUVM fixes - DCN 6 warning fix - DCN 3.5/3.6 fix - DML fix - Backlight fix - Colorop fix - DC get_estimated_bw() fix - devcoredump fix - Userq fixes - APU PSP fix - Cursor fix amdkfd: - MES queue eviction fix - MQD debugfs fix UAPI: - Fix for drm_amdgpu_info_device with mixed 64 bit kernel and 32 bit userspace Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patch.msgid.link/20260903174712.584320-1-alexander.deucher@amd.com commit da2ca406f45a6e21760243152ed8d2e8e72915c2 Author: Rik van Riel Date: Sat Aug 8 10:47:55 2026 -0400 wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver ieee80211_set_bitrate_mask() checks if the interface is running via ieee80211_sdata_running(), but it does not check if the interface is still present in the driver. When sdata is running but IEEE80211_SDATA_IN_DRIVER is not set, the call reaches drv_set_bitrate_mask() in driver-ops.h which hits wlan1: Failed check-sdata-in-driver check, flags: 0x0 WARNING: net/mac80211/driver-ops.h:884 at drv_set_bitrate_mask Syzkaller triggers this via wext SIOCSIWRATE ioctl. The Call Trace shows wext_ioctl_dispatch() in wext-core.c dispatching the ioctl, calling ioctl_standard_call() for SIOCSIWRATE, which calls cfg80211_wext_siwrate() in wext-compat.c. That builds a bitrate mask and calls rdev_set_bitrate_mask() which ends up in ieee80211_set_bitrate_mask() in cfg.c. The interface is marked running via SDATA_STATE_RUNNING but flags is 0, so check_sdata_in_driver() fails. When the interface is being torn down, or when wext ioctl is issued during interface bringup before drv_add_interface() sets IN_DRIVER, the running check passes while IN_DRIVER is clear. Check IEEE80211_SDATA_IN_DRIVER in ieee80211_set_bitrate_mask() before calling the driver, returning -ENETDOWN. This avoids the WARN_ONCE in driver-ops.h and matches other cfg.c operations that bail early when not in driver. This change should be safe because wiphy mutex is held in cfg80211_wext_siwrate() via guard(wiphy), and IN_DRIVER is set/cleared under RTNL and wiphy paths in drv_add_interface() and drv_remove_interface() in driver-ops.c, so the check is race-free against driver add/remove. Returning -ENETDOWN is the same error other not-running paths use and does not introduce new locking. Reported-by: syzbot+af177aa139efdd13a9da@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=af177aa139efdd13a9da Link: https://lore.kernel.org/all/6a75205c.59b6c763.2bba34.00c3.GAE@google.com/ Fixes: 554a43d5e77e ("mac80211: check sdata_running on ieee80211_set_bitrate_mask") Cc: stable@vger.kernel.org Assisted-by: Hermes:muse-spark-1.2 syzkaller Signed-off-by: Rik van Riel Link: https://patch.msgid.link/20260808104755.319c686e@fangorn Reported-by: syzbot+dcaca020ca8377e7ced0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=dcaca020ca8377e7ced0 [also add second syzbot report] Signed-off-by: Johannes Berg commit 4a724bcf5d703e18957397914d79156fa2cf1174 Author: Harry Yoo (Meta) Date: Thu Sep 3 15:32:26 2026 +0100 mm/slab: take n->list_lock in __slab_try_return_freelist() to avoid race Commit ba7425312607 ("mm, slab: add an optimistic __slab_try_return_freelist()") incorrectly assumed that nobody has freed an object to the slab as long as slab->freelist is NULL and cmpxchg succeeds. However, as reported by Hyunwoo Kim [1], other CPUs might have freed an object to the slab, insert the slab to the partial list, then allocated an object from the slab, and be in the middle of removing the slab from the list under n->list_lock. Since __refill_objects_node() puts the slab back on pc.slabs outside n->list_lock, it might insert the slab into that list while the slab is concurrently being removed from n->partial. This led to a list corruption [1]: list_add corruption. next->prev should be prev (ffff888100000248), but was dead000000000122. (next=ffffea000416e410). kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 1 UID: 65534 PID: 144 Comm: poc Not tainted 7.2.0-16172-gcf72cbb39da8-dirty #1 PREEMPT(lazy) RIP: 0010:__list_add_valid_or_report+0x80/0xd0 ... Call Trace: alloc_from_new_slab+0x183/0x300 ___slab_alloc+0x31c/0x890 __kmalloc_noprof+0x3d4/0x800 lsm_blob_alloc+0x2d/0x50 security_msg_msg_alloc+0x26/0x90 load_msg+0x1aa/0x210 do_msgsnd+0x91/0x800 do_syscall_64+0x109/0x5d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Kernel panic - not syncing: Fatal exception This is a classic ABA problem where cmpxchg succeeds but the state has changed since __refill_objects_node() took the freelist from the slab. As Vlastimil Babka mentioned [2], it should be rare to return more than one slab (due to the racy read of slab->counters in get_partial_node_bulk()). Therefore, instead of introducing additional complexity, acquire and release n->list_lock twice in the worst case. Return the slab directly to the partial list and hold n->list_lock across the cmpxchg and add_partial(). This is similar to the initial version of commit ba7425312607 [3]. This is enough to avoid the race as the list manipulation is serialized by n->list_lock. While at it, bring back unlikely() hint now that the condition is unlikely. Reported-by: Hyunwoo Kim Closes: https://lore.kernel.org/linux-mm/apPa-cGLcyt90l-E@v4bel [1] Link: https://lore.kernel.org/linux-mm/ae25c193-b95f-40c1-83b6-1c2546467e41@kernel.org [2] Link: https://lore.kernel.org/all/20260421-b4-refill-optimistic-return-v1-1-24f0bfc1acff@kernel.org [3] Fixes: ba7425312607 ("mm, slab: add an optimistic __slab_try_return_freelist()") Cc: stable@vger.kernel.org Signed-off-by: Harry Yoo (Meta) Link: https://patch.msgid.link/20260903-slab-fix-aba-v3-1-b44cb6badd54@kernel.org Reviewed-by: Hao Li Signed-off-by: Vlastimil Babka (SUSE) commit 5541d897584127b795dbbdc51a78a2348b4eaaa4 Author: Vlastimil Babka (SUSE) Date: Mon Aug 31 18:02:38 2026 +0200 mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again This partially reverts commit 2a8bb29ec9b2 ("mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT"). It was based on the assumption that local_trylock() is safe on PREEMPT_RT from any context. However kvfree_rcu() is also called by set_cpus_allowed_force() with task_struct::pi_lock acquired and there it's not safe, as syzbot has reported. For the immediate fix, skip kfree_rcu_sheaf() on PREEMPT_RT again from kvfree_call_rcu(). In theory, kfree_rcu_nolock() would have the same problem when called from under pi_lock on PREEMPT_RT but that can be addressed if such a caller is proposed. Add an explanation comment, courtesy of Sebastian. Reported-by: syzbot+acf142088e0182172e58@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=acf142088e0182172e58 Reported-by: ThangNN99 Fixes: 2a8bb29ec9b2 ("mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT") Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260831-b4-kfree_rcu_hotfix-v1-1-4f0fb882638b@kernel.org Reviewed-by: Harry Yoo (Meta) Signed-off-by: Vlastimil Babka (SUSE) commit cdd812d0683dee14ead02c9eded568685e61b23f Author: Daehyeon Ko <4ncienth@gmail.com> Date: Mon Aug 31 09:12:21 2026 +0900 exit: hold a reference to thread_pid across proc_flush_pid Commit 0a36bad01731 ("release_task: kill the no longer needed get/put_pid(thread_pid)") removed the reference around proc_flush_pid(). It assumed that free_pids(post.pids) at the end of release_task() would keep thread_pid alive until then. That assumption is wrong. __change_pid() only records a detached PID in post.pids when pid_has_task() is false for every PIDTYPE. If another task still uses the exiting task's PID as its process group or session ID, __unhash_process() removes the exiting task's PIDTYPE_PID link but leaves the PID out of post.pids. release_task() therefore holds no reference to it after dropping tasklist_lock. The other task can then remove the remaining PIDTYPE links. Its free_pids() call schedules delayed_put_pid(), and the RCU callback can free the PID before the first release_task() reaches proc_flush_pid(). An unprivileged reproducer races wait4(-1) against setsid() to trigger this ordering. Three of three fresh v7.2 KASAN boots reported: BUG: KASAN: slab-use-after-free in proc_invalidate_siblings_dcache+0x3e2/0x3f0 Read of size 8 by task h7_pid_reaper/1921 Call Trace: proc_invalidate_siblings_dcache release_task wait_consider_task __do_wait do_wait kernel_wait4 Freed by task 0: kmem_cache_free put_pid delayed_put_pid rcu_core Last potentially related work creation: __call_rcu_common free_pids ksys_setsid KASAN identified a 144-byte object from the pid cache and located the bad read 80 bytes into the freed object, matching pid->inodes. With an explicit reference, three of three fresh boots completed without a KASAN report. The concurrent RCU callback dropped its reference while proc_flush_pid() was protected, and the balancing put_pid() performed the final free afterward. Take a reference before __unhash_process() clears p->thread_pid and release it after proc_flush_pid() completes. A tested source reproducer is available privately on request. No controlled read or write, information leak, or privilege escalation is claimed. The mainline patch applies directly to v6.19.y and newer; v6.16.y through v6.18.y need a context-adjusted backport. Fixes: 0a36bad01731 ("release_task: kill the no longer needed get/put_pid(thread_pid)") Reported-by: syzbot+0aee5e8066eddbbe7397@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0aee5e8066eddbbe7397 Reported-by: syzbot+e8b3520b53e78e90034e@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=e8b3520b53e78e90034e Cc: stable@vger.kernel.org # see patch description, needs adjustments for 6.16.y-6.18.y Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/20260831001221.3755948-1-4ncienth@gmail.com Acked-by: Oleg Nesterov Reviewed-by: Bradley Morgan Signed-off-by: Christian Brauner (Amutable) commit 308d05225281d86150d88141990d6caf8c902349 Author: Diogo Ivo (Schneider Electric) Date: Fri Aug 7 13:07:00 2026 +0200 mmc: sdhci_am654: Fallback to DT-provided itap delay on DDR50 tuning failure DDR50 mode is not required to support the tuning command CMD19, meaning that calibration may fail on cards that do not implement it, in which case a known-good itap delay value should be programmed into the host controller. Do this by reading the (already defined) itap delay DT property for DDR50 and, if tuning fails for this mode, fall back to the DT-provided itap delay value. If the DT does not provide a value for DDR50 fallback then this simply disables using itapdly. Fixes: 901d16e46296 ("mmc: sdhci_am654: Add retry tuning") Cc: stable@vger.kernel.org Signed-off-by: Diogo Ivo (Schneider Electric) Acked-by: Adrian Hunter Reviewed-by: Judith Mendez Signed-off-by: Ulf Hansson commit c9f47cc8c37f7659897142ffe216c250fbc1d4ed Author: Diogo Ivo (Schneider Electric) Date: Fri Aug 7 13:06:59 2026 +0200 mmc: sdhci_am654: Clear ITAPDLY on tuning failure When tuning fails, stale ITAPDLY values can persist and interfere with subsequent I/O accesses, for example in DDR50 mode in cards with no tuning support. Move the ITAPDLY enable setting out of the tuning loop to after successful tuning, and explicitly clear ITAPDLY (delay and enable) when tuning fails so that we are sure only working values are actually left in hardware. Fixes: 901d16e46296 ("mmc: sdhci_am654: Add retry tuning") Cc: stable@vger.kernel.org Signed-off-by: Diogo Ivo (Schneider Electric) Reviewed-by: Judith Mendez Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson commit 7197d9107d9545730153b82ea5a411c5208b443f Author: Diogo Ivo (Schneider Electric) Date: Fri Aug 7 13:06:58 2026 +0200 mmc: sdhci_am654: Reset command and data lines on failed tuning The CMD/DATA reset after tuning should be performed regardless of whether tuning succeeded or failed, since tuning data may remain in the buffer in either case. Move the error return after the reset so that the controller is always cleaned up. Fixes: de31f6ab68a3 ("mmc: sdhci_am654: Reset Command and Data line after tuning") Cc: stable@vger.kernel.org Signed-off-by: Diogo Ivo (Schneider Electric) Reviewed-by: Judith Mendez Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson commit ff894dced1a7ad7523f9c65dbdb53d02474cca0f Author: Diogo Ivo (Schneider Electric) Date: Fri Aug 7 13:06:57 2026 +0200 mmc: sdhci_am654: Move tuning_loop to local variable The tuning_loop field in struct sdhci_am654_data is only used within sdhci_am654_platform_execute_tuning() as a loop counter that is initialized to 0 in sdhci_am654_init(). Since it shouldn't persist across function calls, otherwise every failure expends its "budget", move it to a local variable and remove the struct field along with the now-unnecessary initialization. Signed-off-by: Diogo Ivo (Schneider Electric) Reviewed-by: Judith Mendez Acked-by: Adrian Hunter Fixes: de31f6ab68a3 ("mmc: sdhci_am654: Reset Command and Data line after tuning") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson commit 60892a384aa1e65d0e703e1c513417bdf0c80777 Author: Eric Biggers Date: Mon Aug 31 14:18:12 2026 -0700 crypto: x86/aria - add missing vzeroupper in AVX-512 code Since the AVX-512 optimized ARIA code uses ZMM registers, execute vzeroupper before returning from it. This is needed to avoid degrading the performance of any later SSE code that may happen to be executed. Fixes: c970d42001f2 ("crypto: x86/aria - implement aria-avx512") Cc: stable@vger.kernel.org Cc: Taehee Yoo Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu commit ac53977611428db3bc0b4ac0225e19c3e08ae50b Author: Eric Biggers Date: Mon Aug 31 14:17:15 2026 -0700 crypto: x86/aria - add missing vzeroupper in AVX2 code Since the AVX2 optimized ARIA code uses YMM registers, execute vzeroupper before returning from it. This is needed to avoid degrading the performance of any later SSE code that may happen to be executed. Fixes: 37d8d3ae7a58 ("crypto: x86/aria - implement aria-avx2") Cc: stable@vger.kernel.org Cc: Taehee Yoo Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu commit 5d132990475f02cfa1debe03d50b479432864ebd Author: Fan Wu Date: Fri Aug 14 08:23:54 2026 +0000 mmc: hsq: Fix use-after-free in retry work mmc_hsq_pump_requests() queues retry_work when request_atomic() returns -EBUSY; today sdhci-sprd is the only consumer that implements request_atomic(). The work is embedded in a devm-allocated mmc_hsq, but is never cancelled during driver removal. Work still pending at unbind can therefore run after the devm allocation has been released and dereference hsq->mmc and hsq->mrq. Use devm_work_autocancel() to cancel and drain retry_work before the devm allocation is released. By the time devres cleanup begins, mmc_remove_host() has already stopped the host, so no new requests can arm the work. This issue was found by an in-house static analysis tool. Fixes: 6db96e5810e0 ("mmc: host: Introduce the request_atomic() for the host") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Ulf Hansson commit d3a421c82412344022982d5b91ba23194a0a6f29 Author: Fan Wu Date: Fri Aug 7 03:26:54 2026 +0000 mmc: mxcmmc: cancel data work and watchdog on remove mxcmci_remove() frees the host through the devm tail, but neither it nor mmc_remove_host() drains the driver's own asynchronous state. host->watchdog, a 10 s timer armed on the DMA path in mxcmci_setup_data(), is deleted only by the DMA- and IRQ-complete paths, which the remove path does not explicitly drain; it can therefore fire after the host is freed and dereference it in mxcmci_watchdog(). host->datawork, armed from the IRQ handler on the PIO path, is not cancelled by the remove path either. Free the devm-registered IRQ, then cancel datawork and delete the watchdog in mxcmci_remove(), before dma_release_channel(). Freeing the IRQ first keeps a trailing handler from re-arming datawork between the cancel and the host free. Both callbacks are non-self-rearming. This issue was found by an in-house static analysis tool. Fixes: f6ad0a481342 ("mmc: mxcmmc: fix bug that may block a data transfer forever") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Ulf Hansson commit 2b19cf3e50cddaff07b657dae1a8f30f06032852 Author: Fan Wu Date: Fri Aug 14 08:25:50 2026 +0000 mmc: mmci: Fix use-after-free in busy-timeout work ux500_busy_complete() can queue ux500_busy_timeout_work for an R1b command, but mmci_remove() never cancels it. The work can subsequently dereference the devm-allocated mmci_host after it has been released. Mask the controller interrupts and disable the delayed work during removal. This drains any queued instance and stops an IRQ handler that is still in progress from queueing the work again once it has been disabled. This issue was found by an in-house static analysis tool. Fixes: b1a665932dc2 ("mmc: mmci: Add support for SW busy-end timeouts") Cc: stable@vger.kernel.org # v6.10+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Linus Walleij Signed-off-by: Ulf Hansson commit 6feadbecdae60a6324c967f3b1493741083793a3 Author: Fan Wu Date: Thu Aug 6 13:02:33 2026 +0000 mmc: core: Cancel SDIO IRQ work before freeing host A host controller that uses sdio_signal_irq() schedules host->sdio_irq_work from its interrupt handler. That work is only cancelled on the suspend path (mmc_sdio_suspend()), not on the remove/free path, so a worker armed just before the controller freed its IRQ can run after mmc_host_classdev_release() has freed the host and dereference it through container_of(). Cancel host->sdio_irq_work in mmc_free_host(), like the existing host->detect drain added by commit 1036f69e2513 ("mmc: core: Cancel delayed work before releasing host"). This issue was found by an in-house static analysis tool. Fixes: 682696605c70 ("mmc: sdio: Add API to manage SDIO IRQs from a workqueue") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Ulf Hansson commit d8efd84f49379ed28624098821f80e992657d935 Author: Shengzhuo Wei Date: Mon Aug 31 02:42:13 2026 +0800 wifi: p54: require a full exp_if record in PDR_INTERFACE_LIST The PDR_INTERFACE_LIST loop only checks that the record start is within the entry before reading an entire struct exp_if from it. A truncated trailing record makes the if_id/variant reads cross the entry boundary into the heap beyond the EEPROM buffer (verified with a KASAN reproducer of the loop). The variant also feeds the synth front-end selection, so this is not only a leak. Advance only while a full record still fits in the entry. Fixes: eff1a59c48e3 ("[P54]: add mac80211-based driver for prism54 softmac hardware") Cc: stable@vger.kernel.org Acked-by: Christian Lamparter Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Link: https://patch.msgid.link/20260831-p54-pda-validation-v2-2-dae566b388c8@cherr.cc Signed-off-by: Johannes Berg commit ce858fa6b8a214dee5adb82358885fa024cdd887 Author: Shengzhuo Wei Date: Mon Aug 31 02:42:12 2026 +0800 wifi: p54: validate curve data length in the calibration curve converters p54_convert_rev0() and p54_convert_rev1() read calibration curve data from the device-supplied EEPROM entry using channel and points-per-channel counts taken verbatim from that same entry, so an entry that declares more data than it carries drives an out-of-bounds read past the EEPROM buffer (verified with a KASAN reproducer of the conversion loop). The sibling converters p54_convert_output_limits() and p54_convert_db() already validate their counts against the entry length; this path was missed. Reject the entry when the counts do not fit in the entry data. Fixes: eff1a59c48e3 ("[P54]: add mac80211-based driver for prism54 softmac hardware") Cc: stable@vger.kernel.org Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Link: https://patch.msgid.link/20260831-p54-pda-validation-v2-1-dae566b388c8@cherr.cc Signed-off-by: Johannes Berg commit c46cfaf8db42de0806076139fb40744d23041377 Author: Shmulik Cohen Date: Wed Aug 12 22:04:12 2026 +0300 wifi: ipw2x00: bound management frame length to the receive buffer Both management receive paths establish a lower bound on the frame length and no upper bound, even though the length originates from the device. ipw2100_corruption_check() returns 0 without inspecting frame_size for management frames, and __ipw2100_rx_process() only rejects a frame smaller than the three-address header, so any reported size up to the u32 limit reaches libipw_rx_mgt() against a receive allocation of IPW_RX_NIC_BUFFER_LENGTH bytes. Check frame_size itself rather than stats.len, which is a u16: a size of 65566 truncates to 30 on assignment and would pass a check made afterwards. ipw_rx() likewise only rejects a frame shorter than the header length. Bound it against the DMA mapped receive buffer. The size passed to alloc_skb() is rounded up by the allocator, so skb_tailroom() can exceed IPW_RX_BUF_SIZE and is not a usable bound here; the existing uses of that idiom in the data paths are too permissive for the same reason. libipw then hands the remainder to libipw_parse_info_param(), which walks information elements for as long as the length allows, so an over-long reported length reads past the receive buffer without any wraparound being involved. The length is device-reported, so per Documentation/process/threat-model.rst this is a robustness fix rather than a vulnerability. Found by an AI-assisted review of length arithmetic in management frame parsers. Compile-tested only for these two hunks; I do not have the hardware, so they are not tested on a real device. Assisted-by: Claude:claude-opus-5 Signed-off-by: Shmulik Cohen Link: https://patch.msgid.link/20260812190412.18333-4-anuk909@gmail.com Signed-off-by: Johannes Berg commit adb7118b7d2cfd7e8213c17d7d2829f353017754 Author: Shmulik Cohen Date: Wed Aug 12 22:04:11 2026 +0300 wifi: libipw: reject too-short association responses libipw_handle_assoc_resp() reads the capability, status and aid fields of the 30-byte association response prefix and then computes the information element length as stats->len - sizeof(*frame) stats->len is a u16 and sizeof() has type size_t, so the subtraction is evaluated as size_t and wraps instead of going negative. Truncating that to the u16 length parameter of libipw_parse_info_param() turns a frame shorter than the fixed fields into a length near 64 KiB, and the parser then reads past the receive buffer. Both the ipw2100 and ipw2200 management receive paths reach this function having established only that the frame carries the generic 24-byte three-address header. Reject the frame before any fixed field is touched. Found by an AI-assisted review of length arithmetic in management frame parsers. Verified with a KUnit case under Generic KASAN on arm64 under QEMU; I do not have the hardware, so it is not tested on a real device. Fixes: 9e8571affd1c ("[PATCH] ieee80211: Add QoS (WME) support to the ieee80211 subsystem") Assisted-by: Claude:claude-opus-5 Signed-off-by: Shmulik Cohen Link: https://patch.msgid.link/20260812190412.18333-3-anuk909@gmail.com Signed-off-by: Johannes Berg commit 5ce5721e8cbe3e80db8f43851cc2a2a92485ef4b Author: Shmulik Cohen Date: Wed Aug 12 22:04:10 2026 +0300 wifi: libipw: reject too-short beacon and probe responses libipw_process_probe_response() and the libipw_network_init() call it makes assume the frame contains the full 36-byte beacon and probe response prefix, but the ipw2100 and ipw2200 receive paths only establish that a management frame carries the generic 24-byte three-address header. libipw_network_init() then computes the information element length as stats->len - sizeof(*beacon) stats->len is a u16 and sizeof() has type size_t, so the subtraction is evaluated as size_t and wraps instead of going negative. Truncating that to the u16 length parameter of libipw_parse_info_param() yields 65524 for a 24-byte beacon, and the parser then walks the receive buffer as if it held almost 64 KiB of information elements, reading past the allocation. Reject the frame before any fixed field is touched. Found by an AI-assisted review of length arithmetic in management frame parsers. Verified with a KUnit case under Generic KASAN on arm64 under QEMU; I do not have the hardware, so it is not tested on a real device. Fixes: b453872c35cf ("[NET] ieee80211 subsystem") Assisted-by: Claude:claude-opus-5 Signed-off-by: Shmulik Cohen Link: https://patch.msgid.link/20260812190412.18333-2-anuk909@gmail.com Signed-off-by: Johannes Berg commit 3687d7d48070838cc2953431b3a27717cab0aaf6 Author: Pengpeng Hou Date: Sat Aug 15 21:52:27 2026 +0800 wifi: mwifiex: validate scan response extents mwifiex_ret_802_11_scan() subtracts the fixed response fields and the firmware-provided BSS length from resp->size without first proving that either extent fits. A short response or oversized BSS length can therefore underflow tlv_buf_size and make the TLV parser walk beyond the command response. Compute the fixed extent from the selected normal or background scan response. Validate that the fixed fields and BSS data fit before deriving the TLV extent and entering the parser. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260815135227.50392-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg commit 1c25bfad93e69ce13f744a2fb919f02ea396a985 Author: Zhao Li Date: Tue Aug 25 19:25:23 2026 +0800 wifi: mwifiex: validate action frame fixed fields mwifiex_process_mgmt_packet() accepts an rx_pkt_length as small as a four-address struct ieee80211_hdr plus the two-byte firmware length prefix. After stripping the prefix, mwifiex_parse_mgmt_packet() can receive a frame equal to sizeof(struct ieee80211_hdr). For action frames, the parser reads the category byte immediately after that header and, for a public action frame, reads the following action code byte without verifying that either field is present. A truncated frame can therefore make the parser consume up to two bytes past the firmware-declared frame length. If those bytes look like a TDLS discovery response, the malformed frame can spuriously update peer signal state. Require the category and public action-code fields before reading them. Use sizeof(*ieee_hdr) so the checks and field accesses directly match the firmware four-address layout being parsed before address4 is removed. Suggested-by: Johannes Berg Suggested-by: Brian Norris Fixes: 72e5aa8d2a6d ("mwifiex: support for parsing TDLS discovery frames") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/66f148d83eb9f0970b9abbccc85d1b61244e54ad.camel@sipsolutions.net/ Link: https://lore.kernel.org/all/20260708195911.84365-8-enderaoelyther@gmail.com/ Link: https://lore.kernel.org/all/20260723011013.76968-1-enderaoelyther@gmail.com/ Link: https://lore.kernel.org/all/20260723202257.688-1-enderaoelyther@gmail.com/ Link: https://lore.kernel.org/all/anuWyiPQja6_5vly@google.com/ Assisted-by: Codex:gpt-5 Assisted-by: Kimi:K3 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260825112523.95774-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg commit e667aee1c192d67d27c803007bfa9c6e0873e959 Author: Doruk Tan Ozturk Date: Fri Aug 14 15:47:04 2026 +0200 wifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length mwifiex_search_oui_in_ie() reads a pairwise-cipher (PTK) count from a beacon/probe-response RSN or WPA information element and then walks that many 4-byte OUIs, comparing each with memcmp(). The count comes straight from the (attacker-supplied) IE and is never checked against the element's own length, and the callers admit the element on element_id alone (has_ieee_hdr() / has_vendor_hdr(), no length check). A crafted RSN/WPA IE with a large pairwise count therefore makes the walk read up to 255 * 4 bytes past the element -- an out-of-bounds read of the kmemdup()'d beacon buffer, reachable from any AP whose beacon/probe response is processed during scan-result parsing. Pass the number of IE bytes available at the OUI list and bound the walk to the element. Keep the length signed and reject a negative value before any unsigned arithmetic, so a small or zero IE length cannot underflow to a large size_t and defeat the bound. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Cc: stable@vger.kernel.org Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk Link: https://patch.msgid.link/20260814134704.85902-1-doruk@0sec.ai Signed-off-by: Johannes Berg commit e2de8d5eb2984416affdd9559e55f37c7f1bbf47 Author: Bogdan Nicolae Date: Fri Aug 7 11:34:18 2026 -0500 wifi: brcmfmac: cyw: pass PMKID to firmware if present Zero out auth_status on initialization. Otherwise, garbage will leak from the stack to the firmware (when ssid is less than 32 bytes and/or when params->pmkid is set). Then, pass the params->pmkid to the firmware (without it, the firmware caches a garbage PMKID on successful authentication and denies a subsequent association request that includes the PMKID). Fixes: 66f909308a7c ("wifi: brcmfmac: cyw: support external SAE authentication in station mode") Signed-off-by: Bogdan Nicolae Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260807163418.487508-1-bogdan.nicolae@gmail.com Signed-off-by: Johannes Berg commit fa00193eb991f92b007aefe7afb6a7566976dacf Author: Linmao Li Date: Thu Aug 20 14:21:55 2026 +0800 wifi: mwifiex: prevent authentication frame length truncation mwifiex_cfg80211_authenticate() derives the authentication frame length from req->ie_len and req->auth_data_len, both of type size_t, but stores it in a u16. NL80211_ATTR_AUTH_DATA only has a minimum length policy. Since nla_len is a u16, a single attribute can carry up to 65531 bytes of payload, so the sum can exceed U16_MAX before it is assigned to pkt_len. The truncated pkt_len determines the skb frame area, while the copy length remains req->auth_data_len - 4, resulting in a heap buffer overflow. For example, with auth_data_len equal to 65510 and no IEs, the sum is 65546. It is truncated to 10 and then reduced by four to 6. The driver appends only six bytes to the skb with skb_put(), but then copies 65506 user-provided bytes into the authentication body. Reaching this path requires CAP_NET_ADMIN in the user namespace owning the network namespace, an up station netdev, and a suitable BSS/SAE authentication request. Compute the length in size_t, reject values that cannot be represented by the firmware's u16 frame length field, and only then assign it to pkt_len. Fixes: 36995892c271 ("wifi: mwifiex: add host mlme for client mode") Cc: stable@vger.kernel.org # 6.12+ Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260820062155.3981976-1-lilinmao@kylinos.cn Signed-off-by: Johannes Berg commit a3d722190cdef18da4878b5efc27c3c386dda248 Author: Peng Hao Date: Fri Aug 28 19:15:31 2026 +0800 wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path mwifiex_pcie_request_irq() registers each MSI-X vector with a per-index dev_id (&card->msix_ctx[i]). On a request_irq() failure the cleanup loop "for (j = 0; j < i; j++)" frees msix_entries[j].vector but passes the failed index's &card->msix_ctx[i] as the dev_id. free_irq() matches on (irq, dev_id), so it fails to find the action registered with &card->msix_ctx[j]: the already-requested IRQ j is not freed (leaked) and free_irq() warns about freeing a non-existent IRQ. Use &card->msix_ctx[j]. Fixes: 99074fc1e67b ("mwifiex: enable pcie MSIx interrupt mode support") Signed-off-by: Peng Hao Link: https://patch.msgid.link/20260828111531.56723-1-flyingpeng@tencent.com Signed-off-by: Johannes Berg commit bbb9a0ab96d44a64529aafc7a16de460a1712f6a Author: Jiangshan Yi Date: Sat Aug 15 19:57:24 2026 +0800 wifi: libertas_tf: fix UAF in lbtf_free_adapter() lbtf_free_adapter() calls lbtf_free_cmd_buffer() to free the command buffers before calling timer_delete_sync() to wait for the command timer callback. If the timer callback (command_timer_fn) is already running when lbtf_free_cmd_buffer() frees the command array, the callback dereferences priv->cur_cmd->cmdbuf which points to freed memory. Swap the order so that timer_delete_sync() runs first, ensuring any in-flight callback has completed before the command buffers are freed. Fixes: 06b16ae53192 ("libertas_tf: main.c, data paths and mac80211 handlers") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Link: https://patch.msgid.link/20260815115724.920628-1-yijiangshan@kylinos.cn Signed-off-by: Johannes Berg commit f9edf7cf63b96d2b776fca8d258d3c5256e40c8e Author: Mariano Baragiola Date: Sun Aug 9 09:49:47 2026 -0300 wifi: virt_wifi: free skb when disconnected When the simulated link is disconnected, virt_wifi_start_xmit() returns NET_XMIT_DROP without freeing the skb. dev_hard_start_xmit() treats this return value as consumed, so every packet sent while disconnected leaks its skb. Free the skb before returning the drop status. Fixes: c7cdba31ed8b ("mac80211-next: rtnetlink wifi simulation device") Signed-off-by: Mariano Baragiola Link: https://patch.msgid.link/20260809124947.3590270-1-mbaragiola@linux.com Signed-off-by: Johannes Berg commit ba6cb7c0868a412c2eb68e8efd5aa38bfb258a14 Author: Ali Ahmet Memis Date: Fri Aug 7 11:52:30 2026 +0000 wifi: wilc1000: fix out-of-bounds read in P2P public action frames wilc_wfi_p2p_rx() and mgmt_tx() start parsing a frame once ieee80211_is_public_action() returns true. That helper only verifies the frame is long enough for the action category field, that is offsetofend(struct ieee80211_mgmt, u.action.category), 25 bytes. Both functions then read the P2P public action header up to oui_subtype at offset 30 and pass "size - ie_offset" to cfg80211_find_vendor_ie(), where ie_offset is offsetof(struct ieee80211_mgmt, u) + sizeof(*d), i.e. 32. A public action frame of 25 to 31 bytes passes the check but is shorter than that 32 byte header, so oui_subtype can be read out of bounds, and because the length is unsigned, "size - ie_offset" underflows to a value close to 4 GiB. cfg80211_find_vendor_ie() takes an unsigned int length, so even the size_t subtraction in mgmt_tx() is truncated to the same value. It then walks far past the buffer searching for a vendor element until it reaches unmapped memory. In the receive path the frame arrives over the air and needs no association, so a nearby unauthenticated device can crash the host while it is in P2P listen. Reject frames shorter than the P2P public action header in both paths before dereferencing it. Fixes: 4fb8b5aa2a11 ("staging: wilc1000: refactor p2p action frames handling API's") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260807115230.136767-1-ali@iusegentoo.com Signed-off-by: Johannes Berg commit 8a1f3cf89ddcc700e25afe42cfad333059adcc94 Author: Runyu Xiao Date: Thu Aug 20 20:51:26 2026 +0800 wifi: wlcore: release runtime PM ref on regdomain config failure wlcore_regdomain_config() gets a runtime PM reference before sending the regulatory-domain command. When wlcore_cmd_regdomain_config_locked() fails, the function queues recovery and returns without dropping that reference. Release the reference after handling the command result so both success and failure paths balance the preceding pm_runtime_resume_and_get(). The recovery worker takes a separate runtime PM reference and cannot release the reference held here. Fixes: fa2648a34e73 ("wlcore: Add support for runtime PM") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260820125126.12757-1-runyu.xiao@seu.edu.cn Signed-off-by: Johannes Berg commit b5526b780f8b297a76030410b96ba29153afb98f Author: Stanislaw Gruszka Date: Thu Aug 20 11:30:59 2026 +0200 wifi: iwlegacy: fix broadcast stations deallocation On the error path of __il4965_up(), il_dealloc_bcast_stations() clears only IL_STA_UCODE_ACTIVE, leaving IL_STA_BCAST set. This causes the same broadcast stations to be deallocated again by __il4965_down(). This can occur when RF_KILL is toggled during driver startup. To fix clear the entire 'used' field, since we will not do any other operations on the station. Reported-and-tested-by: Martin-Éric Racine Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221733 Fixes: c2fd34469d16 ("iwl4965: Fix a memory leak in error handling code of __il4965_up") Cc: # 7.1.x: 57aa1718d595 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check Cc: # 6.x.x: 57aa1718d595 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check Cc: # 5.x.x: 57aa1718d595 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check Signed-off-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260820093059.18779-1-stf_xl@wp.pl Signed-off-by: Johannes Berg commit e6031f02269c0f51cf67886d177f02bc300b47cd Author: Ivan Pustogarov Date: Thu Sep 3 17:26:16 2026 +0200 wifi: mac80211: avoid out-of-bounds read for empty PREQ elements ieee80211_mesh_preq_size_ok() derives the location of the PREQ bottom fields before checking whether the element contains even the fixed header. ieee80211_mesh_hwmp_preq_get_bottom() reads the flags byte to account for the optional Address Extension field. Consequently, an empty PREQ element causes a one-byte read beyond its declared payload. Move the helper call after both size checks, so the bottom fields are only accessed when they are present. Fixes: 8b40b1d24a60 ("wifi: mac80211: Fix overread in PREQ frame processing") Cc: stable@vger.kernel.org Signed-off-by: Ivan Pustogarov Link: https://patch.msgid.link/20260903152616.1646637-1-ivan@ipust.net Signed-off-by: Johannes Berg commit af72b5946d493cecced27d0951ea37c1d178601e Author: Lachlan Hodges Date: Thu Aug 27 15:43:02 2026 +1000 wifi: mac80211: include TIM bitmap control for buffered S1G mcast traffic Currently when building the S1G TIM element, we only build the bitmap control if we have buffered unicast traffic. Since AID 0 sits within the bitmap control if we have buffered multicast traffic with no buffered unicast traffic the bitmap control won't be emitted and dozing stations will be unaware of buffered multicast. To fix, only exclude the bitmap control byte when we don't have both buffered unicast and multicast traffic. Fixes: ee6360945483 ("wifi: mac80211: support block bitmap S1G TIM encoding") Signed-off-by: Lachlan Hodges Link: https://patch.msgid.link/20260827054302.254124-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg commit 5ab54837fce04a1c9923d0bfd3d5de51fdc768b3 Author: Jeffin Philip Date: Thu Sep 3 13:40:48 2026 +0530 fs: autofs: fix memory leak in autofs_fill_super() In autofs_fill_super(), we create a new inode using autofs_new_ino(), however, if we fail to create root_inode, (that is, root_inode failure path), we return -ENOMEM without freeing the new inode(ino) that we created causing a memory leak. Fix this by adding autofs_free_ino() to free the inode we created in root_inode failure path before returning ENOMEM. Reported-by: syzbot+df1db6e034b3953e19f5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=df1db6e034b3953e19f5 Fixes: 66917f85db60 ("autofs: add: new_inode check in autofs_fill_super()") Cc: stable@vger.kernel.org Signed-off-by: Jeffin Philip Link: https://patch.msgid.link/20260903081048.132524-1-jeffinphilip14@gmail.com Signed-off-by: Ian Kent Signed-off-by: Christian Brauner (Amutable) commit 6177bcd94be83f80a032c2e69a06606d325335b9 Author: Sebastian Sjoholm Date: Thu Sep 3 20:00:29 2026 +0200 USB: serial: option: add Quectel RG660QB Add support for the Quectel RG660QB 5G module (USB ID 2c7c:013d). The interface layout is the same as the RG650V: If 0: DIAG ff/ff/30, 2 endpoints If 1: NMEA ff/00/00, 2 endpoints If 2: AT ff/00/00, 3 endpoints If 3: Modem ff/00/00, 3 endpoints If 4: QMI ff/ff/ff, 3 endpoints Match the serial interfaces on class/subclass/protocol so that the QMI interface is left to qmi_wwan. # lsusb -v -d 2c7c:013d Bus 004 Device 002: ID 2c7c:013d Quectel Wireless Solutions Co., Ltd. RG660QB-EU Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2c7c Quectel Wireless Solutions Co., Ltd. idProduct 0x013d bcdDevice 6.06 iManufacturer 1 Quectel iProduct 2 RG660QB-EU iSerial 3 f50119d0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0105 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 4 DIAG_SER_RMNET bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 896mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 CDEV Serial ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 CDEV Serial ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 7 RmNet Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 2 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 0x0023 bNumDeviceCaps 2 SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000f Device can operate at Low Speed (1Mbps) Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 0 micro seconds bU2DevExitLat 0 micro seconds SuperSpeedPlus USB Device Capability: bLength 20 bDescriptorType 16 bDevCapabilityType 10 bmAttributes 0x00000001 Sublink Speed Attribute count 1 Sublink Speed ID count 0 wFunctionalitySupport 0x1100 bmSublinkSpeedAttr[0] 0x000a4030 Speed Attribute ID: 0 10Gb/s Symmetric RX SuperSpeedPlus bmSublinkSpeedAttr[1] 0x000a40b0 Speed Attribute ID: 0 10Gb/s Symmetric TX SuperSpeedPlus Device Status: 0x0000 (Bus Powered) Tested with an early sample of the module on a Quectel 5G EVB connected over USB 3 to a Raspberry Pi 5. Assisted-by: LLM Signed-off-by: Sebastian Sjoholm Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold commit 797b13a7de957792c1b4773aa2cc3dab4621fd9c Author: Jiri Slaby (SUSE) Date: Tue Sep 1 09:04:48 2026 +0200 irqdomain: Delete irq_domain_add_linear() 7.3-rc1 is free of calls to irq_domain_add_linear(), so it can be finally deleted. According to Dongliang Mu, the related paragraph in the Chinese docs is now obsolete. So drop it completely. Signed-off-by: Jiri Slaby (SUSE) Signed-off-by: Thomas Gleixner Reviewed-by: Dongliang Mu Reviewed-by: Yanteng Si Link: https://patch.msgid.link/20260901070450.255507-1-jirislaby@kernel.org commit e6df180e976fd08673214bc1305a46a8536aea9a Author: Mika Westerberg Date: Fri Aug 14 06:35:52 2026 +0200 Revert "thunderbolt: xdomain: Notify peers after enumeration" This reverts commit e027dba038f0008df9bc9575f5c3e803e90636c6. Alan noticed that this causes the peers send change properties to each other continuously. Reported-by: Borzeszkowski, Alan Cc: Milo Chen Signed-off-by: Mika Westerberg commit 96ff396e6e0eb754b73f1870ef7e72f2f80cdbe0 Author: Mika Westerberg Date: Fri May 15 10:28:40 2026 +0300 thunderbolt: Use separate lock class for each ring When connected to another host and then unplugging cable lockdep triggers following: ====================================================== WARNING: possible circular locking dependency detected 7.1.0-rc2+ #1775 Tainted: G U ------------------------------------------------------ kworker/u16:6/312 is trying to acquire lock: ffff8881179c70a8 ((work_completion)(&ring->work)){+.+.}-{0:0}, at: __flush_work+0x3cf/0xd10 but task is already holding lock: ffff8881a8b810b0 (&net->connection_lock){+.+.}-{4:4}, at: tbnet_tear_down+0x110/0x720 [thunderbolt_net] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&net->connection_lock){+.+.}-{4:4}: __mutex_lock+0x19a/0x2490 mutex_lock_nested+0x1b/0x30 tbnet_handle_packet+0x74c/0xd70 [thunderbolt_net] tb_xdomain_handle_request+0x37c/0x4b0 [thunderbolt] tb_domain_event_cb+0xc9/0x140 [thunderbolt] tb_ctl_handle_event+0xd6/0x2c0 [thunderbolt] tb_ctl_rx_callback+0x22c/0xa10 [thunderbolt] ring_work+0x715/0xcb0 [thunderbolt] process_one_work+0x902/0x1790 worker_thread+0x5cd/0xfe0 kthread+0x339/0x420 ret_from_fork+0x79a/0x9d0 ret_from_fork_asm+0x1a/0x30 -> #0 ((work_completion)(&ring->work)){+.+.}-{0:0}: __lock_acquire+0x1592/0x2640 lock_acquire+0x1a3/0x300 __flush_work+0x3e9/0xd10 flush_work+0x21/0x30 tb_ring_stop+0x240/0x840 [thunderbolt] tbnet_tear_down+0x2ff/0x720 [thunderbolt_net] tbnet_stop+0x47/0x1a0 [thunderbolt_net] __dev_close_many+0x19e/0x4e0 netif_close_many+0x1e8/0x640 unregister_netdevice_many_notify+0x6d3/0x22d0 unregister_netdevice_queue+0x2b9/0x3a0 unregister_netdev+0x1c/0x70 tbnet_remove+0x52/0xb0 [thunderbolt_net] tb_service_remove+0x8a/0xe0 [thunderbolt] device_remove+0xc5/0x190 device_release_driver_internal+0x3db/0x590 device_release_driver+0x12/0x20 bus_remove_device+0x2c1/0x580 device_del+0x3d9/0x9f0 device_unregister+0x17/0xc0 unregister_service+0x46/0x60 [thunderbolt] device_for_each_child_reverse+0xfa/0x180 tb_xdomain_unregister+0x57/0xe0 [thunderbolt] unregister_unplugged_xdomain+0x101/0x1a0 [thunderbolt] bus_for_each_dev+0x111/0x1a0 tb_domain_unregister_unplugged_xdomains+0x98/0xe0 [thunderbolt] tb_handle_hotplug+0xc3/0x2bb0 [thunderbolt] process_one_work+0x902/0x1790 worker_thread+0x5cd/0xfe0 kthread+0x339/0x420 ret_from_fork+0x79a/0x9d0 ret_from_fork_asm+0x1a/0x30 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&net->connection_lock); lock((work_completion)(&ring->work)); lock(&net->connection_lock); lock((work_completion)(&ring->work)); This in fact is false positive because they involve unrelated rings (and unrelated work structures). In the first one it is ring 0 which is used for control traffic and in the second it is dealing with another ring used for the high-speed traffic. Fix this by using separate lock class for each ring worker. Signed-off-by: Mika Westerberg commit a02188ddc24b7872f0c5e0c5873f827318717803 Author: Mika Westerberg Date: Thu May 7 08:06:48 2026 +0300 thunderbolt: Fix KASAN reported use-after-free when request is canceled Alan reported that when doing stress testing sometimes KASAN notices use-after-free during control channel operation (stripped down keeping the relevant parts): BUG: KASAN: slab-use-after-free in tb_cfg_request_sync+0x240/0x250 [thunderbolt] Read of size 24 at addr ffff88811067f290 by task kworker/u40:2/1760 tb_cfg_request_sync+0x240/0x250 [thunderbolt] tb_cfg_read_raw+0x367/0x510 [thunderbolt] tb_cfg_read+0xec/0x240 [thunderbolt] tb_port_get_link_generation+0x258/0x420 [thunderbolt] tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt] tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt] tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt] tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt] tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 Allocated by task 1760: __kmalloc_cache_noprof+0x1ee/0x550 tb_cfg_read_raw+0x1d3/0x510 [thunderbolt] tb_cfg_read+0xec/0x240 [thunderbolt] tb_port_get_link_generation+0x258/0x420 [thunderbolt] tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt] tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt] tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt] tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt] tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 Freed by task 926: kfree+0x18f/0x4a0 tb_cfg_request_put+0xb7/0xe0 [thunderbolt] tb_cfg_request_work+0x82/0x120 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 Second to last potentially related work creation: __queue_work+0x575/0xd00 queue_work_on+0x77/0x80 tb_cfg_request_cancel+0xc7/0x260 [thunderbolt] tb_cfg_request_sync+0x1f6/0x250 [thunderbolt] tb_cfg_read_raw+0x367/0x510 [thunderbolt] tb_cfg_read+0xec/0x240 [thunderbolt] tb_port_get_link_generation+0x258/0x420 [thunderbolt] tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt] tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt] tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt] tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt] tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt] process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 The last stack trace is helpful because it shows that we are cancelling a request and looking at tb_cfg_request_cancel() what might happen is that tb_cfg_request_work() completes right before tb_cfg_request_cancel() starts and because of this it will call schedule_work() queueing the same work to run again. However, it is already removed from the request_queue and reference count is dropped so when tb_cfg_request_work() triggers again it will access memory that is already released. Fix this so that we first make sure a cancelled request is not handed away from tb_cfg_request_find() or scheduled to run. Then instead of relying on the worker to clean up the request we will do it in tb_cfg_request_cancel() after the work is canceled from running. Make tb_cfg_request_dequeue() release the request only if it was actually removed from the queue. Reported-by: Alan Borzeszkowski Fixes: d7f781bfdbf4 ("thunderbolt: Rework control channel to be more reliable") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg commit a3b8d46fe401cba3a5c46dea610e6eb3dc15370e Author: Yao Kai Date: Tue Sep 1 15:54:52 2026 +0200 futex: Prevent rcuwait use-after-free during requeue PI On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report (slab-out-of-bounds) in futex_requeue_pi_complete() invocation of rcuwait_wake_up(). The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's stack. An early wakeup can race with a PI requeue as follows: waiter requeue task ------ ------------ futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS * timeout/ signal wakes waiter * futex_requeue_pi_wakeup_sync() Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT requeue_pi_wake_futex futex_requeue_pi_complete() cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED rcuwait_wait_event() if (atomic_read(&q->requeue_state) != Q_REQUEUE_PI_WAIT) break /* no schedule() */ /* q.pi_state->owner == current */ futex_private_hash_put() /* return from syscall */ rcuwait_wake_up(&q->requeue_wait) /* q is gone */ futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before calling rcuwait_wake_up(). The waiter observes this state in rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event(). Here, the waiter is free leave the syscall before requeue task can complete the wake. To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED case. This state is only published by requeue_pi_wake_futex(), which saves q->task before futex_requeue_pi_complete() and wakes the waiter via wake_up_state(). This wake is intended to wake the waiter from its futex_do_wait() sleep. If the waiter is still sleeping there, it can not get into the Q_REQUEUE_PI_WAIT state (and require this removed wake). Should the waiter be woken up from futex_do_wait() by other means (as in this example) and sleep in futex_requeue_pi_wakeup_sync() then the wake_up_state() from requeue_pi_wake_futex() will wake it, too. Should the waiter task terminate before wake_up_state() had a chance to wake the task then the task pointer does not become invalid because the futex_hash_bucket::lock is held and the task pointer is RCU protected. [bigeasy: Updated comment and commit message] Fixes: 07d91ef510fb1 ("futex: Prevent requeue_pi() lock nesting issue on RT") Signed-off-by: Yao Kai Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Sebastian Andrzej Siewior Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901135453.3121948-3-bigeasy@linutronix.de commit 912edebe8501a36c6bedcef03bd238ab90a7e060 Author: Sebastian Andrzej Siewior Date: Tue Sep 1 15:54:51 2026 +0200 futex: Provide rt_mutex_.*_schedule() equivalents for futex scheduling There is rt_mutex_{pre|post}_schedule() around rt_mutex_wait_proxy_lock() to ensure that sched_submit_work()/ sched_update_worker() is invoked before we schedule out and block on rt_mutex while waiting for it become available. The reason is that blocking on rt_mutex assigns a pi_waiter for the PI chain and sched_submit_work() will also assign a pi_waiter if it blocks on lock but a this point we already have a waiter assigned. We can't skip sched_submit_work() entirely because I/O relies on the fact that I/O queue is flushed while it blocks on a sleeping lock. Therefore sched_submit_work() is moved before we block on the lock. Sleeping lock in this context means mutex or rw_semaphore not spinlock_t on PREEMPT_RT. Because the mutex abstraction on PREEMPT_RT uses the same abstraction as the futex proxy lock, the futex code ended up using rt_mutex_{pre|post}_schedule(), too. Using it is/ was just to keep the task_struct::sched_rt_mutex assertion happy. Futex proxy lock is used only in the syscall context of a task. At this point it never got any I/O that needs to be flushed and it can't be a workqueue that needs to notify that it will be scheduled out. Therefore sched_submit_work() does nothing here. By mistake futex_wait_requeue_pi() -> rt_mutex_wait_proxy_lock() did not get the rt_mutex_{pre|post}_schedule() annotation. This was not noticed because in this callchain the lock is (usually) not contended and so rt_mutex_slowlock_block() does not schedule, triggering the assert. Adding rt_mutex_pre_schedule() here looks wrong (as noted by PeterZ) because at this point there is a pi_waiter recorded and invoking sched_submit_work() with a possible lock contention would be wrong. Add rt_mutex_futex_{pre|post}_schedule() which toggles the sched_rt_mutex assert and does not involve sched_submit_work(). Add asserts here to ensure that sched_submit_work() would do nothing. Use it only in futex proxy lock case which is rt_mutex_wait_proxy_lock(). Remove it from futex_lock_pi(). Fixes: d14f9e930b90 ("locking/rtmutex: Use rt_mutex specific scheduler helpers") Reported-by: Yao Kai Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901135453.3121948-2-bigeasy@linutronix.de Closes: https://lore.kernel.org/all/20260717084922.4153317-2-yaokai34@huawei.com commit 5ff6e2f8a779f72306bd93bde40c1b10436dbf58 Merge: 42bc1b92c9b986 3785d40831ba56 Author: Dave Airlie Date: Fri Sep 4 15:58:06 2026 +1000 Merge tag 'drm-intel-fixes-2026-09-03' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes drm/i915 fixes for v7.3-rc2: - Drop an accidentally duplicated panel fitter call in DP MST - Fix DDI clock programming for Cx0 and LT PHY - Fix PTL CDCLK handling at probe, causing a glitch - Fix dg2_power_well_count() return type - Fix a NULL pointer deref at forced probe - Fix selective fetch disable Signed-off-by: Dave Airlie From: Jani Nikula Link: https://patch.msgid.link/affe11af9d5eb9dc6f906441495cb843f9d4817c@intel.com commit 254c881fe0554c5efb16d355c273702a27a32a20 Author: Florian Westphal Date: Thu Sep 3 08:58:45 2026 +0200 selftests/bpf: Add tests to assert that netfilter progs cannot write to skb The netfilter framework is allergic to ip header changing after validation done by ip/ipv6 stack. Assert that bpf netfilter programs do not allow skb write access. Following additional tests are expected to be rejected by verifier: 1. alter skb->len. 2. alter skb->data. 3. prog calls bpf_dynptr_slice_rdwr. 4. alter location returned by dynptr API. Add following test case for bpf runtime: - alter skb data via bpf_dynptr_write() Test checks via __retval() that bpf_dynptr_write() returned nonzero value. Signed-off-by: Florian Westphal Reviewed-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260903065845.22762-1-fw@strlen.de Signed-off-by: Alexei Starovoitov commit 42bc1b92c9b98674ab4f368e1bd6fa9be479e969 Merge: cee9395acd8043 d3609b54083894 Author: Dave Airlie Date: Fri Sep 4 13:30:28 2026 +1000 Merge tag 'drm-misc-fixes-2026-09-03' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A whole bunch of fixes for various drivers - Fix drm_crtc_commit leak when PAGE_FLIP_EVENT is used, - amd: plane blend mode fixes - amdxdna: out-of-bounds access fix, reject commands chains with no commands, handle chained mapping BO failures, refuse to flush an imported BO - atomic-state-helpers: set pixel_blend_mode to prop default on reset - dma-buf: Publish the dma-buf only after copy_to_user succeeds, fix some kernel-doc warnings - ethosu: handle mmio mapping failures, handle storage modes only on hardware that supports it, fix job completion fence cleanup - fastrpc: Publish the dma-buf only after copy_to_user succeeds - gud: Improve TV modes and rotation handling - nouveau: use-after-free fixes, add scanline position support, HDMI and DP fixes, null pointer dereference fix, dmem accounting fixes for large folios, use write-combined maps for coherent - pagemap: Prevent double migration of device pages, Reset migration page count on eviction retry, dma-unmap pages before handling migration errors, use after free fixes - prime: fix prime exports tracing - qaic: out-of-bounds access fix - sysfb: Fix integer overflow, fix constant comparison bug - tegra: Add blend mode properties - virtio: exit path and error handling fixes Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patch.msgid.link/apk9X5SkRLS9g4RF@houat commit 0237317ffc70ae9d643161d176999b6283920fe4 Merge: 65b1518c995c59 23724e009f6583 Author: Alexei Starovoitov Date: Thu Sep 3 19:22:53 2026 -0700 Merge branch 'misc-bug-fixes-part-2' Kumar Kartikeya Dwivedi says: ==================== Misc bug fixes - part 2 A set of miscellaneous fixes for bugs reported by Nicholas, plus some new findings by GPT-5.6-Sol and Sashiko. See commit logs for details. ==================== Link: https://patch.msgid.link/20260903214758.2727663-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 23724e009f65838bd8e1b42bed69e3daa4ecfdab Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:54 2026 +0200 selftests/bpf: Reject legacy packet loads from callbacks Add verifier coverage for the callback restriction on legacy packet loads. Exercise BPF_LD_ABS directly in a bpf_loop callback and BPF_LD_IND from a static subprogram called by the callback, ensuring that callback context follows nested static calls. Also exercise a callback which reaches BPF_LD_IND through a global function and its static descendant. A sibling success case calls the same global chain outside a callback, preserving support for ordinary global packet loads. Existing success cases continue to cover loads from ordinary static subprograms. The failure cases expect the policy-specific rejection instead of reaching the implicit-return path, triggering a verifier warning, or being accepted through a function boundary. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903214758.2727663-9-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit e7d28823c662128caae63f14e16bd394916c139b Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:53 2026 +0200 bpf: Reject legacy packet loads from callbacks check_ld_abs() models a failed BPF_LD_ABS or BPF_LD_IND in a subprogram as an implicit return with R0 set to zero. It calls prepare_func_exit() to explore this synthesized path. When the load is reached directly from a synchronous callback, prepare_func_exit() enforces the callback return contract and marks R0 precise. R0 is not derived from a real instruction on this path, so precision backtracking reaches the callback call with R0 still requested and triggers the "callback unexpected regs" verifier bug. A privileged program loader can therefore cause a verifier warning and an -EFAULT BPF_PROG_LOAD. These legacy packet-load instructions are deprecated. Reject them from callbacks rather than complicating their implicit-return model. Check all active frames before constructing the implicit return so nested static subprograms cannot hide the callback context. Global functions are verified independently with a fresh frame zero, so an active-frame check cannot identify a global function called from a callback. Also check the complete subprogram call graph during stack-depth validation and reject a function containing a legacy load when any caller is a callback. This covers global and static descendants without making has_ld_abs transitive, preserving its per-function BTF return-type check. Ordinary uses outside callbacks remain supported. Fixes: ee861486e377 ("bpf: Fix ld_{abs,ind} failure path analysis in subprogs") Reported-by: Sashiko Link: https://lore.kernel.org/bpf/20260903152147.C0E241F00A3A@smtp.kernel.org Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903214758.2727663-8-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 1ba0d0d8b6757eaf107f1f0fa0830c9585853db7 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:52 2026 +0200 selftests/bpf: Check faultable stack helper contexts Add verifier coverage for the sleepable bpf_get_stack() and bpf_get_task_stack() implementations. Call each helper while preemption is disabled and require the verifier to reject it as sleepable. Both programs load when the prototypes lack might_sleep, so the expected-failure tests fail. Keep success controls outside the non-preemptible region to ensure ordinary calls from sleepable uprobes remain valid. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903214758.2727663-7-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 9d02927fdf4e930893c92e35fed01a2704496900 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:51 2026 +0200 bpf: Mark faultable stack helpers as sleepable The faultable variants of bpf_get_stack() and bpf_get_task_stack() pass may_fault=true into the common stack collection code. Resolving user-space build IDs may then call build_id_parse_file() and block on filesystem reads. Neither helper prototype sets might_sleep. Since prototype selection uses the sleepability of the whole program, the verifier can still allow these helpers from a non-sleepable region within that program, such as an explicit RCU or preemption-disabled region. The task-stack helper can also be called from a non-sleepable timer callback of a sleepable program. Mark both faultable prototypes as sleepable. The existing helper context check then rejects these calls while continuing to allow them in genuinely sleepable contexts. Fixes: d4dd9775ec24 ("bpf: wire up sleepable bpf_get_stack() and bpf_get_task_stack() helpers") Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903214758.2727663-6-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 687b2729ce4c90a3cec76db85d3649e8f5086f85 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:50 2026 +0200 selftests/bpf: Test btf lookup helper sleepability Add an expected failure case which calls bpf_btf_find_by_name_kind() from a BPF timer callback. Without the helper prototype being marked sleepable, the verifier accepts the program and the load unexpectedly succeeds. Also add a positive control which calls the helper directly from a syscall program. This verifies that marking the helper sleepable only rejects it in non-sleepable regions. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903214758.2727663-5-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 620614bf7672130c43b3cff375525a2202f61979 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:49 2026 +0200 bpf: Mark bpf_btf_find_by_name_kind() as sleepable When bpf_btf_find_by_name_kind() finds a type in module BTF, it returns a new BTF object fd through __btf_new_fd(). This reaches anon_inode_getfd(), which can sleep while allocating or expanding the current task fd table. The helper prototype does not set might_sleep, so the verifier allows the helper in non-sleepable contexts such as BPF timer callbacks. The fd allocation can then sleep in softirq context and install the fd into the interrupted task. Mark the helper as sleepable. This preserves calls from the main body of a sleepable syscall program while rejecting calls from its non-sleepable regions. Fixes: 3d78417b60fb ("bpf: Add bpf_btf_find_by_name_kind() helper.") Reported-by: Sashiko Link: https://lore.kernel.org/bpf/20260903155150.D57251F000E9@smtp.kernel.org Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903214758.2727663-4-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 22ab49afe1c901b2c0b9482f38bdb647d46e6a34 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:48 2026 +0200 selftests/bpf: Check rbtree callback restrictions in subprogs Add a verifier failure case where an rbtree comparator enters two nested static subprograms and the innermost subprogram unlocks and relocks the tree. Restoring the lock keeps the surrounding callback state balanced, so the test specifically exercises whether the callback restriction follows the nested calls. Also add a load-only positive control whose comparator calls a harmless static subprogram. This preserves the intended support for verified static subprogram calls while holding the tree lock. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903214758.2727663-3-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 369f4ce734570bdfedaa4b5ca50e2a3f6a892728 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 23:47:47 2026 +0200 bpf: Check ancestor frames for rbtree callbacks bpf_rbtree_add() invokes its comparator while the caller holds the root lock. The native insertion code retains raw parent and link pointers across the callback, so the verifier prohibits unlocking, consuming tree nodes, or changing RCU state from that callback. in_rbtree_lock_required_cb() only checks the innermost verifier frame. Static subprogram calls are permitted while holding a spin lock, and such a call pushes a frame without in_callback_fn set. Consequently, all callback restrictions disappear in the nested frame. The subprogram can unlock the tree, remove and drop the node being compared, then relock. Native insertion resumes with the stale parent pointer and links freed memory into the tree. Walk all active frames for the rbtree callback instead. Benign static subprograms remain permitted, while callback restrictions follow execution into nested frames. Fixes: a44b1334aadd ("bpf: Allow calling static subprogs while holding a bpf_spin_lock") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903214758.2727663-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 641d03105cc0d2437e32fdeec164f91a4ccef6c4 Merge: 39b23c1c40e1f7 8972d252f495d4 Author: Jakub Kicinski Date: Thu Sep 3 19:10:20 2026 -0700 Merge branch 'enic-fix-v2-vf-mailbox-reply-matching-and-carrier-reopen' Satish Kharat says: ==================== enic: fix V2 VF mailbox reply matching and carrier reopen Preserve ENIC V2 VF carrier state across netdev reopen and match mailbox replies to their originating requests. A V2 VF receives carrier state from PF MBOX notifications. enic_stop() forces carrier off, but enic_open() does not request another notification or restore the previous state. An ordinary netdev close/open can therefore leave the VF without carrier until the PF sends another link-state notification. The first patch preserves the last PF-reported link state across an ordinary netdev close/open. Internal reset paths invalidate the saved state before reopening the datapath, so carrier remains off until the PF provides a new notification. Mailbox messages carry a message number that replies and acknowledgments echo. ENIC currently assigns a new number to outgoing replies and accepts VF replies by message type alone. After a request times out, a delayed reply can therefore satisfy a later request of the same type. The second patch makes PF replies and the VF link-state acknowledgment echo the initiating message number. The VF accepts a reply only when both its type and message number match the pending request. Reply handling and timeout cleanup are protected by the same lock, and message numbering remains monotonic across admin-channel reopen. Validation: - The VF module with this series applied passed multiple netdev close/open and ENIC module unload/reload cycles, as well as guest reboot testing, with carrier restored as expected after each operation. - With this series folded into the full SR-IOV development stack, VFIO guests passed bidirectional cross-DUT PF-to-VF, VF-to-PF, and VF-to-VF traffic using standard-sized and 8972-byte jumbo ICMP packets. ==================== Link: https://patch.msgid.link/20260830-b4-enic-v2-mbox-fixes-net-v1-0-23adf9bfd426@cisco.com Signed-off-by: Jakub Kicinski commit 8972d252f495d4be4bbfb32d4d9d6c2ff778fea4 Author: Satish Kharat Date: Sun Aug 30 15:22:53 2026 -0700 enic: match mailbox replies to request numbers The version-1 VF mailbox protocol identifies every message with a message number, and a reply or acknowledgment echoes the number of the message it answers. ENIC instead generates a new number for outgoing replies and accepts a VF reply by message type alone. If a request times out, a delayed reply can therefore satisfy a subsequent request of the same type and cause the VF to consume the result of the old request. Allow replies to reuse the initiating message number. Make the in-tree PF handlers and the VF link-state acknowledgment echo that number. Record the expected reply type and message number on the VF, and require both values to match before accepting a reply. Protect expected-reply state with a lock so reply acceptance and timeout invalidation cannot race. Keep message numbers monotonic across an admin- channel reopen so a delayed reply from an earlier channel generation cannot match a new request. Reply-number echo is part of the established version-1 protocol, so this remains compatible with deployed V2-capable PF implementations that already echo msg_num. Fixes: 72b65c94058e ("enic: add MBOX VF handlers for capability, register and link state") Signed-off-by: Satish Kharat Link: https://patch.msgid.link/20260830-b4-enic-v2-mbox-fixes-net-v1-2-23adf9bfd426@cisco.com Signed-off-by: Jakub Kicinski commit b752e041d5845d03f285cf7a1f30b38ca7ef92bf Author: Satish Kharat Date: Sun Aug 30 15:22:52 2026 -0700 enic: preserve V2 VF carrier across netdev reopen A V2 VF receives carrier state only from PF MBOX notifications. enic_stop() forces carrier off, but enic_open() does not request a fresh notification or restore the previous one. An ordinary down/up cycle therefore leaves the VF in NO-CARRIER and unable to pass traffic until the PF repeats the link-state command, even when the physical link remained up. Cache each valid PF link-state notification. Serialize updates with the V2 VF datapath running state. Keep carrier off while the netdev is stopped. Restore the cached state after an ordinary open. Before either internal reset reopens the datapath, invalidate the cache. Carrier then remains off until re-registration receives a fresh PF link-state notification. Fixes: 72b65c94058e ("enic: add MBOX VF handlers for capability, register and link state") Signed-off-by: Satish Kharat Link: https://patch.msgid.link/20260830-b4-enic-v2-mbox-fixes-net-v1-1-23adf9bfd426@cisco.com Signed-off-by: Jakub Kicinski commit 65b1518c995c590ab01f1e87f37d4eb47e8d050f Author: Eduard Zingerman Date: Thu Sep 3 13:58:20 2026 -0700 selftests/bpf: bpf_fastcall patterns entered by a jump Check bpf_fastcall pattern detection when the pattern is entered at an instruction other than the first spill: - a jump to the first spill allows the rewrite; - conditional/unconditional a jump to the call or to the fill does not allow the rewrite. Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903205820.1743087-2-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov commit 0b1c83dc3c4401cd7e846548f62e3caf3d06742e Author: Eduard Zingerman Date: Thu Sep 3 13:58:19 2026 -0700 bpf: don't rewrite bpf_fastcall patterns entered by a jump 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 commit 54ed91950363c116bec9be1b7015ff2bfa989950 Author: Eduard Zingerman Date: Thu Sep 3 10:15:41 2026 -0700 selftests/bpf: check zero extension of an arena 32-bit cmpxchg Add a test to verify that destination register of a 32-bit cmpxchg operating on an arena pointer is explicitly zero extended. W/o patch #1 this did not happen. Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903171542.1438050-3-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov commit 1f3cd9719c40715a7d6328bdbef817d5731bf61c Author: Eduard Zingerman Date: Thu Sep 3 10:15:40 2026 -0700 bpf: update disasm.c to print BPF_PROBE_ATOMIC as atomics bpf_convert_ctx_accesses() rewrites an atomic on an arena pointer from BPF_STX | BPF_ATOMIC to BPF_STX | BPF_PROBE_ATOMIC, this patch adjusts print_bpf_insn() to print such instructions as regular atomics with a 'probe_' prefix (instead of printing them as BUG_XX). Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260903171542.1438050-2-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov commit 4814ed6406f3493bd554ad046da5f7fc04833571 Author: Eduard Zingerman Date: Thu Sep 3 10:15:39 2026 -0700 bpf: zero extend the result of an arena 32-bit cmpxchg 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 commit 00ef2248c5dae08548f7ceb6951b022f89905330 Merge: 6e2b571b0a5475 fd9beb8870736e Author: Jens Axboe Date: Thu Sep 3 19:48:07 2026 -0600 Merge tag 'nvme-7.3-2026-09-03' of git://git.infradead.org/nvme into block-7.3 Pull NVMe fixes from Keith: "- Harden the tcp host and target against malformed PDUs: reject C2HData for a non-read command, bound an over-long PDU before copying it, and reject unsolicited H2CData (Yehyeong, Shivam) - Fix circular locking on TLS queues (Xixin) - Fix a soft lockup when scanning sparse namespace ID space (Mohamed) - Fix racy access to the FDP placement id array (Kanchan) - RDMA host and target fixes for a double cleanup on the queue_rq error path and a queue leak when the connect backlog is exceeded (Xixin) - Authentication fixes: drain the target's expiry work before the SQ is freed, and release the DH-CHAP secret when parsing fails (Kazuki, Xu Rao) - Fix nvme-fc options double free when nvme_add_ctrl() fails (Niklas) - Add missing SRCU grace period to nvme_alloc_ns() error path (Tristan) - Skip zoned limits update when the zone info query failed (Chao) - Reject enabling a target namespace with no device path (Seokgyu) - Add opcode filtering for fault injection (Mohamed) - Drop the kernel-doc comments from nvme-tcp.h (Randy)" * tag 'nvme-7.3-2026-09-03' of git://git.infradead.org/nvme: (21 commits) nvme-tcp.h: drop kernel-doc comments, fix a few descriptions nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails nvmet: reject namespace enable without device path nvmet-auth: Synchronize timeout work during SQ teardown MAINTAINERS: update nvme entry nvmet-tcp: reject unsolicited H2CData PDUs nvme-tcp: defer TLS inline send to io_work nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvme-tcp: return -EPROTO for a C2HData on a write nvmet: print namespace IDs as unsigned 32bit value nvme: print namespace IDs as unsigned 32bit value nvme: remove stale namespaces by NSID range during scan nvme: add missing SRCU grace period in error path nvme-fabrics: fix DHCHAP secret leak on parse failure nvmet-rdma: fix queue leak when connect backlog is exceeded nvme: add opcode filtering for fault injection nvme: fix racy access to FDP placement id array nvme: set ns->head in nvme_alloc_ns_head nvme-rdma: fix -EIO cleanup order in queue_rq nvme: skip the zoned limits update if the zone info query failed ... commit bc35965f6940a9bf834d54187b6088b8eb09206d Merge: a500db7819c50d 97d34aa65c29cc Author: Linus Torvalds Date: Thu Sep 3 17:59:19 2026 -0700 Merge tag 'mm-hotfixes-stable-2026-09-03-17-45' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "18 hotfixes. 13 are cc:stable. 15 are for MM. All are singletons - please see the changelogs for details. There are no fixes (yet) for all the stuff we added in the most recent merge window. Hopefully a good sign" * tag 'mm-hotfixes-stable-2026-09-03-17-45' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/secretmem: properly account locked pages mm/mremap: reset unfaulted VMA page offset for MREMAP_DONTUNMAP MAINTAINERS: add Kiryl as a THP reviewer MAINTAINERS: cover all of RAID MAINTAINERS: mailmap: update entries for Thorsten Blum MAINTAINERS: remove Lorenzo as THP co-maintainer Revert "once: don't use a work queue to reset sleepable static key" mm/hugetlb: fix missing migratable flag on same-node hugetlb migration mm/mempolicy: fix sleeping allocation in alloc_pages_bulk_weighted_interleave() mm/huge_memory: transfer the pmd dirty bit to the folio on zap MAINTAINERS: add Lance Yang as a hung task detector co-maintainer userfaultfd: reset err to be 0 when move_pages_ptes succeeded mm: fix incorrect vm_flags usage when checking allowable orders for tmpfs mm/hugetlb: keep max_huge_pages when dissolving surplus folios mm/migrate_device: avoid out-of-bounds writes for compound folios mm/hugetlb_cgroup: call page_counter_set_max() outside VM_BUG_ON() memcg: make the v1 soft limit knob inert mm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio commit 39b23c1c40e1f73d2b94a09282cc476af647e438 Author: Joe Damato Date: Wed Sep 2 14:39:54 2026 -0700 bnxt_en: Prevent queue stop with deferred completions When the driver receives a burst of packets, it can mark a BD with the NO_CMPL bit to defer completions. The expectation is that the last packet in the ring will have this bit unset and the completion generated by that packet will cleanup that packet and the ones preceding it. This helps to reduce the number of completions fired. The suppressed completions are controlled by the driver and the number of packets with suppressed completions scales with the size of the ring. SW USO packets, on the other hand, have an upper bound on the maximum number of BDs which can be consumed which does not scale with the ring size. So, for small rings it is possible that: a burst of packets is handed to the driver, the driver defers completions for all of the packets because the number of free descriptors stays above the threshold in the driver. Then, a USO packet arrives, but the number of BDs available is not enough and the USO code exits early. In this case, you end up in a state where the ring is full of packets with their completions suppressed, which can cause the queue to stop and never be restarted. Assuming default CONFIG_MAX_SKB_FRAGS, this is only possible for small rings (<= 457 descriptors, below the driver default value) when a burst of packets fills the ring, followed by a large USO packet that can't fit. For larger rings, the delta between the completion suppression threshold and the BDs required for SW USO is large enough that completions will fire and this case is unreachable. This issue was pointed out by Sashiko and while it seems fairly unlikely given that the queue size must be small to trigger this, it is indeed possible. Fix this by tracking the last BD which deferred completions and centralizing the logic for deciding when to ring the doorbell. The NO_CMPL bit is now cleared in bnxt_txr_db_kick(), so every doorbell site is covered, including the SW USO early exit. This guarantees the ring always ends in a BD which generates a completion to clean it and wake the queue. Fixes: cc5d90667db8 ("net: bnxt: Implement software USO") Cc: # v7.1+: 4e15e89faac9: net: bnxt: ring the doorbell when SW USO exits early Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260902213956.4160615-1-joe@dama.to Signed-off-by: Jakub Kicinski commit a09ceadff95b0075a9b6a5d9dbeb6c1c5f311c60 Author: Lorenzo Bianconi Date: Tue Sep 1 11:21:24 2026 +0200 mailmap: add entries for Lorenzo Bianconi Add the active email address for Lorenzo Bianconi and map the old, no-longer-used addresses to it, so that git can attribute his contributions to a single identity. This is done to avoid bouncing emails sent to email addresses that are no longer active. Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260901-lorenzo-mailmap-v2-1-0ee832de0caf@kernel.org Signed-off-by: Jakub Kicinski commit b58d749633203d92c265317b45fccee555090352 Author: Ido Schimmel Date: Wed Sep 2 22:01:12 2026 +0300 tunnels: Drop stale dst when building an ICMP error for PMTUD Bridged UDP tunnels such as VXLAN and GENEVE build an ICMP error packet around an overlay packet if the packet is going to exceed the underlay path MTU. The ICMP error packet is then injected back into the Rx path with the source and destination addresses swapped, so that it will be delivered to the overlay source. If the overlay packet was routed to the UDP tunnel or locally generated, then it is already carrying a valid dst entry and this entry is not dropped when transforming the packet to an ICMP error packet. This causes the IP layer to reuse the dst entry, leading to the ICMP error packet being dropped or routed out of the UDP tunnel interface in case of forwarding. Prior to the blamed commit this could not happen, as skb_tunnel_check_pmtu() did not build ICMP errors for PACKET_HOST packets. Such packets were instead encapsulated and, unless the DF bit was set in the outer header, fragmented by the underlay. Fix this by making sure that the ICMP error packet does not have a valid dst entry, thereby forcing the IP layer to perform a route lookup. Adjust the bridged PMTU exception selftests accordingly. When the local sender in ns_a pings the overlay destination with a deadline (-w), ping exits on the first socket error before any reply is received and returns a non-zero exit code. The test therefore only passed because the ICMP error was never delivered. Use a packet count (-c) like the ns_c line above it, so that the ICMP error counts against the packet budget and the exit code depends on whether echo replies were received. This passes with and without the fix. Fixes: 8930424777e4 ("tunnels: Accept PACKET_HOST in skb_tunnel_check_pmtu().") Cc: stable@vger.kernel.org Reported-by: Laika Price Closes: https://lore.kernel.org/netdev/20260614-master-v3-1-9f5060ba1ed1@gmail.com/ Reported-by: Yaroslav Dudkov Closes: https://lore.kernel.org/netdev/20260901081825.287173-1-aroslavdudkov622@gmail.com/ Reported-by: Charles Bordet Closes: https://lore.kernel.org/netdev/aHVhQLPJIhq-SYPM@eldamar.lan/ Signed-off-by: Ido Schimmel Tested-by: Yaroslav Dudkov Reviewed-by: David Ahern Reviewed-by: Stefano Brivio Reviewed-by: Guillaume Nault Link: https://patch.msgid.link/20260902190112.4126199-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski commit 6a1094c34d176827b2b173e163dcc964a13af93f Author: XingWang Xiang Date: Wed Sep 2 17:43:17 2026 +0900 genetlink: pin family module during policy dump The generic netlink controller's policy dump keeps pointers to the target family's operation and policy tables in its callback state. A dump may be split across multiple skbs and remain pending after the initial request. Netlink pins the module which owns the dump callback, but in this case that is the controller's owner rather than the target family's owner. The target family can consequently be unregistered and its module unloaded while a policy dump is pending. Advancing the dump then dereferences policy memory from the unloaded module. Take a reference to the target family's module when the dump starts. Drop it from the error and done paths. This matches the lifetime for which the dump context retains the family and policy pointers. Fixes: d07dcf9aadd6 ("netlink: add infrastructure to expose policies to userspace") Cc: stable@vger.kernel.org Signed-off-by: XingWang Xiang Link: https://patch.msgid.link/20260902084317.4092542-1-v3rdant.xiang@gmail.com Signed-off-by: Jakub Kicinski commit 2ac174dfcdde399fa95ba889541fb5e688d8bb35 Author: Taylor Bates Date: Tue Sep 1 22:49:46 2026 -0400 mlxsw: spectrum_ptp: Fix napi_gro_receive() call from GC workqueue context Currently mlxsw_sp1_ptp_ht_gc_collect() is run from the PTP garbage-collection workqueue, rather than the NAPI poll context. For any unmatched PTP entries carrying an SKB, it calls mlxsw_sp1_ptp_unmatched_finish() -> mlxsw_sp1_ptp_packet_finish(). For ingress packets, this calls mlxsw_sp_rx_listener_no_mark_func(). The end of that function is the following: skb->protocol = eth_type_trans(skb, skb->dev); napi_gro_receive(mlxsw_skb_cb(skb)->rx_md_info.napi, skb); The napi pointer is one that was placed in the SKB control block when the trapped packet was received in the NAPI context. Later, when the GC reaps the unmatched entry (up to MLXSW_SP1_PTP_HT_GC_TIMEOUT later), the call to napi_gro_receive() mutates the NAPI instance's GRO list, which is unsafe if the poll is running concurrently on another CPU. In mlxsw_sp1_ptp_ht_gc_collect(), local_bh_disable() is called to prevent softirq processing, but this only applies to the local CPU. Additionally, its comment is stale. It states that mlxsw_sp1_ptp_unmatched_finish() invokes netif_receive_skb(). This has not been accurate since the referenced commit; this patch makes that comment accurate again. mlxsw_pci_napi_devs_init() calls netif_threaded_enable() on the NAPI RX net_device without any conditions. The NAPI instance's poll, which may be running concurrent to the GC, is running as an independently-scheduled kthread which may be on a different CPU. The call to local_bh_disable() does not guard against this. If a tx-timestamp timeout produces an unmatched entry (which can be easily reproduced by running ptp4l and waiting for a port to reach the UNCALIBRATED/SLAVE state) while the owning NAPI thread is in the middle of a poll on another CPU, both sides mutate the GRO list concurrently, as shown below: [39.846] port 1 (swp1): MASTER to UNCALIBRATED on RS_SLAVE list_add corruption. next->prev should be prev (ffff8d620faf4138), but was ffff8d624150f700. (next=ffff8d620faf4138). kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 1 UID: 0 PID: 539 Comm: napi/mlxsw_rx-0 Not tainted 6.18.48 #1-NixOS PREEMPT(lazy) Hardware name: Mellanox Technologies Ltd. MSN2410/VMOD0001, BIOS 4.6.5 09/13/2018 RIP: 0010:__list_add_valid_or_report+0x79/0xb0 RSP: 0018:ffffcdf8c0f27c08 EFLAGS: 00010246 RAX: 0000000000000075 RBX: ffff8d624150fd00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8d6315d1e540 RBP: ffff8d620faf4070 R08: 0000000000000000 R09: 00000000ffffdfff R10: ffffffffa5c60fe0 R11: ffffcdf8c0f27ab8 R12: 0000000000000003 R13: 000000000000003d R14: 00000000000001bc R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8d636f63f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562689a60c24 CR3: 000000015f224004 CR4: 00000000001726f0 Call Trace: gro_receive_skb+0xee/0x230 mlxsw_sp1_ptp_got_packet+0x61/0x140 [mlxsw_spectrum] mlxsw_core_skb_receive+0xdf/0x1b0 [mlxsw_core] mlxsw_pci_napi_poll_cq_rx+0x780/0x9d0 [mlxsw_pci] __napi_poll+0x31/0x1e0 napi_threaded_poll_loop+0x16b/0x1c0 napi_threaded_poll+0x71/0xa0 kthread+0xfb/0x260 ret_from_fork+0x22d/0x260 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: Fatal exception in interrupt The machinery that leads to this kernel panic has not been changed between 6.18.48 and mainline. This patch adds an ingress-delivery helper for the PTP packet_finish() path that calls netif_receive_skb() instead of napi_gro_receive(). netif_receive_skb(), unlike napi_gro_receive(), can be called from outside of the NAPI instance's poll context, which can occur at the call site for this path. RX stats accounting and the skb->dev assignment are still preserved; the only change is the delivery call itself. This removes GRO batching for any PTP event traffic received by the mlxsw trap, but given the relatively low volume of traffic characteristic of the protocol, and impact limited to only Spectrum-1 ASICs, this is an acceptable solution. Fixes: 1ba06ca96ca2 ("mlxsw: Switch to napi_gro_receive()") Signed-off-by: Taylor Bates Reviewed-by: Petr Machata Link: https://patch.msgid.link/20260902024949.2273997-1-tmbates12@gmail.com Signed-off-by: Jakub Kicinski commit efdfb1e27a3328085b79540dfe781d537b576ea1 Author: Zihan Xi Date: Tue Sep 1 10:59:04 2026 +0000 ipv4: fib: bound automatic table ID allocation fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment ("ip rule ... table 0") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0. Fixes: b801f54917b7 ("[NET]: Increate RT_TABLE_MAX to 2^32") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Ido Schimmel Signed-off-by: Zihan Xi Reviewed-by: Ido Schimmel Reviewed-by: Petr Vorel Link: https://patch.msgid.link/6f2f2a7a136aee005512a2e1ac8ede62ac8c7bb6.1788258884.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski commit b6dd676d320e6d3c57b84212b035336e03c55e7a Merge: adf50c47a47f0f 0c5cf62e72d7a6 Author: Jakub Kicinski Date: Thu Sep 3 16:55:02 2026 -0700 Merge branch 'net-bcmasp-fix-tx-ring-accounting-bugs' Danesh Petigara says: ==================== net: bcmasp: fix TX ring accounting bugs Two fixes for TX descriptor ring handling in the bcmasp driver: - tx_spb_ring_full() re-initialized next_index from intf->tx_spb_index on every loop iteration instead of advancing it, so it only ever checked a single descriptor slot regardless of cnt. This let bcmasp_xmit() proceed even when the ring didn't actually have enough free slots for the SKB's fragments. - bcmasp_xmit() only set txcb->last for the final fragment of an SKB, leaving stale true values in reused descriptor slots from a prior transmission. Combined with the ring-full miscount above, this could cause bcmasp_tx_reclaim() to treat a mid-SKB descriptor as the last one and free the sk_buff while later fragments were still in flight. Patch 1 clears txcb->last unconditionally before it is set, and patch 2 fixes the ring-full slot check to advance through each candidate slot. ==================== Link: https://patch.msgid.link/20260831184235.4133351-1-danesh.petigara@broadcom.com Signed-off-by: Jakub Kicinski commit 0c5cf62e72d7a666ee4da757e122dc1600df1ecc Author: Justin Chen Date: Mon Aug 31 11:42:35 2026 -0700 net: bcmasp: fix tx_spb_ring_full() checking same slot cnt times The loop initialised next_index from intf->tx_spb_index on every iteration, so incr_ring() always produced the same result and only one slot was ever tested. Move the initialisation before the loop so each iteration advances next_index and the function correctly checks that cnt consecutive descriptor slots are available before allowing a new transmission. Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by: Justin Chen Signed-off-by: Danesh Petigara Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260831184235.4133351-3-danesh.petigara@broadcom.com Signed-off-by: Jakub Kicinski commit 18e5e0ec0e9282c897e2aa81a3e43ccaee03b003 Author: Justin Chen Date: Mon Aug 31 11:42:34 2026 -0700 net: bcmasp: clear txcb->last before writing each descriptor bcmasp_xmit() only wrote txcb->last = true for the final fragment of an SKB; non-final fragments left the field untouched. If a descriptor slot was reused while it still held a stale true from a previous SKB (possible when tx_spb_ring_full() underreported fullness), bcmasp_tx_reclaim() would see last == true mid-SKB and call dev_consume_skb_any() prematurely, freeing the sk_buff while its remaining fragments were still in flight. Unconditionally clear txcb->last before the conditional set so every descriptor slot starts from a known false state regardless of what a prior transmission left behind. Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by: Justin Chen Signed-off-by: Danesh Petigara Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260831184235.4133351-2-danesh.petigara@broadcom.com Signed-off-by: Jakub Kicinski commit 97f8cb91a8c5658fe2ae6f5c2ff6e95474a5eb2f Author: Miguel Ojeda Date: Wed Aug 26 16:56:42 2026 +0200 drm/panic: clean new `clippy::needless_range_loop` lint for Rust 1.100.0 Starting with Rust 1.100.0 (expected 2026-11-12), Clippy warns: warning: the loop variable `i` is only used to index `self.decimals` --> drivers/gpu/drm/drm_panic_qr.rs:410:18 | 410 | for i in 0..len { | ^^^^^^ | note: for this index operation --> drivers/gpu/drm/drm_panic_qr.rs:411:13 | 411 | self.decimals[i] = (chunk % 10) as u8; | ^^^^^^^^^^^^^^^^ = help: for further information visit https://rust-lang.github.io/rust-clippy/main/index.html#needless_range_loop = note: `-W clippy::needless-range-loop` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::needless_range_loop)]` help: consider using an iterator | 410 - for i in 0..len { 410 + for in self.decimals.iter_mut().take(len) { | The lint did not trigger here before because it could not handle arrays behind a field access such as `self.decimals` -- Clippy was improved to catch those cases [1][2]. Thus clean the warning by iterating over a slice rather than using `take()` so that an out-of-range `len` still triggers the same bounds check as the indexed loop. Cc: stable@vger.kernel.org # Needed in 6.18.y and later. Link: https://github.com/rust-lang/rust-clippy/issues/16631 [1] Link: https://github.com/rust-lang/rust-clippy/pull/16634 [2] Assisted-by: LLM Reviewed-by: Alexandre Courbot Reviewed-by: Jocelyn Falempe Link: https://patch.msgid.link/20260826145642.43807-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda commit 6b2f3ab85fc7b2bdde3f01735847c5d4fe9f2942 Merge: edc5d19f9ffea5 99f5566a1a884d Author: Mark Brown Date: Thu Sep 3 22:51:43 2026 +0100 ALSA/ASoC: Intel: avs: HDAudio bus and general fixes Cezary Rojewski says: The first half of the patchset concentrates on the driver initialization procedure - a number of steps do not clean up after themselves when they fail. This is for both, HDAudio bus (ext) and the DSP part (avs) and targets following procedures: - stream initialization - link initialization - bus initialization The next five are loosely related fixes. First, split topology-loading error handling from request-firmware one. Currently -ENOENT coming from topology-loading, which is a real error, is ignored. Second, with deeper test coverage around corrupted firmware/DSP exception handling, new issues are unearthed. Switch to async d0ix_work cancellation to avoid deadlock when D0IX has been scheduled just before the recovery work. The 09/10 patch, init_config change fixes possible out-of-bounds bug. The fix is larger than what one could expect as instead of patching with if-statements I've decided to refactor the parsing of init_configs. The scenario that causes the problem no longer exists. Note: the solution does not impose any changes on the existing topology files (userspace). The remaining two, IMHO are self-explanatory. [1]: https://lore.kernel.org/all/tencent_8E5BBBD19D53B1EFCDB6E89F3B6246A70B06@qq.com/ Link: https://patch.msgid.link/20260902081814.1590883-1-cezary.rojewski@intel.com commit 99f5566a1a884de4a400230835658ada4af6e001 Author: Cezary Rojewski Date: Wed Sep 2 10:18:14 2026 +0200 ASoC: Intel: avs: hda: Constrain MSBs on startup Front-end DAI links are marked as dynamic for the card thus the __soc_pcm_open() function never gets to soc_pcm_apply_msb() step which performs MSBs-constraint rule. Do that on link startup instead. Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-11-cezary.rojewski@intel.com Signed-off-by: Mark Brown commit 681e91035dc794896a904852040837190e5041f5 Author: Cezary Rojewski Date: Wed Sep 2 10:18:13 2026 +0200 ASoC: Intel: avs: Refactor and fix init_config access Existing code accesses enties found in ->init_configs array through indexes that are part of ->config_ids array. Those two are limited by: ->num_init_configs and ->num_config_ids respectively. Using ID larger or equal to ->num_init_configs leads to out-of-bounds access: avs_path_module_send_init_configs() loop: (...) &acomp->tplg->init_configs[ids[i]] ^ out-of-bounds candidate Rather than adding another if-statement, refactor the code. There is no need to store the IDs, have a list of pointers to actual config-entries instead. As the verification of ->init_config entries does not differ from verification of other types that are part of the topology.c file, simply reuse the code. Fixes: 8a49ef789b1b ("ASoC: Intel: avs: Send initial config to module if present") Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-10-cezary.rojewski@intel.com Signed-off-by: Mark Brown commit d4fa6f94b91137e329ea3f5b360e140b227bb696 Author: Cezary Rojewski Date: Wed Sep 2 10:18:12 2026 +0200 ASoC: Intel: avs: Fix unbalanced module reference count strace_open() invokes try_module_get() which on success takes the module reference. If any follow up operation causes strace_open() to fail, the refcount shall be put down. Fixes: 0a5fb3cc28fd ("ASoC: Intel: avs: Keep module refcount up when gathering traces") Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-9-cezary.rojewski@intel.com Signed-off-by: Mark Brown commit 363a6969f7f875b461236bf520d35f35c3b0e5b1 Author: Cezary Rojewski Date: Wed Sep 2 10:18:11 2026 +0200 ASoC: Intel: avs: Cancel d0ix_work asynchrounously during recovery Tests with corrupted firmware binaries prove that the recovery procedure can hit deadlock with d0ix_work if the work has been scheduled shortly before the event that triggered the recovery e.g.: timeouts on communication with a dead AudioDSP firmware. At the same time, the ready-check shall be done after acquiring the msg_mutex as the flag might have been modified by the time the lock is granted. The recovery case is one of such examples. Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-8-cezary.rojewski@intel.com Signed-off-by: Mark Brown commit c6dceca9f78fbd478c41735457c4de9c25a6b1c8 Author: Cezary Rojewski Date: Wed Sep 2 10:18:10 2026 +0200 ASoC: Intel: avs: Do not ignore -ENOENT when loading a topology avs_load_topology() combines request_firmware() and snd_soc_tplg_component_load(). The fallback mechanism introduced for the HDAudio based boards honors -ENOENT and checks for a generic topology if no specific is found before giving up and failing the component probing. However, if -ENOENT is returned by the latter function - snd_soc_tplg_component_load() - is shall not be ignored. That means there is an actual problem with the topology file and no fallback shall be attempted. Fixes: 739c031110da ("ASoC: Intel: avs: Provide support for fallback topology") Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-7-cezary.rojewski@intel.com Signed-off-by: Mark Brown commit f4ba00bb56a8511bafbd19826501d27157141c6d Author: Cezary Rojewski Date: Wed Sep 2 10:18:09 2026 +0200 ASoC: Intel: avs: Clean up streams if their initialization fails When streams are being initialized the memory allocation may fail. Have an error path and return early if that is the case. Fixes: 1affc44ea5dd ("ASoC: Intel: avs: PCI driver implementation") Co-developed-by: Amadeusz Sławiński Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown commit 559ea14b7ae7c7562b48759fa545b64958f35b73 Author: Cezary Rojewski Date: Wed Sep 2 10:18:08 2026 +0200 ASoC: Intel: avs: Clean up the bus when fetching ML caps fails snd_hdac_ext_bus_get_ml_capabilities() may fail and its return code shall be checked and accounted for. Address the issue by updating the error-path for avs_pci_probe(). At the same time, if the function in question succeeds but the next part of avs_pci_probe() fails, the hlink list shall be cleaned up before leaving the scope. Fixes: 1affc44ea5dd ("ASoC: Intel: avs: PCI driver implementation") Co-developed-by: Amadeusz Sławiński Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-5-cezary.rojewski@intel.com Signed-off-by: Mark Brown commit ce4d7356660ab7f8fd7c3119c16fef5c9b9adec9 Author: Cezary Rojewski Date: Wed Sep 2 10:18:07 2026 +0200 ASoC: Intel: avs: Clean up the bus when its initialization fails snd_hdac_i915_init() which is part of the initialization may return -EPROBE_DEFER what fails the procedure and the existing avs_bus_init() and avs_pci_probe() do not clean up the bus fields with snd_hdac_ext_bus_exit() when that happens. Fix avs_bus_init() by rearranging the initialization blocks: allocations first, snd_hdac_ext_bus_init() last. Such approach generates no error-path whilst still achieving the goal of cleaning up the bus. For avs_pci_probe() update the existing error-path instead. Co-developed-by: Amadeusz Sławiński Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown commit 48afc07c4f1b9c3cdbe66ddc3e7677ed395ce75f Author: Cezary Rojewski Date: Wed Sep 2 10:18:06 2026 +0200 ALSA: hda: ext: Clean up streams if their initialization fails snd_hdac_ext_stream_init_all() does not rollback changes done when the allocation fails. Fix that to simplify its usage. Signed-off-by: Cezary Rojewski Acked-by: Takashi Iwai Link: https://patch.msgid.link/20260902081814.1590883-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown commit 35af118326b22d840a3be271daa080728844cc4d Author: Cezary Rojewski Date: Wed Sep 2 10:18:05 2026 +0200 ALSA: hda: ext: Clean up links if their initialization fails snd_hdac_ext_bus_get_ml_capabilities() allocates the hlink nodes one-by-one but the procedure may fails due to -ENOMEM in the middle of it. Clean up the list before returning the error code to simply the function usage. Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260902081814.1590883-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown commit fd9beb8870736e1c6a0b2351d88a161aaeb2b326 Author: Randy Dunlap Date: Sun Aug 30 23:05:01 2026 -0700 nvme-tcp.h: drop kernel-doc comments, fix a few descriptions Expand @fei into @feil and @feih because the field was split due to it not being 32-bit aligned. Struct member @hdr was described twice in struct nvme_tcp_rsp_pdu, so drop one of them. These structs are defined in a spec outside of the kernel, so kernel-doc comments for them aren't needed here as well. This avoids kernel-doc warnings: Warning: include/linux/nvme-tcp.h:95 struct member 'rsvd2' not described in 'nvme_tcp_icreq_pdu' Warning: include/linux/nvme-tcp.h:113 struct member 'rsvd' not described in 'nvme_tcp_icresp_pdu' Warning: include/linux/nvme-tcp.h:128 struct member 'feil' not described in 'nvme_tcp_term_pdu' Warning: include/linux/nvme-tcp.h:128 struct member 'feiu' not described in 'nvme_tcp_term_pdu' Warning: include/linux/nvme-tcp.h:128 struct member 'rsvd' not described in 'nvme_tcp_term_pdu' Warning: include/linux/nvme-tcp.h:169 struct member 'rsvd' not described in 'nvme_tcp_r2t_pdu' Warning: include/linux/nvme-tcp.h:187 struct member 'rsvd' not described in 'nvme_tcp_data_pdu' Signed-off-by: Randy Dunlap Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch commit 56e6279266f6962bb2d38a54397e3c605165b0c5 Author: Niklas Cassel Date: Fri Aug 14 16:38:34 2026 +0200 nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails nvmf_create_ctrl() owns the fabrics options and frees them whenever ->create_ctrl() returns an error, so a transport must not free them on its own error paths. nvme-fc tracks this by testing ctrl->ctrl.opts in nvme_fc_ctrl_free(), which requires nvme_fc_init_ctrl() to clear that pointer on every error exit. The coupling is implicit, and commit 1a9e218195a5 ("nvme: split device add from initialization") broke it by adding a second error exit. When nvme_add_ctrl() fails, nvme_fc_init_ctrl() jumps to out_put_ctrl:, past the "ctrl->ctrl.opts = NULL" that only sits on the fail_ctrl: path, so nvme_fc_ctrl_free() frees the options and nvmf_create_ctrl() frees them a second time: BUG: KASAN: slab-use-after-free in nvmf_free_options+0x30/0x190 nvmf_free_options+0x30/0x190 drivers/nvme/host/fabrics.c:1284 nvmf_create_ctrl drivers/nvme/host/fabrics.c:1374 [inline] Freed by task 5534: nvme_fc_ctrl_free drivers/nvme/host/fc.c:2374 [inline] nvme_fc_init_ctrl+0xe17/0x1450 drivers/nvme/host/fc.c:3605 nvme_add_ctrl() fails when dev_set_name() cannot allocate, so this is reachable under memory pressure or fault injection. Without KASAN the options are freed twice. Rather than clear the pointer on the second exit as well, derive ownership the way nvme-tcp, nvme-rdma and nvme-loop do, from list membership: their free_ctrl leaves the options alone unless the controller made it onto the transport list. The list cannot simply be populated on the success path as it is there. nvme-fc runs the initial connect synchronously via flush_delayed_work(), and the controller has to be reachable on rport->ctrl_list for the whole of it: nvme_fc_unregister_remoteport() needs to find it to signal connectivity loss, nvme_fc_match_disconn_ls() matches an incoming Disconnect Association LS against ctrl->association_id, which is only assigned during that window, nvme_fc_resume_controller() needs it on remoteport re-registration, and nvme_fc_existing_controller() uses it to reject a duplicate connect racing the one in flight. Keep the insertion where it is and add a fail_unlist: label, falling into fail_ctrl:, for the error paths that run after it. The earlier error paths never reach the insertion and keep using fail_ctrl: directly, so the list is only touched where the controller is actually on it. nvme_fc_ctrl_free() cannot use the plain "goto free_ctrl" the other transports use, because it still has to put_device(), release the rport reference and free the ida entry for resources taken before the insertion. Sample list_empty() under rport->lock instead. ctrl->ctrl.opts also stays valid for the whole teardown now. That is not the bug being fixed, but it removes some fragility around the old idiom: nvme_free_ctrl() calls nvme_auth_free() before ->free_ctrl(), and ctrl_max_dhchaps() dereferences ctrl->opts without a NULL check when ctrl->dhchap_ctxs is set, which nvme-fc permits since NVMF_ALLOWED_OPTS allows the dhchap options. The nvme sysfs attributes that dereference ctrl->opts, such as hostnqn and address, evaluate their is_visible() test once at device_add() time and stay readable until cdev_device_del(). Fixes: 1a9e218195a5 ("nvme: split device add from initialization") Cc: stable@vger.kernel.org Reported-by: syzbot+f58e57380a6083c4041d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f58e57380a6083c4041d Signed-off-by: Niklas Cassel Tested-by: Rihyeon Kim Reviewed-by: Hannes Reinecke Signed-off-by: Keith Busch commit 09d0c07bd9ce3b2f2d993f672698d32a17543c32 Author: Seokgyu Choi Date: Thu Aug 27 07:52:21 2026 +0000 nvmet: reject namespace enable without device path A newly allocated namespace has a NULL device_path until userspace configures the device_path attribute. If buffered_io is enabled before device_path is configured, nvmet_bdev_ns_enable() returns -ENOTBLK and nvmet_ns_enable() falls back to nvmet_file_ns_enable(). The latter passes the NULL device_path to filp_open(), causing a NULL pointer dereference in getname_kernel(). Reject namespace enable when device_path has not been configured. Reported-by: syzbot+f613f9f010ec98eb9d86@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f613f9f010ec98eb9d86 Signed-off-by: Seokgyu Choi Reviewed-by: Sagi Grimberg Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch commit eaa948c0e19b1bb2d93262207bca0c3d19cc3406 Author: Kazuki Hanai Date: Sun Aug 30 22:11:05 2026 +0900 nvmet-auth: Synchronize timeout work during SQ teardown nvmet_auth_sq_free() cancels auth_expired_work with cancel_delayed_work(). If the work has already started, cancellation does not wait for the callback. Transport teardown can consequently free or reuse the queue containing struct nvmet_sq while nvmet_auth_expired_work() still accesses that SQ. Add a teardown-specific helper that synchronously drains the delayed work before freeing authentication state, and use it from nvmet_sq_destroy(). Keep the non-synchronous helper for in-band authentication state cleanup, where the SQ owner remains alive. Fixes: 1a70200f404a ("nvmet-auth: expire authentication sessions") Cc: stable@vger.kernel.org Signed-off-by: Kazuki Hanai Reviewed-by: Sagi Grimberg Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch commit 5cdd07a6882504c4b6e61169cce79e0720f77fca Author: Keith Busch Date: Tue Sep 1 09:46:31 2026 -0700 MAINTAINERS: update nvme entry Update Jens' entry to match the mail address of his other entries. Acked-by: Jens Axboe Signed-off-by: Keith Busch commit db62b35cbca052860c519cbcabe7650708528738 Author: Shivam Kumar Date: Thu Aug 27 15:24:55 2026 -0400 nvmet-tcp: reject unsolicited H2CData PDUs nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the "list_add double add" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable@vger.kernel.org Reviewed-by: Sagi Grimberg Signed-off-by: Shivam Kumar Signed-off-by: Keith Busch commit 08acb54b063a33730eb1ae1e0f89bf36542bac9f Author: Xixin Liu Date: Wed Aug 19 08:50:00 2026 +0800 nvme-tcp: defer TLS inline send to io_work blk_mq holds set->srcu while queuing and running requests. The kTLS software send path takes ctx->tx_lock. lockdep knows that tx_lock nests under elevator_lock which then waits on srcu, so an inline send from that path under TLS triggers circular locking. Skip the inline send optimization for TLS queues so the send runs from the workqueue instead. The same workqueue already retries TLS sends on write-space notifications. Plain TCP keeps the inline path. Fixes: be8e82caa685 ("nvme-tcp: enable TLS handshake upcall") Reviewed-by: Hannes Reinecke Signed-off-by: Xixin Liu Signed-off-by: Keith Busch commit 14cc5a7e77731497d5bea70f3bb05df7eda982e4 Author: Shivam Kumar Date: Fri Aug 14 15:48:11 2026 -0400 nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as queue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Shivam Kumar Cc: stable@vger.kernel.org Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch commit df7197ebc7280be9f34dfee9757a933ef0b18741 Author: Yehyeong Lee Date: Sun Aug 23 16:46:16 2026 +0900 nvme-tcp: return -EPROTO for a C2HData on a write The direction check in nvme_tcp_handle_c2h_data() returns -EIO. A C2HData PDU naming a command that did not ask for data is a protocol violation, and the check that rejects a PDU on those grounds a few lines below it - SUCCESS set without LAST - returns -EPROTO. No caller distinguishes the two, so this changes the error code alone. Suggested-by: Sagi Grimberg Signed-off-by: Yehyeong Lee Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch commit 59fe1cbc57235495a5f08dd53db176e3e3250356 Author: Mohamed Khalfella Date: Fri Aug 21 16:03:10 2026 -0700 nvmet: print namespace IDs as unsigned 32bit value struct nvmet_ns.nsid is a u32, but a few messages print it with %d. An NSID larger than 0x7fffffff is rendered as a negative number, which is misleading in general and particularly so for the configfs messages that echo back the NSID the user just asked for. For example: [ T200] nvmet: adding nsid -16 to subsystem mysubsystem Print them with %u. The invalid-NSID error in nvmet_ns_make() keeps its %#x because the two values it rejects, 0 and NVME_NSID_ALL, are more readable in hex format. No functional change other than how the NSID is formatted. Fixes: a07b4970f464 ("nvmet: add a generic NVMe target") Fixes: c6925093d0b2 ("nvmet: Optionally use PCI P2P memory") Fixes: 5a47c2080a73 ("nvmet: support reservation feature") Signed-off-by: Mohamed Khalfella Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch commit b2d8f2a3723103abd0f8b388691ad95817d4fff4 Author: Mohamed Khalfella Date: Fri Aug 21 16:03:09 2026 -0700 nvme: print namespace IDs as unsigned 32bit value NSIDs are 32-bit unsigned values, but a number of log messages print them with %d. An NSID larger than 0x7fffffff is rendered as a negative number, which is confusing in the kernel log and makes the message hard to correlate with the namespace it talks about. Sparse NSID spaces where high NSIDs are common are the most likely to hit this. The nsid sysfs attribute has the same problem, and there it is worse because userspace parses the value. For example: $ grep . /sys/class/block/nvme0*/nsid /sys/class/block/nvme0c0n1/nsid:10 /sys/class/block/nvme0c0n2/nsid:-16 /sys/class/block/nvme0c0n3/nsid:11 /sys/class/block/nvme0c0n4/nsid:-2000000016 /sys/class/block/nvme0n1/nsid:10 /sys/class/block/nvme0n2/nsid:-16 /sys/class/block/nvme0n3/nsid:11 /sys/class/block/nvme0n4/nsid:-2000000016 $ Print all of them with %u. Several messages in these files, including two in zns.c right next to the ones being changed, already use %u, so this only makes the rest consistent with them. No functional change other than how the NSID is formatted. Fixes: 2b9b6e86bca7 ("NVMe: Export namespace attributes to sysfs") Fixes: 1d5df6af8c74 ("nvme: don't blindly overwrite identifiers on disk revalidate") Fixes: ed754e5deeb1 ("nvme: track shared namespaces") Fixes: 9ad1927a3bc2 ("nvme: always search for namespace head") Fixes: 71010c309454 ("nvme: implement multiple I/O Command Set support") Fixes: 2f4c9ba23b88 ("nvme: export zoned namespaces without Zone Append support read-only") Fixes: 0ec84df4953b ("nvme-core: check ctrl css before setting up zns") Fixes: 2079f41ec6ff ("nvme: check that EUI/GUID/UUID are globally unique") Fixes: ce8d78616a6b ("nvme: warn about shared namespaces without CONFIG_NVME_MULTIPATH") Fixes: ac522fc6c316 ("nvme: don't reject probe due to duplicate IDs for single-ported PCIe devices") Signed-off-by: Mohamed Khalfella Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch commit 4ed7f3d7d435bf5b63da2814dc9270f5ba896011 Author: Mohamed Khalfella Date: Sat Aug 22 17:46:41 2026 -0700 nvme: remove stale namespaces by NSID range during scan nvme_scan_ns_list() drops the stale namespaces in each gap in the reported NSID list one NSID at a time. Every iteration calls nvme_find_get_ns() to look the namespace up and removes it if it is present. The loop runs once per NSID in the gap rather than once per namespace actually present. NSIDs are 32-bit, so a target with a sparse NSID space can make a single gap spin the loop billions of times with nothing to remove. watchdog: BUG: soft lockup - CPU#4 stuck for 26s! Workqueue: nvme-wq nvme_scan_work [nvme_core] RIP: 0010:__srcu_read_unlock+0xb/0x20 Call Trace: nvme_find_get_ns+0x7d/0xb0 [nvme_core] nvme_scan_ns_list+0xe8/0x280 [nvme_core] nvme_scan_work+0x18a/0x280 [nvme_core] process_one_work+0x197/0x380 worker_thread+0x2fe/0x410 kthread+0xe0/0x100 Rename nvme_remove_invalid_namespaces() to nvme_remove_nsid_range() and give it an open (start, end) NSID range. ctrl->namespaces is sorted by NSID, so the whole gap is dropped in a single walk that stops once end is reached. This bounds the work by the namespaces that are present instead of by the size of the gap. Fixes: 540c801c65eb ("NVMe: Implement namespace list scanning") Signed-off-by: Mohamed Khalfella Reviewed-by: Sagi Grimberg Reviewed-by: Randy Jennings Signed-off-by: Keith Busch commit ef248d5de4469fb6bbaf8dbe0c4c47800080d648 Author: Tristan Madani Date: Sat Aug 15 00:14:27 2026 +0000 nvme: add missing SRCU grace period in error path nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs. The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path. Fixes: ed754e5deeb1 ("nvme: track shared namespaces") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Reviewed-by: Sagi Grimberg Reviewed-by: John Garry Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch commit afdee49a1b88ed9bb44e2b30e855297c169bcc53 Author: Xu Rao Date: Thu Aug 13 16:31:07 2026 +0800 nvme-fabrics: fix DHCHAP secret leak on parse failure nvmf_parse_options() duplicates dhchap_secret and dhchap_ctrl_secret with match_strdup() before validating the DHHC-1: representation. If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchap_secret or opts->dhchap_ctrl_secret. nvmf_create_ctrl() subsequently frees opts, but nvmf_free_options() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation. This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace. With CONFIG_NVME_HOST_AUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing dhchap_secret=BAD or dhchap_ctrl_secret=BAD to /dev/nvme-fabrics deterministically takes the leaking parse path. Free the temporary string before leaving both validation error paths. Use kfree_sensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets. Fixes: f50fff73d620 ("nvme: implement In-Band authentication") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Xu Rao Signed-off-by: Keith Busch commit a500db7819c50db59e55f1b4fa1c3baa5a2616f3 Merge: 36b03c3e270a2a 4299767d772d4e Author: Linus Torvalds Date: Thu Sep 3 13:36:21 2026 -0700 Merge tag 'selinux-pr-20260903' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux Pull SELinux fixes from Paul Moore: "Two SELinux fixes: one to fix how we lookup a BPF token's creator label to prevent a possible TOCTOU, and one to update Ondrej's email address" * tag 'selinux-pr-20260903' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux: MAINTAINERS, mailmap: update email address for Ondrej Mosnáček selinux: fix BPF token permission checks commit 4299767d772d4e498998e32157e45841178ab192 Author: Ondrej Mosnáček Date: Thu Sep 3 17:56:15 2026 +0200 MAINTAINERS, mailmap: update email address for Ondrej Mosnáček I'm going to use my personal email for kernel contributions from now on. Update MAINTAINERS and .mailmap to reflect this. Also switch to use proper spelling with diacritics, since I normally use the full Unicode name with my personal email address. I'm leaving in-code occurences unchanged though, as that would be just unnecessary churn. Link: https://lore.kernel.org/lkml/CAFqZXNvOGbzy8-ZnJtKi94jfu2H173Tz7VYpK8KuseMQS-9tNA@mail.gmail.com/ Signed-off-by: Ondrej Mosnáček Signed-off-by: Paul Moore commit 0e68c74e44da81a4599c52437ee1f63a2c234470 Author: Matthew Auld Date: Wed Sep 2 13:41:20 2026 +0100 drm/xe/vram: report FLAT_CCS base misalignment So we can easily check if a machine had the CCS bug, when looking back over bug reports where we have the same machine with newer kernel. Example print for a machine with the CCS bug: FLAT_CCS base:27bbff800, aligned:no v2 (Matt B): - Unconditionally print the base + alignment Fixes: 37173392741c ("drm/xe/vram: fix ccs offset calculation") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: Rodrigo Vivi Cc: stable@kernel.org Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260902124117.918018-9-matthew.auld@intel.com (cherry picked from commit d00b7f4f03bbeb2efad872f1686130e18c2b4141) Signed-off-by: Rodrigo Vivi commit 36b03c3e270a2a4cf73202e07a93bd3a9ebd86c7 Merge: 841e384b841a3d 4a819ee5f28343 Author: Linus Torvalds Date: Thu Sep 3 12:17:52 2026 -0700 Merge tag 'acpi-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fix from Rafael Wysocki: "Drop two structure fields that have no more users after recent changes" * tag 'acpi-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: bus: Drop two fields from struct acpi_device_pnp commit 6c001a62c34f13fe1c6a24304c289b387d9e697d Author: Steven Rostedt Date: Thu Sep 3 13:27:28 2026 -0400 ring-buffer: Add checking nr_subbufs to persistent ring buffer validation 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 commit 97d34aa65c29cca85e3e9050f4c936389b38a054 Author: Lorenzo Stoakes (ARM) Date: Wed Aug 26 17:30:35 2026 +0100 mm/secretmem: properly account locked pages secretmem accounts folios by treating memory as if it were mlock()'d and thus limited by the RLIMIT_MEMLOCK limit. However the folios are unevictable and remain so until the inode is evicted, eliminating usual mlock() semantics - mapping folios then unmapping them does not clear their unevictable state, since it depends on AS_UNEVICTABLE, not PG_mlocked. A user can therefore easily work around the RLIMIT_MEMLOCK limit - simply map then unmap and VmLck no longer counts the secretmem range. Worse, folios are not accounted in the process's RSS, meaning the OOM killer won't know to kill the process. Repeatedly mapping/unmapping (or forking) can then result in the consumption of all available system memory with unevictable folios and cause system instability. A secretmem fd can be passed between processes and over fork so a per-process limit simply does not make sense, so follow the precedent set by io_uring, perf, skbuff, iommufd and xdp by tracking the number of locked pages in user_struct->locked_vm. Since the scope tracked is actually inode lifetime, the RLIMIT_MEMLOCK applies per-user not per-process, so it doesn't make sense to bypass for users with CAP_IPC_LOCK, therefore remove this bypass. There is simply no reason to carry on marking the mapping as mlock()'d since it's misleading and the lifecycle is now correctly handled, so remove this too. Note that secretmem does not support any form of truncation (including hole punching) and the folios are unreclaimable, so the folios need only be accounted on fault and unaccounted on inode destruction. __secretmem_account_pages() is more or less a duplicate of the code that io_uring etc. use, but since this is a bug fix that needs backporting, defer any de-duplication efforts to a follow-up. test_mlock_limit() asserts mlock_future_ok() on mmap(), however this has been removed, so remove the test altogether for the fix. A new test will be sent separately for upstream. Link: https://lore.kernel.org/20260826-secretmem-accounting-v3-1-94cb04399510@kernel.org Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: Daehyeon Ko <4ncienth@gmail.com> Closes: https://lore.kernel.org/linux-mm/20260813225328.2010303-1-4ncienth@gmail.com/ Reviewed-by: Mike Rapoport (Microsoft) Acked-by: David Hildenbrand (Arm) Tested-by: Daehyeon Ko <4ncienth@gmail.com> Cc: Alexei Starovoitov Cc: David Hildenbrand Cc: David S. Miller Cc: Hagen Paul Pfeifer Cc: Jakub Kacinski Cc: James Bottomley Cc: Jesper Dangaard Brouer Cc: John Fastabend Cc: Liam R. Howlett Cc: Michal Hocko Cc: Stanislav Fomichev Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton commit 35b0fb391b0df57383bc15985bb769f4555c97ba Author: Lorenzo Stoakes (ARM) Date: Tue Aug 25 08:55:26 2026 +0100 mm/mremap: reset unfaulted VMA page offset for MREMAP_DONTUNMAP Uniquely an mremap() invocation using the MREMAP_DONTUNMAP flag can reset a faulted VMA into an unfaulted one. It does so after the page tables have been moved to the copied VMA with MREMAP_DONTUNMAP leaving the old VMA in place which is naturally unfaulted as the page tables it had are no longer present. However, in doing so, it violates the invariant that the anonymous page offset of an unfaulted VMA is vma->vm_start >> PAGE_SHIFT. This is because a VMA may have been faulted in, mremap()'d (causing a delta between its page offset and vma->vm_start >> PAGE_SHIFT), and then mremap()'d again with MREMAP_DONTUNMAP resulting in the unfaulting. This condition is a violation of a fundamental assumption in mm, but now also triggers an assert in assert_sane_pgoff() which explicitly checks for this condition. Correct it by resetting the VMA's page offset at the point of completing the MREMAP_DONTUNMAP operation. Link: https://lore.kernel.org/20260825-fix-mremap-dontunmap-pgoff-v1-1-39a40b2c98b3@kernel.org Fixes: 1583aa278f5f ("mm: mremap: unlink anon_vmas when mremap with MREMAP_DONTUNMAP success") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a87853b.ae6ddae5.3da009.0023.GAE@google.com/ Tested-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com Acked-by: Vlastimil Babka (SUSE) Reviewed-by: Kunwu Chan Reviewed-by: Pedro Falcato Cc: Jann Horn Cc: Liam R. Howlett Cc: Li Xinhai Cc: Signed-off-by: Andrew Morton commit ed334880e5e6855820855d76f594d973747cbf8a Author: Kiryl Shutsemau (Meta) Date: Thu Aug 27 11:34:35 2026 +0100 MAINTAINERS: add Kiryl as a THP reviewer I have been working on transparent hugepages since 2012, starting with the huge zero page and file-backed THP. A lot of the code that causes pain now traces back to me. It is only fair if I share the review load for THP. Add myself to the reviewer list so get_maintainer.pl puts me on Cc: as well. It is also my commitment to be more active in reviewing this code. Link: https://lore.kernel.org/20260827103435.1371882-1-kas@kernel.org Signed-off-by: Kiryl Shutsemau (Meta) Acked-by: David Hildenbrand (Arm) Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Barry Song Acked-by: Zi Yan Reviewed-by: Lance Yang Acked-by: Usama Arif Acked-by: Baolin Wang Acked-by: SJ Park Cc: Dev Jain Cc: Liam R. Howlett Cc: Ryan Roberts Signed-off-by: Andrew Morton commit 70ded7a57443f41075625f29b9eb88dca154decb Author: Geert Uytterhoeven Date: Thu Aug 27 09:20:56 2026 +0200 MAINTAINERS: cover all of RAID While commit 3626738bc7147d52 ("raid6: move to lib/raid/") handled the move of RAID6, it didn't take into account there was already more RAID code under lib/raid/, as XOR got moved over in commit 9e229025e2474115 ("xor: move to lib/raid/") before. Link: https://lore.kernel.org/7a2e5de234cc0286e3fe9bc11b810433775f2280.1787815121.git.geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven Reported-by: Andrew Morton Closes: https://lore.kernel.org/20260826205058.a6ff019d0584f75c7f50430b@linux-foundation.org Cc: Christoph Hellwig Cc: Song Liu Cc: Yu Kuai Cc: Li Nan Cc: Xiao Ni Signed-off-by: Andrew Morton commit 0a85182723b65ad8bee8131bc38fcf0347d6679b Author: Wanwu Li Date: Thu Sep 3 14:06:26 2026 +0800 sched_ext: Fix NULL sched deref in kfunc sub-sched error paths When the root scheduler has sub-scheds attached, the COMPAT kfunc wrappers scx_bpf_select_cpu_and() and scx_bpf_dsq_insert_vtime() refuse the call and report to @p's scheduler: scx_error(scx_task_sched(p), "... must be used"); The wrappers are reachable with tasks that have no scheduler. scx_bpf_select_cpu_and() is in the select_cpu kfunc group, which scx_kfunc_context_filter() opens to BPF_PROG_TYPE_SYSCALL programs; scx_bpf_dsq_insert_vtime() is in the enqueue_dispatch group, which ops.enqueue() and ops.dispatch() may call with any KF_RCU task -- the group has no kf_tasks validation, and scx_dsq_insert_preamble() checks task ownership with scx_task_on_sched() precisely because @p may be an arbitrary task. scx_task_sched(p) is p->scx.sched, which is NULL for tasks past sched_ext_dead() -- which clears it via scx_disable_and_exit_task() on exit -- and for idle tasks, which the enable paths skip as they are never scheduled through SCX. It is also an rcu_dereference_protected() that expects @p's pi_lock or rq lock, which neither wrapper holds. Passing NULL to scx_error() reaches scx_vexit(), which dereferences sch->exit_info, oopsing the kernel. One concrete trigger exercised while developing the fix: a BPF_PROG_TYPE_SYSCALL program calling the select_cpu_and wrapper on an exited-but-not-reaped task while a sub-scheduler was attached (its pid stays findable while the zombie is unreaped; faulting instruction is the scx_vexit() prologue "mov r15,[rdi+0x398]" with RDI=NULL and 0x398 the offset of sch->exit_info): sched_ext: BPF scheduler "kfunc_subsched_null" enabled sched_ext: BPF sub-scheduler "kfunc_subsched_null" enabled sched_ext: Unassociated program run_select_cpu_ (id 76) BUG: kernel NULL pointer dereference, address: 0000000000000398 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 8201 Comm: kfunc_test_runn Tainted: G W RIP: 0010:scx_vexit+0x25/0xa0 Code: ... <4c> 8b bf 98 03 00 00 ... CR2: 0000000000000398 Call Trace: __scx_exit+0x4f/0x70 scx_bpf_select_cpu_and+0xab/0xb0 bpf_prog_430ed61a7b66e03a_run_select_cpu_and+0x9c/0xe7 ? __x64_sys_bpf+0x2c/0x40 bpf_prog_test_run_syscall+0x130/0x2f0 __sys_bpf+0x930/0x10d0 ? __x64_sys_bpf+0x2c/0x40 __x64_sys_bpf+0x2c/0x40 do_syscall_64+0xbc/0x460 entry_SYSCALL_64_after_hwframe+0x76/0x7e Read @p's scheduler under RCU instead, which the wrappers can do from their guard(rcu)(): fault it when it can be determined, and when it can't be determined -- @p is a task past sched_ext_dead() or an idle task -- there is nothing obviously wrong to report, so just refuse the call as before without faulting any scheduler. These COMPAT wrappers are scheduled for eventual removal once the deprecation grace period elapses, but until then -- and regardless of their removal timeline -- they must not oops the kernel on a task they are handed. Cc: stable@vger.kernel.org # v7.1+ Fixes: a5fa0708cbfd ("sched_ext: Enforce scheduling authority in dispatch and select_cpu operations") Suggested-by: Andrea Righi Signed-off-by: Wanwu Li Signed-off-by: Tejun Heo commit 841e384b841a3d89c50b4b2d6c5bb6abab1a7e39 Merge: adf50c47a47f0f 98d23edcd41432 Author: Linus Torvalds Date: Thu Sep 3 10:28:27 2026 -0700 Merge tag 's390-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Heiko Carstens: - Use jiffies instead of jiffies_64 to address a data-race reported by KCSAN - Unpoison cpacf instruction results to address KMSAN reports - Drop unused member from ap_device_id - Fix potential NULL pointer dereferences in IPL code - Add missing length check to SCLP error report handling - Add missing length check to zcrypt CCA code - Fix return code handling in diag324 code - Handle multiple PMU stop callback invocations in perf pai code correctly - Reduce excessive debug feature size in perf pai code from 32 MiB to 4KiB - Switch to common CPU capacity code in topology code to get rid of few lines of code - Address various bugs in corner cases in boot code - Simplify/Rework crst_table_upgrade() to address a potential NULL pointer dereference in case of an allocation failure - Initialize padding bytes in CRT key structure in zcrypt code * tag 's390-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/zcrypt: Fix uninitialized padding in CRT key structure s390/mm: Simplify crst_table_upgrade() s390/boot: Bound command line facility ranges s390/boot: Avoid IPL parameter append past command line s390/boot: Fix physical memory search range s390/topology: Switch to common cpu capacity code s390/pai: Reduce excessive debug feature size s390/pai: Handle multiple PMU stop callback invocations s390/diag324: Preserve -EBUSY return code s390/zcrypt: Validate length in reply before using it s390/pci: Fix leak of uninitialized kernel data in SCLP report s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block s390/ipl: Fix NULL deref in kdump without re-IPL parm block s390/ap: Drop unused member from ap_device_id s390/cpacf: Unpoison instruction results s390/time: Use jiffies instead of jiffies_64 commit adf50c47a47f0f0f0b79dd58ffade9919cddebea Merge: 8ab1afb2eb246a 66817a9794263c Author: Linus Torvalds Date: Thu Sep 3 10:18:12 2026 -0700 Merge tag 'net-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from bluetooth. Previous releases - regressions: - page_pool: keep frag_offset aligned for odd-sized requests - sched: fix u32 duplicate handle when node ID pool is exhausted - udp: create exceptions before socket matching - igmp: convert struct ip_sf_list to RCU - ip6_gre: check tunnel info before xmit in ip6gre_tunnel_xmit - rds: acquire the fastpath locks in rds_conn_shutdown() - tipc: - protect node reset trace dump with node lock - fix NULL deref in tipc_named_node_up() on empty publication list - bluetooth: - L2CAP: fix out-of-bounds write in l2cap_ecred_connect - hci_core: fix race condition during device registration - eth: - mlx5e: prevent stale XSK buffer release on refill retries - bridge: don't truncate the port group walk on teardown Previous releases - always broken: - gro: fix nesting of TCP GSO SKBs in skb_gro_receive_list() - sched: fix skb sizing and action leak on reoffload delete - tcp: fix use-after-free in do_tcp_getsockopt() - af_packet: don't cast tpacket_hdr.tp_len to int in tpacket_parse_header() - sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration - iptunnel: fix stale transport header during tunnel decapsulation - eth: - vxlan: fix use-after-free in vxlan_mdb_remote_src_del() - bonding: fix uninitialized transport header access in alb_determine_nd()" * tag 'net-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (83 commits) net: gro: Fix nesting of TCP GSO SKBs in skb_gro_receive_list() net: stmmac: reconfigure RX packet parser table in stmmac_hw_setup() after reset net: airoha: enable RX_DONE interrupt for RX queue 31 net/rds: don't let rds_conn_shutdown() consume a concurrent drop net/rds: acquire the fastpath locks in rds_conn_shutdown() net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() net/rds: tcp: don't force RDS_CONN_RESETTING over a concurrent shutdown net/rds: clear cp_flags bits individually in rds_conn_path_reset() net/rds: use clear_bit_unlock() in release_refill() net/rds: use wq_has_sleeper() in release_in_xmit() net: usb: qmi_wwan: add Compal EXM-G1x support net: macb: exclude software FCS from TX byte statistics net: Remove conflicting altnames for dying netns in __dev_change_net_namespace(). net: bridge: mcast: don't truncate the port group walk on teardown bonding: do not clear curr_active_slave prematurely when releasing all slaves net: qrtr: Send HELLO message on endpoint register octeontx2-af: Fix limiting SRIOV VF count logic bonding: alb: fix uninitialized transport header access in alb_determine_nd() s390/ctcm: Prevent XID null dereference net: psp: do not inherit the Rx association on clone ... commit 2b39d680c9e0fb4d625f2916980977622e84248c Author: Rob Herring (Arm) Date: Thu Aug 27 15:33:04 2026 -0500 accel: ethosu: Ensure SRAM region size matches job It is possible for userspace to set the job SRAM size to 0, but then still have SRAM accesses in the command stream. When the job SRAM size is 0, setting the region base register is skipped and a stale base address from a prior job is used. Check the region size against the job's SRAM size instead of just the size of the SRAM. The job's SRAM size was already checked against the total SRAM size. Fixes: 9cff90774872 ("accel: ethosu: Validate SRAM size on submit") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Link: https://patch.msgid.link/20260827-ethosu-fixes-v1-5-346f9ea8791c@kernel.org Signed-off-by: Rob Herring (Arm) commit f5376d7e0fb703876199d3b6f9f97e128fa2f8a4 Author: Rob Herring (Arm) Date: Thu Aug 27 15:33:03 2026 -0500 accel: ethosu: Ensure SRAM size is 0 on mapping failure On a mapping failure of the SRAM, the SRAM size is left as non-zero. The probe will succeed as the error return is not checked since having SRAM is not a hard requirement. The non-zero size allows jobs to access SRAM which is left pointing to physical base address 0x0. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Link: https://patch.msgid.link/20260827-ethosu-fixes-v1-4-346f9ea8791c@kernel.org Signed-off-by: Rob Herring (Arm) commit eb3a41fd35e352fba387c4320a1fa0352f3e551c Author: Rob Herring (Arm) Date: Thu Aug 27 15:33:02 2026 -0500 accel: ethosu: Ensure cmd stream ends with a stop op While the QSIZE register setting should prevent an out of bounds access of the command stream, it is not clear whether the h/w generates an interrupt in this case as is required (to prevent a timeout). As a stop op is expected end of the command stream, let's just ensure it is present. A stop op in the middle of the command stream also makes no sense. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Link: https://patch.msgid.link/20260827-ethosu-fixes-v1-3-346f9ea8791c@kernel.org Signed-off-by: Rob Herring (Arm) commit 2cbd3691565f7c86c0eaca305f5beb3435b4ba70 Author: Rob Herring (Arm) Date: Thu Aug 27 15:33:01 2026 -0500 accel: ethosu: Drop IRQF_SHARED flag The IRQF_SHARED flag doesn't work with runtime-pm as the IRQ handler could run without resuming the device. This could also be fixed with runtime-pm calls in the IRQ handler, but there is no known need for a shared IRQ. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Link: https://patch.msgid.link/20260827-ethosu-fixes-v1-2-346f9ea8791c@kernel.org Signed-off-by: Rob Herring (Arm) commit b3c8d4672f7a8735e2884cefcd89286268e88b2e Author: Rob Herring (Arm) Date: Thu Aug 27 15:33:00 2026 -0500 accel: ethosu: Fix ethosu_job_open() return value A WARN_ON() returns a 0 or 1, not the original negative errno. Just drop the WARN_ON() as the FD open will pass the return code to userspace and there's only one possible source of the error (drm_sched_entity_init()). Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Link: https://patch.msgid.link/20260827-ethosu-fixes-v1-1-346f9ea8791c@kernel.org Signed-off-by: Rob Herring (Arm) commit e044668419b9c444282bd09521f7ea07edbc10b1 Merge: 1329a7aa33848c 26a3a510cd3433 Author: Alexei Starovoitov Date: Thu Sep 3 09:44:56 2026 -0700 Merge branch 'misc-bug-fixes-part-1' Kumar Kartikeya Dwivedi says: ==================== Misc bug fixes - part 1 A set of miscellaneous fixes for bugs reported by Nicholas. These are easy ones and should not require any major discussion, hence batched together. See commit logs and selftests for details. ==================== Link: https://patch.msgid.link/20260903144433.1716731-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 26a3a510cd3433e15f37ea1d5a6f2c17a0170316 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:28 2026 +0200 selftests/bpf: Check syscall helpers in timer callbacks A BPF_PROG_TYPE_SYSCALL program is sleepable, but its bpf_timer callbacks run in a non-sleepable hrtimer softirq context. Add verifier cases that call bpf_sys_bpf() and bpf_sys_close() from timer callbacks. Without the syscall helper prototype annotations these programs load, so their failure expectations expose the bug. Also add successful controls that call each helper from the syscall program main body, ensuring that the intended sleepable use remains accepted. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-11-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit d05524794240b52fdc3b6c1220dd05505715824d Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:27 2026 +0200 bpf: Mark syscall helpers as sleepable 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 commit c1992ba73b0339166906eb2224494e04052a8150 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:26 2026 +0200 selftests/bpf: Test sched_process_wait nullable argument Add a load-time verifier test that dereferences argument 0 of the sched_process_wait tp_btf program without checking it. The test expects the nullable-pointer diagnostic, so it is accepted unexpectedly before the fix and rejected as expected after it. Add a successful control that checks the argument for NULL before the dereference. This ensures the nullable marking preserves legitimate access to the pid when the tracepoint supplies one. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-9-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit a453d6e3b8e8e1a321c8744d6189d763af9287d0 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:25 2026 +0200 bpf: Mark sched_process_wait argument as nullable do_wait() passes wo->wo_pid to the sched_process_wait tracepoint. kernel_wait4() leaves wo_pid NULL for wait4(-1), and kernel_waitid_prepare() does likewise for waitid(P_ALL). btf_ctx_access() currently types argument 0 as PTR_TO_BTF_ID | PTR_TRUSTED. Without PTR_MAYBE_NULL, the verifier accepts an unchecked dereference. Trusted pointer loads have no fault protection, so a wait for any child can then cause a NULL pointer dereference in JITed BPF code. Add sched_process_wait to raw_tp_null_args[] with argument 0 marked nullable. The verifier rejects an unchecked dereference while preserving access after the program checks the pointer for NULL. Fixes: 838a10bd2ebf ("bpf: Augment raw_tp arguments with PTR_MAYBE_NULL") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-8-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 08b4dc83d981bf9136d37aaa4f5cd021ba0d8f2b Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:24 2026 +0200 selftests/bpf: Reject resilient unlock in rbtree callback Add a load-only verifier regression for a resilient lock operation in an rbtree comparison callback. The program holds the rbtree's regular spin lock and a separate resilient lock, then releases the resilient lock from the callback. This isolates the missing kfunc policy check without running a concurrent tree mutation. Release the resilient lock before the regular lock on the outer fall-through. The broken verifier therefore accepts the balanced program, while the fixed verifier rejects the resilient unlock specifically while verifying the callback. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-7-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 7b7b8b5960102566bd625ae829d1f330c5b5d104 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:23 2026 +0200 bpf: Reject resilient lock operations in rbtree callbacks __bpf_rbtree_add() keeps parent and link pointers live across calls to the program-supplied comparison callback. The verifier therefore requires the root's lock to remain held throughout the callback. The helper path enforces this rule for bpf_spin_lock() and bpf_spin_unlock(), but the resilient lock kfunc argument path does not. Since resilient locks may protect BPF rbtree roots, a callback can release the root lock and let another CPU remove and free the node referenced by the in-progress tree walk. The walk then resumes using freed pointers. Reject resilient lock kfuncs in an rbtree comparison callback, matching the existing policy for the spin lock helpers. Resilient-lock-protected trees remain valid when their comparison callbacks leave lock state alone. Fixes: 0de2046137f9 ("bpf: Implement verifier support for rqspinlock") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-6-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit d9ae3e4c7fb5bfaccc9ca295692d54130862f3b2 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:22 2026 +0200 selftests/bpf: Test direct tail calls from callbacks tailcall_callback tests a tail call one static subprogram below a callback. That reaches the later stack-depth rejection, but it does not exercise the tail-call helper while the current frame is itself a callback. Add a callback that calls bpf_tail_call directly and expect the existing "cannot tail call within callback" diagnostic. On an affected kernel, the load instead reaches the "callback unexpected regs" verifier bug, so the expected message is absent and the test fails. The existing ordinary subprogram case remains a success control for legitimate tail calls. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-5-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 266aa4ad0b2e82397cd9045752c9bff03d98eddd Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:21 2026 +0200 bpf: Reject tail calls directly from callback frames A tail call from a non-zero frame is modeled as a return from that frame. The verifier makes R0 unknown and calls prepare_func_exit() for the taken branch. When the current frame is a synchronous callback, prepare_func_exit() enforces the callback return-value contract and marks R0 precise. Since the tail-call path synthesized R0 rather than deriving it from an instruction, precision backtracking reaches the callback-calling instruction with R0 still requested and triggers the "callback unexpected regs" verifier bug. A CAP_BPF task can therefore cause a WARN and an -EFAULT BPF_PROG_LOAD. Tail calls reachable from callbacks are already rejected later by check_max_stack_depth(). Reject a tail call made directly by a callback before constructing the inconsistent return state, using the existing diagnostic. Tail calls from ordinary subprograms keep their current behavior. Fixes: e3245f899043 ("bpf: properly verify tail call behavior") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-4-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit d7719a1736e6be77d0682f7395acd3701949f1fa Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:20 2026 +0200 selftests/bpf: Cover signal tracepoint siginfo sentinels Add load-only verifier coverage for the signal_generate and signal_deliver info arguments. The signal_generate case performs a NULL check before dereferencing info, ensuring that merely making it nullable cannot satisfy the test when the nonzero SEND_SIG_PRIV sentinel is used. Both programs load successfully without the verifier fix, contrary to their expected-failure annotations. With the fix, info is a scalar and the attempted dereferences are rejected. Also add success cases showing that plain raw tracepoint and tp_btf programs can continue to read and compare the context word as a scalar. Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-3-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 77515ab12e4983e6416f8c35039a3f0c0822ac70 Author: Kumar Kartikeya Dwivedi Date: Thu Sep 3 16:44:19 2026 +0200 bpf: Mark signal tracepoint siginfo arguments as scalar The signal_generate and signal_deliver tracepoints declare their info argument as a struct kernel_siginfo pointer. btf_ctx_access() therefore treats it as a trusted pointer for tp_btf programs. Signal delivery also uses SEND_SIG_NOINFO and SEND_SIG_PRIV as special values for this argument. Those values are zero and one respectively, and are not pointers. A tp_btf program can currently dereference either value and fault the kernel. In particular, signal_generate can run from timer interrupt context, turning the fault into a kernel panic. Record both tracepoints in raw_tp_null_args[] and mark argument one as a non-pointer. This preserves scalar access to the cookie while rejecting direct and helper-mediated pointer use. Merely marking it nullable would not suffice because SEND_SIG_PRIV is nonzero. Fixes: 838a10bd2ebf ("bpf: Augment raw_tp arguments with PTR_MAYBE_NULL") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260903144433.1716731-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov commit 1329a7aa33848c6f7e01eec9b9985086a44647d2 Merge: ac0aaef0aa997f 1ae6aa61958a0e Author: Alexei Starovoitov Date: Thu Sep 3 09:31:52 2026 -0700 Merge branch 'bpf-fix-null-ptr-derefs-when-showing-a-void-btf-type' Jiayuan Chen says: ==================== bpf: Fix NULL-ptr-derefs when showing a void BTF type This series fixes three NULL-ptr-derefs in BTF handling. Patch 1 handles the syzbot report. A key-less BTF (btf_key_type_id == 0) used to be rejected for hash maps, until htab and rhtab gained a ->map_check_btf (to register a dtor) that does not look at the key, so a key-less hash map is now accepted. Dumping it through bpffs feeds the key type_id 0 into btf_type_seq_show() and NULL-derefs in btf_type_show(). Reject it again. Patches 2 and 3 fix two related, pre-existing crashes reachable via bpf_snprintf_btf(), which renders a type_id taken straight from the BPF program against the vmlinux BTF. A "const void" (a modifier resolving to void) NULL-derefs in btf_modifier_show() - void has no ->show op; a BTF_KIND_VAR NULL-derefs in btf_var_show() - the vmlinux base BTF has no resolved_ids. Patch 2 falls back to btf_df_show(), the "" placeholder already used for FWD/FUNC/FLOAT/DECL_TAG; patch 3 resolves the var's type directly, mirroring the existing guard in btf_modifier_show(). Patches 4 and 5 add selftests. Patch 4 checks a key-less hash and rhash map is rejected at creation. Patch 5 extends the snprintf_btf test to render a "const void" and a BTF_KIND_VAR from the vmlinux BTF and checks they resolve without crashing. v3 -> v4: Drop the pin-and-read reproducer from the key-less map test, fold the void/VAR test into the existing snprintf_btf test, and simplify patch 2's wording (review comments). v2 -> v3: Fold in a third fix for the same class of bug, btf_var_show(), reported while reviewing v2. Address review comments (Fixes attribution, verbatim syzbot trace, skip instead of fail). v1 -> v2: AI reported a pre-exist issue. Let's fold it in this series. v3: https://lore.kernel.org/bpf/20260831110314.150870-1-jiayuan.chen@linux.dev/ v2: https://lore.kernel.org/bpf/20260830073242.148092-1-jiayuan.chen@linux.dev/ v1: https://lore.kernel.org/bpf/20260828093142.179856-1-jiayuan.chen@linux.dev/ ==================== Link: https://patch.msgid.link/20260901104924.346187-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit 1ae6aa61958a0ee6f254cefbee20663ffbadb195 Author: Jiayuan Chen Date: Tue Sep 1 18:47:39 2026 +0800 selftests/bpf: Add test for showing a void BTF type Extend the snprintf_btf test with type_ids from the vmlinux BTF that used to NULL-deref in the BTF show path: a "const void", checked to render the "" placeholder, and a BTF_KIND_VAR, checked to resolve and render without error. The program renders from its own buffer and the test picks a VAR whose resolved type fits it, so the render stays in bounds. Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260901104924.346187-6-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit 6265b44f2c3bb2839a306d6088d6e65a58d7e80e Author: Jiayuan Chen Date: Tue Sep 1 18:47:38 2026 +0800 selftests/bpf: Add test for key-less BTF hash map Create a hash and an rhash map with btf_key_type_id == 0 and expect bpf_map_create() to fail with -EINVAL; a positive control with a real key type confirms the rejection is about the key-less BTF and not some unrelated failure. Such a map used to be accepted and then NULL-deref in btf_type_show() when dumped through bpffs. Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260901104924.346187-5-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit 5403a383f52fc0905703b488f7c3db4b2447dc58 Author: Jiayuan Chen Date: Tue Sep 1 18:47:37 2026 +0800 bpf: Fix NULL-ptr-deref in btf_var_show() btf_var_show() calls btf_type_id_resolve() unconditionally, which dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is not resolved during parsing. btf_modifier_show() guards this with 'if (btf->resolved_ids)', but btf_var_show() does not. A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux BTF to bpf_snprintf_btf() thus NULL-derefs: KASAN: probably user-memory-access in range [0x46638-0x4663f] RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929) Call Trace: btf_type_show (kernel/bpf/btf.c:8259) btf_type_snprintf_show (kernel/bpf/btf.c:8329) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Resolve the var's type directly with btf_type_skip_modifiers() when resolved_ids is NULL, mirroring btf_modifier_show(). Fixes: c4d0bfb45068 ("bpf: Add bpf_snprintf_btf helper") Signed-off-by: Jiayuan Chen Acked-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260901104924.346187-4-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit 4ea508b9ebd78bce7f212166d2e2cba66b875f08 Author: Jiayuan Chen Date: Tue Sep 1 18:47:36 2026 +0800 bpf: Fix NULL-ptr-deref when showing a void BTF type btf_modifier_show() resolves the modifier and then calls btf_type_ops(t)->show() unconditionally. For the void type (type_id 0, BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL. A "const void" (a modifier resolving to void) cannot be a map key or value - map_check_btf() rejects it because void has no size - so the map dump path does not reach it. But bpf_snprintf_btf() takes a type_id straight from the BPF program, and passing such a "const void" from the vmlinux BTF NULL-derefs: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914) Call Trace: btf_type_show (kernel/bpf/btf.c:8251) btf_type_snprintf_show (kernel/bpf/btf.c:8321) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fall back to btf_df_show() when the resolved type has no show op; it emits the "" placeholder already used for kinds like FWD and FUNC. bpf_snprintf_btf() then returns the length as usual. Fixes: c4d0bfb45068 ("bpf: Add bpf_snprintf_btf helper") Signed-off-by: Jiayuan Chen Acked-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260901104924.346187-3-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit 0895a0c0734703be5532f3883c42db95615fd98b Author: Jiayuan Chen Date: Tue Sep 1 18:47:35 2026 +0800 bpf: Reject key-less BTF for hash maps map_check_btf() allows a key-less BTF (btf_key_type_id == 0) only for maps that have a ->map_check_btf callback, and leaves the actual decision to that callback. Hash maps used to have no ->map_check_btf, so a key-less BTF was rejected outright. That changed when htab and rhtab gained a ->map_check_btf to register a dtor - htab in commit 1df97a7453ee ("bpf: Register dtor for freeing special fields") and rhtab in commit 6905f8601298 ("bpf: Allow special fields in resizable hashtab"). Neither looks at the key, so a key-less hash map now passes map_check_btf() and gets created. Reading it back through bpffs feeds the key type_id 0 into btf_type_seq_show(); btf_type_by_id() returns the void type, kind_ops[BTF_KIND_UNKN] is NULL, and btf_type_show() dereferences it: RIP: 0010:btf_type_show+0x223/0x2e0 kernel/bpf/btf.c:8232 RSP: 0018:ffffc9000399f868 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000005 RSI: 0000000000000000 RDI: 0000000000000028 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: ffffc9000399f970 R11: 0000000000000001 R12: ffffffff9b96b140 R13: ffffc9000399f8e0 R14: ffff88803d393c00 R15: 0000000000000003 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000000 CR3: 000000003d213000 CR4: 0000000000352ef0 DR0: 0000000039ae8f55 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: btf_type_seq_show_flags+0xca/0x120 kernel/bpf/btf.c:8250 htab_map_seq_show_elem+0x12e/0x350 kernel/bpf/hashtab.c:1669 map_seq_show+0x13d/0x1e0 kernel/bpf/inode.c:293 traverse.part.0.constprop.0+0x107/0x650 fs/seq_file.c:112 traverse fs/seq_file.c:99 [inline] seq_read_iter+0x93f/0x1270 fs/seq_file.c:196 seq_read+0x344/0x4d0 fs/seq_file.c:163 vfs_read+0x1e4/0xb40 fs/read_write.c:572 ksys_pread64 fs/read_write.c:764 [inline] __do_sys_pread64 fs/read_write.c:772 [inline] __se_sys_pread64 fs/read_write.c:769 [inline] __x64_sys_pread64+0x1eb/0x250 fs/read_write.c:769 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reject a key-less BTF in htab_map_check_btf() and rhtab_map_check_btf(), restoring the previous behavior. Fixes: 1df97a7453ee ("bpf: Register dtor for freeing special fields") Fixes: 6905f8601298 ("bpf: Allow special fields in resizable hashtab") Reported-by: syzbot+37b56485bbbf90ad8489@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a8f4e88.27659fcc.2ceef7.0008.GAE@google.com/T/ Signed-off-by: Jiayuan Chen Acked-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260901104924.346187-2-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov commit d72aa5cf045a69d5fd433cde5dd4e113d9558fd1 Author: Igor Paunovic Date: Thu Aug 13 16:40:19 2026 +0200 drm/rockchip: rk3066_hdmi: Add missing Kconfig selects rk3066_hdmi.c calls drm_bridge_connector_init(), but ROCKCHIP_RK3066_HDMI selects neither DRM_BRIDGE_CONNECTOR nor DRM_DISPLAY_HELPER, whose module carries the bridge-connector code. A configuration with ROCKCHIP_RK3066_HDMI as the only enabled Rockchip output option fails to link: aarch64-linux-gnu-ld: drivers/gpu/drm/rockchip/rk3066_hdmi.o: in function `rk3066_hdmi_bind': rk3066_hdmi.c:(.text+0x7a4): undefined reference to `drm_bridge_connector_init' aarch64-linux-gnu-ld: drivers/gpu/drm/rockchip/rk3066_hdmi.o: in function `rk3066_hdmi_bridge_atomic_enable': rk3066_hdmi.c:(.text+0xe74): undefined reference to `drm_atomic_helper_connector_hdmi_update_infoframes' Select both, like ROCKCHIP_CDN_DP, ROCKCHIP_LVDS and ROCKCHIP_RGB do. DRM_BRIDGE_CONNECTOR in turn selects DRM_DISPLAY_HDMI_STATE_HELPER, which resolves the second symbol. Fixes: 57d6811e8a6d ("drm/rockchip: rk3066_hdmi: switch to drm bridge") Signed-off-by: Igor Paunovic Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260813144019.12089-3-royalnet026@gmail.com commit c83e3e806d4c115f1dad9ef756db4cd91448a262 Author: Igor Paunovic Date: Thu Aug 13 16:40:18 2026 +0200 drm/rockchip: dw_dp: Select DRM_BRIDGE_CONNECTOR dw_dp-rockchip.c calls drm_bridge_connector_init(), but ROCKCHIP_DW_DP does not select DRM_BRIDGE_CONNECTOR. A configuration with ROCKCHIP_DW_DP as the only enabled Rockchip output option fails to link: aarch64-linux-gnu-ld: drivers/gpu/drm/rockchip/dw_dp-rockchip.o: in function `dw_dp_rockchip_bind': dw_dp-rockchip.c:(.text+0x1d4): undefined reference to `drm_bridge_connector_init' Five other Rockchip encoder options that call drm_bridge_connector_init() (ROCKCHIP_ANALOGIX_DP, ROCKCHIP_CDN_DP, ROCKCHIP_DW_HDMI_QP, ROCKCHIP_LVDS, ROCKCHIP_RGB) already select it, which masks the gap in any configuration that enables one of them. ROCKCHIP_INNO_HDMI is covered through its DRM_INNO_HDMI core option. The same change was posted by Marius Dinu in March and dropped when the failure stopped reproducing in his build. The failure is configuration-dependent - any other enabled option that selects DRM_BRIDGE_CONNECTOR hides it - and it still reproduces on current drm-misc-next with the configuration described above. Select DRM_BRIDGE_CONNECTOR like the other users do. Fixes: d68ba7bac955 ("drm/rockchip: Add RK3588 DPTX output support") Link: https://lore.kernel.org/r/aneNCDU12OzG99UX@venus # ack to handle this apart from the dw-dp series Link: https://lore.kernel.org/r/20260319155051.1944-1-m95d+git@psihoexpert.ro # earlier submission by Marius Dinu Signed-off-by: Igor Paunovic Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260813144019.12089-2-royalnet026@gmail.com commit 3b26ceef88c110f4d188387cffa0df78657be904 Author: Takashi Iwai Date: Thu Sep 3 12:38:51 2026 +0200 ALSA: caiaq: Fix potential double-free at error path The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared. Link: https://sashiko.dev/#/patchset/20260903084747.535367-1-eadavis%40sina.com Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Link: https://patch.msgid.link/20260903103855.1807838-1-tiwai@suse.de Signed-off-by: Takashi Iwai commit 8efd5f623c63584c2e284a837a7795d95a0491cb Author: HyeongJun An Date: Thu Sep 3 21:38:32 2026 +0900 selftests/alsa: Fix the step check for INTEGER controls The modulo sits inside the subtraction, so the check evaluates int_val - (min % step) rather than (int_val - min) % step. The INTEGER64 branch below it is parenthesised correctly. The written form passes only when the value equals min % step, and such a value is always on a step boundary, so it never misses a real violation. It only reports valid values as invalid. snd-aloop declares step 1 on four controls, so every non-zero value on them is reported. Before: # PCM Rate Shift 100000.0 value 100000 invalid for step 1 minimum 80000 # Totals: pass:660 fail:101 xfail:0 xpass:0 skip:296 error:0 After, same card, nothing else changed: # Totals: pass:740 fail:21 xfail:0 xpass:0 skip:296 error:0 Eighteen files under sound/ declare a non-zero step. Fixes: 5aaf9efffc57 ("kselftest: alsa: Add simplistic test for ALSA mixer controls kselftest") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-5 Link: https://patch.msgid.link/20260903123832.97377-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai commit a7df136ec529ee49a789c5029bc37b98b0d4bedd Author: Ruoyu Wang Date: Thu Aug 13 23:31:49 2026 +0800 dmaengine: sprd: Fix runtime PM reference leak in probe pm_runtime_get_sync() increments a device's usage counter even when it fails. sprd_dma_probe() currently jumps directly to controller clock cleanup on that error, bypassing both pm_runtime_put_noidle() and pm_runtime_disable(). This can happen if the preceding unchecked pm_runtime_set_active() fails and the following runtime-resume attempt also returns an error. Enter the existing runtime-PM unwind path instead. This drops the reference without idling the partially initialized device, disables runtime PM, and then releases the controller clocks. The success path and propagated error code are unchanged. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 9b3b8171f7f4 ("dmaengine: sprd: Add Spreadtrum DMA driver") Signed-off-by: Ruoyu Wang Reviewed-by: Frank Li Reviewed-by: Baolin Wang Link: https://patch.msgid.link/20260813153149.3953497-1-ruoyuw560@gmail.com Signed-off-by: Vinod Koul commit 0294b6dd515256c03ea2dbf508ddd3826d788579 Author: Alexander Chesnokov Date: Wed Aug 12 08:34:26 2026 +0300 dmaengine: ti: k3-udma-glue: fix NULL dereference in k3_udma_glue_release_rx_chn() If devm_kcalloc() for rx_chn->flows fails in a channel request function, the error path calls k3_udma_glue_release_rx_chn(), which dereferences the NULL rx_chn->flows pointer in k3_udma_glue_release_rx_flow(). Skip the flow release loop in k3_udma_glue_release_rx_chn() when rx_chn->flows is not allocated. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d70241913413 ("dmaengine: ti: k3-udma: Add glue layer for non DMAengine users") Cc: stable@vger.kernel.org Reported-by: Pavel Zhigulin Signed-off-by: Alexander Chesnokov Reviewed-by: Frank Li Link: https://patch.msgid.link/20260812053426.3521589-1-Alexander.Chesnokov@kaspersky.com Signed-off-by: Vinod Koul commit d1fc569fcbc7be6de06b034cf954a95e30ca1fb2 Author: Troy Mitchell Date: Mon Jul 27 01:26:15 2026 -0700 dmaengine: mmp_pdma: fix wrong extended DRCMR base for SpacemiT K3 The extended DRCMR window on SpacemiT K3 starts at 0x1100. Commit 6587b8661a0b ("dmaengine: mmp_pdma: add SpacemiT K3 support") incorrectly set it to 0x1000, causing DRCMR accesses for request IDs >= 64 to target offsets 0x100 too low. The 0x1100 base has been verified on K3 silicon using real SPI and QSPI DMA transactions. The K3 DMA documentation [1] was updated on June 24, 2026, to reflect the corrected register addresses. Drop the bogus DRCMR_EXT_BASE_K3 macro and reuse DRCMR_EXT_BASE_DEFAULT for the K3 ops. Fixes: 6587b8661a0b ("dmaengine: mmp_pdma: add SpacemiT K3 support") Link: https://www.spacemit.com/community/document/info?nodepath=hardware/key_stone/k3/k3_docs/k3_usermanual/16_peripherals/dma.md&lang=en [1] Signed-off-by: Troy Mitchell Reviewed-by: Frank Li Link: https://patch.msgid.link/20260727-k3-pdma-fix-drcmr-base-v2-1-afba55cba1f3@linux.spacemit.com Signed-off-by: Vinod Koul commit 7f11480cda081de78a05d8c97073df66326b50b3 Author: Ian Lin Date: Mon Aug 31 16:44:05 2026 +0800 USB: serial: option: add Compal EXM-G1x support The Compal EXM-G1x is a Qualcomm SDX12-based LTE modem. Add support for its vendor-specific serial interfaces with protocols 0x30, 0x40, and 0x60. Relevant output from usb-devices: T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=04b7 ProdID=8217 Rev=05.04 S: Manufacturer=COMPAL S: Product=EXM-G1x C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option I: If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan Tested on a Compal EXM-G1x modem. Assisted-by: Codex:GPT-5 Signed-off-by: Ian Lin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold commit 35c950c9ec2c4c4d45dc9b63cfe8fca774ce33a0 Author: Zhao Dongdong Date: Mon Aug 17 15:14:27 2026 +0800 USB: serial: option: add support for SIMCom SIM8260C Add support for SIMCom SIM8260C (1e0e:902b). T: Bus=08 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=1e0e ProdID=902b Rev= 5.04 S: Manufacturer=SIMCOM S: Product=SDXLEMUR-LITE-MTP _SN:120696AB S: SerialNumber=0123456789ABCDEF C:* #Ifs= 8 Cfg#= 1 Atr=a0 MxPwr=896mA A: FirstIf#= 5 IfCount= 3 Cls=01(audio) Sub=00 Prot=20 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan_simcom E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio I:* If#= 6 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 6 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=05(O) Atr=0d(Isoc) MxPS= 34 Ivl=1ms I:* If#= 7 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=(none) I: If#= 7 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=(none) E: Ad=89(I) Atr=0d(Isoc) MxPS= 34 Ivl=1ms Signed-off-by: Zhao Dongdong Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold commit 8ab1afb2eb246ab15b301cd255b5943d208a93c1 Merge: 97be98b94dc8e4 7ac81e2d2240f2 Author: Linus Torvalds Date: Thu Sep 3 08:30:45 2026 -0700 Merge tag 'for-7.3/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fixes from Mikulas Patocka: - fix a dm-crypt race condition that could make errors not being reported - dm-cache: - fix rwsem being locked and unlocked from different processes - fix demotion statistics - dm-integrity: - set the 'stable writes' flag - fix a buffer overflow introduced in this merge window - fix an infinite loop if tag size is greater than 64 - fix NULL pointer dereference in dm-integrity data-recovery mode - remove a bogus restriction on the dm-ebs starting sector offset * tag 'for-7.3/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm-ebs: fix incorrect device offset check in ebs_ctr() dm-integrity: fix NULL pointer dereference when the 'R' flag is used dm cache: fix demotion stats in passthrough mode dm-integrity: fix infinite loop on discard with large tag size dm-integrity: fix buffer overflow with keyed discard dm-integrity: require stable writes for internal hash modes dm cache: fix issue with background work locking dm-crypt: fix a tiny race condition in crypt_dec_pending commit cd243401994880b8b6810c53177bce56eebaece5 Author: Carlo Szelinsky Date: Wed Aug 12 13:42:28 2026 +0300 USB: serial: option: add Quectel EG060W Add Quectel EG060W with product ID 0x6004. The three vendor-specific interfaces are DIAG, NMEA and AT; the CDC-NCM data interfaces are handled by the cdc_ncm driver. T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=6004 Rev= 3.18 S: Manufacturer=Quectel S: Product=EG060W-EAAA S: SerialNumber=123456789ABCD C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr= 2mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_ncm E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org Signed-off-by: Carlo Szelinsky Signed-off-by: Johan Hovold commit 97be98b94dc8e43a3e4dedccaf9683fb806e49aa Merge: 940de590b839f7 0fecc393f2060e Author: Linus Torvalds Date: Thu Sep 3 08:10:04 2026 -0700 Merge tag 'ntfs-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/ntfs Pull ntfs fixes from Namjae Jeon: - Serialize truncate, fallocate, and mmap fault paths with invalidate_lock, avoiding mmap failures during concurrent size changes and exposure of uninitialized data during allocation - Correct fallocate signal and zeroing error handling - Fix FITRIM range alignment to prevent discard requests from extending into allocated clusters - Fix free-cluster accounting when cluster-freeing rollback or bitmap clearing fails - Keep volumes marked dirty when ntfs errors have been recorded - Compute bi_sector in 512-byte units, preventing silent corruption on 4Kn devices - Validate sectors_per_cluster values and prevent undefined shifts when parsing MFT and index record sizes - Bound $AttrDef traversal to the loaded table size - Fix MFT record resizing, memmove overlap, and kmap_local cleanup issues - Improve error propagation across attribute, EA, and reparse operations, including returning -ERANGE for undersized xattr buffers - Avoid modifying the HasEA flag when setxattr fails and return DT_UNKNOWN when directory inode lookup fails - Reduce contention in WOF decompression by performing block reads outside the decompression lock * tag 'ntfs-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/ntfs: (23 commits) ntfs: take invalidate_lock in ntfs_filemap_page_mkwrite() ntfs: take invalidate_lock in ntfs_setattr_size() ntfs: handle signal interruption in fallocate ntfs: fix FITRIM range alignment ntfs: read WOF chunks outside the decompression lock ntfs: leave HasEA flag untouched on setxattr failure ntfs: fix race between fallocate and mmap reads ntfs: fix memmove overlap in ntfs_new_attr_flags ntfs: compute bi_sector in 512-byte units ntfs: reject invalid sectors_per_cluster in the boot sector ntfs: bound $AttrDef table walk to the loaded table size ntfs: fix undefined behavior in mft/index record size calculation ntfs: treat any nonzero dio zero-range return as an error ntfs: fix incorrect MFT record pointer passed to ntfs_attr_record_resize ntfs: do not mark the volume clean in sync_fs when errors were recorded ntfs: skip free cluster decrement when rollback fails ntfs: only count successfully cleared runs when freeing clusters ntfs: fix kmap_local leak in write_mft_record_nolock() error paths ntfs: return real error from ntfs_non_resident_attr_record_add() ntfs: preserve error code in ntfs_resident_attr_record_add() ... commit 82e664cf1219c459c33aae931b222cf951af9cb7 Author: Gao Xiang Date: Thu Sep 3 22:28:41 2026 +0800 erofs: disable LZ4 rolling decompression for now LZ4 rolling decompression [1] was introduced to reduce the memory footprint of temporary pages: For many cases, it is needed for users to read small data within a compressed extent (pcluster), either due to random small read, or since uptodate folios (typically order-0) cannot be reused for decompression again since decompression algorithm refills already-uptodate folios. Rolling decompression works because LZ4 is LZ77-based and only refers to the most recent 64 KiB of decompressed data, so in theory only a bounded rolling window of temporary pages is needed when decompressing. It can save a lot of temporary memory, e.g. 601,960-byte data can be compressed into a 256k LZ4 compressed extent, which means it needs 146 extra pages per request in the worst case if rolling decompression is disabled. However, the upstream LZ4 implementation is not under EROFS' control: For example, the literal copy memmove() may still **copy long literals backward** on x86 based on the address comparison even when the source and destination ranges do not overlap (IOWs, inline decompression doesn't need to be considered here). That breaks the rolling assumption and makes the optimization broken. Disable it for now to make sure the data correctness first since EROFS is used everywhere now: The rolling window approach can be revived once we either ensure that the official LZ4 code always copies forward for non-overlapping ranges or maintain our own LZ4 implementation in EROFS. The main impact is a higher runtime memory footprint; However, recent commit 0f6273ab4637 ("erofs: add a reserved buffer pool for lz4 decompression") helps mitigate this when enabled but it's still not perfect. [1] https://www.usenix.org/conference/atc19/presentation/gao § 3.3 Decompression Reported-by: "Walther, Jens-Uwe" Closes: https://lore.kernel.org/r/BEZP281MB2102E57CD31862B8D958B33DD2AC2@BEZP281MB2102.DEUP281.PROD.OUTLOOK.COM Fixes: 8e6c8fa9f2e9 ("erofs: enable big pcluster feature") Cc: Yann Collet Signed-off-by: Gao Xiang commit 42d3358bf145f27d32350037e67d3527e9098c1e Author: Fredric Cover Date: Wed Sep 2 17:49:01 2026 -0700 smb: client: fill cache fields after populating cache in copy_ref_data() In copy_ref_data(), struct cache_entry *ce has its fields populated at the beginning of the function. Later, if alloc_target fails with an ERR_PTR, free_tgts() is called on the cache, leaving the cache metadata populated without any targets. Critically, this extends ce->etime, making the cache appear valid for longer without any targets. Also, free_tgts() does not set ce->numtgts to zero. On error, when the cache is freed, ce->numtgts is not zeroed, and other cache users may attempt to access nonexistent entries. Update fields after copying targets to prevent partial-state updates. Set ce->numtgts to zero at the end of free_tgts(). Signed-off-by: Fredric Cover Signed-off-by: Paulo Alcantara commit 6365c44a824ff138e7926413932bb5c2e28a4c8c Author: Vincent Donnefort Date: Tue Sep 1 16:54:42 2026 +0100 ring-buffer: Allow splice reads on static buffers ring_buffer_read_page() rejects splice (full=1) reads on static buffers (that is user-mapped, persistent or remote) because !read check assumes unread pages must be swapped. However for those buffers we have no other choice than memcpy the data. For the memcpy case, only return an error when the writer is still on the reader page for the splice interface to wait. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901155445.1475405-2-vdonnefort@google.com Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt commit 6d81700ad7c4871f94fb72e469cb0f3f55843ef7 Author: Damien Le Moal Date: Wed Sep 2 11:08:28 2026 +0900 ata: libata-scsi: do not raise UA for storage element depopulation and restoration The libata command completion for the ATA commands REMOVE ELEMENT AND TRUNCATE and RESTORE ELEMENTS AND REBUILD is handled using the function ata_scsi_depop_ua_cap_changed_complete(). This completion function raises a UNIT ATTENTION with the additional sense code CAPACITY DATA HAS CHANGED. But doing so, the scsi layer seeing the UNIT ATTENTION sense key ends up failing the command, even if the command result is in fact OK. The SAT specifications do provide more details about the capacity change should be notified, and that relies on the ACCESSIBLE CAPACITY field of the IDENTIFY DATA retrieved before or after the command is issued, and then raising a UNIT ATTENTION if the capacity has really changed. However, we do not have any simple mean to raise a unit attention from libata-scsi. So rather than seeing the REMOVE ELEMENT AND TRUNCATE and RESTORE ELEMENTS AND REBUILD commands failing, remove the function ata_scsi_depop_ua_cap_changed_complete() and rely on the regular completion callback. Since for now these commands can only be issued as passthrough commands, the user is responsible for revalidating the device capacity after executing these commands. Fixes: db496721cb0d ("ata: libata-scsi: add support for the REMOVE ELEMENT AND TRUNCATE command") Fixes: 1e307ca61a9c ("ata: libata-scsi: add support for the RESTORE ELEMENTS AND REBUILD command") Signed-off-by: Damien Le Moal Link: https://lore.kernel.org/r/20260902020828.1436048-1-dlemoal@kernel.org Signed-off-by: Niklas Cassel commit bc69439d983cc491cc86e01fafc1deb94e1bb85e Author: Yudi Yang <2000jedi@gmail.com> Date: Tue Sep 1 14:55:11 2026 -0500 drm/rockchip: analogix_dp: fix unchecked bound endpoint name length rockchip_dp_drm_encoder_enable() uses sprintf() to format a device tree path into a 32-byte stack buffer. Device tree paths are not limited to this size, so a sufficiently long path can overflow the buffer. Use snprintf() with the destination size to truncate the generated name and keep the writes within bounds. Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588") Cc: stable@vger.kernel.org Signed-off-by: Yudi Yang <2000jedi@gmail.com> Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260901195511.2761251-1-2000jedi@gmail.com commit 5445d64199626974269fcdf347769ad44b0bb53b Author: Fuad Tabba Date: Thu Aug 27 19:59:37 2026 +0100 arm64: Don't read GMID_EL1 when MTE is disabled __cpuinfo_store_cpu() gates the GMID_EL1 read on the raw ID_AA64PFR1_EL1, so it reads the register even when the kernel has disabled MTE (CONFIG_ARM64_MTE=n or arm64.nomte). KVM sets HCR_EL2.TID5 in that case, and pKVM injects an UNDEF the host cannot handle: Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP pc : __cpuinfo_store_cpu+0xf4/0x264 Kernel panic - not syncing: Attempted to kill the idle task! Only pKVM reaches it, and only after a CPU is offlined and brought back online: its CPU_ON relay sets the host HCR before the CPU enters EL1, while plain nVHE sets it at CPUHP_AP_KVM_ONLINE. Gate the read on the CPU's own ID_AA64PFR1_EL1 with the command-line override applied, and on CONFIG_ARM64_MTE, which no register reflects. The boot CPU stores its registers before init_cpu_features() strips an unsafe override, so clamp against the hardware value here too. Fixes: f35abcbb8a084 ("KVM: arm64: Trap MTE access and discovery when MTE is disabled") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon commit 5541432e09dc2031978188f3e8a00b9fc78cf097 Author: Khushit Shah Date: Mon Aug 31 10:54:44 2026 +0000 arm64: errata: pass REVIDR when matching target implementation CPUs When target implementation CPUs are provided, is_affected_midr_range() accidentally passed the MIDR as both arguments to __is_affected_midr_range(), so the REVIDR mask check operated on the wrong register. Pass REVIDR as intended. Fixes: 86edf6bdcf05 ("smccc/kvm_guest: Enable errata based on implementation CPUs") Cc: stable@vger.kernel.org Signed-off-by: Khushit Shah Reviewed-by: Zenghui Yu (Huawei) Acked-by: Marc Zyngier Reviewed-by: Shameer Kolothum Signed-off-by: Will Deacon commit 1537e55728ec2bc506c74ea69b93cd859da58fb8 Author: Breno Leitao Date: Fri Aug 28 02:28:18 2026 -0700 arm64: trans_pgd: clone only the linear map that exists at runtime kexec_file_load() fails on arm64 if we have CONFIG_ARM64_VA_BITS_52 but it runs on a !FEAT_LPA2 host (such as my loving Grace machine). That is because trans_pgd_create_copy() uses the compile time PAGE_OFFSET (VA 52) instead of the actual VA size (48 -- due to the lack of LPA2). With the fifth level folded, pgd_none() is always false, so the walk cannot skip the 15 extra PGDIR_SIZE slots, and they all alias back to the same table: the whole kernel page table gets cloned 16 times, KASAN shadow included. Without KASAN it does not blow up, it just wastes ~RAM/32 in page tables. Fix it by copying the linear map that is the actual one, not the compiled one. Fixes: a6bbf5d4d9d1 ("arm64: mm: Add definitions to support 5 levels of paging") Signed-off-by: Breno Leitao Tested-by: Yury Smirnov Signed-off-by: Will Deacon commit a77644d009dece1104b6fcc6e322b0e4503db0d6 Author: Karl Mehltretter Date: Fri Aug 28 19:41:31 2026 +0200 arm64: mm: Fix the lockless page-table walk in show_pte() show_pte() walks page tables locklessly and can run with interrupts enabled. A concurrent teardown can free a table page while it is being walked. It can also clear a parent entry after show_pte() checked it; the regular pXd_offset() helpers then reread the cleared entry and can derive a bogus lower-level pointer and fault again. Use the lockless offset helpers with the saved parent entries, as gup_fast() does, and pass the saved PMD to pte_offset_map(). For task page tables, arm64 selects MMU_GATHER_RCU_TABLE_FREE. Disable local interrupts around the walk to hold off RCU-deferred table frees and block the tlb_remove_table_sync_one() IPI until the walk is finished. Place the IRQ guard after the header print. This does not make the output a consistent snapshot, but prevents the task page-table walk from dereferencing a released table page or deriving a pointer from a different parent value. Fixes: 1d18c47c735e ("arm64: MMU fault handling and page table management") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon commit 66817a9794263cd2a5dc4e99bf8e5fcc5ff7181e Author: HW He Date: Tue Sep 1 16:23:12 2026 +0800 net: gro: Fix nesting of TCP GSO SKBs in skb_gro_receive_list() Fraglist GRO and hardware GRO can create an fraglist of HW-GRO packets. This cannot be segmented back into the original form on TCP tethering scenario. Avoid constructing such a GSO packet, by flushing an already built fraglist GRO packet if a hardware GRO packet arrives. Scenario (Tethering/Forwarding): 1.Driver submits a single TCP packet, P1. P1 is kept in the gro_list as the first packet. 2. The driver submits a TCP GSO skb, P2. P2 has already aggregated multiple TCP packets by HW_GRO, and its non-linear data is stored in frags[]. 3. P1 and P2 match the GRO rules, and since there is no local socket, they are aggregated by skb_gro_receive_list(). The resulting skb, P3, has a frag_list entry that still contains frags[]: P3: [ Linear Data ] -> frag_list -> [ Linear Data ] [ frag[1] ] [ frag[2] ] ... 4. Later, tcp4_gso_segment() or tcp6_gso_segment() calls skb_segment_list() to segment P3. However, skb_segment_list() only segments the entries in frag_list. It does not segment the frags[] inside P2, so P3 is not restored to the original packets, which leads to IP fragmentation or packet drop in the following path. Check skb_is_gso(skb) and current GRO method, make sure fraglist GRO applies to consecutive non-GSO skb, others adopt regular GRO path. Fixes: 8d95dc474f85 ("net: add code for TCP fraglist GRO") Signed-off-by: Zhaoping Shu Signed-off-by: HW He Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260901082312.14596-1-zhaoping.shu@mediatek.com Signed-off-by: Paolo Abeni commit 2ae16aaa78b5edc6e6d0904c84fd9cdfb762bcda Author: Quanye Yang Date: Sun Aug 30 15:09:55 2026 +0800 RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted The client borrows shared CQ credits in the ADDR_RESOLVED handler via ib_cq_pool_get(), before the peer is connected. create_cm() can return -ERESTARTSYS from wait_event_interruptible_timeout() without destroying the CM ID. The init_conns() and stop-and-destroy paths then call destroy_con_cq_qp() while cq is still NULL (no PUT) and only afterwards rdma_destroy_id(). CMA serializes the handler against rdma_destroy_id() with handler_mutex, but that does not order the GET against destroy_con_cq_qp(). If ADDR_RESOLVED has already passed the DESTROYING check, it can take con_mutex, GET credits, and then lose the con to kfree. Device unregister later hits WARN_ON(cq->cqe_used) in ib_cq_pool_cleanup(). Set a per-connection flag under con_mutex before CQ/QP teardown so a racing ADDR_RESOLVED cannot borrow credits after teardown has begun. Reported-by: syzbot+d396918a29afb8543e1c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d396918a29afb8543e1c Fixes: 3b89e92c2a95 ("RDMA/rtrs: Use new shared CQ mechanism") Signed-off-by: Quanye Yang Link: https://patch.msgid.link/20260830-rdma-rtrs-clt-cq-pool-leak-v1-1-b169434fd3df@proton.me Reviewed-by: Jack Wang Signed-off-by: Leon Romanovsky commit 6b8fed2675fb75d23e6cf2b7e49c94926e884b34 Author: Lorenzo Bianconi Date: Mon Aug 31 19:06:38 2026 +0200 net: stmmac: reconfigure RX packet parser table in stmmac_hw_setup() after reset The core software reset issued in stmmac_init_dma_engine() during ndo_open() callback clears the MTL RX packet parser registers, but stmmac_rxp_config() is only invoked from the cls_u32 add/delete paths. After an ifdown/ifup cycle the hardware therefore runs with the default all-pass table while priv->tc_entries still reports the filters as installed. Re-apply the RX packet parser table from priv->tc_entries in stmmac_hw_setup(), right after the software reset, so the filters are restored when the interface is brought up again. Fixes: 4dbbe8dde848 ("net: stmmac: Add support for U32 TC filter using Flexible RX Parser") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260831-stmmac_tc_cls32_reconfigure-v1-1-21cb459e64ae@oss.qualcomm.com Signed-off-by: Paolo Abeni commit 7db28abbea0f7dc1ec4fdfdc149db5fbd9e4c994 Author: Lorenzo Bianconi Date: Sun Aug 30 14:28:27 2026 +0200 net: airoha: enable RX_DONE interrupt for RX queue 31 RX queue 31 has always been allocated and filled by airoha_qdma_init_rx() since RX_DONE_INT_MASK spans queues 0-31, but none of the RX_IRQ* _BANK_PIN_MASK values covered BIT(31). As a consequence the RX_DONE interrupt for queue 31 was never enabled, airoha_qdma_rx_process() never ran on that queue and its buffers were never reaped. Route RX queue 31's RX_DONE interrupt to IRQ bank 1 so that the queue is drained and its buffers returned to the page pool. Fixes: f252493e1835 ("net: airoha: Enable multiple IRQ lines support in airoha_eth driver.") Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260830-airoha-rxdone-rxq31-v1-1-830a91503f2f@kernel.org Signed-off-by: Paolo Abeni commit c2549d749539487239475fbc8c614a1f9244d655 Author: Ritesh Harjani (IBM) Date: Sun Aug 30 20:24:30 2026 +0530 powerpc: Do not restore KUAP in arch_exit_to_user_mode_prepare() KUAP means kernel cannot touch user memory unless it explicitly is enabled. In the kernel it should stay AMR_KUAP_BLOCKED. While returning to userspace just before RFI, kernel should restore the user AMR value back. Looks like GENERIC_ENTRY might be treating arch_exit_to_user_mode_prepare() as the last architecture step before returning to userspace. commit bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature") therefore called kuap_user_restore() from that hook. But on PowerPC that is too early. After irqentry_exit() / syscall_exit_to_user_mode() we still run platform specific exit routines. e.g. code snippets showing both exception handling and system call handling as the callers of function arch_exit_to_user_mode_prepare() which does kuap_user_restore(). The below path shows that calling kuap_user_restore() is too early when called from arch_exit_to_user_mode_prepare(). Exception handling in exceptions-64s.S ======================================= bl CFUNC(do_page_fault) ..DEFINE_INTERRUPT_HANDLER_ASYNC(do_page_fault) arch_interrupt_async_enter_prepare(regs); state = irqentry_enter(regs); instrumentation_begin(); irq_enter_rcu(); handler(regs); nap_adjust_return(regs); irq_exit_rcu(); instrumentation_end(); arch_interrupt_async_exit_prepare(regs); irqentry_exit(regs, state); <<< too early irqentry_exit_to_user_mode() __exit_to_user_mode_prepare(regs, EXIT_TO_USER_MODE_WORK_IRQ); arch_exit_to_user_mode_prepare(regs, ti_work); <<< too early b interrupt_return_srr .. bl CFUNC(interrupt_exit_user_prepare) <<< already calls kuap_user_restore prep_irq_for_enabled_exit() retry can run kernel code with IRQs on. So only when that routine is fully finished is when the user KUAP should be fully restored which interrupt_exit_user_prepare() already takes care of before returning. Similarly for system call handling in interrupt_64.S ====================================================== bl CFUNC(system_call_exception) .Lsyscall_exit: addi r4,r1,STACK_INT_FRAME_REGS li r5,0 /* !scv */ bl CFUNC(syscall_exit_prepare) .. kuap_assert_locked(); syscall_exit_to_user_mode(regs); <<< too early syscall_exit_to_user_mode_prepare(regs); <<< too early kuap_user_restore(regs); <<< already calls syscall_exit_prepare(), which can enable IRQs, replay a pending interrupt, and only then rfi. Those functions already restore KUAP immediately before rfi. Note that if we restore the user AMR too early like in the current code as shown from the code snippets above, then we get the following warning when CONFIG_PPC_KUAP_DEBUG is enabled: WARNING: arch/powerpc/include/asm/book3s/64/kup.h:293 at interrupt_exit_user_prepare+0x1a0/0x1c0 Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) TRAP: 0700 LR: c00000000000d8d4 CTR: c0000000021fe500 MSR: CR: 44000804 XER: 20040000 interrupt_exit_user_prepare+0x1a0/0x1c0 interrupt_return_srr_user+0x8/0x12c Fixes: bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature") Fixes: 02565a782c1ee ("powerpc: Introduce syscall exit arch functions") Signed-off-by: Ritesh Harjani (IBM) Tested-by: Venkat Rao Bagalkote Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/52fee44fd23acf8e1c024ace668728e626a783a8.1788101609.git.ritesh.list@gmail.com commit c7585b8e99ad97a0f5dd21e45c90a33aeab0d92b Author: Ritesh Harjani (IBM) Date: Sat Aug 29 09:49:00 2026 +0530 powerpc: Don't drop _TIF_RESTOREALL on syscall restart So the syscall return sequence is as follows: A syscall return to userspace is prepared and then a short asm sequence that actually does the RFI. Note that this asm range is restartable i.e. EE is still on, so an interrupt (e.g. decrementer or external interrupt) can hit while SRR/GPRs are being loaded. This is defined via: RESTART_TABLE(.Lsyscall_rst_start, .Lsyscall_rst_end, syscall_restart) This restart table then sends us to syscall_restart rather than resuming in the middle of the RFI. The same stub is also used if irq_happened already has a pending bit (soft-masked irq that has not been replayed yet (PowerPC special case of local_irq_disable())). Here is a bit of a flow of sequence of code to visualize: syscall_exit_prepare decide full-GPR restore (_TIF_RESTOREALL) for signal, rt_sigreturn or syscall trace save that in regs->exit_result and return it in r3 | v .Lsyscall_rst_start .. _end EE still on irq_happened set or interrupt in this range? | no | yes v v cmpdi r3,0 syscall_exit_restart restore all / zero replay irq, try exit again volatiles; RFI must return flags in r3 again for the same cmpdi Now r3 after prepare is the flags word, not the actual syscall return. A nested interrupt clobbers it, so the restart stub reloads RESULT into r3 and the C handler (syscall_exit_restart()) should put the flags back (because later asm checks whether r3 returned from C has _TIF_RESTOREALL set or not): cmpdi r3, 0 bne .Lsyscall_restore_regs Note that syscall_exit_restart() already ORs any new _TIF_RESTOREALL into exit_result, but then it only returns the new sample and not the full regs->exit_result. That sample could be often 0 even when restore-all is still required: - rt_sigreturn / syscall trace set the bit in prepare's local ret and in exit_result. They never set exit_flags, which is what restart samples. - a signal does set exit_flags but restart clears it. A second pass through the stub then returns 0 while exit_result still has the bit. The asm as mentioned earlier then treats r3==0 as the fast path and zeros r0/r4-r12. That means the userspace that needed the full register set could SIGSEGVs, (which could happen often in ld64.so.2 like while doing a parallel kernel build as reported by Venkat). So we should instead return the accumulated exit_result, like how we do in interrupt_exit_user_restart(). Note that prior to this commit 263e5159e00a ("powerpc: Fix exit_flags field placement in pt_regs for ptrace") we were returning regs->exit_result from syscall_exit_restart(), but this commit changed that behaviour. Fixes: 263e5159e00a ("powerpc: Fix exit_flags field placement in pt_regs for ptrace") Reported-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/75419f88-eab9-444b-bf97-28a9765819ad@linux.ibm.com/ Signed-off-by: Ritesh Harjani (IBM) Tested-by: Amit Machhiwal Tested-by: Shrikanth Hegde Tested-by: Venkat Rao Bagalkote Reviewed-by: Amit Machhiwal Reviewed-by: Shrikanth Hegde Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/10c86c909f870d90b3094f76b692b44ebe9caeac.1787976185.git.ritesh.list@gmail.com commit 2c1dde8a69a3a7d64425a6de0add6e289a5a402f Author: Shrikanth Hegde Date: Fri Aug 28 11:08:11 2026 +0530 powerpc/entry: Clear TIF_SYSCALL_RET before syscall error return Shivaprasad reported a boot failure due to userspace processes crash on abort() from libc.so.6. It was bisected to merge request commit '3424d8c18a7d ("Merge tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")' Upon checking the merge, when syscall_enter_from_user_mode_randomize_stack fails, which could happen when a tracer like seccomp or ptrace intercepts and skips the syscall, the code returns to userspace immediately without clearing the intermediate flag which was set. When the next syscall is made, it immediately aborts the valid syscall since the flag is still set. Hence clear the flag on occurrence of first failure. Reported-by: Shivaprasad G Bhat Closes: https://lore.kernel.org/all/e301014d-568f-4ed5-bc64-b8a85ca0b1e1@linux.ibm.com/ Fixes: 3424d8c18a7d ("Merge tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip") Signed-off-by: Shrikanth Hegde Tested-by: Venkat Rao Bagalkote Tested-by: Shivaprasad G Bhat Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260828053811.1042300-1-sshegde@linux.ibm.com commit 2f37fba846c9fdff5fc15b6d93656057ccd13031 Author: Ibrahim Hashimov Date: Sat Jul 25 15:51:54 2026 +0200 mac802154: fix use-after-free of sdata via queued RX frames The RX softirq producer ieee802154_subif_frame() queues received beacon and MAC-command frames onto local->rx_beacon_list / rx_mac_cmd_list and schedules a process-context worker, storing a raw mac_pkt->sdata (and skb->dev == sdata->dev) with neither a reference nor any locking: - the lists have no lock: the softirq producer list_add_tail()s while the mac_wq worker list_del()s, so sibling interfaces on the same phy corrupt the list; - the workers dereference the interface after it may have been freed. mac802154_rx_mac_cmd_worker() touches mac_pkt->sdata directly, and mac802154_rx_beacon_worker() -> mac802154_process_beacon() dereferences skb->dev (== sdata->dev). Removing an interface frees its sdata (netdev_priv) while a queued frame still points at it, so a later worker run is a use-after-free. Reproduced under KASAN by flooding a victim interface with MAC command frames and removing it (the beacon path is the same class via skb->dev): BUG: KASAN: slab-use-after-free in mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] Read of size 4 at addr ffff888002f9ea18 by task kworker/u8:1/31 Workqueue: phy0-mac-cmds mac802154_rx_mac_cmd_worker [mac802154] Call Trace: mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] process_one_work+0x611/0xe80 worker_thread+0x52e/0xdc0 kthread+0x30c/0x630 ret_from_fork+0x2fd/0x3e0 Fix both lists together: - add local->rx_lock and take it around every list access: the softirq producer (plain spin_lock, softirq context) and the workers and flush (spin_lock_bh, process context); - pin the interface for the lifetime of a queued frame with netdev_hold()/netdev_put(), so the worker can safely dereference sdata / skb->dev even while the interface is being removed; - dequeue under the lock at the head and loop-drain the whole list in the workers (they previously processed one frame per run and relied on a later enqueue to drain the rest); - drop not-yet-started frames of an interface before it is unregistered, from ieee802154_if_remove() (after the RCU grace period) and from the ieee802154_remove_interfaces() loop -- the latter is the whole-phy teardown path, which does not go through ieee802154_if_remove(). An in-flight worker that already dequeued a frame keeps its own netdev reference; unregister_netdevice() then waits it out in netdev_run_todo(), which runs at rtnl_unlock() (rtnl released) and after the interface has been closed, so it does not pin rtnl. A worker blocked in an association TX only delays that one interface's unregister (the usual "waiting for %s to become free"), it does not hold rtnl. netdev_hold() is used for this reason instead of a cancel_work_sync() under rtnl, which would block on the worker's unbounded MLME TX wait via ieee802154_sync_queue(). The mac-command worker additionally skips processing for a stopped interface (ieee802154_sdata_running()), avoiding a needless association response during teardown. Fixes: 57588c71177f ("mac802154: Handle passive scanning") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/20260725135154.99876-1-security@auditcode.ai Signed-off-by: Stefan Schmidt commit d3609b540838945ab2ca5b65f32a2eb67bb284c8 Author: Aditya Garg Date: Thu Jul 23 10:01:36 2026 +0000 MAINTAINERS, mailmap: use Aditya Garg's linux.dev account Due to non standard IMAP and SMTP protocols by Proton Mail, the account was giving trouble. Since my linux.dev account has been approved, all communication related to Linux development shall now be done there. Signed-off-by: Aditya Garg Acked-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260723100136.14467-1-aditya.garg@linux.dev commit 115bf3e51538e74159e9fa46199468b69fd5df70 Author: Sun Jian Date: Tue Sep 1 04:40:11 2026 -0700 exec: Drop bprm loader before closing bprm->file free_bprm() currently drops what may be the final reference to bprm->file before calling bprm_drop_loader(). Since bprm_drop_loader() is attachable via BPF fentry and bprm->file is exposed as a BTF_TYPE_SAFE_TRUSTED pointer, the file can be observed after its reference has been released. Move bprm_drop_loader() before do_close_execat(bprm->file), keeping the file reference held while the hook runs. This preserves the existing trusted BTF contract without changing verifier behavior. The loader file and bprm->file have independent references, so this reordering does not change their required teardown ordering. Link: https://sashiko.dev/#/patchset/20260831092305.42062-1-tasos.papagiannnis@gmail.com?part=3 Signed-off-by: Sun Jian Link: https://patch.msgid.link/20260901114011.112375-1-sun.jian.kdev@gmail.com Signed-off-by: Christian Brauner (Amutable) commit 88f8113ab118ed0e187331324d6b60c694b2e0e2 Author: Melissa Wen Date: Fri Aug 7 13:56:21 2026 +0200 drm/amd/display: use plane color_mgmt_changed to track colorop changes This is a resubmission of commit d79716401a95 ("drm/amd/display: use plane color_mgmt_changed to track colorop changes") whose change was reverted by commit 0461ba9a7994 ("Merge tag 'amd-drm-next-7.3-2026-07-02' of https://gitlab.freedesktop.org/agd5f/linux into drm-next") during a merge conflict resolution. Original commit message: ``` Ensure the driver tracks changes in any colorop property of a plane color pipeline by using the same mechanism of CRTC color management and update plane color blocks when any colorop property changes. It fixes an issue observed on gamescope settings for night mode which is done via shaper/3D-LUT updates. ``` Fixes: 0461ba9a7994 ("Merge tag 'amd-drm-next-7.3-2026-07-02' of https://gitlab.freedesktop.org/agd5f/linux into drm-next") Acked-by: Alex Deucher Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260807115712.22423-1-mwen@igalia.com commit 2f38e26a5741abdf152c1b56b22144a06d30fd66 Merge: 08710f033e3e35 260c6308fe2e19 Author: Jakub Kicinski Date: Wed Sep 2 19:42:25 2026 -0700 Merge branch 'net-rds-own-the-fastpath-locks-across-connection-teardown' Allison Henderson says: ==================== net/rds: own the fastpath locks across connection teardown This is v5 of the follow-up set to "net/rds: Bug fix ports, part 2" [1] (v1 at [2], v2 at [3], v3 at [4], v4 at [5]). During review of part 2, the later half of that series needed more work than a respin, so it was split off into this set together with the companion fixes identified along the way. As discussed on the v2 thread, it is targeted at net. RDS connection teardown quiesces the transmit and receive-refill fast paths by waiting for the RDS_IN_XMIT/RDS_RECV_REFILL bits to be sampled clear. Sampling a bit clear is not owning it: the fast path can re-take its bit right after the wait returns and then run concurrently with the transport shutdown and the send-state reset. Oracle UEK closed this by making teardown acquire the bits as locks ("rds: Make sure transmit path and connection tear-down does not run concurrently"); patches 5 and 6 do the same for the two rds_send_path_reset() call sites upstream. Making teardown block on the bits as locks promotes several latent ordering bugs from rare to load-bearing, so they are fixed first: Patches 1 and 2 fix the release side of the two bit locks. release_in_xmit() and release_refill() both clear their bit and then test for waiters, but the barrier is on the wrong side of the clear to order the critical section's stores before the release, and the waiter check does not order against the clear. Once teardown blocks on these bits as locks (uninterruptible and untimed), a lost wake-up or a store observed out of order stops mattering only in theory. Use clear_bit_unlock() and wq_has_sleeper(), the pattern already half-present in release_in_xmit(). Patch 3: rds_conn_path_reset() wipes the whole cp_flags word with a plain store. Once teardown owns bits in that word across the reset, a blanket store would end lock ownership early - and it already races atomic RMWs on the same word today. Clear the bits the reset is responsible for individually, as Oracle UEK also does. Patch 4: rds_tcp_reset_callbacks() stores RDS_CONN_RESETTING unconditionally, which can overwrite the RDS_CONN_ERROR or RDS_CONN_DISCONNECTING of a shutdown already in progress on the same path and send that shutdown through an extra drop cycle. Once the accept path can park for the duration of a teardown (patch 6) that window widens, so make the transition conditional first, as Oracle UEK does. With those in place, patch 5 converts rds_tcp_reset_callbacks() from waiting on RDS_IN_XMIT to acquiring it, holding it across the socket swap and rds_send_path_reset(), and patch 6 has rds_conn_shutdown() hold both bit locks across the transport shutdown and path reset. Patch 7 fixes a pre-existing teardown-state hole that this series makes easier to hit but did not introduce. Since commit e97656d03ca0 the final transition in rds_conn_shutdown() accepts RDS_CONN_ERROR as well as RDS_CONN_DISCONNECTING, so that a FIN processed during the teardown does not derail the shutdown. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that a concurrent rds_conn_path_drop() queued along with it. For a FIN that is harmless; for rds_tcp_accept_one() it is not. A drop can race the accept's DOWN -> CONNECTING path claim, the accept then installs the freshly accepted socket while the drop's teardown - which sampled tc->t_sock before that socket existed - is still running, rds_connect_path_complete() fails and drops the path again, and if the in-flight shutdown's final transition then swallows that RDS_CONN_ERROR, the pass that should reap the just-installed socket finds the path already RDS_CONN_DOWN and does nothing. The socket is leaked with its callbacks armed and its rds_tcp_connection still on rds_tcp_tc_list, the peer sees an established connection that nothing reads, and the path wedges in RDS_CONN_DOWN. Make the final transition DISCONNECTING -> DOWN only and leave a racing drop's RDS_CONN_ERROR alone, so the pass it queued runs and tears down whatever attached to the path; the branch quiesces the reconnect timer itself, since a pending destroy can suppress that pass (see the changes below). This surfaced while re-reviewing v3: whether the release-then-transition ordering in patch 6 could let a woken waiter install a socket that the teardown then strands. Chasing that down, the reachable form of the leak turned out to be the accept-vs-drop race above rather than the parked-waiter path (a path mid-teardown is never handed to rds_tcp_reset_callbacks(): rds_tcp_accept_one_path() only claims a path it can move DOWN -> CONNECTING), and it predates this series. It reproduces on an instrumented kernel - a test-only drop injected into the accept window plus a widened teardown-to-tail window - as an ESTABLISHED socket with an ever-growing receive queue on a path stuck down; the same kernel runs clean with patch 7. The set was built per-commit, run through the rds selftests (tcp and rdma/rxe), and exercised with a connection/netns churn load and module load/unload cycles; the patch 7 destroy-window fix was additionally verified against an instrumented kernel that reproduces the timer-left-armed WARN deterministically (fires on every destroyed path unfixed, silent with the fix). ==================== Link: https://patch.msgid.link/20260828223921.202913-1-achender@kernel.org Signed-off-by: Jakub Kicinski commit 260c6308fe2e19ad519389d44d582e292aecc3af Author: Allison Henderson Date: Fri Aug 28 15:39:21 2026 -0700 net/rds: don't let rds_conn_shutdown() consume a concurrent drop rds_conn_shutdown() finishes by moving the path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts RDS_CONN_ERROR as the starting state of that final transition, so that a FIN processed in softirq context during the teardown does not derail the shutdown into a noisy error path. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN is a no-op. For the FIN case that is harmless - the socket the FIN arrived on is the very socket the teardown just released. It is not harmless for a dropper that attached something to the path first. rds_tcp_accept_one() is such a dropper. Its path claim in rds_tcp_accept_one_path() transitions RDS_CONN_DOWN -> RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous socket in softirq context, an administrative reset - can put the path into RDS_CONN_ERROR between that claim and the state check that follows, which accepts RDS_CONN_ERROR. The accept then installs the freshly accepted socket with rds_tcp_set_callbacks() while the queued teardown - which sampled tc->t_sock before this socket existed - is still running. rds_connect_path_complete() fails its transition to RDS_CONN_UP and drops the path again, queueing the pass that should reap the socket it just installed. If the in-flight shutdown's final transition consumes that drop's RDS_CONN_ERROR, the queued pass finds the path in RDS_CONN_DOWN and does nothing. The installed socket is never torn down: it sits established with its callbacks armed and its rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some later event drops it again. Reproduced with widened race windows as an ever-growing receive queue on a socket owned by a path stuck in RDS_CONN_DOWN, with the peer's send path wedged behind it. Make the final transition only DISCONNECTING -> DOWN. If it fails because the path is in RDS_CONN_ERROR, a drop raced the teardown: cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one piece of the skipped tail that must not be left behind - and return, letting the pass the drop queued finish the job: it tears down whatever attached to the path in the meantime, completes the transition to RDS_CONN_DOWN, and re-arms the reconnect from its own tail. The timer quiesce in that branch matters because the racing drop does not always queue that pass: rds_conn_path_drop() returns without queueing when a destroy is pending - exactly the situation during a netns teardown or module unload, when a FIN on the dying socket is processed while rds_conn_path_destroy() flushes cp_down_w. If the flushed pass is the one that takes this return, no later pass exists, and rds_conn_path_destroy() would find cp_conn_w still armed (WARN_ON) and then free a path whose reconnect timer can still fire. With the cancel in the branch, every exit of a shutdown pass leaves the timer quiesced no matter which pass completes the transition. The FIN case keeps making progress, one pass later and still without noisy logging. Any other state keeps today's rds_conn_path_error() handling; no current cp_state writer can leave a DISCONNECTING path in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from a non-DISCONNECTING state), so that branch is defensive. On kernels without the preceding patches the same hazard exists with the sample-based quiesce; the fix applies there equally. Fixes: e97656d03ca0 ("rds: tcp: allow progress of rds_conn_shutdown if the rds_connection is marked ERROR by an intervening FIN") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-8-achender@kernel.org Signed-off-by: Jakub Kicinski commit 813f3582ac7ae9f60f917937d54660e0952d5f2d Author: Håkon Bugge Date: Fri Aug 28 15:39:20 2026 -0700 net/rds: acquire the fastpath locks in rds_conn_shutdown() rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them ("rds: Make sure transmit path and connection tear-down does not run concurrently"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on the allocation-failure fallback where a path shares rds_wq, the work items simply serialize). Nor is the blocking wait itself new: rds_tcp_reset_callbacks() has waited on RDS_IN_XMIT from the krdsd work item since commit 335b48d980f6 ("RDS: TCP: Add/use rds_tcp_reset_callbacks to reset tcp socket safely"); this patch stretches its worst case from a sender's batch to the teardown's drain. The alternative to parking is the accept path racing the teardown, which is what these patches close; making the teardown itself non-blocking is a separate item. One observable side effect: the SENDING flag reported by rds-info has always mirrored RDS_IN_XMIT, so it now also covers the window where teardown owns the bit. The comments that describe the old sample-based handshake or name rds_send_xmit() as the only other holder of these bits - in rds_send_xmit(), above rds_conn_path_reset(), in rds_ib_recv_refill() and in rds_tcp_reset_callbacks() - are updated to match. For anyone backporting this patch standalone: it depends on "net/rds: clear cp_flags bits individually in rds_conn_path_reset()" and "net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()" earlier in this series. Without the former, the blanket cp_flags clear in rds_conn_path_reset() would drop both held bits in the middle of the teardown; without the latter, rds_tcp_reset_callbacks() would still sample t_sock without owning RDS_IN_XMIT. "net/rds: use clear_bit_unlock() in release_refill()" is needed for the refill side's release to pair with the acquire added here, and the follow-up "net/rds: don't let rds_conn_shutdown() consume a concurrent drop" completes the teardown-state handling for the waiter this patch parks; a backport should carry all four. Fixes: 0f4b1c7e89e6 ("rds: fix rds_send_xmit() serialization") Signed-off-by: Håkon Bugge [achender: reimplement for net-next shutdown path: acquire the existing RDS_IN_XMIT/RDS_RECV_REFILL bit locks in rds_conn_shutdown() and release after teardown; update comments and commit message] Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-7-achender@kernel.org Signed-off-by: Jakub Kicinski commit 02c5f9dc2efd823e061954d564ce00bacd1bebeb Author: Allison Henderson Date: Fri Aug 28 15:39:19 2026 -0700 net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset(). Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent. Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end. The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock. Two details of the old code go away with the same change: - t_sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds_conn_shutdown() releases that socket and clears t_sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS_IN_XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today. - The old !osock early path called rds_send_path_reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS_CONN_RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t_conn_path_lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped. The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them. Fixes: 335b48d980f6 ("RDS: TCP: Add/use rds_tcp_reset_callbacks to reset tcp socket safely") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-6-achender@kernel.org Signed-off-by: Jakub Kicinski commit e8e60d74fec49ccae2aea9b04a6eb162feb8d9af Author: Gerd Rausch Date: Fri Aug 28 15:39:18 2026 -0700 net/rds: tcp: don't force RDS_CONN_RESETTING over a concurrent shutdown rds_tcp_reset_callbacks() resolves a duelling SYN by storing RDS_CONN_RESETTING into cp_state unconditionally. Nothing serializes that store against the shutdown path: rds_tcp_accept_one() checks for RDS_CONN_CONNECTING or RDS_CONN_ERROR under t_conn_path_lock, but neither rds_conn_path_drop(), which forces RDS_CONN_ERROR, nor rds_conn_shutdown(), which moves the path to RDS_CONN_DISCONNECTING under cp_cm_lock, takes that lock. The store can therefore land on top of a shutdown that is already in progress, or that gets queued right after the accept-side check. When it does, the shutdown worker's final DISCONNECTING -> DOWN transition fails and the path goes through rds_conn_path_error() and a second drop/shutdown cycle instead of a clean reconnect, tearing down the socket the accept path has just installed. Before commit ad22d24be635 ("net/rds: No shortcut out of RDS_CONN_ERROR") a path found in RDS_CONN_RESETTING even made rds_conn_shutdown() bail out altogether. Make the transition conditional: move CONNECTING -> RESETTING (or stay in RESETTING from an earlier duel), and drop the path in any other state. The drop has side effects of its own: it replaces the shutdown's RDS_CONN_DISCONNECTING (or RDS_CONN_ERROR) with RDS_CONN_ERROR and queues one more cp_down_w run. The difference is that rds_conn_shutdown() accepts RDS_CONN_ERROR in its final transition to RDS_CONN_DOWN, so the shutdown in flight completes normally instead of through rds_conn_path_error(); the extra down-work pass then finds the path already down and falls through to the reconnect check, or catches a reconnect that has already started and restarts it. The accept path still installs the new socket, rds_connect_path_complete() then fails its RESETTING -> UP transition and drops it: the raced socket ends up torn down as it does today. The comment at that call site, which promised that rds_connect_path_complete() marks the path RDS_CONN_UP, is updated to name this outcome as well. The state can change again between the failed transitions and the drop. That is inherent to rds_conn_path_drop(), which the socket state-change callbacks also call unconditionally, and costs at most one extra drop/reconnect cycle. Based on Oracle UEK commit "net/rds: Don't force state RDS_CONN_RESETTING" by Gerd Rausch. Fixes: 9c79440e2c5e ("RDS: TCP: fix race windows in send-path quiescence by rds_tcp_accept_one()") Signed-off-by: Gerd Rausch [achender: port to net-next: use the two-argument rds_conn_path_transition()/rds_conn_path_drop() and rewrite the changelog for the upstream shutdown path] Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-5-achender@kernel.org Signed-off-by: Jakub Kicinski commit 103c4b13c4f50322910078d1c02f29334a574122 Author: Allison Henderson Date: Fri Aug 28 15:39:17 2026 -0700 net/rds: clear cp_flags bits individually in rds_conn_path_reset() rds_conn_path_reset() wipes the whole flag word with a plain cp->cp_flags = 0 store. Every other accessor of that word uses atomic bitops, and some of them can run concurrently with the reset: RDS_LL_SEND_FULL is set from rds_send_xmit() and cleared from the transport completion paths, neither of which holds anything that excludes the shutdown worker. A plain store racing an atomic read-modify-write on the same word is a data race, and whichever side loses has its update silently discarded. Clear the two bits the reset is actually responsible for instead. RDS_IN_XMIT and RDS_RECV_REFILL need no store at all here: they belong to the caller, rds_conn_shutdown(), which waits for both to be clear before calling the transport shutdown and this reset. This also gives every bit in cp_flags a single well-defined writer discipline, which the following patches rely on when they turn RDS_IN_XMIT and RDS_RECV_REFILL into bit locks held across the teardown: a blanket store mid-teardown would destroy lock ownership that an atomic clear preserves. Oracle UEK carries the same conversion ("net/rds: Preserve essential connection state flags"), motivated by its asynchronous shutdown state machine, whose progress and destroy flags must survive the reset. UEK's variant also clears RDS_IN_XMIT and RDS_RECV_REFILL because there the reset runs as the final step of a teardown that owns both bits, making those clears its unlock. Upstream that release belongs in rds_conn_shutdown(): once a later patch in this series turns the two bits into locks held across the teardown, ending ownership needs release semantics and a wake-up that a plain clear inside the reset would not provide. Based on Oracle UEK commit "net/rds: Preserve essential connection state flags" by Gerd Rausch. Fixes: 00e0f34c6166 ("RDS: Connection handling") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-4-achender@kernel.org Signed-off-by: Jakub Kicinski commit 17c4476dbb9c3bfd34193a6c22f2c3da8747134a Author: Allison Henderson Date: Fri Aug 28 15:39:16 2026 -0700 net/rds: use clear_bit_unlock() in release_refill() release_refill() drops the RDS_RECV_REFILL bit with a plain clear_bit(). clear_bit() has no ordering semantics, and the smp_mb__after_atomic() that follows it sits on the wrong side for a lock release: it orders the clear against the waitqueue_active() load below it, but does nothing to order the refill critical section's ring and descriptor stores before the clear itself. That matters once connection teardown owns RDS_RECV_REFILL as a lock across the transport shutdown and path reset, rather than sampling it clear, which "net/rds: acquire the fastpath locks in rds_conn_shutdown()" later in this series arranges: on a weakly ordered architecture the teardown can win the bit and start the shutdown and reset while some of the refill's stores are not yet visible to it. The same gap existed under the sample-based scheme - a waiter that saw the bit clear had no guarantee it also observed the refill's stores - but taking the bit as a lock makes the missing release pairing load-bearing. Switch to clear_bit_unlock(), which orders the critical section before the release, and replace the open-coded barrier-plus-waitqueue_active() with wq_has_sleeper(), whose internal full barrier keeps the store-buffering guarantee between clearing the bit and checking for sleepers. This mirrors what "net/rds: use wq_has_sleeper() in release_in_xmit()" does for RDS_IN_XMIT. The fast-path acquire side, acquire_refill(), uses test_and_set_bit(), a full-barrier RMW that pairs with this release. The teardown at this point in the series still samples the bit, so on its own this change is release-side hardening; the shutdown-conversion patch named above makes the teardown acquire the bit with the same RMW, completing the pairing at the end of the series. Fixes: 73ce4317bf98 ("RDS: make sure we post recv buffers") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-3-achender@kernel.org Signed-off-by: Jakub Kicinski commit 6d0c8b7073913011459cf968cbbadd341e166bc3 Author: Allison Henderson Date: Fri Aug 28 15:39:15 2026 -0700 net/rds: use wq_has_sleeper() in release_in_xmit() release_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then checks waitqueue_active() to decide whether anyone needs waking. clear_bit_unlock() is only a release operation: it orders the critical section before the bit clear, but does not order the subsequent plain load of the wait queue head after it. The waiter side does the mirror image - it adds itself to the wait queue and then tests the bit. That is the classic store-buffering pattern: the releasing CPU can read the wait queue as empty while the waiting CPU still reads the bit as set, so the sleeper is never woken. The waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(), both in uninterruptible wait_event() with no timeout. A lost wake-up strands the shutdown worker on its single-threaded workqueue until some other sender releases the bit again - and on a connection that is being torn down precisely because it failed, there may never be another sender. The barrier used to be there: release_in_xmit() did clear_bit() followed by smp_mb__after_atomic() until commit 1422f28826d2 ("rds: introduce acquire/release ordering in acquire/release_in_xmit()") folded both into clear_bit_unlock(), which strengthened the lock hand-off but silently dropped the full barrier the wake-up check depends on. The refill counterpart, release_refill() in net/rds/ib_recv.c, still carries its smp_mb__after_atomic() for exactly this reason. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier. Fixes: 1422f28826d2 ("rds: introduce acquire/release ordering in acquire/release_in_xmit()") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260828223921.202913-2-achender@kernel.org Signed-off-by: Jakub Kicinski commit 08710f033e3e35704e45adf8a95b5043ece34899 Author: Ian Lin Date: Mon Aug 31 16:41:24 2026 +0800 net: usb: qmi_wwan: add Compal EXM-G1x support The Compal EXM-G1x is a Qualcomm SDX12-based LTE modem. Add support for its QMI WWAN interface 8 using the DTR quirk. Tested on a Compal EXM-G1x modem. Signed-off-by: Ian Lin Link: https://patch.msgid.link/20260831084124.65074-1-jisayme@gmail.com Signed-off-by: Jakub Kicinski commit d85f521a9afb786b1d95bbcb218d3afdf3fe73ab Author: Nicolai Buchwitz Date: Mon Aug 31 13:31:28 2026 +0200 net: macb: exclude software FCS from TX byte statistics Frames for which macb_pad_and_fcs() supplies the FCS have four FCS bytes appended, and TX completion then accounts the grown skb->len. tx_bytes is defined to exclude the FCS, so these frames are reported four bytes too large. Track only the number of FCS bytes appended in software, 0 or ETH_FCS_LEN, and subtract that from skb->len at completion. skb->len already reflects the padded length by then, so there is nothing else to store. macb_pad_and_fcs() already returns 0 on every non-error path. Return the FCS length from there instead, rather than recomputing the same check in the caller. BQL stays on the padded skb->len that netdev_tx_sent_queue() saw. Fixes: 653e92a9175e ("net: macb: add support for padding and fcs computation") Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260831113128.1678674-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski commit debac3a20dec524a59625cf10fa2f18571127824 Author: Kuniyuki Iwashima Date: Tue Sep 1 00:55:44 2026 +0000 net: Remove conflicting altnames for dying netns in __dev_change_net_namespace(). syzbot reported the warning in cfg80211_pernet_exit(). [0] The repro does the following: 1. create two device in root netns and non-root netns 2. assign the same altname for the two devices 3. remove the non-root netns Since commit 7663d522099e ("net: check for altname conflicts when changing netdev's netns"), cfg80211_switch_netns() and cfg802154_switch_netns() fail if init_net has a device with the conflicting altname. default_device_exit_net() had the same issue and commit d09486a04f5d ("net: fix removing a namespace with conflicting altnames") fixed it. cfg80211_pernet_exit() and cfg802154_pernet_exit() need the same fix. Let's generalise the fix by removing conflicting altnames for dying netns in __dev_change_net_namespace(). [0]: cfg80211_switch_netns(rdev, &init_net) WARNING: net/wireless/core.c:1871 at cfg80211_pernet_exit+0xd5/0x120 net/wireless/core.c:1871, CPU#1: kworker/u8:9/1160 Modules linked in: CPU: 1 UID: 0 PID: 1160 Comm: kworker/u8:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 Workqueue: netns cleanup_net RIP: 0010:cfg80211_pernet_exit+0xd5/0x120 net/wireless/core.c:1871 Code: e8 03 42 80 3c 20 00 74 08 4c 89 f7 e8 b4 ef 0e f7 4d 8b 36 49 81 fe 20 10 4a 90 74 12 e8 03 3d 9f f6 eb 85 e8 fc 3c 9f f6 90 <0f> 0b 90 eb cc e8 f1 3c 9f f6 eb 05 e8 ea 3c 9f f6 5b 41 5c 41 5e RSP: 0018:ffffc900057a78f0 EFLAGS: 00010293 RAX: ffffffff8b287154 RBX: ffff88807ba72780 RCX: ffff8880213e8000 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: 00000000ffffffef R08: ffffffff9024cc67 R09: 0000000000000000 R10: fffff52000af4eb0 R11: fffffbfff204998d R12: dffffc0000000000 R13: ffffffff904a1080 R14: ffff888144ed0008 R15: ffff888144ed0e20 FS: 0000000000000000(0000) GS:ffff888124de6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005642de0a8a70 CR3: 000000007a40c000 CR4: 00000000003526f0 Call Trace: ops_exit_list net/core/net_namespace.c:200 [inline] ops_undo_list+0x43d/0x8d0 net/core/net_namespace.c:253 cleanup_net+0x572/0x810 net/core/net_namespace.c:706 process_one_work kernel/workqueue.c:3387 [inline] process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3551 kthread+0x38b/0x480 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fixes: 36fbf1e52bd3 ("net: rtnetlink: add linkprop commands to add and delete alternative ifnames") Reported-by: syzbot+74f338e09f1ef3ee6457@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a96219e.04428c52.29b18.0001.GAE@google.com/T/ Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260901005550.2042357-1-kuniyu@google.com Signed-off-by: Jakub Kicinski commit 5a3f7a683aee56e1f15c9d53041f3236767eaae7 Author: Jun Yang Date: Mon Aug 31 19:13:04 2026 +0800 net: bridge: mcast: don't truncate the port group walk on teardown __br_multicast_disable_port_ctx() and br_multicast_del_port() walk port->mglist with hlist_for_each_entry_safe(). However, br_multicast_find_del_pg() can also delete other entries from the same list through br_multicast_fwd_src_remove() or __fwd_del_star_excl(). If such an entry is the iterator's saved next node, hlist_del_init() clears its ->next and terminates the walk early. The reproducer triggers this in both teardown walks, leaving port groups in the bridge mdb with a dangling ->key.port after del_nbp() frees the port: BUG: KASAN: slab-use-after-free in __mdb_fill_info+0x1191/0x1320 __mdb_fill_info+0x1191/0x1320 br_mdb_dump+0x594/0xe40 rtnl_mdb_dump+0x1cf/0x5d0 Use hlist_del_init_rcu() to unlink the group while preserving ->next. br_multicast_del_pg() and the teardown walks run under br->multicast_lock. The GC worker must acquire the same lock before detaching the group for destruction, so the node remains alive while the walk uses the preserved pointer. Preserving ->next means a walk can now reach a group that an earlier iteration already deleted as a side effect. That group is off mp->ports, so br_multicast_find_del_pg() would fall through its port scan and hit the trailing WARN_ON(1). Skip such groups at the top of that helper: a port group is put on port->mglist when it is created and only unlinked when it is deleted, so hlist_unhashed() identifies exactly this case. Fixes: b08123684bd5 ("net: bridge: mcast: install S,G entries automatically based on reports") Cc: stable@vger.kernel.org Suggested-by: Nikolay Aleksandrov Reported-by: TencentOS Corvus AI Signed-off-by: Jun Yang Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260831111330.199543-1-junvyyang@tencent.com Signed-off-by: Jakub Kicinski commit af602c7aa5fedc9be3043244017aef4f26c96b70 Author: Eric Dumazet Date: Mon Aug 31 20:30:42 2026 +0000 bonding: do not clear curr_active_slave prematurely when releasing all slaves When releasing all slaves during bond destruction (all == true), __bond_release_one() unconditionally clears bond->curr_active_slave to NULL in every iteration. If a backup slave is released before the active slave, bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(), which increments the active slave dev promiscuity counter and sets bond_info->primary_is_promisc = 1. Because bond->curr_active_slave was prematurely cleared to NULL when releasing the backup slave, the subsequent iteration releasing the active slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL) is skipped. Consequently, bond_alb_handle_active_change() is never called to decrement the promiscuity counter, permanently leaking promiscuous mode on the physical device after bond teardown. When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets bond->curr_active_slave to NULL. We only need to avoid selecting a new active slave when all == true. Replace the if (all) branch with if (!all && oldcurrent == slave). Fixes: 0896341a44bf ("bonding: fix bond_release_all inconsistencies") Signed-off-by: Eric Dumazet Acked-by: Jay Vosburgh Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260831203042.164466-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit ac0aaef0aa997fcdcb2458bd584539ba8608d33e Author: Eduard Zingerman Date: Wed Sep 2 16:36:58 2026 -0700 selftests/bpf: BPF_PSEUDO_FUNC reference to the main program Add a test case for a BPF_PSEUDO_FUNC load instruction that references the entry function of the program it belongs to. W/o the previous patch the verifier accepts this program thus allowing a runtime call at a bogus address. See previous patch for detailed description. Main function needs to be marked with BTF_FUNC_STATIC for the test to trigger the bug, the patch uses test_verifier harness instead of test_prog because libbpf has no way to convey this. Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260902233658.1186477-2-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov commit 374b2c5561db80fcdd7cdce44af37a49416f61c7 Author: Eduard Zingerman Date: Wed Sep 2 16:36:57 2026 -0700 bpf: reject BPF_PSEUDO_FUNC reference to the main program fixups.c:jit_subprogs() rewrites BPF_PSEUDO_FUNC loads to contain real function addresses. This function is invoked from bpf_jit_subprogs() only when env->subprog_cnt > 1. Meaning that for any program like below: int main(void *ctx) { void *ptr = main; ... bpf_timer_set_callback(..., ptr); ... } The 'ptr' won't be ever converted to contain an address. In combination with e.g. bpf_timer_set_callback() this would lead to a function call at a bogus address. Instead of complicating the implementation, just assume that no useful program needs main to be a sync or async callback and reject BPF_PSEUDO_FUNC loads for the main subprogram. Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260902233658.1186477-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov commit 0c4256196b3a105307e2235fbfd85e768bbcdd0f Author: Masami Hiramatsu (Google) Date: Sun Aug 30 23:27:23 2026 +0900 kprobes: Protect kprobe_blacklist with RCU __within_kprobe_blacklist() traverses kprobe_blacklist without holding kprobe_mutex. When a module is unloaded, kprobe_remove_area_blacklist() removes blacklist entries and immediately frees them with kfree(). A concurrent call to within_kprobe_blacklist() can therefore dereference freed memory. Furthermore, within_kprobe_blacklist() can be called in atomic or non-preemptible contexts where the sleeping kprobe_mutex cannot be taken. Protect kprobe_blacklist with RCU. Use guard(rcu)() and list_for_each_entry_rcu() for traversal, list_add_tail_rcu() for insertions, list_del_rcu() for deletions, and kfree_rcu() to reclaim entries safely after a grace period. Link: https://lore.kernel.org/all/178810004323.64882.16493230858653316962.stgit@devnote2/ Fixes: 376e242429bf ("kprobes: Introduce NOKPROBE_SYMBOL() macro to maintain kprobes blacklist") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260807155802.F06041F000E9@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.7-flash Signed-off-by: Masami Hiramatsu (Google) commit 86b7a239ec6b14a7544200ede85474c6f5526049 Author: Henry Martin Date: Wed Aug 26 11:00:09 2026 +0800 tracing/probes: Fix use-after-free on field name/type of events with multiple probes The fields of a probe-based dynamic event (kprobe, uprobe, eprobe and fprobe events) are created in traceprobe_define_arg_fields() by handing the probe_arg name/type strings to trace_define_field(), which only stores the pointers without copying. Those strings are owned by the trace_probe and are freed when that probe is removed. An event can have several probes attached. The field list is defined only once, by the first probe that registers the event, but it is kept alive by any surviving sibling probe. Deleting just that first probe by symbol - # primary A: fields are defined from A's args echo 'p:kprobes/ev vfs_read a1=$arg1' > kprobe_events # append B: shares A's event call echo 'p:kprobes/ev vfs_write a1=$arg1' >> kprobe_events # delete only A (matched by symbol), B survives echo '-:kprobes/ev vfs_read' >> kprobe_events frees A's args (trace_probe_cleanup() -> traceprobe_free_probe_arg()), but trace_probe_unlink() keeps the trace_probe_event because the probe list is not empty. The event call stays registered via B while its fields now reference freed memory. Any field lookup then reads it, e.g. echo 'a1 == 1' > events/kprobes/ev/filter BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0 Call Trace: strcmp trace_find_event_field parse_pred process_preds create_filter apply_event_filter event_filter_write field->name references parg->name (kstrdup'd, freed with the probe) and, for array arguments, field->type references parg->fmt (kmalloc'd, freed with the probe) - the scalar type otherwise points at the static fmttype rodata, which is safe. Have traceprobe_define_arg_fields() duplicate the name and type strings and anchor the copies on the trace_probe_event, which embeds the event call and outlives every individual probe; trace_probe_event_free() releases them. The reproducer above triggers reliably; the field lookup and the delete both run under event_mutex, so this is a dangling reference after removal rather than a race. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab. Link: https://lore.kernel.org/all/20260826030009.1855331-1-bsdhenrymartin@gmail.com/ Fixes: ca89bc071d5e4 ("tracing/kprobe: Add multi-probe per event support") Signed-off-by: Henry Martin Signed-off-by: Masami Hiramatsu (Google) commit 871e07b6e3841cc9a258572c9ce8d1ea65f6ce7b Author: Masami Hiramatsu (Google) Date: Tue Sep 1 23:22:00 2026 +0900 tracing/probes: Fix code indent in get_bitoffset_of_field() Fix code block indentation introduced by commit f21834524025 ("tracing/probes: Support field specifier option for typecast"). Link: https://lore.kernel.org/all/178827252027.123716.7095571176291547259.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Steven Rostedt commit 47e93045a2db80d24f5fef65adecc6b2b32efa23 Author: Masami Hiramatsu (Google) Date: Tue Sep 1 23:21:49 2026 +0900 tracing/probes: Fix BTF kflag check for anonymous struct member access btf_find_struct_member() traverses into nested anonymous structures and unions to find a struct member. However, get_bitoffset_of_field() in trace_probe.c checked btf_type_kflag(type) using the outer parent type instead of the actual anonymous structure/union that directly contains the found member. If the parent structure and anonymous structure have mismatched kflags (e.g., the parent has kflag=0 while the anonymous structure has kflag=1 because it contains bitfields), the bitfield size encoded in the upper 8 bits of member->offset is erroneously treated as part of the byte/bit offset, corrupting the resolved offset and failing to set last_bitsize. Similarly, btf_find_struct_member() pushed anonymous member offsets onto anon_stack without masking BTF_MEMBER_BIT_OFFSET() when kflag is set. To fix this problem, update btf_find_struct_member() to return actual containing structure/union type via member_type, use appropriate __btf_member_bit_offset() to get bit offset, and use member_type for btf_type_kflag() in get_bitoffset_of_field(). Link: https://lore.kernel.org/all/178827250904.123716.17452648791331881284.stgit@devnote2/ Fixes: c440adfbe302 ("tracing/probes: Support BTF based data structure field access") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260822095110.0772E1F000E9@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.7-flash Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Steven Rostedt commit f36d94a20ca185bcadef3a10b980cd2cfd72d53a Author: Masami Hiramatsu (Google) Date: Tue Sep 1 23:21:37 2026 +0900 tracing/probes: Fix anon_stack check for unnamed bitfields in btf_find_struct_member btf_find_struct_member() traverses into nested anonymous structures and unions by pushing members with !member->name_off onto anon_stack. However, it does not consider the unnamed bitfields (e.g. `int : 5` or `unsigned int : 0`) which also have member->name_off == 0. If such an unnamed bitfield is pushed to anon_stack, the btf_find_struct_member() return an error even if there are other valid entries in anon_stack. To fix this, only push unnamed struct/union members to anon_stack. Also move the btf_type_is_struct() check to the entry of this function because now it is sure only struct/union are pushed to anon_stack. Link: https://lore.kernel.org/all/178827249775.123716.7813217688423513612.stgit@devnote2/ Fixes: 302db0f5b3d8 ("tracing/probes: Add a function to search a member of a struct/union") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260830143859.D56991F00A3D@smtp.kernel.org/ Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Steven Rostedt commit 2c018cc4842c33f0c732962e2ab58635e8ae5823 Author: Chengfeng Ye Date: Mon Aug 24 01:05:38 2026 +0800 netfilter: nf_log: unregister loggers before per-net teardown nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration. Fixes: 5b023fc8d8e0 ("netfilter: enable per netns support for nf_loggers") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Pablo Neira Ayuso commit fec9b1de0d02de8dafa3cc344bcb91cf28660643 Author: Chengfeng Ye Date: Mon Aug 24 20:12:38 2026 +0800 netfilter: cttimeout: prevent UAF during module unload nf_ct_set_timeout() protects the timeout hook dereference and policy lookup with rcu_read_lock(). cttimeout_exit(), however, unregisters the per-net operations before it clears the hook. This allows the following interleaving: CPU 0 CPU 1 cttimeout_exit() nf_ct_set_timeout() unregister_pernet_subsys() rcu_read_lock() kfree(pernet) h = nf_ct_timeout_hook h->timeout_find_get() nfct_timeout_pernet() The hook still points to ctnl_timeout_find_get() when CPU 1 looks up the already freed per-net timeout list. KASAN reported: BUG: KASAN: slab-use-after-free in ctnl_timeout_find_get Read of size 8 by task poc/90 Call Trace: ctnl_timeout_find_get+0x271/0x2a0 [nfnetlink_cttimeout] nf_ct_set_timeout+0x7b/0x3c0 xt_ct_tg_check+0x724/0xb20 xt_check_target+0x234/0xa90 do_ipt_set_ctl+0x570/0x1270 Allocated by task 89: __kmalloc_noprof+0x16e/0x460 ops_init+0x6d/0x420 register_pernet_operations+0x2f6/0x670 Freed by task 91: kfree+0x131/0x390 ops_undo_list+0x3d4/0x730 unregister_pernet_operations+0x232/0x490 unregister_pernet_subsys+0x1c/0x30 cttimeout_exit+0x52/0x970 [nfnetlink_cttimeout] Clear the hook and wait for existing readers before unregistering the per-net operations. This blocks new policy lookups and ensures readers that observed the hook finish before the per-net storage is freed. Fixes: ebfbe67568a7 ("netfilter: cttimeout: use net_generic infra") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Pablo Neira Ayuso commit e8f8231824b5815f57ce62cba116e511b10196de Author: Joas Antonio dos Santos Date: Tue Aug 18 06:31:43 2026 -0700 netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() sip_skip_whitespace() returns dptr unchanged when its own loop exhausts the buffer (dptr == limit), instead of NULL like its sibling sip_follow_continuation() returns on its own "no more data" path. ct_sip_get_header() only checks for NULL after calling it: dptr = sip_skip_whitespace(dptr, limit); if (dptr == NULL) break; if (*dptr != ':' || ++dptr >= limit) break; so a recognized header name followed only by spaces/tabs running to the exact end of the SIP payload, with no colon, makes the very next statement read one byte past the buffer. Make both "no more data" outcomes return NULL, matching the convention sip_follow_continuation() already uses and that both existing callers already check for. Fixes: ea45f12a2766d ("[NETFILTER]: nf_conntrack_sip: parse SIP headers properly") Signed-off-by: Joas Antonio dos Santos Signed-off-by: Pablo Neira Ayuso commit b04578b74f2d3755548fe9e829e3b2a6c6f966a1 Author: Kyle Zeng Date: Mon Aug 10 15:13:47 2026 -0700 ipvs: fix reversed sequence option serialization hton_seq() expects the host-order source first and the unaligned network-order destination second. The version 1 sync sender passes these arguments in reverse for both sequence blocks. This leaves 24 bytes of the kmalloc-backed message unwritten. It may disclose stale heap data and replace the live connection sequence state with values read from the buffer. Pass the connection sequence state as the source and the message payload as the destination for both blocks. Fixes: 986a07579533 ("IPVS: Backup, Change sending to Version 1 format") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Kyle Zeng Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso commit 74cb39735b6cd0aff4b5584158f09376fd97aadf Author: Kyle Zeng Date: Mon Aug 10 15:10:34 2026 -0700 ipvs: reject invalid states in connection template sync records IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records. Fixes: 275411430f89 ("ipvs: add assured state for conn templates") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Kyle Zeng Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso commit d806d5a85dcbe2a0f181b2f0f9f61ddfbefa1818 Author: Karl Mehltretter Date: Wed Sep 2 20:28:14 2026 +0200 smb: client: pin DFS superblock in iterator callback tcon_super_cb() stores a raw superblock pointer, but __cifs_get_super() takes its active reference only after iterate_supers_type() has dropped s_umount and its passive reference. Concurrent DFS automount expiry can therefore free the superblock before cifs_sb_active() uses it. A deterministic KASAN test reproduces the race as: BUG: KASAN: slab-use-after-free in cifs_sb_active+0x77/0x80 The same test passes with this change applied. Take the active reference in the callback while iterate_supers_type() still holds s_umount shared. cifs_put_tcp_super() remains the matching release. Fixes: bacd704a95ad ("cifs: handle prefix paths in reconnect") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Paulo Alcantara commit d9d7eeb0cea5b55b82888f443622fd8d4ee064f3 Author: Aohan Mei Date: Wed Sep 2 20:52:13 2026 +0800 smb: client: reject userspace cifs.idmap descriptions cifs.idmap key descriptions carry authority-bearing fields (owner and group SIDs and uid/gid values in "os:"/"gs:"/"oi:"/"gi:" form) that the cifs.idmap upcall helper treats as kernel-originating inputs. Unlike its sibling cifs.spnego, the cifs.idmap key type has no vet_description hook, so userspace can create keys of this type through request_key(2)/add_key(2) and supply those fields without CIFS origin. A request_key(2) call with a non-NULL callout then drives a root usermodehelper upcall (/sbin/request-key -> cifs.idmap) that consumes the unvetted description in root context. Only accept cifs.idmap descriptions while CIFS is using its private root_cred to request the key. id_to_sid()/sid_to_id() already run under override_creds(root_cred), so the kernel-originated path is unaffected. This mirrors commit 3da1fdf4efbc ("smb: client: reject userspace cifs.spnego descriptions"), which applied the same restriction to cifs.spnego. Fixes: 4d79dba0e007 ("cifs: Add idmap key and related data structures and functions (try #17 repost)") Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Assisted-by: CodeBuddy:Kimi-K3 Signed-off-by: Aohan Mei Acked-by: David Howells Signed-off-by: Paulo Alcantara commit 5be5bdda5863eacc964b609ba927764f253431b3 Author: Diego Oliva Date: Wed Sep 2 11:42:07 2026 +0100 smb: client: reject out-of-bounds DataOffset in CIFSSMBRead() The SMB1 synchronous read helper CIFSSMBRead() validates the server's DataLength against CIFSMaxBufSize and the caller's count, but never validates DataOffset. The copy source is formed as &pSMBr->hdr.Protocol + le16_to_cpu(pSMBr->DataOffset) and memcpy()'d for DataLength bytes with no check that the [DataOffset, DataOffset + DataLength) range lies within the response actually received from the server. A malicious or compromised SMB1 server can return a response carrying an in-range DataLength and a large DataOffset, driving the source pointer past the end of the response buffer. The memcpy() then copies adjacent kernel heap into the caller's read buffer (information disclosure), or reads unmapped memory and oopses (denial of service). SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount. Both DataOffset and the received response length recorded in rsp_iov.iov_len are relative to the start of the SMB header, so reject the response unless DataOffset + DataLength fits within that length, using overflow-safe arithmetic, before forming the source pointer. The response length has been validated by the previous patch, so the DataOffset and DataLength fields can be read safely here. While here, make data_length unsigned. It holds a length derived from unsigned on-the-wire fields and is only ever compared against unsigned quantities; print it with %u accordingly, and add __func__ to the cifs_dbg() calls in this function. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # 6.19.x Assisted-by: Bynario AI Signed-off-by: Diego Oliva Reviewed-by: David Howells Signed-off-by: Paulo Alcantara commit 940de590b839f71d6dc846160534bf202401b8b7 Merge: 89a312991dc6e6 2625480a1bf79c Author: Linus Torvalds Date: Wed Sep 2 16:02:02 2026 -0700 Merge tag 'hardening-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull hardening fix from Kees Cook: - Default randstruct off with rust for better allmodconfig coverage (Mark Brown) * tag 'hardening-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: hardening: Default randstruct off with rust for better allmodconfig support commit 13af55f71399f5e562f6cb59ad413476e513c4d4 Author: Yogesh Mohan Marimuthu Date: Thu Aug 20 09:52:50 2026 +0530 drm/amdgpu/userq: fix struct drm_amdgpu_info_device padding for 32bit compile need to pad before __u64 tcc_disabled_mask variable. This patch fixes 64bit Kernel + 32 bit mesa combination. But at the same time it will break 32bit Kernel(using this patch) + older 32bit mesa(not using this patch). This issue was discussd with alexander.deucher@amd.com, christian.koenig@amd.com and pierre-eric.pelloux-prayer@amd.com. Currently today 32 bit kernel + 32 bit userspace and 64 bit kernel and 64 bit userspace work. Mixed 64 bit kernel and 32 bit userspace is currently broken. Since 32 bit kernel and userspace is probably pretty rare these days and the data affected by this is not critical, Hence we can go ahead with this patch. Fixes: cf21e76a6005 ("drm/amdgpu: return tcc_disabled_mask to userspace") Signed-off-by: Yogesh Mohan Marimuthu Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 497b5090f2857ef8ad9a162aa31ada0de5814663) commit 6293f2e1439fb440be1b606e647ce88e65562a38 Author: Yuling Li Date: Tue Sep 1 15:37:18 2026 +0800 drm/amd/display: Fix cursor disable with horizontally split planes [WHY] resource_can_pipe_disable_cursor() disables the hardware cursor on a pipe when a higher layer fully covers that pipe's recout, to avoid double-cursor and scaling artifacts. When merging pipe-split halves of the same overlay layer, the inner loop walks every pipe above the current one and looks for siblings sharing test_pipe's layer_index. Because test_pipe itself satisfies that condition, it can be treated as its own split partner. That incorrectly doubles r2.width and makes the covering check succeed even when the overlay does not fully contain the underlying pipe. On horizontally split or multi-quadrant layouts this causes the cursor to disappear over overlay regions while input/coordinate mapping remains correct. [HOW] Skip test_pipe when searching for a pipe-split sibling on the same layer, so only the other half of the split plane is merged into r2. Signed-off-by: Yuling Li Reviewed-by: Leo Li Signed-off-by: Alex Deucher (cherry picked from commit 85ccd2c39cca9351d4db393e24acea8bf943d350) commit 8b4a4193f3c0b532054990783f40930083c37618 Author: Sunil Khatri Date: Tue Sep 1 16:30:35 2026 +0530 drm/amdgpu/userq: dont overwrite the error of subsequent map call If a queue fails to map that we need to return the error code back to the caller and not overwrite with a success specifically. Accumulate the failure and return that. Signed-off-by: Sunil Khatri Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 42a0197d10039e9518c0324c43331eb22b44d5f8) commit a26301203a196a991527f7b1ab884d4dd0e7c95e Author: Kanala Ramalingeswara Reddy Date: Mon Aug 31 19:59:11 2026 +0530 drm/amdgpu: Skip accessing psp rum time db for APUs Psp runtime DB is for dGPUs only. Signed-off-by: Kanala Ramalingeswara Reddy Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit dce8195027f146467c9378efb2bb1b0859cb735e) Cc: stable@vger.kernel.org commit 49a74a2388528c1a2e96f01114c4513e635605fe Author: Sunil Khatri Date: Mon Aug 31 20:18:31 2026 +0530 drm/amdgpu: update the fw version for gfx12 userqueues Update to the latest stable fw versions where userqueues is working as it is expected with major fixes. Signed-off-by: Sunil Khatri Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 69fa36e3ac92f2544ee7a1b719ec212b8247a2da) Cc: stable@vger.kernel.org commit c748dd03df33360549ad60cdccee13570e9c0f90 Author: Sunil Khatri Date: Mon Aug 31 20:17:17 2026 +0530 drm/amdgpu: update the fw version for gfx11 userqueues Update to the latest stable fw versions where userqueues is working as it is expected with major fixes. Signed-off-by: Sunil Khatri Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit d50201b891604ab97f305d4a20d888ba93305b48) Cc: stable@vger.kernel.org commit 3b5c4f4a479d0e58a7500cbd2b09d62f719f48b8 Author: Sunil Khatri Date: Mon Aug 31 21:01:39 2026 +0530 drm/amdgpu: fix byte/dword unit mismatch in coredump IB dump In amdgpu_devcoredump_print_ibs(), the NO_CPU_ACCESS VRAM path passed cursor.start/4 and cursor.size/4 to amdgpu_device_mm_access(), but that function's pos/size parameters are byte offsets/lengths (confirmed by amdgpu_ttm_vram_mm_access() and leading to wrong size calculation. Similarly with that change the off index needs to be calculated based on dword since that is a u32 type. Fixes: 7b15fc2d1f1a ("drm/amdgpu: dump job ibs in the devcoredump") Signed-off-by: Sunil Khatri Reviewed-by: Vitaly Prosyak Acked-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 1bd613b0ed98a23575b18674c94b8b3392614681) Cc: stable@vger.kernel.org commit 012a026bae0212952b423a842b7e2c0bf21f8e7a Author: Mario Limonciello Date: Mon Aug 31 08:00:51 2026 -0500 drm/amdkfd: fix scope of mqd_mgr dereference in pqm_debugfs_mqds Reading /sys/kernel/debug/kfd/mqds while a process holds an active KFD queue triggers a NULL pointer dereference because the for loop that calls mqd_mgr->debugfs_show_mqd() is incorrectly placed outside the if (pqn->q) block that initializes mqd_mgr. The queue list can contain entries where pqn->q is NULL (kernel queues where only pqn->kq is valid). In the original code: if (pqn->q) { ... mqd_mgr = q->device->dqm->mqd_mgrs[mqd_type]; size = mqd_mgr->mqd_stride(...); } for (xcc = 0; xcc < num_xccs; xcc++) { // WRONG: outside if block mqd = q->mqd + size * xcc; r = mqd_mgr->debugfs_show_mqd(m, mqd); } When iterating over a queue node where pqn->q is NULL: 1. The if (pqn->q) block is skipped 2. mqd_mgr remains uninitialized (NULL from declaration) 3. The for loop executes anyway 4. mqd_mgr->debugfs_show_mqd(m, mqd) dereferences NULL The crash manifests as: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode RIP: 0010:0x0 Call Trace: pqm_debugfs_mqds+0x10c/0x1d0 [amdgpu] kfd_debugfs_mqds_by_process+0x9b/0x110 [amdgpu] seq_read_iter+0x132/0x4b0 ... Fix by moving the for loop inside the if (pqn->q) block, so mqd_mgr and related variables are only used when properly initialized. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5689 Reviewed-by: Alex Deucher Link: https://patch.msgid.link/20260831130051.2031435-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 8bfe29d5c798940f797aa24135d2734c3ffce9de) Cc: stable@vger.kernel.org commit f63de9054da858d57054474c32464106f8375e0d Author: Hari Mishal Date: Sat Aug 22 16:57:51 2026 +0200 drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. Fixes: 8e5cfe547bf3 ("drm/amd/display: upstream link_dp_dpia_bw.c") Reviewed-by: Alex Hung Assisted-by: gkh_clanker_t1000 Signed-off-by: Hari Mishal Signed-off-by: Alex Deucher (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3) Cc: stable@vger.kernel.org commit 4278d65a41a2f6530437738f158f69e379bddb1c Author: Melissa Wen Date: Thu Aug 20 11:26:37 2026 +0200 drm/amd/display: use halving distribution for all encode-to-linear curves In encode-to-linear conversions, LUT entries should be uniformly distributed across the input range: non-linear encodings are already approximately perceptually uniform, so every input code carries the same weight. A fixed count per region does the opposite, concentrating entries on the darker values and leaving few for the bright end, whereas halving distribution spaces all 256 entries uniformly. This holds for any encoded input, so remove the PQ/sRGB condition from commit "drm/amd/display: use halving distribution for PQ/sRGB linearizing LUT" and apply halving to all encode-to-linear operations (pre-defined TF or user LUTs). It fixes the following IGT kms_colorop subtests: - plane-XR30-XR30-srgb_inv_eotf_lut-srgb_eotf_lut - plane-XR30-XR30-gamma_2_2-gamma_2_2_inv-gamma_2_2 Fixes: a71d2b051f33 ("drm/amd/display: use halving distribution for PQ/sRGB linearizing LUT") Reviewed-by: Alex Hung Reviewed-by: Harry Wentland Signed-off-by: Melissa Wen Signed-off-by: Alex Deucher (cherry picked from commit 6df7c9c307e72e7f13829e94edc89134f0764775) commit 5a67d2e055897a36acb4e48082986fb4a4eebdd3 Author: Roman Li Date: Fri Aug 21 12:19:10 2026 -0400 drm/amd/display: Fix backlight control for luminance-capable OLED [WHY] For some eDP panels VESA aux backlight control is necessary, otherwise they stay black. [HOW] When AUX backlight control is used, select BACKLIGHT_CONTROL_VESA_AUX for panels that advertise panel_luminance_control. Reviewed-by: Hansen Dsouza Signed-off-by: Roman Li Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 42f698bd061d76d5f4c84a195e465cfbeec775e4) commit 93a77d353cb26772ae2fba50ae7321ae996b7f00 Author: Austin Zheng Date: Wed Aug 19 09:33:57 2026 -0400 drm/amd/display: Remove const Qualifier From Non-Pointer Fields [WHY/HOW] Integer values for dml2_core_calcs_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport_params should not have the const qualifier. This prevents using different values of the inputs when the function is called again. Reviewed-by: Dillon Varone Signed-off-by: Austin Zheng Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 342280aae4f33816e8d07c15cb538a3b375a7f8f) Cc: stable@vger.kernel.org commit 9ce3169430f1db035d491481086e2fae2552569c Author: Roman Li Date: Fri Aug 14 18:03:17 2026 -0400 drm/amd/display: Set gpuvm min page size to 4K on dcn35/36 [WHY] Splash screen corruption on some 8K monitors. [HOW] Set GPUVM min page size to 4K for DCN35/36 to use the correct DML2 calculations, avoiding the corruption path observed during splash. Fixes: 115009d11ccf ("drm/amd/display: Add DCN35 DML2 support") Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Alex Hung Signed-off-by: Roman Li Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 2cbfb03dead5088a7bdfe2ce392a5caa3d1b3719) Cc: stable@vger.kernel.org commit ef0e9d12727d0fec762eea5053ff02ba555b8895 Author: Ivan Lipski Date: Wed Aug 12 23:15:18 2026 -0400 drm/amd/display: Fix DCN5/6 DML2 compilation warnings [WHY] A kernel compilation warning was reported caused by upstream of DCN5/6. [HOW] Using plain integer as NULL pointer. Assign NULL to the VActiveLatencyHidingMargin/VActiveLatencyHidingUs pointer members in dml2_core_dcn5_funcs_mode_programming.c, and pass NULL for the pointer arguments to calculate_first_second_splitting() in dml2_pmo_dcn6_stage_optimizers.c. Fixes: 7f7d7ea1fa51 ("drm/amd/display: Add new sources for DCN6") Reviewed-by: Dillon Varone Signed-off-by: Ivan Lipski Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit d96880560e9f35ba7f8de1b3f90032c8c3eaea88) commit 90ce19bd11b2864e26e4b43e7acbffabf037b69b Author: Sunil Khatri Date: Thu Aug 27 21:00:22 2026 +0530 drm/amdgpu: fix Idle BOs list in VM debugfs status info amdgpu_debugfs_vm_bo_status_info() prints the "Idle BOs" section by iterating lists->needs_update, the same list already printed just above under "Moved BOs". struct amdgpu_vm_bo_status has a dedicated idle list, populated whenever a BO's state machine settles, but it was never read here, so genuinely idle BOs never show up in the debugfs output and the "Idle BOs" section duplicates "Moved BOs" instead. Iterate lists->idle for the "Idle BOs" section. Fixes: 4cdbba5a16aa ("drm/amdgpu: restructure VM state machine v4") Signed-off-by: Sunil Khatri Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 451bfc778a8c364841837def00ba15936f72762b) Cc: stable@vger.kernel.org commit d6e16df7df4d2c39e2b04b355d0434fb90e2d62c Author: Sunil Khatri Date: Thu Aug 27 20:33:35 2026 +0530 drm/amdgpu: use AMDGPU_GPU_PAGE_SHIFT instead of PAGE_SHIFT For different address types the variable PAGE_SHIFT might not work well and it's better to use the GPU specific one Signed-off-by: Sunil Khatri Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 3494b77d10375e0f9ab784e9b20763339844b55b) Cc: stable@vger.kernel.org commit b428f83c7c2542837c15231c519583cc26b60156 Author: Amber Lin Date: Thu Aug 27 15:02:53 2026 -0400 drm/amdgpu: Update queue reset support version Update queue reset required MES version for MES 12.1 to 0x7b since we change the implementation from detect-and-reset method to per-queue-reset method. Signed-off-by: Amber Lin Reviewed-by: Michael Chen Signed-off-by: Alex Deucher (cherry picked from commit 2160a5cbf0b7917adce4b55421306b614b4a2c8f) commit 7346a046c6a9b9f30cb1f7d301449300a9174c71 Author: Alex Deucher Date: Thu Aug 20 09:02:01 2026 -0400 drm/amdgpu/gfx8: only apply compute quantums to KCQs Don't apply to KIQ. Seems to cause problems on KIQ on some ARM platforms. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5658 Fixes: 91cf34bc5a55 ("drm/amdgpu/gfx8: align mqd settings with KFD") Reviewed-by: Jesse Zhang Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 6aae7bab029cdccae9a7157facfe36bfc35fc940) Cc: stable@vger.kernel.org commit bd1f08246b8a2564d8ac61df715b6bcd5f994729 Author: Mario Limonciello Date: Wed Aug 26 13:51:02 2026 -0500 drm/amdgpu: restrict BAR0 fallback read to SR-IOV VFs only The BAR0 fallback read path was introduced as a workaround for SR-IOV VFs where the VRAM aperture is not available during early init. Restrict this workaround to only SR-IOV VFs where it's needed. Reported-by: gloveless@jqluv.com Fixes: cba4928cdffa ("drm/amdgpu: reduce early full GPU access during SR-IOV init") Acked-by: Alex Deucher Link: https://patch.msgid.link/20260826185102.2269511-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit d8a0affd207c813bd063fa2c27786f449eaf92b8) commit 94e25cb6ab7f4f025bcdcd8ea79fda30f12843a4 Author: Priya Hosur Date: Thu Aug 27 15:02:46 2026 +0530 drm/amdkfd: Add TLB flush after MES queue eviction/suspension MES (Micro Engine Scheduler) does not perform heavy-weight TLB invalidation after unmapping queues, unlike HWS which does this automatically. This causes a race condition where in-flight DMA descriptors can access memory that has been unmapped, leading to page faults and GPU queue hangs during SVM page migration. The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU compute queue hangs with packets submitted but never consumed. Add kfd_flush_tlb() calls after MES queue removal in two locations: - evict_process_queues_cpsch(): after all queues removed during eviction - suspend_queues(): after debug/criu queue suspension (with mem_fence barrier) This ensures all in-flight memory accesses from unmapped queues are flushed before memory is freed or migrated. Signed-off-by: Priya Hosur Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77) Cc: stable@vger.kernel.org commit 6a7a45b1d94799a5eb8e6d26e65cf31a3fcda9e5 Author: Chris Mason Date: Thu Aug 27 12:29:16 2026 -0700 MAINTAINERS: update Chris Mason's email address David Sterba has been doing the Btrfs maintainership work for years, and my email update to mason@kernel.org seems like a good time to make the MAINTAINERS file a little more accurate. Link: https://lore.kernel.org/all/20260827193032.786461-1-clm@meta.com/ Signed-off-by: Chris Mason Signed-off-by: David Sterba commit 0c1032c8c3e9dc8b9a9fa5f6ef23966e236466ed Author: Qu Wenruo Date: Tue Aug 11 15:31:49 2026 +0930 btrfs: tests: do not touch page cache if root/inode allocation failed Inside test_find_delalloc() of extent-io-tests.c, if we fail to allocate a dummy root or the test inode, we go to out label to clean up. But at that stage, @inode is still NULL and we will call process_page_range() to access the page cache of the inode, this will cause NULL pointer dereference. This is a very minor bug, as it only affects selftests which are not compiled in by default for most distros, and very hard to trigger. Fix it by adding a new out_root_info label to handle root and inode allocation failure. This is a pre-existing bug reported by Sashiko while reviewing another patch. Link: https://sashiko.dev/#/patchset/cover.1786095309.git.wqu%40suse.com Reviewed-by: Boris Burkov Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba commit 2acb9f3d1cc8f65dc81ed55e238cbf8e5b60bff7 Author: FAN YE Date: Fri Aug 21 17:50:09 2026 +0000 btrfs: zstd: fix lost wakeup when waiting for a workspace A writer can sleep forever in zstd_get_workspace() even though a workspace is free. When zstd_alloc_workspace() fails, the task is queued on zwsm->wait and schedules unconditionally, never re-testing the pool. zstd_put_workspace() publishes the workspace and then calls cond_wake_up(), which only wakes when a sleeper is already visible, so a workspace returned between the failed allocation and prepare_to_wait() wakes nobody. The window is wide: zstd_alloc_workspace() goes through kvmalloc() and may enter reclaim. Only a max level workspace triggers the wakeup and one is deliberately kept allocated as the fallback every waiter waits for, so once its wakeup is lost the writer stays in TASK_UNINTERRUPTIBLE until some other task happens to return one. Re-check the pool after prepare_to_wait() has published the waiter, and use the workspace if one turned up. Fixes: 3f93aef535c8 ("btrfs: add zstd compression level support") Assisted-by: Claude:claude-opus-5 Reviewed-by: Qu Wenruo Signed-off-by: FAN YE Signed-off-by: David Sterba commit cacf35832292997018837e484283f95a9301ebf5 Author: Qu Wenruo Date: Thu Aug 20 18:28:48 2026 +0930 btrfs: do not force reloc root creation during qgroup_account_snapshot() [BUG] When running btrfs/252 with quota enabled through MKFS_OPTIONS="-O quota", it has a high chance to trigger the following kernel warning and flips the fs RO: BTRFS info (device dm-2): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: fs/btrfs/extent-tree.c:879 at lookup_inline_extent_backref+0x74b/0x960 [btrfs], CPU#4: btrfs/2173 CPU: 4 UID: 0 PID: 2173 Comm: btrfs Not tainted 7.2.0-rc6-custom+ #457 PREEMPT(full) 3adc6528fb66f7a55fe1095385818e742f200aab Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:lookup_inline_extent_backref+0x74b/0x960 [btrfs] Call Trace: insert_inline_extent_backref+0x7c/0x160 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_inc_extent_ref+0xa9/0x270 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_run_delayed_refs+0x4af/0x11c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_run_delayed_refs+0x9d/0xf0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshot+0x39d/0xf00 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshots+0x9b/0xc0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_commit_transaction+0x280/0xeb0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] prepare_to_relocate+0x147/0x200 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] relocate_block_group+0x6b/0x5e0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_block_group+0x92c/0x2380 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_balance+0xa2c/0x19c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_ioctl+0x2839/0x2d30 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS info (device dm-2): leaf 4593991680 gen 233 total ptrs 175 free space 5953 owner 2 BTRFS info (device dm-2): refs 3 lock_owner 2173 current 2173 item 0 key (166772736 METADATA_ITEM 1) itemoff 16250 itemsize 33 extent refs 1 gen 222 flags 2 ref#0: tree block backref root 266 [ Skip the tree dump ] item 174 key (263225344 METADATA_ITEM 0) itemoff 10328 itemsize 33 extent refs 1 gen 162 flags 258 ref#0: tree block backref root 267 BTRFS error (device dm-2): extent item not found for insert, bytenr 179847168 num_bytes 16384 parent 4594335744 root_objectid 273 owner 0 offset 0 BTRFS error (device dm-2): failed to run delayed ref for logical 179847168 num_bytes 16384 type 182 action 1 ref_mod 1: -117 [CAUSE] The above error is showing that there is a tree reference to a metadata extent that is no longer there. With "ref_verify" mount option (requires CONFIG_BTRFS_DEBUG), there is some extra debug output: BTRFS error (device dm-2): dumping block entry [180961280 16384], num_refs 0, metadata 1, from disk 0 BTRFS error (device dm-2): root entry 256, num_refs 18446744073709551615 BTRFS error (device dm-2): root entry 273, num_refs 18446744073709551615 BTRFS error (device dm-2): Ref action 3, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 1 btrfs_force_cow_block+0x129/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_insert_empty_items+0x3a/0x70 [btrfs] insert_with_overflow+0x53/0x130 [btrfs] btrfs_insert_dir_item+0x125/0x290 [btrfs] btrfs_add_link+0xaa/0x410 [btrfs] btrfs_rename+0x5ea/0xcd0 [btrfs] btrfs_rename2+0x28/0x60 [btrfs] vfs_rename+0x5b2/0xe10 filename_renameat2+0x244/0x430 __x64_sys_rename+0x48/0x70 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 BTRFS error (device dm-2): Ref action 2, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 18446744073709551615 btrfs_force_cow_block+0x327/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_lookup_file_extent+0x4d/0x70 [btrfs] btrfs_drop_extents+0x151/0xf00 [btrfs] insert_reserved_file_extent+0xfe/0x3e0 [btrfs] btrfs_finish_one_ordered+0x549/0xc40 [btrfs] btrfs_work_helper+0xde/0x350 [btrfs] process_one_work+0x198/0x380 worker_thread+0x1c8/0x330 kthread+0xee/0x120 ret_from_fork+0x28f/0x310 ret_from_fork_asm+0x11/0x20 BTRFS error (device dm-2): Ref action 1, root 273, ref_root 0, parent 4594335744, owner 0, offset 0, num_refs 1 __btrfs_mod_ref+0x1c5/0x2d0 [btrfs] btrfs_copy_root+0x262/0x390 [btrfs] create_reloc_root+0xb9/0x370 [btrfs] btrfs_init_reloc_root+0xb0/0x1b0 [btrfs] record_root_in_trans+0xa6/0xd0 [btrfs] create_pending_snapshot+0x383/0xf00 [btrfs] create_pending_snapshots+0x9b/0xc0 [btrfs] btrfs_commit_transaction+0x280/0xeb0 [btrfs] prepare_to_relocate+0x147/0x200 [btrfs] relocate_block_group+0x6b/0x5e0 [btrfs] btrfs_relocate_block_group+0x92c/0x2380 [btrfs] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs] btrfs_balance+0xa2c/0x19c0 [btrfs] btrfs_ioctl+0x2839/0x2d30 [btrfs] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 The above shows the direct cause, Ref action 3 is the oldest operation, which shows the tree block is created by COW. Then ref action 2 shows it's COWed away, by a metadata update, meaning the tree block is already released, should not be referred any more. Then the final one, is trying to create a reloc tree for subvolume 273, and that reloc root creation is referring to the already dropped tree block. The root cause is that, during qgroup_account_snapshot(), we are calling record_root_in_trans() with "force = true". So if the root has no reloc root, we will create one, but at that timing it's already too late. Normally reloc root should be created before the commit and current roots diverge, to avoid the same problem we are hitting. But during relocation initialization, we are committing the current running transaction, with a new reloc_control attached halfway. And if qgroup is enabled, the record_root_in_trans() with "force = true" calls will force reloc root creation even if we do not and should not create reloc root at that timing. [FIX] Do not force reloc root creation during record_root_in_trans() with "force = true" cases, which is only called by qgroup_account_snapshot(). If we're really under relocation, the reloc root should be created way early, before the commit and current root diverge. If the root has no reloc tree yet, it means we're still initializing the reloc, and do not need a reloc root. So skipping the reloc tree creation in qgroup_account_snapshot() should be safe. Link: https://bugzilla.suse.com/show_bug.cgi?id=1275740 Fixes: 4d31778aa2fa ("btrfs: qgroup: Fix root item corruption when multiple same source snapshots are created with quota enabled") Assisted-by: LLM (initial analysis, but incorrect conclusion with too many burnt tokens) Tested-by: Disha Goel Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba commit d0285dfbc3b46f41395b26ee2f4a16d99fb3e736 Author: Avi Weiss Date: Mon Aug 10 12:47:01 2026 +0300 btrfs: send: fix lost error return value in will_overwrite_ref() The direct-return refactoring in commit b3047a42f55d ("btrfs: send: directly return from will_overwrite_ref() and simplify it") changed will_overwrite_ref() to return directly instead of going through the common out label. That resulted in a negative return value from is_inode_existent() to start being converted to 0, making lookup errors unable to be distinguished from the inode not existing. process_recorded_refs() expects negative errors from will_overwrite_ref() and aborts processing when it receives one. Return the value from is_inode_existent() to restore the previous error propagation behavior as it was before the refactor. Fixes: b3047a42f55d ("btrfs: send: directly return from will_overwrite_ref() and simplify it") Signed-off-by: Avi Weiss Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba commit 529c01c3dc0d322c103611c35b01d71ea04562b2 Author: Leo Martins Date: Tue Aug 18 17:40:10 2026 -0700 btrfs: abort transaction before releasing tree_log_mutex on commit failure When transaction metadata writeout fails in btrfs_commit_transaction(), the current code only logs the error, drops tree_log_mutex and then goes through cleanup_transaction(), which aborts the transaction and records the fs error. That is too late for the tree log side. A log sync can already be waiting on tree_log_mutex, because the committing transaction is moved to TRANS_STATE_UNBLOCKED while that mutex is held, which lets fsyncs join the next transaction and queue up in btrfs_sync_log(). Once the failed commit drops tree_log_mutex, such a log sync acquires it, sees BTRFS_FS_ERROR() still clear, and writes super_for_commit. That superblock holds the roots prepared for the transaction that has just failed to write out its metadata, so it can point at tree blocks that never reached the disk, and the next mount fails with a parent transid mismatch. Commit 165ea85f1483 ("btrfs: do not write supers if we have an fs error") fixed this class of problem by making btrfs_sync_log() check for an fs error right after taking tree_log_mutex. That check only works if the commit path publishes the fs error before it releases the same mutex, and commit 68d4ece9c30e ("btrfs: don't call btrfs_handle_fs_error() in btrfs_commit_transaction()") removed the only thing that did so. Restore the ordering by aborting the transaction while tree_log_mutex is still held. We have a transaction handle here, so this does not need to bring back the btrfs_handle_fs_error() call: __btrfs_abort_transaction() records the fs error itself, which is all btrfs_sync_log() looks at, and the error message put in its place is kept. This is what commit 3810ab40afa5 ("btrfs: abort transaction on error in write_all_supers()") already does for the next call in this function. This is reproducible on an unmodified kernel by failing the first couple of bios of a transaction commit with fail_make_request while a concurrent fsync workload keeps log syncs queued on tree_log_mutex. Fixes: 68d4ece9c30e ("btrfs: don't call btrfs_handle_fs_error() in btrfs_commit_transaction()") CC: stable@vger.kernel.org # 7.0+ Reviewed-by: Boris Burkov Reviewed-by: jlayton@meta.com Signed-off-by: Leo Martins Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Signed-off-by: David Sterba commit c428b763f29bf2d7c67b69e5be964c7fb4eee282 Author: Johannes Thumshirn Date: Tue Aug 18 12:00:37 2026 +0200 btrfs: zoned: propagate do_zone_finish() error in btrfs_zone_finish_endio() btrfs_zone_finish_endio() ignored the return value of do_zone_finish() and always returned 0, silently dropping a failed zone finish. Instead propagate any error from do_zone_finish() as the caller btrfs_finish_ordered_io() already handles it. Reviewed-by: Qu Wenruo Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba commit a18a6b93a2843b9d103d3456bbd4b3f90282a379 Author: Johannes Thumshirn Date: Wed Aug 19 12:26:36 2026 +0200 btrfs: zoned: finish active block group cleanup if call_zone_finish() fails do_zone_finish() clears BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE before finishing the zones. If call_zone_finish() then fails it returned early, leaving the now inactive block group on fs_info->zone_active_bgs, leaking its reference, the BTRFS_FS_NEED_ZONE_FINISH waiters are never woken, and as its alloc_offset equals the zone capacity btrfs_zone_finish_one_bg() keeps selecting it, spinning btrfs_zoned_activate_one_bg(). Fall through to the cleanup on failure too and return the error, but keep the block group read-only as its zones are left inconsistent. Fixes: d70cbdda75da ("btrfs: zoned: consolidate zone finish functions") Link: https://sashiko.dev/#/patchset/20260818100037.1366563-1-johannes.thumshirn%40wdc.com Reviewed-by: Qu Wenruo Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba commit 0853dc4f2678bbb21ff3d7572b0e9b812985bd65 Author: ZhengYuan Huang Date: Mon Aug 17 21:20:51 2026 +0800 btrfs: send: reject extents for non-regular inodes [BUG] A corrupted subvolume tree can leave an EXTENT_DATA item attached to an inode whose mode is not S_IFREG or S_IFLNK. During send, such an item can be treated as file data and crash through a NULL address_space operation: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page Call Trace: read_pages+0x80b/0xb30 mm/readahead.c:173 page_cache_ra_unbounded+0x40d/0x890 mm/readahead.c:302 do_page_cache_ra mm/readahead.c:332 [inline] page_cache_ra_order+0xa16/0xcd0 mm/readahead.c:535 page_cache_sync_ra+0x5ce/0x9d0 mm/readahead.c:626 page_cache_sync_readahead include/linux/pagemap.h:1379 [inline] put_file_data fs/btrfs/send.c:5224 [inline] send_write fs/btrfs/send.c:5291 [inline] send_extent_data+0x16b2/0x29b0 fs/btrfs/send.c:5715 send_write_or_clone fs/btrfs/send.c:6135 [inline] process_extent+0x5d4/0x17b0 fs/btrfs/send.c:6504 changed_extent fs/btrfs/send.c:7079 [inline] changed_cb+0x22f9/0x3cd0 fs/btrfs/send.c:7245 full_send_tree fs/btrfs/send.c:7318 [inline] send_subvol fs/btrfs/send.c:7910 [inline] btrfs_ioctl_send+0x46a9/0x57f0 fs/btrfs/send.c:8248 ... [CAUSE] process_extent() skips extent items for symlinks but assumes every other inode with an extent item is a regular file. For a corrupted non-regular inode, btrfs_iget() does not install the regular file address_space operations. The readahead fallback can then call a NULL read_folio callback before the existing validation in btrfs_get_extent() can run. [FIX] Reject extent items for inode types other than regular files and symlinks at the common send extent-processing boundary. Symlink handling is left unchanged because send emits symlink data from read_symlink(). This covers full, incremental and new-generation sends without adding a check to the regular I/O path. Reviewed-by: Qu Wenruo Signed-off-by: ZhengYuan Huang Reviewed-by: David Sterba Signed-off-by: David Sterba commit a03fa65184545837d6461413275da71f30527385 Author: Qu Wenruo Date: Mon Aug 17 14:43:54 2026 +0930 btrfs: return proper negative error code for update_raid_extent_item() The function btrfs_abort_transaction() only accepts negative error code, and have the macro VERIFY_NEGATIVE_ERROR() to verify that error code. But inside update_raid_extent_item(), if there is such key found, we return 1, breaking the negative error code scheme. Furthermore if we hit some real error during the tree search, e.g. -EIO, then the error code is always over-written to -EINVAL. Fix both problems by following other call sites by overwriting @ret to -ENOENT if the btrfs_search_slot() failed to locate the key. This is very unlikely to hit, as we only enter update_raid_extent_item() if there is a conflicting key already in the raid stripe tree. This was reported by Sashiko when reviewing another patch. Link: https://sashiko.dev/#/patchset/20260817021512.3010812-1-shuangpeng.kernel%40gmail.com Fixes: 8c4cba2adbb0 ("btrfs: update stripe extents for existing logical addresses") Reviewed-by: Johannes Thumshirn Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba commit afbe73778338e6d1ac8c4486fbdf33f0cc1f2624 Author: Qu Wenruo Date: Mon Aug 17 14:43:53 2026 +0930 btrfs: fix the possible bioc_list memory leak during error There are two possible ways to leak bioc memory on btrfs_ordered_extent::bioc_list: - An error occurred for btrfs_insert_one_raid_extent() Then the function btrfs_insert_raid_extent() immediately return without freeing any bioc in the bioc_list. - An ordered extent hit an IO error In that case the ordered extent will have BTRFS_ORDERED_IOERR set, and skip the call on btrfs_insert_raid_extent() completely. Fix the problem by: - Introduce a new helper, btrfs_cleanup_ordered_bioc_list() Which will remove all bioc from the bioc_list, and release the bioc. - Call the above helper for btrfs_insert_raid_extent() So that the cleanup helper is always called no matter what. - Call the above helper for btrfs_finish_one_ordered() This is called just before the final release on the ordered extent. This was reported by Sashiko when reviewing another patch. Link: https://sashiko.dev/#/patchset/20260817021512.3010812-1-shuangpeng.kernel%40gmail.com Fixes: 02c372e1f016 ("btrfs: add support for inserting raid stripe extents") Reviewed-by: Johannes Thumshirn Signed-off-by: Qu Wenruo Signed-off-by: David Sterba commit a8813a923f9e43f788b357fb55c35f7f6ed6f98c Author: Shuangpeng Bai Date: Sun Aug 16 22:15:12 2026 -0400 btrfs: fix transaction use-after-free in raid stripe insertion If allocation of a RAID stripe extent fails, btrfs_insert_one_raid_extent() aborts and ends the transaction before returning -ENOMEM. btrfs_finish_one_ordered(), the production caller through btrfs_insert_raid_extent(), still owns the transaction handle. It handles the error by aborting the transaction and then reaches the common exit path, which ends the transaction again. The premature end can free the handle and drop its transaction reference. Transaction cleanup can then free the transaction before the caller's second abort accesses the handle and transaction, resulting in use-after-free. Keep the abort at the failure site, but let the caller's common exit path end the transaction once, after it has finished using both objects. Fixes: 02c372e1f016 ("btrfs: add support for inserting raid stripe extents") Assisted-by: Codex:GPT-5 Reviewed-by: Qu Wenruo Signed-off-by: Shuangpeng Bai Signed-off-by: David Sterba commit 33ce0aa4c57611c3a3485ec7c01ad67b3751447d Author: James C. Owens Date: Fri Aug 14 12:24:05 2026 -0400 btrfs: scrub: report the failing sector's address, not the stripe base scrub_stripe_report_errors() iterates over the sectors of a stripe, but every message it emits passes stripe->logical, the address of the first sector of the 64KiB stripe, rather than the address of the sector being reported. The physical address is likewise computed once, before the loop, from stripe->logical. This matters because scrub_print_common_warning() uses that logical address for the backref walk which produces the "root %llu inode %llu offset %llu ... (path: ...)" part of the message. As the address is always the stripe base, the reported root/inode/offset/path can identify a different file from the one whose sector actually failed. A 64KiB stripe routinely spans several extents belonging to unrelated files. On the machine where this was found, the stripe at logical 0x17D9380000 holds four sectors of /usr/share/plasma/emoji/bg.dict, then a file inside a docker volume, then sectors referenced only by snapshots. Every error anywhere in that stripe is attributed to bg.dict. The effect is visible statistically: across ten months and four kernel series that machine logged 81 distinct flagged logical addresses, and every one of them is exactly 64KiB aligned. Since BTRFS_STRIPE_LEN is 64KiB and stripe->logical is stripe aligned by construction, real failures distributed across sectors could not produce that. Report the address of the sector actually being examined. Adding the sector offset to the physical address is valid because BTRFS_STRIPE_LEN is the unit contiguous on a single device for every profile, so a stripe never crosses a device boundary. Fixes: 0096580713ff ("btrfs: scrub: introduce error reporting functionality for scrub_stripe") Reviewed-by: Qu Wenruo Signed-off-by: James C. Owens Reviewed-by: David Sterba Signed-off-by: David Sterba commit df72e55e754c8d449321ddddad19a8bd3cb8d032 Author: Matthew Brost Date: Tue Sep 1 23:35:04 2026 -0700 drm/pagemap: Fix folio allocation fallback and use-after-put drm_pagemap_migrate_populate_ram_pfn() had two issues when populating RAM PFNs with higher-order folios: 1. The higher-order vma_alloc_folio()/folio_alloc() calls did not pass __GFP_NOWARN, so a THP allocation failure under memory pressure would spam the kernel log, and there was no fallback path despite a TODO comment stating one was needed. Add __GFP_NOWARN to the higher-order allocation and, on failure, fall back to order-0 allocations for the entire range originally covered by the failed higher-order allocation, leaving MIGRATE_PFN_COMPOUND unset for those PFNs. 2. In the free_pages error path, order was computed via folio_order(page_folio(page)) *after* put_page(page) had already dropped the reference, resulting in a use-after-free/put when that was the last reference on the page. Compute order before releasing the page. Introducing the fallback in 1. also requires the source page array handed to ->copy_to_ram() to be built differently. Both callers only populated the entry at the head of each source folio, relying on the copy callback to derive the rest of the folio from the order recorded in the matching drm_pagemap_addr. Once the destination has been demoted to order-0 folios the drm_pagemap_addr entries are per-page, so a source page is needed for every one of them; leaving them NULL makes the copy callback stop after the first page and the remainder of the range is never copied. The source folio is only split later, by migrate_vma_pages() / migrate_device_pages(), so its order cannot be used to detect the demotion - test the destination for MIGRATE_PFN_COMPOUND instead. Factor the array population out into drm_pagemap_migrate_populate_src_pages() and use it from both drm_pagemap_evict_to_ram() and __drm_pagemap_migrate_to_ram(). Fixes: ddeda6136038 ("drm/pagemap: Allocate folios when possible") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-5 Signed-off-by: Matthew Brost Reviewed-by: Himal Prasad Ghimiray Link: https://patch.msgid.link/20260902063504.3024362-2-matthew.brost@intel.com commit 9e6372ec2a3990662ae0a67f56ac0aee19848d5b Author: Matthew Brost Date: Tue Sep 1 23:35:03 2026 -0700 drm/pagemap: dma-unmap pages before handling migration errors drm_pagemap_migrate_unmap_pages() relies on the pages array to determine which pages require DMA unmapping. However, drm_pagemap_migration_unlock_put_pages() clears the array as part of its cleanup, leaving drm_pagemap_migrate_unmap_pages() with no valid page information if it is called afterward. Call drm_pagemap_migrate_unmap_pages() before drm_pagemap_migration_unlock_put_pages() so the pages array remains valid during DMA unmapping. Reported-by: Sashiko Fixes: f86ad0ed620c ("drm/gpusvm, drm/pagemap: Move migration functionality to drm_pagemap") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost Reviewed-by: Himal Prasad Ghimiray Link: https://patch.msgid.link/20260902063504.3024362-1-matthew.brost@intel.com commit f14f4dc8ea3810f8ed4f0f3ea13f8bba3e2b0f04 Author: Vincent Jardin Date: Mon Aug 24 23:25:31 2026 +0200 arm64: dts: lx2160a: fix the iic5 spi3 pinmux offset and value 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 commit 6affdda171ca8f2e082e8c4fba56233a2f8c9910 Author: Vincent Jardin Date: Mon Aug 24 23:25:30 2026 +0200 arm64: dts: lx2160a: fix IIC1 pinmux submask rejected by pinctrl-single 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 commit 8188a59dd6782786556b18f515090b79cb701c45 Author: Vincent Jardin Date: Mon Aug 24 23:25:29 2026 +0200 arm64: dts: lx2160a: fix incorrect pinmux 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 commit f2951ebd15c36a1ea4820a7f0cbb0b5f1c028b73 Author: Steven Rostedt Date: Wed Sep 2 12:19:18 2026 -0400 tracing: Take trace_array reference when opening options file The options files do not take the trace_array reference for the options they represent. This could cause a use-after-free kernel crash if one of these files is opened by one task and another task removes the instance that the option is for. Because it doesn't take a reference upon opening, it will not stop the removal which will free the options descriptor that is being used. As the options are somewhat dynamic in their creation at boot up, each file represents a flag in the trace_array. The trace_array has an array of indexes to represent each of these flags that is stored in the trace_flags_index array. The address of the index array element is used to pass to the inode->i_private pointer. Then that element is read which holds the index (which represents the flag) and then the index is used to calculate the trace_array descriptor from its trace_flags_index array. One issue is that the index element can not be referenced until the trace_array's reference is taken. To handle this, create a new helper function called: trace_array_options_get() that will iterate all the existing trace_arrays in the ftrace_trace_arrays list (under the trace_types_lock), and compare the passed in address of the index element with the entire array of the trace_array's trace_flags_index array. If it matches, then up the corresponding trace_array's reference and return. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260902121918.5a9e9d1b@gandalf.local.home Fixes: 577b785f55168 ("tracing: add tracer dependent options to options directory") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-trace-kernel/20260828135858.2AC501F000E9@smtp.kernel.org/ Signed-off-by: Steven Rostedt commit 332ad707e38fb82dd998b4d0782c15579e5784f1 Author: Melissa Wen Date: Wed Aug 26 12:37:07 2026 +0200 drm/amd/display: advertise PIXEL_NONE and PREMULTI blend mode for DCE DCE can support PREMULTI and COVERAGE blend mode depending on its generation, however current driver implementation either doesn't expose more than primary and cursor plane, or doesn't program registers for any blend mode other than PIXEL_NONE. To fix the missing-blend-mode-prop warning according to current DCE plane caps, create blend mode property with PIXEL_NONE and PREMULTI for primary planes. As long as the background is black and there is no overlay plane, PIXEL_NONE and PREMULTI are equivalent, and PREMULTI has been the mandatory/default mode for years, so keep it to avoid regressions. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Tested-by: Viktor Jägersküpper Tested-by: Dan Wheeler #v3 Reviewed-by: Timur Kristóf Reviewed-by: Alex Hung Reviewed-by: Leandro Ribeiro #v2 Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260826104143.39077-4-mwen@igalia.com commit f0c75da0a6b4084e00cd6faefebcc976ffaccf52 Author: Melissa Wen Date: Wed Aug 26 12:37:06 2026 +0200 drm/amd/display: fix missing blend-mode-prop warning for DCN validate_blend_mode_for_alpha_formats() warns when a plane supports formats with alpha but doesn't expose the blend mode property. Fix this by adding the same overlay plane blend modes to primary plane, since they are all universal planes in DCN-generation. Cursor planes support ARGB8888 format and CURSOR_MODE_COLOR_PRE_MULTIPLIED_ALPHA is set by default (other color formats are not implemented), so only expose support to PREMULTI, which is the default blend mode on DRM. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Tested-by: Mikhail Gavrilov Tested-by: Dan Wheeler Reviewed-by: Timur Kristóf Reviewed-by: Alex Hung Reviewed-by: Leandro Ribeiro Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260826104143.39077-3-mwen@igalia.com commit c3080b58d81d3699cbf4dfd5ba860630fca96f4a Author: Melissa Wen Date: Wed Aug 26 12:37:05 2026 +0200 drm/atomic-state-helper: set pixel_blend_mode to prop default on reset In __drm_atomic_helper_plane_state_init(), pixel_blend_mode is always reset to DRM_MODE_BLEND_PREMULTI. That was consistent while drm_plane_create_blend_mode_property() required PREMULTI in the supported modes, but it now falls back to COVERAGE or PIXEL_NONE when the driver doesn't support PREMULTI. The hardcoded default may therefore not be a blend mode the hardware can do, nor one the property advertises. Initialize pixel_blend_mode from the blend mode property default instead, keeping DRM_MODE_BLEND_PREMULTI for planes without the property. Fixes: 9813e158d13d ("drm/drm_blend: allow blend mode property without PREMULTI") Tested-by: Mikhail Gavrilov Tested-by: Dan Wheeler Reviewed-by: Timur Kristóf Reviewed-by: Alex Hung Reviewed-by: Leandro Ribeiro Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260826104143.39077-2-mwen@igalia.com commit e6142a8bfc230c7263eb8b0475249c958ce49367 Author: Diego Oliva Date: Wed Sep 2 11:42:06 2026 +0100 smb: client: reject short READ responses in CIFSSMBRead() CIFSSMBRead() reads DataLengthHigh, DataLength and DataOffset out of the READ_RSP returned by the server without first checking that a whole READ_RSP was actually received. The length of the response is recorded in rsp_iov.iov_len, but nothing constrains it to be at least read_rsp_size before those fields are dereferenced. A malicious or compromised SMB1 server can return a response shorter than the READ_RSP header, so that parsing the header itself reads past the end of the receive buffer. SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount. Reject the response unless it is at least read_rsp_size bytes long. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Paulo Alcantara Cc: stable@vger.kernel.org # 6.19.x Assisted-by: Bynario AI Signed-off-by: Diego Oliva Reviewed-by: David Howells Signed-off-by: Paulo Alcantara commit 7ac9662189069914a088ec61ad85dc46b5cb1563 Author: Eduard Zingerman Date: Mon Aug 31 18:36:10 2026 -0700 selftests/bpf: test case for unsafe pruning of bpf_loop checkpoints The following BPF program was erroneously accepted by the verifier: static int cb(int i, __u64 *ctx) { /* unsafe on a second iteration */ small_arr[*ctx] = i; *ctx = 100500; return 0; } int main(void *ctx) { int nr_loops = 1; u64 ctx = 0; if (unlikely(bpf_get_prandom_u32() == 42)) nr_loops = 2; bpf_loop(nr_loops, cb, &ctx, 0); return 0; } The branch with nr_loops == 1 was explored first and injected a checkpoint at the entry to 'cb', such that nr_loops in the main's frame was not marked as precise. This checkpoint pruned the state with nr_loops == 2 and the program was accepted. This test case corresponds to the program above. Entry point is written in assembly to ensure branch processing order. Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260831-bug-015-backtrack-cb-args-precise-v1-2-68a8e2a821e0@gmail.com Signed-off-by: Alexei Starovoitov commit e3e4f66cc4b72333d0886ae2673c360248987889 Author: Eduard Zingerman Date: Mon Aug 31 18:36:09 2026 -0700 bpf: backtracking shouldn't clear outer frame R1-R5 for callbacks 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 commit 8ba27b90095a4c7fcc878dd013969cd6b100cea7 Author: Oleksandr Kovalov Date: Wed Sep 2 20:13:05 2026 +0300 ALSA: hda/realtek: Fix cold-boot headset misdetection on Acer Aspire A515-57G On the Acer Aspire A515-57G (PCI SSID 1025:1616), if headphones are already inserted into the combo jack before the codec powers up (a cold boot with the plug already seated), the impedance-based headset-type sensing races and misclassifies the jack. This drives the wrong output configuration and is audible as missing center-panned content (e.g. vocals) while panned content plays normally. A genuine physical unplug/replug after boot reliably fixes this by forcing a fresh sense transient, which is a strong hint about the underlying cause: the sensing hardware appears to need a settled, freshly-triggered read rather than the one-shot classification done during the normal HDA_FIXUP_ACT_INIT pass. Add a machine-specific fixup that, on cold boot only (not S3/S4 resume, which already gets its own re-check), waits briefly after the normal init-time decision and then forces a fresh headset-mode classification by resetting the cached mode and re-invoking the existing alc_fixup_headset_mode() path -- mirroring what a manual replug already does. The wait+recheck is skipped whenever the first pass already determined nothing is plugged in, to avoid adding boot latency on the common case. Chain into the existing ALC256_FIXUP_ACER_SFG16_MICMUTE_LED fixup so this quirk-table entry keeps providing mic-mute LED support alongside the cold-boot headset fix. Tested on kernel 7.1.9 by building the affected module standalone and confirming cold boot with headphones pre-inserted plays correctly from the very first sample, across multiple boots (including a full restart, and headphones inserted mid-POST rather than before power-on), with no crashes or warnings and no behavioral difference from a real post-replug recovery. Signed-off-by: Oleksandr Kovalov Link: https://patch.msgid.link/20260902171305.3955-1-oleksandr.kovalov.work@gmail.com Signed-off-by: Takashi Iwai commit b94cec5761d22624d109d859467d7d4ce0a1b88b Author: Andy Chiu Date: Tue Sep 1 14:23:32 2026 -0500 riscv: skip software algning code for HAVE_EFFICIENT_UNALIGNED_ACCESS We can jump straight into the copy loop if the kernel is compiled for a hardware that natively supports misaligned access. The user copy bandwidth improvement on K3 and Ascaolon is shown as below: Misaligned user copy, size: 512B (offset: [0:15] except 0, 8) BW Improvement | Write | Read | K3 | 6.19% | 3.43% | Ascalon | 10.0% | 11.4% | Aligned user copy, size: 512B (offset: 0, 8) BW Improvement | Write | Read | K3 | 1.69% | 0.90% | Ascalon | 1.25% | 3.32% | Suggested-by: Anton Blanchard Signed-off-by: Andy Chiu Link: https://patch.msgid.link/20260901192334.3543340-1-tchiu@tenstorrent.com Signed-off-by: Paul Walmsley commit f47190b08b71e8482072978373ee88cb2dfbdaf4 Author: Steffen Eiden Date: Wed Aug 12 17:55:20 2026 +0200 s390/uv: Prevent potential out-of-bounds read When the system has more than 85 secrets, the uv_secret_list struct array only holds up to 85 items per page, resulting in an out of bounds read in find_secret_in_page if the targeted secret is in the next page or not stored at all. Fix this by looping over the number of stored secrets which is the per sub-list count of stored secrets and not the overall count. Fixes: 7c9137af2042 ("s390/uv: Retrieve UV secrets support") Signed-off-by: Steffen Eiden Reviewed-by: Christoph Schlameuss Signed-off-by: Claudio Imbrenda Message-ID: <20260812-uv_secrets_fix-v3-2-a85bd29e0666@linux.ibm.com> commit d12ce6bce5ec5175c3581e01c71e7a5abb286d9b Author: Steffen Eiden Date: Wed Aug 12 17:55:19 2026 +0200 s390/uv: Fix loop condition in uv_find_secrets Systems with more than 85 UV secrets got -ENOENT for any secret past the first page. Fix this by setting the start index at the beginning of the loop in uv_find_secret() and not at the end. First test if there are more secrets left by comparing start_idx with list->next_secret_idx, and then set the start index to the next secret index. Fixes: 7c9137af2042 ("s390/uv: Retrieve UV secrets support") Acked-by: Claudio Imbrenda Reviewed-by: Christoph Schlameuss Signed-off-by: Steffen Eiden Signed-off-by: Claudio Imbrenda Message-ID: <20260812-uv_secrets_fix-v3-1-a85bd29e0666@linux.ibm.com> commit 65e05ec252a9b79e75930d3c4dd42d8877db04c5 Author: Anthony Krowiak Date: Tue Aug 18 15:33:49 2026 -0400 s390/vfio-ap: fix KVM GISC and page leak when queue removed from host config Three related problems exist in the handling of KVM interrupt and page resources when a queue is removed from the host's AP configuration while assigned to a mediated device (mdev). Problem 1: ~~~~~~~~~ AP_RESPONSE_Q_NOT_AVAIL not handled in vfio_ap_mdev_reset_queue() When the AP bus removes a queue device whose adapter or domain has been removed from the host's AP configuration, vfio_ap_mdev_remove_queue() is called. If the queue is still in the host's AP configuration at that point, it calls vfio_ap_mdev_reset_queue(), which issues a PQAP(ZAPQ). Since the adapter is already gone from the host configuration, ap_zapq() returns AP_RESPONSE_Q_NOT_AVAIL (0x01). This response code is not handled in vfio_ap_mdev_reset_queue()'s switch statement and falls through to the default case, which issues a WARN but does not call vfio_ap_free_aqic_resources(). As a result, if IRQ handling was enabled for the queue by the guest, the KVM GISC registration and the pinned guest page holding the notification indicator byte (NIB) are both leaked. This is fixed by adding AP_RESPONSE_Q_NOT_AVAIL to the same case as AP_RESPONSE_DECONFIGURED and AP_RESPONSE_CHECKSTOPPED in vfio_ap_mdev_reset_queue(). Like those response codes, Q_NOT_AVAIL indicates the queue is not operational and no further reset attempts are possible; the correct action is to free the IRQ resources immediately. Problem 2: ~~~~~~~~~ AP_RESPONSE_Q_NOT_AVAIL not handled in apq_status_check() In vfio_ap_mdev_reset_queue(), there are four cases that indicate a queue reset has not yet completed, in which case apq_reset_check() is queued to a work queue to verify completion of the reset operation. This function uses the PQAP(TAPQ) function to get the queue's status and calls apq_status_check() to verify whether the reset has completed, failed or needs to be executed again. As described in Problem #1 above, apq_reset_check() does not specifically check for AP_RESPONSE_Q_NOT_AVAIL, thereby potentially leaking KVM GISC registration and the pinned guest page holding the NIB. This is fixed by adding a case statement for AP_RESPONSE_Q_NOT_AVAIL to apq_status_check() and returning -ENODEV for that case. The caller, apq_reset_check() will then check for this return code and call vfio_ap_free_aqic_resources() to prevent the leak. Problem 3: ~~~~~~~~~ vfio_ap_free_aqic_resources() leaks saved_isc when kvm is NULL vfio_ap_free_aqic_resources() guards the call to kvm_s390_gisc_unregister() with: if (q->saved_isc != VFIO_AP_ISC_INVALID && !WARN_ON(!(q->matrix_mdev && q->matrix_mdev->kvm))) If matrix_mdev->kvm is NULL -- which can happen when vfio_ap_mdev_unset_kvm() has already run and cleared kvm before a subsequent cleanup path reaches this function -- the WARN_ON fires and the entire block is skipped. This leaves q->saved_isc set to a non-invalid value, creating a potential double-free on any subsequent call to this function. When kvm is NULL the KVM guest is already torn down, so kvm_s390_gisc_unregister() need not and cannot be called; however, q->saved_isc must always be cleared. Fix this by separating the kvm_s390_gisc_unregister() call from the q->saved_isc reset. The WARN_ON now guards only the genuinely impossible case of matrix_mdev being NULL. A NULL kvm is handled gracefully by skipping only the unregister call, and q->saved_isc = VFIO_AP_ISC_INVALID is set unconditionally whenever saved_isc was not already invalid. Additionally, add an else clause to the host-config check in vfio_ap_mdev_remove_queue() to call vfio_ap_free_aqic_resources() directly when the queue is not in the host's AP configuration. This serves as a backstop: when the AP bus fires the driver .remove callback after an adapter is removed from the host config, the queue is by definition no longer addressable, so vfio_ap_mdev_reset_queue() would always return Q_NOT_AVAIL. The else clause handles this case directly without the unnecessary ap_zapq() call, and ensures cleanup occurs even if kvm has already been set to NULL by a prior call to vfio_ap_mdev_unset_kvm(). Fixes: b9bd10c43456d ("s390/vfio-ap: do not reset queue removed from host config") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Acked-by: Halil Pasic Signed-off-by: Claudio Imbrenda Message-ID: <20260818193349.1877940-2-akrowiak@linux.ibm.com> commit 3fb905f07ea45b31c8f67ba6e4668de46f527e65 Author: Jacob Moroni Date: Tue Sep 1 16:00:14 2026 +0000 RDMA/irdma: Enforce local fence for IB_WR_REG_MR Enforce local fence for IB_WR_REG_MR to avoid spurious FASTREG_VALID_MKEY async events during heavy invalidation and registration activity. Commit 69e8e429bca2 ("RDMA/irdma: Enforce local fence for LOCAL_INV WRs") was very similar, but was not sufficient to prevent all occurrences of these async events. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260901160014.2026285-1-jmoroni@google.com Signed-off-by: Leon Romanovsky commit 00baeade709fb66da647e8327e8398bb532e30f7 Author: Cheng Xu Date: Fri Aug 28 11:03:44 2026 +0800 RDMA/erdma: Use IRQ-safe XArray helpers for QP and CQ tables Locked QP and CQ lookups from EQ interrupts can deadlock with create-path XArray updates. If an interrupt arrives while the create path holds the plain xa_lock, the lookup spins forever trying to acquire the same lock. Use IRQ-safe XArray helpers for all QP and CQ create-path updates, including the GSI QP store and error paths. Initialize both arrays with XA_FLAGS_LOCK_IRQ so sleeping allocations preserve interrupt state. Fixes: 98df2aee1459 ("RDMA/erdma: Hold CQ references when processing EQ events") Fixes: a52eeff32024 ("RDMA/erdma: Hold QP references for AE and CM processing") Signed-off-by: Cheng Xu Link: https://patch.msgid.link/20260828030344.88021-1-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky commit 3476c28c9addfa253f505e6bd87f1f5598b961d0 Author: Li RongQing Date: Wed Aug 26 15:32:16 2026 +0800 RDMA/mad: Fix receive buffer leak when PKey enforcement fails ib_mad_complete_recv() initializes mad_recv_wc->rmpp_list and then runs ib_mad_enforce_security() before linking recv_buf onto that list. On failure it calls ib_free_recv_mad(), which only walks rmpp_list and frees the ib_mad_private of every buffer found there. As the list is still empty at that point, nothing is freed at all. The caller cannot clean up either: ib_mad_recv_done() sets recv to NULL right after ib_mad_complete_recv() returns, assuming the MAD layer took ownership of the buffer. Every MAD that fails the PKey check therefore leaks one ib_mad_private (about 300 bytes per IB port MAD, ~2K for OPA), and a remote node can trigger this repeatedly by sending MADs with a wrong PKey. Link recv_buf onto rmpp_list right after the list is initialized, so the error path has something to free. Fixes: 47a2b338fe63 ("IB/core: Enforce security on management datagrams") Signed-off-by: Li RongQing Link: https://patch.msgid.link/20260826073216.2367-1-lirongqing@baidu.com Signed-off-by: Leon Romanovsky commit af8c27375733fb6a6df9fa484cda77cc3dd0cb80 Author: Thomas Lamprecht Date: Thu Aug 27 19:24:24 2026 +0200 scsi: megaraid_sas: Limit NVMe request size to the PRP chain frame megasas_make_prp_nvme() builds a command's PRP list in cmd->sg_frame, a DMA pool buffer of instance->max_chain_frame_sz bytes, spending one entry per NVMe page of the transfer plus one per page of the buffer for the chain pointer. The loop runs until the transfer is described and never checks the buffer bound. max_hw_sectors comes straight from the MDTS the firmware reports for the drive. On drives with a large MDTS the only thing keeping the list inside the buffer was the block layer default of 1280 KiB, which needs 320 entries, which fit into a 4 KiB frame as that holds 512. But since commit 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") that default is 4 MiB, and such a transfer needs 1025 entries, so the list runs a full page past the end of the frame: sd 1:0:1:0: [sdb] tag#630 page boundary ptr_sgl: 0x00000000ba62d13f BUG: unable to handle page fault for address: ff663bcb81e7c000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:megasas_build_and_issue_cmd_fusion+0xeaa/0x1870 [megaraid_sas] If the page after the frame happens to be mapped, the overrun does not fault but silently corrupts the neighbouring pool entry, which is another in-flight command's PRP list. Cap max_hw_sectors at what the chain frame can describe, less one page for transfers that do not start on a page boundary and so need one entry more. This is the megaraid_sas counterpart of commit 04631f55afc5 ("scsi: mpt3sas: Limit NVMe request size to 2 MiB"), but derives the limit from max_chain_frame_sz rather than hardcoding it. Cc: stable@vger.kernel.org Fixes: 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") Reported-by: Lukasz Magiera Closes: https://lore.kernel.org/all/GPhsSM0vkgyIrs0DIZ62qeUZX7X4RxwQXVKiuvMx-lHQVSPDxpztUyQOGS0xikqvJ-Z94hMV-dW_5KN_0CX2hsfV7kTf_t0MTf6vdAAaSEc=@magik.net/ Reported-by: Mira Limbeck Closes: https://lore.kernel.org/all/d171cc76-bf25-48ce-b482-d344669dfc24@proxmox.com/ Suggested-by: Martin K. Petersen Link: https://lore.kernel.org/all/yq17bmzd5jr.fsf@ca-mkp.ca.oracle.com/ Signed-off-by: Thomas Lamprecht Closes: https://lore.kernel.org/linux-scsi/20260827182106.535D61F000E9@smtp.kernel.org Link: https://patch.msgid.link/20260827175743.734593-1-t.lamprecht@proxmox.com Signed-off-by: Martin K. Petersen (Oracle) commit 08d4d9802d58bf032099091e6acf719f3298f28e Author: Li RongQing Date: Wed Aug 26 15:31:46 2026 +0800 RDMA/uverbs: Fix potential leak of resources->collection in flow_resources_alloc() The two array allocations are done unconditionally and only checked afterwards, so if the counters allocation fails while the collection allocation succeeds, the error path frees counters and the containing struct but never frees resources->collection, losing the only pointer to it. Fixes: de7498147d00 ("RDMA/uverbs: Refactor flow_resources_alloc() function") Signed-off-by: Li RongQing Link: https://patch.msgid.link/20260826073146.2203-1-lirongqing@baidu.com Signed-off-by: Leon Romanovsky commit 90af7fde083e1b22c349c3a8b1626728e44e474c Author: Yifei Gao Date: Tue Aug 4 21:34:56 2026 +0000 memstick: ms_block: destroy io_queue workqueue on removal msb_init_disk() creates the per-card ordered workqueue msb->io_queue with alloc_ordered_workqueue(). It is torn down with destroy_workqueue() only on the init error path; msb_remove() never destroys it. msb_stop() merely flushes the queue, and neither msb_data_clear() nor put_disk() free it. As a result every card insert/remove cycle leaks the workqueue and its kworker, exhausting kernel memory over repeated cycles. Destroy the workqueue in msb_remove() after the disk has been removed and the queue drained. Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yifei Gao Signed-off-by: Ulf Hansson commit 4617721c502b2ddaa4e324e86da4997edf738fa5 Author: Steven Rostedt Date: Wed Sep 2 09:55:01 2026 -0400 ftrace: Synchronize the initialization of ftrace_ops There's some internal state that ftrace_ops needs to have set, but since it can be declared outside of the ftrace.c code, it calls ftrace_ops_init() on the ops in every global function. The issue is that if two tasks call it on the same ops at the same time it is possible to have the initialization of one corrupt the initialization of the other call. Create a ops_mutex to use to synchronize every initialization of the ftrace_ops. The mutex is taken within checking the ftrace_ops flag that states it was initializied but the flag is checked again after the mutex has been taken. Checking first outside the mutex allows it to shortcut having to take the mutex. But then the check needs to be done again after the mute is taken in case of races. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260902095501.6b59af20@gandalf.local.home Fixes: f04f24fb7e48d ("ftrace, kprobes: Fix a deadlock on ftrace_regex_lock") Reported-by: sashiko-bot@kernel.org Close: https://lore.kernel.org/all/20260829025528.49A831F000E9@smtp.kernel.org/ Signed-off-by: Steven Rostedt commit 7ac81e2d2240f2c57bd073b0733e0b2abca38e82 Author: Genjian Zhang Date: Fri Aug 7 23:57:15 2026 +0800 dm-ebs: fix incorrect device offset check in ebs_ctr() is a backing-device sector offset; ti->len is the virtual target length. Comparing them rejects valid tables, e.g.: dmsetup create ebs0 --table "0 1048576 ebs /dev/sda 2097152 1 8" -> ebs: Invalid device offset sector (-EINVAL) Drop the check. Bounds against the backing device are already enforced later by device_area_is_invalid() via ebs_iterate_devices(). Cc: stable@vger.kernel.org Fixes: d3c7b35c20d6 ("dm: add emulated block size target") Signed-off-by: Genjian Zhang Signed-off-by: Mikulas Patocka commit 4b3c5965fca99f62d31c963294bd5b23cc488e97 Author: Rahul Chandelkar Date: Mon Aug 17 16:07:29 2026 +0800 scsi: bsg: Fix TOCTOU in io_uring passthrough command setup scsi_bsg_uring_cmd() reads bsg_uring_cmd from the shared mmap'd SQE. Userspace can change a field after we check it and before we use it. request_len is the sharp case: it can grow past sizeof(scmd->cmnd) after the bound check and overflow scmd->cmnd in copy_from_user(). READ_ONCE() the SQE fields we check or use into locals before use. Fixes: 7b6d3255e7f8 ("scsi: bsg: add io_uring passthrough handler") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260527105931.3950913-1-rc@rexion.ai Signed-off-by: Rahul Chandelkar Co-developed-by: Yang Xiuwei Signed-off-by: Yang Xiuwei Link: https://patch.msgid.link/20260817080730.967879-3-yangxiuwei@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) commit ece06de726737e887dc0225c8283477624f8ae21 Author: Yang Xiuwei Date: Mon Aug 17 16:07:28 2026 +0800 scsi: bsg: Cap io_uring sense copy to max_response_len Completion copied scmd->sense_len to the user response buffer without honoring max_response_len. After a valid sense, the midlayer sets sense_len to the real length (up to SCSI_SENSE_BUFFERSIZE), so a smaller user buffer was overrun. Fixes: 7b6d3255e7f8 ("scsi: bsg: add io_uring passthrough handler") Cc: stable@vger.kernel.org Signed-off-by: Yang Xiuwei Link: https://patch.msgid.link/20260817080730.967879-2-yangxiuwei@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) commit 7d4d4f3b668d708d94f62ecdd33ac330a6fd8a84 Author: Mikulas Patocka Date: Wed Sep 2 16:36:26 2026 +0200 dm-integrity: fix NULL pointer dereference when the 'R' flag is used If the dm-integrity device has the SB_FLAG_DIRTY_BITMAP flag set and the user activates the device in the 'R' mode, a crash in dm_integrity_resume happens because the function attempts to read the journal containing the bitmap. This patch makes dm-integrity skip any writes to the device in dm_integrity_resume if the device is activated in the 'R' mode. Signed-off-by: Mikulas Patocka Fixes: 468dfca38b1a ("dm integrity: add a bitmap mode") Cc: stable@vger.kernel.org commit ce6b9e5dd873de532cd924e2abc928220cdc2738 Author: Eduard Zingerman Date: Wed Sep 2 00:28:35 2026 -0700 selftests/bpf: Precision tracking across BPF_ABS subprog exit A test case checking that the verifier properly backtracks both fallthrough and implicit subprogram exit paths modelled for BPF_LD | BPF_ABS instruction. Without the previous patch: - the verifier did not call bt_subprog_enter() on the implicit subprogram exit path; - bpf_pseudo_call() branch in backtrack_insn() executed 'bpf_bt_set_frame_reg(bt, bt->frame - 1, i);' with bt->frame == 0; - causing a segmentation fault. 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-2-59368f1be435@gmail.com commit 387b1baefbb776e3f48dc2261e77a49213f470f7 Author: Eduard Zingerman Date: Wed Sep 2 00:28:34 2026 -0700 bpf: backtrack_insn(): Handle ld_{abs,ind} subprog exit edge 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 commit f4a23e17d84fd2a152d9e12369761934e1af0ee8 Author: HyeongJun An Date: Wed Sep 2 21:50:58 2026 +0900 ALSA: rawmidi: Return the error from snd_rawmidi_input_params() The snd_rawmidi_input_params() computes err for the three invalid mode combinations and for resize_runtime_buffer(), applies the new framing and clock type only when err is zero, and then returns 0 anyway. A caller that asked for parameters the kernel rejected is told the change succeeded, and the substream keeps its old buffer. The open_mutex conversion turned the early returns into assignments. It handled the output sibling correctly, which still returns err, and left this one behind. Fixes: 94b98194b62e ("ALSA: rawmidi: Take open_mutex around parameter changes") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260902125058.19499-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai commit 23d7e03a52ece66b992620aa9b8fa5f164077c0f Author: Sriharsha Basavapatna Date: Mon Aug 24 22:54:43 2026 +0530 RDMA/bnxt_re: Avoid exposing umdbr to userspace The umdbr field in struct bnxt_re_db_region returns the raw unmapped PCI BAR address of the doorbell region. Avoid sharing this field to the userspace. Change this to a reserved field and stop populating it, keeping the ABI layout and size unchanged for existing binaries. Fixes: 1234a9d8aebb ("RDMA/bnxt_re: Support doorbell extensions") Signed-off-by: Sriharsha Basavapatna Link: https://patch.msgid.link/20260824172443.33943-1-sriharsha.basavapatna@broadcom.com Reviewed-by: Selvin Xavier Signed-off-by: Leon Romanovsky commit 99c24a8968ebef0573825b5cb89d5985d51635b9 Author: Ryan Mehri Date: Sat Aug 22 23:33:43 2026 -0400 RDMA/rtrs: guard against null kobj name In the client, if `init_path()` errors, the callee tries to clean up with `rtrs_clt_close_conns()`. However, this can lead to calling the event tracing code with `clt_path->kobj->name` being `NULL` and thus causing a null pointer dereference when trying to copy from it. This just adds a guard to check that the name is not `NULL` before copying from it. The server appears to have a similar pattern. Fixes: 5a93929d9f9a1 ("RDMA/rtrs-clt: Add event tracing support") Fixes: c16762b7bf54d ("RDMA/rtrs-srv: Add event tracing support") Reported-by: syzbot+1695193198994f4e7fed@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1695193198994f4e7fed Signed-off-by: Ryan Mehri Link: https://patch.msgid.link/20260823034303.163403-1-ryan.mehri1@gmail.com Reviewed-by: Jack Wang Signed-off-by: Leon Romanovsky commit 6c368f7baaea63c1c7c28c6df271511f2a1562c9 Author: Linkai Gong Date: Fri Aug 21 17:09:08 2026 +0800 RDMA/bnxt_re: check create_singlethread_workqueue() in DCB setup bnxt_re_init_dcb_wq() ignores a failed allocation. The async DCB handler later calls queue_work() on the NULL pointer. Fixes: 51dc5312dcd9 ("RDMA/bnxt_re: Add support to handle DCB_CONFIG_CHANGE event") Signed-off-by: Linkai Gong Signed-off-by: Leon Romanovsky commit a8fe3dfce8c0d8a76dc3d8486a5bff5feebe156f Author: Yehyeong Lee Date: Fri Aug 21 17:06:20 2026 +0900 IB/isert: wait for deferred control PDU completions before releasing the connection isert_send_done() hands ISTATE_SEND_TASKMGTRSP, ISTATE_SEND_REJECT and ISTATE_SEND_TEXTRSP completions off to isert_comp_wq and returns. The work item then runs isert_completion_put() -> isert_put_cmd(), which reads isert_conn->conn and takes conn->cmd_lock. Nothing orders that work item against teardown. isert_wait_conn() queues isert_release_work, which frees isert_conn, and iscsit_close_connection() frees the iscsit_conn right after it returns, so the queued work can run against freed memory. Count the deferred control PDU completions per connection and let isert_wait_conn() wait for them before the release work is queued. ISTATE_SEND_LOGOUTRSP is deliberately not counted: that branch runs iscsit_logout_post_handler(), which ends up waiting for conn->conn_wait_comp, and that completion is only sent by iscsit_close_connection() after it has called iscsit_wait_conn(). Waiting for it here would deadlock. Its wait stays the existing isert_wait4logout(). The splat below is from a kernel with tracing printk()s and an msleep(200) injected into isert_do_control_comp() to widen the window: BUG: KASAN: slab-use-after-free in isert_put_cmd+0x53d/0x620 Read of size 8 at addr ffff8881054f1038 by task kworker/u17:1/182 CPU: 0 UID: 0 PID: 182 Comm: kworker/u17:1 Tainted: G B 7.2.0-rc5-TWIDE-gb8babf08acc7 #1 PREEMPT(lazy) Tainted: [B]=BAD_PAGE Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: isert_comp_wq isert_do_control_comp Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x3e/0x70 ? isert_put_cmd+0x53d/0x620 kasan_report+0xce/0x100 ? isert_put_cmd+0x53d/0x620 isert_put_cmd+0x53d/0x620 ? isert_completion_put+0x305/0x330 ? isert_do_control_comp+0x2ef/0x310 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 48: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x158/0x370 isert_cma_handler+0x1e3/0x2ae0 cma_cm_event_handler+0x3e/0x240 cma_ib_req_handler+0x17d9/0x4490 cm_process_work+0x41/0x330 cm_work_handler+0x5727/0xc160 process_one_work+0x633/0x1030 worker_thread+0x45b/0xd10 kthread+0x2c6/0x3b0 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 Freed by task 184: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x121/0x380 iscsit_close_connection+0x7cf/0x1e60 iscsit_take_action_for_connection_exit+0x1b6/0x360 iscsi_target_tx_thread+0x472/0x690 kthread+0x2c6/0x3b0 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260821080620.1694119-1-yhlee@isslab.korea.ac.kr Signed-off-by: Leon Romanovsky commit d85f0f0a7c85756fc992c70d869706f19dac9259 Author: Yehyeong Lee Date: Wed Aug 19 10:08:04 2026 +0900 IB/iser: reject a remote invalidation of an unregistered direction A write command whose data is sent entirely as immediate data is not registered. iser_reg_mem_fastreg() takes the DMA key path and leaves rdma_reg[ISER_DIR_OUT].desc at NULL, while iser_dma_map_task_data() has already set dir[ISER_DIR_OUT]. iser_check_remote_inv() looks at dir[] alone and hands the descriptor to iser_inv_desc(), which reads desc->sig_protected. A target that answers such a command with IB_WR_SEND_WITH_INV faults the initiator. Leaving those commands unregistered is deliberate. The same function already terminates the connection when a target sends a remote invalidation the initiator did not ask for. A target that invalidates a direction that was never registered is in the same class, so give it the same answer. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] CPU: 0 UID: 0 PID: 40 Comm: kworker/u8:2 Not tainted 7.2.0-rc5-ISERHOST-gf5098b6bae76-dirty #3 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: rxe_wq do_work RIP: 0010:iser_task_rsp+0x6d6/0xec0 Code: 48 c1 ea 03 80 3c 02 00 0f 85 ba 06 00 00 48 8b 9b 78 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 20 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 76 06 00 00 80 7b 20 00 0f 84 3d 04 RSP: 0018:ffff88811b008db8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000001848 RDX: 0000000000000004 RSI: 1ffff11021587b12 RDI: 0000000000000020 RBP: ffff88810adc1ae4 R08: ffff888109b7f860 R09: ffffffff90a922c0 R10: ffff88810adc1a1c R11: 000000000000003c R12: ffff888109b7f800 R13: ffff88810adc1acc R14: ffff888109b7f820 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88818a676000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005afe2b CR3: 000000010af23005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: __ib_process_cq+0xe1/0x390 ib_poll_handler+0x6e/0x200 irq_poll_softirq+0x1df/0x480 ? clockevents_program_event+0x2ba/0x860 ? __pfx_irq_poll_softirq+0x10/0x10 handle_softirqs+0x18e/0x590 ? __pfx_handle_softirqs+0x10/0x10 ? __hrtimer_rearm_deferred+0x156/0x450 do_softirq+0x3b/0x60 __local_bh_enable_ip+0x61/0x70 __alloc_skb+0x732/0x890 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx___alloc_skb+0x10/0x10 ? _raw_read_unlock_irqrestore+0x16/0x50 rxe_init_packet+0x16b/0x4f0 prepare_ack_packet+0xb8/0x830 rxe_receiver+0x499/0x9980 ? __pfx_rxe_receiver+0x10/0x10 ? rxe_completer+0x29e5/0x38c0 ? hrtimer_start_range_ns_common+0x75f/0x1730 ? hrtimer_start_range_ns+0xa6/0x2c0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_rxe_receiver+0x10/0x10 do_work+0x144/0x470 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Fixes: 59caaed7a72a ("IB/iser: Support the remote invalidation exception") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260819010804.641772-1-yhlee@isslab.korea.ac.kr Reviewed-by: Max Gurtovoy Signed-off-by: Leon Romanovsky commit 9cdfad5dd5529e1700f51feaed5e8a90044d7e35 Author: Bart Van Assche Date: Tue Aug 18 12:52:29 2026 +0900 RDMA/srp: Fix srp_remove_target() Remove all logical units before disconnecting the transport because one or more SCSI commands may be submitted while removing logical units. Remove the SCSI host after the transport has been disconnected because the code that disconnects the transport needs resources that are freed by the code that removes the SCSI host (SCSI host tag set). Remove the srp_rport_get() and srp_rport_put() calls because the purpose of these calls was to keep the rport until tl_err_work is cancelled. Reported-by: Yehyeong Lee Closes: https://lore.kernel.org/linux-rdma/20260812190418.200337-1-yhlee@isslab.korea.ac.kr/ Signed-off-by: Bart Van Assche Signed-off-by: Yehyeong Lee Signed-off-by: Leon Romanovsky commit 2ac7bad110be6ebe478d6bd57821f7f5259a1f54 Author: Ovidiu Panait Date: Wed Jul 22 08:53:53 2026 +0000 arm64: dts: renesas: r9a09g087: Switch GBETH TX queue scheduling to WRR The GBETH ethernet nodes don't specify a TX scheduling policy, so stmmac falls back to Strict Priority. In this configuration the queue with the highest priority gets all the traffic, starving the others under load. Under sustained UDP TX load with multiple data streams, this starvation triggers spurious adapter resets due to TX queue timeouts: iperf3 -c -i0 -t60 --bind-dev end0 -u -b0 -P4 end0: NETDEV WATCHDOG: CPU: 1: transmit queue 1 timed out 5228 ms end0: Reset adapter. Investigation shows that only the highest priority queue is advancing while the others stall for more than 5 seconds, causing a netdev watchdog reset. Switch the TX scheduling policy to Weighted-Round-Robin (WRR) so that traffic is processed across all queues, eliminating the stalls. Fixes: c4698a34993b ("arm64: dts: renesas: r9a09g087: Add GMAC nodes") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260722085353.136986-6-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven commit f9d9a1913c09366bf7b967d39575e06cb80128dc Author: Ovidiu Panait Date: Wed Jul 22 08:53:52 2026 +0000 arm64: dts: renesas: r9a09g077: Switch GBETH TX queue scheduling to WRR The GBETH ethernet nodes don't specify a TX scheduling policy, so stmmac falls back to Strict Priority. In this configuration the queue with the highest priority gets all the traffic, starving the others under load. Under sustained UDP TX load with multiple data streams, this starvation triggers spurious adapter resets due to TX queue timeouts: iperf3 -c -i0 -t60 --bind-dev end0 -u -b0 -P4 end0: NETDEV WATCHDOG: CPU: 1: transmit queue 1 timed out 5228 ms end0: Reset adapter. Investigation shows that only the highest priority queue is advancing while the others stall for more than 5 seconds, causing a netdev watchdog reset. Switch the TX scheduling policy to Weighted-Round-Robin (WRR) so that traffic is processed across all queues, eliminating the stalls. Fixes: 394c1e24a4cf ("arm64: dts: renesas: r9a09g077: Add GMAC nodes") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260722085353.136986-5-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven commit 63016c3a91f2c458ca75869c8c782e899591f22d Author: Ovidiu Panait Date: Wed Jul 22 08:53:51 2026 +0000 arm64: dts: renesas: r9a09g047: Switch GBETH TX queue scheduling to WRR The GBETH ethernet nodes don't specify a TX scheduling policy, so stmmac falls back to Strict Priority. In this configuration the queue with the highest priority gets all the traffic, starving the others under load. Under sustained UDP TX load with multiple data streams, this starvation triggers spurious adapter resets due to TX queue timeouts: iperf3 -c -i0 -t60 --bind-dev end0 -u -b0 -P4 end0: NETDEV WATCHDOG: CPU: 1: transmit queue 1 timed out 5228 ms end0: Reset adapter. Investigation shows that only the highest priority queue is advancing while the others stall for more than 5 seconds, causing a netdev watchdog reset. Switch the TX scheduling policy to Weighted-Round-Robin (WRR) so that traffic is processed across all queues, eliminating the stalls. Fixes: 41ffbb1c42d3 ("arm64: dts: renesas: r9a09g047: Add GBETH nodes") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260722085353.136986-4-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven commit 66fcbdbeca0118b8aeac218b33fa18c394513543 Author: Ovidiu Panait Date: Wed Jul 22 08:53:50 2026 +0000 arm64: dts: renesas: r9a09g056: Switch GBETH TX queue scheduling to WRR The GBETH ethernet nodes don't specify a TX scheduling policy, so stmmac falls back to Strict Priority. In this configuration the queue with the highest priority gets all the traffic, starving the others under load. Under sustained UDP TX load with multiple data streams, this starvation triggers spurious adapter resets due to TX queue timeouts: iperf3 -c -i0 -t60 --bind-dev end0 -u -b0 -P4 end0: NETDEV WATCHDOG: CPU: 1: transmit queue 1 timed out 5228 ms end0: Reset adapter. Investigation shows that only the highest priority queue is advancing while the others stall for more than 5 seconds, causing a netdev watchdog reset. Switch the TX scheduling policy to Weighted-Round-Robin (WRR) so that traffic is processed across all queues, eliminating the stalls. Fixes: c8c8a57c5b40 ("arm64: dts: renesas: r9a09g056: Add GBETH nodes") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260722085353.136986-3-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven commit 33da68f61d25ef8411489d06514ff627c1f88152 Author: Ovidiu Panait Date: Wed Jul 22 08:53:49 2026 +0000 arm64: dts: renesas: r9a09g057: Switch GBETH TX queue scheduling to WRR The GBETH ethernet nodes don't specify a TX scheduling policy, so stmmac falls back to Strict Priority. In this configuration the queue with the highest priority gets all the traffic, starving the others under load. Under sustained UDP TX load with multiple data streams, this starvation triggers spurious adapter resets due to TX queue timeouts: iperf3 -c -i0 -t60 --bind-dev end0 -u -b0 -P4 end0: NETDEV WATCHDOG: CPU: 1: transmit queue 1 timed out 5228 ms end0: Reset adapter. Investigation shows that only the highest priority queue is advancing while the others stall for more than 5 seconds, causing a netdev watchdog reset. Switch the TX scheduling policy to Weighted-Round-Robin (WRR) so that traffic is processed across all queues, eliminating the stalls. Fixes: 050ee38d0002 ("arm64: dts: renesas: r9a09g057: Add GBETH nodes") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260722085353.136986-2-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven commit e14d4302cbd0de773960bec33c2281508c8d8855 Merge: a518e63c377574 ba0623fc19a424 Author: Christian Brauner Date: Wed Sep 2 14:13:20 2026 +0200 Merge patch series "afs: Miscellaneous fixes" David Howells says: (1) Fix missing kunmap in afs_dir_search_bucket(). (2) Fix double-unmap of directory block. (3) Fix an incorrect free in afs_lookup_server(). (4) Clear stale peer app data after address list changes. * patches from https://patch.msgid.link/20260902121024.3328255-1-dhowells@redhat.com: afs: Clear stale peer app data after address list changes afs: Fix incorrect free in candidate cleanup in afs_lookup_server() afs: Fix double-unmap of directory block afs: Fix missing kunmap in afs_dir_search_bucket() Link: https://patch.msgid.link/20260902121024.3328255-1-dhowells@redhat.com Signed-off-by: Christian Brauner (Amutable) commit ba0623fc19a424f4745394c499f9f28a8d88d397 Author: Chengfeng Ye Date: Wed Sep 2 13:10:22 2026 +0100 afs: Clear stale peer app data after address list changes afs_fs_probe_fileserver() fetches the current endpoint state under server->fs_lock, but leaves old_alist as NULL. Consequently, afs_set_peer_appdata() treats every address list replacement as initial setup and only binds the new peers; it never unbinds peers removed from the old list. An address refresh can therefore proceed as follows. CPU 0 replaces server S's list and drops Pold without clearing Pold->app_data. The server destroyer then clears only S's current peers and lets S reach its RCU callback. After the callback frees S, CPU 1 handles a callback through an RxRPC connection that still pins Pold, reads Pold->app_data, and calls afs_use_server() on the freed object. KASAN reported: BUG: KASAN: slab-use-after-free in afs_find_server+0x3c/0xa0 Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74 Call Trace: afs_find_server+0x3c/0xa0 afs_rx_new_call+0x15c/0x390 rxrpc_new_incoming_call+0x97c/0x1730 rxrpc_input_packet.constprop.0+0xd03/0xec0 rxrpc_io_thread+0x967/0x1640 Allocated by task 93: afs_lookup_server+0x1a7/0x14c0 afs_alloc_server_list+0x43f/0xb60 afs_create_volume+0x923/0x1490 afs_get_tree+0x1c6/0x10a0 Freed by task 0: kfree+0x131/0x3c0 rcu_core+0x50a/0x1850 Last potentially related work creation: __call_rcu_common.constprop.0+0x71/0xa10 afs_put_server+0x213/0x2b0 Preserve old->addresses for the peer app-data update so that removed peers are cleared before the endpoint state is replaced. Also advance both cursors when the old and new lists share a peer; activating the old/new comparison without this would otherwise loop forever on the shared entry. Fixes: 40e8b52fe8c8 ("afs: Use the per-peer app data provided by rxrpc") Signed-off-by: Chengfeng Ye Signed-off-by: Qi Zhang Signed-off-by: David Howells Link: https://patch.msgid.link/20260902121024.3328255-5-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit 044d596094af4b769fb8e1173dff0d08bd68db6c Author: David Howells Date: Wed Sep 2 13:10:21 2026 +0100 afs: Fix incorrect free in candidate cleanup in afs_lookup_server() Fix afs_lookup_server() to not free an existing server's endpoint state when cleaning up a candidate server. The candidate record doesn't have an endpoint state yet at this point, so the free for that can just be removed. Fixes: 4882ba78574e ("afs: Fix afs_server ref accounting") Link: https://sashiko.dev/#/patchset/20260729160108.2031453-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260902121024.3328255-4-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit e3cfd3eb7d5be7787cc69530b423f788f14d084f Author: David Howells Date: Wed Sep 2 13:10:20 2026 +0100 afs: Fix double-unmap of directory block Fix afs_edit_dir_remove() to use a cleanup function to unmap the block pointed to by afs_dir_iter::block if it's left pointing to something rather than manually kunmapping the blocks. Manually kunmapping without clearing iter.blocks can result in a double-kunmap if afs_dir_find_block() is called twice in a row (which would be the case if the block being modified is not first in the hash chain). Fixes: a5b5beebcf96 ("afs: Use the contained hashtable to search a directory") Closes: https://sashiko.dev/#/patchset/20260716103030.3065561-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260902121024.3328255-3-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit 950ae84b5cc944fbe27d81806d0b76af765f779c Author: David Howells Date: Wed Sep 2 13:10:19 2026 +0100 afs: Fix missing kunmap in afs_dir_search_bucket() Fix afs_dir_search_bucket() to kunmap the block it's using in the "bad:" path. Fixes: a5b5beebcf96 ("afs: Use the contained hashtable to search a directory") Closes: https://sashiko.dev/#/patchset/20260716103030.3065561-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260902121024.3328255-2-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit edc5d19f9ffea5ddcb73b25a2de671544dd0e1d2 Merge: 4cb4aead98380f 2519439b4b5f6e Author: Mark Brown Date: Wed Sep 2 12:56:10 2026 +0100 ASoC: ux500: Fix MSP lifecycle, clocking and resources Linus Walleij says: Repair independent correctness problems in the DB8500 multichannel serial port driver. The series fixes duplex and repeated-prepare stream ownership, error propagation, frame and divider programming, FIFO watermarks, DAI validation, reset handling, and MMIO resource ownership. It also removes obsolete PRCMU QoS calls which are unconditional stubs. The register programming follows the DB8500 v2 reference manual. These changes are independent of the later sound-card devicetree conversion. Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-0-4b60b002d55a@kernel.org commit 2519439b4b5f6ee95879b1a44fc373127291b1e4 Author: Linus Walleij Date: Wed Sep 2 09:55:59 2026 +0200 ASoC: ux500: Program the MSP FIFO watermarks The DMA engine is configured for four-element bursts, but the MSP driver never programs the FIFO watermark register and instead depends on its previous or reset value. The DB8500 DMA request protocol requires the peripheral watermark to match the DMA packet size. Program four-element receive and transmit watermarks when configuring the first direction, before enabling MSP DMA requests. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-9-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit dc1a1b1e22066f01bb86a9b11ee998d4dc72db66 Author: Linus Walleij Date: Wed Sep 2 09:55:58 2026 +0200 ASoC: ux500: Allow repeated MSP prepare calls ALSA can call the DAI prepare callback again after an XRUN without first shutting down the stream. The MSP open helper rejects the second call with -EBUSY because the direction remains configured. Track successful playback and capture configurations at the DAI layer. Make repeated prepare calls no-ops and only close directions which were successfully prepared. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-8-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 7b819677b503667422b0b7bdb21853e0066f8606 Author: Linus Walleij Date: Wed Sep 2 09:55:57 2026 +0200 ASoC: ux500: Remove obsolete PRCMU QoS calls The DB8500 PRCMU QoS interface consists of unconditional inline stubs, so the MSP calls and cached constraint state have no effect. Device power and clocks are already represented by the regulator, power-domain and common-clock frameworks. Remove the dead calls and their private state instead of pretending to change the APE operating point. Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-7-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 4fb67925f33ad789e9e00903a73306ed40f7ae32 Author: Linus Walleij Date: Wed Sep 2 09:55:56 2026 +0200 ASoC: ux500: Request the MSP MMIO resource A bare devm_ioremap() neither reserves the register range nor preserves the platform resource error. This permits another driver to claim the same range and reports every mapping failure as an allocation failure. Use the managed platform resource helper, retaining the resolved resource only to derive the DMA register address. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-6-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 66ec63e7a90bedc56aa050fbe437964008c3d584 Author: Linus Walleij Date: Wed Sep 2 09:55:55 2026 +0200 ASoC: ux500: Deassert the MSP reset during probe The devicetree has described each MSP reset line since the PRCC reset controller was added, but the driver never acquires or deasserts it. The block can consequently remain inaccessible when firmware has left it in reset. Acquire the reset exclusively and keep it deasserted for the lifetime of the bound device. Fixes: 95f04048325c ("ARM: dts: ux500: Add reset lines to IP blocks") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-5-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 9ccbacf5a0120964fc1ffacb8151e3347bee9287 Author: Linus Walleij Date: Wed Sep 2 09:55:54 2026 +0200 ASoC: ux500: Validate MSP DAI configuration Installing channel constraints from hw_params is too late to affect the parameters being committed. The driver consequently accepts channel counts which disagree with the I2S or TDM setup. It also silently truncates out-of-range slot masks and accepts inverted bit clock formats which prepare then rejects. Validate the selected channel count directly, reject invalid masks before changing cached TDM state, and implement all four standard clock and frame inversion combinations. Use the requested format in validation diagnostics. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-4-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 94c18cea657c48680e4ee20b635b6c01f3eb352e Author: Linus Walleij Date: Wed Sep 2 09:55:53 2026 +0200 ASoC: ux500: Correct MSP frame and bit clock setup FRPER plus one is the number of bit clocks in a frame. It must follow the configured slot count and width. The legacy rate-dependent constants produce malformed frames; notably, a 16-slot, 16-bit frame is programmed as 278 rather than 256 clocks. Derive the frame period from the TDM geometry and use the real functional clock rate. Validate that the requested bit clock has an exact, representable divider, program SCKDIV as divider minus one, and report the resulting bit clock using that same divisor. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-3-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 3415421a2b0bc4e32bb5a9df24ed7863512d47a7 Author: Linus Walleij Date: Wed Sep 2 09:55:52 2026 +0200 ASoC: ux500: Propagate MSP setup errors The prepare callback continues with a partly initialized configuration when format setup fails. Probe likewise tests the allocated pointer instead of the return value, so an MMIO resource or mapping failure can be ignored after allocation succeeds. Return configuration failures from prepare and test the MSP initialization result directly. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-2-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit c37ba8fe00f264eee2fd18b0bff7c5f188136c51 Author: Linus Walleij Date: Wed Sep 2 09:55:51 2026 +0200 ASoC: ux500: Fix MSP stream lifecycle handling The trigger stop path drops the direction busy flag even though ALSA still owns the stream until shutdown. A later trigger cannot reliably restart it, shutdown may leave the block configured, and a second stream may overwrite shared duplex configuration. Keep configured and running directions as separate state. Program shared settings only for the first direction, require a compatible configuration for the other half of a duplex stream, and enable the frame generator only while a provider stream is running. Also fix the RX-disable direction test and preserve the other direction multichannel setup. Fixes: 3592b7f69a54 ("ASoC: Ux500: Add MSP I2S-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260902-ux500-msp-fixes-v2-1-4b60b002d55a@kernel.org Signed-off-by: Mark Brown commit 312fd3f3a85b89aa0d4fb5417043d640daa3732c Author: Dmitry Torokhov Date: Sun Aug 30 04:15:10 2026 -0700 platform/x86: x86-android-tablets: use shared battery swnode group on Yoga Tab 2 The WM5102 codec software node lenovo_yoga_tab2_830_1050_wm5102 is registered automatically when attached to the codec device via device_add_software_node() in lenovo_yoga_tab2_830_1050_init_codec(). Including it in lenovo_yoga_tab2_830_1050_swnodes is therefore redundant, leaving generic_lipo_hv_4v35_battery_node as the only node needing registration. Switch lenovo_yoga_tab2_830_1050_info and lenovo_yoga_tab2_1380_info to use the shared generic_lipo_hv_4v35_battery_swnodes group directly and drop the custom lenovo_yoga_tab2_830_1050_swnodes array. Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-6-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 74884436a53df0bbaf6d92d2922f643a4581b247 Author: Dmitry Torokhov Date: Sun Aug 30 04:15:09 2026 -0700 platform/x86: x86-android-tablets: drop redundant swnode group on YT3 The WM5102 codec software node lenovo_yt3_wm5102 is assigned to the board info swnode pointer in lenovo_yt3_spi_devs. When spi_new_device() instantiates the SPI device, device_add_software_node() automatically registers the software node. Therefore, explicitly registering lenovo_yt3_swnodes via software_node_register_node_group() and listing it in .swnode_group is redundant. Drop the unused node group and registration. Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-5-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 7872c625cd83a0247821cedd6c6f63938d4bddbc Author: Dmitry Torokhov Date: Sun Aug 30 04:15:08 2026 -0700 platform/x86: x86-android-tablets: add Crystal Cove GPIO swnode support The crystalcove_gpiochip_node was created when gpiolib supported matching a software node name against the GPIO chip label. Later, gpiolib replaced name matching with firmware node identity mapping, and support for dynamically attaching software nodes to ACPI GPIO chips as secondary firmware nodes was added for Baytrail and Cherryview, but Crystal Cove ("INT33FD:00") was omitted. Consequently, lookups on the unattached Crystal Cove software node fail. Add support for attaching crystalcove_gpiochip_node to the INT33FD:00 ACPI device as a secondary firmware node, and enable it on Lenovo Yoga Tab 2 models. Fixes: 611fd6cfe139 ("gpio: swnode: remove deprecated lookup mechanism") Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-4-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit aab060ec969c3859b81f80f3444fd5a2edfc3cf5 Author: Dmitry Torokhov Date: Sun Aug 30 04:15:07 2026 -0700 platform/x86: x86-android-tablets: pass node group to gpio_secondary_fwnode_init() Currently gpio_secondary_fwnode_init() uses a file-scope static gpiochip_node_group variable initialized in probe. Pass the node group directly to gpio_secondary_fwnode_init() as an argument instead of using a global variable. This allows reusing the helper for additional GPIO controllers in subsequent patches. Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-3-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 144113b0a70fa18033a747ee5db6803308f7688c Author: Dmitry Torokhov Date: Sun Aug 30 04:15:06 2026 -0700 platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown In gpio_secondary_fwnode_init(), acpi_bus_find_device_by_name() returns a device reference, but the local dev variable is declared with __free(put_device), dropping the reference at the end of each iteration. Meanwhile, devm_add_action_or_reset() saves the dev pointer for gpio_secondary_unset() without incrementing its reference count, which could lead to a use-after-free during driver teardown if the device is released in the interim. Acquire an explicit device reference with get_device() when registering the devres action, and drop it with put_device() inside gpio_secondary_unset(). Fixes: 1448c2d2ca5c ("platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips") Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-2-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 355b6558dd7be049aff4f0d438b0128f91a982eb Author: Dmitry Torokhov Date: Sun Aug 30 04:15:05 2026 -0700 platform/x86: x86-android-tablets: fix Arizona GPIO swnode references The standalone arizona_gpiochip_node was created when gpiolib supported matching a software node name against the GPIO chip label ("arizona"). Later, gpiolib replaced name matching with firmware node identity mapping (and eventually dropped the fallback mechanism), causing GPIO lookups on unattached software nodes to fail. In gpio-arizona, the GPIO chip inherits the firmware node of the parent codec device. Fix the lookups by pointing the GPIO property entries directly to the codec device software node (which is attached to the parent device) and dropping the obsolete arizona_gpiochip_node. Fixes: 611fd6cfe139 ("gpio: swnode: remove deprecated lookup mechanism") Assisted-by: LLM Signed-off-by: Dmitry Torokhov Tested-by: Hans de Goede # Yoga tab 2 1380, yt3 Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260830-x86-android-lenovo-swnode-v1-1-066a91acb4ba@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 544d85de4dc22c01badfd8cefa59829ce35c4858 Author: Chris Lew Date: Thu Aug 27 17:48:46 2026 +0530 net: qrtr: Send HELLO message on endpoint register HELLO is currently handled entirely by the name server (NS): it is sent once as a broadcast when the NS initializes, and again as a reply whenever the NS receives an inbound HELLO from a remote. Some remote QRTR endpoints (e.g. an external WLAN chipset attached over MHI) operate in a slave role: they only ever send a HELLO in response to one they receive, and never initiate. Since the host cannot tell in advance which remotes behave this way, if the host also only replies, both sides wait on the other to speak first and no HELLO is ever exchanged, stalling further communication. To fix this: - Transfer HELLO handshake ownership to the core layer. A HELLO is now sent once, per endpoint, at registration time. - Schedule a delayed work item on endpoint registration to send a HELLO once the name server is bound. The work reschedules itself with a 100ms backoff if the name server socket is not yet bound or if allocating the control packet fails, so a transient startup condition does not abandon the handshake permanently. - Enforce HELLO-first ordering by dropping non-HELLO packets and returning -EAGAIN until the HELLO is confirmed sent, using bool hello_sent guarded by ep_lock to make the gate check atomic with xmit(). - Skip nodes with nid == QRTR_EP_NID_AUTO in bcast_enqueue(), to avoid broadcasting control packets with QRTR_EP_NID_AUTO as the destination node ID. - Remove say_hello() from the name server's ctrl_cmd_hello() handler and from qrtr_ns_init(); the core layer is now the sole sender of the outbound HELLO. This removes the NS's reply-on-receive behaviour without a replacement. Signed-off-by: Chris Lew Co-developed-by: Deepak Kumar Singh Signed-off-by: Deepak Kumar Singh Co-developed-by: Pranav Mahesh Phansalkar Signed-off-by: Pranav Mahesh Phansalkar Signed-off-by: David S. Miller commit 3b54dbd119805361695cb50ca6a875f4c7518b74 Author: Biju Das Date: Wed Aug 26 13:27:24 2026 +0100 power: sequencing: Fix build issue with COMPILE_TEST The POWER_SEQUENCING_TH1520_GPU driver depends on (ARCH_THEAD && AUXILIARY_BUS) || COMPILE_TEST. This means when COMPILE_TEST=y and ARCH_THEAD is not set, the driver can still be built even though it requires AUXILIARY_BUS, which may not be selected in that configuration, leading to a build failure. Fix this by dropping AUXILIARY_BUS from the dependency and instead selecting it directly, so the dependency is satisfied regardless of whether COMPILE_TEST or ARCH_THEAD is enabled. Fixes: 1a7312b93ab0 ("power: sequencing: extend build coverage with COMPILE_TEST=y") Signed-off-by: Biju Das Link: https://patch.msgid.link/20260826122742.153643-3-biju.das.jz@bp.renesas.com Signed-off-by: Bartosz Golaszewski commit dc173b37415e8f738fc4de477490056b479ddc9f Author: Alex Markuze Date: Thu Aug 27 15:16:21 2026 +0000 ceph: apply nearfull_sync option on remount ceph_parse_mount_param() stores nearfull_sync / nonearfull_sync on the temporary fs_context options, but ceph_reconfigure_fc() never copied CEPH_MOUNT_OPT_NEARFULL_SYNC onto the live mount. Remount therefore succeeded while writes and /proc/mounts kept the original-mount flag. Apply the flag the same way as ASYNC_DIROPS and SPARSEREAD so remount can enable or disable NEARFULL IOCB_DSYNC promotion. Fixes: c7a12c20bfba ("ceph: make nearfull sync writes opt-in") Signed-off-by: Alex Markuze Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov commit f75987e543c243e19f49fe32ce870b2e24ab8c23 Author: Tal Zussman Date: Tue Aug 25 11:41:38 2026 -0400 libceph: remove pinning assertion in ceph_msg_data_iter_next() ceph_msg_data_iter_next() gets a page reference from iov_iter_get_pages2() only to immediately drop it, asserting that the page is pinned some other way. The assertion is the last caller of PageWriteback() in the tree, blocking removal of the PG_writeback page flag accessors. Remove the assertion, as it is a CONFIG_DEBUG_VM-only check of an assumption the FIXME comment already documents. Converting to iov_iter_extract_pages() instead was considered, but the messenger never releases what it extracts, so it would still rely entirely on the caller holding the pages. That would be just as much of an abuse of the API, so leave it as-is for now. Signed-off-by: Tal Zussman Reviewed-by: Christoph Hellwig Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov commit a61c6ae1dae2611082b831b4aaa780878099c012 Author: Max Kellermann Date: Mon Aug 24 18:47:07 2026 +0200 ceph: lock mutex in ceph_mds_check_access() MDS session OPEN handling replaces mdsc->s_cap_auths under mdsc->mutex, freeing the previous array and its strings. ceph_mds_check_access() traverses this array without holding the mutex. A concurrent session reopen can therefore free the array while it is being inspected, resulting in a use-after-free like this: Unable to handle kernel paging request at virtual address 003aaad64b2c8bb9 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 56 UID: 2953037534 PID: 1253231 Comm: php-cgi8.4 Not tainted 6.18.45-i2-ampere #1146 NONE [..] pc : ceph_mds_check_access+0xd4/0x550 lr : ceph_mds_check_access+0xc8/0x550 [...] Call trace: ceph_mds_check_access+0xd4/0x550 (P) ceph_atomic_open+0x138/0xbe8 path_openat+0xa24/0xfa8 do_filp_open+0x94/0x158 do_sys_openat2+0x88/0xf8 Cc: stable@vger.kernel.org Fixes: 596afb0b8933 ("ceph: add ceph_mds_check_access() helper") Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit 560f4deda32785e260056200f8bb911c475c5b88 Author: John Ogness Date: Tue Sep 1 11:37:43 2026 +0206 printk/nbcon: Change nbcon_irq_work to IRQ_WORK_LAZY Change the nbcon_irq_work to be IRQ_WORK_LAZY, thus not raising an IRQ upon irq_work queuing. The irq_work is then handled on the next kernel tick. This additional delay is acceptable because nbcon_irq_work is only responsible for non-emergency deferred printing, which is delayed anyway. This has the benefit of not needing to raise an IRQ for each printk() call. On a side note, the Tegra20 and Tegra30 platforms can hang if an irq_work IRQ is raised while entering cpuidle states. This problem was reproducible by calling printk() while entering cpuidle. So this change also provides a workaround for these platforms (as long as they are not running tickless). Link: https://lore.kernel.org/lkml/f3757a75-0ba1-4558-bf57-f19ab7e59a4c@nvidia.com Fixes: 76f258bf3f2a ("printk: nbcon: Introduce printer kthreads") Signed-off-by: John Ogness Reviewed-by: Sebastian Andrzej Siewior Reviewed-by: Petr Mladek Tested-by: Jon Hunter Link: https://patch.msgid.link/20260901093245.344455-3-john.ogness@linutronix.de Signed-off-by: Petr Mladek commit 0433632bbe8d279e978f3f85212f36281a89946c Author: John Ogness Date: Tue Sep 1 11:37:42 2026 +0206 printk/nbcon: Flush nbcon_irq_work in nbcon_free() Ensure any pending nbcon_irq_work is flushed before allowing the console to be recycled. Signed-off-by: John Ogness Reviewed-by: Petr Mladek Link: https://patch.msgid.link/20260901093245.344455-2-john.ogness@linutronix.de Signed-off-by: Petr Mladek commit adeee7187694719890aaffdc14b7e89cfd736f1d Author: Qingyu Zhang Date: Wed Sep 2 15:39:18 2026 +0800 ALSA: ump: do not touch legacy_rmidi before it exists snd_ump_parse_endpoint() sets ump->parsed on every exit, including error, before the caller attaches the legacy rawmidi device. ump_handle_ep_name_msg() then treats parsed as "legacy_rmidi is live" and calls ump_legacy_set_rawmidi_name(), which snprintf()s into ump->legacy_rmidi->name. If a UMP packet arrives in that window (IRQ path from snd_ump_receive), legacy_rmidi is still NULL (KASAN null-ptr-deref in snprintf). Guard the legacy helpers. parsed only means endpoint info was parsed, not that legacy_rmidi exists. Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing") Signed-off-by: Qingyu Zhang Link: https://patch.msgid.link/20260902073918.880245-1-usupergate@gmail.com Signed-off-by: Takashi Iwai commit b5ec6c462aab1062cf5d1e667ba7c6442f737055 Author: Cen Zhang (Microsoft Security FORGE Labs) Date: Tue Sep 1 14:21:36 2026 -0400 ksmbd: fix tree connection use-after-free in smb2_tree_connect() ksmbd_tree_conn_connect() publishes a new tree connection in sess->tree_conns with a single reference and returns its pointer to smb2_tree_connect(). The handler continues to initialize the object and build the response after publication. A concurrent session logoff can erase the connection and drop that reference, freeing the object while the handler still uses it. BUG: KASAN: slab-use-after-free in smb2_tree_connect+0xe3d/0xf90 smb2_tree_connect (fs/smb/server/smb2pdu.c:2872) handle_ksmbd_work process_one_work worker_thread kthread After xa_store() succeeds, take a second reference before releasing tree_conns_lock. The original reference belongs to the xarray entry and the second belongs to the creating smb2_tree_connect() handler. Keep the references balanced in every path: - On normal exit or an error after publication, smb2_tree_connect() drops its creator reference. Error cleanup also calls ksmbd_tree_conn_disconnect(), which drops the xarray reference only if it removes the exact entry. - SMB2 TREE_DISCONNECT uses the same helper to remove the entry and drop its xarray reference. The request's existing lookup reference remains owned by the request and is released by the existing cleanup. - Session LOGOFF removes each entry and drops its xarray reference. If it wins the race, later cleanup sees that the entry is gone and does not drop that reference again. To enforce this ownership, claim the disconnected state and erase the exact entry atomically under tree_conns_lock. This guarantees one drop for the xarray reference and one drop by each in-flight user, regardless of which teardown path wins. If logoff removes the entry before initialization completes, fail the connect instead of marking the detached object TREE_CONNECTED. Fixes: 33b235a6e6eb ("ksmbd: fix race condition between tree conn lookup and disconnect") Reported-by: Xiang Mei (Microsoft) Cc: AutonomousCodeSecurity@microsoft.com Cc: stable@vger.kernel.org Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) Signed-off-by: Namjae Jeon commit 0480cee8cc3cc906124d398a9779eda144de6b41 Author: Alon Shakevsky Date: Tue Sep 1 00:05:31 2026 +0000 ksmbd: validate COPYCHUNK source and target ranges ksmbd_vfs_copy_file_ranges() rejects negative source offsets in the copy loop, but it does not validate target offsets. It also calculates lock and overlap endpoints before ensuring that either range fits within MAX_LFS_FILESIZE. When the target is an alternate data stream, the buffered path passes a negative target offset to ksmbd_vfs_stream_write(). Let n be Length and let -d be TargetOffset, where 0 < d < n <= XATTR_SIZE_MAX. For an empty stream, the writer allocates n - d bytes, then copies n bytes starting d bytes before the allocation. An authenticated SMB client can control d and the source data, overwrite kernel heap memory, and crash the host. Validate both ranges before lock, overlap, or I/O calculations. Fixes: 8482150a0743 ("ksmbd: support copychunk for alternate data streams") Assisted-by: Antiproof:GPT-5.6-Sol Signed-off-by: Alon Shakevsky Signed-off-by: Namjae Jeon commit 0e753899627b5e28a9fea8bca98262a6f65a2452 Author: Abdifatah Suruur Date: Sat Aug 29 18:40:22 2026 +0300 ksmbd: fix use-after-free in oplock break notification smb2_oplock_break_noti() reads opinfo->conn without any lock and dereferences it after two allocations which may sleep. When the durable handle owning the oplock is disconnected, session_fd_check() clears opinfo->conn and drops its conn reference under ci->m_lock, and the last ksmbd_conn_put() frees the connection. A break triggered by another connection that races with the teardown can then resurrect the freed connection: ksmbd_conn_get() is a plain atomic_inc, and the queued break work later dereferences the stale conn via ksmbd_conn_write(), a use-after-free reachable by any authenticated client holding a durable batch oplock. Thread the caller's inode into the notification path instead of taking a new reference on it. Every caller of oplock_break() already holds a live ksmbd_file (or an explicit ksmbd_inode_lookup_lock() reference, in the parent lease break paths) on the inode that owns the break target's oplock list, so ci cannot be freed during the call, and its lock can be taken without dereferencing opinfo->o_fp, which a concurrent close may free. Select and pin the connection under ci->m_lock, the same lock session_fd_check() and ksmbd_reopen_durable_fd() use to update opinfo->conn, so a concurrent detach either loses the race to the clear or keeps the connection alive until the notification work releases it. Transfer the reference to the work item and release it on allocation failures. Fixes: b003086d7696 ("ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers") Cc: stable@vger.kernel.org Signed-off-by: Abdifatah Suruur Signed-off-by: Namjae Jeon commit 636abbe7a66d80e179011a31754d55001cd44f63 Author: Namjae Jeon Date: Wed Sep 2 13:23:52 2026 +0900 ksmbd: fix sparc build with atomic work state Use an unsigned int for the work state so xchg() uses a supported 4-byte operation on sparc. Fixes: d12168084c8c ("ksmbd: safely drain sessions during logoff") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609021157.8f7Wx34I-lkp@intel.com/ Signed-off-by: Namjae Jeon commit f695390ea63941a9e412bf1f3afe65ab245fc681 Author: Sunil Goutham Date: Fri Aug 28 14:49:45 2026 +0530 octeontx2-af: Fix limiting SRIOV VF count logic When RVU PF0/AF's VFs are SDP instead of LBK, limiting the VF count based on the LBK channel count is incorrect. Apply LBK channel-based VF limits only when the VF device ID matches the LBK RVU AFVF device. Fixes: 9bd6caf33567 ("octeontx2-af: Enable sriov on AF to create VFs") Signed-off-by: Sunil Goutham Signed-off-by: Nitin Shetty J Signed-off-by: David S. Miller commit 979d5b8de8ed4e1f997aef12da5694b99be7b871 Author: David Carlier Date: Thu Jul 9 23:18:58 2026 +0100 ieee802154: hwsim: serialize pib updates to fix double-free hwsim_update_pib() does an unserialized read-swap-free of phy->pib: pib_old = rtnl_dereference(phy->pib); ... rcu_assign_pointer(phy->pib, pib); kfree_rcu(pib_old, rcu); It assumes the RTNL is held, but ->set_channel is not always called under it: the mac802154 scan worker changes channels via drv_set_channel() without the RTNL. Such an update can race an RTNL-held one on the same phy; both read the same pib_old and both kfree_rcu() it, double-freeing the object. With SLUB percpu sheaves batching kfree_rcu(), this surfaces as a KASAN invalid-free in rcu_free_sheaf(). struct hwsim_phy has no lock for pib. Add one and make the swap atomic with rcu_replace_pointer() under it, dropping the misleading rtnl_dereference(). Reported-by: syzbot+60332fd095f8bb2946ad@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=60332fd095f8bb2946ad Fixes: f25da51fdc38 ("ieee802154: hwsim: add replacement for fakelb") Signed-off-by: David Carlier Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20260709221858.158063-1-devnexen@gmail.com Signed-off-by: Stefan Schmidt commit bf79662bc85e820ac3b846e2f347da29fbf6ac95 Author: Zhiling Zou Date: Sat Aug 29 18:07:23 2026 +0800 ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type. Fixes: 51e0e5d8124e ("ieee802154: 6lowpan: remove multiple lowpan per wpan support") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Link: https://lore.kernel.org/0b715da69bd15a86ddc47dad5cf12da648211050.1787997209.git.zhilinz@nebusec.ai Signed-off-by: Stefan Schmidt commit ff5891b266a7fc6a062710836be84f1cc19338b5 Author: Fan Wu Date: Wed Aug 12 06:17:14 2026 +0000 ieee802154: cc2520: fix FIFOP work use-after-free The FIFOP interrupt handler queues cc2520_fifop_irqwork. On removal, cc2520_remove() only flushes the work. The devm-managed FIFOP IRQ remains active until after ->remove() returns and can queue the work again after that flush, allowing it to run after the private data is released. Disable the work with disable_work_sync() instead of flushing it, so the handler can no longer queue it once removal begins. Destroy the buffer mutex last, since the worker and the stop callback invoked through ieee802154_unregister_hw() both take it. Found by an in-house static analysis tool. Fixes: 0da6bc8cc341 ("ieee802154: cc2520: adds driver for TI CC2520 radio") Cc: stable@vger.kernel.org # v6.10+ Suggested-by: Miquel Raynal Reviewed-by: Miquel Raynal Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://lore.kernel.org/20260812061714.175966-1-fanwu01@zju.edu.cn Signed-off-by: Stefan Schmidt commit 02c6be7d675b21d81f0ba3a524346850a8c0e3bf Author: Eric Dumazet Date: Mon Aug 24 15:51:29 2026 +0000 locking/lockdep: Invalidate stale class_cache entries for zapped classes syzbot reported a lockdep splat hitting DEBUG_LOCKS_WARN_ON(1) in hlock_class() due to an invalid class_idx: WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203 Workqueue: wg-crypt-wg0 wg_packet_tx_worker RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4870 [inline] RIP: 0010:__lock_acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203 Call Trace: lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5886 _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:173 tcp_tsq_handler+0x29/0x200 net/ipv4/tcp_output.c:1291 tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325 ... When a lock class is zapped (e.g. during module unload or key unregistration), zap_class() clears the class's bit in lock_classes_in_use and removes it from the class hash table. However, existing lockdep_map instances embedded in data structures may still retain a pointer to the zapped class in their class_cache[] array. When __lock_acquire() subsequently runs on such a lock, it finds lock->class_cache[subclass] != NULL, skipping register_lock_class() and assigning hlock->class_idx to the index of the zapped class. When check_wait_context() or hlock_class() inspects the held_lock, it finds !test_bit(class_idx, lock_classes_in_use) and warns. Furthermore, if the zapped slot is subsequently re-allocated to an unrelated lock key, the stale class_cache entry would erroneously match the unrelated class (ABA issue). Add lock_class_cache_is_valid() to validate that the cached class is within lock_classes bounds, still allocated in lock_classes_in_use (using uninstrumented arch_test_bit() in __always_inline context so it is safe in noinstr contexts like match_held_lock()), and that class->key matches the expected subkey (taking lockdep_set_subclass() overrides into account). Also use READ_ONCE()/WRITE_ONCE() when accessing class_cache[]. If the entry is invalid or stale, fall back to register_lock_class() / look_up_lock_class(). Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in use") Closes: https://lore.kernel.org/netdev/6a8c66dc.4d75e56a.c9a88.0050.GAE@google.com/T/#u Reported-by: syzbot+2d770620059281e225a4@syzkaller.appspotmail.com Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Eric Dumazet Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260824155129.676096-1-edumazet@google.com commit 58a8108bc73de0740d5b88150465d6690ea5f85f Author: Yilin Zhang Date: Tue Sep 1 00:21:55 2026 +0800 perf: Fix use-after-free when perf mmap() revival races with the last munmap() perf_mmap_close() drops rb->mmap_count *without* holding event->mmap_mutex (the refcount_dec_and_test() right before the refcount_dec_and_mutex_lock() of event->mmap_count). A concurrent perf_mmap_rb() can slot its entire "revival" path into that window (perf_mmap holds event->mmap_mutex for its whole duration, including rb_alloc): munmap side (perf_mmap_close) mmap side (perf_mmap_rb) ----------------------------------- -------------------------------- rb->mmap_count 1 -> 0 (no lock) (holds event->mmap_mutex) inc_not_zero(rb->mmap_count) fails ring_buffer_attach(event, NULL) rb_alloc() + attach new rb refcount_set(&event->mmap_count, 1) lock; event->mmap_count 1 -> 0 ring_buffer_attach(event, NULL) ring_buffer_put() -> frees the *new* rb The revival's refcount_set(&event->mmap_count, 1) is an invisible 1 -> 1 write: the close frees the just-revived buffer although the other process still has it mapped -- a page-level use-after-free allowing local privilege escalation to root by any unprivileged user (default kernel.perf_event_paranoid=2). Swap the order of the two counter updates: event->mmap_count is dropped first via refcount_dec_and_mutex_lock(), so its 1 -> 0 transition and the ring_buffer_attach() stay serialized with perf_mmap(). rb->mmap_count == 0 then implies every event using the buffer is detached already, so the result of the rb->mmap_count drop can gate the remaining teardown directly and detach_rest is no longer needed. An earlier fix for this race from Kyle Zeng and David Lee takes event->mmap_mutex around both counter updates [0]; here the not-last close stays lockless. Fixes: 59741451b49c ("perf: Identify the 0->1 transition for event::mmap_count") Reported-by: Kimi Security Team Suggested-by: Peter Zijlstra Co-developed-by: Weiming Shi Signed-off-by: Weiming Shi Signed-off-by: Yilin Zhang Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/linux-perf-users/20260804060931.711308-1-david.lee@trailofbits.com/ [0] Cc: Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260831162155.1437652-1-yilinzhang@moonshot.ai commit 8a7f5b5e860b5c113ca99acd5b1e9074f5c5af3c Author: Leo Yan Date: Tue Aug 25 11:37:06 2026 +0100 perf/core: Skip empty AUX records with only format flags perf_aux_output_end() emits a PERF_RECORD_AUX when the recorded size is nonzero or when any flag other than PERF_AUX_FLAG_OVERWRITE is set. PMU format flags describe how an AUX payload is encoded. TRBE driver sets PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW for raw trace buffers, causing an AUX record to be emitted even when no trace data. This is noticeable when tracing a task with strace. Ptrace stops repeatedly end empty AUX transactions, producing many zero-sized PERF_RECORD_AUX records. For example: perf record -e cs_etm//u -m,128M -- strace ls perf script -D 2>&1 | awk '/PERF_RECORD_AUX offset/ { for (i = 1; i <= NF; i++) if ($i == "size:" && $(i + 1) == "0") count++ } END { print count }' 165 This recording contains 165 zero-sized AUX records which provide no useful information to userspace. Ignore PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK, together with PERF_AUX_FLAG_OVERWRITE, when deciding whether an empty AUX record is useful. Zero-sized records carrying TRUNCATED, PARTIAL or COLLISION are still emitted. Fixes: 547b60988e63 ("perf: aux: Add flags for the buffer format") Reported-by: Tamas Petz Signed-off-by: Leo Yan Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260825-perf_core_fix_zero_aux_records-v1-1-23b95e8d5df3@arm.com commit f0d243a96f2684ad771d678767d17972cf840bd7 Author: Tim Chen Date: Mon Aug 31 10:40:53 2026 -0700 sched/fair: Avoid creating misfits during cache-aware balancing Cache-aware load balancing biases tasks toward their preferred LLC. On asymmetric CPU capacity systems (e.g. big.LITTLE) the destination LLC may contain CPUs that are too small to run the task. Pulling the task there turns it into a misfit, trading a cache-locality gain for a capacity loss that's more detrimental to performance. Guard both cache-aware migration entry points against this: - can_migrate_llc_task(): forbid the LLC migration when the task fits its source CPU but would not fit the destination CPU. - alb_break_llc(): veto the active balance under the same condition so the runnable task is not pushed onto a CPU that cannot accommodate it. Both checks are gated with checks for hybrid processors, so symmetric systems are unaffected. Tasks that already do not fit their source CPU are left to the existing LLC policy, since the move cannot make their fitness worse (this also preserves misfit up-migration to bigger CPUs). Additionally, if there are misfit tasks found in the load balancing classification phase, prioritize misfit task migrations over LLC load aggregation on asymmetric systems. A better fitting CPU will boost performance more than better cache locality. Reviewed-by: Ricardo Neri Tested-by: Ricardo Neri Reviewed-by: Chen Yu Signed-off-by: Tim Chen Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/edbb2503d554c63dc9b72e201fb4a17e1cb119e7.camel@linux.intel.com commit eaece4849991d62fcd6f46637c55dcce00e25d70 Author: Mario Limonciello Date: Mon Aug 31 00:38:33 2026 -0500 x86/itmt: Don't make ITMT enablement depend on debugfs sched_set_itmt_support() treats debugfs file creation failures as fatal. When CONFIG_DEBUG_FS is disabled, debugfs stubs return ERR_PTR(-ENODEV), causing ITMT to be silently disabled. debugfs is a debug-only facility; its return values should be ignored. Drop the fatal error handling and enable ITMT unconditionally. Fixes: d04013a4b21b ("x86/itmt: Move the "sched_itmt_enabled" sysctl to debugfs") Reported-by: Klaus Kusche Signed-off-by: Mario Limonciello Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Tim Chen Reviewed-by: K Prateek Nayak Tested-by: K Prateek Nayak Link: https://patch.msgid.link/20260831053836.1881864-1-mario.limonciello@amd.com commit b038383526d8c7883ea0486dd1911102b6dda414 Author: Wanwu Li Date: Mon Aug 31 18:11:41 2026 +0800 sched/fair: Use cfs_rq->h_curr in distribute_cfs_runtime() distribute_cfs_runtime() refreshes the rq clock and accounts elapsed runtime with update_curr() before redistributing bandwidth, but gates this on cfs_rq->curr. Since commit 85570f10a4c6 ("sched/eevdf: Move to a single runqueue") cfs_rq->curr is only maintained on the root cfs_rq, so for the cgroup cfs_rqs it walks, the check never fires and the refresh is dead code. Use cfs_rq->h_curr, the per-level current entity, restoring the intended behaviour: only refresh when something is actually running at the throttled level, i.e. within the deferred throttle window. Without this, runtime consumed by a still-running task of the throttled hierarchy is not docked before redistribution; unthrottle_cfs_rq() catches up unconditionally since commit 28ad5427682b ("sched/fair: Call update_curr() before unthrottling the hierarchy"), so this is not a correctness hole today, but the refresh the check was written for is gone. Fixes: 85570f10a4c6 ("sched/eevdf: Move to a single runqueue") Signed-off-by: Wanwu Li Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Aaron Lu Tested-by: Aaron Lu Link: https://patch.msgid.link/20260831101141.391382-3-liwanwu@kylinos.cn commit f8610c57f4078c63d1d4e2f3d7134f3dc1768403 Author: Wanwu Li Date: Mon Aug 31 18:11:40 2026 +0800 sched/fair: Use cfs_rq->h_curr in throttle_cfs_rq() After commit 85570f10a4c6 ("sched/eevdf: Move to a single runqueue"), cfs_rq->curr is only maintained on the root cfs_rq (set/cleared from set_next_task_fair()/put_prev_task_fair()), while cfs_rq->h_curr is the per-level current entity, set by set_next_entity() at every level of the hierarchy. For an intermediate cfs_rq (a cgroup), cfs_rq->curr is always NULL, but cfs_rq->h_curr is the group entity at that level. throttle_cfs_rq() reads cfs_rq->curr to decide whether there is a running entity at the throttled level, in which case it should request a full sched_cfs_bandwidth_slice() of runtime and arm the deferred throttle task_work via task_throttle_setup_work(). For intermediate cfs_rqs the check is always false, so bandwidth-controlled cgroups always get just 1ns of runtime and never arm the deferred throttle work; the running task then escapes throttling until the next pick arms the work instead, even though there is an on-rq entity at this level. Switch the read to cfs_rq->h_curr so intermediate bandwidth-controlled cgroups behave consistently with the root cfs_rq, matching the existing usage of cfs_rq->h_curr in update_curr() and check_enqueue_throttle(). Fixes: 85570f10a4c6 ("sched/eevdf: Move to a single runqueue") Signed-off-by: Wanwu Li Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Aaron Lu Tested-by: Aaron Lu Link: https://patch.msgid.link/20260831101141.391382-2-liwanwu@kylinos.cn commit c6dcd97c8be75f052a1ca52cf79b03e7292962f1 Author: Shubhang Kaushik (Ampere) Date: Fri Aug 7 13:38:52 2026 -0700 sched/core: Skip rq->avg_idle update without a valid idle_stamp Commit 4b603f1551a73 ("sched: Update rq->avg_idle when a task is moved to an idle CPU") moved rq->avg_idle accounting out of the wakeup path and into put_prev_task_idle(), so that the idle interval is consumed whenever the idle task is switched out. The wakeup-side accounting that it replaced only updated rq->avg_idle when rq->idle_stamp was non-zero. The new helper lost that validity check and unconditionally computes: rq_clock(rq) - rq->idle_stamp If rq->idle_stamp is zero, this uses rq_clock(rq) as the sample. That is not a valid idle duration and can immediately drive rq->avg_idle to its clamp. This can happen when sched_balance_newidle() returns before setting rq->idle_stamp, for example when this_rq->ttwu_pending is set. In that case the rq can switch to the idle task with idle_stamp still zero and leave idle again when the pending wakeup is processed. Other paths can also switch to the idle task without setting rq->idle_stamp via newidle_balance(), for example find_proxy_task() or force-idling. Restore the idle_stamp validity check in update_rq_avg_idle() and skip the rq->avg_idle update when there is no measured idle interval. Fixes: 4b603f1551a73 ("sched: Update rq->avg_idle when a task is moved to an idle CPU") Signed-off-by: Shubhang Kaushik (Ampere) Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: K Prateek Nayak Reviewed-by: Vincent Guittot Acked-by: John Stultz Link: https://patch.msgid.link/20260807-master-v3-1-c328354efed3@gentwo.org commit dae5c0292080dd7b9c7d784268dcf443f1f3d15e Author: Seiji Nishikawa Date: Sun Aug 30 16:37:46 2026 +0900 sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate A migrate_disable()'d RT task cannot be moved to another CPU, but the scheduler still keeps such a task on that CPU's pushable list (rq->rt.pushable_tasks) and still marks the runqueue RT-overloaded (rq->rt.overloaded = 1). So the RT balancer keeps treating this CPU as having a task to move away, and keeps trying to move the task, but the push can never succeed. When the head is pinned, push_rt_task() does not give up either. It falls back to pushing rq->curr instead, using the per-CPU stopper, as added by commit a7c81556ec4d ("sched: Fix migrate_disable() vs rt/dl balancing"). The CPU spends tens of milliseconds in this retry loop. The core is isolated for real-time work, but during the loop nearly half of its time is consumed by pushes that cannot succeed. An ftrace capture of the affected CPU, with sched_switch enabled and commit 94894c9c477e ("sched/rt: Skip currently executing CPU in rto_next_cpu()") applied, shows where the CPU time went. Two SCHED_FIFO tasks at equal priority shared the CPU, taskA migrate_disable()'d and queued, taskB as rq->curr. In one 89 ms window, taskB got only 52 ms of CPU. The other 37 ms went to the stopper thread. The scheduler kept trying to push taskA, the pinned head of the pushable list, fell back to pushing taskB instead, and woke the stopper 5204 times. Every one of those pushes failed and no task was moved. taskA stayed runnable and queued the whole time, and never ran. Pushing taskB fails on a re-check. find_lock_lowest_rq() drops the rq lock to take the target rq lock, then checks again with "task != pick_next_pushable_task(rq)". The task being pushed is taskB, but the pick returns taskA, the head of the pushable list. taskB is rq->curr, and set_next_task_rt() removes the running task from that list, so taskB can never be the head. The check expects a candidate taken from the pushable list, but the fallback pushes rq->curr, which is never on that list. So the check fails every time. .--> push-IPI arrives | | | v | pushable head = taskA -> pinned, cannot be pushed | | | v | so push taskB instead -> wake migration/N, a stop-class | | thread, so it preempts taskB | v | re-check compares taskB against the pushable head, | which is still taskA -> give up | | | v | nothing moved, taskA still queued, rq still overloaded | | '----------' repeats every ~17 us, 5204 times, for 89 ms The loop cannot stop itself. Every round leaves the runqueue exactly as it was, so the next push-IPI does the same thing. In the capture it ended only when taskB went to sleep on its own. taskA was then picked locally and left the pushable list. CPU time per task in the window, from sched_switch: taskB 51.95 ms real work migration/N 37.18 ms nothing moved taskA 0.00 ms queued the whole time, never picked idle 0.01 ms Counts over the same window: 7667 push-IPIs handled on this CPU 17481 pick_next_pushable_task() returned taskA, still pinned 5204 find_lock_lowest_rq() gave up on the re-check 1 push that actually completed 0 migrations of taskA The CPU times and the window length come from the standard sched_switch tracepoint. The counts needed tracepoints added inside the RT balancer for this investigation. The self-IPI path is closed by the rto_next_cpu() fix above, and that part works. But the runqueue is still marked overloaded, because the pinned task is still advertised as pushable. Other CPUs now send the push-IPIs during their own RT balancing, and the same loop runs again. Closing the self-IPI path did not stop a pinned task from triggering push balancing. A pinned task should never have been returned as a push candidate in the first place. A migrate_disable()'d task cannot be migrated, so it belongs in the same skip that was added for on_cpu tasks by commit e0ca8991b2de ("sched: Make class_schedulers avoid pushing current, and get rid of proxy_tag_curr()"). Add is_migration_disabled() to the skip condition in pick_next_pushable_task() and pick_next_pushable_dl_task(). With the skip in place, if the pinned task is the only extra runnable task the helpers return NULL, push_rt_task() and push_dl_task() give up early, and no stopper is woken. The pinned task then runs locally once curr yields. If a task that really can be migrated is queued behind the pinned head, it is now picked and pushed for real. This makes the fallback that pushes rq->curr unreachable when the pushable head is migrate-disabled. Nothing is lost, because that path was always stopped by the re-check described above. In the capture it ran 5204 times and moved nothing. Fixes: a7c81556ec4d ("sched: Fix migrate_disable() vs rt/dl balancing") Signed-off-by: Seiji Nishikawa Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260830073746.2189355-1-snishika@redhat.com commit 1719d035a6fa90b7467b6daf45a573f5180013b2 Author: Zhan Xusheng Date: Sat Aug 22 18:59:30 2026 +0800 sched/fair: Use update_curr_eevdf() for the remaining root cfs_rq callers pick_task_fair() and yield_task_fair() call update_curr(&rq->cfs) to bring curr up to date before they look at the eevdf state. With cgroups that does not happen: update_curr() reads ->h_curr, which on the root cfs_rq is the top level group entity, and returns at the !entity_is_task() check before touching vruntime. Both then read ->curr, so the guard and the update disagree about which entity they mean. Counting how often ->h_curr and ->curr differ at pick_task_fair(), on one CPU for 10s with three busy tasks and one 200us-periodic task: all tasks in the root cgroup 43321 calls, 0 no-ops busy tasks in G0, periodic in G1 45211 calls, 45193 no-ops Whether that matters depends on what precedes the pick. Since commit 68e37487810a ("sched/fair: Fix flat hierarchy") the tick and enqueue/dequeue all update curr correctly, so on the normal reschedule path only the microseconds between those and the pick are missing, and I could not measure a latency difference there. Three paths have nothing before them on that rq though: - pick_task() on the sibling rqs of a core under core scheduling (kernel/sched/core.c), which updates that rq's clock first for exactly this reason - fair_server_pick_task() - yield_task_fair(), where the stale value feeds the entity_eligible() test that guards forfeiting the remaining vruntime There curr can be a full tick behind, as it was before that commit. No new behaviour for the entity being updated: without cgroups ->h_curr is already the task, so these two call sites already run the full update_curr() including update_deadline(), dl_server_update() and the resched_curr_lazy() at the end. This makes the cgroup case do the same. Fixes: 85570f10a4c6 ("sched/eevdf: Move to a single runqueue") Signed-off-by: Zhan Xusheng Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Link: https://patch.msgid.link/20260822105930.2352761-1-zhanxusheng1024@gmail.com commit 4310c6b8e75d6a47f7548e5948fbe6318aa4440a Author: Fedor Pchelkin Date: Mon Aug 31 10:58:09 2026 +0300 thunderbolt: Fix NULL dereference in tb_remove_work() There is a slight race between tb_remove_work() and tb_domain_remove() which leads to dereferencing a NULL tb->root_switch pointer inside tb_free_unplugged_xdomains(): Thread A Thread B tb_remove_work() tb_domain_remove() mutex_lock(&tb->lock) tb_stop() /* doesn't cancel a running callback */ cancel_delayed_work(&tcm->remove_work) ... tb_switch_remove(tb->root_switch) tb->root_switch = NULL mutex_unlock(&tb->lock) mutex_lock(&tb->lock) ... /* without checking ->root_switch */ tb_free_unplugged_xdomains(tb->root_switch) mutex_unlock(&tb->lock) Commit a8937f35cf39 ("thunderbolt: Remove XDomain from the bus without holding tb->lock") doesn't seem right to move tb_free_unplugged_xdomains() out of the &tb->lock section and the check for tb->root_switch, in particular. It states: For this reason separate removing the XDomain from the topology data structures (where we need the lock) from unregistering the device from the bus (where remove callbacks of the drivers are being called). tb_free_unplugged_xdomains() belongs to the former group of functions requiring the lock. And it also calls tb_xdomain_remove() which should only be called with &tb->lock held. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: a8937f35cf39 ("thunderbolt: Remove XDomain from the bus without holding tb->lock") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Signed-off-by: Mika Westerberg commit 29871903f3a38e75e896f9a644713859490cb85f Author: Tao Cui Date: Tue Sep 1 20:43:47 2026 +0800 sched_ext: Don't deliver duplicate ops.cgroup_set_idle() for same value ops.cgroup_set_idle() is documented to be invoked when a cgroup transitions between idle and non-idle states, and scx_group_set_weight() already skips value-preserving writes. scx_group_set_idle() delivers every write unconditionally, so rewriting an already-correct cpu.idle value feeds the BPF scheduler a transition callback each time, which toggle- or accounting-based schedulers miscount. Mirror the weight guard and only deliver on an actual change. Verified with a probe scheduler printing each callback: rewriting cpu.idle=1 twice on an already-idle cgroup delivered two callbacks before and none after. Fixes: 347ed2d566da ("sched/ext: Implement cgroup_set_idle() callback") Link: https://lore.kernel.org/r/b53c61a1-4d7d-4232-941f-d48b0563d4ed@linux.dev Signed-off-by: Tao Cui Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo commit 9012da455ab9a05d8205b90d0ad7c8b526f89062 Author: Chenguang Zhao Date: Thu Aug 6 17:10:45 2026 +0800 net: 6lowpan: fix mismatched comments Rename @_nexthdrlen to @_hdrlen and drop stale @nhc from lowpan_nhc_do_uncompression docs Signed-off-by: Chenguang Zhao Reviewed-by: Simon Horman Link: https://lore.kernel.org/20260806091045.1701326-1-chenguang.zhao@linux.dev Signed-off-by: Stefan Schmidt commit 82cfab6a52621febf36752bd5ed5184f82c96e07 Author: Jonne Vuorela Date: Tue Sep 1 18:28:27 2026 +0000 ALSA: hda/cs420x: Add CS4208 fixup for MacBookAir 7,2 The MacBookAir 7,2 HDA controller has PCI subsystem 8086:7270 rather than Apple 0x106b, so no fixup is selected and all pins default to 0x400000f0. The pin wiring matches MBA6, so add the subsystem ID to both lookup tables pointing to CS4208_MBA6. Tested on MacBookAir 7,2. [ sorted table entries in SSID order -- tiwai ] Signed-off-by: Jonne Vuorela Link: https://patch.msgid.link/Qcui5livawCaJbO1jfx_jebS64rR0f9KATkqn8May0pPyLw8U5DqPQBigmSzRxJp-GeMPqs-jAK6PCnagk3bspzmH__YPte-eyvPtFtuolo=@proton.me Signed-off-by: Takashi Iwai commit dc3565a4ae538e584e5e63b3b3cd1eaf502593c1 Author: Hajo Noerenberg Date: Mon Aug 31 14:43:03 2026 +0200 ata: ahci: work around lost interrupts on Marvell 88SE61xx ahci_single_level_irq_intr() services the ports first and clears the global HOST_IRQ_STAT afterwards, as recommended by AHCI 1.1 section 10.6.2. The Marvell 88SE6111/6121/6145 family stops reporting interrupts for a port when HOST_IRQ_STAT is cleared while PxIS still holds bits: PxIS keeps its content, HOST_IRQ_STAT reads back as 0, the port is never looked at again, and the command in flight only ends in a timeout. Measured on a Seagate Blackarmor NAS440 (Marvell 88F6281 Kirkwood, 88SE6121 rev B2 behind PCIe) by polling the AHCI registers from userspace while an IDENTIFY was outstanding: t=303.046 irqs 127 PxIS 0x00000000 PxCI 0x00000001 IDENTIFY issued t=303.057 irqs 128 PxIS 0x00000020 PxCI 0x00000000 CI cleared, DPS set, one interrupt taken ... PxIS stays 0x00000020, HOST_IRQ_STAT stays 0 ... t~308.05 qc timeout after 5000 msecs The command had completed - PxCI was clear and PxIS had DPS set - so ahci_qc_complete() would have completed it. It never got the chance because the handler read HOST_IRQ_STAT as 0 and returned IRQ_NONE. Marvell's own driver for these chips clears the two registers in the opposite order and says so ("clear global before channel"), and ahci_xgene handles its broken edge latch the same way. Since the reordering costs at most one spurious interrupt per valid one on conforming controllers, do it in a private interrupt handler selected for board_ahci_mv instead of changing libahci for everyone. With this applied, SATA-2 and SATA-3 disks work at 3.0 Gbps on the 88SE6121 without the drive-side 1.5 Gbps jumper that was needed before. Time from link up to a successful IDENTIFY: WDC WD5000AADS-00S9B0 port 0 7 ms (never identified before) WDC WD3202ABYS-01B7A0 port 1 28 ms WDC WD30EFRX-68EUZN0 port 1 200 ms (3 TB, HPA detection ok) Only the 88SE6121 was tested; board_ahci_mv also covers the 88SE6145, which Marvell's driver treats identically. Fixes: cd70c26617f4 ("[libata] AHCI: Add support for Marvell AHCI-like chips (initially 6145)") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-ide/db6b48b7-d69a-564b-24f0-75fbd6a9e543@noerenberg.de/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=216094 Signed-off-by: Hajo Noerenberg Reviewed-by: Damien Le Moal Acked-by: Pali Rohar Link: https://lore.kernel.org/r/20260831124303.920391-1-hajo-linux-ide@noerenberg.de Signed-off-by: Niklas Cassel commit 341b9b4f8f540fc03e928e67351e4be9461bc56d Author: Thorsten Blum Date: Tue Aug 25 18:49:27 2026 +0200 MAINTAINERS: mailmap: update entries for Thorsten Blum Map my previously used email addresses to blum@kernel.org. Link: https://lore.kernel.org/20260825164933.105605-2-blum@kernel.org Signed-off-by: Thorsten Blum Cc: Jakub Kacinski Cc: Martin Kepplinger Signed-off-by: Andrew Morton commit 627824f20f237902e696efe5b563c18422443370 Author: Lorenzo Stoakes (ARM) Date: Wed Aug 26 10:56:39 2026 +0100 MAINTAINERS: remove Lorenzo as THP co-maintainer Unfortunately my workload is such that I simply no longer have the time to give THP the focus that it deserves. So, at least temporarily, step down from the role. Link: https://lore.kernel.org/20260826-drop-thp-maintainership-v1-1-3d102748fa17@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Ryan Roberts Cc: Zi Yan Cc: Kiryl Shutsemau Signed-off-by: Andrew Morton commit 0ba6912f7e974045dcdd170f022cba19247e00bc Author: Eric Dumazet Date: Tue Aug 25 14:25:15 2026 +0000 Revert "once: don't use a work queue to reset sleepable static key" This reverts commit e8eef69a99f185e75909adb24ab93d706e07bf27. While DO_ONCE_SLEEPABLE() is used from sleepable/process context, callers may still be holding arbitrary subsystem locks. For instance, __inet_hash_connect() uses get_random_sleepable_once() which invokes DO_ONCE_SLEEPABLE() while holding the socket lock (sk_lock): lock_sock(sk) __inet_hash_connect() get_random_sleepable_once() DO_ONCE_SLEEPABLE() __do_once_sleepable_done() static_branch_disable() static_key_disable() cpus_read_lock() Calling static_branch_disable() directly from __do_once_sleepable_done() causes static_key_disable() to synchronously acquire cpus_read_lock() (cpu_hotplug_lock) and jump_label_mutex inside the caller's lock context. This introduces an unwanted lockdep dependency: sk_lock -> cpu_hotplug_lock Because cpu_hotplug_lock depends on fs_reclaim (via workqueue CPU bringup allocating memory with GFP_KERNEL), and storage/block layers (such as NVMe-TCP) acquire sk_lock during I/O dispatch, lockdep reports circular locking dependencies: set->srcu -> sk_lock -> cpu_hotplug_lock -> fs_reclaim -> q_usage_counter -> elevator_lock -> set->srcu This false positive previously prompted commit 19bdb70c77d3 ("nvme-tcp: lockdep: use dynamic lockdep keys per socket instance") to work around the warning using per-socket dynamic keys in NVMe-TCP. That in turn broke asynchronous socket teardown and caused syzbot warnings in tcp_tsq_handler(). Restoring once_disable_jump() in __do_once_sleepable_done() ensures that static_branch_disable() is executed asynchronously from a system workqueue without holding the caller's locks. Link: https://lore.kernel.org/20260825142515.1965654-1-edumazet@google.com Fixes: e8eef69a99f1 ("once: don't use a work queue to reset sleepable static key") Signed-off-by: Eric Dumazet Closes: https://lore.kernel.org/lkml/ao0mwtt8ePAINFni@shinhome/ Reported-by: Shin'ichiro Kawasaki Cc: Tony Luck Cc: Reinette Chatre Cc: Keith Busch Cc: Nilay Shroff Cc: Signed-off-by: Andrew Morton commit 8ee1ef0f2f8ce29338f4ab00a3d344c010208058 Author: Wupeng Ma Date: Tue Jul 7 19:02:54 2026 +0800 mm/hugetlb: fix missing migratable flag on same-node hugetlb migration Commit ba23f58de896 ("mm/migrate: don't call folio_putback_active_hugetlb() on dst hugetlb folio") moved setting of the migratable flag and active-list placement from folio_putback_active_hugetlb(dst) into move_hugetlb_state(), so that the freshly allocated destination folio is handled where allocation is known to have succeeded. Unfortunately, the new code was appended after the existing temporary-folio block in move_hugetlb_state(), which contains an early return added earlier by commit 5af1ab1d24e08 ("mm/hugetlb: optimize the surplus state transfer code in move_hugetlb_state()"): if (folio_test_hugetlb_temporary(new_folio)) { ... if (new_nid == old_nid) return; <-- skips the new code ... } /* added by ba23f58 */ folio_set_hugetlb_migratable(new_folio); list_move_tail(&new_folio->lru, ...&h->hugepage_activelist); When the destination folio is temporary (i.e. the hugetlb pool was exhausted and the migration callback fell back to alloc_migrate_hugetlb_folio()) and the migration does not cross a node -- the common case, and always true on a single-NUMA system -- move_hugetlb_state() returns before setting the migratable flag or adding the new folio to the active list. The destination folio is then installed in the page table but cannot be isolated afterwards, since folio_isolate_hugetlb() rejects folios without the migratable flag; a subsequent soft-offline, hard-offline or memory-hotplug offline of that folio fails with -EBUSY. This was reproduced on a single-NUMA arm64 VM: a second MADV_SOFT_OFFLINE on an already-migrated hugetlb page returned EBUSY and logged "hugepage isolation failed". Keep the surplus adjustment, which is the only part that depends on the node crossing, guarded by `if (new_nid != old_nid)', while making the migratable flag and active-list placement unconditional. This preserves the cleanup intent of ba23f58 and closes the early-return hole. Link: https://lore.kernel.org/20260707110254.3147686-1-mawupeng1@huawei.com Fixes: ba23f58de896 ("mm/migrate: don't call folio_putback_active_hugetlb() on dst hugetlb folio") Signed-off-by: Wupeng Ma Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Muchun Song Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton commit 540e583b66d6402bf556fde5e53c817a54c1afe5 Author: Eric Dumazet Date: Fri Aug 21 17:04:07 2026 +0000 mm/mempolicy: fix sleeping allocation in alloc_pages_bulk_weighted_interleave() syzbot reported a sleeping function called from invalid context splat in bucket_table_alloc(). When rhashtable_insert_slow() rehashes the table under rcu_read_lock(), it calls bucket_table_alloc(..., GFP_ATOMIC | __GFP_NOWARN). If the bucket table allocation uses vmalloc, __vmalloc_node_range_noprof() invokes vm_area_alloc_pages() -> alloc_pages_bulk_mempolicy_noprof() with the passed GFP_ATOMIC flags. If the current task has an MPOL_WEIGHTED_INTERLEAVE mempolicy, alloc_pages_bulk_weighted_interleave() is called and currently hardcodes GFP_KERNEL when allocating the temporary weights array, triggering a might_alloc() splat in atomic/RCU contexts. Pass the gfp flags (masked with GFP_RECLAIM_MASK to strip page-allocator zone modifiers like __GFP_HIGHMEM) received by alloc_pages_bulk_weighted_interleave() to kmalloc() instead of hardcoding GFP_KERNEL. Since the weights buffer is immediately initialized in full, kmalloc() is sufficient. Link: https://lore.kernel.org/20260821170407.3721004-1-edumazet@google.com Fixes: fa3bea4e1f82 ("mm/mempolicy: introduce MPOL_WEIGHTED_INTERLEAVE for weighted interleaving") Signed-off-by: Eric Dumazet Reported-by: syzbot+0dbf6d295b3350944f0b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/6a88837e.ae6ddae5.3da009.0040.GAE@google.com/T/#u Reviewed-by: Andrew Morton Reviewed-by: Gregory Price (Meta) Acked-by: David Hildenbrand (Arm) Cc: Alistair Popple Cc: Byungchul Park Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: Zi Yan Cc: Signed-off-by: Andrew Morton commit fe6cf984939d8e12cb33a99673c8d026c5135e68 Author: Usama Arif Date: Wed Aug 19 03:12:22 2026 -0700 mm/huge_memory: transfer the pmd dirty bit to the folio on zap zap_huge_pmd_folio() propagates the pmd young bit to the folio for the file case, but not the dirty bit. The pte path does propagate it, in zap_present_folio_ptes() and so does the pmd split path, in __split_huge_pmd_locked(). For most file mappings the omission is harmless, because writing to a shared file mapping goes through page_mkwrite(), which dirties the folio. tmpfs is different: it has no page_mkwrite(), and vma_wants_writenotify() is false for it, so a *read* fault on a MAP_SHARED tmpfs mapping installs a writable pmd via do_read_fault(). do_read_fault() does not call fault_dirty_shared_page(), so subsequent stores through that mapping set only the hardware dirty bit in the pmd and never call folio_mark_dirty(). A shmem folio allocated by a fault is marked uptodate but not dirty (see the clear: block in shmem_get_folio_gfp()), so PG_dirty is never set at all. Unmapping such a folio - munmap(), or exit_mmap() when the process dies - then loses the only record that it was written, because zap_huge_pmd() drops the pmd without transferring the dirty bit. Reclaim afterwards sees a clean shmem folio: the whole swap-out block in shrink_folio_list() is inside "if (folio_test_dirty(folio))", so pageout() is skipped and the folio falls into __remove_mapping(). There, folio_is_file_lru() is false for a swapbacked folio, so no shadow entry is created and __filemap_remove_folio(folio, NULL) simply empties the i_pages slot. The data is freed without ever being written to swap, and the next fault on that index returns a freshly zeroed folio. This is silent data loss for any process that keeps state in a MAP_SHARED tmpfs segment across an unmap - for example a cache handed from one process generation to the next through /dev/shm. It requires the folio to be PMD-mapped, so it only shows up once shmem THP is enabled (which is what we did in Meta fleet and started noticing crashes); with THP off the pte path transfers the dirty bit correctly. It also only becomes visible when swap is enabled, because with no swap device shmem folios (which are on the anon LRU) are not scanned by reclaim at all, so the clean folio is never dropped. Reproduced on x86_64 with a tmpfs mounted huge=within_size: read-fault a 2MB-backed region, write a known pattern through the resulting mapping, munmap, force reclaim of the cgroup, then re-map and read back. Without this patch the region reads back as zeros and vmstat shows zswpout 0 - the data was discarded rather than swapped. With this patch the region reads back correctly and the pages are swapped out as expected. With huge=never, or when the first touch is a write, the test passes either way. Link: https://lore.kernel.org/20260819101222.3732660-1-usama.arif@linux.dev Fixes: b5072380eb61 ("thp: support file pages in zap_huge_pmd()") Signed-off-by: Usama Arif Acked-by: David Hildenbrand (Arm) Reviewed-by: Kiryl Shutsemau Acked-by: Hugh Dickins Tested-by: Lance Yang Reviewed-by: Zi Yan Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Johannes Weiner Cc: Liam R. Howlett Cc: Nhat Pham Cc: Rik van Riel Cc: Ryan Roberts Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton commit 6e0803a170552a6ab48538721df6467582fc940c Author: Lance Yang Date: Thu Aug 20 09:45:35 2026 +0800 MAINTAINERS: add Lance Yang as a hung task detector co-maintainer I've been a hung_task reviewer for over a year now and plan to stay involved. Take on more responsibility for hung_task as a co-maintainer. Link: https://lore.kernel.org/20260820014535.79105-1-lance.yang@linux.dev Signed-off-by: Lance Yang Acked-by: Petr Mladek Cc: "Masami Hiramatsu (Google)" Signed-off-by: Andrew Morton commit f025ca73decda1f895a4b80b961d3bc88825298a Author: Bryan Lim Date: Wed Aug 19 10:08:24 2026 +0700 userfaultfd: reset err to be 0 when move_pages_ptes succeeded During move_pages() operation, when move_pages_ptes() returns EAGAIN, the error code is not cleared even after we processed it. This leads to a successful retry but then the same pages are retried again due to the stale error code. This time move fails because pages are already moved, loop is terminated and move_pages() reports a failure. Clear the error code once we processes EAGAIN. Link: https://lore.kernel.org/e1e0b5f8-c3c6-0537-670b-4397f822f980@gmail.com Fixes: 50944692052b ("userfaultfd: opportunistic TLB-flush batching for present pages in MOVE") Assisted-by: ChatGPT:GPT-5.6-Luna Signed-off-by: Bryan Lim Reviewed-by: Suren Baghdasaryan Acked-by: Mike Rapoport (Microsoft) Cc: Peter Xu Cc: Signed-off-by: Andrew Morton commit 2fd4e7693674b17807a6d082feb01a3fbf86f5f8 Author: Baolin Wang Date: Tue Aug 18 10:47:26 2026 +0800 mm: fix incorrect vm_flags usage when checking allowable orders for tmpfs Lance reported that when nothing else causes the mm to be considered for khugepaged collapse, an MADV_HUGEPAGE-advised tmpfs VMA alone does not trigger scanning. After commit 6beeab870e70 ("mm: shmem: move shmem_huge_global_enabled() into shmem_allowable_huge_orders()"), the shmem/tmpfs allowable order check reads vma->flags directly. However, when MADV_HUGEPAGE is handled, khugepaged_enter_vma() is called before the VMA's flags have been updated, so the check uses stale flags and incorrectly rejects the VMA for collapse. As a result, khugepaged does not collapse the tmpfs file into PMD order in time. Fix this by calling khugepaged_enter_vma() with the new VMA flags in madvise_update_vma(). Meanwhile we can remove the khugepaged_enter_vma() in hugepage_madvise(). Link: https://lore.kernel.org/7d5b5eb27be798f89d563b06254c947ff53db0b2.1787020910.git.baolin.wang@linux.alibaba.com Fixes: 6beeab870e70 ("mm: shmem: move shmem_huge_global_enabled() into shmem_allowable_huge_orders()") Signed-off-by: Baolin Wang Reported-by: Lance Yang Closes: https://lore.kernel.org/all/20260815181632.21453-1-lance.yang@linux.dev/ Suggested-by: Lorenzo Stoakes (ARM) Reviewed-by: Zi Yan Reviewed-by: Lorenzo Stoakes (ARM) Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Hugh Dickins Cc: Lance Yang Cc: Liam R. Howlett Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton commit 267bede12d3b108ca29997ce280e927a570ec97f Author: Longlong Xia Date: Fri Aug 14 16:30:27 2026 +0800 mm/hugetlb: keep max_huge_pages when dissolving surplus folios dissolve_free_hugetlb_folio() can remove a free folio as surplus when its node has surplus pages. In that case remove_hugetlb_folio() decrements both nr_huge_pages and surplus_huge_pages, leaving the persistent pool size unchanged. Updating max_huge_pages as if a persistent folio had been removed can therefore corrupt the persistent pool target and underflow it when max_huge_pages is zero. Keep max_huge_pages unchanged for surplus folios, including the vmemmap restoration rollback path. Link: https://lore.kernel.org/20260814083027.1419487-1-xialonglong2025@163.com Fixes: cb402bbdabca ("mm/hugetlb: fix surplus pages in dissolve_free_huge_page()") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Longlong Xia Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Jinjiang Tu Cc: Longlong Xia Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton commit dc41e961a269f2ca4196e669d6d8e05480899cd4 Author: Hui Su Date: Mon Aug 17 20:08:00 2026 +0800 mm/migrate_device: avoid out-of-bounds writes for compound folios migrate_device_range() and migrate_device_pfns() clear the entries following a compound folio so that the PFN arrays retain their page-granular representation. If a compound folio extends beyond the end of the caller-provided range, the loops clear all following folio entries without limiting them to the number of slots remaining in the npages-sized array, causing an out-of-bounds write. Do not proceed with a compound folio if its page-granular representation does not fit entirely in the remaining PFN array. If this happens, drop any reference and lock acquired for the folio, clear the remaining entries, and stop collecting. Observed with a KASAN x86 QEMU kernel using the HMM migrate_anon_huge_zero selftest. Closing /dev/hmm_dmirror0 after migrating an anonymous huge page to device memory exercises: dmirror_fops_release() -> dmirror_device_evict_chunk() -> migrate_device_range() Link: https://lore.kernel.org/20260817120758.669807-3-sh_def@163.com Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages") Signed-off-by: Hui Su Cc: Alistair Popple Cc: Balbir Singh Cc: Byungchul Park Cc: David Hildenbrand Cc: Gregory Price Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: Zi Yan Cc: Signed-off-by: Andrew Morton commit eedc8474d469a2e88f4dc61f8cfe05c147478b43 Author: Narek Jilavyan Date: Mon Aug 17 10:34:33 2026 +0000 mm/hugetlb_cgroup: call page_counter_set_max() outside VM_BUG_ON() hugetlb_cgroup_css_alloc() rounds the counter limit down to a multiple of the huge page size and then applies it inside an assertion: VM_BUG_ON(page_counter_set_max(fault, limit)); VM_BUG_ON(page_counter_set_max(rsvd, limit)); With CONFIG_DEBUG_VM=n, VM_BUG_ON(cond) is BUILD_BUG_ON_INVALID(cond), i.e. ((void)(sizeof((__force long)(cond)))), whose operand is never evaluated. page_counter_set_max() is not a predicate - it performs xchg(&counter->max, nr_pages) - so on every non-debug kernel the limit is never applied and the counters keep page_counter_init()'s PAGE_COUNTER_MAX. That is user-visible, because hugetlb_cgroup_read_u64_max() recomputes the same rounded value and uses equality as its "unlimited" sentinel. PAGE_COUNTER_MAX is LONG_MAX / PAGE_SIZE = 2251799813685247, which is odd, so round_down() really does change it and the two sides disagree. With CONFIG_DEBUG_VM=n: $ cat /sys/fs/cgroup/t/hugetlb.2MB.max 9223372036854771712 and with this patch: $ cat /sys/fs/cgroup/t/hugetlb.2MB.max max A debug option should not change cgroup output. Call the function, then assert the result, as v6.12 did. Use VM_WARN_ON_ONCE() rather than restoring VM_BUG_ON(): the two are identical under CONFIG_DEBUG_VM=n, and checkpatch asks that new code not use BUG() variants. Link: https://lore.kernel.org/20260817103433.191266-1-njilav@gmail.com Fixes: 0e2759afcaf9 ("page_counter: track failcnt only for legacy cgroups") Signed-off-by: Narek Jilavyan Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Oscar Salvador Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton commit a3417097fb107cea3358b19bcbb4eb655fd67f8c Author: Shakeel Butt Date: Tue Aug 11 13:31:55 2026 -0700 memcg: make the v1 soft limit knob inert The v1 soft limit has been deprecated since v6.12 and nobody has reported depending on it. Start the removal by decoupling the interface from the implementation: keep memory.soft_limit_in_bytes, but ignore writes to it and always report the maximum value on read similar to what memory.kmem.limit_in_bytes already does. Writes are still parsed, so malformed input keeps returning -EINVAL. The knob now also behaves the same everywhere: it used to return -EOPNOTSUPP on PREEMPT_RT, where soft limit reclaim has always been disabled. This also fixes the syzbot report linked below. Soft limit reclaim is the only caller that runs shrink_lruvec() from kswapd against a specific memcg, so it is the only way to reach lru_gen_shrink_lruvec() and in turn set_mm_walk(), which warns when called from kswapd. Link: https://lore.kernel.org/20260811203203.3456029-2-shakeel.butt@linux.dev Signed-off-by: Shakeel Butt Reported-by: syzbot+12ee2725d5fde63a9c96@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a7a6929.b50370da.49fe0.005e.GAE@google.com/ Acked-by: Michal Hocko Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Johannes Weiner Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton commit 7b8a8ae4dd176a232e973017d2aa3c536a7275e2 Author: Sourav Panda Date: Tue Aug 11 05:29:09 2026 +0000 mm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio alloc_buddy_hugetlb_folio_with_mpol() can pass a NULL nodemask to alloc_fresh_hugetlb_folio() as a fallback to allocate from all nodes. If order is gigantic, alloc_fresh_hugetlb_folio() propagates the NULL nodemask down to hugetlb_cma_alloc_frozen_folio() via alloc_gigantic_frozen_folio(). Additionally, hugetlb_cma_alloc_frozen_folio() previously attempted allocation on hugetlb_cma[nid] without verifying if nid is included in the caller's nodemask. Adding a node_isset(nid, *nodemask) check ensures the initial preferred node allocation honors the memory policy / nodemask. However, hugetlb_cma_alloc_frozen_folio() dereferences the nodemask in node_isset(nid, *nodemask) and for_each_node_mask(node, *nodemask), leading to a null pointer dereference kernel panic when nodemask is NULL. Fix this by checking if nodemask is NULL in hugetlb_cma_alloc_frozen_folio() and defaulting it to cpuset_current_mems_allowed. Enclose the allocation attempts within the cpuset seqcount retry loop so that if the cpuset changes concurrently during allocation, the attempts are retried using the updated nodemask. This ensures that the initial node check and fallback loop safely honor the task's cpuset without violating cpuset constraints or causing NULL pointer dereferences or unexpected allocation failures. From a userspace perspective, this bug allows an unprivileged user to crash the kernel (trigger a panic) by requesting a gigantic hugepage allocation with MPOL_PREFERRED_MANY on a system where CMA is only configured on a subset of NUMA nodes. This can be reproduced by booting a VM with two NUMA nodes, restricting CMA to Node 1 (e.g., hugetlb_cma=1:1G default_hugepagesz=1G hugepagesz=1G hugepages=0), and running a program that allocates a 1GB hugepage area without reserving, restricts allocation to Node 0 using mbind() with MPOL_PREFERRED_MANY, and triggers a page fault: void *ptr = mmap(NULL, 1UL << 30, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_HUGE_1GB | MAP_NORESERVE, -1, 0); unsigned long nodemask = 1; /* Node 0 */ mbind(ptr, 1UL << 30, MPOL_PREFERRED_MANY, &nodemask, sizeof(nodemask) * 8, 0); memset(ptr, 0, 1UL << 30); /* Trigger fault */ This results in a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:hugetlb_cma_alloc_frozen_folio+0x75/0x120 Call Trace: only_alloc_fresh_hugetlb_folio.isra.0+0x2c/0x160 alloc_surplus_hugetlb_folio+0x6d/0x100 alloc_hugetlb_folio+0x3c5/0x660 hugetlb_no_page+0x3d9/0x650 Link: https://lore.kernel.org/20260811052909.475635-1-souravpanda@google.com Fixes: eb02f14c4a2b ("mm/hugetlb: allow overcommitting gigantic hugepages") Signed-off-by: Sourav Panda Reviewed-by: Muchun Song Reviewed-by: Anshuman Khandual Cc: David Hildenbrand Cc: Frank van der Linden Cc: Greg Thelen Cc: Johannes Weiner Cc: Kefeng Wang Cc: Michal Hocko Cc: Oscar Salvador Cc: Rik van Riel Cc: SeongJae Park Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton commit 617d0d8d199ba1790c94310fd75a22d01c97a8d6 Author: Nikhil Gurudasani Date: Sun Aug 30 16:11:09 2026 +0530 erofs: preserve LZMA decoders on resize failure The pool-resize path frees each stream's old decoder before allocating its replacement. If an allocation fails after some streams have already been replaced, the failed stream is put back on the list with state == NULL. z_erofs_lzma_max_dictsize is still advanced as if the whole pool had been resized. An existing LZMA mount can select the broken stream and pass NULL to xz_dec_microlzma_reset(). A retry at the same size also skip another resize attempt. Since the global maximum was advanced, thus, the invalid state is left unrepaired. Allocate each replacement before freeing the old decoder, temporarily retaining one old decoder during allocation. Stop at the first failure and advance z_erofs_lzma_max_dictsize only after all streams satisfy the request. Record each stream's dictionary capacity so retries can skip streams already enlarged before a partial failure. Fixes: 622ceaddb764 ("erofs: lzma compression support") Cc: stable@vger.kernel.org Signed-off-by: Nikhil Gurudasani Reviewed-by: Gao Xiang Signed-off-by: Gao Xiang commit 8861f6d5c0678a7c5089c7b272509fc5931b8437 Author: Bradley Morgan Date: Thu Aug 27 17:43:38 2026 +0000 ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing. Fixes: 4f2946aa0c45 ("IMA: introduce a new policy option func=SETXATTR_CHECK") Cc: stable@vger.kernel.org Reported-by: syzbot+5ebeb3089ea6439c37be@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/6a8f89e5.1d9ded08.62e62.00bf.GAE@google.com/ Signed-off-by: Bradley Morgan Signed-off-by: Mimi Zohar commit 8e22ce504f8a332c57ca9676ab804da5ac4a1325 Author: Frederick Lawler Date: Wed Aug 19 18:45:23 2026 -0500 ima: don't measure/appraise files on configfs IMA measurement of a configfs file causes process_measurement() to hold iint->mutex while performing a kernel_read() to hash it, which re-enters configfs's own file locking (buffer->mutex, frag_sem). Separately, opening any file with O_TRUNC now causes ima_file_truncate() to take iint->mutex to reset the cached action flags, while sb_writers is already held for that mount. When a configfs-backed nvmet namespace is involved, these two independent lock chains combine into a cycle: iint->mutex -> configfs locks -> subsys->lock -> sb_writers -> iint->mutex Add configfs to the builtin don't measure/appraise rules, similarly to other pseudo file systems, so IMA never takes iint->mutex for configfs file in the first place. Reported-by: syzbot+448c2e24b1ceff13ed2a@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/6a77c7cd.b50370da.49fe0.0031.GAE@google.com/ Suggested-by: Mimi Zohar Signed-off-by: Frederick Lawler Signed-off-by: Mimi Zohar commit ab84c314417e4743f72f4d3d5e58cf96e07213cc Author: Frederick Lawler Date: Wed Aug 19 18:45:22 2026 -0500 configfs: move CONFIGFS_MAGIC definition to magic.h IMA shouldn't measure or appraise configfs, but currently does because it's missing from the default exclusion policies. Move CONFIGFS_MAGIC to magic.h to expose the file system's magic to IMA, as well as other userland applications. Suggested-by: Mimi Zohar Signed-off-by: Frederick Lawler Acked-by: Breno Leitao Signed-off-by: Mimi Zohar commit e0d26fe176a8db6ccad4ab38c5bab29391c1946b Author: Ivy Lopez Date: Tue Aug 25 13:03:13 2026 -0600 scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumask_of_node() indexes node_to_cpumask_map[-1], an out-of-bounds array read caught by UBSAN: UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' Fall back to cpu_online_mask when no NUMA node is available, rather than assuming dev_to_node() always returns a valid node index. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221294 Suggested-by: Johannes Thumshirn Fixes: 728bbc6cbff7 ("scsi: mpt3sas: Affinity high iops queues IRQs to local node") Signed-off-by: Ivy Lopez Reviewed-by: John Garry Link: https://patch.msgid.link/20260825190313.24013-1-skunkolee@gmail.com Signed-off-by: Martin K. Petersen (Oracle) commit 139f57343b3d6b26d9f01580123b2ba2d2150337 Author: Laurence Oberman Date: Mon Aug 31 07:59:17 2026 -0400 scsi: mpi3mr: Fix use-after-free on tgt_dev->starget during target device refresh/update mpi3mr_refresh_tgtdevs() and mpi3mr_devinfochg_evt_bh() read tgt_dev->starget and immediately pass it to starget_for_each_device() without holding mrioc->tgtdev_lock. Every writer of this field -- mpi3mr_target_alloc(), mpi3mr_target_destroy(), mpi3mr_slave_destroy() and mpi3mr_sdev_init() -- correctly serializes access under tgtdev_lock, but these two read sites do not, which leaves a check-then-use window against the SCSI core's target teardown path (scsi_remove_target(), invoked e.g. via a concurrent host reset, sysfs "delete", or SCSI EH device offlining running independently of the fwevt workqueue). Sequence observed on production hardware, triggered on the mpi3mr0_fwevt_wrkr workqueue during a SAS topology change shortly after a controller reset: BUG: kernel NULL pointer dereference, address: 0000000000000058 RIP: scsi_is_host_device+0x7/0x20 Call Trace: starget_for_each_device+0x34/0x100 mpi3mr_refresh_tgtdevs+0x152/0x1d0 [mpi3mr] mpi3mr_fwevt_bh+0x514/0x6c0 [mpi3mr] mpi3mr_fwevt_worker+0x1a/0x50 [mpi3mr] process_one_work+0x194/0x380 worker_thread+0x2fe/0x410 mpi3mr_refresh_tgtdevs() reads tgt_dev->starget as non-NULL, but by the time starget_for_each_device() dereferences it, a concurrent mpi3mr_target_destroy() has already cleared tgt_dev->starget under tgtdev_lock and the SCSI/device core has freed the underlying scsi_target (and its embedded struct device). The stale pointer is then walked by dev_to_shost() -> scsi_is_host_device(), producing the NULL/garbage dereference above. Fix this by taking mrioc->tgtdev_lock around every read of tgt_dev->starget, matching the existing writer-side discipline. Since starget_for_each_device() and mpi3mr_update_sdev() can end up doing non-atomic work (e.g. queue_limits_commit_update()), the lock cannot be held across the whole call, so instead pin the target's device with get_device() while holding the lock, drop the lock, then run starget_for_each_device() against the pinned reference and put_device() afterwards. This closes the TOCTOU window instead of merely narrowing it. The same unlocked read-and-dereference pattern also exists earlier in mpi3mr_refresh_tgtdevs()'s first removal-scan loop (tgt_dev->starget->hostdata); fix it the same way by holding tgtdev_lock across that check, which is cheap since it only touches plain struct fields. Assisted-by: Claude:Sonnet5 [Claude Code] Signed-off-by: Laurence Oberman Acked-by: Chandrakanth Patil Link: https://patch.msgid.link/20260831120047.14690-1-loberman@redhat.com Signed-off-by: Martin K. Petersen (Oracle) commit f4825922d2fb371e2b969697d792077f1b62b62c Author: Sujal Tuladhar Date: Sat Aug 1 21:30:00 2026 +0545 scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where padding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated. Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Assisted-by: Claude Opus5 (custom harness) Cc: stable@vger.kernel.org Signed-off-by: Sujal Tuladhar Signed-off-by: Martin K. Petersen (Oracle) commit 839f075aabdf5c21048f9801b87c0b841dd3d064 Author: Jingbo Xu Date: Wed Sep 2 09:50:39 2026 +0800 erofs: add sysfs feature entry for xattr prefixes Let /sys/fs/erofs/features/xattr_prefixes advertise that this kernel supports the EROFS_FEATURE_INCOMPAT_XATTR_PREFIXES on-disk format. Fixes: 6a318ccd7e08 ("erofs: enable long extended attribute name prefixes") Cc: stable@vger.kernel.org # 6.4+ Reviewed-by: Gao Xiang Signed-off-by: Jingbo Xu Signed-off-by: Gao Xiang commit 2464ac8a6ff8d8a18b50088eb1d1d638f9cee2f1 Author: Thomas Huth Date: Thu Aug 13 09:53:04 2026 +0200 kselftest/riscv: Replace __ASSEMBLY__ with __ASSEMBLER__ While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembly code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This can be very confusing when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's standardize now on the __ASSEMBLER__ macro that is provided by the compilers. Signed-off-by: Thomas Huth Reviewed-by: Nick Desaulniers Link: https://patch.msgid.link/20260813075304.75988-1-thuth@redhat.com Signed-off-by: Paul Walmsley commit 74e26c692c40565448b8a1d1398c69e221a299cf Author: Yukai Wu Date: Sat Aug 29 10:23:27 2026 +0800 docs/zh_CN: Update arch/riscv/patch-acceptance.rst translation Update Documentation/arch/riscv/patch-acceptance.rst translation. Update the translation through commit ed843ae947f8 ("docs: move riscv under arch") Signed-off-by: Yukai Wu Reviewed-by: Dongliang Mu Acked-by: Weijie Yuan Link: https://patch.msgid.link/20260829022344.192491-1-xiaoyewuz.Ruster@gmail.com Signed-off-by: Paul Walmsley commit 817ecd588fa5820527ee3affa43b5116276d2520 Author: Jia Wang Date: Mon Aug 24 13:54:14 2026 +0800 dt-bindings: riscv: cpus: Fix yamllint style issues Wrap an overlong description line and normalize the inline dependency lists to satisfy yamllint. Signed-off-by: Jia Wang Acked-by: Conor Dooley Link: https://patch.msgid.link/20260824-ultrarisc-dts-v1-1-61ab7aebe9e5@ultrarisc.com Signed-off-by: Paul Walmsley commit 93a27367bacdc32e2cdb478597102175db3fb80c Author: Ivy Lopez Date: Mon Aug 31 19:37:46 2026 -0600 riscv: hwprobe: simplify has_fpu() to check D extension only The kernel never supports D without F, since D depends on F. The D-extension flag is cleared during devicetree/ACPI parsing whenever F is not present, so has_fpu() checking either extension with '||' never actually produces a different result than checking D alone - F without D cannot occur in practice, and there is no observable impact on RISCV_HWPROBE_IMA_FD or userspace. Simplify has_fpu() to check D only, matching the expectations set elsewhere in the kernel for this dependency, rather than relying on a redundant OR condition. sys_hwprobe.c already calls has_fpu() and needs no changes. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221874 Suggested-by: Conor Dooley Suggested-by: Andreas Schwab Signed-off-by: Ivy Lopez Reviewed-by: Conor Dooley Link: https://patch.msgid.link/20260901013746.19386-1-skunkolee@gmail.com [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley commit f643f520c4c6998fa27dce90dd3b3ff6414e0bae Author: Xixin Liu Date: Tue Aug 11 11:51:00 2026 +0800 perf: RISC-V: check cpu_hw_evt before dereference in overflow IRQ The overflow IRQ handler dereferences cpu_hw_evt before the null check. Move the check first. Defensive only; the cookie is valid on the normal path today. Fixes: a8625217a054 ("drivers/perf: riscv: Implement SBI PMU snapshot function") Assisted-by: DeepSeek:deepseek-v3 Signed-off-by: Xixin Liu Link: https://patch.msgid.link/fdd42c791752.v2.1786420235.git.liuxixin@kylinos.cn Signed-off-by: Paul Walmsley commit 248dbaf7770c0843702355a9fb724a882c669062 Author: JinRui Date: Tue Aug 11 08:15:13 2026 +0000 riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present The RISC-V ISA manual specifies that Zfh implies Zfhmin, a normative rule clarified in https://github.com/riscv/riscv-isa-manual/pull/3070. Zvfh likewise implies Zvfhmin, as stated by the vector extension specification. The kernel currently reports ZFH and ZFHMIN (and ZVFH and ZVFHMIN) as independent hwprobe bits derived only from what the device tree declares. Platforms that declare just "zfh" (Zfh being a superset that already contains all Zfhmin instructions) therefore report RISCV_HWPROBE_EXT_ZFHMIN=0, which breaks userspace RVA23 conformance checks (e.g. snapd installing core26 on riscv64). Use the existing superset mechanism to set the implied subset bits: - zfh implies zfhmin - zvfh implies zvfhmin Add a hwprobe selftest asserting the implication holds and update the hwprobe documentation accordingly. This is complementary to the rva23u64 base behavior discussion: the RVA23 conformance query proposed there is derived from the per-extension bits fixed here, so correct EXT_0 reporting is a prerequisite for it to work on harts whose device tree declares only "zfh". Tested on a RISC-V QEMU VM whose device tree only declares "zfh" and "zvfh": with this change both /proc/cpuinfo and the hwprobe RISCV_HWPROBE_KEY_IMA_EXT_0 bitmap report ZFHMIN and ZVFHMIN, and the hwprobe selftest (including the new implication check) passes. Link: https://lore.kernel.org/kvm-riscv/20260206002349.96740-1-andrew.jones@oss.qualcomm.com/ Signed-off-by: JinRui Link: https://patch.msgid.link/7190E4DB338251C3+20260811081513.2849980-1-jinrui@haiwei.tech [pjw@kernel.org: trimmed superfluous blank line in tags] Signed-off-by: Paul Walmsley commit 6809da6e9c08ccc9a09cb0a48c61471679274aaa Author: Xixin Liu Date: Tue Aug 18 17:10:00 2026 +0800 perf: RISC-V: store available counter mask as bitmap The available-counter mask was a single unsigned long, but iteration uses RISCV_MAX_COUNTERS, which is 64. On RV32 that reads past the object. Filling with an unsigned-long bit at index 32 and above is also wrong. Use DECLARE_BITMAP and set_bit/bitmap helpers. Walk each bitmap word into CFG_MATCH when checking events, when allocating an index, and when stopping all counters. Set the counter base to i times BITS_PER_LONG. Share the CFG_MATCH ecall through a small helper so the 32-bit argument split is not duplicated. On qemu-system-riscv32 the probe bitmap has bits above XLEN set, so the first word alone is not enough. Fixes: e9991434596f ("RISC-V: Add perf platform driver based on SBI PMU extension") Assisted-by: DeepSeek:deepseek-v3 Signed-off-by: Xixin Liu Link: https://patch.msgid.link/prpmask02cmap.v2.1786434000.git.liuxixin@kylinos.cn Cc: stable@kernel.org [pjw@kernel.org: updated to apply; fixed checkpatch.pl issues] Signed-off-by: Paul Walmsley commit 70f3995830d3f1e79faa14eb0605914f778feca9 Author: Eric Dumazet Date: Mon Aug 31 19:46:26 2026 +0000 bonding: alb: fix uninitialized transport header access in alb_determine_nd() alb_determine_nd() uses icmp6_hdr(skb) to inspect ICMPv6 headers. However, in xmit paths (e.g. packets sent via AF_PACKET / raw sockets or forwarded packets), skb->transport_header is not guaranteed to be initialized. While pskb_network_may_pull() ensures the packet data is linear starting from the network header, it does not set or adjust the transport header offset. Dereferencing icmp6_hdr(skb) can therefore access out-of-bounds memory. Fetch the icmp6hdr directly after ipv6hdr following pskb_network_may_pull(), and reload ipv6hdr in case pskb_may_pull() reallocated skb->head. Also remove the unused bond argument from alb_determine_nd(). Fixes: 0da8aa00bfcf ("net: bonding: Add support for IPV6 ns/na to balance-alb/balance-tlb mode") Signed-off-by: Eric Dumazet Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260831194626.119371-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit b264d8422779d69febce914efc47a92a85cc382c Author: Aswin Karuvally Date: Thu Aug 27 08:34:08 2026 +0200 s390/ctcm: Prevent XID null dereference The mpc_validate_xid() function sets grp->saved_xid2->xid2_flag2 to 0x40 to signal XID validation error. If peer XID is NULL or r/w channel pairing mismatch happens, grp->saved_xid2 is never initialized. An attempt to set the flag in such case leads to NULL dereference. Fix this by using the always available priv->xid->xid2_flag2 instead of grp->saved_xid2->xid2_flag2 for validation errors. Fixes: 293d984f0e36 ("ctcm: infrastructure for replaced ctc driver") Cc: stable@vger.kernel.org Signed-off-by: Aswin Karuvally Link: https://patch.msgid.link/20260827063408.2168914-1-aswin@linux.ibm.com Signed-off-by: Jakub Kicinski commit 2625480a1bf79c62ffb09aafdf61778e682da492 Author: Mark Brown Date: Tue Sep 1 23:50:02 2026 +0100 hardening: Default randstruct off with rust for better allmodconfig support Currently randstruct does not support rust so we have Kconfig dependencies which prevent rust being enabled when randstruct is. Unfortunately this prevents rust being enabled in allmodconfig, our standard coverage build. randstruct gets turned on by default, then the dependency on !RANDSTRUCT causes rust to get disabled. Work around this by disabling randstruct by default if we have a usable rust toolchain and rust support for the architecture, circular dependencies prevent us directly depending on !RUST. This means we might end up with a configuration that disables both rust and randstruct but hopefully it's more likely go give the expected result. Signed-off-by: Mark Brown Acked-by: Miguel Ojeda Link: https://patch.msgid.link/20260901-rust-reverse-randstruct-dep-v4-1-3bfa19efe1fa@kernel.org Signed-off-by: Kees Cook commit 2e42cade8ff1ff579e77976d9869db4df1feaf74 Author: Mark Brown Date: Tue Sep 1 22:55:42 2026 +0100 regmap: irq: Free the irqdomain we create When domain support was added to regmap-irq it was not possible to remove domains, this was added later by 8ee99ada293b (irqdomain: Support removal of IRQ domains.). We did update the main removal path to free the domain but forgot the error unwinding case during creation that is now in regmap_add_irq_chip_fwnode() after some code motion, meaning that errors during instantiation result in an unused irqchip being left hanging around. Add the missing irq_remove_domain() call where the comment says it should be. Reported-by: Farhad Alemi Reported-by: Thomas Gleixner Link: https://patch.msgid.link/20260901-regmap-irq-deallocate-domain-v1-1-4bfed4aff559@kernel.org Signed-off-by: Mark Brown commit e8a0095c7df170945b4740eda4e2738a50f97fc6 Author: Sam Ho Date: Fri Aug 14 13:01:11 2026 +0000 btrfs: preserve the compression property when other inode flags change Setting the compression property on an inode also sets BTRFS_INODE_COMPRESS on it, and btrfs_inode_flags_to_fsflags() reports that back as FS_COMPR_FL to FS_IOC_GETFLAGS. chattr(1), like any other FS_IOC_SETFLAGS caller, reads the current flags, flips only the bit the user asked for and writes the whole set back, so a request as unrelated as "chattr +i" reaches btrfs_fileattr_set() with FS_COMPR_FL set. btrfs_fileattr_set() takes that as a request to enable compression and overwrites the compression property with the algorithm from the mount options, falling back to zlib when the filesystem was not mounted with -o compress. The algorithm the user selected is silently replaced: # btrfs property set /mnt/foo compression zstd # btrfs property get /mnt/foo compression compression=zstd # chattr +i /mnt/foo # btrfs property get /mnt/foo compression compression=zlib Every chattr operation triggers this, not just +i, and directories are affected as well, so files created afterwards inherit the wrong algorithm too. On a filesystem mounted with -o compress=lzo the property is replaced with lzo instead. Recovering needs a chattr -i first, because the immutable flag rejects the setxattr that "btrfs property set" issues. Prefer the algorithm recorded in the compression property and only fall back to the mount default when there is no property, so that unrelated flag changes no longer overwrite the user's choice. Inodes that have the compress flag set but no property still get the default, so they behave as before. Reviewed-by: Qu Wenruo Signed-off-by: Sam Ho Reviewed-by: David Sterba Signed-off-by: David Sterba commit e0b54613aabeb8e9da597f23b90c6a03d0981986 Author: Guanghui Yang <3497809730@qq.com> Date: Mon Aug 10 20:16:05 2026 +0800 btrfs: restore active device pointers after failed sprout btrfs_init_new_device() switches latest_dev and possibly s_bdev from the seed device to the new sprout device before creating the first writable chunks. If chunk creation or the subsequent sprout setup fails, the error path releases the new device without switching those pointers back. btrfs_show_devname() can then dereference the freed latest_dev and crash. Restore the active device pointers to the latest seed device before removing and releasing the failed sprout device. Fixes: b7cb29e666fe ("btrfs: update latest_dev when we create a sprout device") Assisted-by: Codex:gpt-5 Reviewed-by: Qu Wenruo Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: David Sterba Signed-off-by: David Sterba commit c93b3c43df561cd9f592cee20ae058b563f9e5b6 Author: Guanghui Yang <3497809730@qq.com> Date: Mon Aug 10 20:16:04 2026 +0800 btrfs: detach failed sprout device from transaction update list When creating the first metadata chunk for a sprout filesystem, create_chunk() adds the new device to the transaction dev_update_list through device->post_commit_list. If the subsequent system chunk creation fails, btrfs_init_new_device() aborts the transaction and releases the device while post_commit_list is still linked. This triggers a warning in btrfs_free_device() and leaves the transaction list referencing freed memory. Detach the device while holding chunk_mutex before releasing it. Fixes: bbbf7243d62d ("btrfs: combine device update operations during transaction commit") Assisted-by: Codex:gpt-5 Reviewed-by: Qu Wenruo Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: David Sterba Signed-off-by: David Sterba commit 40fe154ba049a33f063c0058cd185d7f682088f3 Author: Guanghui Yang <3497809730@qq.com> Date: Sat Aug 8 14:38:32 2026 +0800 btrfs: clean up target device if block group marking fails btrfs_dev_replace_start() adds the replacement target to the device list before marking block groups to copy. If marking fails, returning directly leaves the target linked and keeps the device accounting incremented. Jump to the existing cleanup path so the target device is removed and released on failure. The issue was found by a failure-path metadata residual analyzer and verified with targeted failure injection on v6.14. Assisted-by: Codex:gpt-5 Reviewed-by: Qu Wenruo Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: David Sterba Signed-off-by: David Sterba commit 9100191e5acb2e5ea2313f436667bb5fce129f47 Author: Steven Rostedt Date: Fri Aug 28 22:39:01 2026 -0400 ftrace: Take trace_array reference before accessing its ftrace_ops The trace instance files set_ftrace_filter and set_ftrace_notrace was updated to work with specific trace instances (trace_arrays). The issue is that when these files are opened, there is a small race window where it will use the ftrace_ops from the inode->private pointer to get a reference to the trace_array and then take its reference. The problem is that the ftrace_ops itself could be freed. If the rmdir on the instance happens at the same time the set_ftrace_filter file is opened, the rmdir could have also freed the ftrace_ops and referencing it will cause a use-after-free bug and crash the kernel. Instead, pass in the trace_array as the file private data (NULL for the top level instance), and then pass both the trace_array and the ftrace_ops to the ftrace_regex_open() function. If the trace_array is NULL, then it just uses the ftrace_ops without the need to take its reference (like normal). If the ftrace_ops is NULL, that is only the case for the top level instance and the global_ops can be used. This allows the trace_array to have its reference incremented before touching the ftrace_ops that could also be freed when the instance is. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260828223901.29e26edb@robin Fixes: 591dffdade9f0 ("ftrace: Allow for function tracing instance to filter functions") Reported-by: Breno Leitao Tested-by: Breno Leitao Closes: https://lore.kernel.org/all/apGORjltZgAiAYHT@gmail.com/ Signed-off-by: Steven Rostedt commit 89a312991dc6e638a36adc43ccb91dbc25504c04 Merge: 9a58da80053f99 4aa2c106aef4bf Author: Linus Torvalds Date: Tue Sep 1 13:37:14 2026 -0700 Merge tag 'cifs-fixes-7.3-rc2' of https://git.manguebit.org/linux Pull smb client fixes from Paulo Alcantara: - Fixes for fallocate range operations (insert, collapse, zero, punch hole) The insert range implementation copied overlapping chunks in the wrong direction, corrupting file data on every server except Windows. Several related issues in the same area are also addressed — stale page cache and FS-Cache readback, an integer truncation on large files, missing RLIMIT_FSIZE validation and missing sparse file marking. - Data corruption fixes in the O_TRUNC open path: one where i_size was zeroed before the server confirmed the truncate and another where the lack of locking allowed concurrent buffered writes to be silently discarded - Heap overflow fixes in legacy SMB1 paths: one in extended attribute writes and one in POSIX ACL handling, both exploitable via unprivileged setxattr(2) - Fix for multiuser mount with krb5 failing because the username option was not propagated to new per-user connections - Fix for split debug message in __release_mid() after a printk conversion * tag 'cifs-fixes-7.3-rc2' of https://git.manguebit.org/linux: smb: client: reject SetEA requests that do not fit the request buffer smb: client: fix data corruption with concurrent writes and O_TRUNC cifs: don't update i_size in cifs_do_truncate without a cached handle smb: client: fix heap overflow in cifs_do_set_acl() smb: client: fix multiuser mount with krb5 smb: client: transport: Fix debug printing in __release_mid() smb/client: invalidate fscache for fallocate range operations smb/client: fix stale page cache in insert/collapse range smb/client: fix integer truncation in collapse range smb/client: fix data corruption in emulated insert range smb/client: mark file sparse before emulating insert range smb/client: validate new EOF for zero range smb/client: validate new EOF for insert range cifs: add revalidation on FSCTL failure in smb2_duplicate_extents() commit f4a771cc684c7354b6200147f7252c58d17408ff Author: Steven Rostedt Date: Fri Aug 28 09:41:53 2026 -0400 tracing: Have show_event_filters/triggers files take trace array ref The newly added files show_event_filters and show_event_triggers that show all filters or triggers that are set within the trace array do not take a reference for the trace array it is showing. Without taking a reference, the trace_array may be freed via "rmdir" while a task is reading one of theses files. Those files iterate all the events within an instance (trace_array) and nothing prevents that instance from being freed while its data is being read. This causes a use-after-free crash. Have the open of both those files take the trace_array reference via the trace_array_get() that prevents the trace_array from being freed while the files are opened. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260828094153.17b95037@gandalf.local.home Fixes: 729757b96a662 ("tracing: Add show_event_filters to expose active event filters") Fixes: 6a80838814eea ("tracing: Add show_event_triggers to expose active event triggers") Reported-by: Farhad Alemi Closes: https://lore.kernel.org/all/CA+0ovCjerKZJLwXScM9bF2ga2rLi4_XOpUfK41NDbENpeu98jA@mail.gmail.com/ Reviewed-by: Aaron Tomlin Signed-off-by: Steven Rostedt commit 774b73428e6eabb4f0382aeeb76e569c7b106a29 Author: Faith Ekstrand Date: Fri Aug 21 23:42:59 2026 -0500 drm/nouveau: Use write-combined maps for coherent On Tegra devices, uncached maps translate to device memory, causing unaligned accesses by userspace resulting in a SIGBUS. Instead, use write-combined maps to ensure proper access. This would also affect discrete cards on any Arm device. It was determined that discrete cards regardless of cpu arch should use write-combined maps for coherent anyways. Thus this change is made for all gpu types. Cc: stable@vger.kernel.org Signed-off-by: Faith Ekstrand Co-developed-by: Aaron Kling Signed-off-by: Aaron Kling Fixes: 1b4ea4c5980f ("drm/ttm: set the tt caching state at creation time") Link: https://patch.msgid.link/20260821-tegra-coherent-wc-v2-1-2b1ddb67bf18@gmail.com Signed-off-by: Danilo Krummrich commit 4a819ee5f2834330656d6ac168c4c8cf27fdeec2 Author: Rafael J. Wysocki Date: Mon Aug 31 22:07:10 2026 +0200 ACPI: bus: Drop two fields from struct acpi_device_pnp There are two fields in struct acpi_device_pnp, device_name and device_class, that were supposed to be populated and used by device drivers, but they have never been used consistently and now they are only set for the bus object in acpi_set_pnp_ids() (and never read afterward). Drop them along with all of the associated symbols except for MAX_ACPI_CLASS_NAME_LEN and the acpi_device_class typedef that are used by the ACPI netlink messaging code. Move those two definitions closer to the struct acpi_bus_event that refers to the acpi_device_class type. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/6314925.lOV4Wx5bFT@rafael.j.wysocki commit 0ba8e0f90039da68342febf613019f4a68d86620 Author: Taimuraz Kaitmazov Date: Thu Aug 20 01:44:57 2026 +0300 accel/amdxdna: refuse to flush an imported BO SYNC_BO clflushes an imported BO's scatterlist. An importer may not do that: the memory belongs to the exporter, and dma-buf gives the importer no interface to ask for maintenance on it. Refuse the request instead. is_import_bo() is (obj)->attach, which covers more than foreign buffers. A userptr BO arrives through a ubuf, and on a carveout device every share BO and the device heap arrive through a cbuf, so SYNC_BO answers -EOPNOTSUPP for those too, including the AMDXDNA_BO_DEV path that flushes through its heap. Only the ubuf case gives up maintenance it was getting: on a 64 MiB userptr BO a 4 KiB sync and a full sync both cost 659 us, this arm having ignored the range. amdxdna_cbuf_map() fills in only the DMA address and length, so drm_clflush_sg() already walks zero pages on carveout memory. Userspace maintains these through the mapping it already holds, as XRT's buffer::sync() does unless it is told to sync through the driver. Fixes: dbc8fd7a03cb ("accel/amdxdna: Add expandable device heap support") Reported-by: Christian König Link: https://lore.kernel.org/dri-devel/a505f9e5-b416-43e9-934d-c5c29b8a70e9@amd.com/ Suggested-by: Lizhi Hou Signed-off-by: Taimuraz Kaitmazov Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260819224458.257346-5-taimuraz@kaitmazov.com commit 4cb4aead98380fc0b1b0500a1c49d35724854067 Author: Zhang Yi Date: Tue Sep 1 18:49:46 2026 +0800 ASoC: codecs: ES8326: issue about capture pop This RFC asks how to resolve the 'capture pop noise' issue. The ES8326's capture pop noise occurs when LRCK is active. While the pop noise can be effectively reduced through codec configuration, it cannot be completely eliminated. So I decided to create a workqueue. unmute the ADC once the LRCK becomes active. Signed-off-by: Zhang Yi Link: https://patch.msgid.link/20260901104946.20114-1-zhangyi@everest-semi.com Signed-off-by: Mark Brown commit 6d49beec658f61801e79019fd73691b17252dee3 Author: Ian Luites Date: Mon Aug 31 08:25:47 2026 +0000 soundwire: dmi-quirks: Disable ghost Realtek on Asus GX651AX The Asus ROG Zephyrus Duo GX651AX exposes a Realtek RT722 device in ACPI which does not exist in the physical hardware. The device remains unattached while the CS42L43 and both CS35L56 devices attach successfully. This confuses the function topology machine driver into creating duplicate DAI links named SDW3-Playback-SimpleJack, and the sof_sdw probe fails with error -12. Add a model-specific quirk to remove the ghost RT722 device. Fixes: 45cf24da0a10 ("ASoC: Intel: soc-acpi-intel-ptl-match: Remove unnecessary cs42l43 match") Cc: stable@vger.kernel.org # 7.2.x Assisted-by: LLM Signed-off-by: Ian Luites Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260831082534.224716-1-ian@luites.com Signed-off-by: Vinod Koul commit 00aef6b609bf231b4213704b602250ca53f95897 Author: Syed Saba Kareem Date: Tue Sep 1 15:53:26 2026 +0530 ASoC: amd: yc: Add DMI entry for HP 255R G10 laptop The HP 255R G10 laptop has an internal DMIC connected to the AMD ACP6x audio coprocessor. Add a DMI quirk entry so the internal microphone is properly detected on this model. Reported-by: eraleexxx@gmail.com Signed-off-by: Syed Saba Kareem Link: https://patch.msgid.link/20260901102338.26403-1-syed.sabakareem@amd.com Signed-off-by: Mark Brown commit 9cdc7e6dc7a99ad7311ad5e7c145f2b9ce4e24b0 Author: Shen Yongchao Date: Mon Aug 3 22:31:57 2026 +0800 HID: bpf: serialize device reference release in struct_ops destroy path __hid_bpf_ops_destroy_device() and hid_bpf_unreg() can race on the same registration reference, double-putting struct hid_device and freeing it while hid_destroy_device() still uses it. Serialize the remove/NULL decision under hdev->bpf.prog_list_lock so exactly one path releases each registration reference: unreg re-checks ops->hdev under the lock and returns without putting when the destroy path already cleared it; all put_device() calls happen after the lock is dropped, which is safe because a concurrent unreg then observes ops->hdev == NULL under the lock. Background: each successful attach (hid_bpf_ops_reg) acquires one device reference (hid_get_device()). Two paths can release it: - device destruction: hid_destroy_device() -> hid_bpf_destroy_device() -> __hid_bpf_ops_destroy_device(), which walks hdev->bpf.prog_list under rcu_read_lock() and drops one reference per attached program; - BPF link release: bpf map delete (no BPF_F_LINK) synchronously calls st_ops->unreg() -> hid_bpf_unreg(), which drops the reference for its own registration. The coordination handshake (e->hdev = NULL on the destroy side vs "if (!hdev) return" on the unreg side) is a TOCTOU check: the two paths run under different lock domains (rcu_read_lock vs prog_list_lock), so a concurrent unreg can read ops->hdev as non-NULL, block on prog_list_lock, and then proceed while the destroy traversal executes - both paths then drop the same reference. The refcount reaches zero legitimately (each decrement is individually valid), so no refcount_t saturation fires: the device is simply freed while the transport is still inside hid_destroy_device(), and subsequent teardown touches freed memory. The fix serializes the remove/NULL decision under prog_list_lock on both sides and moves the destroy-side puts outside the lock. With the lock held, plain reads/writes of ops->hdev are sufficient; no READ_ONCE/WRITE_ONCE are added, keeping the patch minimal. Unlocked-read safety: the unlocked read of ops->hdev at the top of hid_bpf_unreg() cannot touch a freed device, because the unreg path itself still holds this registration's reference (released only by its own hid_put_device() after the lock is dropped), and a destroy traversal that already cleared ops->hdev makes the lock-internal re-check return early without any put. At most one of the two paths releases each registration reference. Fixes: ebc0d8093e8c ("HID: bpf: implement HID-BPF through bpf_struct_ops") Cc: stable@vger.kernel.org Signed-off-by: Shen Yongchao Assisted-by: Hermes:kimi-k3 Signed-off-by: Benjamin Tissoires commit 3bb3e80faf21e432f6e6d89c55fb587c323b8813 Author: Sudeep Holla Date: Tue Sep 1 14:11:12 2026 +0100 firmware: arm_ffa: Tear down driver during shutdown The platform core invokes a driver's shutdown callback, rather than its remove callback, while preparing devices for a normal kexec. Without a shutdown callback, the FF-A driver leaves notifications, partition devices, and the RX/TX mapping active before the replacement kernel is booted. Use ffa_remove() for shutdown so the existing cleanup runs before a normal kexec and other orderly system shutdowns. Reported-by: Nat Gurumoorthy Closes: https://lore.kernel.org/all/20260729162731.1383875-1-natg@google.com/ Reported-by: Carol L Soto Closes: https://lore.kernel.org/all/20260818224404.3694580-1-csoto@nvidia.com Reported-by: Maxi Saparov Closes: https://lore.kernel.org/all/20260826222337.73480-1-maxi.saparov@gmail.com Link: https://patch.msgid.link/20260901131112.3437516-1-sudeep.holla@kernel.org Tested-by: Carol L Soto Signed-off-by: Sudeep Holla commit f6d752278c13839888425294c110174fb6c87e3d Author: Russ Weight Date: Tue Aug 18 13:46:48 2026 -0600 MAINTAINERS: Remove Russ Weight from Firmware Loader Remove Russ Weight from the MAINTAINERS for FIRMWARE LOADER. Signed-off-by: Russ Weight Link: https://patch.msgid.link/20260818194648.1014604-4-russ.weight@linux.dev Signed-off-by: Danilo Krummrich commit 0d3e690c112939d869931a5c8c0bb23718d58370 Author: Russ Weight Date: Tue Aug 18 13:46:47 2026 -0600 CREDITS: Add CREDITS entry for Firmware Upload Add an entry to the CREDITS file for the Firmware Upload functionality of the Firmware Loader. Signed-off-by: Russ Weight Link: https://patch.msgid.link/20260818194648.1014604-3-russ.weight@linux.dev Signed-off-by: Danilo Krummrich commit 6db237eb516774a76b0d6ab8b4090185f6f2f956 Author: Russ Weight Date: Tue Aug 18 13:46:46 2026 -0600 firmware_loader: Change contact for sysfs nodes Change the contact name for the firmware_loader sysfs nodes to driver-core@lists.linux.dev. Signed-off-by: Russ Weight Link: https://patch.msgid.link/20260818194648.1014604-2-russ.weight@linux.dev [ Since we have a driver-core mailing list, use it as contact information instead of myself. - Danilo ] Signed-off-by: Danilo Krummrich commit a20afec40ea1012659861e58374c1bcde2e18a43 Author: Jack Yu Date: Tue Sep 1 17:37:51 2026 +0800 ASoC: rt721-sdca: Adjust latency control to fix no-sound issue Adjust latency control in speaker preset to fix no-sound issue. Signed-off-by: Jack Yu Link: https://patch.msgid.link/20260901093751.2962786-1-jack.yu@realtek.com Signed-off-by: Mark Brown commit 83162eeaf78c71ff6f6fa31dc95e3b6e90ee593f Author: HyeongJun An Date: Wed Sep 2 00:39:21 2026 +0900 ALSA: dummy: Report a change when one capture switch channel moves The snd_dummy_capsrc_put() builds its change flag with &&, so it reports a change only when both channels move at once. Writing a single channel stores the new value and returns 0, the control core then sends no SNDRV_CTL_EVENT_MASK_VALUE, and a second reader keeps showing the old setting until it polls again. The volume put a few lines above compares the same pair of channels with ||. The mixer selftest already reports this. With snd-dummy loaded it fails event_missing on all five capture switches: # CD Capture Switch.1 orig 0 read 1, is_volatile 0 not ok 13 event_missing.Dummy.9 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260901153921.3971-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai commit 8d7b3e41ffecc69388a566ecc52093d292074c2a Author: Sophon Zhang Date: Tue Sep 1 01:09:53 2026 +0800 rust: pci: reject IRQ vector indices that do not fit in u32 IrqVectorRegistration::index() accepts a usize, but pci_irq_vector() takes an unsigned int. On 64-bit architectures, casting an index larger than u32::MAX wraps it before the PCI core can validate it. In particular, u32::MAX + 1 becomes zero and can resolve to the first allocated vector. Use a checked conversion and return EINVAL when the index cannot be represented by the C API. Fixes: 2fb7755b0a7e ("rust: pci: resolve IRQ in index() and embed IrqRequest in IrqVector") Signed-off-by: Sophon Zhang Reviewed-by: Gary Guo Reviewed-by: Alexandre Courbot Link: https://patch.msgid.link/20260901-fix-pci-irq-vector-index-truncation-v4-1-f94aa6932fd9@hotmail.com Signed-off-by: Danilo Krummrich commit 1f1d0812f6a8ab8e6f709c599f137c99646512cc Author: Abdurrahman Hussain Date: Sat Aug 15 13:44:19 2026 -0700 gpiolib: of: don't mark hog nodes OF_POPULATED before a chip is found When a gpio-hog node is attached by a device-tree overlay before its parent GPIO chip has been registered, of_gpio_notify() sets OF_POPULATED on the node via of_node_test_and_set_flag() and only then discovers that there is no gpio_device for the parent, returning NOTIFY_DONE without clearing the flag. Since gpiochip_hog_lines() skips any hog child whose of_node carries OF_POPULATED, the leaked flag makes the hog silently ignored when the chip is registered later. Applying an overlay containing both a GPIO controller node and its hog children - and populating devices only after the overlay apply completes - hits this on every boot; the hog is only applied if the chip driver is unbound (which clears the flag in the remove path) and rebound. Look up the parent gpio_device before claiming the node so that a hog attached ahead of its chip stays unclaimed and is picked up normally by gpiochip_hog_lines() at registration time. Signed-off-by: Abdurrahman Hussain Fixes: a23226b7c1f6 ("gpiolib: handle gpio-hogs only once") Cc: stable@vger.kernel.org Reviewed-by: Daniel Drake Link: https://patch.msgid.link/20260815-gpiolib-of-hog-flag-leak-v1-1-6126aac5f6f3@nexthop.ai Signed-off-by: Bartosz Golaszewski commit 3663c8d1f31e65771bd73ee3259f35fd397f9933 Author: Lu Yao Date: Mon Aug 31 09:42:18 2026 +0800 drm/xe/oa: Remove sysfs entry on idr_alloc failure in xe_oa_add_config_ioctl() If idr_alloc() fails after create_dynamic_oa_sysfs_entry() has succeeded, the error path frees the OA config without removing the metrics sysfs group. Remove the sysfs group before releasing the config, and fix up the misleading error message copied from the sysfs creation failure path. Fixes: cdf02fe1a94a ("drm/xe/oa/uapi: Add/remove OA config perf ops") Signed-off-by: Lu Yao Link: https://patch.msgid.link/20260831014218.28515-1-yaolu@kylinos.cn Reviewed-by: Rodrigo Vivi Signed-off-by: Rodrigo Vivi (cherry picked from commit 2c6fbda5fdde461d6dedb82a59285182720b8fef) Signed-off-by: Rodrigo Vivi commit 2b0ac85512b7f67479127b2713254490662eb13d Author: Linkai Gong Date: Fri Aug 21 15:57:28 2026 +0800 cpuidle: dt_idle_genpd: kfree() the original name allocation dt_idle_pd_alloc() kasprintf()s the full node path, then points pd->name at kbasename() of that string. dt_idle_pd_free() kfree()s pd->name, which is no longer the start of the allocation. Copy the basename instead. Fixes: 9d976d6721df ("cpuidle: Factor-out power domain related code from PSCI domain driver") Signed-off-by: Linkai Gong Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson commit 1d80a4792f1de236c157bcee2e5400fad4c66c65 Author: Richard Fitzgerald Date: Tue Sep 1 13:26:44 2026 +0100 ASoC: cs35l56: Fix probe deadlock waiting for SoundWire enumeration On SoundWire, don't call snd_soc_register_component() from driver probe(). Instead, queue a work item after first SoundWire attach to call snd_soc_register_component(). This prevents a deadlock if snd_soc_register_component() directly calls cs35l56_component_probe(). On SoundWire, the registers are not accessible during driver probe(). Drivers must return from their probe() and wait for the SoundWire core to call their update_status() callback to report an ATTACHED status. The cs35l56 driver handled this by calling snd_soc_register_component() from driver probe() as usual, and cs35l56_component_probe() waited for init_completion to be signalled. A SoundWire attach calls cs35l56_init() which then signals init_completion. This created a deadlock if this was the last component needed to complete a card. In that case, snd_soc_register_component() directly called cs35l56_component_probe() which led to this: driver probe() calls snd_soc_register_component() calls cs35l56_component_probe() waits for init_completion In this case the driver probe() has not returned, so the SoundWire core would not call update_status() and init_completion would not be signalled. Fortunately, snd_soc_register_component() never returns -EPROBE_DEFER, so it doesn't need to be called from a driver probe(). It can be deferred to a work item. This work is queued after the first completed pass through cs35l56_init(), so there is no need for it to wait for init_completion. snd_soc_register_component() isn't called directly from cs35l56_init() because cs35l56_init() runs in the SoundWire bus driver thread, and there would be a risk of nested locking or lock inversion. The work item is queued on a freezable workqueue to prevent a race between the work item and system_suspend of another instance. If the workqueue were not frozen it would be possible for the work item of one driver instance to call snd_soc_register_component() which then calls cs35l56_component_probe() of another instance while that instance is already executing its system suspend functions. The non-SoundWire case still calls snd_soc_register_component() from cs35l56_common_probe() so that it is the last initialization action. There's no need defer the call for I2S/SPI buses so we can also leave it able to return errors during probe. Fixes: 440c2d38950f7 ("ASoC: cs35l56: Wait for init_complete in cs35l56_component_probe()") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260901122644.634494-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit 9a58da80053f992b285b6b7bebc694b0f284c443 Merge: 786262be6048de ba9572bc43d04d Author: Linus Torvalds Date: Tue Sep 1 08:17:01 2026 -0700 Merge tag 'ksmbd-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/smb Pull smb server fixes from Namjae Jeon: - Prevent unintended data exposure by clearing pipe compound padding and the response buffer - Initialize missing fields in FS_OBJECT_ID_INFORMATION, FS_CONTROL_INFORMATION, and FS_POSIX_INFORMATION - Propagate DACL parsing and allocation failures so malformed security descriptors are rejected - Rate-limit errors for unmapped SIDs to prevent kernel log flooding - Drain multichannel sessions during LOGOFF, wake deferred locks and cancellable requests, and ensure cancellation callbacks run only once - Fix listener kthread reference handling and teardown ordering during netdevice events - Validate normalized-name and IPC share configuration response lengths - Update the KSMBD MAINTAINERS entry and add Paulo Alcantara as an SMBDIRECT co-maintainer * tag 'ksmbd-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/smb: ksmbd: validate normalized name response length ksmbd: fix listener task lifetime on netdev events ksmbd: prevent out-of-bounds reads in share config responses ksmbd: rate limit unmapped SID errors ksmbd: propagate DACL parsing errors ksmbd: zero pipe read compound padding ksmbd: safely drain sessions during logoff MAINTAINERS: Update the KSMBD entry MAINTAINERS: Add Paulo Alcantara as an SMBDIRECT co-maintainer ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION ksmbd: initialize FileSystemControlFlags in FS_CONTROL_INFORMATION ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in commit 7b15d6cf25e6c2aea77129179b75c191b20d79a9 Author: Hengyu Liang Date: Sat Aug 22 01:17:05 2026 -0400 kernfs: preserve security xattrs without allocating iattrs Commit d5e81a5650b5 ("kernfs: avoid iattr allocation in listxattr") made kernfs_iop_listxattr() return an empty list when the kernfs node has no allocated kernfs_iattrs. However, this also skips security xattr names provided by simple_xattr_list(). As of now, applications can retrieve the SELinux label of a sysfs file with getxattr(), but cannot do it through listxattr(). A similar issue happened before in commit b09e0fa4b4ea ("tmpfs: implement generic xattr support"). It was fixed by commit 8b0ba61df5a1c ("fs/xattr.c: fix simple_xattr_list to always include security.* xattrs"). Perhaps this recent commit needs a fix as well. The issue can be reproduced with a simple python program: python3 - <<'PY' import os path = "/sys/kernel/warn_count" print("getxattr:", os.getxattr(path, "security.selinux")) print("listxattr:", os.listxattr(path)) PY Before commit d5e81a5650b5 ("kernfs: avoid iattr allocation in listxattr"), the result is: getxattr: b'system_u:object_r:sysfs_t:s0\x00' listxattr: ['security.selinux'] After that commit, the result is: getxattr: b'system_u:object_r:sysfs_t:s0\x00' listxattr: [] This patch will keep listxattr() consistent with getxattr() when security xattrs are available. Fixes: d5e81a5650b5 ("kernfs: avoid iattr allocation in listxattr") Signed-off-by: Hengyu Liang Acked-by: Tejun Heo Link: https://patch.msgid.link/20260822051705.1761850-1-hengyul@cs.unc.edu Signed-off-by: Danilo Krummrich commit 4956993bb3befdf791d71a4952d8d13bcfd44c7b Author: Wei Jie Law <98lawweijie@gmail.com> Date: Tue Aug 25 18:31:17 2026 +0800 HID: rmi: fix OOB access with undersized RMI reports The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: data->input_report_size = hid_report_len(input_report); data->output_report_size = hid_report_len(output_report); alloc_size = data->output_report_size + data->input_report_size; data->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); data->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly "this probe validated the reports"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles a reply carrying fewer bytes than requested, and a write longer than the output report was overrunning the buffer already. Verified on v6.12.69 and on v6.12.105 built with CONFIG_KASAN=y and booted kasan_multi_shot, whose hid-rmi.c is identical to mainline here. An emulated RMI4 device driven over /dev/uhid, and the same device again over dummy_hcd plus raw-gadget, give identical results: BUG: KASAN: slab-out-of-bounds in rmi_hid_read_block+0x409/0x750 [hid_rmi] Read of size 21 at addr ffff88800bf33bba by task kworker/0:3/285 __asan_memcpy+0x23/0x60 rmi_hid_read_block+0x409/0x750 [hid_rmi] rmi_f01_probe+0x5dd/0x1dc0 [rmi_core] BUG: KASAN: slab-out-of-bounds in rmi_hid_write_block+0x1a9/0x350 [hid_rmi] Write of size 35 at addr ffff88810a2b24ac by task kworker/1:10/666 __asan_memcpy+0x3c/0x60 rmi_hid_write_block+0x1a9/0x350 [hid_rmi] rmi_driver_set_irq_bits+0x1f6/0x4d0 [rmi_core] rmi_driver_probe+0x636/0xbf0 [rmi_core] rmi_input_configured+0x184/0x2e0 [hid_rmi] rmi_probe+0x952/0xcf0 [hid_rmi] and, for the zero-length reply, a probe worker left in D state in rmi_hid_read_block() after 225 replies at 200 ms intervals. After this change the undersized descriptor is refused at probe with "rmi reports too small (out=2 in=2)", the oversized read and write are both rejected, the zero-length reply fails the read with -EIO while later reads on the same device keep working, and a device declaring reports large enough for a 21-byte register read still probes normally and reports its real product id. A device bound through new_id with RMI_DEVICE in its driver_data no longer reaches rmi_set_page() with an unallocated writeReport either. Link: https://lore.kernel.org/linux-input/20260822121007.153988-1-98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/00a489f38b240624dcb5a4bae36a53fcba9cfb47.1787549195.git.98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/20260824122708.76168-1-98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/20260825060954.104890-1-98lawweijie@gmail.com/ Fixes: 9fb6bf02e3ad ("HID: rmi: introduce RMI driver for Synaptics touchpads") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Assisted-by: GLM:glm-5.3 Signed-off-by: Wei Jie Law <98lawweijie@gmail.com> Signed-off-by: Jiri Kosina commit 6d94c47a2e3a38170a0a141547e4c52fbe232cc3 Author: Christian Marangi Date: Fri Aug 21 10:52:15 2026 +0200 pmdomain: airoha: fix unselectable AIROHA_CPU_PM_DOMAIN kconfig The AIROHA_CPU_PM_DOMAIN config was wrongly guarded under the Mediatek PM Domains menu and was unselectable. Move it outside the menu so it's now visible and correctly selectable by default on Airoha SoC. Cc: stable@vger.kernel.org Fixes: 82e703dd438b ("pmdomain: airoha: Add Airoha CPU PM Domain support") Signed-off-by: Christian Marangi Reviewed-by: Abel Vesa Signed-off-by: Ulf Hansson commit bb3a94a6828336dcc2dd891e51ebd92dcdd0b576 Author: Geert Uytterhoeven Date: Thu Aug 20 17:23:29 2026 +0200 drivers: base: test: DRIVER_PE_KUNIT_TEST should not select OF Enabling a (modular) test should not silently enable additional kernel functionality, as that may increase the attack vector for a product. Fix this by skipping the new test when OF support is disabled instead of selecting OF support. Note that when OF support is disabled, the compiler optimizes away the then unused reference to of_fwnode_ops in of_node_init(), so linking succeeds. Fixes: 0e6f8ccd4618afdb ("device property: add test cases for fwnode_for_each_child_node()") Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/8dfb4afaf70b59cd33af9296464395470405187e.1787239268.git.geert@linux-m68k.org Signed-off-by: Danilo Krummrich commit c9273c83885835dbd1e8835d5665dfb8503d65e0 Author: Fan Wu Date: Thu Aug 20 13:53:07 2026 +0000 usb: typec: qcom-pmic-typec: drain cc_debounce_dwork if port_start() fails cc_debounce_dwork can be queued before port_start() fails: tcpm_register_port() runs first, and its state machine may invoke set_cc() or start_toggling() from the TCPM worker. The error path then calls tcpm_unregister_port(), whose worker flush may queue the delayed work before devres frees pmic_typec_port. Disable and drain the delayed work directly at port_start()'s error exit. Do not use port_stop() for this path: its IRQs use IRQF_NO_AUTOEN and are enabled only after a successful port_start(). This issue was found by an in-house static analysis tool. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable # v6.10+ Suggested-by: Bryan O'Donoghue Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260820135307.153773-3-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 263f7d61a4201cde16849b2d016251806e7418be Author: Fan Wu Date: Thu Aug 20 13:53:06 2026 +0000 usb: typec: qcom-pmic-typec: disable cc_debounce_dwork on stop cc_debounce_dwork is queued from the set_cc() and start_toggling() callbacks, which run from TCPM's kthread worker. port_stop() returns before tcpm_unregister_port() destroys that worker. Flushing the worker during unregister may therefore run a callback which queues the delayed work after port_stop() has returned. The delayed work can then run after devres has freed pmic_typec_port. Use disable_delayed_work_sync() in port_stop() to cancel a pending instance and prevent the TCPM callbacks from queueing another one. This issue was found by an in-house static analysis tool. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable # v6.10+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260820135307.153773-2-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 6e74ac5c596fd246e37eadfc354567179ccbe9aa Author: Jeffin Philip Date: Sun Aug 16 11:47:12 2026 +0530 usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null. Reported-by: syzbot+fd6ef980cf1c722be639@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fd6ef980cf1c722be639 Fixes: 0062f6e56f70 ("usb: gadget: add a forward pointer from usb_function to its "instance"") Cc: stable Signed-off-by: Jeffin Philip Link: https://patch.msgid.link/20260816061712.15547-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7b0df6efd143f8085bdb68778a013a46f1349913 Author: Fan Wu Date: Wed Aug 19 16:14:48 2026 +0000 usb: typec: qcom-pmic: cancel reset_work on stop pdphy_stop() disables IRQs but leaves reset_work pending. If the IRQ handler schedules it just before disable_irq(), the work runs after remove() frees the struct via devm. Call cancel_work_sync() after disabling IRQs to close the window. This issue was found by an in-house static analysis tool. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Konrad Dybcio Reviewed-by: Bryan O'Donoghue Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260819161448.76597-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 2c0f5ca48674a5b5f9fa4a9c3325aa48053af0bc Author: Jeffin Philip Date: Tue Aug 18 09:29:04 2026 +0530 usb: gadget: f_mass_storage: fix null pointer dereference in fsg_common_set_num_buffers() Previously fsg_num_buffers_validate() was removed as it was not necessary due to Kconfig setting the limits for n from 2 to 256 with default as 2. However, setting the page content in such a way that kstrtou8() reflects n value as either 0 or 1 bypasses these restrictions leading to a null pointer dereference if n is 0. Fix this by adding a check for n < 2 and returning -EINVAL if n is either 0 or 1 consistent with Kconfig logic. Reported-by: syzbot+791be35f1fbcc85d06d7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=791be35f1fbcc85d06d7 Fixes: fe5a6c48fd95 ("usb: gadget: storage: get rid of fsg_num_buffers_validate()") Cc: stable Signed-off-by: Jeffin Philip Acked-by: Alan Stern Link: https://patch.msgid.link/20260818035904.10324-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9f6f095beec82a80daa666a3b2186a5b95841e9a Author: Andy Shevchenko Date: Mon Aug 17 18:11:30 2026 +0200 usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns() GCC (Debian 14.2.0-19) is not happy about the buffer size: drivers/usb/gadget/function/f_mass_storage.c:2970:48: error: ‘%d’ directive output may be truncated writing between 1 and 9 bytes into a region of size 5 [-Werror=format-truncation=] Bump the size to get it enough for all possible values. Note, although cfg->nluns is limited to FSG_MAX_LUNS (16), the compiler doesn't realize this and complains about the buffer size. Also note, the existing comment is wrong as size 8 for the whole buffer doesn't cover 100 mil numbers, hence drop it altogether. Fixes: b27c08c953e9 ("usb: gadget: f_mass_storage: create lun creation helpers for use in fsg_common_init") Cc: stable Acked-by: Alan Stern Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260817161239.1448582-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4ffee1aebb0c0ffcda9faffd17834ea9b00d42cc Author: Myeonghun Pak Date: Mon Jul 27 21:34:14 2026 +0900 usb: storage: realtek_cr: fix use-after-free on disconnect realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis. Fixes: e931830bb877 ("Realtek cr: Add autosuspend function.") Cc: stable Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260727123414.44700-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6e2b571b0a54755b06e092501913e1dfefe75d6c Author: Kanishka De Silva Date: Sun Aug 30 12:31:33 2026 +0530 ublk: clear VM_MAYWRITE on read-only ublk char device mmap ublk_ch_mmap() rejects mmap requests with VM_WRITE set, but never clears VM_MAYWRITE on the resulting read-only mapping. This allows a userspace daemon to mmap the per-queue command buffer PROT_READ, then upgrade it to PROT_WRITE via mprotect(), since VM_MAYWRITE was never cleared. The command buffer holds struct ublksrv_io_desc entries that are kernel-written ABI; a writable mapping lets an unprivileged daemon process corrupt fields such as addr, op_flags, nr_sectors, and start_sector. Same bug class as the drm/panthor and drm/vc4 VM_MAYWRITE fixes, and the 2026-08-13 ptp/vmclock fix (a5edadbae57e). Verified via mprotect() PoC: before the fix, a PROT_READ mapping can be upgraded to PROT_READ|PROT_WRITE and a write into the command buffer corrupts io_desc fields (confirmed under KASAN). After the fix, mprotect() returns -EACCES. Fixes: 3fee8d7599e1 ("ublk_drv: add io_uring based userspace block driver") Cc: stable@vger.kernel.org Signed-off-by: Kanishka De Silva Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260830070133.559-1-kpskanna1915@gmail.com Signed-off-by: Jens Axboe commit eae6460f617382044c5afe5ef202f4d8b2c099b5 Author: Pawel Laszczak Date: Thu Aug 20 12:45:31 2026 +0200 usb: cdnsp: fix wakeup from S3 after controller context loss CDNSP controller may lose its runtime register programming across S3 suspend/resume, depending on SoC power domain configuration. After resume the operational and interrupter registers may contain reset values, which prevents the gadget side from recovering correctly and breaks wakeup from S3. Fix this by detecting whether the controller lost its register context after resume and handling both cases: - If context was lost (CFG_3XPORT_U1_PIPE_CLK_GATE_EN set or power lost): reset the controller and reprogram the state required for normal operation, including the command ring, DCBAA pointer, doorbell base, event ring, ERST base/size and event ring dequeue pointer. - If context was retained: restart the controller directly without reprogramming registers. Issue a wakeup if the link was in U3 before suspend. Move the basic controller register programming out of the one-time memory initialization path and make it reusable from the resume path. Also separate ring allocation from ring initialization so that rings can be reinitialized without reallocating DMA memory. Always perform the full suspend sequence regardless of the current link state. Previously, if the device was already in U3, the suspend callback returned early without stopping the controller, which could lead to commands being issued on a disabled slot during resume. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable Signed-off-by: Pawel Laszczak Acked-by: Peter Chen Link: https://patch.msgid.link/20260820-suspend_resume_fix-v3-1-5a713098b977@cadence.com Signed-off-by: Greg Kroah-Hartman commit 445fc368c6bc73eff0aeb3818cf5f355facfbb16 Author: Liu Qi Date: Fri Aug 21 17:04:16 2026 +0800 usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path. Reported-by: syzbot+22ea20ef3afb6785b122@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=22ea20ef3afb6785b122 Assisted-by: Qwen:Qwen3.6 Signed-off-by: Liu Qi Acked-by: Alan Stern Link: https://patch.msgid.link/20260821090416.1247127-1-liuqi@longcheer.com Signed-off-by: Greg Kroah-Hartman commit e52349a5ea6a74d46dfb703fcb64e08b5af28e8c Author: Keith Busch Date: Mon Aug 10 09:42:17 2026 -0700 loop, zloop: fix dma_alignment for large or unreported limits A file system sets STATX_DIOALIGN with zeroed alignments when the file can't be used for direct I/O. The zero underflowed to UINT_MAX and triggered a queue limits validation warning. Fall back to the block device's limits when dio_mem_align isn't reported. A file system with a block size larger than PAGE_SIZE may also report a memory alignment that can't be expressed as a queue limit. File systems fall back to buffered I/O for requests that don't meet their alignment, so cap the reported limit to the largest possible value. Fixes: 6c8dec275ccc ("loop: set dma_alignment from the backing file for direct I/O") Fixes: c5059c1af2bd ("zloop: set dma_alignment from the backing files for direct I/O") Reported-by: syzbot+ac00e7bf7ac8c91af921@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ac00e7bf7ac8c91af921 Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260810164218.3721636-1-kbusch@meta.com Signed-off-by: Jens Axboe commit 96c8ea3c5add7920b3c43840d1ea76b3354c8d2d Author: Keith Busch Date: Wed Aug 19 08:49:37 2026 -0700 block: save page offset gaps in cloned bio The cloned bio needs to inherit the accumulated gaps between vectors so that we can know if this bio can subscribe to the iova coalescing optimization. When cloning for a split, the gap only applies to the front bio since that's as far as has been processed. The remaining bio can reset its gaps to 0 since it advanced past the checked vectors, and will start its accounting from there on the next split check. Fixes: 2f6b2565d43c ("block: accumulate memory segment gaps per bio") Reported-by: Eric Auger Tested-by: Eric Auger Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260819154937.3903312-1-kbusch@meta.com Signed-off-by: Jens Axboe commit dd0eed9e165b1a6292f49e622e3dd0b7d99b106d Author: Lovekesh Solanki Date: Tue Aug 25 22:43:43 2026 +0530 USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently. Cc: stable Reported-by: Eulgyu Kim Link: https://lore.kernel.org/all/20260824113510.1141236-1-jjy600901@snu.ac.kr/ Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/all/20260824113510.1141236-1-jjy600901@snu.ac.kr/ Signed-off-by: Lovekesh Solanki Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260825171343.459630-1-lovekeshsolanki00@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7e07d3e4c389217d7d7171d80edf2e23ac70f1ea Author: Jeffin Philip Date: Sat Aug 15 11:10:06 2026 +0530 usb: gadget: f_midi: initialize work in f_midi_alloc() f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc(). Reported-by: syzbot+d5fa3d224505c8610702@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d5fa3d224505c8610702 Fixes: 8653d71ce376 ("usb/gadget: f_midi: Replace tasklet with work") Cc: stable Signed-off-by: Jeffin Philip Reviewed-by: Takashi Iwai Link: https://patch.msgid.link/20260815054006.102325-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit fed0aa7c6eaedc6c0d4e362fc91724aa47be4a7b Author: Ivy Lopez Date: Sat Aug 15 18:54:33 2026 -0600 usb: gadget: f_midi2: fix use-after-free in string attribute show path f_midi2_opts_str_show() takes the string lock internally, but its callers dereference the opts->info. pointer before calling it, outside the lock. This races with f_midi2_opts_str_store(), which frees the old string under opts->lock when the attribute is written concurrently, the show path can read a pointer that gets freed before the lock inside str_show() is even taken. Change f_midi2_opts_str_show() to take a pointer to the string field, matching the existing pattern in f_midi2_opts_str_store(), and dereference it only after the lock is held. Update all three callers (iface_name, block name, and the EP string option macro) accordingly. Reported-by: syzbot+2280f1cca5e6b0c353e4@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=2280f1cca5e6b0c353e4 Signed-off-by: Ivy Lopez Reviewed-by: Takashi Iwai Link: https://patch.msgid.link/20260816005434.34018-1-skunkolee@gmail.com Signed-off-by: Greg Kroah-Hartman commit e24e3370356bddb65d667985a332b5f8aeeb5f97 Author: Sven Peter Date: Thu Aug 13 20:16:15 2026 +0200 usb: typec: tipd: Fix Thunderbolt altmode VDOs for cd321x The Intel VID status register is actually 9 bytes long and doesn't contain the raw VDOs but only the upper 16bits for device mode and enter mode. Shift those two fields into place and reconstruct the cable discover mode VDO from the data status register instead since it's not directly accessible. With this fixed now the correct VDOs are forwarded to the PHY and the to-be-submitted Thunderbolt/USB4 native host interface so that the right mode can be negotiated and the link actually comes up. Link: https://www.ti.com/lit/ug/slvubh2b/slvubh2b.pdf Fixes: 0b31c978935f ("usb: typec: tipd: Read USB4, Thunderbolt and DisplayPort status for cd321x") Fixes: 82432bbfb9e8 ("usb: typec: tipd: Handle mode transitions for CD321x") Cc: stable Signed-off-by: Sven Peter Tested-by: Rafay Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260813-b4-tipd-vdo-fix-v1-1-70317f2cd554@kernel.org Signed-off-by: Greg Kroah-Hartman commit 85f080fb87ed5cd3e46121be677f52c82f26a0ab Author: Linkai Gong Date: Tue Sep 1 20:26:49 2026 +0800 Input: cyttsp5 - clamp the HID report size before memcpy The size field comes from the device and is used as the memcpy() length into response_buf, which is CY_MAX_INPUT bytes. Fixes: 5b0c03e24a06 ("Input: Add driver for Cypress Generation 5 touchscreen") Signed-off-by: Linkai Gong Link: https://patch.msgid.link/20260901122649.1173066-1-gonglinkai@kylinos.cn Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov commit f0efaf1872949e96d213c8e910fd9517f7d7c406 Author: Aleksandr Nogikh Date: Wed Jul 29 09:04:54 2026 +0000 usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs A null-pointer dereference occurs in f_midi2_free_ep_reqs() when attempting to clean up an endpoint that was never initialized. When configuring the MIDI 2.0 gadget via configfs and setting the block direction to SNDRV_UMP_DIR_INPUT, the initialization of the midi1_ep_out endpoint is explicitly skipped during the gadget bind phase (f_midi2_bind()). As a result, the usb_ep->card field remains NULL. Later, when the host sets the alternate setting, f_midi2_set_alt() unconditionally stops both the IN and OUT endpoints by calling f_midi2_stop_eps(), which in turn calls f_midi2_free_ep_reqs() for both endpoints. When f_midi2_free_ep_reqs() is called for the uninitialized midi1_ep_out, it attempts to dereference usb_ep->card to determine the number of requests to free, leading to a crash. Fix this by using usb_ep->num_reqs instead of usb_ep->card->info.num_reqs in f_midi2_free_ep_reqs(). usb_ep->num_reqs is correctly set during f_midi2_init_ep() and remains 0 if the endpoint was never initialized, safely avoiding the loop. For consistency, apply the same change to f_midi2_alloc_ep_reqs(). Oops: general protection fault, probably for non-canonical address 0xdffffc00000000ee: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000770-0x0000000000000777] ... RIP: 0010:f_midi2_free_ep_reqs drivers/usb/gadget/function/f_midi2.c:1166 [inline] RIP: 0010:f_midi2_stop_eps+0x28e/0x4d0 drivers/usb/gadget/function/f_midi2.c:1246 ... Call Trace: f_midi2_set_alt+0x11c/0xf00 drivers/usb/gadget/function/f_midi2.c:1296 composite_setup+0x1ffd/0x3480 drivers/usb/gadget/composite.c:1933 configfs_composite_setup+0xbd/0x100 drivers/usb/gadget/configfs.c:1877 Fixes: 8b645922b223 ("usb: gadget: Add support for USB MIDI 2.0 function driver") Cc: stable Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+bbb6dad313f4aaa8da6b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bbb6dad313f4aaa8da6b Link: https://syzkaller.appspot.com/ai_job?id=8ce30b1a-8cf7-4e38-bcf7-1f69e6f6313f Signed-off-by: Aleksandr Nogikh Reviewed-by: Takashi Iwai Closes: https://syzkaller.appspot.com/bug?extid=01a17afb30637396955e Link: https://patch.msgid.link/cafe65f4-e1bb-46a3-901d-732814b861b2@mail.kernel.org Signed-off-by: Greg Kroah-Hartman commit f84819ef8d66931ee3998fee3c4f03230f4cb6cc Author: Iván Ezequiel Rodriguez Date: Tue Sep 1 10:06:28 2026 -0300 Input: zero ff_effect before compat copy in input_ff_effect_from_user In the compat path input_ff_effect_from_user() aliases the caller's native struct ff_effect with the smaller struct ff_effect_compat and copies only the compat sized prefix: compat_effect = (struct ff_effect_compat *)effect; if (copy_from_user(compat_effect, buffer, sizeof(struct ff_effect_compat))) The tail of the native structure is never written. Callers pass an uninitialized on-stack object, for example evdev_do_ioctl() for EVIOCSFF, so those bytes keep their previous stack contents. input_ff_upload() then stores the full native structure in ff->effects[id], from where a uinput based force feedback daemon can read it back via UI_BEGIN_FF_UPLOAD, disclosing kernel stack memory to userspace. Zero the effect before the compat copy. Fixes: 2d56f3a32c0e ("Input: refactor evdev 32bit compat to be shareable with uinput") Cc: stable@vger.kernel.org Signed-off-by: Iván Ezequiel Rodriguez Link: https://patch.msgid.link/20260901130629.24078-3-ivanrwcm25@gmail.com Signed-off-by: Dmitry Torokhov commit 8b852965b8eaf910c314dc346967ed82c8d4f235 Author: Iván Ezequiel Rodriguez Date: Tue Sep 1 10:06:27 2026 -0300 Input: evdev - zero absinfo before partial copy in EVIOCSABS The EVIOCSABS handler copies at most the user supplied ioctl size into an uninitialized on-stack struct input_absinfo: if (copy_from_user(&abs, p, min_t(size_t, size, sizeof(struct input_absinfo)))) The size comes from _IOC_SIZE() of the ioctl command and is therefore fully controlled by userspace. A short size leaves the trailing part of the structure holding whatever was on the kernel stack, and the whole structure is then stored into the device: dev->absinfo[t] = abs; EVIOCGABS hands that back to userspace, disclosing the stale stack bytes. Only the resolution field is currently cleared, which covers the legacy struct layout but not an arbitrarily short size. Zero the structure before the copy so any part not supplied by the caller reads back as zero. The existing resolution fixup is kept, since it also handles a size that partially overlaps that field. Fixes: 448cd1664a57 ("Input: evdev - rearrange ioctl handling") Cc: stable@vger.kernel.org Signed-off-by: Iván Ezequiel Rodriguez Link: https://patch.msgid.link/20260901130629.24078-2-ivanrwcm25@gmail.com Signed-off-by: Dmitry Torokhov commit c9a48db776d7184981630ecc01a3ad30a8f7dc24 Author: Chang Wu Date: Wed Aug 19 23:20:27 2026 +0800 usb: typec: hd3ss3220: track VBUS enable state per consumer regulator_is_enabled() reports the aggregate regulator state, not whether this consumer holds an enable reference. If another consumer enables VBUS first, the driver can skip its own regulator_enable() call and later attempt to drop a reference it never acquired, triggering an unbalanced regulator disable warning. Track successful enable and disable calls locally. Keep the state unchanged when an operation fails so a later role or ID notification retries the operation while this consumer keeps balanced references. Fixes: b3f9d6e491fd ("usb: typec: hd3ss3220: Check if regulator needs to be switched") Cc: stable Link: https://github.com/qualcomm-linux/kernel/issues/472 Signed-off-by: Chang Wu Reviewed-by: Heikki Krogerus Tested-by: Jan Remmet Reviewed-by: Krishna Kurapati Link: https://patch.msgid.link/20260819152027.90994-1-kunjinkao.jp@gmail.com Signed-off-by: Greg Kroah-Hartman commit b58e6200450d350314db0ecda7d6d1bde3281e80 Author: Elson Serrao Date: Thu Aug 13 08:14:56 2026 -0700 usb: dwc3: clear forceRM when issuing EndTransfer The forceRM bit of the DEPCMD register controls the behavior of the EndTransfer command used to stop an active transfer. Older DWC3 programming guide revisions recommended setting forceRM=1 when issuing EndTransfer. Newer programming guide revisions recommend issuing EndTransfer with forceRM cleared. With forceRM=1 on DWC_usb31 v2.00a and v2.10a controllers, a transfer aborted through the ep_dequeue path was observed to remain active after EndTransfer completion. A subsequent StartTransfer issued on the same endpoint triggered writes associated with the aborted transfer. This resulted in an SMMU fault because the transfer buffer had already been unmapped during EndTransfer command-completion cleanup. Using forceRM=0 eliminates the issue. Although older DWC3 programming guide revisions recommended setting forceRM=1, no issues are known from using forceRM=0. Clear forceRM when issuing EndTransfer to provide consistent EndTransfer behavior and align with newer programming guide recommendations. Fixes: 1e43c86d84fb ("usb: dwc3: core: Add DWC31 version 2.00a controller") Cc: stable Signed-off-by: Elson Serrao Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260813151456.867008-1-elson.serrao@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 6b2a674fcc953378e5e750d47a888bbe51229de5 Author: Radhey Shyam Pandey Date: Wed Aug 19 23:51:58 2026 +0530 usb: dwc3: google: Initialise probe properties with DWC3_DEFAULT_PROPERTIES dwc3_google_probe() zero initialises struct dwc3_probe_data and never assigns its properties member. The unspecified state of gsbuscfg0_reqinfo is encoded as DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED (0xffffffff), not as zero, so dwc3_get_software_properties() reads the zeroed field as a value the glue explicitly requested: if (properties->gsbuscfg0_reqinfo != DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED) { dwc->gsbuscfg0_reqinfo = properties->gsbuscfg0_reqinfo; return; } Two things follow. dwc3_config_soc_bus() programs GSBUSCFG0.REQINFO with zero on hardware that never asked for it, and the early return skips the walk over the parent devices, so a swnode or device tree supplied snps,gsbuscfg0-reqinfo would be ignored. Assign DWC3_DEFAULT_PROPERTIES so the unset fields carry their unspecified sentinels and the controller is left alone. Fixes: 8995a37371bf ("usb: dwc3: Add Google Tensor SoC DWC3 glue driver") Cc: stable Signed-off-by: Radhey Shyam Pandey Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260819182158.1351869-1-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman commit d50b6442bef66abbe4694f918f8ad013f81d75cf Author: Marek Vasut Date: Sat Aug 22 09:24:58 2026 +0200 usb: typec: mux: avoid duplicated mux switches Some devices use combo PHYs (i.e. USB3 + DisplayPort), which also handle the lane muxing. These PHYs are referenced twice from the USB-C connector (USB super-speed lines and SBU/AUX lines) resulting in the mux being configured twice. Avoid this by dropping duplicates. This is a re-application of b145c3f29d62 ("usb: typec: mux: avoid duplicated mux switches"), with fix derived from usb: typec: mux: Fix typec_switch_match() . Fixes: f576c75f95a5 ("Revert "usb: typec: mux: avoid duplicated mux switches"") Cc: stable Signed-off-by: Sebastian Reichel Co-developed-by: Sebastian Reichel Signed-off-by: Marek Vasut Tested-by: Jens Glathe Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260822072556.490594-1-marex@nabladev.com Signed-off-by: Greg Kroah-Hartman commit dea99705bc8fcda12590cfeeae6d2ba47a7ef572 Author: Marek Vasut Date: Mon Aug 17 20:22:39 2026 +0200 usb: typec: mux: Fix typec_switch_match() The fwnode_typec_switch_get() sporadically returns NULL instead of an -EPROBE_DEFER for orientation-switch described in DT. This makes it impossible to discern whether the DT does describe an orientation-switch which did not probe yet, or whether the DT does not describe the switch. This happens with gpio-sbu-mux connected to an I2C GPIO expander. The class_find_device() on typec_switch_match() may return NULL in case the mux did not probe just yet early on boot. The sw_devs[] array can be empty on boot as well. If these two conditions occur, then the conditional if (to_typec_switch_dev(dev) == sw_devs[i]) evaluates to true and the match function returns NULL, which propagates to fwnode_typec_switch_get() which makes it look as if the orientation-switch was not described in DT. This is incorrect, because the mux driver will probe a bit later on, but at that point, the caller of fwnode_typec_switch_get() already got the NULL return value. The NULL return value also does not trigger IS_ERR(), therefore the caller driver interprets this as if the orientation-switch is not described in DT, and does not return -EPROBE_DEFER to try again, even if it should. Fix this by checking the class_find_device() return value, and return -EPROBE_DEFER if it is NULL right away. If the return value is not NULL, perform the deduplication test, and if that test passes, consider the return value to be already non-NULL. Fixes: a53b4f9c51a9 ("usb: typec: mux: avoid duplicated orientation switches") Cc: stable Signed-off-by: Marek Vasut Reviewed-by: Sebastian Reichel Tested-by: Jens Glathe Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260817182302.146546-1-marex@nabladev.com Signed-off-by: Greg Kroah-Hartman commit 2430eb81e44111b30eeb5273bbcf8b24ca517ef9 Author: Griffin Kroah-Hartman Date: Wed Aug 19 12:04:25 2026 +0200 usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify() Assisted-by: gkh_clanker_t1000 Cc: stable Signed-off-by: Griffin Kroah-Hartman Link: https://patch.msgid.link/20260819-usb_misc_random-v1-1-43a0dcee3a32@kroah.com Signed-off-by: Greg Kroah-Hartman commit ce58f5a1843235d800ad724e86a3cf5c9c6f08ab Author: Benjamin Tissoires Date: Tue Aug 25 11:55:13 2026 +0200 selftests/hid: prepare test_rdesc_fixup_get_data_overflow for the new verifier The new verifier in the bpf-next branch is now capable of detecting the overflow that was triggered by test_rdesc_fixup_get_data_overflow. This is better in terms of UI, but now the test is failing and should be marked as expected to fail. Add a new parameter to load_programs() when we expect the test to fail, and dynamically validate the test by checkcing if it loads (it should fail to load with new verifier), but if it still loads, HID-BPF should detect the overflow itself and return an error in hid_bpf_get_data(). Signed-off-by: Benjamin Tissoires commit 1fb68c2e76386ac663819036c2c75cd476e433c1 Author: Benjamin Tissoires Date: Tue Aug 25 11:55:12 2026 +0200 selftests/hid: Add a test to ensure we can write fields in hid_device hid_device->{name,uniq,phys} are all writeable fields, we need to have tests for them in case the verifier becomes too much strict. Signed-off-by: Benjamin Tissoires commit 67bfe48a29fbddfff77e13d4d327e49fca2c2be5 Author: Benjamin Tissoires Date: Tue Aug 25 11:55:11 2026 +0200 HID: bpf: mark struct hid_device as safe BPF pointer Commit ee9ad135b208 ("bpf: Reject a store through a fault prone pointer") in the BPF tree makes the verifier reject any writes to hid_device->{name,uniq,phys}. A simple solution is to mark the struct hid_device as safe from a BPF point of view. Suggested-by: Daniel Borkmann Signed-off-by: Benjamin Tissoires commit 1af874e9f4ce22ccf8b10ab5462f32c70d3be21a Author: Shuangpeng Bai Date: Sun Aug 16 00:45:10 2026 -0400 IB/mlx4: Fix use-after-free on pkey sysfs registration failure register_pkey_tree() ignores errors from register_one_pkey_tree() and continues registering the remaining slaves. The per-slave error path has already released the pkey parent kobjects, but their pointers remain stored in the device. A later device cleanup therefore passes the stale pointers to kobject_put(), causing a use-after-free. Clear the parent pointers after releasing a failed slave tree and skip unregistered trees during device cleanup. This preserves the existing best-effort registration behavior while preventing a second cleanup of the failed tree. Fixes: c1e7e466120b ("IB/mlx4: Add iov directory in sysfs under the ib device") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Link: https://patch.msgid.link/20260816044510.3848996-1-shuangpeng.kernel@gmail.com Signed-off-by: Leon Romanovsky commit a44a3f175eaee7e5aeb6a8fed381c4a0d5f49236 Author: Or Har-Toov Date: Tue Aug 11 19:19:16 2026 +0300 RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency Commit 51976c6cd786 ("RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages") introduced disassociation_lock to protect new mmap registrations against uverbs_user_mmap_disassociate(), but created an ABBA deadlock: Thread A (mmap / fork): mmap_lock -> disassociation_lock Thread B (disassociate): disassociation_lock -> mmap_lock Fix by removing disassociation_lock entirely and using the pre-existing hw_destroy_rwsem instead. hw_destroy_rwsem already provides the same protection: rdma_umap_open() and ib_uverbs_mmap() both use down_read_trylock() before registering a new VMA, so holding hw_destroy_rwsem in uverbs_user_mmap_disassociate() is sufficient to block new registrations. trylock is used in both mmap paths (not blocking down_read) because mmap_lock is already held on entry, and uverbs_user_mmap_disassociate() acquires mmap_lock internally — a blocking read would recreate the same deadlock. The only caller that was not taking hw_destroy_rwsem for write was rdma_user_mmap_disassociate(). Fix it to take the rwsem per-ufile while iterating under lists_mutex. This is safe because ib_uverbs_close() releases hw_destroy_rwsem entirely before acquiring lists_mutex, so the two locks are never held simultaneously. lockdep warning: [ 776.654252] ====================================================== [ 776.655214] WARNING: possible circular locking dependency detected [ 776.656167] 6.18.0for-upstream_debug_94e244d9ccab #1 Not tainted [ 776.657114] ------------------------------------------------------ [ 776.658087] devlink/14824 is trying to acquire lock: [ 776.658879] ffff88811170c800 (&mm->mmap_lock){++++}-{4:4}, at: uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs] [ 776.660479] [ 776.660479] but task is already holding lock: [ 776.661460] ffff888142d92b08 (&file->disassociation_lock){+.+.}-{4:4}, at: uverbs_user_mmap_disassociate+0x39/0x780 [ib_uverbs] [ 776.663177] [ 776.663177] which lock already depends on the new lock. [ 776.663177] [ 776.664525] [ 776.664525] the existing dependency chain (in reverse order) is: [ 776.665724] [ 776.665724] -> #2 (&file->disassociation_lock){+.+.}-{4:4}: [ 776.666887] __mutex_lock+0x16d/0x2330 [ 776.667633] rdma_umap_open+0x129/0x280 [ib_uverbs] [ 776.668489] dup_mmap+0xa40/0x1790 [ 776.669170] copy_process+0x5dd2/0x6170 [ 776.669933] kernel_clone+0xb6/0x610 [ 776.670636] __do_sys_clone+0xb5/0xf0 [ 776.671354] do_syscall_64+0x70/0x12e0 [ 776.672083] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.672940] [ 776.672940] -> #1 (&mm->mmap_lock/1){+.+.}-{4:4}: [ 776.673985] down_write_nested+0x90/0x1e0 [ 776.674751] dup_mmap+0x201/0x1790 [ 776.675448] copy_process+0x5dd2/0x6170 [ 776.676180] kernel_clone+0xb6/0x610 [ 776.676904] __do_sys_clone+0xb5/0xf0 [ 776.677615] do_syscall_64+0x70/0x12e0 [ 776.678351] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.679239] [ 776.679239] -> #0 (&mm->mmap_lock){++++}-{4:4}: [ 776.680253] __lock_acquire+0x18c6/0x2ec0 [ 776.681018] lock_acquire+0x10e/0x2e0 [ 776.681742] down_read+0x95/0x430 [ 776.682395] uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs] [ 776.683436] uverbs_destroy_ufile_hw+0x1ae/0x270 [ib_uverbs] [ 776.684416] ib_uverbs_remove_one+0x22b/0x420 [ib_uverbs] [ 776.685371] remove_client_context+0xa6/0xf0 [ib_core] [ 776.686342] disable_device+0x12b/0x240 [ib_core] [ 776.687249] __ib_unregister_device+0x269/0x460 [ib_core] [ 776.688233] ib_unregister_device+0x21/0x30 [ib_core] [ 776.689140] mlx5r_remove+0xd0/0x170 [mlx5_ib] [ 776.689999] device_release_driver_internal+0x3b2/0x560 [ 776.694876] bus_remove_device+0x1f5/0x3e0 [ 776.695638] device_del+0x3b9/0x990 [ 776.696329] mlx5_detach_device+0x17e/0x350 [mlx5_core] [ 776.697429] mlx5_unload_one_devl_locked+0x3f/0xb0 [mlx5_core] [ 776.698578] mlx5_devlink_reload_down+0x1f9/0x550 [mlx5_core] [ 776.699712] devlink_reload+0x13e/0x680 [ 776.700456] devlink_nl_reload_doit+0xc29/0x1160 [ 776.701293] genl_family_rcv_msg_doit+0x1c9/0x2a0 [ 776.702135] genl_rcv_msg+0x3f0/0x6b0 [ 776.702854] netlink_rcv_skb+0x11d/0x370 [ 776.703605] genl_rcv+0x24/0x40 [ 776.704236] netlink_unicast+0x5b4/0x970 [ 776.704984] netlink_sendmsg+0x730/0xbf0 [ 776.705748] __sock_sendmsg+0xc5/0x190 [ 776.706461] __sys_sendto+0x201/0x2f0 [ 776.707188] __x64_sys_sendto+0xdc/0x1b0 [ 776.707931] do_syscall_64+0x70/0x12e0 [ 776.708643] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.709546] [ 776.709546] other info that might help us debug this: [ 776.709546] [ 776.710910] Chain exists of: [ 776.710910] &mm->mmap_lock --> &mm->mmap_lock/1 --> &file->disassociation_lock [ 776.710910] [ 776.712805] Possible unsafe locking scenario: [ 776.712805] [ 776.713828] CPU0 CPU1 [ 776.714589] ---- ---- [ 776.715347] lock(&file->disassociation_lock); [ 776.716097] lock(&mm->mmap_lock/1); [ 776.717067] lock(&file->disassociation_lock); [ 776.718199] rlock(&mm->mmap_lock); [ 776.718857] [ 776.718857] *** DEADLOCK *** Fixes: 51976c6cd786 ("RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages") Signed-off-by: Or Har-Toov Signed-off-by: Leon Romanovsky Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260811-fix-mmap-lockdep-v1-1-1151b41063b4@nvidia.com Acked-by: Junxian Huang Signed-off-by: Leon Romanovsky commit 2dc65035eb8d9f4b4495a8bc044f10f44974a9c6 Author: Niranjan H Y Date: Tue Sep 1 10:11:32 2026 +0800 ASoC: Intel: sof_sdw: add tac5xx2-sdw family Add Texas Instrument's tac5xx2-sdw family to include support for soundwire codecs tac5572, tac5682 Signed-off-by: Niranjan H Y Signed-off-by: Bard Liao Link: https://patch.msgid.link/20260901021132.231908-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown commit cc7cd2a9228175c975f62ad56ed7c767701cb4fa Author: Muhammad Bilal Date: Tue Sep 1 16:30:31 2026 +0500 staging: sm750fb: fix mono image source stride mismatch in lynxfb_ops_imageblit() sm750_hw_imageblit() advances its monochrome source pointer by src_delta per scanline, and computes the correct rounded-up stride internally as: bytes_per_scan = (width + start_bit + 7) / 8; Its only caller, lynxfb_ops_imageblit(), instead passed src_delta as image->width >> 3. For widths not a multiple of 8 this under-counted the stride, so the source pointer fell further behind the real per-scanline layout on every line, corrupting the rendered image. Rather than just fixing the caller's calculation, remove src_delta as a parameter entirely and have sm750_hw_imageblit() advance by the bytes_per_scan it already computes for itself. There has only ever been one caller, and that caller was passing an out-of-sync derivative of the same width/start_bit values sm750_hw_imageblit() already has, so keeping stride as a separate parameter served no purpose beyond letting the two calculations drift apart, which is exactly what happened here. Rounding up, rather than down, is the direction consistent with the rest of the fbdev core: struct fb_image mono bitmap data (the same image->data this driver receives) is walked elsewhere with byte strides derived from a ceiling division of width by 8. The generic mono bit iterator in drivers/video/fbdev/core/fb_imageblit.h advances scanlines with "iter->data += BITS_TO_BYTES(iter->width)", and BITS_TO_BYTES() (include/linux/bitops.h) is a ceiling division. sm750_hw_imageblit()'s own "(width + start_bit + 7) / 8" is that same ceiling division with an added start_bit offset, so the caller's ">> 3" (floor) was the one calculation out of step with how this data layout is handled everywhere else. Found by code review of sm750_hw_imageblit()'s internal stride calculation against what its only caller was passing in, and confirmed with a clean -Werror build. I do not have this hardware, so this has not been exercised at runtime on real sm750 silicon. Fixes: 81dee67e215b2 ("staging: sm750fb: add sm750 to staging") Cc: stable@vger.kernel.org Reviewed-by: Dan Carpenter Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260901113031.161610-1-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman commit ef9fbe1b93f3b617b96e86d5cd76b3fa44514cb5 Author: Krystian Kaniewski Date: Wed Aug 12 10:16:41 2026 +0200 RDMA/core: Reject unregistering netdevs in ib_get_eth_speed ib_device_get_netdev() intentionally returns a referenced net_device even when it is unregistering, so matching and cleanup callers can still find the association. The reference keeps struct net_device allocated, but does not guarantee that the device remains operational. ib_get_eth_speed() uses the returned device operationally by invoking its ethtool callback. Although that call is made under RTNL, the function does not verify the registration state first. An asynchronous RDMA port query can therefore call into a netdev after NETDEV_UNREGISTER and ndo_uninit have completed. Check for NETREG_REGISTERED while holding RTNL and return -ENODEV for a device which is being unregistered. Keeping RTNL across the check and the ethtool operation prevents unregister from starting between them. Keep the speed fallback and warning under RTNL as well, so the warning can safely read netdev->name. Drop the netdev reference before releasing RTNL once all accesses to the device are complete. Fixes: d41861942fc5 ("IB/core: Add generic function to extract IB speed from netdev") Reported-by: syzbot+5fe14f2ff4ccbace9a26@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5fe14f2ff4ccbace9a26 Signed-off-by: Krystian Kaniewski Link: https://patch.msgid.link/20260812081708.32468-1-krystianmkaniewski@gmail.com Signed-off-by: Leon Romanovsky commit 4ca00a9154f998116fba9a32cce5bd938d228065 Author: Claudio Imbrenda Date: Fri Aug 28 13:54:39 2026 +0200 KVM: s390: Fix race in _destroy_pages_crste() Use READ_ONCE() in _destroy_pages_crste() to read the crste, avoid dereferencing the pointer multiple times. Fixes: a2c17f9270cc ("KVM: s390: New gmap code") Signed-off-by: Claudio Imbrenda Message-ID: <20260828115439.145885-9-imbrenda@linux.ibm.com> commit 27554b9505ddfc0aeab466aeb60929dfa17284c7 Author: Claudio Imbrenda Date: Fri Aug 28 13:54:38 2026 +0200 KVM: s390: Fix potential races in dat skey functions When dat_cond_set_storage_key() finds a large page, it will conditionally set the storage key in absolute memory using large_crste_to_phys() to get the absolute address. There is a race window between dat_entry_walk() and large_crste_to_phys(): the large page could have been split concurrently, and large_crste_to_phys() might be called with a crste that does not designate a large page, leading to crashes. Similar issues were also present in dat_set_storage_key(). dat_get_storage_key() and dat_reset_reference_bit() did instead check for a potential concurrent splitting of the large page, but then handled it incorrectly. Fix by performing a READ_ONCE on the crste pointer, checking and using the result, instead of dereferencing the pointer again. In case a race is detacted, try dat_entry_walk() again. Fixes: 8e03e8316eb2 ("KVM: s390: KVM page table management functions: storage keys") Signed-off-by: Claudio Imbrenda Message-ID: <20260828115439.145885-8-imbrenda@linux.ibm.com> commit f3a557067d57ce6ae98d485c8009b223e16f5f36 Author: Claudio Imbrenda Date: Fri Aug 28 13:54:37 2026 +0200 KVM: s390: Add missing srcu in kvm_s390_set_irq_state() Like kvm_s390_inject_vcpu(), kvm_s390_set_irq_state() also needs the kvm->srcu or the slots lock when performing the Store status operation. Fix by taking kvm->srcu in kvm_s390_set_irq_state(). Fixes: ba5c1e9b6cee ("KVM: s390: interrupt subsystem, cpu timer, waitpsw") Fixes: 062e44a9319f ("KVM: s390: Use srcu in kvm_arch_vcpu_unlocked_ioctl()") Signed-off-by: Claudio Imbrenda Message-ID: <20260828115439.145885-7-imbrenda@linux.ibm.com> commit 19192a4043277af380f83d550a55b92eeeaac7c6 Author: Claudio Imbrenda Date: Fri Aug 28 13:54:36 2026 +0200 KVM: s390: Move all code into s390_kvm_mmu_prepare_memory_region() Move all code from s390_kvm_mmu_commit_memory_region() into s390_kvm_mmu_prepare_memory_region(). This allows the function to fail gracefully if needed. The previous behaviour was to print a warning and continue execution with page tables inconsistent with the memslots. Fixes: e38c884df921 ("KVM: s390: Switch to new gmap") Signed-off-by: Claudio Imbrenda Message-ID: <20260828115439.145885-6-imbrenda@linux.ibm.com> commit 00c0ae5e438615bde828a3b9f33912960f4e6511 Author: Claudio Imbrenda Date: Fri Aug 28 13:54:35 2026 +0200 KVM: s390: Refactor dat_set_slot() Refactor dat_set_slot(), _dat_slot_pte(), _dat_slot_crste(). Now they only take a struct kvm_s390_mmu_cache as priv. For dat_delete_slot(), mc is NULL, as no allocations should take place. This is needed as a prerequisite to move gmap DAT table setup from kvm_arch_commit_memory_region() to kvm_arch_prepare_memory_region(). Signed-off-by: Claudio Imbrenda Message-ID: <20260828115439.145885-5-imbrenda@linux.ibm.com> commit faff4c8ff3dbec6d71b89dd281a0d17c4478fa44 Author: Claudio Imbrenda Date: Fri Aug 28 13:54:34 2026 +0200 KVM: s390: Fix _gaccess_shadow_fault() In some circumstances, it is possible that the page of nested guest memory that is being shadowed is not present at all in the parent guest gmap. dat_entry_walk() will not find any leaf entry and return with -ENOENT, which will erroneously be propagated all the way to userspace. Fix by manually calling gmap_link() on the memory of the nested guest that is being shadowed if the mapping was not already present. Fixes: e38c884df921 ("KVM: s390: Switch to new gmap") Signed-off-by: Claudio Imbrenda Message-ID: <20260828115439.145885-4-imbrenda@linux.ibm.com> commit ae12d2f9c119639a142d92c4a37c30277e8576da Author: Claudio Imbrenda Date: Fri Aug 28 13:54:33 2026 +0200 KVM: s390: Fix compile warning for kvm_s390_update_cmma_dirty() The parameter "old" should be marked as const, to prevent compile-time warnings. Fixes: d487a24041c2 ("KVM: s390: Prepare gmap for a second KVM implementation") Signed-off-by: Claudio Imbrenda Message-ID: <20260828115439.145885-3-imbrenda@linux.ibm.com> commit d215f014b3526a9898d87bfb4b866287f0864cc9 Author: Claudio Imbrenda Date: Fri Aug 28 13:54:32 2026 +0200 KVM: s390: Fix dirty marking in adapter_indicators_set*() When the indicator and/or summary bits are set in the guest, the accessed page was only marked dirty in KVM if the access was performed using the slow path; accesses through the new kvm_arch_set_irq_inatomic fast inject path would not mark the page as dirty. Fix by adding/moving the missing calls to mark_page_dirty(). Note that for the inatomic path set_page_dirty{,_lock}() is not needed as the page stays pinned; the unpin path correctly marks it as dirty. Opportunistically reorder the local variables to be in reverse Christmas tree order and refactor to use guard(). Fixes: 1e95e3bc6b05 ("KVM: s390: Enable adapter_indicators_set to use mapped pages") Signed-off-by: Claudio Imbrenda Message-ID: <20260828115439.145885-2-imbrenda@linux.ibm.com> commit 1b67e0d3b9691d7b6b74e18960ddd2be24f9dc9d Author: wangdicheng Date: Mon Aug 24 14:35:07 2026 +0800 ASoC: amd: yc: fix memory leak in acp6x_pdm_dma_close() acp6x_pdm_dma_close() does not free the runtime->private_data buffer allocated in acp6x_pdm_dma_open(). Add the missing kfree. Fixes: 7610174a5bfe ("ASoC: amd: add acp6x pdm platform driver") Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260824063507.483784-2-wangdich9700@163.com Signed-off-by: Mark Brown commit 0c06c4ce0206290c9a934a1e7196aaa86adfe018 Author: wangdicheng Date: Mon Aug 24 14:35:06 2026 +0800 ASoC: amd: renoir: fix disable_pdm_interrupts() to clear mask bits disable_pdm_interrupts() uses |= ~PDM_DMA_INTR_MASK which sets all bits except the PDM DMA interrupt bit instead of clearing only the PDM DMA interrupt bit. Use &= ~PDM_DMA_INTR_MASK to clear only the target bit. Fixes: f621a3676d3f ("ASoC: amd: add ACP3x PDM platform driver") Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260824063507.483784-1-wangdich9700@163.com Signed-off-by: Mark Brown commit 2be77295316c2dff0a33c0dc3a65abdab4ccf796 Author: Or Har-Toov Date: Tue Aug 11 19:25:57 2026 +0300 RDMA/mlx5: Remove warn on missing representor in query_port_speed The representor ib_device's phys_port_cnt is set to the total vport count when the uplink vport rep loads. Individual port[i].rep entries are populated only as each VF/SF vport rep registers. A NULL .rep for a given port index is therefore expected while VF reps are still loading or haven't been enabled yet. Tools like ibstat and ibv_devinfo iterate over all ports of all RDMA devices. Some ports may not have an eswitch representor, causing repeated dmesg warnings when these tools run without a device argument. This causes dmesg to be flooded with this message on every ibstat invocation. Remove the warning and return -ENODEV when no representor exists for the queried port. Fixes: aaecff5e13cd ("RDMA/mlx5: Implement query_port_speed callback") Signed-off-by: Or Har-Toov Reviewed-by: Shay Drory Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260811-remove-warn-on-miss-rep-v1-1-eccf399bc6af@nvidia.com Signed-off-by: Leon Romanovsky commit 62f0f34fbd2b2d5653d33d3b9d42fdcabb1c0101 Author: Shuhei Takeshita Date: Sun Aug 9 12:27:43 2026 +0900 IB/hfi1: Fix the PIO_CRED credit-return mmap hfi1_file_mmap()'s PIO_CRED case must hand user space the single credit-return page that holds this context's entry. That page is the second or third page of the per-node credit-return allocation once the hardware send context index reaches 64 or 128, so the failure below is intermittent: when the entry lands on the first page the offset is zero and everything works. Two things are wrong. First, cr_page_offset is a byte offset but .va is a struct credit_return *, so adding it is pointer arithmetic and scales the offset by sizeof(struct credit_return) == 64. memvirt then lands 256 KiB or 512 KiB past a 10240-byte allocation. With an IOMMU translating, that address is inside the vmalloc range but in no vm_area, so dma_mmap_coherent() -> iommu_dma_mmap() finds no pages, vmalloc_to_pfn() returns page_to_pfn(NULL), and remap_pfn_range() installs a frame above MAXPHYADDR. The first user read then takes: psm2_ep_open_pr: Corrupted page table at address 7a14d007e000 PGD 800000013886a067 P4D 800000013886a067 PUD 13886b067 PMD 13886c067 PTE 800049168e911235 Oops: Bad pagetable: 000d [#1] SMP PTI Second, and still wrong once the arithmetic is corrected, dma_mmap_coherent() describes a whole coherent buffer and selects the page within it with vma->vm_pgoff. Offsetting cpu_addr has no effect: for a vmap'd allocation iommu_dma_mmap() uses cpu_addr only to locate the vm_area and then maps pages[vm_pgoff], which hfi1_file_mmap() has just set to 0. User space therefore always receives the first credit-return page, every credit read is for the wrong context, and send PIO stalls forever. Use the DMA API as intended: pass the base of the allocation with its full length and select the page with vm_pgoff. A separate length is needed because memlen must keep describing the VMA for the existing size check. The dma-direct path stays correct as well, since dma_direct_mmap() adds the same vm_pgoff to the base pfn. Tested on a Dell T7610 (Xeon E5-2650 v2, Intel IOMMU in DMA-FQ mode) against a Threadripper PRO 3995WX peer, both Omni-Path 100. Before this change psm2_ep_open() Oopses the kernel; with only the arithmetic corrected psm2_ep_open() succeeds but any transfer that uses send PIO hangs, PSM2_SDMA=2 (send PIO disabled) completing normally while PSM2_SDMA=0 (send PIO only) hangs every time. With this change send PIO, send DMA and the default mixed mode all work. Fixes: 1ec82317a1da ("IB/hfi1: Use dma_mmap_coherent for matching buffers") Cc: stable@vger.kernel.org Signed-off-by: Shuhei Takeshita Link: https://patch.msgid.link/20260809032743.2671579-3-jyohuku.alterego@gmail.com Signed-off-by: Leon Romanovsky commit 975396b9e5a4028e649f4b9a6a5ca5dfb76a824b Author: Shuhei Takeshita Date: Sun Aug 9 12:27:42 2026 +0900 IB/hfi1: Resolve the credit-return buffer through the send context's node hfi1_file_mmap()'s PIO_CRED case derives this context's credit-return page offset, and the DMA handle for it, from dd->cr_base[uctxt->numa_id]. uctxt->numa_id is the node of whichever CPU the process happened to be running on, but the entry itself lives in the credit-return allocation of the send context's own node: sc->hw_free = &sc->dd->cr_base[sc->node].va[gc].cr[index]; and user send contexts are allocated with sc_alloc(dd, SC_USER, ..., dd->node), the HFI-local node. On a multi-socket host with the process running off that node the two allocations differ, so the subtraction produces an offset into an unrelated buffer and the DMA handle belongs to the wrong allocation. Use the send context's own node for all three references. The continuation lines are reindented at the same time; they mixed spaces and tabs. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Cc: stable@vger.kernel.org Signed-off-by: Shuhei Takeshita Link: https://patch.msgid.link/20260809032743.2671579-2-jyohuku.alterego@gmail.com Signed-off-by: Leon Romanovsky commit 2ccb8878c149443c6acf628b438c9c942c20abb2 Author: Ming-Hung Tsai Date: Tue Aug 18 18:05:47 2026 +0800 dm cache: fix demotion stats in passthrough mode The demotion counter is incremented per incoming write bio before the invalidation begins, causing the demotion count to exceed the actual number of cached blocks when multiple bios target the same cached block. Additionally, the counter is incremented unconditionally regardless of invalidation failure. Reproduce steps: 1. Create a cache device consisting of 512 cache entries modprobe brd rd_size=262144 dmsetup create cmeta --table "0 8192 linear /dev/ram0 0" dmsetup create cdata --table "0 65536 linear /dev/ram0 8192" dmsetup create corig --table "0 65536 linear /dev/ram0 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 65536 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Populate the cache, and record the number of cached blocks fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --direct=1 --ioengine=libaio --iodepth=32 --io_size=2048m nr_cached=$(dmsetup status cache | awk '{split($7, a, "/"); print a[1]}') 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 65536 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the passthrough cache with multiple jobs to trigger multiple bios hitting the same cached block. fio --filename=/dev/mapper/cache --name=test --rw=write --bs=4k \ --direct=1 --ioengine=libaio --iodepth=32 --numjobs=4 5. Check if demoted matches cached block count. These numbers should match but may differ due to overcounting per bio. nr_demoted=$(dmsetup status cache | awk '{print $12}') echo "$nr_cached, $nr_demoted" Fix by moving the demotion counter increment into invalidate_complete(), gated on the success flag. Reported-by: Ben Marzinski Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Cc: stable@vger.kernel.org Signed-off-by: Ming-Hung Tsai Reviewed-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka commit 1d2929d0850fff683b8aff051275945e65f082c8 Author: Norbert Szetei Date: Sat Aug 29 18:56:18 2026 +0200 net: psp: do not inherit the Rx association on clone sk->psp_assoc sits past sk_dontcopy_end, so sock_copy() copies it into every socket accepted from a listener without taking a reference, while inet_sock_destruct() puts for every inet socket. psp_twsk_init() does refcount_inc() for the timewait socket, so a child closing through TIME_WAIT cancels its own put and leaves the association with one reference and N timewait sockets holding the same pointer. Closing the listener frees it, and the timewait timers then put freed memory. Rejecting the association on a listening socket is not sufficient: a socket can acquire one while established and then be turned back into a listener, because tcp_disconnect() leaves sk->psp_assoc in place. BUG: KASAN: slab-use-after-free in psp_twsk_assoc_free+0x6f/0xf0 Write of size 4 at addr ffff888110f9255c by task swapper/7/0 psp_twsk_assoc_free+0x6f/0xf0 inet_twsk_put+0xda/0x1b0 call_timer_fn+0x53/0x2e0 __run_timers+0x764/0xa80 Freed by task 99: kfree+0x1a7/0x500 process_one_work+0x7ec/0x1100 An association carries a per-connection SPI and key, so a child must not inherit the parent's. Clear it on clone. Fixes: 6b46ca260e22 ("net: psp: add socket security association code") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei Reviewed-by: Daniel Zahka Link: https://patch.msgid.link/BC10EB92-ABB3-41B2-AB16-266BEEBE18C0@doyensec.com Signed-off-by: Paolo Abeni commit 4ed5bfc41071a48d609a6eaf41d68b2fd09e69d6 Author: Jairaj Arava Date: Tue Sep 1 09:19:51 2026 +0800 ASoC: Intel: sof_rt5682: Add support for nvl_max98360a_rt5682 This patch adds the driver data for rt5682 codec on SSP0 and max98360a speaker amplifiers on SSP1 for NVL platform. The existing one is not aligned with PTL. Hence, changed it to align with the working changes in PTL. Signed-off-by: Jairaj Arava Reviewed-by: Péter Ujfalusi Signed-off-by: Bard Liao Link: https://patch.msgid.link/20260901011951.230315-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown commit 1caceeb2d74bbe88223aea55eb8626b4c5f076fd Author: Michael Bommarito Date: Tue Jun 16 22:27:28 2026 -0400 RDMA/rxe: insert mcg into mcg_tree only after rxe_mcast_add() succeeds rxe_get_mcg() publishes a newly allocated multicast group in rxe->mcg_tree before programming the backing Ethernet multicast address with rxe_mcast_add(), which runs outside mcg_lock. A local userspace RDMA client reaches this path with ATTACH_MCAST on a UD QP; if rxe_mcast_add() then returns an error (for example -ENODEV when the backing netdev has been removed, or a propagated dev_mc_add() error), the unwind frees the published group without removing it from the tree. A later lookup of the same MGID dereferences the freed struct rxe_mcg from __rxe_lookup_mcg(). Fix this by keeping the new mcg private until rxe_mcast_add() succeeds. Split the tree publication into __rxe_publish_mcg(), call rxe_mcast_add() before taking the tree reference, and free the still-private mcg on failure. Because the group is never visible in mcg_tree until the multicast address is programmed, no concurrent caller can look it up or attach a QP to a group that is about to be torn down, so the error path needs no conditional unwind. If another caller publishes the same MGID while the address is being programmed, the post-add re-check under mcg_lock finds the winner; this caller then drops its private object and balances its own rxe_mcast_add() with rxe_mcast_del() before returning the winner. Reproduced by forcing the rxe_mcast_add() error return under KASAN: without the change the next attach to the same MGID reports a slab-use-after-free in __rxe_lookup_mcg(); with it the forced failure returns cleanly. A no-injection attach/detach regression, including a two-QP shared join/leave and re-attach, stays KASAN- and leak-clean. Fixes: a926a903b7dc ("RDMA/rxe: Do not call dev_mc_add/del() under a spinlock") Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260617022728.2770116-1-michael.bommarito@gmail.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky commit d3dbccfe6afa7b9a6a7ed65cfaa76a47fa050a56 Author: Ștefan Ghețu Date: Sun Aug 30 23:51:06 2026 +0300 ASoC: fsl_micfil: balance mclk enable/disable hw_params() enables mclk unconditionally and hw_free() disables it unconditionally, but the PCM core does not guarantee 1:1 pairing: hw_free() can run without hw_params(), and hw_params() can be called multiple times from the SETUP state. This triggers an "already disabled" WARN() in the first case and leaks an enable reference in the second, leaving the clock ungateable. Guard both sides with the existing mclk_flag, as fsl_sai.c does with mclk_streams. Fixes: b47024dc624b ("ASoC: fsl_micfil: Add mclk enable flag") Signed-off-by: Ștefan Ghețu Reviewed-by: Chancel Liu Link: https://patch.msgid.link/20260830205106.11267-1-stefanghetu9@gmail.com Signed-off-by: Mark Brown commit 769001ce838d907ecaa95f1d0a4e8fc86f761f9f Author: Weiming Shi Date: Sun Jul 26 19:15:30 2026 +0800 RDMA/rxe: Restore HMM_PFN_WRITE check in ODP write paths Commit 0b261d7c1cd3 ("RDMA/rxe: Break endless pagefault loop for RO pages") dropped the access permission test from rxe_check_pagefault() and left only HMM_PFN_VALID. A page faulted in read-only, for example a page-cache folio behind a PROT_READ file mapping, then satisfies the check and ODP write operations (RDMA WRITE, RDMA READ response, SEND payload, atomics) modify it through kmap without ever breaking CoW. An unprivileged user can register an ODP MR over such a mapping and have incoming RDMA traffic overwrite the page cache of a file it only holds O_RDONLY, including /etc/passwd or setuid binaries. This is the same primitive class as Dirty COW and CVE-2022-2590. mlx5 has the missing invariant: its ODP path sets the device write bit only for pfns that carry HMM_PFN_WRITE. Restore it in rxe by requiring HMM_PFN_WRITE in rxe_check_pagefault() for every operation except RXE_PAGEFAULT_RDONLY. A write to a non-writable VMA now fails the one fault attempt with -EPERM from hmm_vma_fault() instead of re-faulting forever. For a writable VMA the fault breaks CoW and the write lands in the private page. Keep pmem flushes on the read-only check. arch_wb_cache_pmem() never modifies memory, and the FLUSH access bits do not make the umem writable, so classifying flushes as writes would make every flush against a flush-only MR fail. Fixes: 0b261d7c1cd3 ("RDMA/rxe: Break endless pagefault loop for RO pages") Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260726111533.1037819-1-bestswngs@gmail.com Reviewed-by: Zhu Yanjun Tested-by: Hongqiang Luo Tested-by: Xinyu Ma Tested-by: Zhanbo Ye Reported-by: Weiming Shi Reported-by: Shaomin Chen Reported-by: Rui Ding Reported-by: Miao Zhao Signed-off-by: Leon Romanovsky commit 18d80c77b4c7dd20699e81cedfbbff4e9d198f28 Author: Ben Cressey Date: Thu Aug 20 21:44:58 2026 +0000 dm-integrity: fix infinite loop on discard with large tag size When integrity_metadata handles a discard, it fills a buffer with DISCARD_FILLER and writes it over the tags, max_blocks blocks at a time. If the kmalloc fails, the buffer is the on-stack array checksums_onstack and max_size is set to HASH_MAX_DIGESTSIZE. So if the tag size is larger than HASH_MAX_DIGESTSIZE, max_blocks is zero, bi_size is never decremented and the loop never terminates. Fix this by using sizeof(checksums_onstack) as max_size. The array has MAX_TAG_SIZE bytes since commit b93b6643e9b5 ("dm integrity: fix a crash with unusually large tag size"), so max_blocks is at least 1. Fixes: 84597a44a9d8 ("dm integrity: add optional discard support") Cc: stable@vger.kernel.org Reviewed-by: Jose Fernandez (Anthropic) Signed-off-by: Ben Cressey Assisted-by: Claude:unspecified Signed-off-by: Mikulas Patocka commit 59e6f919d77d72ec79cbf171256f2f7819737580 Author: Ben Cressey Date: Thu Aug 20 21:44:57 2026 +0000 dm-integrity: fix buffer overflow with keyed discard Since commit 68c5c42567bc ("dm-integrity: replace forgeable discard filler with a keyed sector marker"), integrity_metadata computes a checksum for every discarded block into the "checksums" buffer. integrity_sector_checksum always writes the whole digest. So if the tag size is smaller than the digest size, the checksum of the last block that fits into the buffer is written past the end of it. For example, with hmac(sha256) and tag size 16, a 4MiB discard writes 16 bytes past the kmalloc'ed page. Fix this by subtracting extra_space from the buffer size when computing max_blocks, like we do for writes. Fixes: 68c5c42567bc ("dm-integrity: replace forgeable discard filler with a keyed sector marker") Reviewed-by: Jose Fernandez (Anthropic) Signed-off-by: Ben Cressey Assisted-by: Claude:unspecified Signed-off-by: Mikulas Patocka commit b2fd92f016e9d692fd3c8c08d0ee014e9212279d Author: Chen Cheng Date: Mon Aug 24 19:34:49 2026 +0800 dm-integrity: require stable writes for internal hash modes dm-integrity direct, bitmap and inline internal-hash modes compute integrity tags from the pages carried by the write bio. The lower data write also uses those pages, so the tag and the data write depend on the same memory contents staying unchanged while writeback is in flight. Without stable writes, a buffered writer can modify a writeback folio after dm-integrity has submitted the data bio and before the lower device has consumed the data. After a crash, this can leave data from the later contents with a tag calculated from the earlier contents, causing permanent checksum failures on read. Set BLK_FEAT_STABLE_WRITES for internal-hash D, B and I modes so filesystems wait for writeback folios to become stable before modifying them again. Journal mode is left unchanged because it copies data into the journal before computing and persisting the tag. Tested using dm-delay over a virtio-blk test disk, dm-integrity internal_hash:crc32c and no-journal ext4. The D and B reproducers both failed with checksum errors before this change and completed with READ_RC=0 and zero mismatches after it. Fixes: 7eada909bfd7 ("dm: add integrity target") Cc: stable@vger.kernel.org Reported-by: Sun Yangkai Link: https://github.com/chencheng-fnnas/reproducer/blob/main/dm-integrity-writeback-race.py Signed-off-by: Chen Cheng Signed-off-by: Mikulas Patocka commit bc9781c0247de107876f32929f1637db93a42b34 Author: Benjamin Marzinski Date: Tue Aug 25 15:22:26 2026 -0400 dm cache: fix issue with background work locking dm cache used a rw_semaphore for background_work_lock. Write locks on rw_semaphores have strict owner semantics, but there was no guarantee that the process that locked background_work_lock was the same process that unlocked it. This can be easily seen using a kernel compiled with CONFIG_DEBUG_RWSEMS. Given a dm cache device , run: 'dmsetup suspend && dmsetup resume '. This will trigger a kernel warning: DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)) triggered by cache_resume(). To fix this, switch from a rw_semaphore to a spinlock and a wait queue. dm cache already has a wait queue and associated counter, migration_wait and nr_allocated_migrations, that was getting woken up when background work was getting completed, but wasn't actually used by anything. This is replaced by the background_work queue and counter. Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Marzinski Reviewed-by: Matthew Sakai Reviewed-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka commit 148845aa1921d95ef5dc851c76e6a284f6657df6 Author: Ben Cressey Date: Wed Aug 26 00:25:33 2026 +0000 dm-crypt: fix a tiny race condition in crypt_dec_pending crypt_dec_pending reads io->error before calling atomic_dec_and_test. Another context, for example crypt_endio called from an interrupt, may set io->error and drop its reference between the read and the decrement. crypt_dec_pending then drops the last reference and completes the bio with the stale status - so a read that failed and was never decrypted, or a write that failed, is reported as successful. The read was placed before the decrement by commit b35f8caa0890 ("dm crypt: wait for endio to complete before destruction"), because that commit freed dm_crypt_io before calling bio_endio. This is no longer the case, dm_crypt_io lives in the per-bio data now. Read io->error after atomic_dec_and_test instead. atomic_dec_and_test is fully ordered, so no additional barrier is needed. Fixes: b35f8caa0890 ("dm crypt: wait for endio to complete before destruction") Cc: stable@vger.kernel.org Reviewed-by: Jose Fernandez (Anthropic) Signed-off-by: Ben Cressey Assisted-by: Claude:unspecified Signed-off-by: Mikulas Patocka commit 86d923a882f48b047b079a293abb6ebca3eaf23f Author: Xixin Liu Date: Tue Jul 28 09:27:31 2026 +0800 clk: scpi: use PLATFORM_DEVID_NONE for scpi-cpufreq Replace the magic -1 passed to platform_device_register_simple() with PLATFORM_DEVID_NONE. This is a readability cleanup only and does not change behavior. Signed-off-by: Xixin Liu Link: https://patch.msgid.link/fb51cfbfbb41.v2.1785200642.git.liuxixin@kylinos.cn Signed-off-by: Sudeep Holla commit ab06cf8152dace327cd873188e4a036c4e0b5944 Author: Xixin Liu Date: Tue Jul 28 08:50:00 2026 +0800 clk: scpi: register scpi-cpufreq once and clear on failure scpi_clocks_probe() walks clock children and, for each DVFS provider, calls platform_device_register_simple("scpi-cpufreq", -1, ...). Two related bugs: Since all DVFS providers register the fixed scpi-cpufreq device using PLATFORM_DEVID_NONE, a second registration fails with -EEXIST and overwrites the pointer to the successfully registered device. The first device can then no longer be unregistered. Register the virtual device only once. If registration fails, reset the pointer to NULL so a subsequent DVFS provider can retry and the global pointer only represents a successfully registered device. Fixes: 9490f01e2471 ("clk: scpi: add support for cpufreq virtual device") Fixes: 67bcc2c5f1da ("clk: scpi: don't add cpufreq device if the scpi dvfs node is disabled") Signed-off-by: Xixin Liu Link: https://patch.msgid.link/fd1b9199a9c3.v2.1785200642.git.liuxixin@kylinos.cn (sudeep.holla: reworded the commit message to improve readability) Signed-off-by: Sudeep Holla commit 70f4b78d560e592cbf3325b162424737d032fc1d Author: Xixin Liu Date: Tue Jul 28 08:50:00 2026 +0800 clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate dvfs_get_idx() may return an out-of-range index if the SCP firmware is buggy or returns a stale value. Only negative indexes were rejected, so a large index walked past info->opps and could treat garbage as a clock rate (KASAN OOB / wrong frequency to consumers). The missing upper bound dates back to the original SCPI clock driver. Treat indexes >= opp count as invalid and return 0, same as idx < 0. Fixes: cd52c2a4b5c4 ("clk: add support for clocks provided by SCP(System Control Processor)") Signed-off-by: Xixin Liu Link: https://patch.msgid.link/04f9ab766e07.v2.1785200642.git.liuxixin@kylinos.cn Signed-off-by: Sudeep Holla commit 32471d84a487c7fd74532bc96be56f8028cf4a3f Author: Xixin Liu Date: Tue Jul 28 08:50:00 2026 +0800 firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS scpi_dvfs_get_info() already rejected a zero opp_count, but still trusted any larger value from the SCP firmware. The shared-memory reply only holds MAX_DVFS_OPPS entries in buf.opps[]; a bigger count over-reads that array and then sizes the allocated OPP table incorrectly (garbage OPPs / OOB). The missing upper bound dates back to the original SCPI DVFS support. Reject zero and out-of-range counts in one check and return -EINVAL. Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol") Signed-off-by: Xixin Liu Link: https://patch.msgid.link/022802f0b38f.v2.1785200642.git.liuxixin@kylinos.cn Signed-off-by: Sudeep Holla commit 65320b642025c53063372bd34a376bec7bf15598 Author: Xixin Liu Date: Tue Jul 28 08:50:00 2026 +0800 firmware: arm_scpi: fix device_node leak in scpi_dev_domain_id of_parse_phandle_with_args() takes a reference on clkspec.np that must be released with of_node_put(). scpi_dev_domain_id() returned clkspec.args[0] without dropping that reference, so every domain lookup leaked a device node. Paths such as scpi_dvfs_info() / cpufreq init call this per CPU, so the leak accumulates over time. Save the domain id, of_node_put(clkspec.np), then return the saved value. Signed-off-by: Xixin Liu Link: https://patch.msgid.link/84fdd490495b.v2.1785200642.git.liuxixin@kylinos.cn Signed-off-by: Sudeep Holla commit 98d23edcd41432286cf03672252507a841323c8c Author: Harald Freudenberger Date: Tue Aug 25 18:01:54 2026 +0200 s390/zcrypt: Fix uninitialized padding in CRT key structure The zcrypt_type6_crt_key() function leaves padding bytes uninitialized between key components and the modulus in the CCA CRT key token. These padding bytes are sent to the crypto card, potentially leaking kernel memory contents. The initial memset() only zeros fixed structure fields, not the flexible array member key_parts[] where the padding resides. While key components are properly copied from userspace, the calculated pad_len bytes between them remain uninitialized. Fix by explicitly zeroing the padding bytes after copying the CRT key components. Signed-off-by: Harald Freudenberger Reviewed-by: Finn Callies Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit 33123ff9cbcb35640f56efb8ede1d6f0d97376fd Author: Heiko Carstens Date: Thu Aug 27 12:28:32 2026 +0200 s390/mm: Simplify crst_table_upgrade() In case of an upgrade from four to five level page tables, and a failing pgd allocation, the exit path of crst_table_upgrade() would incorrectly dereference the p4d NULL pointer via pagetable_dtor(). Address this by reworking crst_table_upgrade(), which basically is a revert of [1]. Take into account that GFP_KERNEL order-2 allocation failures are very unlikely. Therefore keep the code as simple as possible: In case of an upgrade from three to five levels, and an allocation failure of the fifth page table level, keep the upgrade to four levels instead of reverting back to three levels. This allows to keep error handling minimal. [1] commit 31932757c612 ("s390/mm: optimize page table upgrade routine") Reviewed-by: Alexander Gordeev Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit 12373ea918a0e72483662095686556eea21d67bc Author: Vasily Gorbik Date: Wed Aug 19 12:31:10 2026 +0200 s390/boot: Bound command line facility ranges The facilities and debug-alternative command line parsers iterate over inclusive numeric ranges. If a range ends at ULONG_MAX, incrementing the current value wraps to zero and the loop never terminates. Large finite out-of-range values also cause unnecessary early boot iterations even though the bitmap helpers ignore them. Stop each loop at the size of the bitmap it modifies. This preserves all meaningful range values while guaranteeing termination. Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit d76181dfabdaa720703167393704efacba343442 Author: Vasily Gorbik Date: Wed Aug 19 12:30:33 2026 +0200 s390/boot: Avoid IPL parameter append past command line A command line may occupy all but the terminating byte of COMMAND_LINE_SIZE. In that case append_ipl_block_parm() passes a zero size to the IPL parameter conversion helpers and points the destination one byte past early_command_line. The helpers subtract one from the unsigned size and write the converted parameter outside the command line buffer. Convert the IPL parameter in the command line parsing buffer first. A parameter beginning with '=' can then replace the existing command line regardless of its length, while other parameters are appended only when space remains. Fixes: 5ecb2da660ab ("s390: support command lines longer than 896 bytes") Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit a0c798ed4103316c23938bdf625af364fbd38016 Author: Vasily Gorbik Date: Wed Aug 19 12:30:05 2026 +0200 s390/boot: Fix physical memory search range search_mem_end() calculates the number of 1MB blocks with a signed int literal. CONFIG_MAX_PHYSMEM_BITS values of 51 and above either overflow the signed int or shift beyond its width. This produces an invalid search range when the binary-search memory detection fallback is used. Use an unsigned long literal so the full supported physical address range is represented. Fixes: 54c57795e848 ("s390/mem_detect: replace tprot loop with binary search") Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit c53f5bfc370046e098fe04dc045e9e3cf19df609 Author: Peter Drabik Date: Mon Aug 31 21:58:55 2026 +0200 ALSA: usb-audio: Add mixer map quirk for Audient iD24 The Audient iD24 (2708:000d) exposes feature unit 12 as a 4-channel "Speaker Playback Volume" control (cmask 0xf, -127..0 dB). The device does not actually apply this volume to all of its output channels: the left main output ignores it and stays at 0 dB, while the right main output honors it. When userspace (PulseAudio / PipeWire in a stereo profile) adopts this control as the master playback volume, any setting below maximum produces a stereo imbalance on the main outputs. This was verified against the device's internal meters: with the control set to 107/127 (-20 dB) on all four channels and a digitally identical L/R sine played back, both DAW return meters read the same level while the right main output metered exactly 20 dB below the left. Restoring the control to 127 (0 dB) restored the balance. Rename the control to "Monitor Mix Playback" so that it is not picked up as the stream's master volume control, in line with similar quirks for other devices. The control remains accessible for manual use. Signed-off-by: Peter Drabik Link: https://patch.msgid.link/20260831195855.1836617-1-drabik.p@gmail.com Signed-off-by: Takashi Iwai commit 32d7226e6105c257ef7b3d0ec819f11a81f53b6d Author: Xu Rao Date: Tue Sep 1 11:40:24 2026 +0800 ALSA: hda: restore MFG widget enumeration after core split Before commit 7639a06c23c7 ("ALSA: hda - Move a part of hda_codec stuff into hdac_device"), widget enumeration selected the function group with codec->afg ? codec->afg : codec->mfg and read subordinate nodes from that group. The core split moved this logic into snd_hdac_refresh_widgets(), but hard-coded codec->afg there. For an MFG-only codec, codec->afg is zero, so the Root Node is queried and codec->start_nid/num_nodes are populated from the function-group range instead of the MFG's subordinate nodes. Restore the pre-split AFG-or-MFG selection. Fixes: 7639a06c23c7 ("ALSA: hda - Move a part of hda_codec stuff into hdac_device") Signed-off-by: Xu Rao Link: https://patch.msgid.link/44809B8FF80DCCA2+20260901034024.2407783-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai commit e4637ce34607f1733a34a57294966d26b263e626 Author: HyeongJun An Date: Tue Sep 1 18:04:09 2026 +0900 ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here. Fixes: 030a07e44129 ("ALSA: Add USB US122L driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260901090409.1478573-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai commit bc93419130bb70fabf6561e197054caae85c160c Author: Eric Dumazet Date: Mon Aug 31 08:10:27 2026 +0000 net: bonding: annotate lockless writes with WRITE_ONCE() Several fields in bonding are read locklessly using READ_ONCE() (or ACCESS_ONCE() previously) but have corresponding writes that do not use WRITE_ONCE(). Add WRITE_ONCE() annotations to: - bond->send_peer_notif decrements in bond_peer_notify_may_events() and reset in bond_close(). - bond->slave_cnt increments and decrements in bond_enslave() and __bond_release_one(). - bond->recv_probe updates in bond_open(), bond_option_arp_interval_set() and rlb_initialize(). - slaves->count decrement in bond_skip_slave(). Fixes: 4d97480b1806 ("bonding: use local function pointer of bond->recv_probe in bond_handle_frame") Fixes: 9a72c2da690d ("bonding: fix div by zero while enslaving and transmitting") Fixes: ee6377147409 ("bonding: Simplify the xmit function for modes that use xmit_hash") Fixes: 429208aab9db ("net: bonding: add the READ_ONCE/WRITE_ONCE for outside lock accessing") Signed-off-by: Eric Dumazet Cc: Jay Vosburgh Reviewed-by: Xuanqiang Luo Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260831081027.3209554-1-edumazet@google.com Signed-off-by: Paolo Abeni commit 96f01b53c2d05e003b040892256de54a586e8529 Author: Wyatt Feng Date: Sat Aug 29 23:44:32 2026 +0800 net: xfrm: reject unrepresentable espintcp transport headers ESP-in-TCP can hand xfrm packets whose transport header offset no longer fits after the stream parser trims the TCP envelope. The plain transport header reset truncates that offset and triggers the skb warning path. Use the careful transport-header helper and drop the skb through the existing XFRM error path when the offset cannot be represented. Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Signed-off-by: Steffen Klassert commit 3cf5cdecd99c9c186a5ea518d93bbf3045b6e3aa Author: Zhiling Zou Date: Sat Aug 29 17:24:24 2026 +0800 xfrm: save input state data before secpath resets xfrm_input() stores the current xfrm_state in the skb secpath while it continues receive-side processing. Some input paths can reset that secpath before xfrm_input() has finished dereferencing the state. Receive callback users such as VTI and XFRM interfaces can reset the secpath. The VTI receive path does so before checking whether the packet crosses network namespaces, while the XFRM interface path does so only for cross-network-namespace packets. The XFRM_MAX_DEPTH error path can also reset the secpath before the final drop callback reports the current state's protocol. If secpath_reset() drops the last state reference while the state is concurrently deleted, xfrm_input() can still dereference the freed state when selecting transport_finish() or reporting the drop callback protocol. Save the state protocol on the stack while the state is still valid, and use the already saved address family for transport_finish(). A larval XFRM_STATE_ACQ state has no type, so retain nexthdr as its protocol. This preserves the existing drop-path fallback while avoiding the post-reset state dereferences without adding an extra state reference to every received packet. Fixes: df3893c176e9 ("vti: Update the ipv4 side to use it's own receive hook.") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Steffen Klassert commit 9fa903b24b1f46b4ff5443bcd4aca23e5c57f9c1 Author: Cen Zhang (Microsoft Security FORGE Labs) Date: Wed Aug 26 16:17:45 2026 -0400 xfrm: hold net_device reference under RCU in bundle creation xfrm_bundle_create() and xfrm_create_dummy_bundle() read dst->dev into a local pointer without taking a device reference, then pass it to xfrm_fill_dst(). A concurrent RTM_DELLINK replaces dst->dev via dst_dev_put() and frees the old net_device, causing a use-after-free when xfrm6_fill_dst() later dereferences the stale dev pointer. BUG: KASAN: slab-use-after-free in xfrm6_fill_dst+0x82c/0x860 (net/ipv6/xfrm6_policy.c:86 netdev_hold()) Read of size 8 at addr ffff8880142fe588 by task exploit/153 Call Trace: xfrm6_fill_dst+0x82c/0x860 xfrm_resolve_and_create_bundle+0x21d4/0x2bd0 xfrm_lookup_with_ifid+0x485/0x1640 ip6_dst_lookup_flow+0x19b/0x1e0 udpv6_sendmsg+0x1443/0x2dd0 Fix this by reading dst->dev via dst_dev_rcu() and keeping the RCU read-side critical section active until xfrm_fill_dst() has taken the required device references. Fixes: 25ee3286dcbc ("[IPSEC]: Merge common code into xfrm_bundle_create") Fixes: a0073fe18e71 ("xfrm: Add a state resolution packet queue") Suggested-by: Steffen Klassert Reported-by: Xiang Mei (Microsoft) Link: https://lore.kernel.org/all/20260820200245.44312-1-blbllhy@gmail.com/ Cc: AutonomousCodeSecurity@microsoft.com Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) Signed-off-by: Steffen Klassert commit d10e2a08799e858d3e71ea4169bcd018f216d444 Author: Gang Yan Date: Fri Aug 14 17:37:40 2026 +0800 RDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB access mr_check_range() validates that [iova, iova+length) falls within the registered MR range using wraparound-prone arithmetic: if (iova < mr->ibmr.iova || iova + length > mr->ibmr.iova + mr->ibmr.length) A remote peer can craft an RDMA-Write/Read RETH so that iova + length wraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing the check. rxe_mr_iova_to_index() then computes a huge index (int idx, only guarded by WARN_ON) and rxe_mr_copy_xarray() dereferences mr->page_info[huge], causing an out-of-bounds read/write and a kernel oops that is triggerable by an unauthenticated remote peer. Rewrite the check in overflow-safe form; the first two clauses guarantee that the subsequent subtractions do not underflow: if (iova < mr->ibmr.iova || length > mr->ibmr.length || iova - mr->ibmr.iova > mr->ibmr.length - length) With the fix, mr_check_range() returns -EINVAL for the crafted iova and the responder reports REMOTE_ACCESS_ERROR instead of triggering the OOB. Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Gang Yan Link: https://patch.msgid.link/20260814093740.292954-1-gang.yan@linux.dev Reviewed-by: Zhu Yanjun Reviewed-by: Shukai Ni Tested-by: Shukai Ni Signed-off-by: Leon Romanovsky commit 28a289beaf226b30b1e6e7d7b1a2946fe2d6e852 Author: Muhammad Bilal Date: Tue Jul 28 17:54:56 2026 +0500 staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie() rtw_restruct_wmm_ie() scans in_ie for a WMM IE with: while (i < in_len) { ... if (i + 5 < in_len && in_ie[i] == 0xDD && ...) { ... break; } i += (in_ie[i + 1] + 2); /* to the next IE element */ } When the "i + 5 < in_len" match check fails simply because i is within 5 bytes of the end of the buffer (i.e. no WMM IE was found near the tail of in_ie), execution falls through to "i += (in_ie[i + 1] + 2)", which reads in_ie[i + 1]. If i == in_len - 1 at that point, this is a 1-byte out-of-bounds read of an attacker-influenced IE buffer built from association/scan data. Commit a75281626fc8f ("staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie") added the "i + 5 < in_len" guard to the match condition itself, but did not add an equivalent guard before the fallthrough advance, so the same class of OOB read remained reachable through the non-matching path. Add an explicit bounds check before advancing to the next IE. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260728125456.32359-4-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman commit ff917923f4fb9c83717ba135ee47d7e4c1567bb7 Author: Muhammad Bilal Date: Tue Jul 28 17:54:55 2026 +0500 staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: const u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); ... c = frame_body[0]; ... a = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260728125456.32359-3-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 99aa998dec83ba180822f70e6d48a514fc81c20d Author: Muhammad Bilal Date: Tue Jul 28 17:54:54 2026 +0500 staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: if (attr_ptr + 4 > wps_ie + wps_ielen) break; u16 attr_id = get_unaligned_be16(attr_ptr); u16 attr_data_len = get_unaligned_be16(attr_ptr + 2); u16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: memcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack "u8 sr"/"u8 selected_registrar" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The "attr_ptr + 4 > wps_ie + wps_ielen" header check above was added by commit 1463ca3ec6601 ("staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260728125456.32359-2-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman commit f576944a59f31bcffff121117ebf452c5dd162b7 Author: Hui Su Date: Fri Aug 7 23:09:55 2026 +0800 staging: fbtft: make dirty_lock IRQ-safe fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short. Fixes: c296d5f9957c ("staging: fbtft: core support") Signed-off-by: Hui Su Link: https://lore.kernel.org/lkml/20260804173712.176017-1-sh_def@163.com/ Reviewed-by: Nam Cao Link: https://patch.msgid.link/20260807150953.2811933-3-sh_def@163.com Signed-off-by: Greg Kroah-Hartman commit ae36a5b609ae79f4de966328b78d2584be9719a4 Author: Norbert Szetei Date: Thu Aug 27 19:18:07 2026 +0200 RDMA/rxe: validate access flags before swapping the MR's PD rxe_rereg_user_mr() reassigns mr->ibmr.pd first and only then validates the IB_MR_REREG_ACCESS argument: if (flags & IB_MR_REREG_PD) { rxe_put(old_pd); rxe_get(pd); mr->ibmr.pd = ibpd; } if (flags & IB_MR_REREG_ACCESS) { if (access & ~RXE_ACCESS_SUPPORTED_MR) return ERR_PTR(-EOPNOTSUPP); mr->access = access; } Both flags pass the entry check because RXE_MR_REREG_SUPPORTED is IB_MR_REREG_PD | IB_MR_REREG_ACCESS, so a caller can reach the access check with mr->ibmr.pd already reassigned. mr->ibmr.pd is owned by the core, which adjusts pd->usecnt only on the success path: ib_uverbs_rereg_mr() jumps to put_new_uobj on a driver error without undoing the reassignment, so mr->pd == new_pd while the usecnts still charge the MR to orig_pd. ib_dereg_mr_user() then decrements new_pd, whose count can reach zero while a memory window still references it; uverbs_free_pd() frees the PD on that count alone and rxe_mw_cleanup() writes to freed memory: BUG: KASAN: slab-use-after-free in __rxe_put+0x31/0xa0 Write of size 4 at addr ffff8881301dd690 by task rxe_poc/591 __rxe_put+0x31/0xa0 rxe_mw_cleanup+0x42/0x200 __rxe_cleanup+0x115/0x370 rxe_dealloc_mw+0x4c/0x80 Allocated by task 591: ib_uverbs_alloc_pd+0x258/0x540 Freed by task 591: ib_dealloc_pd_user+0x174/0x210 uverbs_free_pd+0x8d/0xc0 ib_uverbs_dealloc_pd+0x18e/0x1d0 Validate the access flags before mutating any state so the callback either applies every requested change or none. Fixes: 544c7f62cf32 ("RDMA/rxe: Implement rereg_user_mr") Signed-off-by: Norbert Szetei Link: https://patch.msgid.link/46E1D5C0-24BE-4D01-BDB3-634FE09B22C5@doyensec.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky commit c037915f80c4db47f7d061d68e703ffd551b1a34 Author: Kaiwen Shi Date: Sun Aug 30 07:05:51 2026 +0800 mac802154: fix data race and NULL deref on local->assoc_dev local->assoc_dev is shared between the association path and the association-response worker without common synchronization. mac802154_perform_association() stores the coordinator pointer and waits for a response. Its timeout and error paths clear the pointer and return to mac802154_associate(), which may then free the coordinator object. Meanwhile, mac802154_rx_mac_cmd_worker() may observe the associating bit and enter mac802154_process_association_resp(), which dereferences assoc_dev. The worker's bit test and the handler's pointer dereference are not atomic with respect to cleanup. Cleanup can clear assoc_dev between them, causing a NULL dereference, or free the coordinator while the response handler still uses the pointer. The recorded result is exposed to the same window. assoc_status and assoc_addr are written by the handler but read by the association path while the associating bit is still set, so a second response for the same request - a malicious one, for instance - can replace them between those reads and leave the caller with an incoherent status and address pair. The response handler only needs the coordinator extended address. Replace assoc_dev with a cached address, removing the pointer lifetime dependency. Protect the cached address and the associating bit with a dedicated spinlock. A READ_ONCE()/WRITE_ONCE() pair would not guarantee an atomic __le64 access on all 32-bit architectures. wpan_dev->association_lock cannot be reused here: nl802154_associate() holds it across rdev_associate(), hence for the whole of mac802154_perform_association() including the wait for the response. A response handler taking that lock would only get it once the association has already given up. Reset the completion, publish the cached address, and set the associating bit while holding the lock. The response handler takes the lock, rechecks the bit and the cached address, records the response, clears the bit, and only then completes the waiter. Thus cleanup cannot pass the handler between its state check and completion, and the cached 64-bit value cannot tear. The handler clears the bit before completing, not the woken waiter: otherwise complete() is issued under the lock and a second (e.g. malicious) response can reacquire it before the waiter and replace the result. So a wait that returns success implies the bit is already clear, and the success and negative-response paths return directly. The transmit-error and timeout paths still clear it under assoc_lock, which serializes any racing response against the cleanup while the call returns the error it already selected. Both paths snapshot assoc_status and assoc_addr under the same lock. Both users run in process context, so a plain spinlock is sufficient. The lock is not held while waiting for the completion. Suggested-by: Miquel Raynal Suggested-by: Xuanqiang Luo Fixes: fefd19807fe9 ("mac802154: Handle associating") Cc: stable@vger.kernel.org Signed-off-by: Kaiwen Shi Reviewed-by: Xuanqiang Luo Reviewed-by: Miquel Raynal Link: https://patch.msgid.link/20260829230551.1787432-1-skwkevin@mail.ustc.edu.cn Signed-off-by: Paolo Abeni commit c2256c044a1df39c8aad4dd2d6f709b2533e2d7a Author: Zhenhao Wan Date: Tue Aug 11 22:28:51 2026 +0800 drm/nouveau/dmem: fix callocated underflow on large folio split nouveau_dmem_folio_free() drops chunk->callocated once per freed folio, while a large (compound) device-private folio is only counted once when it is allocated. When such a folio is split, the mm core invokes ->folio_split() (nouveau_dmem_folio_split()) once for each new sub-folio, but the hook only fixes up the sub-folio metadata and leaves chunk->callocated unchanged. Each resulting sub-folio is later freed separately, so after a split the single allocation (+1) is met by N frees (-N), leaving chunk->callocated short by N-1. On the first split/free cycle it underflows: WARN_ON(!chunk->callocated) fires, the unsigned counter wraps and never returns to zero, so the chunk can no longer be reclaimed (nouveau_dmem_fini() also warns on the leaked count). Account for the new sub-folio in the split hook, under the same lock as nouveau_dmem_folio_free(), so the count stays balanced. Fixes: c32287471077 ("gpu/drm/nouveau: enable THP support for GPU memory migration") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-b4-nouveau-dmem-thp-fixes-v1-2-2cdf9860af2a@gmail.com Signed-off-by: Danilo Krummrich commit caa1bc2a0a6ca19dcb90bbf88208b0fe2decd66f Author: Zhenhao Wan Date: Tue Aug 11 22:28:50 2026 +0800 drm/nouveau/dmem: fix mismatched DMA unmap size for large folios Device-private THP migration maps migration buffers with page_size() and records that length in dma_info->size. For a compound folio page_size() is PAGE_SIZE << order, but two teardown sites still pass a literal PAGE_SIZE to dma_unmap_page(): - nouveau_dmem_migrate_to_ram() on the success path, and - nouveau_dmem_migrate_copy_one() on the copy-error path. For an order > 0 folio this unmaps less than was mapped, leaking the remainder of the IOMMU/IOVA mapping. The other unmap sites, in nouveau_dmem_migrate_chunk() and nouveau_dmem_evict_chunk(), already use the saved size; use it here too. Fixes: c32287471077 ("gpu/drm/nouveau: enable THP support for GPU memory migration") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Link: https://patch.msgid.link/20260811-b4-nouveau-dmem-thp-fixes-v1-1-2cdf9860af2a@gmail.com Signed-off-by: Danilo Krummrich commit deced5fa01c5e9813384b6c176379e5baaf5ec10 Author: Dave Airlie Date: Tue Aug 25 13:06:15 2026 +1000 nouveau/instmem: handle iomapping already existing Turns out sashiko was right, and I should protect this properly Fixes: 34e27b90552a ("nouveau/instmem: use iomapping interface for instmem handling") Signed-off-by: Dave Airlie Link: https://patch.msgid.link/20260825030615.3464436-1-airlied@gmail.com Signed-off-by: Danilo Krummrich commit 73e594c19b4f815d8343461cec7074c4713bbde7 Author: Kuniyuki Iwashima Date: Sun Aug 30 18:09:12 2026 +0000 af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header(). syzbot reported BUG() in sock_sendmsg_nosec(). [0] The problem is that tpacket_parse_header() casts user-provided tpacket_hdr.tp_len, which is u32, to int. If the length is larger than INT_MAX, the following condition in tpacket_parse_header() passes, if (unlikely(tp_len > size_max)) and any negative value can be returned to the caller, up to sock_sendmsg_nosec(). The repro set tpacket_hdr.tp_len to 0xfffffdef, which is cast to -EIOCBQUEUED (-529), triggering BUG() in sock_sendmsg_nosec(). *(uint64_t*)0x200000000008 = 0xfffffdef; ... syscall(__NR_write, /*fd=*/r[0], /*buf=*/0x200000000000ul, /*count=*/1ul); Let's define the local tp_len as u32 in tpacket_parse_header(). [0]: kernel BUG at net/socket.c:803! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 RIP: 0010:sock_sendmsg_nosec+0x145/0x180 net/socket.c:803 Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28 RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293 RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80 RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8 R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001 R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310 FS: 000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0 Call Trace: __sock_sendmsg net/socket.c:815 [inline] sock_write_iter+0x2de/0x3e0 net/socket.c:1266 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x612/0xba0 fs/read_write.c:687 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f173130ecb9 Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 d8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9 RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388 R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002 Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap") Reported-by: syzbot+73df3f89e1e13089e466@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a946ffa.1d9ded08.62e62.0123.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260830180915.260225-1-kuniyu@google.com Signed-off-by: Paolo Abeni commit 38a62306c4266bcb3cd89e33c7111ee33096ebb3 Author: Zhenhao Wan Date: Tue Aug 11 16:46:30 2026 +0800 drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE A successful OP_UNMAP_SPARSE marks its region dirty with nouveau_uvma_region_dirty() and defers the teardown to nouveau_uvmm_bind_job_cleanup(); it does not remove the region from uvmm->region_mt. If a later op in the job fails, the unwind path never clears reg->dirty (set in one place, cleared nowhere) and sets op->reg = NULL, so cleanup skips the teardown. The region is left in the tree with dirty set and its completion never signalled. Later binds over that range then fail permanently -- -ENOENT or -EINVAL from the dirty checks, or an unkillable wait_for_completion() in bind_validate_region() -- for the lifetime of the uvmm. Clear reg->dirty when the unwind reverts the sparse unmap, restoring the region to the state it was found in. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-3-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich commit ccf930812f23b8259ef64fd3394d53b093e4651a Author: Zhenhao Wan Date: Tue Aug 11 16:46:29 2026 +0800 drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE In nouveau_uvmm_bind_job_submit()'s OP_UNMAP_SPARSE arm, op->reg is set from nouveau_uvma_region_find(), which only looks the region up and takes no reference; a region's sole reference is its membership in uvmm->region_mt. Two failure paths leave op->reg set: the -ENOENT check when the region is busy, and the drm_gpuvm_sm_unmap_ops_create() failure. The sibling nouveau_uvmm_sm_unmap_prepare() failure just below clears op->reg; these two do not. unwind_continue steps back one op, so the failing op is skipped by the unwind loop and its op->reg stays set. nouveau_uvmm_bind_job_cleanup() then enters its if (op->reg) branch and calls nouveau_uvma_region_remove() and nouveau_uvma_region_put() on it, dropping the tree's sole reference and freeing a region this job never created. The comment above the cleanup loop documents the broken invariant: op->reg must be NULL on submit failure. This frees a live region on an unrelated failure, reachable single-job when drm_gpuvm_sm_unmap_ops_create() returns -ENOMEM; if another job owns the same region, its cleanup then removes and puts the freed region, a use-after-free. Clear op->reg on both failure paths. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-2-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich commit 412a6ceb56d501ef2f8202e26ab4b5d4dfbca566 Author: Zhenhao Wan Date: Tue Aug 11 16:46:28 2026 +0800 drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op Each bind_job_op is zeroed by kzalloc_obj() in bind_job_op_from_uop(), and the OP_MAP_SPARSE case in nouveau_uvmm_bind_job_submit() only creates a region, so op->ops stays NULL for a successfully processed sparse map. If a later op in the same job fails, the reverse unwind loop revisits that op and calls drm_gpuva_ops_free(&uvmm->base, op->ops) unconditionally. drm_gpuva_ops_free() dereferences its argument right away (list_for_each_entry_safe on &ops->list), so a NULL op->ops oopses. The path is reachable by any render-node fd holder, since NOUVEAU_VM_BIND is DRM_RENDER_ALLOW. Guard the free with IS_ERR_OR_NULL(), as nouveau_uvmm_bind_job_cleanup() already does for the identical free. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-1-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich commit 0b457c6733f73421a3fb03786f13d67c618b5119 Author: Sven Peter Date: Sat Aug 29 10:08:38 2026 +0200 thunderbolt: Tear down inactive DP tunnels when the domain is stopped tb_stop() only tears down DMA tunnels so a DP tunnel that is still waiting for dprx_work to complete keeps that work queued while the routers are removed and the control channel is stopped. The work only stops once the DPRX timeout has passed and because it requeues itself until then the flush_workqueue() in tb_domain_remove() won't wait for its final run. The callback then runs against a domain that is already torn down. A reference to that domain is kept so the completion waiting for that domain to disappear in unbind will block until the timeout is eventually reached. Tear down DP tunnels that are not active yet as well which also cancels that work. Tunnels for displays that are already alive are untouched and keep working. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Signed-off-by: Mika Westerberg commit c222f80be55f6c17851af1c68a70ae4046c848e2 Author: Sven Peter Date: Sat Aug 29 10:08:37 2026 +0200 thunderbolt: Mark discovered tunnels as active Discovered tunnels that have been activated by whatever was running before us stay in TB_TUNNEL_INACTIVE until hibernation restore such that anything depending on tb_tunnel_is_active() skips them. Mark them active during discovery instead. These now also emit TUNNEL_EVENT=activated uevents during discovery. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Signed-off-by: Mika Westerberg commit 419fa32fa5bc2d7fb9d0d15d5630b1c1090808b3 Author: Sven Peter Date: Sat Aug 29 10:08:36 2026 +0200 thunderbolt: Don't access a DP tunnel after its DPRX read was canceled tb_dp_dprx_work() checks ->dprx_canceled before it takes tb->lock so it misses a tb_dp_dprx_stop() that could not cancel the already running work. It then polls the DPRX capabilities and runs the callback for a tunnel that has already been torn down while the domain is suspending or going away. This can be hit by cancelling the DPRX read from outside the ordered tb->wq: During suspend tb_disconnect_and_release_dp() does just this and with a later patch tb_stop() will do it as well. The latter in combination with the Apple NHI where the DPRX read never completed is how I hit this. Check the flag with tb->lock held instead and check it again in tb_dp_tunnel_active() because the callback runs after the lock has been dropped again. Also clear the flag in tb_dp_dprx_start() so that it only ever describes the work that is currently in flight. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Signed-off-by: Mika Westerberg commit 1fd1f67c94d30889377bba774f032ec15e8b9299 Author: Sven Peter Date: Sat Aug 29 10:08:35 2026 +0200 thunderbolt: Fix domain reference leak when DPRX read is canceled tb_tunnel_one_dp() takes a domain reference which is only dropped once tb_dp_tunnel_active() has run on the work queue. If that work is cancelled that reference is leaked. Since commit f5cc545f5969 ("thunderbolt: Wait for tb_domain_release() to complete when driver is removed") instead of just leaking memory this now also blocks in the completion wait forever when unbinding the driver. This can be triggered whenever a DP tunnel is torn down before the DPRX read has completed, e.g. by unplugging within the timeout, and then unbinding the driver. That reference only exists to keep the domain around while the DPRX work is scheduled so let the work itself own it: take it in tb_dp_dprx_start() and drop it in both places that end the work. Get/put are then paired inside the same file and it doesn't matter anymore if the callback ever runs. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Signed-off-by: Mika Westerberg commit 12f5d8b85a66a0ac08d082517d92ce136f8c0d42 Author: Sven Peter Date: Sat Aug 29 10:08:34 2026 +0200 thunderbolt: Make the DP tunnel activation callback mandatory tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Signed-off-by: Mika Westerberg commit 032c59c7681c661b63123231824170c025afb7e7 Author: Sven Peter Date: Sat Aug 29 10:08:33 2026 +0200 thunderbolt: Hold a router reference for each allocated HopID tb_stop() drops the reference to all DP tunnels but does not deactivate them, thus nothing cancels a dprx_work still in flight (which holds its own tunnel reference) and the tunnel can outlive tb_switch_remove(). The HopID releases in tb_path_free() then operate on freed IDAs and trigger warnings like ida_free called for id=8 which is not allocated. This can be triggered by unbinding the driver while a DP tunnel is still waiting for the DPRX capabilities read to finish. On the Apple NHI unplugging the cable runs into just that reliably because the read can never finish right now and because the unplug powers down the entire USB4 complex and removes the NHI device. Take a router reference whenever an input or output HopID is allocated and drop it again after the HopID is released. This keeps the ports and their HopID IDAs alive for as long as they are used. The KUnit tests allocate routers without ever registering their devices so initialize the embedded struct device there as well and drop its initial reference when the test is finished. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Signed-off-by: Mika Westerberg commit 67f8bc848ee31831336bd478e57d2f993551902e Merge: 8eae39cd0adf28 cee9395acd8043 Author: Maxime Ripard Date: Tue Sep 1 09:38:51 2026 +0200 Merge drm/drm-fixes into drm-misc-fixes Let's start the 7.3 drm-misc-fixes cycle. Signed-off-by: Maxime Ripard commit 32cd87f54dd1070020e664ccb0312a9f0fea79b4 Author: Guoqing Jiang Date: Thu Aug 27 20:55:53 2026 +0800 RDMA/siw: Clear association under lock if siw_qp_modify fails in siw_accept We need to clear cep before release state_lock as siw_qp_llp_close and siw_qp_modify->siw_qp_llp_close did. Otherwise if siw_qp_modify() fails in siw_accept(), the QP's state_lock is released before the error path cleanup. A concurrent ibv_modify_qp() transitioning the QP to ERROR can race in this window: siw_accept() ibv_modify_qp(ERROR) ---------------------- ---------------------- siw_qp_modify() fails up_write(&qp->state_lock) down_write(&qp->state_lock) nextstate_from_idle(): if (qp->cep) siw_cep_put(qp->cep) <- frees cep qp->cep = NULL goto error cep->qp = NULL <- UAF Clear qp->cep and drop the association reference taken by siw_cep_get(), all under the write lock held from the initial down_write(&qp->state_lock). Thread B therefore sees qp->cep == NULL, skips its own put, and cannot free the cep before siw_accept() is done with it. Fixes: 6c52fdc244b5 ("rdma/siw: connection management") Reported-by: Shuangpeng Bai Link: https://lore.kernel.org/linux-rdma/d6fbe475-a5c2-f975-99b0-a0bd6b6d10e8@linux.dev/T/#m5876c1ff2de8686a9a1173b8f1aa0ff5363a785c Signed-off-by: Guoqing Jiang Link: https://patch.msgid.link/20260827125553.12831-1-guoqing.jiang@linux.dev Acked-by: Bernard Metzler Signed-off-by: Leon Romanovsky commit 49bda4826843be0ef97a162009a29ea3a63f3935 Merge: 16b10f64c63f78 cee9395acd8043 Author: Bartosz Golaszewski Date: Tue Sep 1 09:16:55 2026 +0200 Merge tag 'v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-current Linux 7.3-rc1 commit 3f9c7a108c0e8f14425384912017071b71341e3b Author: Damien Le Moal Date: Mon Aug 31 11:50:50 2026 +0900 block: flag zoned disks with GENHD_FL_NO_PART Zoned block devices do not support partitions. However, the partition table is nevertheless still inspected, and any partition found ignored with a warning in add_partition(). While this is generally not a problem, and in fact beneficial to the user as it indicates an invalid use of a zoned block device, scanning for a partition table on the device may result in issuing read operations to offline zones (e.g. after a disk head is depopulated for disks that support head management operations). Since partitions are ignored anyway, completely disable partition scanning for zoned gendisks by setting the flag GENHD_FL_NO_PART in __add_disk(). The existing check in add_partition() is left as-is to ensure that we still get a warning if for whatever reason, despite GENHD_FL_NO_PART, we still endup trying to add partitions. Flagging zoned disks with GENHD_FL_NO_PART also has the benefit to expose through sysfs the ext_range attribute with the value of 1 instead of the default DISK_MAX_PARTS, thus correctly advertizing the fact that zoned disks do not support partitions. Fixes: 5eac3eb30c9a ("block: Remove partition support for zoned block devices") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Bart Van Assche Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260831025050.667758-1-dlemoal@kernel.org Signed-off-by: Jens Axboe commit 786262be6048deab760f68c8acc2c85607165894 Merge: abdf623ddb75b2 68c90773f40f91 Author: Linus Torvalds Date: Mon Aug 31 20:10:39 2026 -0700 Merge tag 'edac_updates_for_v7.3_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras Pull forgotten EDAC updates from Borislav Petkov: "Somewhat belated (and forgotten :-\) EDAC updates lineup for v7.3: - Mark the mpc85xx and ThunderX EDAC drivers as orphaned due to lack of access to hardware - Remove the unused fake error injection interface from the EDAC debugfs code due to potential races between logging a fake and a real hw error - edac_mc_sysfs: Use sysfs_emit_at() for proper bounds checking - Remove Mark Gross from maintainer entries and move him to CREDITS - Load the AMD address translation library only on systems which can actually make use of it (have ECC memory) instead of on every AMD Zen system out there - In edac_altera, detect the SoC variant using the ECC manager's compatible string instead of the build architecture to select the correct interrupt layout, and remove leftover architecture-specific ifdeffery from the double-bit error handling path - Add a new reviewer for the Xilinx EDAC drivers - Unify address translation logic in Intel client EDAC drivers igen6 and ie31200 along with detecting memory controller counts at boot time instead of relying on hardcoded, platform specific numbers. Also, fix a bunch of issues in them; work by Qiuxu Zhuo - Add support for a new Intel processor platform Starfire which is a derivative of Panther Lake SoCs - The usual cleanups and fixlets all over" * tag 'edac_updates_for_v7.3_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: (24 commits) EDAC/thunderx: Orphan it EDAC/device_sysfs: Cleanup around edac_device_ctl_poll_msec_store() EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation EDAC/igen6: Add Intel Starfire SoCs support EDAC/igen6: Refactor address translation logic EDAC/igen6: Remove redundant resource configuration tables EDAC/igen6: Detect present memory controllers at runtime EDAC/igen6: Simplify compute die ID comments EDAC/igen6: Remove unnecessary XOR on the zero-valued interleave bit EDAC/igen6: Fix Raptor Lake-P logged error address EDAC/igen6: Fix channel address decode for non-hash mode EDAC/igen6: Fix channel selection hash EDAC/igen6: Fix interleave boundary condition EDAC/ie31200: Decouple DIMM width decoding from enum order RAS/AMD/ATL: Remove conditional return with no effect EDAC: Remove redundant dev_err() MAINTAINERS: Add Radhey Shyam Pandey as Xilinx EDAC reviewer EDAC/altera: Remove remaining CONFIG_64BIT ifdefs in the DB-error path EDAC/altera: Use ECC manager compatible to select A10/S10 IRQ layout RAS/AMD/ATL, EDAC/amd64: Only load ATL when needed ... commit 545b63503c696c4ce0663b3fcd37f41169aec1eb Author: Koichiro Den Date: Mon Aug 31 00:16:17 2026 +0900 net: ntb_netdev: Fix statistics races ntb_netdev updates shared net_device stats from per-QP RX and TX callbacks. Once multiple queues are enabled, concurrent updates can be lost. Use per-CPU tstats for packet and byte counters and DEV_STATS_INC() for less frequent drop and error counters. Callbacks can run synchronously in the xmit path or asynchronously from a tasklet or the memcpy kthread. Pin TX updates against migration in the kthread path. Use the IRQ-safe u64_stats helpers because netpoll can invoke the synchronous path with IRQs disabled. Let the core manage tstats while keeping transport teardown after unregister_netdev(), outside RTNL. RCU lets unregister wait for TX completions already updating stats, while later completions only consume the skb and skip accounting and queue wake. Fixes: 24d9e73c7e00 ("net: ntb_netdev: Support ethtool channels for multi-queue") Cc: stable@vger.kernel.org Suggested-by: Jakub Kicinski Signed-off-by: Koichiro Den Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260830151617.3546585-1-den@valinux.co.jp Signed-off-by: Jakub Kicinski commit 975b5b067f525a1b1338c4a3bee1c46545801518 Author: Eric Dumazet Date: Fri Aug 28 14:17:27 2026 +0000 ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back. Fixes: 1ababeba4a21 ("ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)") Reported-by: TencentOS Corvus AI Reported-by: Jun Yang Reported-by: Fourie Zhang Closes: https://lore.kernel.org/netdev/20260817104128.22681-1-juny24602@gmail.com/ Closes: https://lore.kernel.org/netdev/20260827092345.2301937-1-fouriezhang@tencent.com/ Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828141727.2372570-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit 81c600c26302a27852ed8b19c5f2f647ea3555c9 Author: David Laight Date: Sat Aug 29 12:58:12 2026 +0100 tipc: Dont send random pad bytes in RESET/ACTIVATE messages The interface name is passed in a fixed length (TIPC_MAX_IF_NAME) buffer. Replace the strcpy(data, l->if_name) with memcpy() so that the pad bytes are actually written (l->if_name[] is zero padded) rather than sending random bytes from the skb to the remote system. Replace two other strcpy() with strscpy(). Fixes: e74a386d70c7 ("tipc: remove pre-allocated message header in link struct") Signed-off-by: David Laight Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260829115813.188600-1-david.laight.linux@gmail.com Signed-off-by: Jakub Kicinski commit b3b76e9f4f2476f1135b2ba7743a821db4a0df4b Author: Tung Nguyen Date: Thu Aug 27 18:13:46 2026 +0700 tipc: fix NULL deref in tipc_named_node_up() on empty publication list User-space applications can bind a large number of service addresses to one or more sockets. Each binding of a local-scope service address inserts one entry (publication) into the TIPC name table. If the number of these publications exceeds TIPC_MAX_PUBL (65535), protocol service types (such as node state and link state) are no longer inserted into the name table. This causes two issues: 1. User-space applications subscribing to node or link up/down events stop receiving notifications. 2. A NULL pointer dereference can occur: BUG: kernel NULL pointer dereference, address: 00000000000000d0 ... CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full) ... RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221) ... Call Trace: tipc_node_write_unlock (net/tipc/node.c:428) tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189) tipc_udp_recv (net/tipc/udp_media.c:389) Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute) -----------------------------|----------------------------- | ... | list_for_each_entry(publ, pls, binding_node) { | ... | __skb_queue_tail(list, skb); | ... | } | ... | hdr = buf_msg(skb_peek_tail(list)); ... | tipc_nametbl_publish(); | If 'tipc_nametbl_publish()' (Thread 1) fails because the number of local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference. Fix these issues by allowing protocol service types (node state, link state, and topology server) to be inserted into the name table unconditionally. This ensures that users subscribing to these types always receive notifications. In addition, the maximum number of local user publications is reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size calculated in tipc_link_set_queue_limits() remains valid. Fixes: a5e7ac5ce134 ("tipc: fix regression bug where node events are not being generated") Reported-by: Xiang Mei Tested-by: Weiming Shi Signed-off-by: Tung Nguyen Link: https://patch.msgid.link/20260827111418.164957-1-tung.quang.nguyen@est.tech Signed-off-by: Jakub Kicinski commit f88bbbbe96d6d2ba4cca8af0c47907ed27de2863 Merge: 97cc84dad1d7f6 c923c14942b164 Author: Jakub Kicinski Date: Mon Aug 31 19:56:33 2026 -0700 Merge branch 'mitigate-a-side-channel-in-routing-exception-caches' Ido Schimmel says: ==================== Mitigate a side channel in routing exception caches When an ICMP error that quotes a UDP packet is locally delivered, the kernel only creates a routing exception if the quoted packet matches a socket. This allows an off-path attacker to conduct a side-channel attack on the routing exception caches in order to discover the ephemeral ports used by connected UDP sockets. Previous mitigations tried to make it harder for attackers to find hash collisions in these caches and make the eviction of exceptions less predictable. Amit Klein and Noam Caspi demonstrated that both of these mitigations can be bypassed. This patchset tries to mitigate such attacks by always creating an exception, even before trying to find a matching socket. The exception is created by the same helpers that are used when the quoted packet did not originate from a socket, so that guesses (right or wrong) from an off-path attacker always result in an exception being created or updated in the cache that the attacker can observe. Note that this mitigation does not make it easier for attackers to fill these caches, since they can already create exceptions with little to no validation. For example, by sending an ICMP error that quotes an ICMP Echo Reply or one that quotes a UDP source port that matches a wildcard socket. In the good case (matched socket) this comes at the cost of an extra route lookup, as the exception is created before the one performed by the socket path. When the two lookups resolve to different nexthops, an exception is created in the cache of each. Patch #1 fixes a pre-existing bug in the handling of ICMPv6 Redirect Message packets. Discovered while writing the selftest. Patch #2 creates an exception from the IPv4 UDP code even before socket matching. Other socket types do not need this: raw sockets have no ports, and for TCP the ICMP error is discarded unless the quoted sequence number is in window. Patch #3 does the same for IPv6. Patch #4 adds a selftest. v1: https://lore.kernel.org/netdev/20260826143735.1819315-1-idosch@nvidia.com/ ==================== Link: https://patch.msgid.link/20260828192344.2596928-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski commit c923c14942b164cfc2c1efa4e6324214f2fc248a Author: Ido Schimmel Date: Fri Aug 28 22:23:44 2026 +0300 selftests: net: Add exception cache tests Add a test for the IPv4 and IPv6 exception caches, covering the exceptions that are created in response to ICMP errors quoting a UDP packet. The topology consists of a host (h1) that reaches a remote host (h2) via a router (r1), with a second router (r2) attached to the segment shared by h1 and r1. UDP packets are injected using a packet socket, so that an ICMP error quoting them is only matched to a socket when one was opened separately with the same source port. PMTU errors are provoked by lowering the MTU of the far end of the path and redirects by pointing r1's route towards h2 back over the segment it received the packet from. The following is tested for both address families and for both PMTU and redirect exceptions: * An error that is not matched to a socket creates an exception that carries the new MTU or gateway. * An error that is matched to a socket creates the same exception. The PMTU tests further verify that a lower PMTU replaces the one stored in the exception whereas a higher one does not, and that a socket which disabled PMTU discovery using IP{,V6}_PMTUDISC_OMIT gets the same exception as the other cases. Without "ipv4: udp: Create exceptions before socket matching" and "ipv6: udp: Create exceptions before socket matching", the tests that do not open a socket fail: # ./exception_cache.sh TEST: IPv4: PMTU: exception without a matching socket [FAIL] No socket: exception does not carry an MTU of 1400 TEST: IPv6: PMTU: exception without a matching socket [FAIL] No socket: exception does not carry an MTU of 1400 TEST: IPv4: PMTU: exception with a matching socket [ OK ] TEST: IPv6: PMTU: exception with a matching socket [ OK ] TEST: IPv4: PMTU: exception with a socket ignoring it [FAIL] PMTU discovery disabled: exception does not carry an MTU of 1400 TEST: IPv6: PMTU: exception with a socket ignoring it [FAIL] PMTU discovery disabled: exception does not carry an MTU of 1400 TEST: IPv4: Redirect: exception without a matching socket [FAIL] No socket: exception does not carry the new gateway TEST: IPv6: Redirect: exception without a matching socket [FAIL] No socket: exception does not carry the new gateway TEST: IPv4: Redirect: exception with a matching socket [ OK ] TEST: IPv6: Redirect: exception with a matching socket [ OK ] Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260828192344.2596928-5-idosch@nvidia.com Signed-off-by: Jakub Kicinski commit ac76cab50e899a7346408b8d3c3a4192c2eefb9f Author: Ido Schimmel Date: Fri Aug 28 22:23:43 2026 +0300 ipv6: udp: Create exceptions before socket matching Currently, when ICMPv6 Packet Too Big and Redirect Message packets are locally delivered and quote a UDP packet, an exception is only created in the IPv6 exception cache if the kernel can match the UDP packet to an existing socket. This behavior allows off-path attackers to conduct a side-channel attack on the exception cache in order to discover the ephemeral port used by a connected UDP socket. Commit 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()") and commit a00df2caffed ("ipv6: make exception cache less predictible") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the exception cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed. Instead, mitigate such attacks by always creating an exception, even before trying to find a matching socket. Do that by calling ip6_update_pmtu() and ip6_redirect(), the helpers used when the quoted packet did not originate from a socket. This means that guesses (right or wrong) from an off-path attacker will always result in an exception being created or updated in the cache that the attacker can observe. Pass the ifindex of the ingress device and the default uid, in a similar fashion to icmpv6_err(). Unlike IPv4, an oif of 0 would not match any nexthop in ip6_redirect_nh_match() and no exception would be created in response to a Redirect Message. Note that this does not allow attackers to create exceptions that they could not create before, as both helpers can already be reached with little to no validation. For example, by sending an ICMPv6 error that quotes an ICMPv6 Echo Reply or one that quotes a UDP source port that matches a wildcard socket. Also note that in the good case (matched socket) the above scheme comes at the cost of an extra route lookup, as the no socket helpers perform their own lookup before the one performed by ip6_sk_update_pmtu() / ip6_sk_redirect(). When the two resolve to different nexthops, it also results in two exceptions being created for the same destination IP. One in the exception cache of the nexthop resolved by the no socket helpers and another in the exception cache of the nexthop used by the socket. Fixes: 2b760fcf5cfb ("ipv6: hook up exception table to store dst cache") Cc: stable@vger.kernel.org Reported-by: Amit Klein Reported-by: Noam Caspi Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260828192344.2596928-4-idosch@nvidia.com Signed-off-by: Jakub Kicinski commit 4c3499f79f8c7e8561266bcc220a18538cec0458 Author: Ido Schimmel Date: Fri Aug 28 22:23:42 2026 +0300 ipv4: udp: Create exceptions before socket matching Currently, when ICMP Fragmentation Needed and Redirect Message packets are locally delivered and quote a UDP packet, a FIB nexthop exception (FNHE) is only created if the kernel can match the UDP packet to an existing socket. This behavior allows off-path attackers to conduct a side-channel attack on the FNHE cache in order to discover the ephemeral port used by a connected UDP socket. Commit 6457378fe796 ("ipv4: use siphash instead of Jenkins in fnhe_hashfun()") and commit 67d6d681e15b ("ipv4: make exception cache less predictible") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the FNHE cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed. Instead, mitigate such attacks by always creating a FNHE, even before trying to find a matching socket. Do that by calling ipv4_update_pmtu() and ipv4_redirect(), the helpers used when the quoted packet did not originate from a socket. This means that guesses (right or wrong) from an off-path attacker will always result in a FNHE being created or updated in the cache that the attacker can observe. Pass an oif of 0, in a similar fashion to icmp_err(). This is also the oif used by the socket path for sockets that are not bound to a device. Note that this does not allow attackers to create FNHEs that they could not create before, as both helpers can already be reached with little to no validation. For example, by sending an ICMP error that quotes an ICMP Echo Reply or one that quotes a UDP source port that matches a wildcard socket. Also note that in the good case (matched socket) the above scheme comes at the cost of an extra route lookup, as the no socket helpers perform their own lookup before the one performed by ipv4_sk_update_pmtu() / ipv4_sk_redirect(). When the two resolve to different nexthops, it also results in two exceptions being created for the same destination IP. One in the FNHE cache of the nexthop resolved by the no socket helpers and another in the FNHE cache of the nexthop used by the socket. Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.") Cc: stable@vger.kernel.org Reported-by: Amit Klein Reported-by: Noam Caspi Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260828192344.2596928-3-idosch@nvidia.com Signed-off-by: Jakub Kicinski commit cd51b74bdd0b75aedf255dc67306a16dd057f7ee Author: Ido Schimmel Date: Fri Aug 28 22:23:41 2026 +0300 ipv6: Fix redirect exception creation for UDP/RAW sockets 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 commit 68c90773f40f91f48a557e9fa65e2a72cebc58df Merge: d6eac386814356 1713cc6b0e1904 0c4775d3a756b9 Author: Borislav Petkov (AMD) Date: Mon Aug 31 19:29:47 2026 -0700 Merge remote-tracking branches 'ras/edac-misc', 'ras/edac-drivers' and 'ras/edac-amd-atl' into edac-updates * ras/edac-misc: EDAC/thunderx: Orphan it EDAC/device_sysfs: Cleanup around edac_device_ctl_poll_msec_store() EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation MAINTAINERS: Add Radhey Shyam Pandey as Xilinx EDAC reviewer MAINTAINERS: Remove Mark Gross from relevant entries EDAC/sysfs: Use sysfs_emit_at() in dimmdev_location_show() EDAC/mpc85xx: Orphan it * ras/edac-drivers: EDAC/igen6: Add Intel Starfire SoCs support EDAC/igen6: Refactor address translation logic EDAC/igen6: Remove redundant resource configuration tables EDAC/igen6: Detect present memory controllers at runtime EDAC/igen6: Simplify compute die ID comments EDAC/igen6: Remove unnecessary XOR on the zero-valued interleave bit EDAC/igen6: Fix Raptor Lake-P logged error address EDAC/igen6: Fix channel address decode for non-hash mode EDAC/igen6: Fix channel selection hash EDAC/igen6: Fix interleave boundary condition EDAC/ie31200: Decouple DIMM width decoding from enum order EDAC: Remove redundant dev_err() EDAC/altera: Remove remaining CONFIG_64BIT ifdefs in the DB-error path EDAC/altera: Use ECC manager compatible to select A10/S10 IRQ layout * ras/edac-amd-atl: RAS/AMD/ATL: Remove conditional return with no effect RAS/AMD/ATL, EDAC/amd64: Only load ATL when needed EDAC/debugfs: Remove the fake_inject debugfs interface Signed-off-by: Borislav Petkov (AMD) commit da7c937e0abc86710e237e88bbaaff4a298e48d1 Author: Vladislav Leonov Date: Sun Aug 23 15:20:34 2026 +0300 dt-bindings: iio: adc: rockchip-saradc: Fix RV1106 compatible rockchip,rv1106-saradc was folded into the fallback enum together with rockchip,rk3576-saradc, falling back to rockchip,rk3588-saradc. The two IP blocks are not equivalent, though: per the RV1106 TRM v0.3, chapter 20 (SAR-ADC), RV1106 only has 2 channels at 10-bit resolution, versus 8 channels at 12-bit on RK3588. Documenting it as falling back to rk3588-saradc allows device trees that would bind against the wrong channel table and report an incorrect voltage scale. Remove rockchip,rv1106-saradc from the RK3588 fallback enum and give it its own standalone compatible entry, matching the dedicated match table entry added by the driver patch. Fixes: bdba14f6122c ("dt-bindings: iio: adc: rockchip-saradc: Add RV1106 compatible") Suggested-by: Jonathan Cameron Signed-off-by: Vladislav Leonov Acked-by: Conor Dooley Signed-off-by: Jonathan Cameron commit df82be40ae0868be98c8febaf7928cf3e44f7ab9 Author: Vladislav Leonov Date: Sun Aug 23 15:20:33 2026 +0300 dt-bindings: iio: adc: rockchip-saradc: Group single-entries into an enum list Group single-entries into an enum list Suggested-by: Krzysztof Kozlowski Signed-off-by: Vladislav Leonov Acked-by: Conor Dooley Signed-off-by: Jonathan Cameron commit 6693171c8c540b3a54e671992f0561613076fc3b Author: Xixin Liu Date: Tue Aug 18 17:10:00 2026 +0800 perf: RISC-V: use BIT_ULL for u64 overflow masks Overflow status and restart masks are u64, but bits were built with BIT(). On RV32 that is an unsigned long shift, so indices >= 32 truncate or wrap and corrupt the mask. Use BIT_ULL() for those u64 bitops. Fixes: a8625217a054 ("drivers/perf: riscv: Implement SBI PMU snapshot function") Assisted-by: DeepSeek:deepseek-v3 Signed-off-by: Xixin Liu Link: https://patch.msgid.link/prpmask01bitul.v2.1786434000.git.liuxixin@kylinos.cn Cc: stable@vger.kernel.org [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley commit ddeaa39406c4cf680643412cd1f75bb98a641f6c Author: Jisheng Zhang Date: Mon Aug 31 19:11:23 2026 -0600 riscv: bug: Make RV32 use GENERIC_BUG_RELATIVE_POINTERS x86 did this in commit b0a848f4a47a ("x86/bugs: Make i386 use GENERIC_BUG_RELATIVE_POINTERS") powerpc did this in commit 1baa1f70ef77 ("powerpc: Allow relative pointers in bug table entries") Similar as x86 and powerpc does, make RV32 use GENERIC_BUG_RELATIVE_POINTERS for "there is only one code path." and "less #ifdef is more better". Signed-off-by: Jisheng Zhang Link: https://patch.msgid.link/20260221024255.3552-1-jszhang@kernel.org Signed-off-by: Paul Walmsley commit d0fc6fab20460add1f27402cd8b945d094a56b21 Author: Andy Chiu Date: Mon Aug 31 19:11:23 2026 -0600 riscv: hwprobe: initialize pair->value in hwprobe_one_pair() The vendor-extension handlers reached from hwprobe_one_pair() (hwprobe_isa_vendor_ext_thead_0() and friends) only OR the present bits into pair->value via VENDOR_EXTENSION_SUPPORTED() and clear their own missing bits; they assume the caller has already zeroed pair->value. That holds for hwprobe_get_values() (it zeroes each pair) and hwprobe_get_cpus() (it re-initializes its scratch pair per key), but not for complete_hwprobe_vdso_data(), which reuses a single pair across all keys without re-zeroing. A vendor key therefore inherits stale bits from the previously probed key, and the wrong value is cached in the vDSO all_cpu_hwprobe_values[] and handed to userspace on the fast patih. Zero pair->value once at the top of hwprobe_one_pair() so every handler starts from a clean value regardless of the caller, and drop the now redundant zeroing in the *_BLOCK_SIZE cases. hwprobe_isa_ext0() keeps its own zeroing because hwprobe_ext0_has() calls it directly, bypassing hwprobe_one_pair(). Fixes: a5ea53da65c5 ("riscv: hwprobe: Add thead vendor extension probing") Signed-off-by: Andy Chiu Reviewed-by: Jesse Taube Link: https://patch.msgid.link/20260725001614.2578617-2-tchiu@tenstorrent.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley commit 12381af01024f4a59cd3f673fb3644bbe2ca3aad Author: Dmitry Antipov Date: Mon Aug 31 19:11:23 2026 -0600 riscv: use string helper in setup_global_riscv_enable() Prefer the convenient string choice 'str_disabled_enabled()' helper over hardcoded strings in 'setup_global_riscv_enable()'. Signed-off-by: Dmitry Antipov Link: https://patch.msgid.link/20260819160546.3219942-1-dmantipov@yandex.ru Signed-off-by: Paul Walmsley commit 2d2184ac90365a4af3274e23c98d469f09f91749 Author: Samuel Holland Date: Mon Aug 31 19:11:23 2026 -0600 Revert "riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set" This reverts commit 3033b2b1e3949274f33a140e2a97571b5a307298. The reverted patch is userspace-visible behavior change, not a bug fix. The two variables here (pmm and pmlen) control two independent features: pmm is the _hardware_ pointer masking mode that applies while executing in userspace. pmlen is the shift amount that the _kernel_ uses when untagging addresses; PMLEN_0 means no untagging occurs, so the kernel does not accept tagged addresses in syscall arguments. It is valid (as documented and tested by the self test) to enable pointer masking without enabling the tagged address ABI. This separation is necessary to allow userspace to create an execution environment similar to what the kernel supports on arm64 by default, where TBI is enabled but the tagged address ABI is not. (On arm64, there is no equivalent to PR_PMLEN_MASK because TBI is always enabled.) Signed-off-by: Samuel Holland Link: https://patch.msgid.link/20260820014551.1979772-1-samuel.holland@sifive.com Cc: stable@vger.kernel.org Fixes: 3033b2b1e394 ("riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set") Signed-off-by: Paul Walmsley commit 8718e5a3090bbfd759801d088b700aab21e8e989 Author: Xiaofeng Yuan Date: Mon Aug 31 19:11:23 2026 -0600 riscv: patch: skip fixmap mapping when kernel text is already writable patch_map() always creates a temporary writable mapping via fixmap for kernel text addresses, even when CONFIG_STRICT_KERNEL_RWX is disabled and the kernel text is already mapped with _PAGE_WRITE. This is unnecessary overhead at best, and on minimal configurations it can cause page faults. Skip the fixmap path for kernel text when CONFIG_STRICT_KERNEL_RWX is not enabled, since the text pages are already writable in that case. The module text path is already gated on CONFIG_STRICT_MODULE_RWX and is kept unchanged. Reported-by: Klara Modin Closes: https://lore.kernel.org/all/ant_8TaBbov_GS4i@soda.int.kasm.eu/ Reported-by: Lad Prabhakar Closes: https://lore.kernel.org/all/CA+V-a8tQK8rih9SGGTyqrEBGpNkx4H0eX2YccCRrgkVAPr+EBg@mail.gmail.com/ Tested-by: Klara Modin Tested-by: Lad Prabhakar Link: https://patch.msgid.link/20260814082742.148403-3-xiaofengmian@163.com Signed-off-by: Paul Walmsley commit bdc46e507b59ac44c8e1dab505121f18c2add1ab Author: Xiaofeng Yuan Date: Mon Aug 31 19:11:22 2026 -0600 riscv: mm: make EXECMEM_KPROBES writable without CONFIG_STRICT_MODULE_RWX When CONFIG_STRICT_MODULE_RWX is not set, execmem cannot create temporary writable mappings for read-only executable pages. In this case, the execmem ranges must already have writable permissions. Currently EXECMEM_KPROBES unconditionally uses PAGE_KERNEL_READ_EXEC, which causes kprobe instruction slot writes to trigger page faults on systems where CONFIG_STRICT_MODULE_RWX is not enabled. Fix this by using PAGE_KERNEL_EXEC when CONFIG_STRICT_MODULE_RWX is not available. Signed-off-by: Xiaofeng Yuan Tested-by: Lad Prabhakar Reviewed-by: Nam Cao Link: https://patch.msgid.link/20260814082742.148403-2-xiaofengmian@163.com Signed-off-by: Paul Walmsley commit 97cc84dad1d7f68a36b71b69b361d88482707673 Author: Eric Dumazet Date: Fri Aug 28 10:37:31 2026 +0000 ip6_gre: check tunnel info before xmit in ip6gre_tunnel_xmit Shuangpeng Bai reported a KASAN slab-use-after-free in ip6gre_tunnel_xmit(). The precise KASAN bug was caused by ip6_tnl_xmit() consuming the skb during headroom expansion and returning an error, while ip6gre_tunnel_xmit() still held the stale pointer and called skb_tunnel_info_txcheck(skb) at tx_err. That specific bug was fixed by commit 87f21b59ddc6 ("ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit()"). However, calling skb_tunnel_info_txcheck(skb) at the tx_err label after the transmission attempt remains problematic: Downstream helpers like ip6_tnl_xmit() call skb_scrub_packet(), which drops the skb's metadata_dst before transmission. If an error occurs later during transmit, inspecting skb at tx_err sees a scrubbed dst and misclassifies tx_errors vs tx_dropped. Commit e5f7e211b6aa ("ip6gre: avoid tx_error when sending MLD/DAD on external tunnels") already handled this correctly in ip6erspan_tunnel_xmit() by checking and caching tun_info before transmit. Align ip6gre_tunnel_xmit() with ip6erspan_tunnel_xmit() by caching tun_info before xmit and checking it at tx_err. Fixes: e5f7e211b6aa ("ip6gre: avoid tx_error when sending MLD/DAD on external tunnels") Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/netdev/20260819062224.3197349-1-shuangpeng.kernel@gmail.com/ Cc: Davide Caratti Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828103731.1951815-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit ec12bdd56861b305ba4fa9da50729bd32e5a927f Merge: d8d4d1cf40d541 b4cf4a092a7bda Author: Jakub Kicinski Date: Mon Aug 31 17:54:47 2026 -0700 Merge branch 'ipv6-mcast-rcu-and-timer-fixes' Eric Dumazet says: ==================== ipv6: mcast: RCU and timer fixes This series addresses several RCU synchronization and timer calculation issues identified in IPv6 multicast (MLD) handling within net/ipv6/mcast.c while I was working on fixing a syzbot report in net/ipv4/icmp.c. Patch 1 fixes an RCU reader diversion in ip6_mc_del1_src() where mutating psf->sf_next to insert an unlinked source node into the tombstone list diverted concurrent lockless readers (e.g. ipv6_chk_mcast_addr()) into pmc->mca_tomb, causing them to miss remaining active sources. Patch 2 converts ip6_mc_source() to use copy-on-write RCU updates. Previously, source additions and deletions modified the socket's psl->sl_addr array in-place, causing concurrent lockless readers in inet6_mc_check() (UDP/RAW receive path) to observe torn 16-byte IPv6 addresses or duplicated/missed sources. Patch 3 fixes delay calculation in igmp6_join_group() when canceling an existing delayed work, preventing unsigned jiffies underflows when the timer has already expired and clamping the delay to the unsolicited report interval. Patch 4 ensures rcu_assign_pointer() is consistently used for __rcu list updates in __ipv6_dev_mc_dec(), ipv6_sock_mc_drop(), __ipv6_sock_mc_close(), and related helpers. Patch 5 switches igmp6_mc_seq_show() to use jiffies_delta_to_clock_t() with a signed long delta, preventing underflows in /proc/net/igmp6 timer duration reporting. ==================== Link: https://patch.msgid.link/20260828084531.1826790-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit b4cf4a092a7bdaa62acca39c28f386b6d1674968 Author: Eric Dumazet Date: Fri Aug 28 08:45:31 2026 +0000 ipv6: mcast: use jiffies_delta_to_clock_t() in igmp6_mc_seq_show() If a multicast group timer has expired but the delayed work has not yet run to clear MAF_TIMER_RUNNING, expires - jiffies produces a negative value. Because unsigned arithmetic was used with jiffies_to_clock_t(), expires - jiffies underflows to a huge value and reports invalid timer durations in /proc/net/igmp6. Use jiffies_delta_to_clock_t() with a signed long delta to properly cap expired deltas to 0, matching IPv4 igmp_mc_seq_show() and commit a399a8053164 ("time: jiffies_delta_to_clock_t() helper to the rescue"). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828084531.1826790-6-edumazet@google.com Signed-off-by: Jakub Kicinski commit 0c8f56c583c3250408367880c98e4d6fbc929315 Author: Eric Dumazet Date: Fri Aug 28 08:45:30 2026 +0000 ipv6: mcast: use rcu_assign_pointer() for __rcu list updates 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 commit 75fa9caeb8aaba19c2463dee0b0a1e09d39c04af Author: Eric Dumazet Date: Fri Aug 28 08:45:29 2026 +0000 ipv6: mcast: fix delay calculation in igmp6_join_group() When joining a multicast group, if a report work is already pending (e.g. scheduled by a query or a previous join), igmp6_join_group() cancels the delayed work and recalculates the delay: if (cancel_delayed_work(&ma->mca_work)) { refcount_dec(&ma->mca_refcnt); delay = ma->mca_work.timer.expires - jiffies; } Unlike igmp6_group_queried(), igmp6_join_group() did not check if delay >= interval. This leads to two issues: 1. If the timer has already expired (timer.expires <= jiffies), the stale expiry is reused by mod_delayed_work(), causing the second unsolicited report to fire on the very next tick without a randomized delay. 2. If the timer was originally armed by a query with a large maximum response delay, delay could exceed unsolicited_report_interval(ma->idev). Fix this by initializing delay to unsolicited_report_interval(ma->idev) and re-randomizing it with get_random_u32_below(interval) when delay >= interval, mirroring the logic in igmp6_group_queried(). Fixes: 2d9a93b4902b ("mld: convert from timer to delayed work") Signed-off-by: Eric Dumazet Cc: Taehee Yoo Reviewed-by: Ido Schimmel Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://patch.msgid.link/20260828084531.1826790-4-edumazet@google.com Signed-off-by: Jakub Kicinski commit c073d1b070f171d206b19c98d71739a97f15b3f1 Author: Eric Dumazet Date: Fri Aug 28 08:45:28 2026 +0000 ipv6: mcast: use copy-on-write RCU updates in ip6_mc_source() pmc->sflist is read locklessly under rcu_read_lock() by inet6_mc_check() during packet reception in the UDP and RAW multicast receive paths. ip6_mc_source() mutated psl->sl_addr and psl->sl_count in-place when adding or removing a source filter. Additionally, when expanding the filter buffer, newpsl was published via rcu_assign_pointer() before writing the new source into the array. Because 16-byte struct in6_addr writes are not atomic and array shifting is not synchronized with RCU readers, concurrent readers in inet6_mc_check() could read torn IPv6 addresses or observe duplicated/missed source entries. Fix this by switching ip6_mc_source() to copy-on-write RCU updates: allocate and fully populate newpsl before publishing it via rcu_assign_pointer(), and reclaim the old filter via kfree_rcu(), matching ip6_mc_msfilter(). Also remove the now unused IP6_SFBLOCK macro. Fixes: 882ba1f73c06 ("mld: convert ipv6_mc_socklist->sflist to RCU") Signed-off-by: Eric Dumazet Cc: Taehee Yoo Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828084531.1826790-3-edumazet@google.com Signed-off-by: Jakub Kicinski commit 93b49239840b91313adbd77b8b52993eff2d08c1 Author: Eric Dumazet Date: Fri Aug 28 08:45:27 2026 +0000 ipv6: mcast: fix RCU list diversion in ip6_mc_del1_src() When removing a source filter whose count reaches zero, ip6_mc_del1_src() unlinks psf from pmc->mca_sources. If the filter was previously active, the code moved psf directly into pmc->mca_tomb by updating psf->sf_next. Because pmc->mca_sources is traversed locklessly under RCU (e.g. by ipv6_chk_mcast_addr()), mutating psf->sf_next before a grace period elapses diverts concurrent readers to the tombstone list. Consequently, readers miss remaining active sources in pmc->mca_sources and improperly examine deleted tombstone entries. Fix this by allocating a new tombstone node for pmc->mca_tomb (as done in sf_setstate()) and retiring the original psf via kfree_rcu(). Fixes: 4b200e398953 ("mld: convert ip6_sf_list to RCU") Signed-off-by: Eric Dumazet Cc: Taehee Yoo Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260828084531.1826790-2-edumazet@google.com Signed-off-by: Jakub Kicinski commit ac323c9467092479dc1e5bc138c9abbe015b0069 Author: Josh Poimboeuf Date: Fri Aug 28 10:48:50 2026 -0700 objtool/klp: Fix checksums for constant pool references Adding a line of code to __link_shadow_page() with a literal string causes a false positive changed function with GCC: arch/x86/kvm/kvm.ko.o: changed function: kvm_tdp_mmu_map_private_pfn While the patch only touched __link_shadow_page(), the string addition triggered a rename of .LC64 -> .LC65 in kvm_tdp_mmu_map_private_pfn() even though the underlying referenced constant data didn't change. So for .LC* symbols, the suffix is arbitrary but the data isn't. Add the underlying data to the checksum calculation rather than the symbol name. Clang also uses .LC* symbols, but also uses anonymous data. Both compilers put this data in .rodata.cst sections. Fixes: 0d83da43b1e1 ("objtool/klp: Add --checksum option to generate per-function checksums") Link: https://patch.msgid.link/f3a9e74ceebc6475ce94bcfe985401140857814a.1787939301.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf commit 738ef4cd82818b13f492fd5ddec7e00f177ffe60 Author: Andi Kleen Date: Mon Aug 31 08:04:37 2026 -0700 uprobes: guard trace cleanup against error pointers Sashiko pointed out the some of the scope cleanups for free_uprobe could get an error pointer. Handle this case in free_uprobe to prevent a crash. On the other hand the macro doesn't need the guard because free_uprobe itself already does the check. Link: https://lore.kernel.org/all/20260831150651.1134594-2-ak@kernel.org/ Assisted-by: omp:gpt-5.6-luna sashiko Signed-off-by: Andi Kleen Signed-off-by: Masami Hiramatsu (Google) commit 4825ef699cda4c6f2f0586b17a5e225560481da6 Author: Yafang Shao Date: Sun Aug 16 17:04:41 2026 +0800 klp-build: Fix wrong index in funcs cleanup error path In the object allocation loop, when kzalloc() for funcs fails, the cleanup loop uses `objs[i].funcs` instead of `objs[j].funcs`. Since `objs[i].funcs` is still NULL at that point, it repeatedly calls kfree(NULL) and leaks all previously allocated funcs arrays. Fixes: 59adee07b568 ("livepatch/klp-build: Add stub init code for livepatch modules") Signed-off-by: Yafang Shao Acked-by: Song Liu Reviewed-by: Petr Mladek Acked-by: Miroslav Benes Link: https://patch.msgid.link/20260816090442.18128-2-laoar.shao@gmail.com Signed-off-by: Josh Poimboeuf commit d8d4d1cf40d541a5d7cc3b15d57e42d0815c7d53 Author: Qingfang Deng Date: Fri Aug 28 15:32:37 2026 +0800 ppp: ppp_synctty: simplify tty disc_data access Apply the same simplification as the preceding ppp_async change. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+b503105c2410c3433459@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=b503105c2410c3433459 Signed-off-by: Qingfang Deng Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260828073245.126804-2-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski commit 9feb069e5ed03582fbf6272539f1caa2a17dc6d5 Author: Qingfang Deng Date: Fri Aug 28 15:32:36 2026 +0800 ppp: ppp_async: simplify tty disc_data access tty_ldisc_hangup() invokes the hangup callback while holding only a read lock on tty->ldisc_sem, so it can run concurrently with other line discipline callbacks. This currently forces async PPP to maintain separate lifetime protection around tty->disc_data. Line discipline close is called under the write lock during hangup processing. Remove the hangup callback and rely on close for teardown, as done for SLIP by commit 23c53269f2ba ("slip: remove slip_hangup() to fix use-after-free in slip_receive_buf()"). This serializes teardown with all other line discipline operations. disc_data_lock, refcount and completion are redundant with that serialization. Remove them and access tty->disc_data directly. This also eliminates a lockdep warning reported by syzbot. The warning does not indicate a real deadlock because the write side runs only in process context with hardirqs disabled. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+8e808eb853386f575d86@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/0000000000002fbad30611e25849@google.com/ Signed-off-by: Qingfang Deng Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260828073245.126804-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski commit 2987ee196c88dbde0463dc87d5fb209c684e34a2 Author: Eric Dumazet Date: Thu Aug 27 16:06:56 2026 +0000 igmp: convert struct ip_sf_list to RCU Commit 23d2b94043ca ("igmp: Add ip_mc_list lock in ip_check_mc_rcu") added spin_lock_bh(&im->lock) to ip_check_mc_rcu() to prevent a use-after-free while iterating im->sources during concurrent deletions. However, ip_check_mc_rcu() is called from RCU read-side critical sections in packet receive and route lookup fast paths (e.g. __mkroute_output(), ip_route_input_rcu(), and __udp4_lib_rcv()). When igmpv3_send_cr() or igmpv3_send_report() holds &pmc->lock and calls add_grec() -> igmpv3_newpack() -> ip_route_output_ports(), an XFRM policy matching a multicast destination triggers xfrm_tmpl_resolve_one() -> xfrm4_get_saddr() -> __mkroute_output() -> ip_check_mc_rcu(). This attempts to acquire &im->lock while &pmc->lock is already held on the same CPU, triggering a lockdep recursive locking warning / deadlock. Fix this by converting IPv4 struct ip_sf_list to RCU, mirroring the IPv6 implementation in net/ipv6/mcast.c: 1. Add struct rcu_head to struct ip_sf_list and annotate sf_next, sources, and tomb as __rcu pointers. 2. Use rcu_assign_pointer() and kfree_rcu() for list updates and deletions. 3. Remove spin_lock_bh(&im->lock) from ip_check_mc_rcu() and traverse im->sources locklessly with for_each_psf_rcu(), reading and writing counter fields with READ_ONCE() and WRITE_ONCE(). Note: RCU conversion of /proc/net/mcfilter will be done in a separate patch. Fixes: 23d2b94043ca ("igmp: Add ip_mc_list lock in ip_check_mc_rcu") Reported-by: syzbot+3d99fb01bcd740f2fc1e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3d99fb01bcd740f2fc1e Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260827160656.903003-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit e510334fbaeaa016ac76d80b4c5f47611c5f7860 Author: Mehmet Koseoglu Date: Fri Aug 28 04:50:20 2026 +0300 rust: samples: add missing newlines in rust_print_main Calls to `pr_info!` in `arc_print` are missing trailing newlines, which are expected as the `pr_*!` documentation shows. Add the missing `\n` to all four formatting strings. Fixes: f431c5c581fa ("samples: rust: print: Add sample code for Arc printing") Fixes: 47cb6bf7860c ("rust: use derive(CoercePointee) on rustc >= 1.84.0") Suggested-by: Miguel Ojeda Link: https://github.com/Rust-for-Linux/linux/issues/1139 Signed-off-by: Mehmet Koseoglu Link: https://patch.msgid.link/20260828015148.221737-2-mehmet.mkoseoglu@gmail.com [ Reworded to fix the description of the missing-newline behavior. - Miguel ] Signed-off-by: Miguel Ojeda commit 1ea9fff22bf6107b421d2978e097865f73714382 Merge: fee10655709c5c 2deb76c21b81e4 Author: Jakub Kicinski Date: Mon Aug 31 17:12:02 2026 -0700 Merge tag 'for-net-2026-08-31' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: Core: - hci_core: Fix race condition during device registration - L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan - L2CAP: fix out-of-bounds write in l2cap_ecred_connect - L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM Drivers: - hci_mrvl: Fix wrong return value check of wait_on_bit_timeout() - btintel_pcie: Clear automask on spurious interrupts - btintel: validate version TLV value lengths - btintel: bound firmware ID by TLV length - btintel: propagate version TLV parsing errors * tag 'for-net-2026-08-31' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: hci_mrvl: Fix wrong return value check of wait_on_bit_timeout() Bluetooth: L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM Bluetooth: L2CAP: fix out-of-bounds write in l2cap_ecred_connect Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan Bluetooth: hci_core: Fix race condition during device registration Bluetooth: btintel: propagate version TLV parsing errors Bluetooth: btintel: bound firmware ID by TLV length Bluetooth: btintel: validate version TLV value lengths Bluetooth: btintel_pcie: Clear automask on spurious interrupts ==================== Link: https://patch.msgid.link/20260831181837.946230-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski commit fee10655709c5c597e8e9f722f3035d9ea31ff3a Author: Aohan Mei Date: Wed Aug 26 10:51:20 2026 +0800 net/sched: cls_flower: validate mask pointer after nla_next() fl_set_enc_opt() iterates the key's nested tunnel-option attributes with nla_for_each_attr() while advancing a single mask pointer via nla_next() at the bottom of each loop, so the mask cursor is driven by the number of key attributes rather than by the mask's own attributes. The nla_ok() added by commit c96adff956191 ("cls_flower: call nla_ok() before nla_next()") only validates the mask pointer that was just consumed; the pointer produced by nla_next() is used by the next iteration (fl_set_geneve_opt() and siblings) without any validation. The mask's nested attributes are validated with NL_VALIDATE_LIBERAL, which merely warns on trailing bytes that do not form a complete attribute. A mask carrying one valid attribute plus 1-3 residue bytes (or a non-aligned attribute length making msk_depth negative) therefore reaches the next iteration with msk_depth != 0, so neither the !msk_depth check in fl_set_enc_opt() nor the !depth check in the per-type helpers fires. nla_type() then reads past the mask payload and nla_parse_nested_deprecated() iterates with an nla_len taken from those bytes, reading well beyond the mask attribute (KASAN: slab-out-of-bounds read in __nla_validate_parse from fl_change()). Validate the advanced mask pointer as well: when the mask is not legitimately exhausted (msk_depth != 0) and the new pointer fails nla_ok(), reject the filter with -EINVAL. An exactly exhausted mask still skips the check, preserving exact-match behaviour for the remaining key attributes. Fixes: c96adff95619 ("cls_flower: call nla_ok() before nla_next()") Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Signed-off-by: Aohan Mei Link: https://patch.msgid.link/20260826025123.62758-1-ljp1205831794@gmail.com Signed-off-by: Jakub Kicinski commit 9d0f206eb38dbf9e56f94285dcf5138146bde89c Merge: dc0df5a0c62cce ad9a7da3fa39c2 Author: Jakub Kicinski Date: Mon Aug 31 16:50:58 2026 -0700 Merge branch 'vsock-validate-packet-sources-after-bound-lookup-fallback' Daehyeon Ko says: ==================== vsock: validate packet sources after bound lookup fallback Both virtio and VMCI look up connected sockets by the full tuple before falling back to a destination-only bound lookup. The fallback can select a non-listening socket without validating the packet source. V2 covered only the virtio path. Following Stefano's review, this series moves the source and transport validation into a documented AF_VSOCK helper and uses it for both virtio and VMCI. The VMCI patch checks both its bottom-half and deferred workqueue receive paths. V4 preserves VMCI's existing RST behavior when source validation fails. The reset is addressed from the received packet so that a bound but non-listening or concurrently closed socket still notifies the sender, without directing the reset to a connected socket's stored peer. The v3 regression was reproduced in three x86_64 KASAN boots: a REQUEST to a bound but non-listening socket returned VMCI_ERROR_NO_ACCESS but no RST arrived within one second. With v4, the sending context received the expected RST in all three boots. The original VMCI source-validation oracle also passed in three v4 boots: a matched RST reset the pending socket while a mismatched-context RST left it pending. No KASAN report occurred. Patch 1 is unchanged from v3 (identical stable patch-id) and carries Bobby's Reviewed-by for that revision. Its v3 validation covered the cross-UID injection oracle, local CID aliases, selected VSOCK selftests, and W=1 changed-object builds under allmodconfig and allyesconfig. The current-tree guest-CID vhost probe could not be rerun because the test user lacks access to /dev/vhost-vsock. ==================== Link: https://patch.msgid.link/20260826003929.966160-1-4ncienth@gmail.com Signed-off-by: Jakub Kicinski commit ad9a7da3fa39c2d616ec0dd3cf6e30531d032fe7 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Aug 26 09:39:28 2026 +0900 vsock/vmci: validate packet source for connected sockets vmci_transport_recv_stream_cb() looks up sockets first by the full source and destination tuple, then by destination only in the bound table. The fallback can select a non-listening socket without checking whether the packet came from its stored peer. This was reproduced with two VMCI contexts. A RST from the context not stored in a TCP_SYN_SENT socket reset that socket after it was selected by the destination-only lookup. VMCI can process notification packets in bottom-half context when the socket is not owned by user context, or defer packets to a workqueue. Use vsock_check_source() after taking the socket lock in the bottom-half path, and recheck after lock_sock() in the workqueue path. Listening sockets continue to accept packets from any source. Reply with a RST addressed from the received packet before dropping a source that fails validation. This preserves the existing reset behavior for bound non-listening and concurrently closed sockets without directing the reset to a connected socket's stored peer. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reported-by: Sashiko Closes: https://lore.kernel.org/netdev/20260814121255.6B5001F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Suggested-by: Stefano Garzarella Suggested-by: Paolo Abeni Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Vishnu Dasa Link: https://patch.msgid.link/20260826003929.966160-3-4ncienth@gmail.com Signed-off-by: Jakub Kicinski commit dee44f41f206becb41c492899c1996cfd7f82a1b Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Aug 26 09:39:27 2026 +0900 vsock/virtio: validate packet source for connected sockets virtio_transport_recv_pkt() looks up sockets first by the full source and destination tuple, then by destination only in the bound table. The fallback is needed for listening and connecting sockets, but sockets remain in the bound table after connect(), so it can also return a non-listening socket. The fallback does not validate the source address. In TCP_SYN_SENT, a RESPONSE from an unrelated source can transition the victim socket to TCP_ESTABLISHED while its stored remote address remains unchanged. Subsequent RW packets from that source are delivered through the same destination-only fallback. This was reproduced with capability-empty processes under different UIDs. The attacker discovered the target tuple through unprivileged AF_VSOCK sock_diag and caused the victim socket to read 16 attacker-chosen bytes; the intended peer-side socket read 0 of those 16 bytes. Add vsock_check_source() to validate the transport, source port and source CID against the peer stored in a non-listening socket. The local transport is the CID exception because its packets are generated internally with VMADDR_CID_LOCAL as their source, including connections using CID aliases. Use the helper after lock_sock() in the virtio receive path. Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko") Closes: https://lore.kernel.org/netdev/20260813121236.2328599-1-4ncienth@gmail.com/ Cc: stable@vger.kernel.org Suggested-by: Stefano Garzarella Reviewed-by: Bobby Eshleman Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/20260826003929.966160-2-4ncienth@gmail.com Signed-off-by: Jakub Kicinski commit b6b9e6d4abe87b16ab55990b887c6fad8e7a01af Author: Gary Guo Date: Fri Aug 28 16:50:33 2026 +0100 rust: pin-init: use irrefutable pattern for `stack_pin_init` In Rust 1.100.0, `Infallible` will become an alias of `!`. The let binding in `stack_pin_init` will thus become unreachable and produce an "unreachable expression" warning for the subsequent match, and thus will fail a `-Dwarnings` build. For this macro, all we need to know is that the error type is uninhabited, so replace this with an irrefutable pattern instead. [ The error looks like (dummy reproducer): error: unreachable expression --> rust/kernel/sync.rs:177:5 | 177 | pin_init::stack_pin_init!(let num = 42u32); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | | | unreachable expression | any code following this expression is unreachable | = note: `-D unreachable-code` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unreachable_code)]` = note: this error originates in the macro `pin_init::stack_pin_init` (in Nightly builds, run with -Z macro-backtrace for more info) - Miguel ] Reported-by: Mohamad Alsadhan Closes: https://github.com/Rust-for-Linux/pin-init/pull/171 Signed-off-by: Gary Guo Cc: stable@vger.kernel.org # Needed in 7.1.y and later (for 6.12.y and 6.18.y a custom one is needed). Link: https://patch.msgid.link/20260828155033.2101924-1-gary@kernel.org [ Reworded for typos. - Miguel ] Signed-off-by: Miguel Ojeda commit dc0df5a0c62ccea1d0e08d39a4dc9064de81d411 Author: Florian Schauer Date: Fri Aug 28 08:08:22 2026 +0200 page_pool: keep frag_offset aligned for odd-sized requests page_pool_alloc_frag_netmem() rounds the requested fragment size with size = ALIGN(size, dma_get_cache_alignment()); dma_get_cache_alignment() returns 1 unless the architecture defines ARCH_DMA_MINALIGN, which DMA-coherent architectures such as x86 do not. There the ALIGN() is a no-op and pool->frag_offset advances by the raw, unrounded size. A single caller asking for an odd size then leaves frag_offset misaligned for every fragment carved out of that page afterwards. The pool is shared, so the damage is not confined to the caller that caused it. The per-cpu system_page_pool used by generic XDP hits this. skb_pp_cow_data() allocates its fragments with the raw packet length: size = min_t(u32, len, PAGE_SIZE); truesize = size; page = page_pool_dev_alloc(pool, &page_off, &truesize); leaving frag_offset odd for whatever is carved out of that page next. Its own head allocation is already aligned -- SKB_HEAD_ALIGN(size) plus the XDP_PACKET_HEADROOM its callers pass -- so it is a later user of the shared pool that pays: page_pool_dev_alloc_va() returns a misaligned buffer, napi_build_skb() installs it as skb->head, and skb_shinfo(skb) == skb->head + skb->end is misaligned with it. skb_shinfo()->dataref is a 4-byte atomic_t at offset 0x20, so the atomic_inc() in __skb_clone() straddles a cache line. On x86 with split lock detection -- fatal for kernel split locks by default -- this panics the machine: Oops: Split lock detected RIP: 0010:skb_clone+0x154/0x1e0 Call Trace: raw_local_deliver+0x1ed/0x2c0 ip_protocol_deliver_rcu+0x54/0x1c0 ip_local_deliver_finish+0x85/0x100 ip_local_deliver+0x67/0x100 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 Reproduced by attaching any generic-mode XDP program to loopback and opening a RAW IPPROTO_UDP socket, which makes raw_local_deliver() clone every locally delivered UDP packet; ordinary DNS traffic then triggers it, roughly once per 2500 clones. Observed on 6.12.101 and 7.1.8. Tracing page_pool_alloc_frag_netmem() over one such run shows the amplification -- two odd-sized requests, nine misaligned offsets: requested size & 7: 0: 17035 5: 1 7: 1 frag_offset & 7: 0: 17028 3: 1 4: 1 5: 1 6: 1 7: 5 and skb_pp_cow_data() returning heads that were aligned on entry: head 0xffff8f4c86aeac00 -> 0xffff8f4c53a9a9c4 (&7=4) head 0xffff8f4d6a8a42c0 -> 0xffff8f4c4f7b7a45 (&7=5) Round the fragment size up to at least the alignment struct skb_shared_info requires, so fragments are always suitably aligned for the objects callers build on them. Architectures needing a larger DMA alignment keep it. This also makes the remainder computed in page_pool_alloc_netmem(), *size = max_size - *offset; aligned, since max_size is a power of two -- which fixes the matching misalignment of skb->end. Verified with a controlled A/B under QEMU/KVM: same tree, same config, same compiler, same rootfs and identical traffic, differing only by this patch. A SEC("xdp.frags") XDP_PASS program on lo plus UDP datagrams larger than max_head_size drives skb_pp_cow_data()'s fragment loop, which passes raw packet lengths to the pool. Measured at the return of skb_pp_cow_data(): unpatched patched skb_pp_cow_data calls 40800 40800 misaligned skb->head 1120 0 dataref at line offset >60 80 0 The last row counts the accesses that actually fault: skb_shinfo()->dataref sits at head+end+0x20 and is a 4-byte atomic, so `lock incl` splits a 64-byte cache line only when that address lands at offset 61..63. All 80 occurrences were at offset 61; the panic reported above was at offset 62. Eliminating the misalignment removes every one of them. Same class of bug as commit 3bed3cc4156e ("net: Do not allocate page fragments that are not skb aligned"), which fixed the older netdev_alloc_frag()/napi_alloc_frag() allocators. Fixes: 53e0961da1c7 ("page_pool: add frag page recycling support in page pool") Cc: stable@vger.kernel.org Signed-off-by: Florian Schauer Acked-by: Jesper Dangaard Brouer Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260828060822.2628276-1-florian@schauer.to Signed-off-by: Jakub Kicinski commit 5f8cb07d7a8573753c5d31dc76b51cab8e5e9460 Author: Dinh Nguyen Date: Fri Aug 28 10:31:29 2026 +0800 arm64: dts: socfpga: change access permission from 755 to 644 These files have an incorrect access permission of 755 instead of 644. Change them to the correct access permission of 644. Fixes: 4bc04eb90b7c ("arm64: dts: socfpga: stratix10: Add emmc support") Cc: # v7.1+ Signed-off-by: Dinh Nguyen commit 7b120a771943ffc3cbce787daecdd23eccb0505f Author: Jamal Hadi Salim Date: Tue Aug 25 04:10:52 2026 -0400 selftests: tc-testing: add u32 node ID pool exhaustion test Add a tdc test case that fills the u32 node ID space with 4095 auto-generated handles, then attempts to add a 4096th. On the fixed kernel the 4096th filter is rejected with ENOSPC (exit 2). On the unfixed kernel it silently succeeds with a duplicate handle. The setup pipes the 4095 add commands directly into `tc -b -` inside a single bash -c (matching the existing test id 1234 pattern), avoiding any temp file. Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260825081052.133898-2-jhs@mojatatu.com Signed-off-by: Jakub Kicinski commit d7e7e98d23f42a92d9ab7e36302bd96bd9b33b5f Author: Jamal Hadi Salim Date: Tue Aug 25 04:10:51 2026 -0400 net/sched: cls_u32: fix duplicate handle when node ID pool is exhausted gen_new_kid() falls back to returning max (htid | 0xFFF) when both idr_alloc_u32() ranges are full, instead of reporting an error. u32_change() trusts that value and inserts a new knode with a handle that is already live in the hash table, breaking handle uniqueness within the table's node ID space. The handle was never reserved in ht->handle_idr, so every later error path that does idr_remove(&ht->handle_idr, handle) removes the reservation of a different, live knode, which is then reused — one failed add compounds into further duplicates. The 4095 limit is per (table, bucket) — ht->handle_idr is per hash table and the range is derived from htid (bucketid), so a table with divisor 256 can legitimately hold 256*4095 knodes. The sibling helper gen_new_htid() has the same silent in-band failure: it returns 0 when the tp_c handle pool (1..0x7FF) is full, and u32_init() publishes the root hash table with handle 0 without checking. Two root tables with handle 0 alias in u32_lookup_ht(), allowing cross-tcf_proto knode add/lookup/delete. Add the same exhaustion check that the divisor path already has. Return an error so u32_change() fails with ENOSPC/ENOMEM when the node ID space is exhausted, and so u32_init() fails with -ENOMEM when the hash table ID space is exhausted. The extack message distinguishes pool exhaustion (-ENOSPC) from a transient allocation failure (-ENOMEM). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_CLS_U32=y (or =m with module loaded) - Create a clsact qdisc on a device, then add 4095 u32 filters with auto-generated handles to fill the node ID space for the root hash table (single bucket). The 4096th auto-handle filter add triggers the duplicate handle (fh 800::fff reused). Reachable at Level 2 (unshare -Urn, namespace-local CAP_NET_ADMIN). - For gen_new_htid: create 2047 u32 proto entries on the same block to fill the tp_c handle pool, then create one more. The root table gets handle 0 and aliases with other handle-0 root tables. Fixes: 7801db8aec95 ("net_sched: avoid generating same handle for u32 filters") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260825081052.133898-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski commit f05f0d85cd025aa87fede7577f69f23d2536f294 Merge: fa5acd038ea657 3cc2aa96b97184 Author: Jakub Kicinski Date: Mon Aug 31 16:03:22 2026 -0700 Merge branch 'fix-to-possible-skb-leak-due-to-race-condtion-in-tx-path' Selvamani Rajagopal says: ==================== Fix to possible skb leak due to race condtion in tx path Now the traffic is handled in threaded IRQ, and the disable_traffic flag is checked before handling the data, new race condition is exposed, in which buffer may leak, if threaded IRQ interrupts the trasmit path midway. With this change, disable_traffic and waiting_tx_skb pointer are protected by spin lock/unlock pair. This is highlighted in Sashiko review https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260611-level-trigger-v5-0-4533a9e85ce2%40onsemi.com Also on buffer overrun condition, probably due to loss of SPI data chunks, receive path doesn't see the expected data chunk with end_valid bit set. As a result, driver keeps adding data chunks to the skb before running out of space and kernel panic is seen. With this change, before adding data to the skb, if there is no space, skb is freed and driver starts looking for new frame by looking for a data chunk with start_valid bit set. [ 705.405490] skbuff: skb_over_panic: text:ffffffd2eb72a264 len:1600 put:64 head:ffffff804e5cdc40 data:ffffff804e5cdc80 tail:0x680 end:0x640 dev:eth1 [ 705.405569] ------------[ cut here ]------------ [ 705.405575] kernel BUG at net/core/skbuff.c:214! [ 705.405589] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 6703.427690] Call trace: [ 705.925157] skb_panic+0x58/0x68 (P) [ 705.928726] skb_put+0x74/0x80 [ 705.931772] oa_tc6_update_rx_skb+0x44/0x98 [oa_tc6_mod] [ 705.937084] oa_tc6_macphy_threaded_irq+0x3f4/0x900 [oa_tc6_mod] [ 705.943084] irq_thread_fn+0x34/0xb8 [ 705.946654] irq_thread+0x1a0/0x300 [ 705.950134] kthread+0x138/0x150 [ 705.953356] ret_from_fork+0x10/0x20 ==================== Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-0-4323279b18f2@onsemi.com Signed-off-by: Jakub Kicinski commit 3cc2aa96b97184abd6fc106aac626ddf14389813 Author: Selvamani Rajagopal Date: Mon Aug 24 14:58:01 2026 -0700 net: ethernet: oa_tc6: Fix for the wrong data type Inadvertently bool data type is used where int is supposed to be used. This might turn a negative error code into true or false and sign of the return code would be lost. Fixes: 8f9bf857e43b ("net: ethernet: oa_tc6: implement internal PHY initialization") Signed-off-by: Selvamani Rajagopal Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-4-4323279b18f2@onsemi.com Signed-off-by: Jakub Kicinski commit 349c366365876b7f67120827a0deb44899f59303 Author: Selvamani Rajagopal Date: Mon Aug 24 14:58:00 2026 -0700 net: ethernet: oa_tc6: Disable tx queues on fatal error Previously, TX queue interface was stopped when disable_traffic flag was set, which would indicate fatal error. It is more appropriate to disable the queue as, unless driver is unloaded and reloaded, there is no recovery after disable_traffic is set. Queues may be re-enabled inadvertently by other layers. Intention of disable_traffic is only to stop the traffic from flowing on fatal error. Fixes: b542d13fab0f ("net: ethernet: oa_tc6: Interrupt is active low, level triggered.") Signed-off-by: Selvamani Rajagopal Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-3-4323279b18f2@onsemi.com Signed-off-by: Jakub Kicinski commit 172c974113bffe5723b80b1acac17593bb50513c Author: Selvamani Rajagopal Date: Mon Aug 24 14:57:59 2026 -0700 net: ethernet: oa_tc6: Improve the error recovery When oversubscribed traffic causes lot of buffer overflow errors, probably due to loss of data chunks, driver fails to find a data chunk with end_valid bit set, before it runs out of sk buffer space. As a result, assert is seen during skb_put. Now, check is made if skb buffer has enough tailroom for the incoming data before accepting. If there is no room, current frame is abandoned and it will start looking for a data chunk with start_valid bit, that is a new frame. SK buffer allocation error is considered as recoverable error. rx_buf_overflow flag is too specific and no longer the only condition this flag is used for. Therefore it is renamed as wait_until_start_valid. This is more appropriate as this flag is used to look for the next data chunk with SV bit set, after failures like buffer overflow, buffer allocation failure, skb pointer validity besides buffer overflow error. Not writing to status0 if it reads 0. Fixes: d70a0d8f2f2d ("net: ethernet: oa_tc6: implement receive path to receive rx ethernet frames") Signed-off-by: Selvamani Rajagopal Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-2-4323279b18f2@onsemi.com Signed-off-by: Jakub Kicinski commit 5443d9c4f55d46634b95432e1e8a40b824019bbb Author: Selvamani Rajagopal Date: Mon Aug 24 14:57:58 2026 -0700 net: ethernet: oa_tc6: Protect skb pointer used by two different kernel instances Threaded IRQ uses waiting_tx_skb. Transmit path also uses this pointer without any mutual exclusion protection. As a result, it might leak skb buffer, particularly if threaded IRQ sets disable_traffic true after start_xmit already checked and found that disable_traffic being false, if they happen to run on different cores. On fatal error, where disable_traffic is set, transmit function drops the packet and return NETDEV_TX_OK. Due to this change, skb_linearize call is moved up to the beginning of the transmit function. Since skb buffer may be freed from different contexts, dev_kfree_skb_any is used to free skb buffer now, replacing one of the kfree_skb call. oa_tc6_exit disables the irq before setting disable_traffic true. Fixes: b542d13fab0f ("net: ethernet: oa_tc6: Interrupt is active low, level triggered.") Signed-off-by: Selvamani Rajagopal Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-1-4323279b18f2@onsemi.com Signed-off-by: Jakub Kicinski commit fa5acd038ea657ad5033713d6916214cbd349151 Author: Bryam Vargas Date: Fri Aug 28 14:07:47 2026 -0500 net/iucv: fix the recvmsg window update iucv_sock_recvmsg() sends the HiperSockets-only AF_IUCV_FLAG_WIN without testing the transport, so on a classic z/VM socket iucv_send_ctrl() sizes the skb through a NULL iucv->hs_dev. SO_MSGLIMIT accepts 1, so msglimit / 2 is zero and one recvmsg() on its own socket is enough for an unprivileged process to take a spurious disconnect. It also calls iucv_send_ctrl() under spin_lock_bh(&message_q.lock), which allocates GFP_KERNEL inside a section the code treats as atomic. Sending outside that lock lets two recvmsg() reach afiucv_hs_send() at once, where msg_recv is sampled for the advertised window and subtracted after dev_queue_xmit() -- and sendmsg reaches that counter under lock_sock() while recvmsg holds no socket lock, so both can subtract the same value, the counter goes negative and the credit reaches the peer twice. Test the transport, claim the credit with atomic_xchg() after the last error exit and hand it back if the transmit fails, and send once the lock is dropped. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Fixes: 238965b71b96 ("net/af_iucv: build proper skbs for HiperTransport") Cc: stable@vger.kernel.org Tested-by: Aswin Karuvally Signed-off-by: Bryam Vargas Reviewed-by: Alexandra Winter Link: https://patch.msgid.link/20260828-b4-disp-33fac0ed-v3-1-e6d061880ee0@proton.me Signed-off-by: Jakub Kicinski commit ca12149896ed040dafef92eacd2af3f903afb177 Author: Rudi Heitbaum Date: Mon Aug 24 02:27:29 2026 +0000 regulator: dt-bindings: fan53555: add tcs,tcs4526 The driver has accepted tcs,tcs4526 since commit 5eee5eced95f ("regulator: fan53555: add tcs4526"), which added the compatible to both the of_device_id and i2c_device_id tables for the TCS4526, a chip that reports id 0 rather than the TCS4525's id 12. The binding was converted to DT schema afterwards, in commit 6cea468b680e ("regulator: dt-bindings: Convert Fairchild FAN53555 to DT schema"), and only picked up tcs,tcs4525. No in-tree DTS used the 4526 string at the time, so nothing flagged the omission. RK3399Pro boards use the TCS4526 for vdd_gpu and vdd_cpu_b, so a DTS describing them fails dtbs_check today even though the driver binds correctly. Add the missing compatible. Signed-off-by: Rudi Heitbaum Acked-by: Conor Dooley Link: https://patch.msgid.link/aousEdwMni9ScZBn@0d3a7a881997 Signed-off-by: Mark Brown commit 8eae39cd0adf28ba81a46090b10484cf402c0ac8 Author: Arvind Yadav Date: Tue Jul 28 14:33:04 2026 +0530 drm/pagemap: Reset migration page count on eviction retry drm_pagemap_evict_to_ram() may retry eviction, but mpages retains the count from the previous attempt. A retry can therefore continue to the copy path even when no RAM pages were populated. Reset mpages at the retry label so it reflects only the current attempt. Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Cc: Matthew Brost Cc: Thomas Hellström Cc: Himal Prasad Ghimiray Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Signed-off-by: Arvind Yadav Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260728090304.1264759-1-arvind.yadav@intel.com commit c4126f1db36e6b2e1c79b0e30a8a2de91c568f4c Author: Arvind Yadav Date: Mon Aug 10 14:58:45 2026 +0530 drm/pagemap: Prevent double migration of device pages A device-private folio migrated to system memory by a CPU fault can remain reachable through the raw-PFN eviction path until migration finalization drops the source reference. If eviction selects the same device-private folio during this window, it can attempt to migrate the folio again. The second migration can leave an uncharged folio on an LRU list, causing folio_lruvec_lock_irqsave() to retry indefinitely and resulting in a soft lockup and RCU stall. Mark successfully migrated device-private folios using a low bit of their zone_device_data before migration finalization. Make both CPU-fault and raw-PFN migration paths skip device-private folios carrying this flag. Mask the flag when retrieving the drm_pagemap_zdd pointer and preserve it when a device-private folio is split. Keeping the state on the physical folio also avoids depending on a virtual address that may change before a fault occurs. v2: - Replace the retired-PFN XArray with an embedded bitmap. (Matthew Brost) - Mark every base page covered by a migrated folio so retirement remains valid if the folio is later split. v3: - Store the migrated state in a low bit of zone_device_data instead of adding virtual-range and bitmap tracking to the ZDD. (Matthew Brost) - Mask the flag when retrieving the ZDD and preserve it when splitting a folio. - Drop the pre-existing fixes already covered by Matthew Brost's series: https://patchwork.freedesktop.org/series/171651/ v4: - Advance by the folio size only for migration entries marked with MIGRATE_PFN_COMPOUND. (Sashiko) v5: - Simplify ZDD flag updates and folio iteration. (Matthew Brost) - Skip retired device-private folios in the CPU-fault path. (Matthew Brost) - Preserve flag bits while taking a new ZDD reference for split folios. v6: - Restore MIGRATE_PFN_COMPOUND-aware stepping so non-compound migration entries are processed one at a time. (Sashiko) - Drop the pre-existing fixes already covered by Matthew Brost's series: https://patchwork.freedesktop.org/series/171651/ The lockup was observed as: [10109.860465] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [kworker/u65:5:6557] [10109.860524] Tainted: [S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE [10109.860524] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 [10109.860525] Workqueue: xe_page_fault_work_queue xe_pagefault_queue_work [xe] [10109.860644] RIP: 0010:_raw_spin_unlock_irqrestore+0x57/0x80 [10109.860655] Call Trace: [10109.860655] [10109.860657] folio_lruvec_lock_irqsave+0x216/0x220 [10109.860661] ? __pfx_lru_add+0x10/0x10 [10109.860665] folio_batch_move_lru+0xc8/0x450 [10109.860670] ? lock_acquire+0xc4/0x2d0 [10109.860674] ? __folio_batch_add_and_move+0x60/0x2e0 [10109.860677] ? folio_migrate_mapping+0xa6/0x110 [10109.860679] ? folio_migrate_flags+0x13b/0x1b0 [10109.860681] ? __pfx_lru_add+0x10/0x10 [10109.860683] __folio_batch_add_and_move+0xe7/0x2e0 [10109.860685] ? dma_iova_try_alloc+0xb0/0x140 [10109.860689] folio_add_lru+0x64/0x80 [10109.860691] __migrate_device_finalize+0x12c/0x270 [10109.860695] migrate_device_finalize+0x10/0x20 [10109.860698] drm_pagemap_evict_to_ram+0x185/0x370 [drm_gpusvm_helper] [10109.860704] ? drm_pagemap_evict_to_ram+0x96/0x370 [drm_gpusvm_helper] [10109.860709] xe_svm_bo_evict+0x15/0x20 [xe] [10109.860819] ? xe_svm_bo_evict+0x15/0x20 [xe] [10109.860921] xe_bo_move+0x107e/0x1570 [xe] [10109.860992] ? xe_ttm_tt_create+0x168/0x340 [xe] [10109.861059] ? __up_read+0x98/0x2b0 [10109.861061] ? lock_is_held_type+0xa3/0x130 [10109.861067] ttm_bo_handle_move_mem+0xe8/0x1e0 [ttm] [10109.861075] ttm_bo_evict+0x141/0x1c0 [ttm] [10109.861081] ttm_bo_evict_cb+0x9f/0x100 [ttm] [10109.861086] ttm_lru_walk_for_evict+0x84/0x190 [ttm] [10109.861091] ? xe_ttm_vram_mgr_new+0x258/0x3a0 [xe] [10109.861198] ttm_bo_alloc_resource+0x219/0x750 [ttm] [10109.861203] ? ttm_bo_alloc_resource+0xa9/0x750 [ttm] [10109.861208] ? lock_acquire+0xc4/0x2d0 [10109.861214] ttm_bo_validate+0x94/0x1c0 [ttm] [10109.861218] ? ww_mutex_trylock+0x19d/0x3d0 [10109.861219] ? _raw_write_unlock+0x22/0x50 [10109.861223] ttm_bo_init_reserved+0x17d/0x1f0 [ttm] [10109.861228] xe_bo_init_locked+0x20a/0x620 [xe] [10109.861294] ? __pfx_xe_ttm_bo_destroy+0x10/0x10 [xe] [10109.861359] ? mark_held_locks+0x46/0x90 [10109.861361] ? __create_object+0x68/0xc0 [10109.861366] __xe_bo_create_locked+0x384/0xa20 [xe] [10109.861432] ? lock_acquire+0xc4/0x2d0 [10109.861434] ? xe_drm_pagemap_populate_mm+0xd3/0x340 [xe] [10109.861542] xe_bo_create_locked+0x23/0x40 [xe] [10109.861609] xe_drm_pagemap_populate_mm+0x12e/0x340 [xe] [10109.861707] ? __lock_acquire+0x43e/0x2930 [10109.861716] drm_pagemap_populate_mm+0x74/0xe0 [drm_gpusvm_helper] [10109.861720] xe_svm_alloc_vram+0xb5/0x2c0 [xe] [10109.861817] ? seqcount_lockdep_reader_access.constprop.0+0x9f/0xc0 [10109.861819] ? ktime_get+0x23/0x130 [10109.861821] ? trace_hardirqs_on+0x22/0xe0 [10109.861823] ? seqcount_lockdep_reader_access.constprop.0+0x9f/0xc0 [10109.861826] __xe_svm_handle_pagefault+0x77d/0xbf0 [xe] [10109.861924] ? rwsem_down_write_slowpath+0x43a/0x9a0 [10109.861926] ? _raw_spin_unlock_irq+0x27/0x70 [10109.861928] ? rwsem_down_write_slowpath+0x43a/0x9a0 [10109.861929] ? trace_hardirqs_on+0x22/0xe0 [10109.861931] ? _raw_spin_unlock_irq+0x27/0x70 [10109.861933] ? rwsem_down_write_slowpath+0x459/0x9a0 [10109.861937] xe_svm_handle_pagefault+0x3d/0xb0 [xe] [10109.862030] xe_pagefault_queue_work+0x1a9/0x520 [xe] [10109.862122] process_one_work+0x239/0x730 [10109.862127] worker_thread+0x200/0x3f0 [10109.862130] ? __pfx_worker_thread+0x10/0x10 [10109.862132] kthread+0x10d/0x150 [10109.862133] ? __pfx_kthread+0x10/0x10 [10109.862135] ret_from_fork+0x3bd/0x470 [10109.862138] ? __pfx_kthread+0x10/0x10 [10109.862140] ret_from_fork_asm+0x1a/0x30 [10109.862146] Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Matthew Brost Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Cc: Thomas Hellström Cc: Himal Prasad Ghimiray Assisted-by: Claude:claude-opus-4-8 Suggested-by: Matthew Brost Signed-off-by: Arvind Yadav Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260810092845.2776097-1-arvind.yadav@intel.com commit 93d88ac4a448f200d18d1d71de0074b8e716bbee Author: Tao Cui Date: Tue Aug 25 10:35:56 2026 +0800 sched_ext: Pass the initial cpu.idle state in scx_cgroup_init_args scx_cgroup_init_args carries the initial weight and bandwidth control parameters of a cgroup to ops.cgroup_init(), but not its cpu.idle state. A cgroup that was already configured idle before the scheduler was loaded (or before it was onlined under it) is presented as non-idle, and the BPF scheduler only learns about it if cpu.idle is written again later. Add the sched_idle state to scx_cgroup_init_args and fill it in all four places that build the args: scx_tg_online() for cgroups onlined under the scheduler, scx_cgroup_init() for cgroups that already exist when the scheduler is loaded, and the sub-scheduler handover paths scx_cgroup_claim_subtree() and scx_cgroup_return_subtree(). Verified in a VM with a probe scheduler printing the init args: a cgroup configured cpu.idle=1 before loading shows sched_idle=1 in ops.cgroup_init(), the default shows 0, and later cpu.idle writes still come through ops.cgroup_set_idle(). The sub-scheduler paths are compile-tested only. Fixes: 347ed2d566da ("sched/ext: Implement cgroup_set_idle() callback") Signed-off-by: Tao Cui Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo commit 7a4ce92d150b9e7ecf1a710a34d8cdeb590d3751 Author: Tianchu Chen Date: Mon Aug 31 15:13:36 2026 +0000 ASoC: sprd: validate compress buffer sizes against fixed allocations sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: cce1396936ef ("ASoC: sprd: Add Spreadtrum audio compress offload support") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/4386bc53631b052c1866a91061715b009d98b04f@linux.dev Signed-off-by: Mark Brown commit abdf623ddb75b24659018d3952d8f61937306ae5 Merge: c3b510de420d70 93e257938aa67a Author: Linus Torvalds Date: Mon Aug 31 14:38:40 2026 -0700 Merge tag 'wq-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq Pull workqueue fixes from Tejun Heo: - An unbound worker pool could be freed while still reachable through the pending-activation list, leading to a use-after-free. Unlink before dropping the reference - On PREEMPT_RT, the BH workqueue kick raised softirqs from preemptible context, tripping a lockdep assertion and possibly losing concurrently raised softirq bits - Draining BH work off a dead CPU nests two pools' callback locks, which lockdep misreported as recursive locking. The nesting cannot deadlock. Annotate it - Reject watchdog thresholds that overflow the conversion to jiffies - Make the drgn workqueue dump script work again on kernels and vmcores from before the workqueue attrs field rename * tag 'wq-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: tools/workqueue/wq_dump.py: Support backward compatibility for wq->attrs rename workqueue: reject watchdog thresholds that overflow jiffies workqueue: Fix unbound pool lifetime for pending pwqs workqueue: Use raise_softirq() to trigger softirq in irq_work handler workqueue: Annotate cb_lock nesting when draining a dead BH pool commit c3b510de420d70def08190083d388e0873c1aa84 Merge: bf1079577a116f 3f4b7d1a49c5c8 Author: Linus Torvalds Date: Mon Aug 31 14:20:32 2026 -0700 Merge tag 'cgroup-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: - After cgroup.kill was written to a cgroup, every child cloned into it with CLONE_INTO_CGROUP was spuriously killed because the fork path snapshotted the kill counter before resolving the target cgroup - Releasing an isolated cpuset partition dropped the isolation of CPUs isolated on the kernel command line - Selftest and documentation fixes * tag 'cgroup-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: selftests/cgroup: test clone3() into a previously killed cgroup cgroup: fix spurious SIGKILL of CLONE_INTO_CGROUP children selftests/cgroup: Add test for preserving boot-isolated CPUs cgroup/cpuset: Preserve boot-isolated CPUs on partition release selftests/cgroup: Drop invalid boot isolation comparison docs: cgroup-v2: fix misc.events key format description selftests/cgroup: Fix cg_run_in_subcgroups ignoring arg parameter selftests/cgroup: set the test plan after the setup checks commit 05bbe220993f6d9f85fa831ea2fe6b607fbc529e Merge: fbf2c660bac863 711178754287db Author: Mark Brown Date: Mon Aug 31 22:14:51 2026 +0100 ASoC: ab8500: Fix codec reset, routing and DAI setup Linus Walleij says: Repair independent correctness problems in the AB8500 codec driver: reset sequencing, AB8505 digital microphone GPIO setup, the capture power graph, serial format setup, and TDM slot programming. Remove the sidetone apply control which became destructive when its coefficient controls were removed. Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-0-f85024e717e3@kernel.org commit 711178754287db3fd0f7accff3c2a7575f8873b7 Author: Linus Walleij Date: Mon Aug 31 22:29:11 2026 +0200 ASoC: ab8500: Skip missing DMIC GPIOs on AB8505 GPIO27, GPIO29 and GPIO31 provide the digital microphone clock outputs on AB8500, but these GPIOs do not exist on AB8505. The shared codec driver nevertheless accesses their direction register while setting up every AB8505 codec. Identify the parent MFD device and leave the nonexistent GPIOs untouched on AB8505. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-6-f85024e717e3@kernel.org Signed-off-by: Mark Brown commit ec75e653b70ce26ea68187c2069722baa80efadb Author: Linus Walleij Date: Mon Aug 31 22:29:10 2026 +0200 ASoC: ab8500: Remove the nonfunctional sidetone apply control After the coefficient controls were removed, writing "Apply FIR" programs 128 zero coefficients and reports that the sidetone filter is configured. The associated ANC configuration DAPM pins are also now unreachable dead infrastructure. Remove the misleading status/apply control, its private state, and the obsolete configuration-only DAPM pins. Keep the direct sidetone reset and remaining hardware controls. Fixes: e366ce8b22ec ("ASoC: codecs: ab8500: Remove suspicious code") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-5-f85024e717e3@kernel.org Signed-off-by: Mark Brown commit 85cef7e2004ef5c1a715feaddb55d3f3d27bac0a Author: Linus Walleij Date: Mon Aug 31 22:29:09 2026 +0200 ASoC: ab8500: Validate and program TDM slots correctly The interface clock ratio is selected from the slot count alone, ffs() and fls() produce one-based hardware slot numbers, eight-channel mode does not program any mappings, and all register errors are ignored. Invalid masks can also leave a partially programmed interface. Validate the complete configuration first, derive the supported BCLK ratio from slots times slot width, use zero-based slot indices, program deterministic eight-channel maps, and propagate register failures. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-4-f85024e717e3@kernel.org Signed-off-by: Mark Brown commit f98785adf004db6b1c9f4cea9dadae7b800db72f Author: Linus Walleij Date: Mon Aug 31 22:29:08 2026 +0200 ASoC: ab8500: Correct digital interface format setup The codec programs I2S as an undelayed left-aligned format, although the hardware manual defines delayed left-aligned as I2S compatible. It also enables the master generator when the codec is a clock consumer, changes registers before the complete format has been validated, and discards register I/O errors. Build all three interface register values before writing them, use the required one-bit I2S delay, only run the master generator for a provider configuration, and propagate write failures. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-3-f85024e717e3@kernel.org Signed-off-by: Mark Brown commit 103fe1a37f040ef6ac9ed1cf33be786149d2bb15 Author: Linus Walleij Date: Mon Aug 31 22:29:07 2026 +0200 ASoC: ab8500: Repair the DAPM capture graph The capture stream routes point away from the stream widget. Digital microphone mux routes are unconditional and bypass their enable bits, and several widgets independently own shared AD path enable bits. The dummy ADC and DAC widgets hide the resulting power graph errors. Connect each real AIF widget to the stream and main supply, use the mux item names on digital microphone routes, and model shared AD enables as supplies. Also make the ANC DAPM switch writable. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-2-f85024e717e3@kernel.org Signed-off-by: Mark Brown commit 8e839bca7793a0b03c005f4b2b0825464290d425 Author: Linus Walleij Date: Mon Aug 31 22:29:06 2026 +0200 ASoC: ab8500: Reset the audio block before configuring it ResetAudn is active low, but the codec probe only deasserts it. It also clears Clk32kOut2Dis despite claiming to disable that output, and writes codec registers before releasing reset. Pulse ResetAudn before the first audio-bank access and leave the unused 32 kHz output disabled. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260831-ab8500-codec-fixes-v1-1-f85024e717e3@kernel.org Signed-off-by: Mark Brown commit 93e257938aa67a6c957217db94091d9d9e5d403f Author: Aaron Tomlin Date: Mon Aug 31 14:15:53 2026 -0400 tools/workqueue/wq_dump.py: Support backward compatibility for wq->attrs rename Commit 464e454e1cb4 ("workqueue: rename wq->unbound_attrs to wq->attrs") renamed wq->unbound_attrs to wq->attrs. When running wq_dump.py against older running kernels or vmcores where struct workqueue_struct still contains unbound_attrs, drgn raises an AttributeError. Add a wq_attrs() helper to allow wq_dump.py to inspect both older and newer kernel versions seamlessly. Fixes: 464e454e1cb4 ("workqueue: rename wq->unbound_attrs to wq->attrs") Signed-off-by: Aaron Tomlin Signed-off-by: Tejun Heo commit bf1079577a116f0685e7025b9ee2547345ee1c63 Merge: a7f25dc23ff6d2 068e5a0bc57e57 Author: Linus Torvalds Date: Mon Aug 31 13:13:35 2026 -0700 Merge tag 'sched_ext-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext Pull sched_ext fixes from Tejun Heo: - The task ownership check in the dispatch queue move operation raced against the task exiting or moving to a different sub-scheduler, spuriously triggering scheduler aborts. Fix by moving the check under the queue lock - The cgroup bandwidth change callback runs in a sleepable context but sleepable implementations were rejected at load time. Allow them and add a marker so userspace can detect the capability - Sync tooling headers with the scx repo for accumulated compatibility improvements - Example scheduler fixes: ignored timer re-arm failures and vtime credit loss on cgroup migration - Documentation and comment fixes * tag 'sched_ext-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: Fix missing @slice and @vtime descriptions in finish_dispatch() kernel-doc sched_ext: Fix several comment issues sched_ext: Check bpf_timer_start return values in scx_qmap sched_ext: Fix vtime delta loss in scx_flatcg cgroup migration sched_ext: Fix timer pinning and return value in scx_central docs/sched_ext: document that cgroup CPU knobs are scheduler-dependent sched_ext: Fix spurious aborts in scx_bpf_dsq_move() on ownership change races sched_ext: Sync common and compat headers from the scx repo sched_ext: Sync tools autogen enum headers from the scx repo Docs/admin-guide/cgroup-v2: document BPF scheduler callbacks for cpu.max and cpu.idle sched_ext: Fix nonexistent field in sched-ext.rst example sched_ext: Allow ops.cgroup_set_bandwidth() to be sleepable commit 55981579b27b6541aeeab81c768f248dba0491ac Author: Taniya Das Date: Sat Aug 1 23:01:18 2026 +0530 clk: qcom: gpucc-kaanapali: Mark the GPU CX GDSC as votable The GPU CX GDSC on Kaanapali is a votable power domain and hence should not be polled for power-off status during GDSC disable. Also, its power-on status should be read from the GDS hardware control register. Accommodate this by removing POLL_CFG_GDSCR and adding the VOTABLE flag for the GPU CX GDSC, similar to other platforms (e.g. SM8750 and Milos). Fixes: 685ec348339b ("clk: qcom: Add support for GPUCC and GXCLK for Kaanapali") Signed-off-by: Taniya Das Reviewed-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20260801-kaanapali-gpu-voteable-v1-2-fe804d24d2e9@oss.qualcomm.com Signed-off-by: Bjorn Andersson commit 8f3f88309fa4e975ac27368ee945c2c202251a7c Author: Taniya Das Date: Sat Aug 1 23:01:17 2026 +0530 clk: qcom: gpucc-glymur: Mark the GPU CX GDSC as votable The GPU CX GDSC on Glymur is a votable power domain and hence should not be polled for power-off status during GDSC disable. Also, its power-on status should be read from the GDS hardware control register. Accommodate this by removing POLL_CFG_GDSCR and adding the VOTABLE flag for the GPU CX GDSC, similar to other platforms (e.g. SM8750 and Milos). Fixes: 67e645285dd0 ("clk: qcom: Add support for GPUCC and GXCLK for Glymur") Signed-off-by: Taniya Das Reviewed-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20260801-kaanapali-gpu-voteable-v1-1-fe804d24d2e9@oss.qualcomm.com Signed-off-by: Bjorn Andersson commit 0bfb542fc3368371cefb4cf45ef21c3ba2d37c3f Author: Luca Weiss Date: Fri Aug 7 09:46:06 2026 +0200 clk: qcom: gcc-kaanapali: Fix always-enabling PCIE_RSCC clocks The critical_cbrcrs array will get qcom_branch_set_clk_en() called on each entry which will set BIT(0) to enable the clock. This is however wrong for these two PCIE_RSCC clocks which need BIT(20) and BIT(21) set respectively to enable them. Fixes: d1919c375f21 ("clk: qcom: Add support for Global clock controller on Kaanapali") Signed-off-by: Luca Weiss Link: https://lore.kernel.org/r/20260807-various-pcie-clk-fix-v1-3-5caf78a599d7@fairphone.com Signed-off-by: Bjorn Andersson commit 62bbf7ed9ad97c17377377aae50b7ea7feb9464e Author: Luca Weiss Date: Fri Aug 7 09:46:05 2026 +0200 clk: qcom: gcc-hawi: Fix always-enabling PCIE_RSCC clocks The critical_cbrcrs array will get qcom_branch_set_clk_en() called on each entry which will set BIT(0) to enable the clock. This is however wrong for these two PCIE_RSCC clocks which need BIT(20) and BIT(21) set respectively to enable them. Fixes: 67121dad6cba ("clk: qcom: Add support for global clock controller on Hawi") Signed-off-by: Luca Weiss Link: https://lore.kernel.org/r/20260807-various-pcie-clk-fix-v1-2-5caf78a599d7@fairphone.com Signed-off-by: Bjorn Andersson commit 5ffd02d16f4e2f0566b8f31d5610538987e1944c Author: Luca Weiss Date: Fri Aug 7 09:46:04 2026 +0200 clk: qcom: gcc-eliza: Fix always-enabling PCIE_RSCC clocks The critical_cbrcrs array will get qcom_branch_set_clk_en() called on each entry which will set BIT(0) to enable the clock. This is however wrong for these two PCIE_RSCC clocks which need BIT(20) and BIT(21) set respectively to enable them. Fixes: 3d356ab4a1ec ("clk: qcom: Add support for Global clock controller on Eliza") Signed-off-by: Luca Weiss Tested-by: Abel Vesa Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260807-various-pcie-clk-fix-v1-1-5caf78a599d7@fairphone.com Signed-off-by: Bjorn Andersson commit d83b7502bb087fa54daf0fdd419d2910c34bc97d Author: Antonio Borneo Date: Mon Aug 31 17:36:46 2026 +0200 MAINTAINERS: Update URI for watchdog tree The old git repository git://www.linux-watchdog.org/linux-watchdog.git is not accessible anymore, while the development of the watchdog framework is currently handled in git.kernel.org by Guenter's linux-staging repository. Update the URI. Signed-off-by: Antonio Borneo Link: https://patch.msgid.link/20260831153646.396038-1-antonio.borneo@foss.st.com Signed-off-by: Guenter Roeck commit 9ffed84a24d60ec506d8961fe138f0baa92fdbd0 Author: Pedro Falcato Date: Mon Aug 31 12:43:46 2026 +0100 platform/x86/amd/pmf: fix build on !CONFIG_AMD_PMF_DEBUG amd_pmf_get_ta_custom_bios_inputs() is used by non-debug features. Fix the build on !CONFIG_AMD_PMF_DEBUG by moving amd_pmf_get_ta_custom_bios_inputs() outside the ifdef CONFIG_AMD_PMF_DEBUG. Fixes: 5bda82c797c9 ("platform/x86/amd/pmf: Implement util layer ioctl handler") Reported-by: Oleksandr Natalenko Link: https://lore.kernel.org/all/fS7s9V_xTaedaqEAaxwKnQ@natalenko.name/ Signed-off-by: Pedro Falcato Reviewed-by: Mario Limonciello (AMD) > --- Tested-by: Oleksandr Natalenko Link: https://patch.msgid.link/20260831114346.2041361-1-pfalcato@suse.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 6bb4fb72c00dc2a9cb663e2d16adce15e4170cdf Author: Armin Wolf Date: Mon Aug 31 01:50:58 2026 +0200 platform/x86: asus-laptop: Fix ACPI event handling The event codes inside asus_keymap[] span a wide range from 0x02 till 0xC5, but using ACPI_DEVICE_NOTIFY prevents us from receiving event codes below 0x80. Fix this by using ACPI_ALL_NOTIFY instead. Fixes: 378500dc1313 ("platform/x86: asus-laptop: Register ACPI notify handler directly") Reported-by: Mo Jun Closes: https://bugs.debian.org/1146124 Tested-by: Mo Jun Signed-off-by: Armin Wolf Reviewed-by: Rafael J. Wysocki Link: https://patch.msgid.link/20260830235058.324140-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit ee02ed6308fbbd851c4e5c1f642d029617049a12 Author: Arda Doğu Ari Date: Fri Aug 28 02:51:39 2026 +0300 platform/x86: hp-wmi: Fix board_params typo for 8DD6 board When adding support for board 8DD6, &omen_v1_no_ec_thermal_params was passed as driver_data instead of &omen_v1_no_ec_board_params. Because active_board_params expects a pointer to struct hp_wmi_board_params, dereferencing active_board_params->thermal_profile results in a type confusion bug and invalid memory access. Update the entry to point to omen_v1_no_ec_board_params. Fixes: a7320d6eb9c42 ("platform/x86: hp-wmi: Add support for OMEN MAX 16-ak0xxx (8DD6)") Cc: stable@vger.kernel.org Signed-off-by: Arda Doğu Ari Reviewed-by: Krishna Chomal Link: https://patch.msgid.link/20260827235139.154462-1-arfeliousheres@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen commit 77d499e61d36e883a6ad1f10afe05f556aa7e0cc Author: Paul Moore Date: Fri Aug 14 16:35:18 2026 -0400 selinux: fix BPF token permission checks Avoid multiple lookups of the bpffs creator SID using the token's file descriptor when the same information can be found via the resolved path/dentry (in selinux_bpf_token_create()) or the token itself (in selinux_bpf_map_create() and selinux_bpf_prog_load()). Not only does this simplify the code, it avoids potential TOCTOU issues if the user changes the token file descriptor passed into the kernel. Cc: stable@vger.kernel.org Fixes: 5473a722f782 ("selinux: add support for BPF token access control") Reviewed-by: Stephen Smalley Tested-by: Stephen Smalley Signed-off-by: Paul Moore commit 2deb76c21b81e42b3282224f7dd2046fe73fd1e0 Author: Gongwei Li Date: Tue Aug 25 10:01:45 2026 +0800 Bluetooth: hci_mrvl: Fix wrong return value check of wait_on_bit_timeout() wait_on_bit_timeout() returns 0 if the bit was cleared, -EINTR if the process received a signal and the mode permitted wake up on that signal, or -EAGAIN if the timeout elapsed. It never returns 1. Hence the check "err == 1" in mrvl_load_firmware() is dead code: when the waiting task is interrupted by a signal (-EINTR), the code falls into the "else if (err)" branch and misreports it as "Firmware request timeout" with -ETIMEDOUT instead of propagating -EINTR. Fix this by testing for -EINTR so that an interrupted firmware load is properly detected and reported. Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support") Signed-off-by: Gongwei Li Signed-off-by: Luiz Augusto von Dentz commit 0d77683237270702fa93489ca759c89b4e970554 Author: Pauli Virtanen Date: Sun Aug 30 15:04:02 2026 +0300 Bluetooth: L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM l2cap_ecred_defer_connect() clears FLAG_DEFER_SETUP also for channels with different PID/PSM, which will not be added to the same ECRED_CONN_REQ in any case. Consequently, only one ECRED connection group can work at a time although it appears intended they would be separate for each PID/PSM combination. Fix by clearing FLAG_DEFER_SETUP only for the connections that could be added in the request. Retain test_bit(FLAG_DEFER_SETUP) before calling get_peer_pid as it may be NULL otherwise. Fixes: da49b602f7f7 ("Bluetooth: L2CAP: Use DEFER_SETUP to group ECRED connections") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz commit 56c2b5831d39dc84aad2573dc3e197af1a872a05 Author: Pauli Virtanen Date: Sun Aug 30 15:04:01 2026 +0300 Bluetooth: L2CAP: fix out-of-bounds write in l2cap_ecred_connect l2cap_chan_connect() tries to ensure there are no more than L2CAP_ECRED_CONN_SCID_MAX pending ECRED channels, so they fit in the same L2CAP_ECRED_CONN_REQ that l2cap_ecred_connect() constructs. However, the check only counts deferred channels. If 6 L2CAP sockets are connected at the same time in order DDDDND (D=deferred, N=non-deferred), the last can bump the total to max+1. It results to one __le16 written out of bounds of the scid array, and an invalid ECRED_CONN_REQ being sent. Fix by leaving room for the non-deferred pending ECRED channels in the counting in l2cap_chan_connect(), so the limit can't be exceeded. Move counting under same critical section where the channel is added. Although race conditions involving this appear unreachable, it's easier to see. Also add WARN_ON_ONCE check in l2cap_ecred_defer_connect() to make this less brittle. Fixes: da49b602f7f7 ("Bluetooth: L2CAP: Use DEFER_SETUP to group ECRED connections") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz commit 4ef05db5b08b176a551b4a6287372045998806b0 Author: Pauli Virtanen Date: Sun Aug 30 20:11:36 2026 +0300 Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect. It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident. Fix by setting chan->mode correctly in l2cap_le_connect_req(). Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle. Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz commit 57938bbdb9bf7fd41cbd5cd509ec10c4b22bec18 Author: Aleksandr Nogikh Date: Fri Aug 28 08:55:09 2026 +0000 Bluetooth: hci_core: Fix race condition during device registration In hci_register_dev(), the power_on work item is queued to hdev->req_workqueue before initializing hdev->adv_monitors_idr and registering the MSFT extension via msft_register(). For devices marked with quirks such as HCI_QUIRK_RAW_DEVICE, the HCI_UNCONFIGURED flag is set on the device. When the power_on work item runs concurrently on another CPU, hci_power_on() detects that the device is unconfigured and immediately invokes hci_dev_do_close(), which calls msft_do_close(). Concurrently, msft_register() allocates the msft structure and exposes it to hdev->msft_data prior to calling mutex_init(&msft->filter_lock). If msft_do_close() executes while hdev->msft_data is already assigned but the mutex has not yet been initialized, mutex_lock(&msft->filter_lock) operates on an uninitialized mutex, triggering a DEBUG_LOCKS warning: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline] WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821 ... Call Trace: msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline] hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fix this by moving the queue_work() call in hci_register_dev() to after idr_init(&hdev->adv_monitors_idr) and msft_register(hdev) so that device structures and extensions are fully initialized before asynchronous tasks can access them. Additionally, assign hdev->msft_data in msft_register() only after mutex_init(&msft->filter_lock) has completed. Fixes: 9e14606d8f38 ("Bluetooth: msft: Extended monitor tracking by address filter") Assisted-by: Gemini:gemini-3.7-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+14ce1b05b7d5a989abbe@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=14ce1b05b7d5a989abbe Link: https://syzkaller.appspot.com/ai_job?id=2bc9e8aa-ca6d-43e2-be2c-fd5d9f649d7e Signed-off-by: Aleksandr Nogikh Signed-off-by: Luiz Augusto von Dentz commit a7f25dc23ff6d238ed70e8a3a8a3792cde3bcc68 Merge: cee9395acd8043 412f89fb3988a3 Author: Linus Torvalds Date: Mon Aug 31 10:45:40 2026 -0700 Merge tag 'xfs-fixes-7.3-rc2' of gitolite.kernel.org:/pub/scm/fs/xfs/xfs-linux Pull xfs fixes from Carlos Maiolino: "This contains a few fixes for the zoned storage support, a possible deadlock vector fix, some code refactoring patches and a quota evasion fix on XFS while exporting it via NFS. Please note that for the quota evasion fix, a couple patches for the capability subsystem are included in the pull request. Those have been ack'ed by the respective maintainer which also agreed to have them going through the xfs tree. This also includes a patch for the quota subsystem to stop issuing audit messages during quota enforcing. Quota maintainer also ack'ed and agreed with this going through xfs tree" * tag 'xfs-fixes-7.3-rc2' of gitolite.kernel.org:/pub/scm/fs/xfs/xfs-linux: capability: unexport has_capability_noaudit xfs: replace ns_capable_noaudit quota: Don't issue audit messages on quota enforcing capability: Add new capable_noaudit xfs: fix capability check in xfs xfs: restore bi_bdev in xfs_zone_gc_write_chunk xfs: split ioend handling into a separate source file xfs: factor out a xfs_iomap_set_anon_write helper xfs: fix zoned write iomap flags assignments xfs: fix racy open zone caching xfs: handle NULL open_zone for merged ioends in xfs_ioend_put_open_zones xfs: use inode_init_always_gfp with __GFP_NOFAIL in xfs_inode_alloc xfs: remove kmem_to_page() xfs: don't flush and invalidate internal RT device twice in xfs_shutdown_devices xfs: split an assert in xfs_trans_log_buf xfs: don't hold buffer locks across sync transaction commit in xfs_sync_sb_buf commit 3a74624b5deae7f5e2b98e638687fbf9594a9781 Author: Laxman Acharya Padhya Date: Mon Aug 31 15:44:23 2026 +0545 Bluetooth: btintel: propagate version TLV parsing errors btintel_read_version_tlv() ignores the parser return value, so setup continues with partially initialized version data after a malformed TLV causes parsing to stop. Return the parser error to the caller so an invalid response fails setup instead of being treated as successful. Keep this behavioral change separate from the bounds checks so it can be reverted independently if an existing controller sends malformed data. Signed-off-by: Laxman Acharya Padhya Reviewed-by: Ali Ahmet Memis Tested-by: Kiran K Signed-off-by: Luiz Augusto von Dentz commit ac8aa9e0ec93a12a60230066f199f49c3b9aac3d Author: Laxman Acharya Padhya Date: Mon Aug 31 15:44:22 2026 +0545 Bluetooth: btintel: bound firmware ID by TLV length The firmware ID is treated as a NUL-terminated string even though the TLV length is its only boundary. If the value does not contain a NUL terminator, snprintf() can read beyond the received response. Limit the conversion to the advertised TLV value length. Fixes: 164c62f958f8 ("Bluetooth: btintel: Add firmware ID to firmware name") Reviewed-by: Ali Ahmet Memis Signed-off-by: Laxman Acharya Padhya Tested-by: Kiran K Signed-off-by: Luiz Augusto von Dentz commit a086c0892969bf8a0151b0f12bd14a68827c88b2 Author: Laxman Acharya Padhya Date: Mon Aug 31 15:44:21 2026 +0545 Bluetooth: btintel: validate version TLV value lengths btintel_parse_version_tlv() verifies that a complete TLV is present in the response, but it does not ensure that the value is long enough for the specific TLV type. A short value can therefore cause an out-of-bounds read through get_unaligned_le16(), get_unaligned_le32(), or memcpy(). Reject values shorter than the minimum required by each known TLV type. Also reject responses that do not contain the Command Complete Status field. Fixes: 57375beef71a ("Bluetooth: btintel: Add infrastructure to read controller information") Reviewed-by: Ali Ahmet Memis Signed-off-by: Laxman Acharya Padhya Tested-by: Kiran K Signed-off-by: Luiz Augusto von Dentz commit 068c35b5d0546c8625b3d7c61910f73775cf1216 Author: Jiacheng Xu Date: Tue Aug 25 15:03:15 2026 +0800 workqueue: reject watchdog thresholds that overflow jiffies The watchdog threshold is supplied in seconds but is multiplied by HZ before being used as a jiffies interval. Reject values that exceed MAX_JIFFY_OFFSET / HZ so the multiplication cannot wrap and the time_after() comparisons remain within their supported range. The check is performed before changing the threshold or watchdog timer. Zero remains the value used to disable the watchdog. Fixes: 82607adcf9cdf ("workqueue: implement lockup detector") Signed-off-by: Jiacheng Xu Signed-off-by: Tejun Heo commit 068e5a0bc57e57d24cbf38def29cc5fb4db9a0df Author: Liang Luo Date: Tue Aug 25 13:50:53 2026 +0800 sched_ext: Fix missing @slice and @vtime descriptions in finish_dispatch() kernel-doc Commit 13f1eae3b662 ("sched_ext: Synchronize slice and dsq_vtime writes") added the slice and vtime parameters to finish_dispatch() but did not update its kernel-doc, which produces warnings: Warning: function parameter 'slice' not described in 'finish_dispatch' Warning: function parameter 'vtime' not described in 'finish_dispatch' Describe both parameters using the same wording as dispatch_to_local_dsq(), which receives the same values. Signed-off-by: Liang Luo Signed-off-by: Tejun Heo commit ea2ee8b222306208d2b094d1a11894da6c106d42 Author: Kiran K Date: Tue Aug 25 22:53:00 2026 +0530 Bluetooth: btintel_pcie: Clear automask on spurious interrupts On spurious interrupt where the TX and RX causes are not set, driver was not clearing the auto mask which can block all the interrupts. Driver needs to clear the automask even if no causes are set. Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz commit 2fabd2f406d0cf787be47b3bbeea99b30004033d Author: David Oberhollenzer Date: Thu Jul 16 13:39:47 2026 +0200 ARM: dts: ti/omap: dra7: fix PCIe PHY clock divider definition Commit d0bdd8bb7f35 ("ARM: dts: ti/omap: dra7: fix redundant clock divider definition") removes the clock divider definition from optfclk_pciephy_div, reasoning that the table is redundant, as it contains the values 1 and 2, while also setting ti,max-div to 2 while ti,min-div is implicitly initialized to 1. What that commit missed was the fact that the values in the table are in reverse order, i.e. first 2, then 1. As is clearly described in the documentation, the ordering is signifficant, the actual values for the register setting are derived from the index. If no table is specified, the driver assumes that the register value is divider - 1 (see also `_get_val` in `drivers/clk/ti/divider.c`). What is in fact redundant is the value of ti,max-div that is derived from the table if none is specified. To satisfy device tree semantic linters, it is removed instead. Fixes: d0bdd8bb7f35 ("ARM: dts: ti/omap: dra7: fix redundant clock divider definition") Signed-off-by: David Oberhollenzer Link: https://patch.msgid.link/20260716113947.92513-1-david.oberhollenzer@sigma-star.at Signed-off-by: Kevin Hilman (TI) commit 4881a13521886076e8d6d677f274320dcf66fea4 Author: Wanwu Li Date: Thu Aug 27 17:14:11 2026 +0800 sched_ext: Fix several comment issues Fix several comment issues found during review: __setschduler_prio() -> __setscheduler_class() scx_iter_scx_dsq_new() -> bpf_iter_scx_dsq_new() scx_next_task_scx() -> set_next_task_scx() Signed-off-by: Wanwu Li Signed-off-by: Tejun Heo commit 84590dbb9f3519e865ee8396494ac7186b625fef Author: Wanwu Li Date: Thu Aug 27 16:07:38 2026 +0800 sched_ext: Check bpf_timer_start return values in scx_qmap monitor_timerfn(), lowpri_timerfn() and round_robin_timerfn() ignore bpf_timer_start()'s return value: a failed re-arm silently stops the periodic heartbeat, starving every task parked in LOWPRI_DSQ (lowpri) or freezing cid rotation (round-robin). Check the returns and raise scx_bpf_error(), matching the init paths. Signed-off-by: Wanwu Li Signed-off-by: Tejun Heo commit b6ee92d7f7f0498d1f776d0b125a2f6bcedf0891 Author: Wanwu Li Date: Thu Aug 27 16:07:37 2026 +0800 sched_ext: Fix vtime delta loss in scx_flatcg cgroup migration fcg_cgroup_move() lost the signed vtime offset across cgroup migration in the mechanical conversion to time helpers: time_delta() clamps negative deltas to 0, so a queued task (whose dsq_vtime is normally behind the source frontier) loses its accumulated vtime credit and lands exactly at the destination frontier instead of keeping its relative position. Restore the wrapping signed subtraction. Fixes: 62addc6dbf36 ("sched_ext: Use time helpers in BPF schedulers") Signed-off-by: Wanwu Li Signed-off-by: Tejun Heo commit 23761359861ca4bb087540937dfea8b0716914c2 Author: Wanwu Li Date: Thu Aug 27 16:07:36 2026 +0800 sched_ext: Fix timer pinning and return value in scx_central central_timerfn() re-arms the timer with a hardcoded BPF_F_TIMER_CPU_PIN flag and ignores the return value, defeating start_central_timer()'s -EINVAL fallback for kernels without the flag (<6.7): on such kernels the first tick kills the timer permanently with no diagnostic. Honor timer_pinned and check the return like the initial arm does. Fixes: 22a920209ab6 ("sched_ext: Implement tickless support") Signed-off-by: Wanwu Li Signed-off-by: Tejun Heo commit 9db31edf92dde1f3c98008bd5f88e859d14324cc Author: Vignesh Viswanathan Date: Wed Aug 19 11:00:30 2026 +0530 remoteproc: qcom_q6v5_pas: Fix error masking in qcom_pas_stop() In qcom_pas_stop function, return value of qcom_pas_shutdown for pas_id is overwritten by the return value of qcom_pas_shutdown for dtb_pas_id. This causes errors seen on qcom_pas_shutdown failures for pas_id to be masked to the caller. This might lead to issues where the memory regions locked by PAS, as part of qcom_pas_auth_and_reset, are not released for access by linux and rproc_coredump flow will end up accessing the locked memory, leading to an access violation. Fix this by using a separate variable for the dtb_pas_id shutdown call and only overriding the main return value if the pas_id shutdown succeeded but dtb_pas_id shutdown failed. Fixes: 29814986b82e ("remoteproc: qcom_q6v5_pas: add support for dtb co-firmware loading") Signed-off-by: Vignesh Viswanathan Reviewed-by: Konrad Dybcio Reviewed-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260819-rproc_dtb_fix-v1-1-cb6be7f93bc9@oss.qualcomm.com Signed-off-by: Bjorn Andersson commit cd3b9cea675bbfebc223f007dc2f4e79524fa54c Author: Amit Sunil Dhamne Date: Thu Aug 27 21:16:17 2026 +0000 usb: typec: tcpm: constrain TCPM_SOURCING_VBUS event handling When a sink detach occurs while waiting for TX send status, the old TCPM_SOURCING_VBUS event along with TCPM_VBUS_EVENT and TCPM_CC_EVENT can be queued in port->pd_events. Because TCPM_SOURCING_VBUS is evaluated after TCPM_VBUS_EVENT and TCPM_CC_EVENT in tcpm_pd_event_handler(), a stale TCPM_SOURCING_VBUS event can override the detach handling and incorrectly set port->vbus_source and port->vbus_present to true. Add a state guard to check that the port is either operating as a Source (tcpm_port_is_source(port)) or in a Fast Role Swap (FRS) state up to FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED before processing TCPM_SOURCING_VBUS. Otherwise, discard and log the event. Log snippet for error condition before fix: [72792.204955] state change SRC_ATTACHED -> SRC_STARTUP [rev3 NONE_AMS] [72792.204960] sourcing vbus [72792.204962] VBUS on [72792.204970] AMS POWER_NEGOTIATION start [72792.204974] cc:=4 [72792.205319] state change SRC_STARTUP -> AMS_START [rev3 POWER_NEGOTIATION] [72792.205325] state change AMS_START -> SRC_SEND_CAPABILITIES [rev3 POWER_NEGOTIATION] [72792.205332] PD TX, header: 0x11a1 [72792.216911] PD TX complete, status: 2 [72792.216957] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES @ 150 ms [rev3 POWER_NEGOTIATION] [72792.218005] VBUS off [72792.218013] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION] [72792.218020] VBUS VSAFE0V [72792.218024] state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED [rev3 POWER_NEGOTIATION] [72792.218458] CC1: 2 -> 0, CC2: 0 -> 0 [state SNK_UNATTACHED, polarity 0, disconnected] [72792.218467] VBUS on --> VBUS left on [72792.218980] disable vbus discharge ret:0 [72792.235193] Start toggling After fix: [ 1195.291691] state change SRC_ATTACHED -> SRC_STARTUP [rev3 NONE_AMS] [ 1195.291698] sourcing vbus [ 1195.291700] VBUS on [ 1195.291707] AMS POWER_NEGOTIATION start [ 1195.291710] cc:=4 [ 1195.291758] state change SRC_STARTUP -> AMS_START [rev3 POWER_NEGOTIATION] [ 1195.291794] state change AMS_START -> SRC_SEND_CAPABILITIES [rev3 POWER_NEGOTIATION] [ 1195.291798] PD TX, header: 0x11a1 [ 1195.297056] PD TX complete, status: 2 [ 1195.297092] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES @ 150 ms [rev3 POWER_NEGOTIATION] [ 1195.297177] VBUS off [ 1195.297184] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION] [ 1195.297227] CC1: 2 -> 0, CC2: 0 -> 0 [state SRC_SEND_CAPABILITIES, polarity 0, disconnected] [ 1195.307469] cc:=2 [ 1195.307544] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION] [ 1195.307555] Discarding sourcing vbus! Invalid state SRC_SEND_CAPABILITIES [ 1195.957636] state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED [delayed 650 ms] [ 1195.957732] disable vbus discharge ret:0 [ 1195.970196] Start toggling [ 1195.970468] VBUS off [ 1196.051637] VBUS off [ 1196.051642] VBUS VSAFE0V Fixes: 8dc4bd073663 ("usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)") Cc: stable Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Amit Sunil Dhamne Reviewed-by: Badhri Jagan Sridharan Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260827-sourcing-vbus-v1-1-9be1aca991a0@google.com Signed-off-by: Greg Kroah-Hartman commit 0d8e2195bce6f08c1c53c5ef4d7347fe46418101 Author: Mostafa Saleh Date: Thu Aug 27 20:30:55 2026 +0000 remoteproc: qcom_q6v5_adsp: Fix iommu_unmap() usage During adsp_map_carveout, the IOVA is computed by combining the physical address and the SID: iova = adsp->mem_phys | (sid << 32); However, adsp_unmap_carveout() uses the physical address and not the IOVA in iommu_unmap(), causing the unmap to fail or leak mappings because the address doesn't match the original IOVA. Cache the constructed IOVA within the qcom_adsp device struct during mapping and use it during unmapping. Fixes: f22eedff28af ("remoteproc: qcom: Add support for memory sandbox") Signed-off-by: Mostafa Saleh Link: https://lore.kernel.org/r/20260827203055.640116-1-smostafa@google.com Signed-off-by: Bjorn Andersson commit b853857293584dd1f52183f70a2bdeca692a1e71 Author: Paul Hollinsky Date: Fri Aug 21 01:15:40 2026 -0700 remoteproc: qcom_q6v5_mss: Don't require PAS for memory protection Commit f3b1357673dd ("remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs") changed the probe-time gate for need_mem_protection platforms from qcom_scm_is_available() to qcom_pas_is_available(). Memory protection in this driver is implemented with qcom_scm_assign_mem(), which is a TZ service distinct from PAS. The only PAS call in the driver is qcom_pas_mem_setup(), and it is already guarded by need_pas_mem_setup. No descriptor sets both flags: sc7180, sc7280, sdm660, sdm845, msm8996 and msm8998 set need_mem_protection only, while msm8937, msm8940 and msm8953 set need_pas_mem_setup only. On TrustZone firmware that does not implement PAS - for example SC7180 Chromebooks, where call-availability queries report every QCOM_SCM_SVC_PIL command as unavailable - the modem consequently never probes: platform 4080000.remoteproc: deferred probe pending: (reason unknown) On those machines the modem is also what loads the WLAN firmware, so ath10k never receives QMI and wifi does not come up either. Gate memory protection on SCM availability as it was before, and require PAS only where a PAS call is actually issued. Keeping the SCM check matters: qcom_scm_assign_mem() passes __scm->mempool to qcom_tzmem_alloc() without testing __scm, so dropping the gate entirely would allow a NULL dereference when qcom_scm has not yet probed. Fixes: f3b1357673dd ("remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs") Link: https://lore.kernel.org/r/20260808034716.58888-1-phollinsky@holtechnik.com Signed-off-by: Paul Hollinsky Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260821081540.89137-1-phollinsky@holtechnik.com Signed-off-by: Bjorn Andersson commit 3f4b7d1a49c5c826f3be9b684313eea5b83ac232 Author: Etienne Perot Date: Fri Aug 28 21:52:52 2026 +0000 selftests/cgroup: test clone3() into a previously killed cgroup Once cgroup.kill had been written to a cgroup, a stale kill_seq snapshot (taken in cgroup_css_set_fork() before the target cgroup was resolved) caused every child subsequently cloned into that cgroup with clone3(CLONE_INTO_CGROUP) to be SIGKILLed on the spot. Add a regression test: create a cgroup, kill it while it is empty, then clone a child into it and check that the child runs and exits cleanly. On a kernel without the fix, the test fails: not ok 4 test_cgkill_clone_into_killed The test is skipped on kernels without clone3() or without CLONE_INTO_CGROUP. Cc: Shakeel Butt Assisted-by: LLM Signed-off-by: Etienne Perot Signed-off-by: Tejun Heo commit 8e359920216689b3b79e0fe8961a77fe312a511f Author: Etienne Perot Date: Fri Aug 28 21:52:51 2026 +0000 cgroup: fix spurious SIGKILL of CLONE_INTO_CGROUP children Since commit b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill"), the fork path snapshots the kill_seq of the child's future cgroup into kargs->kill_seq, and cgroup_post_fork() SIGKILLs the child if that cgroup's kill_seq has changed in the meantime, to catch forks racing with a cgroup.kill sweep. For CLONE_INTO_CGROUP, however, the snapshot in cgroup_css_set_fork() is taken before the target cgroup has been resolved: kargs->cgrp is always NULL at this point (it is only set at the end of the function). So the "if (kargs->cgrp)" branch is dead code and the snapshot always records the kill_seq of the parent's cgroup. cgroup_post_fork() then compares it with the kill_seq of the target cgroup, so the child gets SIGKILLed whenever the two cgroups have been killed a different number of times. As a result, once cgroup.kill has been written to a cgroup, every child subsequently cloned into it with clone3(CLONE_INTO_CGROUP) is killed on the spot, for as long as the cgroup exists: kill_seq is not exposed to userspace and never resets. Re-snapshot kill_seq from the target cgroup once it has been resolved, and drop the dead branch at the early snapshot site. This does not reopen the race fixed by b69bb476dee9. For CLONE_INTO_CGROUP, everything from the snapshot to the check in cgroup_post_fork() runs with cgroup_mutex held, and kill_seq is only ever incremented under cgroup_mutex. tj: Updated the comment above kill_seq to reflect the new serialization rules as suggested by Shakeel Butt. Fixes: b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill") Cc: stable@vger.kernel.org Cc: Shakeel Butt Assisted-by: LLM Signed-off-by: Etienne Perot Signed-off-by: Tejun Heo commit 34b8b2d78b6276dc2dc4ebc06625a39956f266e4 Author: Shawn Guo Date: Sat Aug 1 09:17:31 2026 +0800 remoteproc: qcom: q6v5_pas: Don't enable handover IRQ on attach qcom_pas_attach() unmasks the handover IRQ and marks handover_issued even though this driver instance never runs qcom_q6v5_prepare() for the boot it is attaching to. This was believed necessary to flush a stale interrupt latched at the interrupt controller while masked, but the handover IRQ is a Qualcomm SMP2P soft IRQ, not a real edge-latched hardware interrupt. The Linux SMP2P driver updates its cached value unconditionally on every notification and only delivers the nested IRQ for bits currently enabled in its own software bitmap, so a transition that happens while masked is simply dropped, never replayed on a later unmask. Since there is nothing to flush, and this driver instance never takes the proxy power-domain/clock/regulator votes that the handover callback would tear down, there is no need to unmask the IRQ in attach() at all. Drop the enable_irq()/disable_irq() pair; setting handover_issued = true is sufficient to keep the flag consistent for the eventual qcom_q6v5_unprepare()/qcom_q6v5_prepare() cycle. It fixes the following unbalanced runtime PM usage and IRQ enable warnings seen on Nord ADSP (probed as attached), after commit bb7c5d6f5b41 ("remoteproc: qcom: q6v5: Make handover IRQ one-shot") comes in place. root@iq10-rrd:~# cat /sys/class/remoteproc/remoteproc0/state attached root@iq10-rrd:~# echo stop > /sys/class/remoteproc/remoteproc0/state [ 40.004874] genpd genpd:0:4c00000.remoteproc: Runtime PM usage count underflow! [ 40.012409] genpd genpd:1:4c00000.remoteproc: Runtime PM usage count underflow! [ 40.050074] remoteproc remoteproc0: stopped remote processor adsp root@iq10-rrd:~# echo start > /sys/class/remoteproc/remoteproc0/state [ 44.350298] remoteproc remoteproc0: powering up adsp [ 44.375769] remoteproc remoteproc0: Booting fw image qcom/nord/adsp.mbn, size 8241816 [ 44.389850] PDM: no support for the platform, userspace daemon might be required. [ 44.397864] ------------[ cut here ]------------ [ 44.402633] Unbalanced enable for IRQ 363 [ 44.406779] WARNING: kernel/irq/manage.c:775 at __enable_irq+0x4c/0x7c, CPU#9: sh/791 ... Suggested-by: Stephan Gerhold Signed-off-by: Shawn Guo Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260801011731.1084591-1-shengchao.guo@oss.qualcomm.com Signed-off-by: Bjorn Andersson commit cfc1e9a543e3589ba200795b6e7fd8ef4314efdf Author: Pengpeng Hou Date: Sun Aug 30 22:22:44 2026 +0800 ARM: socfpga: select the PL310 erratum 753970 workaround ARCH_INTEL_SOCFPGA selects CACHE_L2X0 and several PL310 erratum workarounds. The 753970 workaround is still conditioned on PL310, but that Kconfig symbol no longer exists, so this one selection is always disabled. Select PL310_ERRATA_753970 directly, consistently with the other PL310 workarounds required by the platform. Fixes: fbc125afdc50 ("ARM: socfpga: Turn on ARM errata for L2 cache") Signed-off-by: Pengpeng Hou Signed-off-by: Dinh Nguyen commit 35131b1d29cbb30a4a3f32c541a0167bdfdbcbd1 Merge: cee9395acd8043 d5869dae5080e9 Author: Martin K. Petersen (Oracle) Date: Mon Aug 31 11:20:09 2026 -0400 Merge branch '7.3/scsi-queue' into 7.3/scsi-fixes Pull in outstanding fixes queued for 7.3. Signed-off-by: Martin K. Petersen (Oracle) commit 35ce3c571297aee13c6da604d022929fd1aa9efb Author: Dale Whinham Date: Sun Aug 30 18:40:07 2026 +0100 arm64: dts: qcom: x1-denali: Fix microphone distortion The microphones (2x) on Surface Pro 11 are currently ususable due to a misconfigured sample rate, which results in a very distorted recording with the voice barely audible. Under Windows, the DMIC0_CTL register is set to 0x00000005 while recording: bit 0 = 1 --> DMIC0 enabled bits 3:1 = 2 --> DMIC clock divider = /4 The current dmic-sample-rate of 4800000 corresponds to the default DMIC clock divider of /2. Dropping dmic-sample-rate to 2400000 sets the divider to /4, matching the working Windows configuration and resulting in perfect audio. While we're at it, remove the reference to dmic23_default, as we only have two microphones and don't need to configure the pins for a 3rd/4th microphone. Signed-off-by: Dale Whinham Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260830-surface-pro-11-mic-fix-v1-1-36a53140373b@gmail.com Signed-off-by: Bjorn Andersson commit 4aa2c106aef4bf3dfd97c30842db0767b26e8428 Author: Yunpeng Tian Date: Sun Aug 30 18:46:56 2026 -0700 smb: client: reject SetEA requests that do not fit the request buffer CIFSSMBSetEA() copies the caller's extended attribute value into the SMB request buffer without checking that it fits. The requirement is stated in the source but was never implemented: /*BB add length check to see if it would fit in negotiated SMB buffer size BB */ /* if (ea_value_len > buffer_size - 512 (enough for header)) */ if (ea_value_len) memcpy(parm_data->list.name + name_len + 1, ea_value, ea_value_len); The only bound applied on the way in is in cifs_xattr_set(): #define MAX_EA_VALUE_SIZE CIFSMaxBufSize ... if (size > MAX_EA_VALUE_SIZE) CIFSMaxBufSize is the full payload capacity of the buffer, so a value of exactly that size leaves no room for the SMB header, the TRANS2 parameter block, the fealist header and the EA name that are written ahead of it in the same object. SendReceive() already enforces the correct limit on this very length: if (in_len > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE) but it is called after the copy has taken place. An unprivileged setxattr(2) on an SMB1 mount with a 250-byte name and a 16384-byte value writes 16384 bytes starting 345 bytes into a 16588-byte cifs_request object, ending 141 bytes past it: BUG: KASAN: slab-out-of-bounds in CIFSSMBSetEA+0xabc/0xde0 Write of size 16384 at addr ffff888003aa0159 by task init/68 __asan_memcpy+0x3c/0x60 CIFSSMBSetEA+0xabc/0xde0 cifs_xattr_set+0xd3a/0xff0 __vfs_setxattr+0x13e/0x1a0 The buggy address is located 345 bytes inside of allocated 16588-byte region Apply SendReceive()'s limit to the assembled request before the copy rather than after it, and widen the byte counters so the sum cannot wrap before it is tested. byte_count is also tested against U16_MAX, because it is stored in the 16-bit pSMB->ByteCount. That becomes reachable when CIFSMaxBufSize is raised at module load, where it may be set as high as 1024*127: with a 5-byte EA name and a 65521-byte value, count is exactly U16_MAX while byte_count is 65556, and cpu_to_le16() would truncate it to 20 and transmit a frame whose ByteCount does not match its length. Testing byte_count covers count as well, since byte_count is the larger of the two and count's only 16-bit consumer is written after this point. check_add_overflow() is evaluated first so that total_len is assigned before it is reported. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yunpeng Tian Reported-by: Mingda Zhang Reported-by: Gongming Wang Reported-by: Qinrun Dai Cc: stable@vger.kernel.org Signed-off-by: Yunpeng Tian Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit a8603b52b39f520ea8a34def74c23fba87396d3e Author: Paulo Alcantara Date: Fri Aug 28 19:08:09 2026 -0300 smb: client: fix data corruption with concurrent writes and O_TRUNC cifs_do_truncate() flushes dirty pages with filemap_write_and_wait() and truncates the file on the server, but in the old code both operations ran without holding i_rwsem or invalidate_lock. A concurrent buffered write via netfs_perform_write() -- which only needs i_rwsem shared -- could dirty new pages after the flush but before the local truncation, and those pages would be silently discarded by cifs_setsize() -> truncate_pagecache(). Fix by acquiring inode_lock (exclusive i_rwsem) and filemap_invalidate_lock at the top of cifs_do_truncate(), so the entire flush-truncate-resize sequence is atomic with respect to: - buffered writes (blocked by exclusive i_rwsem, since netfs_start_io_write takes i_rwsem shared), - read page faults (blocked by exclusive invalidate_lock, since filemap_fault takes it shared), - writeback collection (blocked by netfs_wb_begin/netfs_wb_end around the server truncate and local resize, since netfs_writepages also acquires the wb lock). Fixes: 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC") Signed-off-by: Paulo Alcantara Reviewed-by: Namjae Jeon Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org commit bb06e5a2a031c89b1f1f60ff45ce80f8e4f6ee56 Author: Mete Durlu Date: Tue Aug 25 14:58:20 2026 +0200 s390/topology: Switch to common cpu capacity code s390 implementation of cpu capacity management infrastructure code does not do anything different than its common code counterpart. Switch to common code functions and remove the smp_cpu_*_capacity() functions. Make s390 code better align with other architectures which utilize cpu_capacity. No functional changes. Allow cpu_capacity attributes inside sysfs to accurately reflect cpu capacity. ex: $ cat /sys/devices/system/cpu/cpu0/polarization vertical:high $ cat /sys/devices/system/cpu/cpu0/cpu_capacity 1024 $ cat /sys/devices/system/cpu/cpu40/polarization vertical:low $ cat /sys/devices/system/cpu/cpu40/cpu_capacity 128 Prior to commit 6bceea7a1e07 ("arch_topology: Relocate cpu_scale to topology.[h|c]") cpu_capacity attribute was only available to the common arch_topology driver's users. Reflect the correct values to the newly made available attributes. Signed-off-by: Mete Durlu Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit 8cff0ac21658fedd4598e9904dd0c518bdaf5856 Author: Heiko Carstens Date: Tue Aug 25 11:49:25 2026 +0200 s390/pai: Reduce excessive debug feature size The pai debug feature is registered with 256 areas, where each area contains 32 pages. This sums up to a total of 32MiB. The code does not use any debug exceptions, which means that 255 of those areas are never used. In addition all existing debug feature calls have a lower level (5) than the default level (3). This in turn means that without user interaction the debug feature is unused. Reduce the number of areas to 1, and also reduce the number of pages for the remaining area to 1. Since user interaction is required, the user can also increase the size of the remaining area, instead of wasting memory by default. This reduces the total size of the debug feature to 4KiB. Fixes: a3f8423622ef ("s390/pai_crypto: Add PAI crypto characteristics table for parameters") Reviewed-by: Thomas Richter Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit f3110e969ad226ffbb2d9b4bf5387e68d0d9ef40 Author: Thomas Richter Date: Wed Aug 19 07:58:55 2026 +0200 s390/pai: Handle multiple PMU stop callback invocations Handle the following scenario: The kernel protects itself against a very high sampling load and throttles the sampling using: perf_event_throttle() --> PMU->stop() Shortly later the scheduler may terminate the task and removes it from the CPU. It again calls PMU->stop() which results in two invocations of PMU->stop() called back to back. Protect against this and check the PERF_HES_STOPPED bit on function entry. If it is already set return. Clear bit PERF_HES_STOPPED in PMU->start(). Prohibit ioctl(fd, PERF_EVENT_IOC_PERIOD, ...) call for this event. It sets perf_event::event_limit to a positive value and causes perf_event_overflow() to invoke pai_stop() call back function when perf_event::event_limit hits zero. This is not supported because the sample events CRYPTO_ALL and NNPA_ALL are only taken at schedule out of a task. Use list_for_each_entry_safe() for safe iteration over syswide_list in pai_have_samples(). Fixes: 9f66572f2889 ("s390/pai_crypto: Enable per-task and system-wide sampling event") Fixes: 582cc1b28e8c ("s390/pai_ext: Enable per-task and system-wide sampling event") Cc: stable@vger.kernel.org # v6.19+ Signed-off-by: Thomas Richter Reviewed-by: Sumanth Korikkar Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit 439077c39d8f7108aea4dd8d4d819b9b864fe84c Author: Sumanth Korikkar Date: Tue Aug 11 16:23:06 2026 +0200 s390/diag324: Preserve -EBUSY return code When diag324 reports -EBUSY, the error code is overwritten by the result of copy_to_user() and put_user(). As a result, the ioctl may incorrectly return success instead of -EBUSY. Preserve the original diag324 return code and only return -EFAULT when copying data to userspace fails. Fixes: 90e6f191e1ee ("s390/diag324: Retrieve power readings via diag 0x324") Signed-off-by: Sumanth Korikkar Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit a91a5c25a2c3f652178b591facc2395a7dbb59af Author: Holger Dengler Date: Thu Aug 20 17:50:03 2026 +0200 s390/zcrypt: Validate length in reply before using it The length information in the reply is used to copy the key token to the target buffer. An invalid information in t->len of the reply may cause an over-read of the target buffer and also a over-write of the target buffer. To prevent that, check t->len before using it. As the available space in destination and source buffer is always larger than the valid length value in the parameter block in the reply, compare t->len with this (already validated) length information. As a side effect, this check also prevents buffer over-read and over-write. Reviewed-by: Harald Freudenberger Signed-off-by: Holger Dengler Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit 8ac60ae2a307a50b599bf5d300b448d638f3ba29 Author: Niklas Schnelle Date: Thu Aug 6 11:43:39 2026 +0200 s390/pci: Fix leak of uninitialized kernel data in SCLP report While report_error_write() checks that the provided buffer is at least as large as the header struct, but not that it is large enough to contain the report with the length claimed by report->length. If user-space provides a short buffer, meaning a larger report->length than the actually written payload, up to around 4K of kernel data from past the kmalloc(len + 1) sized buffer allocated in kernfs_fop_write_iter() will leak into the SCLP report. However, as the entity processing the SCLP is privileged and able to access at least the page including the report, this does not leak data that entity could not access but it is still an out of bounds read and a malformed error report that should be rejected. Fixes: 368704a65be8 ("s390/pci: add report_error attribute") Cc: stable@vger.kernel.org Signed-off-by: Niklas Schnelle Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit 37f61b71cbc0caefc01022a19ee56fc2510e2e6e Author: Vasily Gorbik Date: Thu Aug 13 13:06:55 2026 +0200 s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block Unlike kdump, which passes the re-IPL parameter block through os_info, the stand-alone dump passes it through the IPL parm block address and checksum in lowcore. Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not provide an IPL parameter block. In this case reipl_type_init() selects IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL. Nevertheless, dump_reipl_run() unconditionally dereferences it when preparing the lowcore fields. This may happen to work by chance when address zero contains readable lowcore data. A zero IPL parameter block address is then stored in lowcore, causing the stand-alone dumper to enter disabled wait after completing the dump. Explicitly store a zero IPL parameter block address and checksum when no re-IPL parameter block is available. This does not change the behavior: the stand-alone dumper completes the dump and halts, while valid re-IPL parameter blocks continue to be handled as before. Fixes: 099b76513992 ("[S390] Automatic IPL after dump") Reviewed-by: Mikhail Zaslonko Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit 7f918871112e8e7c581e99eb8e545af4e59c8367 Author: Vasily Gorbik Date: Thu Aug 13 13:06:54 2026 +0200 s390/ipl: Fix NULL deref in kdump without re-IPL parm block Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not provide an IPL parameter block. In this case, reipl_type_init() selects IPL_TYPE_UNKNOWN, and reipl_block_actual remains NULL. kdump passes the re-IPL parameter block to the dump kernel through os_info. Before commit 3b9678472bab ("s390/ipl: correct kdump reipl block checksum calculation"), the os_info entry was added only for IPL types which initialized reipl_block_actual. That commit moved the os_info update to machine_crash_shutdown(), making it unconditional. As a result, set_os_info_reipl_block() dereferences reipl_block_actual for IPL_TYPE_UNKNOWN. This may happen to work by chance when address zero contains readable lowcore data and the resulting empty os_info entry is ignored by the dump kernel. Skip the os_info update when no re-IPL parameter block is available. Kdump then collect the dump and reboot without setting re-IPL parameter block. Fixes: 3b9678472bab ("s390/ipl: correct kdump reipl block checksum calculation") Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit f3c63b8cabbb121866347fe164c23635965b31d7 Author: Uwe Kleine-König (The Capable Hub) Date: Thu Aug 6 18:21:19 2026 +0200 s390/ap: Drop unused member from ap_device_id ap_device_id::driver_info is not used in the kernel. The structure is also not part of API/ABI, so the unused member can just be dropped. Signed-off-by: Uwe Kleine-König (The Capable Hub) Acked-by: Holger Dengler Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit b00c10948fa4c9b1f3e2814b97f299ad970f94c8 Author: Ilya Leoshkevich Date: Fri Aug 14 14:15:25 2026 +0200 s390/cpacf: Unpoison instruction results Stop KMSAN from complaining about CPACF outputs being uninitialized. Do not unpoison variable-length parameter blocks: mapping function codes (like CPACF_KIMD_SHA_256) to lengths will be ugly. So let the callers do this once the need arises. Also do not touch cpacf_kma(): this wrapper does not handle cc 1 and cc2 at the moment and has to be reworked. Reviewed-by: Harald Freudenberger Signed-off-by: Ilya Leoshkevich Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit ca1f4a5ecab084af7f405baa902edbed171b57e6 Author: Heiko Carstens Date: Thu Aug 13 15:25:05 2026 +0200 s390/time: Use jiffies instead of jiffies_64 Christoph Schlameuss and Alexander Egorenkov reported a data-race reported by KCSAN when jiffies_64 is read: ================================================================== BUG: KCSAN: data-race in do_account_vtime / tick_do_update_jiffies64 write to 0x0000016599ea8600 of 8 bytes by interrupt on cpu 6: tick_do_update_jiffies64+0x140/0x250 =============================================================> BUG: KCSAN: data-race in do_account_vtime / tick_do_update_ji> write to 0x0000016599ea8600 of 8 bytes by interrupt on cpu 6: tick_do_update_jiffies64+0x140/0x250 tick_nohz_handler+0x2e6/0x300 __run_hrtimer+0x156/0x4d0 __hrtimer_run_queues+0xd2/0x150 ... system_call+0x72/0x90 read to 0x0000016599ea8600 of 8 bytes by interrupt on cpu 12: do_account_vtime+0x7d6/0x860 vtime_flush+0x26/0xe0 update_process_times+0x32/0x160 tick_nohz_handler+0x12a/0x300 ... system_call+0x72/0x90 value changed: 0x00000000ffffaa6c -> 0x00000000ffffaa6d ... =============================================================> Problem is that jiffies_64 instead of jiffies is used. Both are at the same address, but only jiffies is of volatile type, which prevents this warning. Change the vtime code so jiffies instead of jiffies_64 is used everywhere. This addresses also the inconsistency that both jiffies and jiffies_64 were used in the original patch which introduced this. Fixes: f341b8dff982 ("s390/vtime: limit MT scaling value updates") Reported-by: Christoph Schlameuss Reported-by: Alexander Egorenkov Reviewed-by: Alexander Egorenkov Tested-by: Alexander Egorenkov Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens commit fbf2c660bac863f0ac372b677ee55bf775c94594 Author: Richard Fitzgerald Date: Mon Aug 31 10:45:06 2026 +0100 ASoC: cs35l56: Fix pm_runtime imbalance if suspending before first attach Remove the check for init_done in cs35l56_sdw_system_suspend(). Instead, protect the call to cs35l56_mask_soundwire_interrupts() to only be done if the amp is currently enumerated. This fixes a runtime imbalance if cs35l56_sdw_system_suspend() is called before the first SoundWire attach. This would skip the call to pm_runtime_force_suspend() in cs35l56_system_suspend(). But resume unconditionally called pm_runtime_force_resume() leading to an imbalance. cs35l56_system_suspend() doesn't have any dependency on completion of cs35l56_init(), so there is no need for the skip on !init_done in cs35l56_sdw_system_suspend(). Fixes: f9dc6b875ec0a ("ASoC: cs35l56: Add basic system suspend handling") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260831094506.57467-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown commit 2f4a0fb66d313f03832f061bc3ec25b33c8198c9 Author: Jinhui Guo Date: Tue Aug 4 20:19:10 2026 +0800 soc/tegra: fuse: Add missing newline to APBMISC error message The error message printed by tegra_acpi_init_apbmisc() when failing to get APBMISC memory resources is missing a trailing newline. This can cause the message to be merged with the following kernel log line, making the log harder to read. Add the missing newline to keep the error output properly formatted. Fixes: 7b0c505eb341 ("soc/tegra: fuse: Add tegra_acpi_init_apbmisc()") Signed-off-by: Jinhui Guo Signed-off-by: Thierry Reding commit b86eaddf467a9ddb69dbaa46eea9dda7f93347a3 Author: Thierry Reding Date: Thu Jul 16 13:43:26 2026 +0200 arm64: tegra: Add PCIe root ports on Tegra264 The bindings have been updated to use the PCIe root port bindings, so the nodes for the root ports must be added. Signed-off-by: Thierry Reding commit 4ee64cda9866f4ef19f2802443548e942ad24a23 Author: Thierry Reding Date: Wed May 7 12:02:18 2025 +0200 arm64: tegra: Reorder reg and reg-names to match bindings The ECAM region cannot be the first entry in the "reg" property, because in that case the unit-address wouldn't match the first entry. The order of the nodes can also not be changed to match the ECAM entry because the ECAM region is global and outside of any of the control busses. Acked-by: Manivannan Sadhasivam Signed-off-by: Thierry Reding commit a93db5724ada1c09a434f43258db4545a893a1af Author: Thierry Reding Date: Thu Aug 27 17:01:43 2026 +0200 arm64: tegra: Add PWM fan on Jetson AGX Thor DevKit Without a PWM fan device node to actively control the PWM, the fan will either stop or run at full speed, depending on the state of the PWM when the controller's clock gets turned off during boot. One is bad for the system's lifetime and the other is very annoying for anyone in close proximity to the device, so add the PWM fan in device tree to fix this. Signed-off-by: Thierry Reding commit dd3b6f7adcc559647f8215a1c73d19af27a8d20a Author: Thierry Reding Date: Wed Jul 1 12:20:36 2026 +0900 arm64: tegra: Add PWM controllers on Tegra264 Tegra264 has a number of PWM controllers that are similar but incompatible with those found on earlier chips. Signed-off-by: Mikko Perttunen Tested-by: Jon Hunter Reviewed-by: Jon Hunter Signed-off-by: Thierry Reding commit be150d35864ccd8d1005a12953da145013219d35 Merge: c8329cb590df4a 8d3ae59288f1e7 Author: Thomas Zimmermann Date: Mon Aug 31 14:43:36 2026 +0200 Merge drm/drm-fixes into drm-misc-fixes Updating drm-misc-fixes to the state of v7.2. Signed-off-by: Thomas Zimmermann commit 406292fd75f95aa3010fec95b5beb5a8b7e3ba3a Author: Lucas Tanure Date: Sat Aug 29 10:47:58 2026 +0100 arm64: dts: amlogic: t7: fix the pin groups of the vsync PWM The vsync PWM output can appear on either of two pins, but the description named a single group that does not exist, so anything using it would refuse to start. Name the real groups instead, one entry per pin. No board describes this output yet, so nothing changes today. Fixes: 2a2a7b9701a7 ("arm64: dts: amlogic: t7: Add PWM pinctrl nodes") Assisted-by: Claude:claude-opus-5 Signed-off-by: Lucas Tanure Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260829094758.23248-5-tanure@linux.com Signed-off-by: Neil Armstrong commit 1e5a53bd16ac501e68463e84023d1bff543cc696 Author: Lucas Tanure Date: Sat Aug 29 10:47:57 2026 +0100 arm64: dts: amlogic: t7: khadas-vim4: add the PWM-driven supplies The board powers its two CPU clusters, the GPU, the NPU, the memory and the always-on domain from regulators steered by PWM outputs. None of them were described, so Linux treated those outputs as unused and switched them off part way through boot. The supplies then drifted away from the levels the bootloader had set, which showed up as random hangs and memory corruption. Describe each supply so it has an owner and is left alone. The voltage ranges are read off the feedback networks on the board schematic. VDDNPU is deliberately not the range in Amlogic's own device tree: this board fits a different feedback resistor, which puts it about 40mV higher at both ends. Fixes: 8c45bf9ae4ef ("arm64: dts: amlogic: t7: khadas-vim4: Add power regulators") Assisted-by: Claude:claude-opus-5 Signed-off-by: Lucas Tanure Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260829094758.23248-4-tanure@linux.com Signed-off-by: Neil Armstrong commit ae7be5c58a819259e5eb98a3abfa60842478f2ae Author: Lucas Tanure Date: Sat Aug 29 10:47:56 2026 +0100 arm64: dts: amlogic: t7: fix the pin groups of two PWM outputs Two of the PWM outputs can each appear on more than one pin, but the description named a single group that does not exist, so anything using it refused to start. Name the real groups instead, one entry per pin, the same way the other multi-pin PWM output is already described. Fixes: 2a2a7b9701a7 ("arm64: dts: amlogic: t7: Add PWM pinctrl nodes") Assisted-by: Claude:claude-opus-5 Signed-off-by: Lucas Tanure Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260829094758.23248-3-tanure@linux.com Signed-off-by: Neil Armstrong commit c793a084ab3088744516aef437b4239d0d98623f Author: Lucas Tanure Date: Sun Aug 23 12:53:35 2026 +0100 arm64: dts: amlogic: t7: khadas-vim4: allow the SD card to be power cycled SD cards start at 3.3V and switch to 1.8V to reach UHS-I speeds. Some cards refuse that switch, and the SD specification says the only way to recover is to power the card off and start again. SD_3V3 is marked regulator-always-on, so the supply never goes off, the card stays stuck half way through the switch, and the MMC core retries forever: mmc1: error -95 whilst initialising SD card Drop regulator-always-on. regulator-boot-on still turns the supply on at boot, and a card that refuses the switch now falls back to high speed instead of failing to initialise. Fixes: 8c45bf9ae4ef ("arm64: dts: amlogic: t7: khadas-vim4: Add power regulators") Signed-off-by: Lucas Tanure Assisted-by: Claude:claude-fable-5 Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260823115335.102219-3-tanure@linux.com Signed-off-by: Neil Armstrong commit 882de800bf583dd15969836088789edbf035a944 Author: Lucas Tanure Date: Sun Aug 23 12:53:34 2026 +0100 arm64: dts: amlogic: t7: use the real UART pclk uart_a listed the 24MHz crystal for all three of its clocks because the T7 clock controller driver did not exist when these boards were added. That leaves the real UART bus clock without a user, so the kernel turns it off when it disables unused clocks at the end of boot, and the board hangs. Update the board DTS files to point uart_a's pclk to CLKID_SYS_UART_A instead of the dummy crystal clock. Fixes: 4fef056588f5 ("arm64: dts: amlogic-t7-a311d2-khadas-vim4: add initial device-tree") Fixes: 6f048cc7a635 ("arm64: dts: add board AN400") Signed-off-by: Lucas Tanure Assisted-by: Claude:claude-fable-5 Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260823115335.102219-2-tanure@linux.com Signed-off-by: Neil Armstrong commit 04405aeef4f8d7bcac6dcb1947acafdb4420c2c3 Author: Runyu Xiao Date: Sun Aug 30 22:20:26 2026 +0800 ASoC: sti: initialize IRQ lock before requesting IRQ uni_reader_init() registers the shared IRQ before initializing reader->irq_lock. A pending interrupt can invoke the handler while the lock is still uninitialized. Initialize the lock before registering the IRQ so the interrupt path always sees valid lock state. Fixes: d05d862ead8e ("ASoC: STI: Fix null ptr deference in IRQ handler") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260830142026.2666914-1-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown commit 0fecc393f2060e6bc25138df32cb923ec7071c6b Author: Hongling Zeng Date: Mon Aug 31 16:32:52 2026 +0800 ntfs: take invalidate_lock in ntfs_filemap_page_mkwrite() ntfs_filemap_page_mkwrite() calls iomap_page_mkwrite() without holding mapping->invalidate_lock, so a concurrent truncate or fallocate can be in the middle of invalidating pagecache and rewriting the runlist while the write fault maps blocks and dirties the folio. This races with ntfs_attr_fallocate(), which merges clusters into the in-memory runlist, drops the runlist lock, and only afterwards zeroes the newly allocated clusters on disk; and with the punch-hole/insert/collapse paths that free clusters after truncating the cache. Per Documentation/filesystems/locking.rst, ->page_mkwrite() must ensure there are no truncate/invalidate races, "usually mapping->invalidate_lock is suitable for proper serialization". xfs takes its mmaplock (= the invalidate_lock rwsem) shared in exactly this path. Take invalidate_lock shared around iomap_page_mkwrite(). The read-only fault path is already covered because filemap_fault() itself grabs invalidate_lock shared on instantiation/read paths; only page_mkwrite was bypassing it in this driver. Fixes: 9c87959601e8 ("ntfs: update file operations") Cc: stable@vger.kernel.org Reviewed-by: Hyunchul Lee Reviewed-by: Baolin Liu Signed-off-by: Hongling Zeng Co-developed-by: Namjae Jeon Signed-off-by: Namjae Jeon commit 9cc5761b8f28f9cef72061094eb5e37e2cd44d97 Author: Hongling Zeng Date: Mon Aug 31 16:30:14 2026 +0800 ntfs: take invalidate_lock in ntfs_setattr_size() ntfs_setattr_size() updates i_size and resizes the on-disk attribute without holding mapping->invalidate_lock. Page faults take the lock shared, so a fault racing the resize can resolve a VCN against the transient runlist state of ntfs_non_resident_attr_expand() and fail with a spurious SIGBUS, and can interleave with the size-change epilogue (truncate_pagecache(), i_size_write(), pagecache_isize_extended()). Take invalidate_lock exclusively around the whole resize after inode_dio_wait(), matching the fallocate path and other filesystems such as xfs, which wraps truncate in its mmaplock (= invalidate_lock). Fixes: 9c87959601e8 ("ntfs: update file operations") Cc: stable@vger.kernel.org Reviewed-by: Hyunchul Lee Reviewed-by: Baolin Liu Signed-off-by: Hongling Zeng Signed-off-by: Namjae Jeon commit 04cec690b1fd9d1c4c314b91a10d8c68a3acfe18 Author: Jameson Thies Date: Tue Aug 25 23:45:45 2026 +0000 usb: typec: ucsi: displayport: Fix OOB altmode array index The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array. Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Cc: stable@vger.kernel.org Signed-off-by: Jameson Thies Reviewed-by: Benson Leung Link: https://patch.msgid.link/20260825234545.2076049-1-jthies@google.com Signed-off-by: Greg Kroah-Hartman commit 4dc8f4ee2d46d5d1e749ddd1b94912c72e796162 Author: Hongling Zeng Date: Wed Aug 26 13:59:53 2026 +0800 ntfs: handle signal interruption in fallocate The ntfs_attr_fallocate() function checks for pending signals during allocation loops and exits early via 'out' label. However, when a signal interrupts the operation with err == 0, the function returns 0 (success) instead of -EINTR. The signal_pending() checks at the allocation loops jump to 'out' without setting err = -EINTR, so the function returns success even when interrupted by a signal. Set err = -EINTR when jumping to the signal exit path, and only override when no other error is pending. This ensures: - Allocation interrupted by signal returns -EINTR - Allocation that completed successfully before signal arrived returns 0 - Other errors are preserved and not overwritten by -EINTR Fixes: 495e90fa3348 ("ntfs: update attrib operations") Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon commit ba9572bc43d04d71ba52ae7f20645f1eafe86875 Author: Alon Shakevsky Date: Sat Aug 29 06:27:46 2026 +0000 ksmbd: validate normalized name response length FILE_NORMALIZED_NAME_INFORMATION converts the open file path to UTF-16. smb2_allocate_rsp_buf() leaves these responses in the 448-byte small buffer, and get_file_normalized_name_info() converts the path without checking the remaining space. An authenticated client can query a long path and make smbConvertToUTF16() write beyond work->response_buf. Use the large response buffer for normalized-name queries. Before conversion, verify that the response has room for the worst-case UTF-16 output and its terminator. Fixes: 10aeff72ab82 ("ksmbd: support normalized name information") Assisted-by: Antiproof:GPT-5.6-Sol Signed-off-by: Alon Shakevsky Signed-off-by: Namjae Jeon commit a506290f59e1c6ce9ac0a13158640bb8fee93471 Author: Namjae Jeon Date: Fri Aug 28 09:24:49 2026 +0900 ksmbd: fix listener task lifetime on netdev events The listener thread exits when its listening socket is shutdown. The netdevice notifier shuts down the socket before calling kthread_stop(), so the task_struct can be freed before kthread_stop() gets its reference. Create the listener in a stopped state and hold an extra task_struct reference until kthread_stop_put() completes. Also stop and release listeners before freeing their interface records during TCP teardown. Fixes: 3316a8fc840d ("ksmbd: server: avoid busy polling in accept loop") Reported-by: Farhad Alemi Signed-off-by: Namjae Jeon commit f25e93768fcc5d8287e50b1ec52a42e4c276df34 Author: Namjae Jeon Date: Fri Aug 28 08:39:57 2026 +0900 ksmbd: prevent out-of-bounds reads in share config responses Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length. Fixes: a677ebd8ca2f ("ksmbd: validate payload size in ipc response") Reported-by: Kanishka De Silva Reported-by: Farhad Alemi Signed-off-by: Namjae Jeon commit feca5e70fc963b088377b20879e8cd8237c2fd7d Author: Namjae Jeon Date: Tue Aug 25 09:32:23 2026 +0900 ksmbd: rate limit unmapped SID errors A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages. Rate limit the message to prevent an authenticated client from flooding the kernel log. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Reported-by: Cheryl Babcock Signed-off-by: Namjae Jeon commit c61dc7b1b4a3234b4aa3965502908a292238805c Author: Namjae Jeon Date: Tue Aug 25 09:32:07 2026 +0900 ksmbd: propagate DACL parsing errors parse_dacl() silently accepts truncated ACEs and allocation failures, allowing set_info_sec() to continue with an incomplete ACL conversion. Return parsing and allocation errors to parse_sec_desc() so malformed security descriptors are rejected before inode attributes or ACL xattrs are updated. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Reported-by: Cheryl Babcock Signed-off-by: Namjae Jeon commit 73f860489e3be2245598d1819226304fc5b87291 Author: Namjae Jeon Date: Tue Aug 25 09:31:35 2026 +0900 ksmbd: zero pipe read compound padding Compound response handling extends the last response iov to an eight-byte boundary. smb2_read_pipe() allocates only the payload size, so the alignment padding can expose up to seven bytes of uninitialized kernel heap memory. Allocate the aligned size and clear the unused tail before pinning the response buffer. Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Reported-by: Cheryl Babcock Signed-off-by: Namjae Jeon commit d12168084c8c1b6d883c8eca5853929ac5136a9e Author: Namjae Jeon Date: Fri Aug 28 10:46:44 2026 +0900 ksmbd: safely drain sessions during logoff SMB3 multichannel allows requests for one session to run on multiple connections. Wait for all channels bound to a session before freeing shared session objects. A deferred byte-range lock remains counted as a running request and only wakes when its file closes. Wake blocked locks during the drain without unpublishing or modifying their file objects. Synchronous CANCEL requests must invoke their cancellation callback to wake pending operations, while CHANGE_NOTIFY completion remains specific to the asynchronous path. Serialize session teardown with channel registration and previous-session cleanup, and use atomic work-state transitions so LOGOFF, CANCEL, and connection teardown invoke cancellation callbacks only once. Fixes: 76e98a158b20 ("ksmbd: fix race condition between destroy_previous_session() and smb2 operations()") Reported-by: Cheryl Babcock Signed-off-by: Namjae Jeon commit 5c944895a94d0317669f1b3409deb0161eaf916b Author: Namjae Jeon Date: Wed Aug 26 23:36:28 2026 +0900 MAINTAINERS: Update the KSMBD entry Steve French passed away recently. He was a long-time maintainer of Linux's SMB support and will be greatly missed. Update the KSMBD entry to no longer list Steve French as a maintainer. Signed-off-by: Namjae Jeon commit edcd92df5e1f94e89f8cd410ce41c5cb56e24453 Author: Namjae Jeon Date: Wed Aug 26 23:03:01 2026 +0900 MAINTAINERS: Add Paulo Alcantara as an SMBDIRECT co-maintainer Steve French passed away recently. He was a long-time maintainer of Linux's SMB support and will be greatly missed. Add Paulo Alcantara as a co-maintainer of SMBDIRECT. Acked-by: Paulo Alcantara Signed-off-by: Paulo Alcantara Acked-by: Stefan Metzmacher Signed-off-by: Namjae Jeon commit db2267b27c054a6c2151ff7fbb67927e784f31d6 Author: Aleksandr Khromov Date: Tue Aug 25 10:19:21 2026 +0900 ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION smb2_get_info_filesystem() reports 56 bytes for FS_POSIX_INFORMATION, that is the whole of FILE_SYSTEM_POSIX_INFO, but never assigns FileSysIdentifier. Those eight bytes go to the client as they are found in the response buffer. The buffer is zeroed on allocation, so a standalone request leaks nothing. A compound request can leak: the offset of the next response is advanced by the length pinned for the previous one, so a reply that was written into the buffer and then dropped in favour of the short error response of smb2_set_err_rsp() stays there, and the next reply is laid over it with only the header cleared. Report the file system id statfs() returned, which is what the field is for. FileSysIdentifier is __le64 and f_fsid is a pair of ints, so assemble the value first, val[0] as the low half, and convert it on the way out. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Aleksandr Khromov Signed-off-by: Namjae Jeon commit c0cd3fc6824122014da2b3b0cb7ddeaa2946ec8e Author: Aleksandr Khromov Date: Mon Aug 24 21:23:32 2026 +0900 ksmbd: initialize FileSystemControlFlags in FS_CONTROL_INFORMATION smb2_get_info_filesystem() reports 48 bytes for FS_CONTROL_INFORMATION, that is the whole of struct smb2_fs_control_info, but never assigns FileSystemControlFlags. Those four bytes go to the client as they are found in the response buffer. The buffer is zeroed on allocation, so a standalone request leaks nothing. A compound request can leak: the offset of the next response is advanced by the length pinned for the previous one, so a reply that was written into the buffer and then dropped in favour of the short error response of smb2_set_err_rsp() stays there, and the next reply is laid over it with only the header cleared. ksmbd does not implement quota tracking, so report no control flags. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Aleksandr Khromov Signed-off-by: Namjae Jeon commit 399aa12450a61a5c73dc77e73f069ece9687c95d Author: Aleksandr Khromov Date: Mon Aug 24 13:22:46 2026 +0300 ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in smb2_get_info_filesystem() reports 64 bytes for FS_OBJECT_ID_INFORMATION, that is the whole of struct object_id_info, but writes only 46 of them: - objid[] is 16 bytes, and when the volume UUID is not available only sizeof(stfs.f_fsid) (8) bytes are copied into it; - extended_info.version_string[] is STRING_LENGTH (28) bytes, and only strlen("1.1.0") (5) bytes are copied into it. The response buffer is zeroed on allocation (kvzalloc() in smb2_allocate_rsp_buf()), so for a standalone request the remaining 31 bytes are zero. In a compound request they need not be. The offset of the next response is advanced by the length pinned for the previous one, so if a preceding command wrote its reply into the buffer and then failed, smb2_set_err_rsp() pins only the short error response and the next reply lands inside the area that has already been written. Only the header is cleared there: memset((char *)rsp_hdr, 0, sizeof(struct smb2_hdr) + 2); The client then receives up to 31 bytes of a response it was not meant to see, including one that failed with an access denied error. Clear the structure before filling it in. As a side effect version_string is now NUL terminated. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Suggested-by: ChenXiaoSong Cc: stable@vger.kernel.org Signed-off-by: Aleksandr Khromov Signed-off-by: Namjae Jeon commit a518e63c377574784f49653ef5314c70e2463b0c Author: Miklos Szeredi Date: Tue Aug 25 17:23:29 2026 +0200 ovl: return EINVAL instead of EIO in case of mismatched user_ns The EIO was used to signal an internal error (commit 9efb069de4ba ("ovl: add warning on user_ns mismatch")), which is no longer the case. Fixes: 63981fc786da ("ovl: don't warn when the mount is completed from another user namespace") Signed-off-by: Miklos Szeredi Link: https://patch.msgid.link/20260825152330.850645-1-mszeredi@redhat.com Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Amutable) commit 0606f2114e2dc88fe293858fd991cda2688b8c3a Author: Ulf Hansson Date: Wed Aug 26 10:45:32 2026 +0200 cpuidle: psci: Fix support for probe deferral by dropping the faux device At the conversion to the faux driver/device we broke the support for probe deferral. In hindsight, the move to the faux device seems questionable, as it simply makes the code more complicated and for no good reason. To fix the support for the probe deferral let's therefore restore the old code and drop the faux device. Fixes: af5376a77e87 ("cpuidle: psci: Transition to the faux device interface") Fixes: 5836ebeb4a2b ("cpuidle: psci: Avoid initializing faux device if no DT idle states are present") Fixes: 39cdf87a97fd ("cpuidle: psci: Fix uninitialized variable in dt_idle_state_present()") Cc: stable@vger.kernel.org Reviewed-by: Abel Vesa Signed-off-by: Ulf Hansson Signed-off-by: Ulf Hansson commit 3785d40831ba5601296283e0197e10e089392757 Author: Deepanshu Kartikey Date: Thu Aug 13 12:19:02 2026 +0530 drm/i915: Guard against NULL driver_data in i915_pci_probe() pci_match_device() can return the dummy pci_device_id_any entry when a device is force-bound via sysfs driver_override, in which case ->driver_data is unset (NULL). i915_pci_probe() casts it to struct intel_device_info * unconditionally and dereferences intel_info->require_force_probe, causing a NULL-ptr-deref. Reported-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=db96c5ff032f4292a8dc Tested-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260813064902.367504-1-kartikey406@gmail.com Signed-off-by: Jani Nikula (cherry picked from commit 2727922084672cc274ecea726ea00363c2893731) Signed-off-by: Jani Nikula commit a154f2ae8eecbf2a4f97376d29b8d38c198b54e7 Author: Ville Syrjälä Date: Wed Aug 26 17:31:00 2026 +0300 drm/i915/cdclk: Fix dg2_power_well_count() return type dg2_power_well_count() is supposed to return an integer, not a boolean. Make it so. Fixes: 9112ce99c1d7 ("drm/i915/cdclk: Extract dg2_power_well_count()") Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260826143100.19401-1-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper (cherry picked from commit dcf423710d0253d7d729c3992bbae0c6197c9c22) Signed-off-by: Jani Nikula commit aad969968824e97ba8d70dd7a95691f750438ebd Author: Ville Syrjälä Date: Fri Jul 17 18:51:06 2026 +0300 drm/i915/cdclk: Avoid spurious cdclk sanitization on PTL+ Apparently PTL+ no longer has the cd2x pipe select field in CDCLK_CTL. Take that into account during CDCLK sanitization. This currently triggers a spurious CDCLK sanitization during driver load on PTL+ which will causes a visible glitch on all active displays. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8550 Fixes: 2ee8dbd880b1 ("drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable") Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260717155107.17801-1-ville.syrjala@linux.intel.com Reviewed-by: Suraj Kandpal (cherry picked from commit 1786d26887817a779641d3a093c66ac91382113b) Signed-off-by: Jani Nikula commit 7f1172a2ac0d7e50850785e2e65789c8aac8411a Author: Nemesa Garg Date: Tue Aug 18 15:21:49 2026 +0530 drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable icl_plane_disable_sel_fetch_arm() wrote SEL_FETCH_PLANE_CTL = 0 only when crtc_state->enable_psr2_sel_fetch was set. If a plane was disabled after selective fetch had been turned off, the guard fired early and left the register's enable bit set in hardware. The bit is harmless until selective fetch is re-enabled. When it is, the hardware resumes fetching for the now-disabled plane and keeps its old DDB range reserved. i9xx_cursor_disable_sel_fetch_arm() has the same guard on SEL_FETCH_CUR_CTL and is fixed the same way. v2: Add same check for cursor also. [sashiko] Cc: stable@vger.kernel.org Fixes: b1f5279b5981 ("drm/i915/psr: Move plane sel fetch configuration into plane source files") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8739 Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Nemesa Garg Reviewed-by: Jouni Högander Signed-off-by: Animesh Manna Link: https://patch.msgid.link/20260818095149.2172935-1-nemesa.garg@intel.com (cherry picked from commit 600a7c9d40e5e0c5544f42d1c9592c8d15224dc0) Signed-off-by: Jani Nikula commit 1d79c50e2eeae42b8aad7b5d4d0fe57027174e8a Author: Suraj Kandpal Date: Tue Aug 11 23:28:44 2026 +0530 drm/i915/lt_phy: program DDI_CLK_VALFREQ with DDI clock frequency DDI_CLK_VALFREQ is programmed with the port clock, which for DP is the symbol clock computed assuming 8b/10b encoding (link_rate / 10). For DP 128b/132b (UHBR) rates and for HDMI FRL the port clock needs to be modified. DDI_CLK_VALFREQ does not have any functional impact on H/w, it only records the frequency S/w intends to set. Use intel_ddi_link_symbol_clock() to write the correct DDI clock in kHz Fixes: 5ec58d714935 ("drm/i915/lt_phy: Add .enable_clock hook on DDI") Signed-off-by: Suraj Kandpal Reviewed-by: Ankit Nautiyal Link: https://patch.msgid.link/20260811175844.2613721-4-suraj.kandpal@intel.com (cherry picked from commit eaed815ca3483c227e4ec80b86d1b3ce5c2508be) Signed-off-by: Jani Nikula commit 0cd42b346d13486f8f31c0846f9f2a9241e191c2 Author: Suraj Kandpal Date: Tue Aug 11 23:28:43 2026 +0530 drm/i915/cx0: program DDI_CLK_VALFREQ with DDI clock frequency DDI_CLK_VALFREQ is programmed with the port clock, which for DP is the symbol clock computed assuming 8b/10b encoding (link_rate / 10). For DP 128b/132b (UHBR) rates and for HDMI FRL the port clock needs to be modfied. DDI_CLK_VALFREQ does not have any functional impact on H/w, it only records the frequency S/w intends to set. Use intel_ddi_link_symbol_clock() to write the correct DDI clock in kHz. Fixes: 51390cc0e00a ("drm/i915/mtl: Add Support for C10 PHY message bus and pll programming") Fixes: 73fc3abcb797 ("drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll") Signed-off-by: Suraj Kandpal Reviewed-by: Ankit Nautiyal Link: https://patch.msgid.link/20260811175844.2613721-3-suraj.kandpal@intel.com (cherry picked from commit 9ac3ee6c0f92cd09893bd442964fb6b0d6813b5e) Signed-off-by: Jani Nikula commit 900f48940abcb5294dac8f1b5335cdc562798734 Author: Suraj Kandpal Date: Tue Aug 11 23:28:42 2026 +0530 drm/i915/ddi: add helper to compute DDI clock frequency Add intel_ddi_link_symbol_clock() to return the DDI clock frequency for a given port clock: DP 8b/10b : rate DP 128b/132b (UHBR) : (10 / 32) * rate HDMI FRL : (10 / 18) * rate HDMI TMDS : rate The DP case reuses intel_dp_link_symbol_clock(). This will help in upcoming commits to decide value to be written in DDI_CLK_VALFREQ. Signed-off-by: Suraj Kandpal Reviewed-by: Ankit Nautiyal Link: https://patch.msgid.link/20260811175844.2613721-2-suraj.kandpal@intel.com (cherry picked from commit 5abc20e39dd074e8696387ca6871d6e432baf0cd) Signed-off-by: Jani Nikula commit 9fca7779ad18538188d640b1fdcfea924459542c Author: Abel Vesa Date: Wed Aug 19 08:55:08 2026 +0300 Revert "pmdomain: qcom: rpmhpd: Add missing MXC and MMCX power domains for Eliza" This reverts commit b48a0a0a76ccecec60f0568e2af4d89994b08bec, which wrongfully added the MXC and MMCX power domains on Eliza. Even though they are indeed available in cmd-db, which has been the source of information for adding these two, at hardware level they are not actually wired up. Therefore they need to be dropped. Fixes: b48a0a0a76cc ("pmdomain: qcom: rpmhpd: Add missing MXC and MMCX power domains for Eliza") Signed-off-by: Abel Vesa Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson commit ff44dfb03a293bf30e31f98772a1dd316a6071d1 Author: Arthur Gautier Date: Mon Aug 31 12:04:48 2026 +0300 xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.] Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer") Cc: stable@vger.kernel.org Suggested-by: Michal Pecio Signed-off-by: Arthur Gautier Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260831090448.95644-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 05506a76f13a279a204b6f9b89b8352b646e54d3 Author: Michal Pecio Date: Mon Aug 31 12:04:47 2026 +0300 usb: xhci: Fix isochronous scheduling regression An isoc URB without URB_ISO_ASAP should be scheduled immediately after the previous one, unless it's the first submission or prior URBs have completed without resubmitting and the endpoint became idle. An HCD_BH driver must consider URBs pending completion in the BH queue in addition to its own queue. Regrettably, core doesn't provide much information, we can only know if we are being called by completion now. This issue is as old as HCD_BH, affects ehci-hcd too and has no known reproducible impact, as drivers generally resubmit from completion. A recent patch tried to address it by looking at xHCI HW state instead. Obviously, HW has no knowledge of the BH giveback queue either, and the whole solution amounts to testing whether prior URBs have been unlinked instead of completing normally - then a new stream is assumed. This leads to false negatives when a driver simply allows the endpoint to empty out and begins a new stream. New URBs are scheduled into the past and promptly fail with -EXDEV status, causing data loss and worse, because drivers get confused by premature completion, particularly when multiple endpoints are started at once and required to stay in sync. snd-usb-audio underruns the OUT endpoint when userspace fails to supply playback data in time. If this is detected in duplex mode, IN URBs are unlinked and both streams restarted. OUT underruns again before IN even begins, another recovery is attempted and the cycle repeats. Fix this by using the best criteria we can muster, taken from ehci-hcd. This brings false negative rate back to zero and false positive rate to less than ever before in xhci-hcd. Traditional logic was equivalent to: if (list_empty(&ep_ring->td_list) || GET_EP_CTX_STATE(ep_ctx) != EP_STATE_RUNNING) // consider this URB a new stream While free of false negatives, it had easily avoidable false positives: * no check for completion in progress when the list is empty * the ep_ctx check doesn't make up for it at all, but it adds a race - EP state can remain "stopped" for a while after the first submission [mn: add debug message in possible false positive case where driver might incorrectly assume new stream starts mid stream just because td list is empty (URB enqueue is late), and workqueue isn't processing URB completions for this endpoint at the moment] Link: https://lore.kernel.org/linux-usb/20260813005635.34750f8c.michal.pecio@gmail.com/ Fixes: add8469b3e00 ("xhci: fix frame id calculation and checks for isoc URBs") Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260831090448.95644-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 045b5bef916d1cb1a52cb6aa68f78fd8b1235cef Author: Chen-Yu Tsai Date: Mon Aug 31 12:04:46 2026 +0300 usb: xhci: Fix HCS_ERST_MAX conversion This fixes one broken line in commit 6d45e9556d4a ("usb: xhci: standardize multi bit-field macros") included in 7.3-rc1 kernel HCS_ERST_MAX holds power of 2 value for maximum number of segments. In the culprit commit, this was incorrectly converted to "shift up 2". On hardware where this field is zero, this results in xhci_alloc_erst() calling dma_alloc_coherent() with size = 0, leading to a horrible splat and non-usable XHCI. Revert the shift-up-2 to the BIT() macro. Fixes: 6d45e9556d4a ("usb: xhci: standardize multi bit-field macros") Cc: Niklas Neronin Signed-off-by: Chen-Yu Tsai Signed-off-by: Mathias Nyman Tested-by: Pierre-David Belanger Link: https://patch.msgid.link/20260831090448.95644-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 6463655ab2946d13d2ec5efe04a5c2bf9d675f01 Author: Chaitanya Kumar Borah Date: Thu Aug 6 13:18:19 2026 +0530 drm/i915/dp_mst: Remove duplicate intel_pfit_compute_config() call mst_stream_compute_config() called intel_pfit_compute_config() twice in a row. commit 5ce9ac1531b8 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter") was erroneously cherry-picked to the fixes tree while commit ca97f5546f19 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter") was already in there. Drop the redundant duplicate call. Cc: Rodrigo Vivi Cc: Ville Syrjälä Cc: Nemesa Garg Cc: Jani Nikula Fixes: 5ce9ac1531b8 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter") Signed-off-by: Chaitanya Kumar Borah Reviewed-by: Nemesa Garg Link: https://patch.msgid.link/20260806074819.2631970-1-chaitanya.kumar.borah@intel.com Signed-off-by: Rodrigo Vivi [Rodrigo: adjusted commit message] (cherry picked from commit ea9f3470d33602fb776ea55443467baacf66f23a) Signed-off-by: Jani Nikula commit 1376afc7660bad2a1a5ee0876898312a486cf8bd Author: Kiran Kumar K Date: Tue Aug 25 10:47:25 2026 +0530 octeontx2-af: fix CN20K default MCAM rule removal on port cleanup npc_mcam_free_all_entries() disables every MCAM entry mapped to a port before freeing it. On CN20K, that also disables the default broadcast, multicast, promiscuous, and unicast rules, which causes packet drops when all rules are removed per port. Only disable and free non-default entries. Leave CN20K default rules enabled when freeing the remaining port entries. Fixes: 013717353c03 ("octeontx2-af: npc: cn20k: Tear down default MCAM rules explicitly on free") Signed-off-by: Kiran Kumar K Signed-off-by: Ratheesh Kannoth Signed-off-by: David S. Miller commit c8329cb590df4a8b3a4e878d289d4b17824db8d1 Author: Randy Dunlap Date: Sun Aug 30 20:19:53 2026 -0700 dma-buf: fix some kernel-doc warnings - drop Excess description of @lock from kernel-doc - add missing function/macro short descriptions WARNING: include/linux/dma-fence-array.h:47 Excess struct member 'lock' description in 'dma_fence_array' WARNING: include/linux/dma-fence-chain.h:48 Excess struct member 'lock' description in 'dma_fence_chain' Warning: include/linux/dma-fence-chain.h:82 missing initial short description on line: * dma_fence_chain_alloc Warning: include/linux/dma-fence-chain.h:94 missing initial short description on line: * dma_fence_chain_free Fixes: 5943243914b9 ("dma-buf: use inline lock for the dma-fence-array") Fixes: a408c0ca0c41 ("dma-buf: use inline lock for the dma-fence-chain") Signed-off-by: Randy Dunlap Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260831031956.3410813-1-rdunlap@infradead.org commit 5a88f78df753993469dab4d1831f8fb4256a9468 Author: Cen Zhang (Microsoft) Date: Fri Aug 14 00:09:44 2026 -0400 reboot: fix cad_pid use-after-free race cad_pid is a single kernel-wide struct pid pointer. proc_do_cad_pid() reads it and passes it to pid_vnr() without protecting the lifetime of the referenced struct pid. A concurrent writer can replace cad_pid and drop the final reference to the old struct pid after the reader has loaded the pointer but before pid_vnr() has finished dereferencing it, causing a use-after-free. kill_cad_pid() has the same lifetime race when it passes cad_pid to kill_pid(). At the time this issue was reported, an unprivileged user could reach the sysctl through user and PID namespaces because cad_pid was registered in pid_table[]. Moving cad_pid back to the global reboot sysctl table corrected that namespace and permission mismatch, but did not fix the underlying lifetime race. Fix this by treating cad_pid as an RCU-protected pointer at both read sites and by waiting for a grace period before dropping the old reference on the write side. call_rcu(&old_pid->rcu, ...) cannot be used here because free_pid() also queues pid->rcu; queueing the same rcu_head twice can corrupt the RCU callback list. Original KASAN crash stack: kernel/pid.c:545 pid_nr_ns() # reads freed pid->level kernel/pid.c:556 pid_vnr() # calls pid_nr_ns() kernel/pid.c:775 proc_do_cad_pid() # calls pid_vnr(cad_pid) Fixes: 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") Reported-by: AutonomousCodeSecurity@microsoft.com Closes: https://lore.kernel.org/all/20260717210143.4734-1-blbllhy@gmail.com/ Link: https://lore.kernel.org/all/alz5ZYLE4kaq_v2P@redhat.com/ Link: https://lore.kernel.org/all/al4ICz9biJKtdZc4@redhat.com/ Suggested-by: Mateusz Guzik Suggested-by: Bradley Morgan Suggested-by: Oleg Nesterov Suggested-by: Eric W. Biederman Suggested-by: Pavel Tikhomirov Cc: stable@vger.kernel.org Signed-off-by: Cen Zhang (Microsoft) Link: https://patch.msgid.link/20260814040944.16561-1-blbllhy@gmail.com Reviewed-by: Bradley Morgan Reviewed-by: Oleg Nesterov Reviewed-by: Pavel Tikhomirov Signed-off-by: Christian Brauner (Amutable) commit 9b110a9dcecc59516c77cb3c0caf1f492f75df2d Author: Yilin Zhang Date: Mon Aug 31 12:55:06 2026 +0800 ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation with an mmap_count check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: snd_pcm_sync_stop(), constraint refinement and do_free_pages() all happen in between. snd_pcm_mmap_data(), on the other hand, takes no lock at all: it validates against the old buffer's state and dma_bytes, remaps its pages into the VMA, and only then increments mmap_count. A concurrent mmap() can therefore slip in between the check and the free. remap_pfn_range() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent do_free_pages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation. Make snd_pcm_mmap_data() participate in the buffer-access scheme introduced for hw_params/hw_free: acquire runtime->buffer_accessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave. A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request. Reported-by: Kimi Security Team Fixes: 92ee3c60ec9f ("ALSA: pcm: Fix races among concurrent hw_params and hw_free calls") Signed-off-by: Yilin Zhang Link: https://patch.msgid.link/20260831045506.889070-1-yilinzhang@moonshot.ai Signed-off-by: Takashi Iwai commit 33abb7491e89285a41565670945293dda841afc4 Author: Runyu Xiao Date: Sun Aug 30 14:34:11 2026 +0800 ALSA: harmony: initialize locks before requesting IRQ snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260830063411.2215691-1-runyu.xiao@seu.edu.cn Signed-off-by: Takashi Iwai commit a565d82392e2240e6b2b25e2118e8617efa9fe74 Author: Riku Matsumura Date: Sun Aug 30 09:00:08 2026 +0900 ALSA: hda/realtek: Add quirk for VAIO VJS131 The VAIO VJS131 with an ALC233 codec incorrectly selects the headset microphone when no headset is connected. Add a PCI SSID quirk for 1d19:0006 to apply ALC233_FIXUP_ASUS_MIC_NO_PRESENCE, which configures pin 0x19 as a headset microphone without its own jack detection. Signed-off-by: Riku Matsumura Link: https://patch.msgid.link/20260830000008.22371-1-rick197.3@icloud.com Signed-off-by: Takashi Iwai commit acac7b5e07349a9d10d78873afb4b93cd1dc721f Author: Takashi Iwai Date: Fri Aug 28 13:55:39 2026 +0200 ALSA: pcm: Fix race between non-atomic ops and trigger-start We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running. Reported-by: syzbot+225231fce6755d40d078@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a8f0de8.1d9ded08.62e62.00b5.GAE@google.com Cc: Link: https://patch.msgid.link/20260828115542.3999-1-tiwai@suse.de Signed-off-by: Takashi Iwai commit 34e08ad3a8da293009a4bc8f2f6738bd66b18e0d Author: Zhang Heng Date: Fri Aug 28 18:17:04 2026 +0800 ALSA: hda/realtek: Add quirk for Acer Predator PHN16-72 The Acer Predator PHN16-72 (subsystem ID 1025:1731) uses a Realtek ALC245 codec. The PCI SSID and HDA codec SSID are both 0x10251731, as confirmed in the system's ALSA diagnostic report. Apply ALC2XX_FIXUP_HEADSET_MIC to enable the headset microphone. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221811 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260828101704.354406-2-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai commit 616fd322e0245f3e62541aa39856f75f1b1aa604 Author: Zhang Heng Date: Fri Aug 28 18:17:03 2026 +0800 ALSA: hda/realtek: Add quirk for Lenovo Yoga Slim 9 14ILL10 The Lenovo Yoga Slim 9 14ILL10 (83CX) uses ALC287 with CS35L56 amplifiers. Without a matching SSID entry the bass speakers stay silent. Add PCI SSID 17aa:380b (codec SSID 17aa:3905) to apply ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221902 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260828101704.354406-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai commit 7b9b202f154488d06d8de89bfb17f2b68b1ed4cc Author: feng liu Date: Fri Aug 28 14:34:56 2026 +0800 ALSA: hda/conexant:Fix abnormal Mic/Speaker functionality on SN6140 after S3 wake-up Inside cx_codec_ops.set_power_state, implement a 1‑second delay after resuming from the S3 state before sending the power command to the codec AFG, thereby preventing potential transmission failures. Signed-off-by: feng liu Link: https://patch.msgid.link/20260828063456.1368-1-feng.liu@senaryTech.com Signed-off-by: Takashi Iwai commit 3884c9b120e26dad7f92317dea404a1843a17d83 Merge: b12e20c6ac156a a67632c8c2688d Author: Christian Brauner Date: Mon Aug 31 09:54:38 2026 +0200 Merge patch series "netfs, cachefiles: Miscellaneous fixes" David Howells says: Here are some miscellaneous fixes for netfslib and one for cachefiles: The first six are all in unbuffered/DIO write: (1) Fix an uninitialised return value from netfs_unbuffered_write(). (2) Fix the normal error return, preferring partial transfer size over request error over immediate error (e.g. EINTR). (3) Fix the async error return, preferring partial transfer size over error. (4) Fix the update of i_size on partial transfer ending in an error. (5) Fix a subrequest leak in an error path. (6) Fix the code to handle subrequest allocation failure. Then there's: (7) Fix synchronisation issues with using a progressive rolling buffer for readahead by fetching everything into it upfront so that the issues don't arise. Dropping the refs so acquired is deferred until after I/O is begun. (8) Change the marking of folios to be copied to the cache to be done whilst subreqs are being issued rather than at the time they're collected. Whilst this is not strictly a fix, it means that the collector thread doesn't need to try and keep track of that, which means that delayed progress reporting will not be a problem in patch (9). (9) Fix read progress reporting to avoid 64-bit tearing on a 32-bit machine. This has been modified from the previous submission as part of a different series to take account of a sashiko reported issue[1]. (10) Fix a potential UAF/KASAN warning reported by sashiko[1] in cachefiles in which the coherency data buffer is cast to a __be64* and dereferenced in a tracepoint - even though it might not be at least that large (or aligned). * patches from https://patch.msgid.link/20260827134304.2075713-1-dhowells@redhat.com: cachefiles: Fix potential UAF/KASAN warning netfs: Fix read progress reporting netfs: Mark folios with COPY_TO_CACHE whilst issuing subreqs netfs: Fix readahead synchronisation issues by loading all folios upfront netfs: break unbuffered write when netfs_alloc_subrequest() fails netfs: Fix subreq ref leak netfs: Fix i_size update for partial transfer netfs: Fix error vs transferred passed to ->ki_complete() netfs: Fix unbuffered/DIO write partial transfer error return netfs: Fix uninitialized return value in netfs_unbuffered_write() Link: https://patch.msgid.link/20260827134304.2075713-1-dhowells@redhat.com Signed-off-by: Christian Brauner (Amutable) commit a67632c8c2688d6e0091529bcefe54bc5ee80e9b Author: David Howells Date: Thu Aug 27 14:43:03 2026 +0100 cachefiles: Fix potential UAF/KASAN warning Currently, trace_cachefiles_coherency() is being passed a pointer to a __be64 lain over the coherency data in struct cachefiles_xattr so that it can display the first 8 bytes. However, the data is of variable length and could even be 0 bytes. This could lead to a UAF or KASAN warning. Fix this by making sure the buffer has room for at least 8 bytes and that those 8 bytes are pre-cleared. Further, those bytes are not 8-byte aligned, so fix the tracepoint to extract the data as four 2-byte words (they are 2-byte aligned) and reassemble the __be64. The compiler will convert this into a single 8-byte load where the CPU supports it. Fixes: 229105e5cfd9 ("cachefiles: Add auxiliary data trace") Link: https://sashiko.dev/#/patchset/20260810144746.574036-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-11-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit e00827a4d0cfebf8d78dfd0a9a024237f57c9273 Author: David Howells Date: Thu Aug 27 14:43:02 2026 +0100 netfs: Fix read progress reporting For really big read RPC ops that span multiple folios, netfslib allows the filesystem to give progress notifications to wake up the collector thread to do a collection of folios that have now been fetched, even if the RPC is still ongoing, thereby allowing the application to make progress. This works by taking the current rreq->cleaned_to value (which indicates which folios have been unlocked) and adding the stashed size of the next folio to it. cleaned_to, however, is subject to 64-bit tearing on a 32-bit arch. Fix this by stashing the next progress notification point as a size_t (which won't tear) to be added to rreq->start (which won't change), with the collector thread calculating that from cleaned_to plus the next folio size. Further, however, if the folios are small, the collector thread gets constantly woken up - which has a negative performance impact on the system. Fix that too by setting a minimum trigger of 256KiB or the size of the folio at the front of the queue, whichever is larger. Note that this has an issue that different subreqs have different need-to-be-cached properties; this is solved by a preceding patch that marks the property on the folios whilst issuing subreqs rather than when collecting them. Also, make sure rreq->cleaned_to is initialised up front, along with rreq->collected_to and stream->collected_to. Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") Link: https://sashiko.dev/#/patchset/20260804100224.2748935-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-10-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit 533203c4183123dad8ffecd694e7573a0ccd0da0 Author: David Howells Date: Thu Aug 27 14:43:01 2026 +0100 netfs: Mark folios with COPY_TO_CACHE whilst issuing subreqs Mark folios with NETFS_FOLIO_COPY_TO_CACHE whilst issuing subreqs rather than when collecting them. This means that the collector thread doesn't have to try and keep track of which subreqs contribute to which folios - and thus which folios will need to be copied to the cache because at least one byte wasn't in the cache. Instead, this is marked on the folios up front and the collector need only consider the folios. For PG_private_2-using filesystems, PG_private_2 is set instead of NETFS_FOLIO_COPY_TO_CACHE, but otherwise it works the same. The NETFS_RREQ_COPY_TO_CACHE is replaced with NETFS_RREQ_CANCEL_CACHING, which is now set if caching fails somewhere, thereby causing the collection thread to cancel the copy-to-cache marks on the remaining folios. Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-9-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara (Red Hat) cc: Matthew Wilcox cc: netfs@lists.linux.dev cc: linux-mm@kvack.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit fed0b33e6c584986ba70018ec9f9787a98216e64 Author: David Howells Date: Thu Aug 27 14:43:00 2026 +0100 netfs: Fix readahead synchronisation issues by loading all folios upfront There are some synchronisation issues that derive from the app thread adding more folios to the rolling buffer whilst the collector thread is looking at them or trying to clear them, such as determining the setting of front_folio_order when the next folio hasn't been added yet, The reason for the rolling buffer approach is that loading the buffer upfront and then dropping all the refs just acquired is quite a slow operation, and loading progressively allows some of the cost to be deferred until after at least some of the I/O is started. Instead, a better way is to load all the folios into the rolling buffer upfront - and then drop the refs later, once the I/O is in progress. (Even better would be for the refs not to be there at all.) Fix this by changing the rolling buffer loader to load all the folios selected by the VM for readahead upfront into the folio queue. The folio queue is allocated a batch worth at a time as we don't know how many folios are involved (the readahead_control struct, alas, has a page count, not a folio count). The folio refs acquired from readahead are then dropped in bulk once the first subrequest is dispatched as it's quite a slow operation. The collector waits for NETFS_RREQ_NEED_PUT_RA_REFS to be cleared so that it doesn't unlock folios before the xarray has been scanned for them. This simplifies the buffer handling later and isn't noticeably slower as the xarray doesn't need to be modified and the folios are all already pre-locked. Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Link: https://sashiko.dev/#/patchset/20260824120224.504575-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-8-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara (Red Hat) cc: Matthew Wilcox cc: netfs@lists.linux.dev cc: linux-mm@kvack.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit 8fb45a934661419c04a44d4cfea1e0df7dcf2805 Author: Edward Adam Davis Date: Thu Aug 27 14:42:59 2026 +0100 netfs: break unbuffered write when netfs_alloc_subrequest() fails syzbot reported a null-ptr-deref below [1] following a fault injection in netfs_alloc_subrequest(). [0] When netfs_alloc_subrequest() fails, subreq is NULL. Later, netfs_prepare_write() tries to initialize members of subreq(e.g., source), the issue in [1] is triggered. Let's handle the error of netfs_prepare_write() properly. [0] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 Call Trace: netfs_alloc_subrequest+0x116/0x3f0 netfs_prepare_write+0x76/0x7b0 netfs_unbuffered_write+0x75c/0x2020 netfs_unbuffered_write_iter_locked+0x7d6/0xa80 netfs_unbuffered_write_iter+0x442/0x720 v9fs_file_write_iter+0xbf/0x100 vfs_write+0x6ac/0x1050 [1] KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af] RIP: 0010:netfs_prepare_write+0xbc/0x7b0 fs/netfs/write_issue.c:173 Call Trace: netfs_unbuffered_write+0x75c/0x2020 fs/netfs/direct_write.c:111 netfs_unbuffered_write_iter_locked+0x7d6/0xa80 fs/netfs/direct_write.c:290 netfs_unbuffered_write_iter+0x442/0x720 fs/netfs/direct_write.c:382 v9fs_file_write_iter+0xbf/0x100 fs/9p/vfs_file.c:409 new_sync_write fs/read_write.c:595 [inline] Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Reported-by: syzbot+6a13fc77eb6f0802be2d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6a13fc77eb6f0802be2d Tested-by: syzbot+6a13fc77eb6f0802be2d@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-7-dhowells@redhat.com Acked-by: Paulo Alcantara Signed-off-by: Christian Brauner (Amutable) commit 3c30087e27598d9d359763e8be9bd3017fe08348 Author: David Howells Date: Thu Aug 27 14:42:58 2026 +0100 netfs: Fix subreq ref leak Fix a subrequest ref leak in netfs_unbuffered_write() in the event that subreq->io_iter ends up zero length during preparation. Fixes: a0b4c7a49137e ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Link: https://sashiko.dev/#/patchset/20260824120224.504575-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-6-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit 741416a8003b77e636dafade408f808d96ac3f47 Author: David Howells Date: Thu Aug 27 14:42:57 2026 +0100 netfs: Fix i_size update for partial transfer Fix netfs_unbuffered_write_done() to pass the amount written to netfs_update_i_size() in the event of a partial transfer that ends in an error. That said, it might be better for the filesystem to mark the inode data as invalid and recheck it in case something like a network error occurred that prevented the reply from the server from being received. Fixes: a0b4c7a49137e ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Link: https://sashiko.dev/#/patchset/20260824120224.504575-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-5-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit 0bfe2571a6af653611860d0e24c4e4c83bae7a54 Author: David Howells Date: Thu Aug 27 14:42:56 2026 +0100 netfs: Fix error vs transferred passed to ->ki_complete() Fix netfs_unbuffered_write_done() to pass the amount written to ->ki_complete() rather than the error in the event of a partially complete transfer. Fixes: a0b4c7a49137e ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Link: https://sashiko.dev/#/patchset/20260824120224.504575-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-4-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit c753a33664e4e86246f7491a93d9a77c1a673b5d Author: David Howells Date: Thu Aug 27 14:42:55 2026 +0100 netfs: Fix unbuffered/DIO write partial transfer error return Fix unbuffered/DIO write to return the amount of data transferred in preference to an error if a partial transfer has been achieved, and to prefer an error stashed in the request over the one returned by netfs_unbuffered_write() (likely -EINTR or -ERESTARTSYS). Fixes: a0b4c7a49137e ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Link: https://sashiko.dev/#/patchset/20260824120224.504575-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-3-dhowells@redhat.com Acked-by: Paulo Alcantara cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) commit f18e8774f4d3137fa0a5fb8ffa83d59a719666d8 Author: Karl Mehltretter Date: Thu Aug 27 14:42:54 2026 +0100 netfs: Fix uninitialized return value in netfs_unbuffered_write() If preparation of the first subrequest fails, netfs_unbuffered_write() exits its loop before ret is initialized. The empty-iterator check can do the same. For synchronous writes, netfs_unbuffered_write_iter_locked() may then return an unrelated error instead of wreq->error. This is reachable through CIFS if cifs_prepare_write() fails to reopen the file or obtain credits. Initialize ret to 0 so the caller returns wreq->error if no data was written, or the number of bytes already written otherwise. Found with Clang's -Wconditional-uninitialized. Fixes: a0b4c7a49137e ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Cc: stable@vger.kernel.org Signed-off-by: Karl Mehltretter Signed-off-by: David Howells Link: https://patch.msgid.link/20260827134304.2075713-2-dhowells@redhat.com Acked-by: Paulo Alcantara Signed-off-by: Christian Brauner (Amutable) commit d476d5995c8a146b03e56eb60940a0ac3524a655 Author: Will Porter Date: Thu Aug 27 18:21:43 2026 -0500 ALSA: usb-audio: Guard FCP protocol transfers FCP meter and hwdep operations issue control transfers without preventing runtime suspend or disconnect. Protect the central request-and-response transport. One reference then covers the command, acknowledgment wait, and response. The initial step-zero request bypasses that transport. Hold an outer reference across the complete initialization sequence so the device stays active through step zero, notification-URB setup, and both initialization commands. The central transport keeps its guard for calls outside initialization; the existing active counter balances the nested calls. FCP has no private resume callback. Its suspend callback only removes the notification URB. Taking the initialization and transport guards under the existing protocol mutex causes no resume-side lock inversion. Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Will Porter Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260827232143.149197-7-mrwillporter@gmail.com commit 9d4ae593fc578f6c88ce48a8b974e306de159e99 Author: Will Porter Date: Thu Aug 27 18:21:42 2026 -0500 ALSA: usb-audio: Add PM guards to RME Digiface controls The RME Digiface status and register helpers issue vendor requests without preventing runtime suspend or disconnect. The volatile status controls can repeatedly reach these unguarded paths while userspace polls them. Protect both helpers with snd_usb_lock. All Digiface get and put callbacks then resume the device and hold the disconnect reference across their transfer. Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Will Porter Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260827232143.149197-6-mrwillporter@gmail.com commit de018804734757fcb7b16156b5fb297129f9ca99 Author: Will Porter Date: Thu Aug 27 18:21:41 2026 -0500 ALSA: usb-audio: Guard Scarlett2 protocol transfers Scarlett2 controls and hwdep operations reach the proprietary USB transport without preventing runtime suspend or disconnect. Protect the central request-and-response helper. One reference then covers the command, acknowledgment wait, and response. The runtime and system resume hook submits only the notification URB. It takes no protocol mutex. Thus, the transport guard does not invert the existing data_mutex or usb_mutex order. Keep the suspend-time config save on the unguarded helper because it runs inside the USB suspend callback. This change protects each USB transaction. It does not hold a runtime-PM reference across the asynchronous flash-erase interval. Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Will Porter Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260827232143.149197-5-mrwillporter@gmail.com commit 103da4a7bca6bc6ae263c5e4e3053fa166691731 Author: Will Porter Date: Thu Aug 27 18:21:40 2026 -0500 ALSA: usb-audio: Add PM guard to Scarlett meter reads The Scarlett Gen 1 meter callback reads the device without preventing runtime suspend or disconnect. The transfer can fail when userspace polls the volatile control after the device suspends. Hold snd_usb_lock across the meter request. This matches the guarded Forte and common mixer control paths in this file. Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Will Porter Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260827232143.149197-4-mrwillporter@gmail.com commit 9e6c9d7531de7c6da66431a54d3c89f9514da937 Author: Will Porter Date: Thu Aug 27 18:21:39 2026 -0500 ALSA: usb-audio: Add PM guards to US-16x08 transfers The TASCAM control helpers submit vendor requests without preventing runtime suspend or disconnect. This affects mixer writes and the volatile meter path. Protect both send and receive helpers with snd_usb_lock. Acquire the PM guard before chip->mutex in the receive path so autoresume cannot invert the mutex order. Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Will Porter Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260827232143.149197-3-mrwillporter@gmail.com commit 077304dfa7d1c641fbc10310c831ba8505887bd2 Author: Will Porter Date: Thu Aug 27 18:21:38 2026 -0500 ALSA: usb-audio: Add PM guard to Studio 1810c controls The Studio 1810c control callbacks issue vendor transfers without preventing runtime suspend or disconnect. A transfer attempted after runtime suspend can fail because the USB device cannot accept submissions. Take snd_usb_lock before the driver data and USB mutexes in both callbacks. This resumes the device before either the state read or control write. It also prevents disconnect cleanup from racing the complete operation. Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Will Porter Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260827232143.149197-2-mrwillporter@gmail.com commit b12e20c6ac156a307acdf0545432eb3b6cb41f8f Author: Ahmet Eray Karadag Date: Mon Dec 15 06:14:34 2025 +0300 adfs: fix memory leak in sb->s_fs_info Syzbot reported a memory leak in adfs during the mount process. The issue arises because the ownership of the allocated (struct adfs_sb_info) is transferred from the filesystem context to the superblock via sget_fc(). This function sets fc->s_fs_info to NULL after the transfer. The ADFS filesystem previously used the default kill_block_super for superblock destruction. This helper performs generic cleanup but does not free the private sb->s_fs_info data. Since fc->s_fs_info is set to NULL during the transfer, the standard context cleanup (adfs_free_fc) also skips freeing this memory. As a result, if the superblock is destroyed, the allocated struct adfs_sb_info is leaked. Fix this by implementing a custom .kill_sb callback (adfs_kill_sb) that explicitly frees sb->s_fs_info before invoking the generic kill_block_super. Reported-by: syzbot+1c70732df5fd4f0e4fbb@syzkaller.appspotmail.com Signed-off-by: Ahmet Eray Karadag Link: https://patch.msgid.link/20251215031433.182205-2-eraykrdg1@gmail.com Signed-off-by: Christian Brauner (Amutable) commit e04ffff543db06308a8100f6aa3a65aebcd9834c Author: Linmao Li Date: Tue Aug 18 17:59:29 2026 +0800 media: rppx1: bls: read the raw pattern from the PRE2 acquisition module rppx1_bls_swap_regs() gets the Bayer pattern from the acquisition module. The PRE1 path uses pre1.acq, but the PRE2 path mistakenly uses pre2.bls. The BLS module does not store a Bayer pattern, so PRE2 would read zero (RGGB) and map fixed black levels to the wrong colour registers. PRE2 is not started or dispatched yet, so the bug is currently latent. Read the pattern from pre2.acq, as the PRE1 path does, so that enabling PRE2 does not start out with the wrong register mapping. Signed-off-by: Linmao Li Reviewed-by: Niklas Söderlund Reviewed-by: Jacopo Mondi Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil commit a1530ef451f53b63dcf4a2805a5524b590a146ad Author: Linmao Li Date: Tue Aug 18 10:09:33 2026 +0800 media: rppx1: describe the MAIN_POST white balance gains block rppx1_ext_params_blocks_info[] is indexed by block type and is built with designated initialisers, so a block type without an entry is left as a zero-sized hole. RPPX1_PARAMS_BLOCK_TYPE_AWBG_POST is the only such hole: a block reporting that type and a size of zero passes v4l2_isp_params_validate_buffer(), which then has nothing to advance the walk with. Describe the block, so the array covers all block types the uAPI defines. The MAIN_POST white balance gains module is probed and started with the rest of the POST pipe, and RPPX1_PARAMS_MAX_SIZE already reserves room for all three white balance gains blocks. The block is not dispatched by rppx1_params(), in line with the other described blocks that have no users yet. Reviewed-by: Niklas Söderlund Reviewed-by: Jacopo Mondi Signed-off-by: Linmao Li Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil commit aadea57f532882d8bab444646863c7ef8a778ff1 Author: Wang Yan Date: Tue Aug 25 17:47:33 2026 +0800 perf powerpc-vpadtl: Fix raw_size of DTL samples In powerpc_vpadtl_sample(), raw_data of the synthetic sample points to a struct powerpc_vpadtl_entry (48 bytes), but raw_size is set to sizeof(record). record is a struct powerpc_vpadtl_entry pointer, so sizeof(record) is the size of the pointer (8 bytes on 64-bit) rather than the size of the record itself. As a result, consumers that bound their access to raw_data by raw_size only see or copy the first 8 bytes of each DTL entry instead of the full record. Use sizeof(*record) so that raw_size reflects the actual length of the raw data. Fixes: 8644834a482a ("perf powerpc: Process the DTL entries in queue and deliver samples") Signed-off-by: Wang Yan Reviewed-by: Athira Rajeev Reviewed-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim commit a5096d4927d1eb607d51a7342a7e7591a3838c19 Author: Sumeet Pawnikar Date: Sat Aug 29 19:19:24 2026 +0530 opp: Use %pe to print symbolic error name Replace PTR_ERR() and %ld with %pe and pass the original pointer directly to dev_dbg(), dev_warn(), dev_err() or pr_err(). The %pe format specifier prints a symbolic error name (e.g. -ENOMEM) when CONFIG_SYMBOLIC_ERRNAME is enabled, otherwise it falls back gracefully and prints the raw integer value. This makes error messages more readable without any functional change. Signed-off-by: Sumeet Pawnikar Signed-off-by: Viresh Kumar commit e11811a552252740bd396ec38378e9570ee16578 Author: Colin Ian King Date: Wed Aug 26 14:19:57 2026 +0100 OPP: of: Fix potential multiplication overflow when calculating freq The multiplication be32_to_cpup(val++) * 1000 is performed using 32 bit unsigned integers and hence uses a 32 bit multiplication; this will overflow if be32_to_cpup(val++) is greater than 4294967 (which is very unlikely at present). The result is assigned to an unsigned long (which is a 64 bit value on 64 bit systems), so fix this potential overflow by casting the first operand of the multiplication to an unsigned int. Fixes: b496dfbc94ab ("PM / OPP: Initialize OPP table from device tree") Signed-off-by: Colin Ian King Signed-off-by: Viresh Kumar commit ae9464c65e9d1ad4df4fed516cee9bca3bc614cc Author: Adrian Hunter Date: Tue Aug 25 09:23:45 2026 +0300 perf symbol: Do not use debug file as the binary type dso__load() sets the binary type of a DSO to the type of the first symbol source found. For a DSO with a separate debug file linked via .gnu-debuglink, that is DSO_BINARY_TYPE__DEBUGLINK, which makes dso__get_filename() return the name of the debug file instead of the file that was actually executed. Consumers that need to read instruction bytes, such as Intel PT decoding in 'perf script', then read from the debug file and produce wrong instructions. Prefer DSO_BINARY_TYPE__BUILD_ID_CACHE, and otherwise DSO_BINARY_TYPE__SYSTEM_PATH_DSO, over debug-only types, which restores the behaviour of using a file that contains the executed instructions. This is a workaround. Properly separating the binary file used for instructions from the file used for debug symbols is left for later. Example: Create a shared object with a separate .gnu_debuglink debug file. Note that 'objcopy --only-keep-debug' leaves .text as NOBITS, so instructions read from the debug file are zeros: # cat > foo.c << EOF unsigned long foo_work(unsigned long n) { unsigned long s = 0; for (unsigned long i = 0; i < n; i++) s = s * 31 + i; return s; } EOF # cat > main.c << EOF #include unsigned long foo_work(unsigned long n); int main(void) { printf("%lu\n", foo_work(1000)); return 0; } EOF # gcc -g -O2 -shared -fPIC -o libfoo.so foo.c # gcc -g -O2 -o main main.c -L. -lfoo -Wl,-rpath,'$ORIGIN' # objcopy --only-keep-debug libfoo.so libfoo.so.debug # objcopy --strip-debug libfoo.so # objcopy --add-gnu-debuglink=libfoo.so.debug libfoo.so # perf record -e intel_pt//u ./main Note that branch samples must be requested, because it is the resolving of the branch target symbol that causes dso__load() to be called, and hence the binary type to be set, before the decoder walks the code. With '--itrace=e' alone, nothing loads symbols for libfoo.so, the binary type is left as DSO_BINARY_TYPE__NOT_FOUND, the correct file is read anyway, and no errors are reported either way. Before: # perf.before script --itrace=be 2>&1 | grep "instruction trace error" instruction trace error type 1 time 2350.467489498 cpu 9 pid 75634 tid 75634 ip 0x77d48480718f code 6: Trace doesn't match instruction instruction trace error type 1 time 2350.467489832 cpu 9 pid 75634 tid 75634 ip 0x77d484807341 code 6: Trace doesn't match instruction instruction trace error type 1 time 2350.467496412 cpu 9 pid 75634 tid 75634 ip 0x5b4de37a8074 code 6: Trace doesn't match instruction instruction trace error type 1 time 2350.467593393 cpu 9 pid 75634 tid 75634 ip 0x77d4848070d0 code 6: Trace doesn't match instruction instruction trace error type 1 time 2350.467593954 cpu 9 pid 75634 tid 75634 ip 0x77d4848075a8 code 6: Trace doesn't match instruction instruction trace error type 1 time 2350.467595728 cpu 9 pid 75634 tid 75634 ip 0x77d4848324de code 6: Trace doesn't match instruction 6 instruction trace errors After: # perf script --itrace=be 2>&1 | grep "instruction trace error" # Fixes: 5363c306787c8 ("perf symbol: Set binary_type of dso when loading") Reported-by: Todd Lipcon Closes: https://lore.kernel.org/all/CAGH6UiG=RJLqBU3kLu9XJciPyPO1HZkbAPERguVUMRuWQgqf=A@mail.gmail.com/ Signed-off-by: Adrian Hunter Signed-off-by: Namhyung Kim commit 9f8139c6145cf17d690d6c414d43b4c0bef632fb Author: Zhichen Wang Date: Tue Aug 25 21:50:54 2026 +0800 virt: vmgenid: set driver_data before registering notification handlers Both probe paths register their notification handler before assigning driver_data, which the handler dereferences. In the devicetree path, the notification IRQ can fire as soon as devm_request_irq() registers the handler: the interrupt may already be pending at probe time, for example when a VMM injects the generation-changed notification while restoring a guest from a snapshot that was taken before the driver had probed (Firecracker does exactly this on snapshot restore). The IRQ is also requested with IRQF_SHARED, so another device sharing the line can trigger the handler just as early. The handler then calls vmgenid_notify(), which dereferences the still-NULL driver_data and panics: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.38+ #1 PREEMPT(none) Hardware name: linux,dummy-virt (DT) pc : vmgenid_notify.isra.0+0x24/0x8c lr : vmgenid_of_irq_handler+0x14/0x34 Call trace: vmgenid_notify.isra.0+0x24/0x8c (P) vmgenid_of_irq_handler+0x14/0x34 __handle_irq_event_percpu+0x44/0x1bc handle_irq_event+0x4c/0xb4 handle_fasteoi_irq+0xf8/0x1f8 The ACPI path has the same ordering problem: the handler is installed with acpi_install_notify_handler() before driver_data is assigned. ACPI notifications are dispatched asynchronously from a workqueue, so the window is narrow, but a notification arriving between the two calls hits the same NULL dereference. Assign driver_data before registering the handlers. The state is fully initialized at that point, so the handlers are safe to run. Should registration fail, the probe error path leaves no dangling pointer behind: the driver core clears driver_data in device_unbind_cleanup(). Fixes: 7b1bcd6b50a6 ("virt: vmgenid: add support for devicetree bindings") Fixes: e07606713a90 ("virt: vmgenid: change implementation to use a platform driver") Cc: stable@vger.kernel.org Signed-off-by: Zhichen Wang Signed-off-by: Jason A. Donenfeld commit 1b48c13075829ee4961feeabd816dac1c9111959 Author: Vitaly Kuznetsov Date: Mon Dec 22 15:46:46 2025 +0100 virt: vmgenid: remap memory as decrypted It was found that AWS SEV-SNP enabled instances are not able to boot with commit 81256a50aa0f ("x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default") applied and the reason seems to be the vmgenid device which requires unencrypted writeable memory. A similar problem was previously fixed in DRM with commit 7dfede7d7edd ("drm/vmwgfx: Fix guests running with TDX/SEV"). Note, trusting vmgenid device in a Confidential VM is questionable: the malicious host may intentionally avoid notifying the guest when a copy is created. Fixes: 81256a50aa0f ("x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default") Signed-off-by: Vitaly Kuznetsov Cc: stable@vger.kernel.org # 6.15+ Signed-off-by: Jason A. Donenfeld commit 72bd92bd8190d7869ecb462649ca40f297822a33 Author: Jason Andryuk Date: Tue Aug 25 17:48:02 2026 -0400 x86/amd_node: Avoid divide by zero on virtualized systems On a virtualized system, the number of nodes does not have a relationship to the number of roots. A Xen PVH dom0 can calculate roots_per_node as 0, which crashes with a divide by zero in: if (count++ % roots_per_node) because the underlying topology code on Xen ends up making num_nodes 2 and num_roots 1 and the integer division result is 0. The issue is seen with Xen, but it could affect other systems. Set roots_per_node to 1 in this case. Print a firmware bug when this is performed for non-virtualized systems. [ bp: Massage commit message. ] Fixes: 0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching") Suggested-by: Borislav Petkov Signed-off-by: Jason Andryuk Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Yazen Ghannam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260825214805.39148-2-jason.andryuk@amd.com commit b1c3c51b0916f7d1b2dceffc0e48abe185958825 Author: Jean-Baptiste Maneyrol Date: Mon Aug 24 17:16:58 2026 +0200 iio: inv_sensors: fix estimated value larger than interrupt timestamp When interrupt timestamp interval is not valid, we use an estimated value that can in rare case be bigger than the interrupt timestamp. This is obviously wrong, so better use interrupt timestamp in this case. Fixes: 8f4b627656fa ("iio: inv_sensors: better timestamp alignment when using watermark") Cc: stable@vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol Signed-off-by: Jonathan Cameron commit 95e4eb426b4bd666fa2f37886c0ddf74a0cc6167 Author: Pengpeng Hou Date: Sun Aug 30 21:42:27 2026 +0800 iio: adc: aspeed: propagate reset deassert errors aspeed_adc_probe() continues to register ADC resources after deasserting the shared reset, even if the reset controller reports a failure. A failed deassertion leaves the hardware unavailable, so stop probing before installing the cleanup action and enabling the ADC. Fixes: edf7550a1f93 ("iio: adc: aspeed: Deassert reset in probe") Signed-off-by: Pengpeng Hou Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit 0d0ffbcc92e30a8d656ad76a6e278fa3400fed85 Author: Michael Hennerich Date: Fri Aug 28 11:46:55 2026 +0100 iio: buffer-dmaengine: fix sg entry iteration when building dma_vecs iio_dmaengine_buffer_submit_block() counts scatterlist entries with sg_nents_for_len(), which walks the CPU-side lengths (sg->length), but then consumes the DMA-side fields (sg_dma_address()/sg_dma_len()). After dma_map_sgtable() the two views may differ: an IOMMU can coalesce the mapping so that only the first sgt->nents entries carry valid DMA addresses, with nents < orig_nents. On x86 with an IOMMU enabled, a DMABUF block backed by two 1 MiB system-heap chunks maps to a single 2 MiB IOVA range. The CPU-side count is 2, so the loop reads one entry past the mapped set and emits a garbage vec ({addr = ~0, len = 0}). The DMA engine driver rejects the vec array (prep returns NULL), the fence is signalled with -ENOMEM, which a userspace poller cannot observe, and the block is left in ACTIVE state so every further enqueue of it fails with -EBUSY. The visible symptom is a stream of zero-filled blocks followed by a wedged buffer. Platforms without an IOMMU never hit this because nents == orig_nents. Size the vec array with sgt->nents, i.e. the DMA-mapped view, and stop the fill loop once bytes_used is covered - which is allowed to be smaller than the block size - passing the number of vecs actually filled to dmaengine_prep_peripheral_dma_vec(). One vec per mapped entry is enough since coalescing can only ever reduce the number of entries. A single mapped entry longer than the device's maximum segment size would need more than one, but the DMA API already assumes no single segment exceeds it [1], and splitting a vec down to the hardware descriptor size is the DMA engine driver's job - which both current .device_prep_peripheral_dma_vec() implementations do. [1]: commit ab2cbeb0ed30 ("iommu/dma: Handle SG length overflow better") Assisted-by: Claude:claude-fable-5 Fixes: 7a86d469983a ("iio: buffer-dmaengine: Support new DMABUF based userspace API") Signed-off-by: Michael Hennerich Signed-off-by: Nuno Sá Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit 4daa9ca557b4b98ae1ad38a6d1deaa3e31eb8edf Author: Cong Nguyen Date: Fri Aug 28 17:59:09 2026 +0700 iio: proximity: pulsedlight: fix iio_device left registered on PM setup failure pm_runtime_set_active() failing in probe() jumps to error_unreg_buffer, which only calls iio_triggered_buffer_cleanup() -- it does not undo the iio_device_register() that already succeeded a few lines above. probe() then returns the error, the devm-managed indio_dev is freed, but the iio core still has it registered: the sysfs/chardev nodes stay live and point at freed memory. Add an error_unreg_dev label that unregisters the iio device before falling through to the existing buffer cleanup, mirroring the teardown order already used in lidar_remove(). Fixes: 4ac4e086fd8c ("iio: pulsedlight-lidar-lite: add runtime PM") Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit 2a57b9246cecd5dd797a42eb310d6c8816f26d9e Author: Fan Wu Date: Thu Aug 6 14:25:02 2026 +0000 iio: trigger: cancel reenable_work before freeing trigger iio_trigger_notify_done_atomic() defers ->reenable() into trig->reenable_work on the system workqueue, and the worker dereferences the owning trigger through container_of(). Nothing cancels this work before iio_trig_release() frees the trigger, so a worker armed by the last in-flight IRQ can outlive the free and touch freed memory. Cancel it at the top of iio_trig_release(), which every free path reaches through the device core's final put_device(). Found by an in-house static analysis tool. Fixes: 9020ef659885 ("iio: trigger: Fix a scheduling whilst atomic issue seen on tsc2046") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jonathan Cameron commit 2093236e886ad9446ec3285ba520e024dd1464e1 Author: Salah Triki Date: Wed Aug 19 18:51:19 2026 +0100 iio: frequency: admv1013: fix wrong channel field used in admv1013_read_raw() admv1013_read_raw() switches on chan->channel instead of chan->channel2 when handling IIO_CHAN_INFO_CALIBBIAS. The channel field only ever holds 0 or 1 (see ADMV1013_CHAN_CALIB()), while the IIO_MOD_I / IIO_MOD_Q modifiers are stored in channel2. As a result, the switch always falls through to the default case and calibbias reads always fail with -EINVAL, even though the corresponding admv1013_write_raw() path correctly uses channel2 and works as expected. Fix the read path to switch on chan->channel2, matching the write path and the actual channel_spec definition. Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013") Signed-off-by: Salah Triki Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit d380bf5f94a892e546d9a94e8557ad866b043a2a Author: Salah Triki Date: Wed Aug 19 12:41:01 2026 +0100 iio: accel: sca3000: fix frequency divider condition check When setting the sampling frequency, the check for `base_freq / 2` is followed by an independent `if` statement for `base_freq / 4`. If `val` equals `base_freq / 2`, the second check fails and falls through to the `else if (val != base_freq)` branch, returning `-EINVAL` erroneously. Fix this by chaining the checks with `else if`. Fixes: e0f3fc9b47e6 ("iio: accel: sca3000_core: implemented IIO_CHAN_INFO_SAMP_FREQ") Signed-off-by: Salah Triki Reviewed-by: Joshua Crofts Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit baf7e43b7fb5afb777353bf265ddf9d909f72b9f Author: Runyu Xiao Date: Wed Aug 19 22:17:51 2026 +0800 iio: admv1013: initialize callback mutex before registering notifier admv1013_probe() registers a clock notifier whose callback takes st->lock on POST_RATE_CHANGE. Initialize the mutex before devm_clk_notifier_register() so the callback cannot observe an uninitialized lock during probe. Use devm_mutex_init() so the lock lifetime is tied to the device and cleanup stays paired with the rest of the managed probe resources. Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Signed-off-by: Jonathan Cameron commit 2b498df75d6c29aa3e760127ae0f0003df598b53 Author: Arka Mondal Date: Sun Aug 16 03:27:26 2026 +0900 iio: gyro: adis16136: fix unprotected debugfs reads The serial_number file operations are open coded and never call debugfs_file_get(), which debugfs_create_file_unsafe() requires. debugfs_remove_recursive() therefore does not wait for a read in progress, and unbind frees the iio_dev underneath it. Use debugfs_create_file() instead. Fixes: 9aaea09b4cbd ("gyro:adis16136: fix debugfs_simple_attr.cocci warnings") Signed-off-by: Arka Mondal Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit d94787287a113a1326211647d5e0deed1e9de105 Author: Arka Mondal Date: Sun Aug 16 03:27:25 2026 +0900 iio: imu: adis16400: fix unprotected debugfs reads adis16400_serial_number_fops is open coded and never calls debugfs_file_get(), so debugfs_remove_recursive() does not wait for a read in progress and unbind frees the iio_dev underneath it. Commit ae1d37a9bb4b ("iio: imu: adis16400: use DEFINE_DEBUGFS_ATTRIBUTE instead of DEFINE_SIMPLE_ATTRIBUTE") converted product_id and flash_count to DEFINE_DEBUGFS_ATTRIBUTE, which protects itself, but moved all three files to debugfs_create_file_unsafe(). serial_number prints three registers as "%.4x-%.4x-%.4x" and DEFINE_DEBUGFS_ATTRIBUTE() formats a single u64, so it cannot be converted without changing what the file returns. adis16475 and adis16550 already use debugfs_create_file() for their open coded files. Use it here too. Fixes: ae1d37a9bb4b ("iio: imu: adis16400: use DEFINE_DEBUGFS_ATTRIBUTE instead of DEFINE_SIMPLE_ATTRIBUTE") Signed-off-by: Arka Mondal Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit e1dea54496f90a62318cf4eeaa1e9ef8316e92b6 Author: Arka Mondal Date: Sun Aug 16 03:27:24 2026 +0900 iio: imu: adis16480: fix unprotected debugfs reads The firmware_revision and firmware_date file operations are open coded and never call debugfs_file_get(), which debugfs_create_file_unsafe() requires. debugfs_remove_recursive() therefore does not wait for a read in progress, and unbind frees the iio_dev underneath it. Use debugfs_create_file() instead. Fixes: 9bf94f836e32 ("imu:adis16480: fix debugfs_simple_attr.cocci warnings") Signed-off-by: Arka Mondal Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron commit 0f3f427076240e75ff265e61645627a71ca4918c Author: Fan Wu Date: Mon Aug 3 08:03:43 2026 +0000 iio: adc: xilinx-xadc: free IRQ before cancelling the unmask worker on unbind The ZYNQ XADC alarm IRQ handler queues zynq_unmask_work via schedule_delayed_work(); that work is cleared by a devm callback. Register the devm callback before devm_request_irq() so the devres LIFO teardown frees the IRQ first, ensuring the handler can no longer queue work by the time the workqueue is cleared. Otherwise the handler could re-arm the work and run it after the xadc structure has been freed. This issue was found by an in-house static analysis tool. Fixes: 2a9685d1a3b7 ("iio: adc: xilinx: use more devres helpers and remove remove()") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Reviewed-by: David Lechner Signed-off-by: Fan Wu Reviewed-by: Sai Krishna Potthuri Signed-off-by: Jonathan Cameron commit 5330036bc68d23672bfcc16c60c54701ae123083 Author: Jonathan Cameron Date: Mon Aug 3 02:22:24 2026 +0100 iio: buffer: Ensure bounce buffer used for unaligned case is zeroed. iio_push_to_buffers_with_ts_unaligned() leaks uninitialized heap memory to userspace if the data passed in is not a multiple of 8 bytes and the timestamp is enabled. Specify __GFP_ZERO for the devm_krealloc() to ensure any extra space is cleared. Fixes: 95ec3fdf2b79 ("iio: core: Introduce iio_push_to_buffers_with_ts_unaligned()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260529121005.1470-1-kimjinseob88%40gmail.com Reviewed-by: Andy Shevchenko Reviewed-by: Joshua Crofts Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron commit 1a7c522a35477d70320bd64aba8e9de0c1058c6f Author: Laxman Acharya Padhya Date: Sun Aug 2 01:22:00 2026 +0545 iio: proximity: aw96103: validate firmware data length The firmware parser reads a length from the binary header and then uses it to walk six-byte register/value entries. A truncated firmware image can make the parser read beyond the copied firmware buffer. A value smaller than the four-byte count field also underflows, producing a very large length. Read the little-endian field with get_unaligned_le32(), as previously proposed by David Lechner. Validate the header size, reject an underflowed length, ensure the resulting payload is contained in the firmware image, and require it to contain whole register/value entries. Fixes: 07b241262dca ("iio: proximity: aw96103: Add support for aw96103/aw96105 proximity sensor") Link: https://lore.kernel.org/r/20260314-iio-proximity-aw96103-fix-firmware-read-v1-1-c74fe9ccd82b@baylibre.com Cc: stable@vger.kernel.org Signed-off-by: Laxman Acharya Padhya Signed-off-by: Jonathan Cameron commit e787fd23d5063c61582c3c27522240b6e6703fde Author: Geert Uytterhoeven Date: Thu Aug 20 11:19:52 2026 +0200 iio: frequency: adf4377: Fully initialize clk_init_data and clk_parent_data The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. adf4377_clk_register() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter is uninitialized, and thus may cause a crash. Similarly, adf4377_clk_register() fills in only parent_data.fw_name, leaving other members of the clk_parent_data structure uninitialized. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: 60e5448ddbec2dc2 ("iio: frequency: adf4377: add clk provider support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron commit fbf33cb18334e7cab1ed4ad2e9a98a1299ad874c Author: Zhang Jie Date: Tue Aug 18 15:28:03 2026 +0800 iio: proximity: sx9324: Correct proximity channel resolution The proximity channels were previously defined with 12 realbits. However, PROXDIFF is read from RegDiffMsb (0x65) and RegDiffLsb (0x66). The SX9324 datasheet assigns bits 7:0 of each register to PROXDIFF and documents it as a signed two's-complement value (Revision 3, Section 8, Table 8, page 43). In contrast, RegOffsetMsb explicitly marks bits 7:6 as reserved. Thus, PROXDIFF is a 16-bit signed value. With realbits = 12, sx_common_read_proximity() uses bit 11 as the sign bit in sign_extend32(), causing samples outside the 12-bit signed range to wrap into the [-2048, 2047] range. Correct the realbits value to 16 to accurately reflect the hardware. Tested on an SX9324-based device: a phase 0 DIFF readback of 0x7fff was reported as -1 before this change and as 32767 afterward. Fixes: 4c18a890dff8 ("iio:proximity:sx9324: Add SX9324 support") Cc: stable@vger.kernel.org Signed-off-by: Zhang Jie Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron commit 0e65412aee4f651d2c9785f542a13e4b44002a75 Author: Matti Vaittinen Date: Mon Aug 10 10:54:32 2026 +0300 iio: accel: kionix-kx022a: Fix array boundary check The driver performs a sanity check for an array size, when converting a register value to an array index. The check incorrectly accepts the sizeof(array) as a last index, when last valid index should be sizeof(array) - 1. Fix the check by bailing out when index >= sizeof(array). Fixes: 7c1d1677b322 ("iio: accel: Support Kionix/ROHM KX022A accelerometer") Signed-off-by: Matti Vaittinen Reviewed-by: Mehdi Djait Signed-off-by: Jonathan Cameron commit 4e5b0b7c5d95814b6d76911a91572a0691925ca7 Author: Matti Vaittinen Date: Mon Aug 10 10:53:35 2026 +0300 iio: light: rohm-bu27034: Fix error return When BU27034 fails to read gain value at integration-time setting, it returns 0. This leaves caller unaware of the fact that setting the integration time failed. Fix this by returning the relevant error instead of zero. Fixes: 439c2cef8157 ("iio: bu27034: simplify using guard(mutex)") Signed-off-by: Matti Vaittinen Signed-off-by: Jonathan Cameron commit b0e951ffc5a28141a106562997ca136ec6a0e1a3 Author: Matti Vaittinen Date: Mon Aug 10 10:52:47 2026 +0300 iio: pressure: rohm-bm1390: Return error when read fails The data reading function ignores the cached error value, and unconditionally returns 0. Return cached 'ret' -value after stopping the measurement so user knows if read failed and data is garbage. Fixes: 534674463a59 ("iio: bm1390: simplify using guard(mutex)") Signed-off-by: Matti Vaittinen Cc: Signed-off-by: Jonathan Cameron commit 55671fbc3d12ae1f381842433567fcb7ff96a298 Author: Matti Vaittinen Date: Mon Aug 10 10:51:38 2026 +0300 iio: dac: rohm-bd79703: Do not allow writing SCALE The BD79703 has adds IIO_CHAN_INFO_SCALE in the info_mask_shared_by_type so users can read the scale, which depends on the used reference voltage. This, however, enables users to try writing the scale as well. This isn't really supported but the bd79703_write_raw() does not check the mask, and if written scale values pass the validation, the driver will proceed writing the DAC value when users writes the scale. Prevent the unsupported scale setting and return an error. Fixes: af6aca656a85 ("iio: dac: Support ROHM BD79703 DAC") Signed-off-by: Matti Vaittinen Signed-off-by: Jonathan Cameron commit 196cc715dce3576a54065f5cb07185c75778f9a8 Author: Matti Vaittinen Date: Mon Aug 10 10:51:20 2026 +0300 iio: adc: rohm-bd79124: Catch regmap errors at measurement start/stop The bd79124_start_measurement() and bd79124_stop_measurement() ignore errors from the regmap reads, causing potential use of uninitialized stack variable when deciding whether the measurement is already started/stopped. The bd79124_stop_measurement() may also ignore failure to clear the sequencer state bits, which may make the hardware to ignore the setting and leave hardware and driver states out of sync. Check the return value and bail-out if error is detected. Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC") Signed-off-by: Matti Vaittinen Cc: Signed-off-by: Jonathan Cameron commit d081c116a16489f7808d35fcf1ee9d4b9869d204 Author: Matti Vaittinen Date: Mon Aug 10 10:50:49 2026 +0300 iio: adc: rohm-bd79124: Fix GPIO mask check The ROHM BD79124 has pins which can be configured as GPOs or as ADC inputs. The bd79124gpo_set_multiple() is intended to ensure that a pin which is requested to be toggled, is indeed configured as a GPO. The check uses XOR, causing it to fail if mask is not exactly same as GPO configuration. Eg, if not all GPOs are asked to be toggled at once. Fix this by checking that mask does not contain pins that are not configured as GPO, allowing some of the pins which are configured as GPO to be untouched. Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC") Signed-off-by: Matti Vaittinen Cc: Signed-off-by: Jonathan Cameron commit edd56c01d174153bf90160279742ff6f3ad27a93 Author: Matti Vaittinen Date: Mon Aug 10 10:50:21 2026 +0300 iio: adc: rohm-bd79124: Fix channel initialization The alarm limit register on BD79124 span to two consecutive registers. The first register for high-limit containing also hysteresis configuration. The initialization in driver writes only one 8-bit register, overwriting the hysteresis and leaving the other limit register uninitialized. Fix the limit initialization by using the bd79124_write_int_to_reg(), which correctly initializes the limit on both of the registers. Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC") Signed-off-by: Matti Vaittinen Cc: Signed-off-by: Jonathan Cameron commit 0d3f6b5e639f0bca5c1466ec523a94ec4f9f4c24 Author: Matti Vaittinen Date: Mon Aug 10 10:49:56 2026 +0300 iio: adc: rohm-bd79124: Fix rising alarm The rising alarm is using the cached falling alarm value causing wrong value to be used. Fix this by using the correct cached value for rising alarm. Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC") Signed-off-by: Matti Vaittinen Cc: Signed-off-by: Jonathan Cameron commit 91908c0a78baddc8572aa3ab69e62ee2eb496ba4 Author: Cong Nguyen Date: Mon Aug 10 23:44:46 2026 +0700 iio: adc: max1363: sign-extend bipolar differential channel reads MAX1363 differential channels are bipolar, but max1363_read_single_chan() masks the raw value to the ADC resolution without sign-extending it. Negative differential readings are therefore reported to userspace as large positive values (e.g. -1 as 4095 on a 12-bit part). Sign-extend the masked value from the resolution bit for differential channels. Single-ended channels are unipolar and are left unchanged. Fixes: d1325cf45077 ("Staging: IIO: max1363 ADC driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron commit fafefa925ed7ec10383d9bf0378abf878b7f13cb Author: Antoniu Miclaus Date: Fri Aug 7 11:56:43 2026 +0300 iio: adc: ade9000: handle Phase C dip events in IRQ1 handler ADE9000_ST1_CROSSING_DEPTH is the exclusive upper bound for scanning the STATUS1 event bits, so a value of 25 left out the highest event bit, ADE9000_ST1_DIPC_BIT (bit 25). Phase C dip events were never reported. Bump the value to 26 so bit 25 is scanned. Fixes: 81de7b4619fc ("iio: adc: add ade9000 support") Signed-off-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron commit d01f63f673e18f3a99ce8d6fbf1a5f58b70990f7 Author: Antoniu Miclaus Date: Fri Aug 7 11:56:42 2026 +0300 iio: adc: ade9000: fix overlapping scan_index for current and voltage channels Current channels used scan_index "num" and voltage "num + 1", so with phases 0, 1 and 2 the indices overlapped and no longer matched the IA=0, VA=1, IB=2, VB=3, IC=4, VC=5 layout expected by ade9000_waveform_buffer_config(). Phase B and C buffers were configured incorrectly. Use "num * 2" for current and "num * 2 + 1" for voltage to get the non-overlapping 0/1, 2/3, 4/5 layout. Fixes: 81de7b4619fc ("iio: adc: add ade9000 support") Signed-off-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron commit 88fda1ed51a579eb51980436abc6557006a520a3 Author: Antoniu Miclaus Date: Fri Aug 7 11:56:41 2026 +0300 iio: adc: ade9000: request interrupts after powering the device The IRQ handlers do SPI register accesses, but the interrupts were requested before the vdd regulator was enabled. An interrupt arriving while the chip is unpowered runs a handler against a dead chip, causing SPI errors or garbage reads. Request the interrupts after enabling the regulator. This keeps irq1 registered before ade9000_reset(), which waits on it, and lets devm free the interrupts before the regulator is disabled. Fixes: 81de7b4619fc ("iio: adc: add ade9000 support") Signed-off-by: Antoniu Miclaus Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron commit 549b71ce050637dd32678371ad76c445a2f8c9aa Author: Janani Sunil Date: Thu Aug 13 15:56:56 2026 +0200 iio: adc: adi-axi-adc: Initialize state mutex The AXI ADC register access paths serialize transactions with st->lock, but probe does not initialize it. Initialize the mutex before registering the backend. Fixes: 7ecb8ee5c93b ("iio: adc: adi-axi-adc: support digital interface calibration") Signed-off-by: Janani Sunil Cc: Signed-off-by: Jonathan Cameron commit 63213927b141085b6c8719b8037dab3074b7e0fe Author: Fan Wu Date: Thu Aug 6 13:29:23 2026 +0000 iio: light: gp2ap020a00f: drain irq_work after free_irq The threaded IRQ handler queues data->work through irq_work_queue() so the trigger is polled from a per-CPU context. free_irq() does not flush an irq_work the handler already queued, so after gp2ap020a00f_remove() returns that work may still run and call iio_trigger_poll() on data->trig, which the devm cleanup has already freed, causing a use-after-free. Add irq_work_sync(&data->work) after free_irq() in remove() and in the probe error path, mirroring commit 78601726d4a5 ("iio: trigger: sysfs: fix use-after-free on remove"). Found by an in-house static analysis tool, confirmed by manual review. Fixes: bf29fbeaa13d ("iio: gp2ap020a00f: Add a driver for the device") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jonathan Cameron commit 56c423b233b214182c58c99861899327b45b0d6c Author: Hui Su Date: Tue Aug 11 10:52:53 2026 +0800 iio: pressure: bmp280: fix out-of-bounds access in sampling frequency lookup The sampling frequency tables store each frequency as an integer part and a fractional part in micro units. num_sampling_freq_avail is initialized to the number of flattened integer elements because read_avail() returns the table as a flat array. bmp280_write_sampling_frequency(), however, indexes the same table as a two-dimensional array and uses num_sampling_freq_avail as the number of rows. Convert the flattened element count back to the number of rows before iterating over the table. Fixes: 10b40ffba2f9 ("iio: pressure: bmp280: Add more tunable config parameters for BMP380") Cc: stable@vger.kernel.org Signed-off-by: Hui Su Reviewed-by: Joshua Crofts Signed-off-by: Jonathan Cameron commit f0ea4824deebf21dacfbe397c4b0a5fd3e745a8d Author: Marco Chen Date: Sat Aug 8 15:54:50 2026 -0400 iio: health: max30102: fix NULL dereference in interrupt handler The interrupt is requested in max30102_probe() and stays enabled for the lifetime of the device, but indio_dev->active_scan_mask is only valid while a buffer is enabled. When an interrupt arrives while no buffer is enabled, the handler dereferences the NULL active_scan_mask: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __bitmap_weight+0x64/0x98 (P) max30102_interrupt_handler+0x48/0x160 [max30102] Call max30102_fifo_count() at the top of the handler and return early unless it reports a FIFO sample is ready. Because FIFO_RDY is the only interrupt source enabled in max30102_chip_init(), an invocation of max30102_interrupt_handler() without the FIFO_RDY interrupt status bit set carries no data to read and can return before touching active_scan_mask. A negative return from max30102_fifo_count() indicates a failed interrupt status read and is treated the same way. Fixes: 90579b69e94b ("iio: health: max30102: Add MAX30105 support") Suggested-by: Jonathan Cameron Signed-off-by: Marco Chen Cc: Signed-off-by: Jonathan Cameron commit 173cb3147ba26449e6023df56f9bcd34ce6d1c3b Author: Antoine Monnet Date: Sat Aug 15 14:50:00 2026 +0300 ASoC: tas2783-sdw: split a stereo stream across the two mono amps A board with two TAS2783 aggregated on one link renders mono: the two amplifiers are mono parts that each carry one channel of the stereo stream, but snd_sdw_params_to_config() hands every codec the full channel mask for playback. The pair stays in mirror mode, both amps render the same channel, and the other channel is never reproduced. Claim a single channel per amplifier instead. The index comes from the machine-assigned component name prefix rather than the SoundWire unique_id, which is board-specific: soc_sdw_ti_amp.c names the amplifiers tas2783-1..4. The bit that is set does not choose the side. sdw_compute_slave_ports() advances the payload offset by hweight32(ch_mask) and never looks at which bit it is, so a one-channel mask fixes mono by defeating mirror mode, and left and right then follow the amplifier's position in the codec order of the DAI link. That was measured: inverting the two masks between the amplifiers does not move the audio. On the boards this has been run on the codec order matches the prefix numbering, so the sides come out as the machine driver names them, but the mapping is not an ABI promise the bus allocator could honour. Reported-by: Robin Everaars Closes: https://lore.kernel.org/all/20260805183517.8665-1-robineveraars@pm.me/ Suggested-by: Robin Everaars Signed-off-by: Antoine Monnet Tested-by: Andrey Golovko Signed-off-by: Andrey Golovko Link: https://patch.msgid.link/20260815113000.4488-1-andrey.golovko@gmail.com Signed-off-by: Mark Brown commit fe10579b6dc3f0dac61e51e1797cacbba5039ac2 Author: Dmitry Torokhov Date: Wed Aug 5 22:44:23 2026 -0700 Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound Transport drivers (such as rmi_i2c and rmi_spi) invoke rmi_driver_suspend() and rmi_driver_resume() on their child rmi_dev device during system power management events. However, transport drivers are fully registered and operational even if the physical RMI driver failed to bind or probe the rmi_dev device. When rmi_driver_suspend() or rmi_driver_resume() is called on an unbound rmi_dev, dev_get_drvdata() returns NULL. Calling rmi_disable_irq() or rmi_enable_irq() without driver data attached causes a NULL pointer dereference and General Protection Fault when attempting to lock data->enabled_mutex. Fix this by checking if driver data is attached to rmi_dev in rmi_driver_suspend() and rmi_driver_resume(), exiting early if no driver data is present. Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Reported-by: syzbot+09103639e39c989e3ed3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=09103639e39c989e3ed3 Cc: stable@vger.kernel.org Assisted-by: LLM Link: https://patch.msgid.link/anQe8UiyUR4x0flD@google.com Signed-off-by: Dmitry Torokhov commit 51cfe54f815ae175c7d1126b983d4d7c89715004 Author: Dmitry Torokhov Date: Tue Aug 4 22:08:54 2026 -0700 Input: rmi_smbus - fix out-of-bounds read in rmi_smb_write_block() When chunking writes into SMBus blocks in rmi_smb_write_block(), the loop calculates block_len using the original total length (len) instead of the remaining length (cur_len). If len is greater than 32 bytes (SMB_MAX_COUNT), block_len remains 32 for every iteration, even on the final partial chunk where fewer than 32 bytes remain. This causes smb_block_write() to read 32 bytes from the advanced data buffer pointer, reading past the end of the input buffer. Fix this by calculating block_len using cur_len and advancing the buffer and address pointers by block_len. Fixes: 82264d0cf7ae ("Input: synaptics-rmi4 - add SMBus support") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Assisted-by: LLM Link: https://patch.msgid.link/anLFSMKSoKyyZ272@google.com Signed-off-by: Dmitry Torokhov commit e3eceb76515910746e6268c4e4ac1c07516ebd7b Author: Tzung-Bi Shih Date: Thu Aug 27 04:46:59 2026 +0000 watchdog: msc313e: Fix NULL pointer dereference in PM callbacks msc313e_wdt_probe() doesn't set the driver data for the platform device. As a result, dev_get_drvdata() in msc313e_wdt_suspend() and msc313e_wdt_resume() will return NULL, leading to a NULL pointer dereference afterward. Set the platform device driver data in msc313e_wdt_probe(). Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver") Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260827044700.554333-2-tzungbi@kernel.org Signed-off-by: Guenter Roeck commit aab55360fa11a2c054798a484ac67ad606f563e4 Author: James Hilliard Date: Thu Aug 27 22:42:31 2026 -0600 watchdog: sunxi_wdt: preserve boot-enabled watchdog sunxi_wdt_probe() unconditionally stops the watchdog even when firmware left it running. This opens an unprotected interval during boot and prevents CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED from taking over the active watchdog. Detect an enabled watchdog and decode its programmed interval. Preserve representable timeouts, and round the 0.5-second interval up to the minimum representable one-second timeout. Use the configured timeout for reserved interval encodings. Set the Linux reset mode and ping the watchdog without clearing its enable bit, then mark it hardware-running before registration so the watchdog core services it until userspace takes control. Leave disabled watchdogs untouched. Fixes: d00680ed0026 ("watchdog: sunxi: New watchdog driver for Allwinner A10/A13") Cc: stable@vger.kernel.org Signed-off-by: James Hilliard Link: https://patch.msgid.link/20260827-submit-sunxi-wdt-boot-enabled-v1-v2-1-610d37dccc97@gmail.com Signed-off-by: Guenter Roeck commit a8455260b2e9c024d1872ac1c094793d55a7e537 Author: Maciej Fijalkowski Date: Fri Aug 28 18:49:18 2026 +0200 ipvlan: unregister upper devices outside pnodes_lock syzbot reported the following circular locking dependency: xs->mutex -> netdev lock -> pnodes_lock -> net->xdp.lock -> xs->mutex The pnodes_lock -> net->xdp.lock edge is recorded when ipvlan_device_event(NETDEV_UNREGISTER) calls unregister_netdevice_many() while holding pnodes_lock. A nested NETDEV_UNREGISTER notification for an IPvlan device enters xsk_notifier(), which acquires net->xdp.lock. Keep pnodes_lock only while marking the upper devices as dying, removing them from port->ipvlans, and queueing them for unregistration. Once the devices have been detached from the protected list, release pnodes_lock before unregister_netdevice_many() invokes notifier callbacks. The port remains alive across unregistration because ipvlan_device_event() holds the reference acquired by ipvlan_port_get(). The dying flag prevents a concurrent ->dellink() callback from deleting a queued device again. Fixes: 35add1093e2f ("ipvlan: Protect ipvl_port.ipvlans with mutex.") Reported-by: syzbot+aa48b5fe7bfda62d1682@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=aa48b5fe7bfda62d1682 Signed-off-by: Maciej Fijalkowski Reviewed-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260828164918.451364-1-maciej.fijalkowski@intel.com Signed-off-by: Jakub Kicinski commit 4aa61c88b4e292e10abdfd791334b8272108d68a Author: Baul Lee Date: Thu Aug 27 02:36:04 2026 +0900 vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del() vxlan_mdb_is_valid_source(), which validates MDBE_ATTR_SOURCE and every MDBE_ATTR_SRC_LIST member, accepts the all-zeros address. A source list is only accepted on a (*, G) entry, whose source is the all-zeros address, and for each member of the list an (S, G) entry is derived from it by substituting the source. Entries are keyed by a plain memcmp() of struct vxlan_mdb_entry_key, so if MDBE_ATTR_SOURCE is present and holds the all-zeros address and the source list holds it as well, the derived (S, G) key is byte-identical to the (*, G) key and resolves to the same entry. Omitting MDBE_ATTR_SOURCE is not equivalent, as the key is then left with a zero address family. vxlan_mdb_remote_src_del() removes the forwarding entry of a source before freeing the source entry: vxlan_mdb_remote_src_fwd_del(vxlan, group, remote, &ent->addr); vxlan_mdb_remote_src_entry_del(ent); With the keys aliased, the first call deletes the remote of the entry that owns 'ent' instead of a separate (S, G) entry, and frees 'ent'. The second call then runs on the freed entry, and its hlist_del() reads ->pprev and ->next out of it and writes through them. Adding the (*, G) entry with NLM_F_REPLACE and no source list marks the all-zeros source for deletion and reaches this from the sweep at the end of vxlan_mdb_remote_srcs_replace(). BUG: KASAN: slab-use-after-free in __vxlan_mdb_add+0x1cd/0xd70 Read of size 8 at addr ffff888102852500 by task poc/84 __vxlan_mdb_add+0x1cd/0xd70 vxlan_mdb_add+0xc0/0x140 rtnl_mdb_add+0x157/0x2a0 rtnetlink_rcv_msg+0x207/0x5a0 Allocated by task 84: __kmalloc_cache_noprof+0x153/0x360 vxlan_mdb_remote_srcs_add+0x2eb/0x440 __vxlan_mdb_add+0x803/0xd70 Freed by task 84: kfree+0x14c/0x3b0 vxlan_mdb_remote_del+0x129/0x1a0 __vxlan_mdb_del+0x4f/0xe0 vxlan_mdb_remote_src_fwd_del.isra.0+0x162/0x1b0 __vxlan_mdb_add+0x1c5/0xd70 The MDB operations are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Reject the all-zeros address in vxlan_mdb_is_valid_source(), which covers both call sites. A (*, G) entry is expressed by omitting the source, so nothing legitimate is refused. Discovered by XBOW, triaged by Baul Lee Fixes: a3a48de5eade ("vxlan: mdb: Add MDB control path support") Signed-off-by: Baul Lee Reviewed-by: Ido Schimmel Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260826173604.90158-1-baul.lee@xbow.com Signed-off-by: Jakub Kicinski commit 6cfc1b90cb86f4aabc69fb8e30128e07e2cdfa3a Author: Charles Vosburgh Date: Thu Aug 27 17:32:53 2026 -0400 sctp: validate chunk length in the inqueue parser SCTP chunks always include a four-byte generic header, but sctp_inq_pop() currently accepts shorter declared lengths. A zero-length chunk leaves chunk_end at the current header. When ASCONF is covered by the association's SCTP-AUTH policy, sctp_assoc_bh_rcv() can continue before the state machine performs its normal chunk-length check. sctp_inq_pop() then returns the same malformed chunk repeatedly and the receive softirq can lock up. A remote SCTP peer can trigger this after establishing an association on a kernel built with CONFIG_IP_SCTP and configured with net.sctp.addip_enable=1 and net.sctp.auth_enable=1. The reproducer did not require application credentials, a shared SCTP AUTH key, or net.sctp.addip_noauth_enable=1. On commit f967455fb2a5 ("seg6: reset IP6CB after IPv6 decapsulation"), one zero-length ASCONF caused repeated watchdog soft-lockup reports in a two-vCPU KVM guest. All 3 pre-trigger health probes succeeded, while 36 of 37 post-trigger probes failed. With this change, all 37 post-trigger probes succeeded and no equivalent soft-lockup signature appeared. Reject chunks shorter than the generic SCTP header at the shared inqueue parser boundary. Mark the packet for discard before either caller can continue processing it, while preserving the four-byte generic minimum. Declared-length 1 through 4 controls and kernel-generated ASCONF traffic remained healthy. The patched sctp_hello selftest passed for IPv4 and IPv6. The complete private reproducer and validation evidence are available directly to maintainers on request. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Cc: stable@vger.kernel.org Signed-off-by: Charles Vosburgh Acked-by: Xin Long Link: https://patch.msgid.link/20260827-sctp-zero-chunk-inqueue-v2-1-2e7669c6a6cb@gmail.com Signed-off-by: Jakub Kicinski commit ac8d6b28d48c5d951dcd923d33e461588e762a6d Author: James Nugraha Date: Fri Aug 28 09:22:19 2026 +1000 net: amd-xgbe: discard rx packets with bad FCS amd-xgbe driver currently sets the MAC_RCR.DCRCC bit whenever RX is enabled. This disables hardware FCS validation, causing packets with bad FCS to be accepted unconditionally. This change unsets DCRCC so that packets with bad FCS will be dropped, in-line with typical behaviours of many other network controllers. Tests: - Verified that packets with bad FCS are now dropped. - Verified that receiving packets with bad FCS will increment the `rx_crc_errors` counter. Fixes: c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver") Signed-off-by: James Nugraha Link: https://patch.msgid.link/20260827232220.69907-1-aslan.jnn@gmail.com Signed-off-by: Jakub Kicinski commit ac08d183dac0441e41f77bbad50798fe609d90f1 Author: Xuanqiang Luo Date: Fri Aug 28 09:29:18 2026 +0800 raw: annotate disconnect-side IPv4 match writers raw_v4_match() reads inet_daddr, inet_rcv_saddr and sk_bound_dev_if locklessly under RCU. Bind and connect writers are annotated, but __udp_disconnect() still clears the same fields using plain stores. Commit 18f116931f52e ("raw: annotate lockless match fields in raw_v4_match()") added the lockless readers and annotated the raw bind and datagram connect writers. Its v4 revision intentionally left the shared disconnect-side IPv4 writers for follow-up cleanup. Complete that follow-up by using WRITE_ONCE() for the disconnect-side stores, including the inet_rcv_saddr reset in inet_reset_saddr(), to pair with the lockless raw socket matcher. Fixes: 0daf07e52709 ("raw: convert raw sockets to RCU") Link: https://lore.kernel.org/netdev/20260716142958.3064224-1-runyu.xiao@seu.edu.cn/ Suggested-by: Runyu Xiao Signed-off-by: Jackie Liu Signed-off-by: Xuanqiang Luo Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260828012918.1461-1-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski commit 2cb0b0b1ed69430bf73740377ea0a1c44c50db63 Author: Henry Martin Date: Fri Aug 28 12:24:25 2026 +0800 sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration sctp_verify_asconf() walks ASCONF-ACK parameters with sctp_walk_params(), which advances by SCTP_PAD4(length), while the consumer sctp_get_asconf_response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset. When those bytes yield a length of zero, the while loop over asconf_ack_len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help). The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read. Reject SCTP_PARAM_ERR_CAUSE parameters shorter than sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR_CAUSE parameter the consumer can see, so the consumer's asconf_ack_len check is dropped and it returns err_param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP_PARAM_ERR_CAUSE per RFC 5061. The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Henry Martin Acked-by: Xin Long Link: https://patch.msgid.link/20260828042431.3873725-1-bsdhenrymartin@gmail.com Signed-off-by: Jakub Kicinski commit cee9395acd8043be0644b25c34bfa86623f2b935 Author: Linus Torvalds Date: Sun Aug 30 13:34:40 2026 -0700 Linux 7.3-rc1 commit 2af470916a208b576ac9975d221d9a378cf8ace9 Author: Boqun Feng Date: Thu Aug 27 12:48:35 2026 -0700 preempt: Remove hardirq_disable_count() It turns out the previous usage of hardirq_disable_count() in __irq_exit_rcu() would cause softirq pending issues. Without that usage, hardirq_disable_count() doesn't need to exist, so remove it. Also move hardirq_disable_enter/exit() into the Rust specific interrupt_rc header. [ tglx: Move the helpers over ] Signed-off-by: Boqun Feng Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260827194835.38968-1-boqun@kernel.org commit 78bb208b99e7d3314f670710fa9ee0a793682bca Merge: eea8bdcb59e027 b15b548d52b43b Author: Linus Torvalds Date: Sun Aug 30 10:53:24 2026 -0700 Merge tag 'i2c-fixes-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull i2c fixes from Andi Shyti: "Fixes mainly for teardown and resource handling, runtime PM and hardware-specific controller issues: - fix debugfs use-after-free when removing the adapter - designware: apply interrupt mask quirk for HJMC3001 - imx-lpi2c: avoid target accesses on master-only controllers - mux: release channel node when adapter registration fails - qcom-cci: fix autosuspend and runtime PM cleanup on removal - qcom-geni: fix timing parameters for 32 MHz clock" * tag 'i2c-fixes-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: i2c: core: fix debugfs UAF on adapter removal i2c: imx-lpi2c: avoid accessing target registers on master-only controllers i2c: qcom-cci: fix autosuspend cleanup i2c: designware: Enable interrupt mask workaround for HJMC3001 i2c: qcom-geni: update frequency table to fix timing parameters i2c: mux: Fix channel node leak on adapter add failure commit eea8bdcb59e02729a33a8666f7b0b5e30e6cb736 Merge: cbb4c6d9af7dde ef6a1dca8de41a Author: Linus Torvalds Date: Sun Aug 30 10:42:40 2026 -0700 Merge tag 'cocci-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux Pull Coccinelle updates from Julia Lawall: - Clean up a number of the semantic patches in the scripts/coccinelle directory, particularly with respect to functions that no longer exist in the kernel (Sang-Heon Jeon) He and I have also done some reorganizations that improve performance. - Eliminate some false positives (me) - Fix an out of date URL (相浦彰) * tag 'cocci-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux: coccinelle: ifnulldev_put: update error message coccinelle: ifnulldev_put: update outdated helper names coccinelle: atomic_as_refcounter: drop atomic_long_dec_and_lock coccinelle: kfree_mismatch: drop vmalloc_exec coccinelle: pool_zalloc-simple: drop the pci_pool_alloc rules coccinelle: zalloc-simple: drop the kmem_alloc rules coccinelle: alloc_cast: drop removed allocators coccinelle: remove obsolete pci_free_consistent.cocci scripts: coccinelle: devm_free: reduce false positives coccinelle: misc: struct_size: drop unneeded parentheses coccinelle: mini_lock: improve performance when searching loops coccinelle: api: check for macro context coccinelle: update Coccinelle website URL coccinelle: misc: minmax: avoid unhelpful isomorphisms coccinelle: misc: minmax: check for the presence of if cases coccinelle: misc: minmax: drop unneeded parentheses coccinelle: misc: minmax: improve performance when no candidate exists coccinelle: double_lock: improve performance when no double lock exists commit cbb4c6d9af7dde462f8c9261bdcd35c47a0b4054 Author: Darrick J. Wong Date: Fri Aug 28 09:15:01 2026 -0700 CREDITS/mailmap: add some info about Darrick J. Wong Add myself to CREDITS because apparently I've never done that; and update mailmap so that all my old email addresses get remapped to the kernel.org redirector. Signed-off-by: "Darrick J. Wong" Signed-off-by: Linus Torvalds commit a23cbb05744b22719efdc34f9e329a120e81e617 Merge: 637836563deb95 64f74d8f728877 Author: Linus Torvalds Date: Sun Aug 30 10:19:11 2026 -0700 Merge tag 'timers-urgent-2026-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fix from Ingo Molnar: - Fix UM build regression caused by the removal of the UM specific timex.h header (Thomas Weißschuh) * tag 'timers-urgent-2026-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: um: Use asm-generic/timex.h over the host architecture one commit fe39cd9d48f2346605f3746e0cc19e89d5f373eb Author: Frank Sorenson Date: Wed Aug 26 20:57:38 2026 -0500 cifs: don't update i_size in cifs_do_truncate without a cached handle If find_writable_file() returns null, cifs_file_flush will return 0 without issuing set_file_size, and the outer 'if (!rc)' block will set i_size to 0 before telling the server to truncate. If the cifs_open() then fails, the inode will have size 0, while the server file is unchanged. Move the netfs_resize_file() and cifs_setsize() into the 'if (cfile)', so they only run after a successful set_file_size. In the no-handle else branch, evict stale pages with truncate_inode_pages before the O_TRUNC open to dispose of old cache pages, and let the open response set the i_size. Fixes: 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Acked-by: David Howells Signed-off-by: Paulo Alcantara commit 1dac61e2c29d1a71784604b48cf3b1234a65ec29 Author: Frank Sorenson Date: Wed Aug 26 21:13:36 2026 -0500 smb: client: fix heap overflow in cifs_do_set_acl() cifs_set_acl() validates ACL size using posix_acl_xattr_size(): 4 + (count * 8) // 4-byte header + 8 bytes per ACE cifs_do_set_acl() then calls posix_acl_to_cifs() to write the CIFS wire format into the same buffer: 6 + (count * 10) // 6-byte header + 10 bytes per ACE An ACL that passes the xattr-based check in cifs_set_acl() can overflow the heap when posix_acl_to_cifs() writes the larger CIFS format. Validate the CIFS format size against the remaining buffer space and USHRT_MAX before converting--data_count is __u16, so sizes above USHRT_MAX truncate the on-wire packet length, causing the server to apply a partial ACL. Replace MaxDataCount = 1000 with min(CIFSMaxBufSize, USHRT_MAX). Fixes: dc1af4c4b4721 ("cifs: implement set acl method") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Signed-off-by: Paulo Alcantara commit 69499395867332364ed4ac8b546537eb3bab6ebb Author: Paulo Alcantara Date: Mon Aug 24 16:59:12 2026 -0300 smb: client: fix multiuser mount with krb5 Customer reported that they could no longer mount their SMB shares with multiuser mount option and krb5. Turned out that the client wasn't duplicating username option when creating multiuser connections, therefore failing to retrieve credentials as cifs.upcall(8) couldn't find them in keytab. Fix this by duplicating username option (if set) from original fs context before creating multiuser connections with krb5. Reproducer: ``` $ ktutil ktutil: add_entry -password -p testuser -k 1 -e aes256-cts Password for testuser@ZELDA.TEST: ktutil: write_kt /etc/krb5.keytab ktutil: quit $ klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- ---------------------------------------------------------------- 1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96) $ mount.cifs //w22-root2/scratch /mnt/1 -o \ uid=1000,sec=krb5,username=testuser@ZELDA.TEST,multiuser mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) ``` Reported-by: Jacob Shivers Fixes: 12b4c5d98cd7 ("smb: client: fix krb5 mount with username option") Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit d83a21bb26015bfdd79b0440fe816b271b8bbab3 Author: Andy Shevchenko Date: Tue Aug 25 10:30:43 2026 +0200 smb: client: transport: Fix debug printing in __release_mid() Long time ago during upgrading printk():s to the respective pr_() calls one misconversion happened and nobody has noticed that. So, previously printk(KERN_DEBUG) + printk() worked as one long debug print since the trailing '\n' is only present in the followup printk() format string. The culprit change missed that and split the message to two on the different levels. Restore the original behaviour to make users be less confused in the most likely never happen cases of partially getting that message. Fixes: 0b456f04bcdf ("cifs: convert printk(LEVEL...) to pr_") Signed-off-by: Andy Shevchenko Signed-off-by: Paulo Alcantara commit 448ba0ae65ca61064183564d2983c9aa59bd6ba7 Author: Huiwen He Date: Fri Aug 28 15:19:35 2026 +0800 smb/client: invalidate fscache for fallocate range operations smb3_zero_range(), smb3_punch_hole(), smb3_insert_range(), and smb3_collapse_range() modify file contents through server-side range operations. These operations discard the affected page cache, but leave the FS-Cache cookie valid, so a later read may return data cached before the range operation. Fix this by invalidating FS-Cache after outstanding I/O has completed and before modifying the file on the server. Run the following as root on a CIFS mount with fsc enabled and an active CacheFiles backend: bash -c ' MNT=/mnt/cifs FILE="$MNT/repro" # Generate four 1 MiB random blocks: [A][B][C][D]. dd if=/dev/urandom of=/tmp/src bs=1M count=4 status=none # Expected contents after zeroing B: [A][zero][C][D]. cp /tmp/src /tmp/expected dd if=/dev/zero of=/tmp/expected bs=1M seek=1 count=1 \ conv=notrunc status=none cp /tmp/src "$FILE" # Populate FS-Cache, then discard the page cache. sync echo 1 > /proc/sys/vm/drop_caches cat "$FILE" > /dev/null sync echo 1 > /proc/sys/vm/drop_caches fallocate --zero-range -o 1M -l 1M "$FILE" if cmp -s /tmp/expected "$FILE"; then echo "readback: OK" else echo "readback: STALE DATA" fi ' Before this change, the readback differs from /tmp/expected: readback: STALE DATA After this change, it matches: readback: OK Fixes: 30175628bf7f ("[SMB3] Enable fallocate -z support for SMB3 mounts") Fixes: 31742c5a3317 ("enable fallocate punch hole ("fallocate -p") for SMB3") Fixes: 5476b5dd82c8 ("cifs: add support for FALLOC_FL_COLLAPSE_RANGE") Fixes: 7fe6fe95b936 ("cifs: add FALLOC_FL_INSERT_RANGE support") Signed-off-by: Huiwen He Suggested-by: Namjae Jeon Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 01261a6fa48b62f5ead8e88aaca1e27cb9ab9032 Author: Huiwen He Date: Fri Aug 28 15:19:34 2026 +0800 smb/client: fix stale page cache in insert/collapse range smb3_insert_range() and smb3_collapse_range() use truncate_pagecache_range() to invalidate the affected page cache. However, if off or old_eof is not page-aligned, the boundary pages are only partially zeroed and remain uptodate. As a result, the client may return stale data after a successful insert/collapse range operation. For example, with 4K pages: page 0 page 1 page 2 0------4K 4K------8K 8K------12K ^ ^ off=2K old_eof=10K Page 1 is removed from the page cache, while the boundary pages are only partially zeroed. After COPYCHUNK moves the data on the server, these cached pages may still return stale data. This can be reproduced on a CIFS mount: bash -c ' FILE=/mnt/scratch/repro # Use a 6 KiB file so EOF is not page-aligned. dd if=/dev/urandom of=/tmp/src bs=1K count=6 status=none # Expected: a 4 KiB hole followed by the original data. rm -f /tmp/expected truncate -s 4K /tmp/expected cat /tmp/src >> /tmp/expected cp /tmp/src "$FILE" # Prime the page cache before moving data on the server. cat "$FILE" > /dev/null fallocate --insert-range -o 0 -l 4K "$FILE" if cmp -s /tmp/expected "$FILE"; then echo "readback: OK" else echo "readback: STALE DATA" fi ' Fix this by writing back dirty data and discarding the page cache from the start of the page containing off to EOF before moving data on the server. Fixes: 9c8b7a293f50 ("smb3: fix temporary data corruption in insert range") Fixes: fa30a81f255a ("smb3: fix temporary data corruption in collapse range") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 7811701d6af7db76481a82b9bc3c4adf7863acf5 Author: Huiwen He Date: Fri Aug 28 15:19:33 2026 +0800 smb/client: fix integer truncation in collapse range smb3_collapse_range() stores the ssize_t return value of smb2_copychunk_range() in an int. A successful copy larger than INT_MAX is truncated to a negative value and treated as an error. Reproducer: MNT=/mnt/scratch truncate -s 2056M "$MNT/file" fallocate --collapse-range -o 1M -l 1M "$MNT/file" Fix this by using __smb2_copychunk_range(), which reports success as zero instead of returning the copied byte count. Before this change, the reproducer fails with: fallocate: fallocate failed: Success and the file size remains unchanged at 2056 MiB. After this change, the reproducer succeeds and the file size becomes the expected 2055 MiB. Fixes: 5476b5dd82c8 ("cifs: add support for FALLOC_FL_COLLAPSE_RANGE") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 0923ae9f23cc9460b0df6fc124cd56ec4436411b Author: Huiwen He Date: Fri Aug 28 15:19:32 2026 +0800 smb/client: fix data corruption in emulated insert range smb3_insert_range() shifts [off, EOF) right with COPYCHUNK, copying from low to high offsets. When the ranges overlap, the copy can overwrite source data that has not yet been copied. For a 1 MiB insert at offset 0: offset: 0 1M 2M 3M 4M 5M before: | A | B | C | D | expected: | hole | A | B | C | D | current: | hole | A | A | A | A | (corrupted) Let x be the insertion offset, L the total length to move, delta the insert length, and C the normal chunk size allowed by the server. Insert range maps [x, x + L) -> [x + delta, x + delta + L). When delta >= L, the complete source and target ranges are disjoint, so the normal copy order and chunk size are safe: offset: 0 4 8 12 16 20 24 28 32 source: [--S0--][--S1--][--S2--][--S3--] target: [--T0--][--T1--][--T2--][--T3--] When delta < L, the complete source and target ranges overlap, so the copy must proceed from EOF backwards. There are two subcases. If delta >= C, each corresponding source and target chunk is disjoint. The 1 MiB example has L = 4 MiB and delta = C = 1 MiB: offset: 0 1M 2M 3M 4M 5M source: [--S0--][--S1--][--S2--][--S3--] target: [--T0--][--T1--][--T2--][--T3--] Copying S0 from [0, 1M) to [1M, 2M) overwrites S1 before it is copied. Processing chunks from EOF backwards prevents this inter-chunk overwrite. If delta < C, the source and target ranges of a normal chunk also overlap. For example, with L = 16, delta = 2 and C = 4: offset: 0 2 4 6 8 10 12 14 16 18 source: [--S0--][--S1--][--S2--][--S3--] target: [--T0--][--T1--][--T2--][--T3--] Here S0 and T0 overlap over [2,4), S1 and T1 over [6,8), and so on. Backward ordering cannot control how the server copies bytes inside one descriptor, so the chunk size must be limited to delta. Fix this by copying overlapping right shifts from EOF backwards. Limit the chunk size to delta when delta < C so that each chunk's source and target ranges do not overlap. Using larger chunks would require a way to identify servers that safely handle overlapping COPYCHUNK descriptors. Therefore: delta >= L: keep the normal copy order and chunk size delta < L: delta >= C: copy backwards and keep the normal chunk size delta < C: copy backwards and limit the chunk size to delta Only the delta < C subcase requires reducing the chunk size for data integrity. Reproducer: bash -c ' MNT=/mnt/scratch # Generate four 1 MiB random blocks: [A][B][C][D]. dd if=/dev/urandom of=/tmp/src bs=1M count=4 status=none # With C = 1 MiB, test delta = C and delta < C. for delta in 1M 1K; do truncate -s 0 /tmp/expected truncate -s "$delta" /tmp/expected cat /tmp/src >> /tmp/expected cp /tmp/src "$MNT/file" fallocate --insert-range -o 0 -l "$delta" "$MNT/file" if cmp -s /tmp/expected "$MNT/file"; then echo "delta=$delta: OK" else echo "delta=$delta: CORRUPTED" fi done ' The corruption reproduces with Samba and ksmbd, while Windows handles the overlapping COPYCHUNK ranges safely. The 1 MiB case tests delta >= C, while the 1 KiB case tests delta < C. Before this change, the reproducer reports: delta=1M: CORRUPTED delta=1K: CORRUPTED After this change, it passes against both ksmbd and Samba: delta=1M: OK delta=1K: OK Fixes: 7fe6fe95b936 ("cifs: add FALLOC_FL_INSERT_RANGE support") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit cd03ce4950d80147ac8f20bc03c42b75b0352407 Author: Huiwen He Date: Fri Aug 28 15:19:31 2026 +0800 smb/client: mark file sparse before emulating insert range The SMB client emulates FALLOC_FL_INSERT_RANGE with SET_EOF, COPYCHUNK and SET_ZERO_DATA. SET_ZERO_DATA creates a hole only when the file is sparse. On a non-sparse file, it clears the inserted range but leaves its blocks allocated, causing the extent count check in xfstests generic/064 to fail. Fix this by marking the file sparse before modifying it. This patch produces the expected sparse extents in xfstests generic/064 only when the server-reported block size is compatible with the server's deallocation granularity. For ksmbd, the reported block size follows the backing filesystem, and the test passes. For Samba, the test passes with a block size matching the backend granularity, for example, 4 KiB on Btrfs, but not with the default 1 KiB value. For Windows Server 2022, 4 KiB inserts do not generate holes, while aligned inserts of 64 KiB or larger do. Fixes: 7fe6fe95b936 ("cifs: add FALLOC_FL_INSERT_RANGE support") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 88972e35750792e717af287dc71f42a03b5cbce4 Author: Huiwen He Date: Fri Aug 28 15:19:30 2026 +0800 smb/client: validate new EOF for zero range When FALLOC_FL_ZERO_RANGE is used without FALLOC_FL_KEEP_SIZE, smb3_zero_range() may extend EOF without checking RLIMIT_FSIZE, allowing the file to grow beyond the caller's file-size limit. Fix this by calling inode_newsize_ok() before sending the zero-range request when the operation would extend EOF. Reproducer, using a file on a CIFS mount: bash -c ' FILE=/mnt/cifs/repro trap "" SIGXFSZ ulimit -f 3072 truncate -s 2M "$FILE" fallocate --zero-range -o 0 -l 4M "$FILE" echo "fallocate rc=$?" stat -c "file size=%s" "$FILE" ' Before this change, the operation succeeds despite the 3 MiB limit: fallocate rc=0 file size=4194304 After this change, fallocate fails and leaves the file at 2 MiB. Fixes: 72c419d9b073 ("cifs: fix smb3_zero_range so it can expand the file-size when required") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 1519dc88c87f5346dae0464d7d6da1b6bf1f6e8e Author: Huiwen He Date: Fri Aug 28 15:19:29 2026 +0800 smb/client: validate new EOF for insert range smb3_insert_range() does not check if the new file size (i_size + len) is valid. This allows FALLOC_FL_INSERT_RANGE to bypass RLIMIT_FSIZE, exceed s_maxbytes, or produce a size outside the loff_t range. Use check_add_overflow() to calculate the new EOF. Validate it with inode_newsize_ok() before modifying the file. Reproducer, using a file on a CIFS mount: bash -c ' FILE=/mnt/cifs/repro trap "" SIGXFSZ ulimit -f 3072 # RLIMIT_FSIZE = 3 MiB # A regular write is stopped at 3 MiB. dd if=/dev/zero of="$FILE" bs=1M count=4 status=none stat -c "size after write: %s" "$FILE" # Insert 2 MiB into a 2 MiB file. truncate -s 2M "$FILE" fallocate -i -o 0 -l 2M "$FILE" stat -c "size after insert: %s" "$FILE" ' Before this change, the regular write stops at the 3 MiB limit, but insert range grows the file to 4 MiB: dd: error writing '/mnt/cifs/repro': File too large size after write: 3145728 size after insert: 4194304 After this change, insert range also fails at the limit and leaves the 2 MiB file unchanged: dd: error writing '/mnt/cifs/repro': File too large size after write: 3145728 fallocate: fallocate failed: File too large size after insert: 2097152 Fixes: 7fe6fe95b936 ("cifs: add FALLOC_FL_INSERT_RANGE support") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 637836563deb95f4338decf2d2d832c4deef022a Merge: f59c074e76a6a9 46094a7708b794 Author: Linus Torvalds Date: Sun Aug 30 09:57:35 2026 -0700 Merge tag 'locking-urgent-2026-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fix from Ingo Molnar: - Revert a commit to spinlock cleanup guards that got caught up in the subtle limitations & fragility of guards (again...) and caused a regression (Peter Zijlstra) * tag 'locking-urgent-2026-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking: Revert switching guards to _irq_{disable,enable}() commit f59c074e76a6a9ea55818373decdf56c6fddca30 Merge: 0fe792fa9b616b 1b0bab4a873f10 Author: Linus Torvalds Date: Sun Aug 30 09:47:39 2026 -0700 Merge tag 'rust-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Fix KCFI failures, such as in Rust doctests, by disabling function merging when CFI is enabled. Gary reported the LLVM bug to upstream and it is now fixed in their mainline. - Fix 'objtool' fallthrough warnings under the experimental 'CONFIG_RUST_INLINE_HELPERS' by passing (for the combined Rust and helpers code) the LLVM options needed to preserve the unreachable traps that 'rustc' normally emits. In addition, fix 'objtool' errors when LTO is enabled on top, by also filtering out the LTO flags (for the combined Rust and helpers code) so that the traps are kept in place. - Fix 'objtool' warnings by adding one more 'noreturn' function. - Fix 'make rusttest' target when the 'rustc-dev' component is installed and Rust >= 1.82.0, <= 1.87.0 is used. 'kernel' crate: - 'num' module: fix soundness issue in the 'Bounded' conversion from 'bool' by restricting the conversions to unsigned 'Bounded'. - 'jump_label' module: fix future 'make rusttest' target failures when 'ARCH=' is set to an arch different than the host's. - 'list' module: fix incorrect 'pop_back()' comment" * tag 'rust-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: rust: kbuild: disambiguate `zerocopy_derive` for `rusttest` rust: num: restrict bool conversion to unsigned Bounded kbuild: rust: keep Rust objects out of Clang LTO with inline helpers kbuild: rust: preserve unreachable traps with inline helpers rust: cfi: disable function merging if CFI is enabled rust: jump_label: skip arch-specific asm in `testlib` builds objtool/rust: add one more `noreturn` Rust function rust: kernel: list: fix incorrect pop_back example comment commit 0fe792fa9b616b790f03cbeed067b83eeaae7e7e Merge: fb5b59a6a678ba 1a89abc009cb50 Author: Linus Torvalds Date: Sun Aug 30 09:43:01 2026 -0700 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux Pull arm updates from Russell King: "Updates for 7.3: - add module description for kprobes testing module - remove references to CONFIG_CPU_ARM92x_CPU_IDLE options - expand comment in ARM's __switch_to() Also a number of fixes that missed 7.2: - disable broken eBPF on RiscPC - more BKPT fixes (guys, it's a *very* bad idea when everyone uses the BKPT instruction for their own differing purposes) - another preempt-rt fix, this time for siglock / CPU timers - fix another path where we try to send signals to processes with interrupts disabled - acquire mmap write lock for show_pte() with user faults" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux: ARM: 9480/1: entry: expand comment in __switch_to ARM: 9478/1: Remove references to removed CONFIG_CPU_ARM92x_CPU_IDLE options ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults ARM: 9484/1: enable interrupts when unhandled user faults are triggered ARM: 9483/1: select HAVE_POSIX_CPU_TIMERS_TASK_WORK ARM: 9481/2: breakpoint: CFI breakpoints only on demand ARM: 9477/1: Disable broken eBPF JIT on the Risc PC ARM: 9473/1: kprobes: test: add MODULE_DESCRIPTION commit fb5b59a6a678bab054a78d99eecfdb6f5558e82e Merge: 034dd340b08be1 78004e9a87f240 Author: Linus Torvalds Date: Sun Aug 30 09:26:54 2026 -0700 Merge tag 'for-linus' of https://github.com/openrisc/linux Pull OpenRISC updates from Stafford Horne: "One small trivial macro cleanup and one bug fix. The bug fix is to fix an unchecked access in our or1k_atomic syscall, I am debating if we should just deprecate this as there is minimal need for it" * tag 'for-linus' of https://github.com/openrisc/linux: openrisc: fix arbitrary kernel memory access via or1k_atomic syscall openrisc: drop unneeded semicolon commit 034dd340b08be1f2f0477ad16131d609f9dbd53c Merge: 08dbfad3f5040f 5eab74874d1116 Author: Linus Torvalds Date: Sun Aug 30 09:22:00 2026 -0700 Merge tag 'trace-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Fix error output of boot instance creation failure Currently if a boot instance creation fails, instead of printing out the name of the instance that failed, it prints "(null)". That is because it prints "cur_str" that had already been processed by strsep(). Print the saved name instead. While at it, print the error code of the failure. - Fix use-after-free for same named historgrams Histograms can be named so that they can be used in multiple events. But if the named histogram has a variable attached, the second event that uses the named histogram which duplicates it and needs to free the original after duplication leaves the old variable in place and still visible. If another histogram uses than variable, it will use the stale one which will try to reference the freed duplicate histogram and crash the kernel. Free the duplicate variables along with the duplicated histogram data. - Check return value of kthread_run() in event self test The events self tests uses a kthread for testing but does not check if it succeeded in creating a kthread. If the kthread creation were to fail, the code will still try to call kthread_stop() on the error returned. - Fix race between reading trace_pipe and updating subbuffer size If a user is reading the trace_pipe file at the same time they update the ring buffer sub-buffer size, can cause the trace_pipe read to read stale data. Add trace_access_lock() around updating the ring buffer sub-buffer size. - Fix eventfs_inode on failure path in creation of the events directory In the creation of the "events" directory, if after allocating the eventfs_inode a failure is detected, it calls cleanup_ei() which calls free_ei(). The free_ei() will test if eventfs_inode being freed has no children. It is a bug if it does. But on the failure case of the creation of the "events" directory, the children lists have not yet been initialized and the free will trigger a warning because list_empty() on an uninitialized list returns false. Move the initialization into init_ei() where it makes more sense and makes sure that a created eventfs_inode has its lists initialized upon creation. - Check return value of kthread_run() in ftrace direct sample code The sample code that shows how to use the ftrace direct calls does not test the return of kthread_run() to see if it succeeds. Return a failure if the kthread_run() doesn't succeed. - Clear user events state on fork in case of alloc failure On fork, the child gets a pointer to the parent's user events state. It makes a copy of it then updates the child's pointer to it. But if the allocation fails, the duplication function leaves the child with a pointer to its parent's descriptor. When the child cleans up its data, it will free the parent's descriptor while the parent is still using it. In the duplication function, set the child's user_event_mm to NULL before testing if the allocation succeeded, and when it exits it will not free the parent's descriptor. - Fix retry exhaustion in simple ring buffer reader swap simple_ring_buffer_swap_reader_page() starts with retry set to 8 and post-decrements it only after a failed link replacement. On the final attempt, a successful replacement leaves retry at zero, while a failed replacement leaves it at -1. But the check for success expects the retry value to be non-zero and exits with an error on zero. This is the opposite result. Fix it. - Fail nicely when the remote swap_reader_page() returns an error Currently, if the swap_reader_page() of a remote buffer fails, it triggers a WARN_ON_ONCE() and continues normally. Instead, have it exit with an error and a pr_warn() print instead of a full WARNING. * tag 'trace-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: ring-buffer: Stop remote reader update when page swap fails tracing: Fix retry exhaustion in simple ring buffer reader swap tracing/user_events: Clear copied tracing state before fork duplication samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-modify samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-modify eventfs: Initialize ei->children and ei->list in init_ei() tracing: Fix use-after-free in trace_pipe read on sub-buffer order change tracing: Fix crash passing ERR_PTR to kthread_stop() tracing: Fix use-after-free with same-name named triggers tracing: Fix logged instance name on creation failure commit 1a89abc009cb5035d0cb4e5ba48d32b94f30e8e4 Merge: 1039bffd6ae9c7 bb3b2cfeb206f5 Author: Russell King (Oracle) Date: Wed Aug 5 17:08:50 2026 +0100 Merge branches 'fixes' and 'misc' into for-linus commit ef6a1dca8de41a408019310649e6d1b7b21ac4bc Author: Julia Lawall Date: Sun Aug 30 14:36:11 2026 +0200 coccinelle: ifnulldev_put: update error message Update the report and org mode messages to reflect the new function names. Signed-off-by: Julia Lawall commit f83b8a58695cbf419beaa3f63b9d3e264792d8ea Author: Sang-Heon Jeon Date: Mon Aug 24 01:18:19 2026 +0900 coccinelle: ifnulldev_put: update outdated helper names dev_put_track() and dev_hold_track() were renamed to netdev_put() and netdev_hold() by commit d62607c3fe45 ("net: rename reference+tracking helpers"). So update the names. Signed-off-by: Sang-Heon Jeon Signed-off-by: Julia Lawall commit 5264281879ef19b68f61846a7455a627f10b92e8 Author: Sang-Heon Jeon Date: Mon Aug 24 01:18:18 2026 +0900 coccinelle: atomic_as_refcounter: drop atomic_long_dec_and_lock atomic_long_dec_and_lock() has never existed. So drop it from the rules. No functional change. Signed-off-by: Sang-Heon Jeon Signed-off-by: Julia Lawall commit 3beb6e620fae118f1dc1092b08b2c82b4e762b8a Author: Sang-Heon Jeon Date: Mon Aug 24 01:18:17 2026 +0900 coccinelle: kfree_mismatch: drop vmalloc_exec vmalloc_exec() was removed by commit 7a0e27b2a0ce ("mm: remove vmalloc_exec"). So drop it from the rules. No functional change. Signed-off-by: Sang-Heon Jeon Signed-off-by: Julia Lawall commit 729eb52aa17f480a14ec0e7df363deabd41e57a3 Author: Sang-Heon Jeon Date: Mon Aug 24 01:18:16 2026 +0900 coccinelle: pool_zalloc-simple: drop the pci_pool_alloc rules pci_pool_alloc() and pci_pool_zalloc() were removed by commit 88dee3b0efe4 ("PCI: Remove unused pci_pool wrappers"). So drop the pci_pool_alloc rules. No functional change. Signed-off-by: Sang-Heon Jeon Signed-off-by: Julia Lawall commit a155ac8f0c523bd53f412196dcbb104ad1f4595f Author: Boqun Feng Date: Sat Aug 29 14:34:12 2026 -0700 interrupt: Disable interrupt before modifying hardirq_disable counter Currently a softirq may be pending longer then expected if the triggering interrupt happens in-between hardirq_disable_enter() and _local_interrupt_disable() in local_interrupt_disable(): local_interrupt_disable(): hardirq_disable_enter(); ... __irq_exit_rcu(): // false because hardirq_disable_count() is not 0 if (.. && !hardirq_disable_count() && ..) { invoke_softirq(); } _local_interrupt_disable(); , it'll defer the softirq to the next interrupt which can be forever. The order between hardirq_disable_enter() and _local_interrupt_disable() is to optimize re-disabling interrupts if they are already disabled, but as 1) local_interrupt_disable() is not widely used yet and 2) the proper way to achieve this optimization may need fixing up the counter at entry/exit time [1], so reverse the order for now to avoid the softirq pending issue. Because of this fix, the part of saving the current state is separated from irq disabling, and the logic of local_interrupt_disable() becomes: local_irq_save(flags); if (counter++ == 0) { this_cpu(local_interrupt_disable_state) = flags; } Therefore change the helper function _local_interrupt_disable() to _local_interrupt_save_state() which only saves the current irqflags (when interrupts get disabled the first time). Fixes: e901c1510e24 ("irq,spin_lock: Add counted interrupt disabling/enabling") Reported-by: Thomas Gleixner Signed-off-by: Boqun Feng Signed-off-by: Thomas Gleixner Reviewed-by: Bradley Morgan Link: https://patch.msgid.link/20260829213412.14303-1-boqun@kernel.org Link: https://lore.kernel.org/lkml/87v78wezid.ffs@fw13/ [1] Closes: https://lore.kernel.org/lkml/87jypbfu1t.ffs@fw13/ commit 03c6ecc4b4b13a3901f207152451fdd2d82e40c4 Author: Jacopo Labardi Date: Sun Aug 30 02:15:36 2026 +0200 ntfs: fix FITRIM range alignment ntfs_trim_fs() aligns the start of a free extent up to the device discard granularity, but derives the discard length by aligning the original extent length down. When the free extent start is not discard-aligned, adding that length to the aligned start can extend the discard past the free extent and into allocated clusters. For example, with 4 KiB clusters and 32 KiB discard granularity, the free extent [4 KiB, 36 KiB) becomes the discard range [32 KiB, 64 KiB), so 28 KiB beyond the free extent may be discarded. Align the absolute end of the free extent down and derive the length from the two aligned endpoints. Skip extents that contain no full discard unit. Reproduced with a 4 KiB-cluster NTFS filesystem on scsi_debug configured for 32 KiB discard granularity and read-zero-after-trim. Before this change, FITRIM zeroed seven allocated 4 KiB clusters following an unaligned 32 KiB hole. With this change, the same data remains intact across FITRIM and remount. Fixes: 11ccc9107dc4 ("ntfs: update runlist handling and cluster allocator") Cc: stable@vger.kernel.org Assisted-by: OpenAI Codex:GPT-5.6 Sol Max Signed-off-by: Jacopo Labardi Signed-off-by: Namjae Jeon commit 41a52ba4a5fe25b2cca431fe76fb5f3d8ad35139 Author: Zhan Xusheng Date: Fri Aug 28 12:58:43 2026 +0800 ntfs: read WOF chunks outside the decompression lock WOF decompression uses four module-global workspaces, one per compression format, each with a static mutex. ntfs_read_wof_compressed_block() takes that mutex once and holds it across the whole chunk loop, so both block reads run inside it: mutex_lock(ws->lock); for each chunk { parse_wof_chunk_table(..., ws->input, ...); /* reads disk */ ntfs_read_wof_chunk(..., ws->input, ...); /* reads disk */ decompress into ws->output; } mutex_unlock(ws->lock); Readers of system-compressed files then serialise system-wide on the disk waits, not just on the decompressor scratch the lock exists for. One reader sleeping in submit_bio_wait() blocks all the rest. The waits dominate. Reading an 8 MiB xpress4k file (2048 chunks at a 48% compressed ratio, so 2048 acquisitions and 4096 block reads) and timing ws->lock against the part of it spent in ntfs_bdev_read(): backing store held of that in I/O held after virtio, host page cache 348 ms 321 ms (92%) 24.6 ms virtio, throttled 100 MB/s 978 ms 948 ms (96%) 36.6 ms The page-cache row is a lower bound, having no seek cost at all, and the share still grows with slower storage because only the wait scales while decompression stays near 26 ms. The reads are inside the lock only because they land in ws->input, a buffer shared through the workspace. Nothing else requires it: parse_wof_chunk_table() and ntfs_read_wof_chunk() already take the buffer as a parameter and both set *chunk_mem to a pointer inside it, so a caller-owned buffer works unchanged. Allocate that buffer per call, do both reads without the lock, and take the lock only around decompression, which is the step needing ws->output and ws->scratch. squashfs is arranged this way already: its squashfs_decompress() is handed a bio that has been read, and locks only for the CPU work. Block reads are unchanged in number, they just no longer run under the lock, and hold time stops tracking device speed. This also unnests two per-inode locks from the global one, runlist->lock taken by both reads and base_ni->mrec_lock taken for a resident stream. A resident chunk needs no I/O at all, yet used to queue behind a reader blocked in submit_bio_wait() and then take mrec_lock inside the global mutex. The buffer is 4608 bytes for xpress4k and at most 33280 for lzx32k. This path already does GFP_NOFS allocations per call in ntfs_attr_iget(), and in ntfs_attr_get_search_ctx() for a resident stream, so one more does not change how it behaves under memory pressure. The workspace keeps output and scratch, 4 KiB to 32 KiB and 6224 bytes (xpress) or 10240 (lzx), and its "already allocated" test moves from ws->input to ws->output. The lock is now taken per chunk rather than per call, which differs only for a folio spanning several chunks: a few more uncontended mutex operations in exchange for not holding it across the reads between them. Verified under QEMU against an uncompressed copy of the same data, on an 8 MiB file and a 100000 byte one, the latter covering the tail chunk that is not a full comp_unit. Signed-off-by: Zhan Xusheng Signed-off-by: Namjae Jeon commit 28d75dd3eb60812b3a87cbdf0d52c42f51b28a78 Author: Yonghong Song Date: Fri Aug 28 10:05:34 2026 -0700 selftests/bpf: Bound the offset accumulator in __tld_fetch_key() The LLVM commit c7f4a76da024 [1] "[InstCombine] fold ((x - 1) | (2^k - 1)) + 1 to (x + (2^k - 1)) & -(2^k)" caused test_task_local_data.bpf.o to fail verification: The sequence of 8193 jumps is too complex. processed 188770 insns (limit 1000000) max_states_per_insn 34 total_states 8238 peak_states 12330 mark_read 0 TLD_ROUND_UP(x, 8) expands to ((((x) - 1) | 7) + 1), exactly the pattern that [1] rewrites, so the accumulation in __tld_fetch_key() off += TLD_ROUND_UP(metadata[i].size, 8); is now compiled as (x + 7) & -8 instead of ((x - 1) | 7) + 1. Both are correct, but they leave the verifier in very different states. Note that 'off' is marked as precise. Without [1], "size - 1" wraps at zero (size is a __u16), so the verifier loses all bounds on the increment: 211: (69) r1 = *(u16 *)(r1 +62) ; R1=scalar(...,umax32=0xffff,var_off=(0x0; 0xffff)) 212: (04) w1 += -1 ; R1=scalar(smin=0,smax=umax=0xffffffff,smin32=-1,smax32=0xfffe,var_off=(0x0; 0xffffffff)) 213: (44) w1 |= 7 ; R1=scalar(smin=umin=umin32=7,smax=umax=0xffffffff,var_off=(0x7; 0xfffffff8)) 214: (0c) w6 += w1 ; R6=scalar(smin=umin=umin32=7,smax=umax=0xffffffff,var_off=(0x7; 0xfffffff8)) 215: (04) w6 += 1 ; R6=scalar(smin=0,smax=umax=umax32=0xfffffff8,var_off=(0x0; 0xfffffff8)) Note that 'w6' will be used in the next iteration. In the next iteration after insn 215, the R6 range will be the same as previous iteration. The iterator loop converges at depth 2. With [1] the increment stays precisely bounded at [0, 0x10006]: 211: (69) r9 = *(u16 *)(r1 +62) ; R9=scalar(...,umax32=0xffff,var_off=(0x0; 0xffff)) 212: (04) w9 += 7 ; R9=scalar(...,umax32=0x10006,var_off=(0x0; 0x1ffff)) 213: (54) w9 &= 131064 ; R9=scalar(...,umax32=0x10006,var_off=(0x0; 0x1fff8)) 214: (0c) w9 += w6 ; R9=scalar(...,umax32=0x10006,var_off=(0x0; 0x1fff8)) 215: (bf) r1 = r10 216: (07) r1 += -8 217: (85) call bpf_iter_num_next 218: (bc) w6 = w9 In the next iteration, we will have 211: (69) r9 = *(u16 *)(r1 +62) ; R9=scalar(...,umax32=0xffff,var_off=(0x0; 0xffff)) 212: (04) w9 += 7 ; R9=scalar(...,umax32=0x10006,var_off=(0x0; 0x1ffff)) 213: (54) w9 &= 131064 ; R9=scalar(...,umax32=0x10006,var_off=(0x0; 0x1fff8)) 214: (0c) w9 += w6 ; R9=scalar(...,umax32=0x2000c,var_off=(0x0; 0x3fff8)) ... so 'off' umax grows by 0x10006 on every iteration and the loop-head state never repeats: 218: (bc) w6 = w9 ; R6=scalar(...,umax32=0x10006,var_off=(0x0; 0x1fff8)) 218: (bc) w6 = w9 ; R6=scalar(...,umax32=0x2000c,var_off=(0x0; 0x3fff8)) 218: (bc) w6 = w9 ; R6=scalar(...,umax32=0x30012,var_off=(0x0; 0x3fff8)) ... 218: (bc) w6 = w9 ; R6=scalar(...,umax32=0xff95fd6,var_off=(0x0; 0xffffff8)) That last one is iterator depth 4090. Saturating umax would take ~65531 iterations; the verifier gives up long before that. Note the loop does not diverge from the start. widen_imprecise_scalars() blows 'off' up to an unbounded scalar while it is still imprecise, and that alone converges the first three passes through the loop at depth 4. Once mark_chain_precision() reaches the loop body, maybe_widen_reg() starts skipping the register, and no widening ever happens again. In the failing log widening fires exactly 6 times out of 4098 arrivals at the iter_next() checkpoint, all of them before the umax starts accumulating. With [1] and this fix, here is one full trip through the loop body, entered with 'off' (R6) already clamped by the previous iteration: 208: frame1: R6=scalar(...,umax32=4088,var_off=(0x0; 0xff8)) 208: (67) r7 <<= 6 ; R7=scalar(...,umax32=3968,var_off=(0x0; 0xfc0)) 209: (bf) r1 = r9 ; R1=mem(id=54,sz=4036,imm=4) 210: (0f) r1 += r7 211: (69) r1 = *(u16 *)(r1 +62) ; R1=scalar(...,umax32=0xffff,var_off=(0x0; 0xffff)) 212: (04) w1 += 7 ; R1=scalar(...,umax32=0x10006,var_off=(0x0; 0x1ffff)) 213: (54) w1 &= 131064 ; R1=scalar(...,umax32=0x10006,var_off=(0x0; 0x1fff8)) 214: (0c) w1 += w6 ; R1=scalar(...,umax32=0x10ffe,var_off=(0x0; 0x1fff8)) R6=scalar(...,umax32=4088,var_off=(0x0; 0xff8)) 215: (bc) w6 = w1 ; R6=scalar(...,umax32=0x10ffe,var_off=(0x0; 0x1fff8)) 216: (26) if w1 > 0xff8 goto pc+1 ; R6=scalar(...,umax32=4088,var_off=(0x0; 0xff8)) 217: (05) goto pc-27 This makes the loop body a fixpoint. 'off' (w6) enters at 208 as [0, 4088] with var_off=(0x0; 0xff8); the increment computed at 212/213 is [0, 0x10006], so 214/215 leave it at [0, 0x10ffe]; then 216 truncates it straight back to [0, 4088]/(0x0; 0xff8), and only then is the back edge at 217 taken. Convergence no longer depends on the widening window above. Verification converges at iterator depth 3. [1] https://github.com/llvm/llvm-project/pull/216436 Signed-off-by: Yonghong Song Link: https://lore.kernel.org/r/20260828170534.1011183-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov commit 08dbfad3f5040f5bdb6c529da20d6d4e81fefd72 Merge: cf72cbb39da84b 12e67eb89eb2b9 Author: Linus Torvalds Date: Sat Aug 29 11:55:36 2026 -0700 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi Pull more SCSI updates from Martin Petersen: "Remaining updates for the 7.3 merge window. The only core change is enabling context analysis for the SCSI layer and UFS. The remaining changes are either bug fixes or hardening" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi: (26 commits) scsi: snic: Fix SCSI host leak on workqueue allocation failure scsi: MAINTAINERS: Update my email address scsi: MAINTAINERS: Leave the cumana_1 and oak drivers to the RISCPC maintainers scsi: leapraid: Standardize NCQ priority sysfs attributes scsi: leapraid: Serialize firmware log mmap with teardown scsi: leapraid: Balance host references for firmware log VMAs scsi: lpfc: Remove unnnecessary NULL check scsi: qla2xxx: Fix an loop timeout test scsi: qla2xxx: Fix an error code in qla_get_tmf() scsi: ibmvfc: Fix use of uninitialized rport in ibmvfc_do_work() scsi: core: Enable context analysis for hosts.o scsi: lpfc: Replace strlcat() with sysfs_emit_at() in the sysfs show functions scsi: lpfc: Replace strlcat() with seq_buf in the debugfs dump helpers scsi: lpfc: Replace strlcat() with seq_buf in lpfc_rx_monitor_report() scsi: lpfc: Replace strlcat() with scnprintf() in lpfc_vport_symbolic_node_name() scsi: lpfc: Replace strlcat() with seq_buf in lpfc_info() scsi: core: Enable context analysis scsi: core: Protect host state changes with the host lock scsi: core: Add lock context annotations scsi: core: Pass the SCSI host pointer directly to scanning functions ... commit 78004e9a87f240df03e2f73120d291763c32e0a7 Author: Ali Ahmet Memis Date: Fri Aug 21 01:45:27 2026 +0000 openrisc: fix arbitrary kernel memory access via or1k_atomic syscall sys_or1k_atomic() (syscall 244 in the "or1k" ABI) takes two user pointers, v1 and v2, and swaps the words they point to in hand-written assembly. l.lwz r29,0(r4) l.lwz r27,0(r5) l.sw 0(r4),r27 l.sw 0(r5),r29 The pointers are not checked with access_ok(). The four memory accesses also have no exception table entries. A caller passes a kernel address as either pointer, and the syscall reads from and writes to it directly. This gives an unprivileged process a kernel read/write primitive. It overwrites kernel data such as the sys_call_table, gaining code execution in kernel context. Check both pointers before entering the critical section. Add fixups for the four memory accesses so faults on valid but unmapped user addresses return -EFAULT. [shorne@gmail.com: fix comment style] Fixes: 9d02a4283e9c ("OpenRISC: Boot code") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Signed-off-by: Stafford Horne commit d5869dae5080e976d4b03cc33eb7ceb527f242bf Author: Maurizio Lombardi Date: Fri Jul 17 16:38:28 2026 +0200 scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands When a LUN_RESET aborts a WRITE command that is in the TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits for the frontend to finish processing. If the initiator subsequently sends the remaining dataout PDUs, __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in target_put_cmd_and_wait(), leading to a deadlocked target worker thread. Fix this by explicitly calling target_complete_cmd() when the final dataout PDU is received for an aborted WRITE command. target_complete_cmd() detects the CMD_T_ABORTED flag and cleanly routes the command into target_abort_work, allowing the abort completion to successfully unblock. Signed-off-by: Maurizio Lombardi Reviewed-by: Laurence Oberman Link: https://patch.msgid.link/20260717143828.76291-2-mlombard@redhat.com Signed-off-by: Martin K. Petersen (Oracle) commit c46cc9cee39bd6f395ab9ac98b1794705df13d7c Author: sangram kumar yerra Date: Tue Aug 18 16:58:30 2026 +0530 scsi: ufs: ufs-pci: Add MCQ support for Intel UFS 4.0 controllers The Intel UFS 4.0 PCI variant (PCI ID 8086:D335) advertises MCQ support in its capability register. However, ufshcd_alloc_mcq() also requires an .op_runtime_config hook to locate the per-queue operation and runtime (OPR) register blocks, which was not provided by this variant operations table. As a result, MCQ initialization fails and ufshcd_add_scsi_host() prints "MCQ mode is disabled, err=%d\n" before falling back to legacy single-doorbell (SDB) mode. Add ufs_intel_mcq_config_resource() to initialize the MCQ configuration base and add ufs_intel_op_runtime_config() to set up the OPR register offsets and stride. Wire both hooks into the variant operations table so MCQ is enabled when supported by the hardware. Fixes: 096cd6b7adf2 ("scsi: ufs: ufs-pci: Add support for Intel Nova Lake") Signed-off-by: sangram kumar yerra Reviewed-by: Adrian Hunter Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260818112830.453402-3-sangram.k.y@intel.com Signed-off-by: Martin K. Petersen (Oracle) commit ef675ea168453a9b3e635b8ac543f92938bdd03b Author: sangram kumar yerra Date: Tue Aug 18 16:58:29 2026 +0530 scsi: ufs: ufs-pci: Add support for Intel UFS 4.0 HS-Gear5 Reliable HS-Gear5 operation on Intel UFS 4.0 controllers requires configuring PA_INITIAL_ADAPT before changing the power mode. Without this setting, the link fails to train reliably at Gear5. Add a pwr_change_notify() hook to configure the adaptation mode before the power mode transition. Enable this only for UFS 4.0 and later controllers by checking hba->ufs_version. Wire the hook into the existing Meteor Lake family variant operations table (ufs_intel_mtl_hba_vops) instead of introducing a separate table, since the Intel UFS 4.0 PCI variant (PCI ID 8086:D335) already uses this vops table and the hook is internally gated on UFS version >= 4.0. Use PA_INITIAL_ADAPT when the negotiated TX power mode is FAST_MODE or FASTAUTO_MODE. Otherwise, reset the adaptation mode to PA_NO_ADAPT, which is the default setting. Fixes: 096cd6b7adf2 ("scsi: ufs: ufs-pci: Add support for Intel Nova Lake") Signed-off-by: sangram kumar yerra Reviewed-by: Adrian Hunter Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260818112830.453402-2-sangram.k.y@intel.com Signed-off-by: Martin K. Petersen (Oracle) commit 11300f8ddee301dca9914561f24bea4168de076d Author: Xu Rao Date: Mon Jul 6 16:44:43 2026 +0800 scsi: sg: Report request-table problems when any status is set SG_GET_REQUEST_TABLE reports per-request diagnostic state through sg_req_info::problem. The field is meant to indicate whether there is an error to report for a completed request. sg_fill_request_table() currently combines masked_status, host_status and driver_status with bitwise AND. This only reports a problem when all three status fields are non-zero at the same time. A normal target check condition, for example, has masked_status set while host_status and driver_status may both be zero, so the request is incorrectly reported as clean. Use the same condition as sg_new_read(), which sets SG_INFO_CHECK when any of the three status fields is non-zero. Signed-off-by: Xu Rao Reviewed-by: Bart Van Assche Cc: stable@vger.kernel.org Link: https://patch.msgid.link/26BF67F369E2123E+20260706084443.805598-1-raoxu@uniontech.com Signed-off-by: Martin K. Petersen (Oracle) commit 419d129f970aaa6567dbac366b0c93784bf9ec97 Author: Milan P. Gandhi Date: Wed Aug 12 16:03:44 2026 +0530 scsi: mpi3mr: Fix target device refcount leak in mpi3mr_sas_port_add() mpi3mr_get_tgtdev_by_addr() increments the target device kref when it returns a device. If a subsequent error triggers a goto out_fail after the tgtdev reference is acquired, the reference is never released because the out_fail path does not call mpi3mr_tgtdev_put(). This prevents the target device structure from ever being freed. Add a tgtdev put in the out_fail path, guarded by a NULL check since tgtdev is only acquired for SAS_END_DEVICE types and the same cleanup path is shared by earlier error cases where tgtdev is still NULL. Fixes: e22bae30667a ("scsi: mpi3mr: Add expander devices to STL") Signed-off-by: Milan P. Gandhi Reviewed-by: Laurence Oberman Link: https://patch.msgid.link/20260812103344.174247-3-mgandhi@redhat.com Signed-off-by: Martin K. Petersen (Oracle) commit dba9e2181ca5e875f98b8b9b4535cdaab87dcb0d Author: Milan P. Gandhi Date: Wed Aug 12 16:03:43 2026 +0530 scsi: mpi3mr: Fix NULL pointer dereference in mpi3mr_sas_port_add() sas_port_alloc_num() can return NULL on memory allocation failure. The return value is passed directly to sas_port_add() without a NULL check, which causes a NULL pointer dereference. Additionally, if sas_port_add() fails, the allocated port is not freed before jumping to out_fail, leaking the sas_port structure. Call sas_port_free() to properly release it. Fixes: e22bae30667a ("scsi: mpi3mr: Add expander devices to STL") Signed-off-by: Milan P. Gandhi Reviewed-by: Laurence Oberman Link: https://patch.msgid.link/20260812103344.174247-2-mgandhi@redhat.com Signed-off-by: Martin K. Petersen (Oracle) commit b2ededcb271b37510366cbf6853be193d681ba5c Author: Nitin Rawat Date: Tue Aug 25 20:22:03 2026 +0530 scsi: ufs: ufs-qcom: Fix sequential read variance The current devfreq downdifferential threshold of 5% causes overly aggressive frequency downscaling, leading to performance degradation sometimes during sequential read workloads. Update the UFS devfreq downdifferential threshold to 65. This widens the hysteresis window and prevents overly aggressive downscaling, ensuring that frequency is maintained for loads above 5% and scaling down occurs only when utilization falls below this level, while scale-up still triggers above the 70% threshold. Reviewed-by: Konrad Dybcio Signed-off-by: Nitin Rawat Link: https://patch.msgid.link/20260825145203.265579-3-nitin.rawat@oss.qualcomm.com Signed-off-by: Martin K. Petersen (Oracle) commit a3756f53baf1830c65149cfcb81cb96360976cf3 Author: Nitin Rawat Date: Tue Aug 25 20:22:02 2026 +0530 scsi: ufs: ufs-qcom: Restore HS/LS link startup mode for Qualcomm UFS controller v6.2+ The link startup mode (HS LSS - high-speed link startup, or LS LSS - low-speed link startup) is decided in the boot stage based on the bootconfig GPIO. This selection is carried forward through the secondary stage bootloaders and finally to HLOS via the spare configuration register (REG_UFS_DEBUG_SPARE_CFG). On Qualcomm UFS controller v6.2 and later, bit 31 in the spare configuration register indicates the high-speed link startup mode selection, as per the Hardware Programming Guide (HPG). The spare register value is read during host driver initialization but gets cleared after UFS reset. Preserve the spare register value during initialization and restore it during link startup to maintain the bootloader-configured link startup mode. Signed-off-by: Nitin Rawat Tested-by: Mukesh Ojha Link: https://patch.msgid.link/20260825145203.265579-2-nitin.rawat@oss.qualcomm.com Signed-off-by: Martin K. Petersen (Oracle) commit 9a69cc5f192f356c1c7b4fa2821da4a8cf684829 Author: Muhammad Falak R Wani Date: Thu Aug 27 16:50:38 2026 +0530 scsi: ibmvfc: Document protocol parameter of ibmvfc_alloc_target() Commit 249313b3f7b5 ("scsi: ibmvfc: allocate targets based on protocol") added a protocol parameter to ibmvfc_alloc_target() but did not describe it in the function's kernel-doc comment, so a W=1 build warns: drivers/scsi/ibmvscsi/ibmvfc-core.c:4996: warning: Function parameter or struct member 'protocol' not described in 'ibmvfc_alloc_target' Add the missing parameter description. Fixes: 249313b3f7b5 ("scsi: ibmvfc: allocate targets based on protocol") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202608270829.lHI1FAdO-lkp@intel.com/ Signed-off-by: Muhammad Falak R Wani Reviewed-by: Dave Marquardt Acked-by: Tyrel Datwyler Link: https://patch.msgid.link/b073968ae020b6ae0240e91341a92f428587ebd9.1787828961.git.falakreyaz@gmail.com Signed-off-by: Martin K. Petersen (Oracle) commit 9a0716348dafe9c6d3529991a50b96c6d18abb51 Author: Muhammad Falak R Wani Date: Thu Aug 27 16:50:37 2026 +0530 scsi: ibmvfc: Fix kernel-doc name for ibmvfc_scsi_relogin() Commit e0fca728a89f ("scsi: ibmvfc: delete NVMe/FC targets as well as SCSI") renamed ibmvfc_relogin() to ibmvfc_scsi_relogin() but left the kernel-doc comment referring to the old name, so a W=1 build warns: drivers/scsi/ibmvscsi/ibmvfc-core.c:1901: warning: expecting prototype for ibmvfc_relogin(). Prototype was for ibmvfc_scsi_relogin() instead Update the kernel-doc comment to use the current function name. Fixes: e0fca728a89f ("scsi: ibmvfc: delete NVMe/FC targets as well as SCSI") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202608271026.iMLmrwz4-lkp@intel.com/ Signed-off-by: Muhammad Falak R Wani Reviewed-by: Dave Marquardt Acked-by: Tyrel Datwyler Link: https://patch.msgid.link/dd866cf2321381694af027fbd726bcbd63ac3751.1787828961.git.falakreyaz@gmail.com Signed-off-by: Martin K. Petersen (Oracle) commit 3f92a64545165bdbb36dee8fa35626b295463313 Author: Runyu Xiao Date: Mon Aug 24 19:36:18 2026 +0800 scsi: pm8001: Use rollback index when freeing MSI-X vectors pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop. Fixes: a76037ff3479 ("scsi: pm8001: switch to pci_irq_alloc_vectors") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Acked-by: Jack Wang Link: https://patch.msgid.link/20260824113618.2239100-1-runyu.xiao@seu.edu.cn Signed-off-by: Martin K. Petersen (Oracle) commit 98f0a1422e285f6132a73932ebd4fe5c6f513261 Author: Linmao Li Date: Wed Aug 19 19:42:41 2026 +0800 scsi: fnic: Initialize the NVMe local port info before registering nvfnic_add_lport() declares struct nvme_fc_port_info on the stack and fills in four of its five members, leaving dev_loss_tmo holding whatever the stack happened to contain before the call. The structure is then handed to nvme_fc_register_localport(). nvfnic_add_tport(), which registers the remote port a few lines further down, memsets its own struct nvme_fc_port_info first, so only the local port path passes uninitialized data across the transport interface. The NVMe/FC transport documents dev_loss_tmo as "Used only on a remoteport" and does not read it in nvme_fc_register_localport(), so there is no behavioural change today. Initialize the structure anyway: the driver must not depend on which members the transport happens to consume, and any member added to struct nvme_fc_port_info later would silently start out as stack garbage. Signed-off-by: Linmao Li Tested-by: Karan Tilak Kumar Reviewed-by: Karan Tilak Kumar Link: https://patch.msgid.link/20260819114242.3598034-2-lilinmao@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) commit cf72cbb39da84b6f02f90c07f33b102fc10b16f0 Merge: a99d741df7372f 2cf20c4e0f72d5 Author: Linus Torvalds Date: Fri Aug 28 16:51:14 2026 -0700 Merge tag 'io_uring-7.3-20260828' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull io_uring fixes from Jens Axboe: "A few smaller fixes for io_uring that should go into the 7.3-rc1 kernel, all three headed to stable as well. This contains: - A few fixes around cancellation and teardown for waitid - Cap the user size for the query interface copy-out" * tag 'io_uring-7.3-20260828' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: io_uring/waitid: avoid siginfo copy during ring teardown io_uring/waitid: honor task_work cancellation io_uring/query: cap user size passed to copy_struct_to_user commit a99d741df7372f2175677673d78a6335f3e0706f Merge: 4cc4cc367fd5c3 a8b02aa825803e Author: Linus Torvalds Date: Fri Aug 28 16:37:55 2026 -0700 Merge tag 'drm-next-2026-08-29' of https://gitlab.freedesktop.org/drm/kernel Pull more drm updates from Dave Airlie: "As mentioned last week, an msm pull request fell down the side of the couch or whatever the email equivalent of that is. This has the msm next stuff + the usual fixes for amd/intel. core: - use drm_warn instead of warn msm: - Bindings: - Added Shikra support - Document a840, a704, a722 - Core: - Use drm_client buffers for fbdev emulation - teardown fixes - ARM32 DMA fixup - Remove objects from evict list when re-validated - Bunch of corner case and error path fixes - DPU: - Dropped dev_pm_opp_set_rate(0) preventing burnout - Fixed SSPP offsets of Kaanapali - DP: - Dropped dev_pm_opp_set_rate(0) preventing burnout - Cleaned up core code in preparation for MST support - Fixed prepare() to let Pipewire continue in case of the unplugged cable - GPU: - Add support for a704 - Add support for a722 - HDMI: - Simplifed register access amdgpu: - eGPU fixes - Runtime PM fix - UserQ fixes - Backlight fix - Discovery sysfs fix - Reset handling fixes - Buffer func handling fix for xgmi - VCN boundary check fix - DC lut handling fixes - MES fixes - UVD fix - VCE 3 fix - Enforce isolation fix - HPD fix for VGA/LVDS - DML fix - DCN 6 fixes - DC gpu reset fix amdkfd: - Fix return value - CU occupancy for GFX 11 - CU occupancy for GFX 12/12.1 - Queue bounds checking fix - SVM fixes - CRIU bounds checking fix radeon: - iMac display fix xe: - error message cleanups - i2c global register definitions as dependency for xe/i2c fixes - Media workardound - Add CCS to gt_idle debugfs print - Page fault related fix - i2c related fixes - System Controller mailbox bit fix" * tag 'drm-next-2026-08-29' of https://gitlab.freedesktop.org/drm/kernel: (121 commits) drm/xe/sysctrl: Read mailbox phase bit from hardware drm/xe/i2c: Keep the i2c controller always enabled drm/xe/i2c: Fix the interrupt handling i2c: designware: Global register definitions drm/xe: Reject page faults from non-fault-mode scratch VMs drm/xe/xe_gt_idle: Add CCS to the powergating info print drm/xe: Do not apply WA 14025883347 to media 3503 drm/amd/display: fix dc_lock leak on GPU reset error paths drm/amd/display: Fix redundant GPUVMEnable checks in dcn6 flip schedule drm/amd/display: Fix wrong bytes-per-pixel value for dml2_422_packed_10 drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore drm/amdgpu/userq: fix lock missing for userq fence error set drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram drm/amdkfd: Fix error path at svm_migrate_copy_to_ram drm/amd/display: Log details when failing to register HPD IRQ drm/amd/display: Fix HPD consideration for VGA/LVDS connectors on DCE drm/amdgpu: clamp the isolation index for rings outside a partition drm/amdkfd: Reject zero-sized AQL queue allocations after size halving drm/amdgpu: Fix VCE 3 ring align_mask drm/kfd: Add CU occupancy support to GFX12.1 ... commit 4cc4cc367fd5c37ddef3279038bccbf152ef68d9 Merge: 548e7bcd0c5460 05ec76cfbce653 Author: Linus Torvalds Date: Fri Aug 28 16:32:12 2026 -0700 Merge tag 'for-linus-7.3-1' of https://github.com/cminyard/linux-ipmi Pull ipmi updates from Corey Minyard: "Several cleanup on error fixes and a missing RCU wait and proper validation on a received message in one place. The biggest change is the initialization of the driver can be done asynchronously on a work queue. That saves significant boot time" * tag 'for-linus-7.3-1' of https://github.com/cminyard/linux-ipmi: ipmi: Fix use-after-free of cmd_rcvr in _ipmi_destroy_user() ipmi:msghandler: Cancel work cleanly on an error ipmi:si: Add async init to ipmi_si char: ipmi: use named initializers for acpi_device_id ipmi: Fix leak in __ipmi_bmc_register ipmi: Remove all sysfs files on registration failure ipmi: si: Fix NULL pointer dereference after failed registration ipmi: ipmb: validate write message length commit 2188569e7e1b0bc3f3b557dc97ab7a02befc11c8 Author: Xin Long Date: Wed Aug 26 15:49:04 2026 -0400 sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START The SCTP_CMD_TIMER_START handler checks timer_pending() before calling timer_reduce(). The timer can expire and detach between these operations, causing timer_reduce() to rearm the timer without taking the association reference required for the newly armed timer. The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown. Use the return value of timer_reduce() to determine whether the timer was actually armed. Take the association reference only when timer_reduce() successfully starts a new timer, closing the race between checking the timer state and rearming it. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative. Fixes: 20a785aa52c8 ("sctp: Don't add the shutdown timer if its already been added") Reported-by: Zero Day Initiative Signed-off-by: Xin Long Link: https://patch.msgid.link/9d8f1b5c50329d5ea7c642128d35681abaa9ed20.1787773744.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski commit b84cc38f3f0da7bd2e02f5165b653379c5eb8902 Merge: 7e1d6caa9c6bd8 385e474086c2e7 Author: Jakub Kicinski Date: Fri Aug 28 16:09:04 2026 -0700 Merge branch 'tcp-fix-use-after-free-in-do_tcp_getsockopt' Cen Zhang says: ==================== tcp: fix use-after-free in do_tcp_getsockopt() do_tcp_getsockopt() has two lockless reads of icsk_ca_ops. Since BPF struct_ops congestion control made icsk_ca_ops point to dynamically allocated memory, a concurrent setsockopt(TCP_CONGESTION) can replace the pointer and free the old object while either reader is using it. Patch 1 fixes the TCP_CONGESTION path by copying ca_ops->name to a stack buffer while holding rcu_read_lock(). It also uses READ_ONCE() for the lockless load and annotates the relevant icsk_ca_ops stores with WRITE_ONCE(). Patch 2 fixes the TCP_CC_INFO path by keeping the READ_ONCE() load, ca_ops->get_info lookup, and call inside an RCU read-side critical section. ==================== Link: https://patch.msgid.link/cover.1787870710.git.blbllhy@gmail.com Signed-off-by: Jakub Kicinski commit 385e474086c2e7e29e2dded690be40dc273e20ee Author: Cen Zhang (Microsoft Security FORGE Labs) Date: Thu Aug 27 19:55:11 2026 -0400 tcp: fix use-after-free in do_tcp_getsockopt(TCP_CC_INFO) do_tcp_getsockopt() reads icsk->icsk_ca_ops and dereferences the get_info function pointer without rcu_read_lock(). With BPF struct_ops congestion control, ca_ops can point to dynamically allocated memory that is freed concurrently, resulting in a use-after-free when the kernel dereferences or calls through the stale pointer. BUG: KASAN: slab-use-after-free in do_tcp_getsockopt+0x2037/0x23e0 Read of size 8 at addr ffff888013701258 by task exploit/149 do_tcp_getsockopt+0x2037/0x23e0 (net/ipv4/tcp.c:4564) tcp_getsockopt+0x91/0xf0 __sys_getsockopt+0xf7/0x170 Fix this by wrapping the ca_ops load and get_info call within rcu_read_lock()/rcu_read_unlock(), and using READ_ONCE() to load the icsk_ca_ops pointer. Fixes: 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf") Suggested-by: Eric Dumazet Cc: AutonomousCodeSecurity@microsoft.com Cc: stable@vger.kernel.org Reviewed-by: Eric Dumazet Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) Reviewed-by: Jiayuan Chen Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/65fd3816ed5d541d9edd4bf4fcf97104a2cf907a.1787870710.git.blbllhy@gmail.com Signed-off-by: Jakub Kicinski commit 5271b79b7ad68dcb222e893773f92bdabf7750f3 Author: Cen Zhang (Microsoft Security FORGE Labs) Date: Thu Aug 27 19:55:10 2026 -0400 tcp: fix use-after-free in do_tcp_getsockopt(TCP_CONGESTION) do_tcp_getsockopt() reads icsk->icsk_ca_ops->name without holding rcu_read_lock(). Since commit 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf"), icsk_ca_ops can point to dynamically allocated BPF struct_ops memory that may be freed concurrently via setsockopt(TCP_CONGESTION), leading to a use-after-free. BUG: KASAN: slab-use-after-free in _copy_to_user+0x37/0x60 Read of size 16 at addr ffff888013505260 by task exploit/149 _copy_to_user+0x37/0x60 do_tcp_getsockopt+0x158a/0x2460 (net/ipv4/tcp.c:4585) tcp_getsockopt+0x91/0xf0 __sys_getsockopt+0xf7/0x170 Fix this by holding rcu_read_lock() around the ca_ops->name access, using READ_ONCE() to load icsk_ca_ops, and copying the name to a stack buffer before releasing the lock. Also annotate the relevant icsk_ca_ops stores with WRITE_ONCE() to fix the accompanying KCSAN data-race issue. Fixes: 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf") Suggested-by: Eric Dumazet Reported-by: Xiang Mei (Microsoft) Link: https://lore.kernel.org/all/20260821182449.79785-2-blbllhy@gmail.com/ Cc: AutonomousCodeSecurity@microsoft.com Cc: stable@vger.kernel.org Reviewed-by: Eric Dumazet Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) Reviewed-by: Jiayuan Chen Reviewed-by: Matthieu Baerts (NGI0) Reviewed-by: Breno Leitao Link: https://patch.msgid.link/d3f97f1acbf0010898148be6e6406e4b8b4a5c84.1787870710.git.blbllhy@gmail.com Signed-off-by: Jakub Kicinski commit 7e1d6caa9c6bd8e89a0639ae44be8b23f43386fc Merge: 28a57fb2c5df4d 251367a0a3319f Author: Jakub Kicinski Date: Fri Aug 28 15:56:11 2026 -0700 Merge branch 'net-sched-fix-remaining-actions-notification-accounting-issues' Victor Nogueira says: ==================== net/sched: Fix remaining actions notification accounting issues Commit 8e2efb3f45a5 ("net/sched: add get_fill_size callbacks for actions missing them") fixed the reported echo/notify skb overrun and noted that the pre-existing issues Sashiko pointed out [1] would be fixed separately. This is that series. Patch 1 makes tcf_action_shared_attrs_size() a real upper bound again. TCA_ACT_IN_HW_COUNT and TCA_STATS_BASIC_HW are emitted on every action dump and were never budgeted; TCA_STATS_PKT64 was budgeted once but can be emitted twice; TCA_ACT_USED_HW_STATS and the rate estimator attributes are conditional and also unaccounted. Patch 2 makes the RTM_GETACTION path use the attr_size that tca_action_gd() already computes and then throws away, so that "tc actions get" can read back an action whose dump is larger than NLMSG_GOODSIZE. Patch 3 wraps the reoffload delete notification in tcf_action_full_attrs_size() like every other notification path, and stops leaving a skip_sw action installed when that notification cannot be built. [1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810164357.1653956-1-victor%40mojatatu.com ==================== Link: https://patch.msgid.link/20260824153903.4143642-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski commit 251367a0a3319fa565daf7468b0afd933b1f5ab1 Author: Victor Nogueira Date: Mon Aug 24 12:39:02 2026 -0300 net/sched: act_api: fix skb sizing and action leak on reoffload delete tcf_reoffload_del_notify_msg() sizes the RTM_DELACTION skb with tcf_action_fill_size(action) alone. Unlike every other notification path it never wraps that in tcf_action_full_attrs_size(), so the nlmsg_put() header, struct tcamsg and the TCA_ACT_TAB nest that tca_get_fill() emits - 24 bytes on x86_64 - are not budgeted. As long as the single action stays well under NLMSG_GOODSIZE the floor in alloc_skb() hides this, but once its fill size crosses NLMSG_GOODSIZE the allocation is exactly 24 bytes short and tca_get_fill() runs out of tailroom. That is now easy to reach for an offloadable act_pedit with a large tcfp_nkeys, which commit 8e2efb3f45a5 ("net/sched: add get_fill_size callbacks for actions missing them") started accounting for properly. When that happens tcf_reoffload_del_notify() returns early, before tcf_idr_release_unsafe(), and tcf_action_reoffload_cb() discards the return value: if (tc_act_skip_sw(p->tcfa_flags) && !tc_act_in_hw(p)) tcf_reoffload_del_notify(net, p); The action has just lost its last hardware instance and is skip_sw, so it is left installed while processing no packets, and with no notification to tell userspace about it. An -ENOBUFS from alloc_skb() gets the same treatment. Fix this by budgeting the message header the way the add and delete paths do, and release the action even when the notification cannot be built - dropping the notification is strictly better than leaking a dead action, and there is no caller left to report the error to. Fixes: 13926d19a11e ("flow_offload: add reoffload process to update hw_count") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810164357.1653956-1-victor%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Reviewed-by: Pedro Tammela Link: https://patch.msgid.link/20260824153903.4143642-4-victor@mojatatu.com Signed-off-by: Jakub Kicinski commit e9ca46ebc3262b498626c4095826b8fa034bbf21 Author: Victor Nogueira Date: Mon Aug 24 12:39:01 2026 -0300 net/sched: act_api: size the RTM_GETACTION reply from the actions tca_action_gd() already walks every requested action and accumulates attr_size += tcf_action_fill_size(act), then wraps the result in tcf_action_full_attrs_size(). For RTM_DELACTION that value is handed to tcf_del_notify_msg(), which allocates max(attr_size, NLMSG_GOODSIZE). For RTM_GETACTION it is silently discarded and tcf_get_notify() allocates a fixed NLMSG_GOODSIZE skb instead. Any action whose dump exceeds that fixed budget therefore cannot be read back. For example, act_pedit overruns the budget with 32 actions of four munge keys each, act_police with 32 policers once the optional rate/peakrate/result/avrate attributes are present Fix this by passing attr_size through and allocate the reply the way the add and delete paths do. Note on exposure: RTM_GETACTION is the only one of the three action commands that is not capability checked - tc_ctl_action() requires CAP_NET_ADMIN for RTM_NEWACTION and RTM_DELACTION only - so this turns a fixed NLMSG_GOODSIZE reply into a user sized allocation on an unprivileged path. It is bounded by TCA_ACT_MAX_PRIO actions per request, and tca_action_gd() does not reject duplicate indices, so a single large action can be requested 32 times; an act_bpf program near BPF_MAXINSNS is about 32KB of dump, or roughly 1MB for one request. Creating such an action still requires CAP_NET_ADMIN, and the add and delete paths have sized their skbs this way since the Fixes commit. Should this ever need bounding, GFP_KERNEL_ACCOUNT would charge the reply to the caller's memcg. Fixes: 4e76e75d6aba ("net sched actions: calculate add/delete event message size") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810164357.1653956-1-victor%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260824153903.4143642-3-victor@mojatatu.com Signed-off-by: Jakub Kicinski commit 13eb543cebef6d6c3ec42e31afe3856f51b7126b Author: Victor Nogueira Date: Mon Aug 24 12:39:00 2026 -0300 net/sched: act_api: budget all shared attributes in notify skbs tcf_action_shared_attrs_size() is supposed to return an upper bound on the netlink attributes every action dump emits outside of TCA_ACT_OPTIONS, so that tcf_add_notify_msg(), tcf_del_notify_msg() and friends can allocate an skb large enough for the reply. It has fallen behind the dump path and is now an underestimate for every single action. Attributes, such as, TCA_ACT_IN_HW_COUNT and TCA_STATS_BASIC_HW are emitted unconditionally and never accounted for. TCA_STATS_PKT64, TCA_ACT_USED_HW_STATS, TCA_STATS_RATE_EST, TCA_STATS_RATE_EST64 require specific conditions, but are also not accounted for. Fix the issue by budgeting all of them so that we have a legitimate upper bound. Even tough for of them require specific conditions, they are cheap so, to avoid overcomplicating, we opted to account for them unconditionally as well to account for a real worst case scenario. Fixes: 4e76e75d6aba ("net sched actions: calculate add/delete event message size") Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810164357.1653956-1-victor%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260824153903.4143642-2-victor@mojatatu.com Signed-off-by: Jakub Kicinski commit 28a57fb2c5df4deb42a06e52fd36c14b37aa0034 Author: Dong Chenchen Date: Tue Aug 25 20:39:09 2026 +0800 net: iptunnel: fix stale transport header during tunnel decapsulation Syzbot reported a crash in qdisc_pkt_len_segs_init() caused by a stale transport_header offset after tunnel decapsulation. BUG: unable to handle page fault for address: ffffed102091a42e Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 340 Comm: qdisc_uaf_repro Not tainted 7.2.0-rc4-00061-g248951ddc14d #256 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__asan_load2 qdisc_pkt_len_segs_init (net/core/dev.c:4145) __dev_queue_xmit (net/core/dev.c:4787) br_dev_queue_push_xmit (net/bridge/br_forward.c:53) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:315) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6099) __netif_receive_skb_list_core (net/core/dev.c:6287) netif_receive_skb_list_internal (net/core/dev.c:6445) napi_complete_done (net/core/dev.c:6813) gro_cell_poll (net/core/gro_cells.c:74) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7798 net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) do_softirq (kernel/softirq.c:523 kernel/softirq.c:510 ) __local_bh_enable_ip (kernel/softirq.c:450) tun_get_user (drivers/net/tun.c:1986 (discriminator 1)) tun_chr_write_iter (drivers/net/tun.c:2032) The issue is completely latent until qdisc read transport header in commit 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()"). The crash requires four conditions to line up: 1. The incoming packet is encapsulated and carries GSO metadata. The outer transport header offset is stored in skb->transport_header while the packet is still in the outer tunnel context. 2. The tunnel receiver strips the outer headers. skb->data is advanced to the inner frame, but skb->transport_header is left pointing to the now-removed outer L4 header, so it becomes a negative offset relative to the new data. 3. The inner frame is not delivered to the local IP stack. Instead, it is forwarded at L2 by a bridge or HSR, so ip_rcv_core() never runs and the transport header is not reset to the inner L4 offset. 4. The forwarding path calls __dev_queue_xmit(), which enters qdisc_pkt_len_segs_init(). That function computes the GSO header length from skb_transport_offset(skb). Because the offset is negative, the unsigned cast overflows and pskb_may_pull(skb, hdr_len + sizeof(struct tcphdr)) reads past the end of the skb, triggering a KASAN fault or page fault. The issue specifically requires GSO packets (shinfo->gso_size != 0), which are processed/aggregated through gro_cells. Fix this by clearing transport_header to the ~0U sentinel in gro_cell for all tunnnel driver. GTP does not support GRO/GSO, drop the evil GSO packets in GTP directly. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+83181a31faf9455499c5@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69de2bee.a00a0220.475f0.0041.GAE@google.com/T/ Suggested-by: Eric Dumazet Signed-off-by: Dong Chenchen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260825123909.1463121-1-dongchenchen2@huawei.com Signed-off-by: Jakub Kicinski commit b873bf81412eb9292ec6028dca2c66d08f8d526e Merge: a5d946466a9562 63811edf512584 Author: Jakub Kicinski Date: Fri Aug 28 15:39:17 2026 -0700 Merge branch 'net-mlx5e-prevent-stale-xsk-buffer-release-on-refill-retries' Jerome Tollet says: ==================== net/mlx5e: Prevent stale XSK buffer release on refill retries Prevent duplicate XSK buffer release when a deferred RX refill fails and the same WQE is retried. Patch 1 fixes legacy cyclic RQ. It is unchanged from v3 and retains Dragos' Reviewed-by tag. Patch 2 fixes the analogous striding-RQ MPWQE path. Following Dragos' review, it now fills skip_release_bitmap in the common error path of mlx5e_xsk_alloc_rx_mpwqe(), consistently with mlx5e_alloc_rx_mpwqe(). Targeted fault injection covered both an early allocation failure and a partial 8-of-16-buffer unwind. With three consecutive failures for one MPWQE, the original 16 XSK buffers were released only once, retries saw a full bitmap, and a later successful allocation cleared it. A clean 20-second AF_XDP zero-copy pressure run exercised 1,575,262 buffer allocation failures without invalid descriptors, WQE errors, or kernel warnings. ==================== Link: https://patch.msgid.link/20260824141645.23700-1-jtollet@cisco.com Signed-off-by: Jakub Kicinski commit 63811edf512584c946e5e96b100e9e280703bbb5 Author: Jerome Tollet Date: Mon Aug 24 16:16:45 2026 +0200 net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry 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 commit e01620844c5c88b6fcf819d171df8e3976a0e76f Author: Jerome Tollet Date: Mon Aug 24 16:16:44 2026 +0200 net/mlx5e: Prevent stale XSK buffer release on refill retry 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 commit a5d946466a95621fa2769720d59ea336003aa1a5 Author: Lorenzo Bianconi Date: Wed Aug 26 15:03:15 2026 +0200 net: stmmac: fix dma mapping leak in stmmac_tso_xmit() 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 commit 18666c73afe95eeca8707c699b63f96ce3acda42 Author: Eric Dumazet Date: Thu Aug 27 09:59:36 2026 +0000 tcp: use GFP_ATOMIC in tcp_send_active_reset() tcp_send_active_reset() can be called from contexts where gfp_any() (in tcp_disconnect()) or sk->sk_allocation (in __tcp_close() and mptcp_do_fastclose()) evaluates to GFP_KERNEL, which includes __GFP_FS and __GFP_DIRECT_RECLAIM. Allocating with GFP_KERNEL while holding the socket lock (sk_lock) creates a lockdep dependency: sk_lock -> fs_reclaim This causes false-positive lockdep circular locking warnings with storage subsystems (such as nvme-tcp) that acquire socket locks in block I/O paths and invoke tcp_disconnect() or close sockets upon teardown: set->srcu -> sk_lock -> fs_reclaim -> elevator_lock -> set->srcu Active resets are small RST packet headers that should never enter direct reclaim or block while holding socket locks. Use sk_gfp_mask(sk, GFP_ATOMIC | __GFP_NOWARN) inside tcp_send_active_reset() and remove its priority argument. This preserves __GFP_MEMALLOC access for SOCK_MEMALLOC sockets, suppresses allocation failure warnings, and aligns with other control packet allocations (e.g. tcp_send_fin(), __tcp_send_ack(), tcp_xmit_probe_skb()). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Acked-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260827095936.551524-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit c185c78e2a0eed9bbc63537b99f65a8d5da8112d Merge: 7fcc2fe39fed1c 8b348496cbec0d Author: Jakub Kicinski Date: Fri Aug 28 15:34:54 2026 -0700 Merge branch 'netlink-specs-fixes-for-conntrack-dump-filtering' Ilya Maximets says: ==================== netlink: specs: fixes for conntrack dump filtering ==================== Link: https://patch.msgid.link/20260826220444.4054714-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski commit 8b348496cbec0d5ca24a99f668096e2e16e8fbeb Author: Ilya Maximets Date: Thu Aug 27 00:01:12 2026 +0200 netlink: specs: add missing mask attributes for conntrack dump 'mark-mask' and 'status-mask' are defined and supported by the conntrack dump, but missing from the list of arguments. While at it, the order of the arguments should follow the order of their definition in the enum ctattr_type. That appears to be a common convention for other spec files. Fixes: 23fc9311a526 ("netlink: specs: add conntrack dump and stats dump support") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Asbjørn Sloth Tønnesen Link: https://patch.msgid.link/20260826220444.4054714-3-i.maximets@ovn.org Signed-off-by: Jakub Kicinski commit 2a004bfb62bdb847f25a8001e104bf33922a2cf4 Author: Ilya Maximets Date: Thu Aug 27 00:01:11 2026 +0200 netlink: specs: fix the conntrack filter type The CTA_FILTER doesn't contain nested tuple attributes, instead it contains bit masks that specify which tuple attributes to filter on. The values for filtering are taken from the top-level CTA_TUPLE_ORIG and CTA_TUPLE_REPLY, which are also missing in the attribute list for the dump request. The bits themselves somehow are not in the public headers, so not defining them in the spec either for now. Once they are public in uAPI, they can be added here with enum-as-flags. Fixes: 23fc9311a526 ("netlink: specs: add conntrack dump and stats dump support") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Asbjørn Sloth Tønnesen Link: https://patch.msgid.link/20260826220444.4054714-2-i.maximets@ovn.org Signed-off-by: Jakub Kicinski commit 7fcc2fe39fed1cb98a7374a113ff3800e8f9af80 Author: Eric Dumazet Date: Tue Aug 25 08:45:51 2026 +0000 net: icmp: avoid invalid transport header access in icmp_send tracepoint syzbot reported a WARNING triggered by DEBUG_NET_WARN_ON_ONCE(): WARNING: at skb_transport_header include/linux/skbuff.h:3087 [inline] WARNING: at udp_hdr include/linux/udp.h:23 [inline] WARNING: at do_trace_event_raw_event_icmp_send include/trace/events/icmp.h:30 [inline] WARNING: at trace_event_raw_event_icmp_send+0x48c/0x6ec include/trace/events/icmp.h:11 Call trace: skb_transport_header include/linux/skbuff.h:3087 [inline] udp_hdr include/linux/udp.h:23 [inline] do_trace_event_raw_event_icmp_send include/trace/events/icmp.h:30 [inline] trace_event_raw_event_icmp_send+0x48c/0x6ec include/trace/events/icmp.h:11 __traceiter_icmp_send include/trace/events/icmp.h:11 [inline] __do_trace_icmp_send include/trace/events/icmp.h:11 [inline] trace_icmp_send+0x320/0x49c include/trace/events/icmp.h:11 __icmp_send+0xcfc/0x11d8 net/ipv4/icmp.c:1013 ipv4_send_dest_unreach net/ipv4/route.c:1280 [inline] ipv4_link_failure+0x57c/0x8dc net/ipv4/route.c:1287 dst_link_failure include/net/dst.h:438 [inline] vti_tunnel_xmit+0xe40/0x17a4 net/ipv4/ip_vti.c:307 TP_fast_assign() unconditionally calls udp_hdr(skb) before checking whether the packet is UDP. Furthermore, __icmp_send() can be invoked from paths (e.g., link failures, ARP errors, forwarding, AF_PACKET) where skb->transport_header was never initialized (~0U). Under CONFIG_DEBUG_NET=y, calling skb_transport_header(skb) triggers DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb)). Fix this by: 1. Only parsing transport info when iph->protocol == IPPROTO_UDP. 2. Using skb_header_pointer() at skb_network_offset(skb) + (iph->ihl << 2) to safely fetch the UDP header without assuming transport_header is set. Fixes: db3efdcf70c7 ("net/ipv4: add tracepoint for icmp_send") Reported-by: syzbot+6d2762674103618994b0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a8d5538.91706f20.ef82.0009.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Peilin He Cc: xu xin Cc: Steven Rostedt Reviewed-by: Jiayuan Chen Reviewed-by: David Ahern Link: https://patch.msgid.link/20260825084551.1562967-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit dddf197f29ba5e47a476dde82bf542ca2e0d5e5e Author: Chengfeng Ye Date: Wed Aug 26 03:01:41 2026 +0800 tipc: protect node reset trace dump with node lock The tipc_node_reset_links trace event asks tipc_node_dump() to walk the node's link entries. Unlike the other node events that request link data, this event runs without the node lock. This permits bearer teardown to free a link while the trace callback is dumping it: CPU 0 CPU 1 trace_tipc_node_reset_links() tipc_node_dump() l = n->links[0].link tipc_node_write_lock() kfree(l) n->links[0].link = NULL tipc_node_write_unlock() tipc_link_dump(l) tipc_link_dump() then dereferences the stale pointer. KASAN reported: BUG: KASAN: slab-use-after-free in tipc_link_dump Read of size 4 by task poc/115 Call Trace: tipc_link_dump+0x10cb/0x16b0 tipc_node_dump+0x4bb/0x740 trace_event_raw_event_tipc_node_class+0x258/0x360 tipc_node_reset_links+0x14d/0x1a0 tipc_rcv+0x13f5/0x3030 tipc_udp_recv+0x4e3/0x670 Allocated by task 0: tipc_link_create+0x1e1/0x1020 tipc_node_check_dest+0x7d2/0x11a0 tipc_disc_rcv+0xdbf/0x1430 Freed by task 89: kfree+0x131/0x3c0 tipc_node_link_down+0x267/0x4b0 tipc_node_delete_links+0xec/0x160 bearer_disable+0x107/0x260 Take the node write lock around the trace event. This serializes the dump against tipc_node_link_down(delete=true), which frees the link under the same write lock. Fixes: eb18a510b5cd ("tipc: add trace_events for tipc node") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260825190141.242219-1-nicoyip.dev@gmail.com Signed-off-by: Jakub Kicinski commit 5046d2880fec7d49ebed2fd2866747ee1d06ad71 Author: Zihan Xi Date: Thu Aug 27 18:25:14 2026 +0000 ipv4: avoid divide by zero in fib_rebalance fib_rebalance() computes the total eligible nexthop weight in one pass and programs upper bounds in a second pass. A concurrent change to ignore_routes_with_linkdown can make the first pass return zero while the second pass sees an eligible nexthop, resulting in division by zero. If the first pass reports a zero total, set each nexthop upper bound to -1 and skip the division. This matches the IPv6 fix in commit d2c26c2911dd ("ipv6: avoid divide by zero in rt6_multipath_rebalance") and preserves the lock-free rebalance path. Fixes: 0e884c78ee19 ("ipv4: L3 hash-based multipath") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zihan Xi Reviewed-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260827182514.4667-2-zihanx@nebusec.ai Signed-off-by: Jakub Kicinski commit 548e7bcd0c5460ddcbca9600cea603ebeebf4da7 Merge: ce727a090be04d 8fdf946445732c Author: Linus Torvalds Date: Fri Aug 28 11:51:05 2026 -0700 Merge tag 'ceph-for-7.3-rc1' of https://github.com/ceph/ceph-client Pull ceph updates from Ilya Dryomov: "A wide variety of mostly CephFS fixes and cleanups, split between changes that address edge cases (Sam, Xiubo, Matthew), efficiency improvements (Max) and AI-assisted hardening (Michael, Jeremy). One thing that stands out is Alex's change to how CephFS behaves in NEARFULL scenarios: the long-standing "make all writes synchronous" behavior has become opt-in. It was always somewhat controversial and doesn't make much sense for modern deployments; the new default is to continue normal operation (i.e. buffer writes as MDS allows, etc). The behavior in case the cluster reaches any FULL state remains the same as before" * tag 'ceph-for-7.3-rc1' of https://github.com/ceph/ceph-client: (32 commits) ceph: force a cap message when a deferred revoke can't be acked immediately libceph: reject buckets with mismatched CRUSH ids ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode ceph: fix leaked inode reference on writeback abort at umount libceph: remove ceph_put_page_vector() libceph: validate banner payload length ceph: make nearfull sync writes opt-in ceph: do not repeat ceph_trim_dentries() if no progress possible ceph: drop mdsc->mutex before decoding the MDS reply ceph: fix UAF in check_new_map() on session freed during unlock ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock ceph: pass inode pointer around instead of reloading it ceph: mark cap remove with RB_CLEAR_NODE() instead of setting ci=NULL ceph: add helper function ceph_cap_is_removed() ceph: make __ceph_remove_cap() static ceph: cap delegated inode count in ceph_parse_deleg_inos() ceph: bound num_export_targets array for mds info v2/v3 ceph: bound MDSCapAuth path and fs_name decode in handle_session() ceph: bound xattr value length in __build_xattrs() ceph: bound copied dentry name length in NFS export get_name ... commit ce727a090be04dc7c51edd5c0da2a41d2fb6e106 Merge: 115bd364ab20b2 a5e0055eac837a Author: Linus Torvalds Date: Fri Aug 28 10:59:07 2026 -0700 Merge tag 'ubifs-for-linus-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs Pull UBI and UBIFS updates from Richard Weinberger: "UBI: - Support for a per-device wear-leveling threshold - Various fixes and cleanups of error paths - Correctly preserve torture flag up wear-leveling UBIFS: - Various fixes and cleanups of error paths and kernel-doc" * tag 'ubifs-for-linus-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs: UBI: support per-device wear-leveling threshold UBI: fix two issues in the ubi.mtd MODULE_PARM_DESC mtd: ubi: Release device reference on busy detach ubi: Fix rollback for explicit UBI device numbers ubifs: fix out-of-bounds read in signature length check UBI: fastmap: Pass to_be_tortured when reusing old fastmap PEBs UBI: Preserve torture flag when rescheduling failed erasures ubifs: ubifs.h: clean up kernel-doc comments ubifs: key.h: use correct function parameter name ubifs: debug.h: fix kernel-doc struct prototypes commit 115bd364ab20b2dbef22824ec80d15901847dbe2 Merge: c20313e98b04ce c966d29e01bbf8 Author: Linus Torvalds Date: Fri Aug 28 10:48:48 2026 -0700 Merge tag 'f2fs-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs Pull f2fs updates from Jaegeuk Kim: "In this round, key enhancements focus on reducing inode management memory overhead, introducing resizable tail sections with unified pinned allocation, and boosting I/O throughput via parallel multi-device flushes and asynchronous f2fs_write_end_io() execution. We also add dynamic device alias reservations to allow on-the-fly space donation from user partitions. Alongside these features, critical bug fixes resolve folio race conditions, lingering dirty flags, dentry and block counter leaks, and potential deadloops in f2fs_fsync_node_pages(). Additional stability patches address error-path handling across symlink, sync, and rename/unlink operations, prevent pinned file fragmentation, and correct segment migration and free section accounting in free_segment_range. Enhancements: - reduce memory footprint of ino management - support dynamic reserve/release for device aliasing - issue multi-device flushes in parallel - add a way to run f2fs_write_end_io() asynchronously - support resizable tail section and unify pinned allocation Bug fixes: - fix to pass folio->index to f2fs_sanity_check_node_footer() - fix folio_nr_pages() race after put in large folio invalidate - fix to clear dirty flag on folio in error path - accurately adjust free_sections during free_segment_range - fix to avoid potential deadloop in f2fs_fsync_node_pages() - fix the error path in symlink, device alias in rename/unlink, f2fs_sync_fs - fix to migrate all curseg types during free_segment_range - fix to avoid pinfile fragment on fragment:{block, segment} mode - fix valid block count leak on data block allocation failure - fix dentry folio leak in find_in_level - reject overlapping move range after len expansion - fix some bugs related to file pinning, GC functions, i_size And, the series includes a number of minor bug fixes" * tag 'f2fs-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs: (51 commits) f2fs: support resizable tail section and unify pinned allocation f2fs: don't leave the hashed inode while it's unlinked f2fs: accurately adjust free_sections during free_segment_range f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages() f2fs: use adjusted write range after f2fs_write_checks() f2fs: fix to propagate error from f2fs_sync_fs() f2fs: return symlink writeback errors f2fs: fix error handling on device alias check in rename and unlink f2fs: fix to reset all pinned status during fggc f2fs: use f2fs_{down, up}_(read, write}_trace() for nat_tree_lock f2fs: reduce memory footprint of ino management f2fs: fix i_size when pinned fallocate partially fails f2fs: fix to migrate all curseg types during free_segment_range f2fs: avoid setting SBI_NEED_FSCK on transient resize failure f2fs: fix to avoid pinfile fragment on fragment:{block, segment} mode f2fs: cleanup w/ f2fs_need_rand_{blk, seg, seg_blk} f2fs: fix to shrink gc_lock coverage in f2fs_gc_range() f2fs: fix to reclaim space in f2fs_allocate_pinning_section() f2fs: unify add/remove ino entry API for all ino types f2fs: fix to zero post-EOF data when extending file size ... commit c6ff14f1cd9e9b7d5631882ff509fbc29e90cfe0 Author: Eduard Zingerman Date: Thu Aug 27 15:48:24 2026 -0700 selftests/bpf: half-dead scalar zero stack spill test A test case demonstrating unsafe pruning when spill of a scalar zero spilled on a first pass in replaced by STACK_ZERO in the __clean_func_state(). Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260827-bug-011-cleanfunc-stack-zero-simple-v1-v1-2-c0e996589a52@gmail.com Signed-off-by: Alexei Starovoitov commit 2f3536bff8823d3c5fdbbe15e17bfca696cc2b2e Author: Eduard Zingerman Date: Thu Aug 27 15:48:23 2026 -0700 bpf: don't downgrade half-dead scalar zero spills to STACK_ZERO states.c:__clean_func_state() can downgrade scalar zero spill to STACK_ZERO in the following case: *(u64 *)(r10 - 8) = 0; ... checkpoint ... r1 = *(u32 *)(r10 - 4); ... no reads from r10-8 ... Here 4 bytes at r10-8 are dead and verifier changes scalar spill to a combination: 0000pppp (p stands for poison). Such a change breaks precision propagation chains. All places that produce STACK_ZERO should call bpf_mark_chain_precision() for the zero source. This patch fixes the bug in a simplest way possible: avoids converting stack spills of zero to STACK_ZERO. Two smarter approaches are possible: - do bpf_mark_chain_precision() from __clean_func_state() - check slot liveness information in check_stack_write_fixed_off() I investigated both and the changes required are a bit tricky, hence go with a simple fix for the time being. Fixes: be23266b4a08 ("bpf: 4-byte precise clean_verifier_state") Reported-by: Nicholas Carlini Suggested-by: Nicholas Carlini Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260827-bug-011-cleanfunc-stack-zero-simple-v1-v1-1-c0e996589a52@gmail.com Signed-off-by: Alexei Starovoitov commit c20313e98b04ce543936431b6122dd639d3a8346 Merge: 275bc4eedf2c60 c4a0927f535f77 Author: Linus Torvalds Date: Fri Aug 28 10:01:02 2026 -0700 Merge tag 'sound-fix-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of various small fixes since the last PR. Most changes are device-specific fixes, while there are a few fixes addressing the issues reported recently by fuzzers. Here are highlights: ALSA Core: - Prevent adding invalid kcontrols to the LED layer - Workaround for a false-positive mutex lockdep warning in rawmidi USB-audio: - Relaxed the sticky mixer behavior check that caused regressions - Fix an OOB write in Novation MIDI output - Proper cleanup after system-resume errors - Quirk updates for M-Audio Venom, Audient iD14 MkI, Logitech PRO X Wireless, SMSL USB DAC, and Creative Sound Blaster Play! 3 HD-audio: - Conexant headset plugin fixes - Quirk additions and fixes for HP Laptop 15, Lenovo IdeaPad Slim 3, TongFang XxAF5xxx, Lenovo Legion Pro 7, and Lenovo Yoga Pro 9 ASoC: - DAPM: Fix off-by-one check on the second enum channel - Tegra: Fix and sort register defaults - AMD quirk updates for ASUS FA401EA, HP OmniBook X Flip 16, HVY-WXX9/M1060, Alienware m18 R1, and MSI Thin A15 B7UC - Fixes Qualcomm TDM handling - Fix double put_device() on SoundWire - Codec fixes for rt766, tac5xx2, rt712, tas2783, and max98926 Misc: - Fix card leak on probe error on ice1712 driver - Hardening for legacy aoa, mtpav and pcxhr drivers" * tag 'sound-fix-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (53 commits) ALSA: control: Don't add invalid kcontrols to LED layer ASoC: amd: acp-config: change quirks to cover all ASUS FA401EA variants ALSA: hda/conexant: Always enable the headset-mic pin on plugin ASoC: dapm: Fix off-by-one check on the second enum channel ASoC: amd: acp-config: force SoundWire probe on HP OmniBook X Flip 16 ASoC: amd: acp3x-es83xx: Add HVY-WXX9/M1060 DMI quirk ASoC: amd: acp-config: Add HVY-WXX9/M1060 DMI quirk ASoC: soc-generic-dmaengine: Fix DMA channel request warning ALSA: rawmidi: Another workaround for false-positive mutex lockdep warning ASoC: amd: yc: Add DMI entry for Alienware m18 R1 AMD ASoC: amd: yc: Add DMI entry for MSI Thin A15 B7UC ALSA: hda/realtek: Fix speaker mute LED for HP Laptop 15-fd0039nt ALSA: usb-audio: Complete cleanup after system-resume errors ALSA: hda/realtek: Add quirk for Lenovo IdeaPad Slim 3 15ABR8 ALSA: aoa: i2sbus: Check IRQ before requesting it ALSA: usb-audio: Skip mixer creation on M-Audio Venom ALSA: usb-audio: Skip reading sample rate on M-Audio Venom ASoC: rt766: add RT766/RT767 VA1 device IDs ALSA: hda/realtek: Add quirk for TongFang XxAF5xxx ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() ... commit 275bc4eedf2c6081200998954efcb5eb90413a41 Merge: afe0579334f622 afce9701d6423a Author: Linus Torvalds Date: Fri Aug 28 09:53:43 2026 -0700 Merge tag 'rtc-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux Pull RTC updates from Alexandre Belloni: "The RZN1 driver got a fairly comprehensive cleanup. More DT binding are converted to DT schema, leaving only 5 remaining files to convert. Subsystem: - patchwork project is moving to kernel.org - fully initialize clk_init_data - add missing MODULE_DEVICE_TABLE() - DT bindings conversions to DT schema Drivers: - ds1307: fix WADA bit for alarms on RX8130 - rzn1: add support for RZ/T2H and RZ/N2H, many fixes" * tag 'rtc-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (42 commits) MAINTAINERS: update rtc subsystem patchwork location rtc: msc313: Select by default on MSTARV7 rtc: microcrystal: Make sure clk_init_data is fully initialized rtc: philips: Make sure clk_init_data is fully initialized rtc: nct3018y: Make sure clk_init_data is fully initialized rtc: m41t80: Make sure clk_init_data is fully initialized rtc: hym8563: Make sure clk_init_data is fully initialized rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs rtc: rzn1: Drop trailing comma from OF match table sentinel rtc: rzn1: Add OF match data to gate SUBU register access rtc: rzn1: use FIELD_PREP/FIELD_GET and GENMASK for register access rtc: rzn1: Consistently use dev_err_probe() rtc: rzn1: Use temporary variable for struct device rtc: rzn1: Dynamically calculate synchronization delay based on clock rate rtc: rzn1: Replace remove callback with devm_add_action_or_reset() rtc: rzn1: Use pm_runtime_put_sync() rtc: Kconfig: Broaden RTC_DRV_RZN1 dependency to ARCH_RENESAS rtc: rzn1: Fix malformed MODULE_AUTHOR string rtc: rzn1: Disable alarm interrupt before reprogramming alarm registers rtc: rzn1: Fix alarm range check truncation on 32-bit systems ... commit afe0579334f622c803f2864f22c04c20c320bd80 Merge: 9df08cdd33a70e 55ba91d4c54ab3 Author: Linus Torvalds Date: Fri Aug 28 09:36:27 2026 -0700 Merge tag 'for-next-tpm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd Pull TPM updates from Jarkko Sakkinen: "The bulk of this is Ross Philipson's TPM enablement for Trenchboot. That exposes TPM constants, and decouple and improve robustness of tpm_buf a bit in order to implement a minimal early TPM driver. Early boot code will call either SKINIT on AMD or GETSEC[SENTER] on Intel before jumping into kernel's entry point. They re-initalize TPM PCRs but leave up to the early boot code measure initrd, boot_params and Trenchboot associated metadata. The motivation here is just that we would want in future iterations of the series put our full focus to the x86 part of the review, and call it a day as per TPM changes. Further, even if Trenchboot turned out to be empty lottery the worst possible outcome for TPM driver is that things get cleaned up a bit" * tag 'for-next-tpm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: tpm-buf: Add TPM buffer support header for standalone reuse tpm-buf: Memory-safe allocations tpm-buf: Remove chip parameter from tpm_buf_append_handle() tpm-buf: Merge TPM_BUF_BOUNDARY_ERROR and TPM_BUF_OVERFLOW tpm: Remove main TPM header from TPM event log header tpm: Move platform specific definitions to the new PTP header tpm: Move TPM common base definitions to the command header tpm: Move TPM2 specific definitions to the command header tpm: Move TPM1 specific definitions to the command header tpm: Initial step to reorganize TPM public headers tpm: st33zp24: Validate locality read result tpm: st33zp24: Return zero on status read failure tpm: tpm_tis_spi: fix nodef CR50 tpm_tis_spi_resume is null tpm: atmel: depend on X86 tpm: Remove redundant dev_err() tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout commit 9df08cdd33a70ee1310523065fc4e3f161f6242e Merge: 344be13211d0fc ee440d4fc0d2f1 Author: Linus Torvalds Date: Fri Aug 28 09:28:40 2026 -0700 Merge tag 'v7.3-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "Fix a memory allocation overrun in crypto acomp" * tag 'v7.3-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: acomp - allocate async request context when cloning commit 344be13211d0fceb791a7da70ef810ad13340fe0 Merge: 9d607ae0f7d629 3b446d169a93e6 Author: Linus Torvalds Date: Fri Aug 28 09:09:01 2026 -0700 Merge tag 'acpi-7.3-rc1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI support fix from Rafael Wysocki: "Revert an incomplete recent commit that may cause ACPI device power management to stop working" * tag 'acpi-7.3-rc1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "ACPI: scan: Defer device power initialization" commit 9d607ae0f7d629dc068aed5f498e24d3e9875ef1 Merge: 72ecc30d607f6c 2bd533739234d7 Author: Linus Torvalds Date: Fri Aug 28 09:02:04 2026 -0700 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "A mixture of ptdump, compat and MTE fixes that came in during the merge window: - Fix address handling of final memory region in ptdump - Fix emulation of decrementing load/store multiple from 32-bit task - Fix SCTLR context-switching for store-only MTE mode - Fix numerous issues in MTE selftests" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: selftests/arm64: Add MTE test config fragment selftests/arm64: Fix MTE prctl TAP plan selftests/arm64: Treat KSM merge_across_nodes as optional selftests/arm64: Print missing MTE TAP headers arm64: compat: Fix decrementing LDM/STM alignment emulation arm64: process: Fix context switching MTE store-only tag check KVM: arm64: ptdump: Flush the last region arm64: ptdump: Make note_page_flush() range aware commit 72ecc30d607f6c8ef8ac0d7b88b0c176a7409367 Merge: 874b43b9f3c704 eb049bdbf2b98d Author: Linus Torvalds Date: Fri Aug 28 08:55:47 2026 -0700 Merge tag 'xtensa-20260828' of https://github.com/jcmvbkbc/linux-xtensa Pull Xtensa updates from Max Filippov: - use strnlen() to improve iss_console_write() - remove unused function setup_profiling_timer() - fix CONFIG_XTENSA_CALIBRATE_CCOUNT macro name in comment * tag 'xtensa-20260828' of https://github.com/jcmvbkbc/linux-xtensa: xtensa: remove unused setup_profiling_timer function xtensa: correct CONFIG_XTENSA_CALIBRATE_CCOUNT macro name in comment tty: xtensa/iss: use strnlen to improve iss_console_write commit 874b43b9f3c704f24f0bdcc347b2e596ad3228ec Merge: 1b78070aaef635 de0dab22cbf694 Author: Linus Torvalds Date: Fri Aug 28 08:44:36 2026 -0700 Merge tag 'm68knommu-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu Pull m68knommu updates from Greg Ungerer: "This includes a couple more new defconfigs to improve test build coverage, changes to use the more correct linux/gpio/legacy.h and platform setup for the reset device of the ColdFire 5441x SoC hardware. - new defconfigs for 2 more ColdFire boards - change to use linux/gpio/legacy.h - add platform setup for reset device of the 5441x SoC boards" * tag 'm68knommu-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: m68k: coldfire/5441x: register mcf-rcm-reset platform device m68k/coldfire: replace linux/gpio.h inclusions m68k: defconfig: add config for M5282EVB board m68k: defconfig: add config for M52358EVB board commit aefbda23eeba234c3ff0f135dc5be6e294bd25a6 Author: Alexei Turtanov <9alexei9@gmail.com> Date: Fri Aug 28 14:22:39 2026 +0300 Input: atkbd - skip deactivate for Xiaomi Redmi Book Pro 16 2026 The internal keyboard of the Xiaomi Redmi Book Pro 16 2026 (board TM2425) does not work: atkbd_probe() succeeds and every command is ACKed, but no scancodes ever arrive afterwards. Testing on the hardware through serio_raw shows that ATKBD_CMD_RESET_DIS (0xF5) is the culprit. After 0xF5 the embedded controller keeps ACKing commands but stops delivering scancodes, and neither ATKBD_CMD_ENABLE (0xF4) nor ATKBD_CMD_RESET_BAT (0xFF) bring them back. Only re-enabling the keyboard interface at the controller level (i8042 command 0xAE, or rewriting the command byte as i8042_port_close() does) revives it. Running the init sequence without 0xF5 (0xED 0x00, 0xF3 0x00, 0xF4) keeps the keyboard working. 'i8042.dumbkbd=1' also works around this, but then the driver never writes to the keyboard and the LEDs cannot be controlled. Use the existing atkbd_deactivate_fixup quirk instead, as done for the sibling TM2424 by commit 3a046db33bb9 ("Input: atkbd - skip deactivate for Xiaomi Book Pro 14's internal keyboard"). Tested on v7.2: keyboard, Caps Lock LED and s2idle suspend/resume all work. DMI: XIAOMI REDMI Book Pro 16 2026/TM2425, BIOS RMAPT6B0P0909 05/22/2026 Fixes: 9cf6e24c9fbf ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID") Cc: stable@vger.kernel.org Signed-off-by: Alexei Turtanov <9alexei9@gmail.com> Link: https://patch.msgid.link/20260828112239.18081-1-9alexei9@gmail.com Signed-off-by: Dmitry Torokhov commit a8b02aa825803e6c5b6b27340f583900afa0861d Merge: 1dd31281a6e3f3 92a9eebd2a1f89 Author: Dave Airlie Date: Fri Aug 28 13:27:51 2026 +1000 Merge tag 'amd-drm-next-7.3-2026-08-27' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-7.3-2026-08-27: amdgpu: - MES fixes - Userq fixes - UVD fix - VCE 3 fix - Enforce isolation fix - HPD fix for VGA/LVDS - DML fix - DCN 6 fixes - DC gpu reset fix amdkfd: - CU occupancy for GFX 11 - CU occupancy for GFX 12/12.1 - Queue bounds checking fix - SVM fixes - CRIU bounds checking fix Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patch.msgid.link/20260827203610.3249084-1-alexander.deucher@amd.com commit 1dd31281a6e3f370914f99b7cf6cccbc2c050ea3 Merge: 1ff8d3e3165fd0 a62212b35a214c Author: Dave Airlie Date: Fri Aug 28 13:14:31 2026 +1000 Merge tag 'drm-xe-next-fixes-2026-08-27' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Cross-subsystem Changes: - i2c global register definitions as dependency for xe/i2c fixes. (Heikki) Driver Changes: - Media workardound (Daniele) - Add CCS to gt_idle debugfs print (Bala) - Page fault related fix (Arvind) - i2c related fixes (Heikki) - System Controller mailbox bit fix (Anoop) Signed-off-by: Dave Airlie From: Rodrigo Vivi Link: https://patch.msgid.link/apBrVgvZwIRIfuhR@intel.com commit 5eab74874d11160725c42ab676ba97a797a362eb Author: Ivan Immanuel Shaji Date: Tue Aug 25 12:52:50 2026 -0400 ring-buffer: Stop remote reader update when page swap fails The remote swap_reader_page callback can return -EBUSY when the writer moves the head before the remote catches it, particularly during an event storm on a small buffer. __rb_get_reader_page_from_remote() currently warns about that failure but continues with the unchanged reader ID and rearranges the local page list as though the swap succeeded. Handle the callback failure as a recoverable error. Report it with pr_warn_ratelimited() and return NULL. Callers already handle a NULL reader page as a failed attempt. This avoids splicing the same page as both the previous and new reader without flooding the log under contention. Cc: stable@vger.kernel.org Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes") Link: https://patch.msgid.link/20260825-kernel-patch-1-v2-2-bb3461807a32@gmail.com Assisted-by: LLM sparse Signed-off-by: Ivan Immanuel Shaji Signed-off-by: Steven Rostedt commit e0d3aed7b12cf37b74c7cc5265073d0263b49cde Author: Ivan Immanuel Shaji Date: Tue Aug 25 12:52:49 2026 -0400 tracing: Fix retry exhaustion in simple ring buffer reader swap simple_ring_buffer_swap_reader_page() starts with retry set to 8 and post-decrements it only after a failed link replacement. On the final attempt, a successful replacement leaves retry at zero, while a failed replacement leaves it at -1. The current !retry test reverses both outcomes. It returns an error after a successful final replacement, leaving the link update complete but the reader bookkeeping unfinished. After a failed final replacement, it falls through and updates the head and reader pointers as though the replacement succeeded, which can corrupt the ring. Treat only a negative counter as exhaustion and return the documented -EBUSY error. Cc: stable@vger.kernel.org Fixes: 34e5b958bdad ("tracing: Introduce simple_ring_buffer") Link: https://patch.msgid.link/20260825-kernel-patch-1-v2-1-bb3461807a32@gmail.com Assisted-by: LLM sparse Reviewed-by: Vincent Donnefort Signed-off-by: Ivan Immanuel Shaji Signed-off-by: Steven Rostedt commit 390f6bd8583d177029d9df4bea6667509e55a765 Author: Jérémy Jean Date: Thu Aug 27 18:43:22 2026 +0000 tracing/user_events: Clear copied tracing state before fork duplication dup_task_struct() copies user_event_mm from the parent into the child, without grabbing a reference to it. user_event_mm_dup() should replace it, but it leaves that copied pointer unmodified if user_event_mm_alloc() fails. When the child exits, user_event_mm_remove() decrements a reference the child never owned, which ultimately frees user_event_mm, while the parent still as a stale pointer to it. This creates a UAF, which KASAN reports as: BUG: KASAN: slab-use-after-free in current_user_event_mm+0x51/0x1d0 Write of size 4 at addr ffff888005010d30 by task init/44 Call Trace: kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0 current_user_event_mm+0x51/0x1d0 user_events_ioctl+0x82e/0x15c0 __x64_sys_ioctl+0x139/0x1c0 do_syscall_64+0xce/0x450 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 44: __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x180/0x3a0 user_event_mm_alloc+0x3c/0x1f0 current_user_event_mm+0x88/0x1d0 Freed by task 42: __kasan_slab_free+0x43/0x70 kfree+0x13a/0x390 process_one_work+0x696/0xf90 worker_thread+0x420/0xba0 The fix simply clears the copied pointer before any possible failure. In case of failure, the child then has nothing to free. Cc: stable@vger.kernel.org Fixes: 7235759084a4 ("tracing/user_events: Use remote writes for event enablement") Link: https://patch.msgid.link/20260827184321.2964601-2-Jeremy.Jean@oss.cyber.gouv.fr Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Bradley Morgan Signed-off-by: Steven Rostedt commit b15b548d52b43ba8ac4652bc2c7244a8dd1e9622 Author: Vasileios Almpanis Date: Wed Aug 12 11:14:48 2026 +0200 i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left. Fixes: 73febd775bdb ("i2c: create debugfs entry per adapter") Reported-by: syzbot+23ad911c819b923238b7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=23ad911c819b923238b7 Signed-off-by: Vasileios Almpanis Cc: # v6.8+ Tested-by: syzbot+23ad911c819b923238b7@syzkaller.appspotmail.com Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260812-i2c-v2-1-5efaab4c3334@gmail.com commit 27c9445be86b1313746c46d659d3f823a5f7a218 Author: Carlos Song Date: Mon Aug 3 11:27:05 2026 +0800 i2c: imx-lpi2c: avoid accessing target registers on master-only controllers Not all LPI2C controller instances implement the Target block. Since commit 90311787f483 ("i2c: imx-lpi2c: reset controller in probe stage"), the driver unconditionally resets both the Master and Target blocks during probe. On controllers that do not support target mode, accessing the Target registers triggers an asynchronous SError and prevents the driver from probing successfully. For example on i.MX8QM: SError Interrupt on CPU2, code 0x00000000bf000002 -- SError Hardware name: Freescale i.MX8QM MEK (DT) pc : lpi2c_imx_probe+0x280/0x594 lr : lpi2c_imx_probe+0x224/0x594 Kernel panic - not syncing: Asynchronous SError Interrupt The VERID register is implemented in the Master block and can be safely accessed on all controller variants. Its FEATURE field indicates whether target mode is supported. Read VERID during probe and use it to determine whether the Target block is present. Only access Target registers when target mode is supported and reject target registration requests with -EOPNOTSUPP otherwise. Fixes: 90311787f483 ("i2c: imx-lpi2c: reset controller in probe stage") Signed-off-by: Carlos Song Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260803032705.2250373-1-carlos.song@oss.nxp.com commit f98d4986482151a835b521a734722fe8dc5ca37d Author: Guangshuo Li Date: Wed Aug 12 17:44:25 2026 +0800 i2c: qcom-cci: fix autosuspend cleanup cci_probe() calls pm_runtime_use_autosuspend(), but the remove path does not call the matching pm_runtime_dont_use_autosuspend() before disabling runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without undoing the autosuspend setting during teardown, this reference is not dropped and usage_count remains unbalanced. Use devm_pm_runtime_set_active_enabled() to manage the runtime PM state. Its managed cleanup disables autosuspend and runtime PM and restores the suspended state on probe failure and driver removal. Remove the now redundant manual runtime PM cleanup. This issue was found by manual code inspection. Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Guangshuo Li Cc: # v5.8+ Reviewed-by: Vladimir Zapolskiy Reviewed-by: Loic Poulain Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260812094425.3515179-1-lgs201920130244@gmail.com commit 77549d01edecc20da73c8599e14648877198ce9b Author: Hongbo Yao Date: Wed Aug 26 15:05:47 2026 +0800 i2c: designware: Enable interrupt mask workaround for HJMC3001 On HJMicro ARM64 servers, the DesignWare I2C controller does not retrigger a pending interrupt if the interrupt status changes after the current status bits have been cleared. The issue is exposed under heavy system load when the corresponding SPI is routed across sockets to a core in the remote socket. The interrupt is then lost and the I2C transfer times out. Enable ACCESS_INTR_MASK for HJMC3001. This toggles DW_IC_INTR_MASK before returning from the interrupt handler and retriggers any pending interrupt. Fixes: 6816ce57c479 ("i2c: designware: Add a new ACPI HID for HJMC01 I2C controller") Signed-off-by: Hongbo Yao Cc: # v6.13+ Acked-by: Mika Westerberg Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260826070547.268672-1-andy.xu@hj-micro.com commit a4f3fbccb65de757569686baaf2b72e329096aba Author: Kathiravan Thirumoorthy Date: Wed Aug 12 14:00:55 2026 +0530 i2c: qcom-geni: update frequency table to fix timing parameters In IPQ5424, to meet the setup and hold timing requirements in the standard mode, update the frequency table with the values recommended by HW design team. Also remove the stray space in the I2C_MAX_FAST_MODE_FREQ entry. Fixes: 85c34532849d ("i2c: qcom-geni: fix I2C frequency table to achieve accurate bus rates") Fixes: 506bb2ab0075 ("i2c: qcom-geni: Support systems with 32MHz serial engine clock") Signed-off-by: Kathiravan Thirumoorthy Cc: # v6.13+ Reviewed-by: Mukesh Savaliya Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260812-ipq5424_i2c_scl_updates-v2-1-e09cd39d01d7@oss.qualcomm.com commit afce9701d6423a63194a349d2f1e34c50ce76482 Author: Alexandre Belloni Date: Fri Aug 21 22:07:58 2026 +0200 MAINTAINERS: update rtc subsystem patchwork location The RTC subsystem is migrating it patchwork to kernel.org. Link: https://patch.msgid.link/202608212007582a463833@mail.local Signed-off-by: Alexandre Belloni commit 1b78070aaef63512688aebfbc82365ef9d6660f1 Merge: 3ba13f5e7180c0 4a9d62a8774f13 Author: Linus Torvalds Date: Thu Aug 27 13:53:43 2026 -0700 Merge tag 'net-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from Bluetooth, IPSec and Netfilter. Current release - fix to a fix: - netfilter: ipset: remove need to allocate memory on delete operations Current release - regressions: - macb: drop CONFIG_OF #if block, fix build Previous releases - always broken: - stream of fixes for SCTP continues - inet: frags: strip GSO state from fragments before reassembly - virtio-net: ensure that TCP packets don't overflow gso_segs - tcp-ao: fix use-after-free of current_key on reconnect to another peer - page_pool: remove zone/policy GFP flags when allocating XArray entries - Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN - tls: device: fix out-of-bounds write in tls_append_frag() - eth: bnxt: - ring the doorbell when SW USO exits early, avoid packets stuck in Tx - gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check, avoid users of older NICs seeing non-actionable warning messages - eth: qede: fix NULL pointer dereference in TPA fragment processing" * tag 'net-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (216 commits) inet: frags: strip GSO state from fragments before reassembly net/sched: sch_htb: limit htb_classify inner-class filter hops selftests/net: packetdrill: add tcp_urg_ptr_retransmit tcp: fix corruption of urgent data on multi-segment retransmit usb: atm: usbatm: fix invalid ci_range initialization net: fec: only stop PTP if it was initialized slip: remove slip_hangup() to fix use-after-free in slip_receive_buf() net: bridge: mcast: fix use-after-free of a master VLAN's multicast context net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup net: dsa: mxl862xx: enable assisted learning on CPU port net: stmmac: restore NET_IP_ALIGN in the RX DMA offset net: stmmac: drop gso_enabled_types and rely on netdev features net: stmmac: selftests: Don't test flow control for small rx fifos net: stmmac: selftests: Account for the UC filter list for filtering tests net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering net: stmmac: dwmac4: Account for the primary MAC address for UC filtering net: stmmac: dwmac1000: Account for the primary MAC address for UC filtering net: stmmac: selftests: Check multiple MMC counters selftests: net: Fix slow configurations in big_tcp_tunnels.sh selftests: net: Lower threshold with csum offload off in big_tcp_tunnels.sh ... commit 4a9d62a8774f130a5b8de26ca9f415e6050a9d51 Merge: d5dc1e69fd7258 fc04229727d8ff Author: Jakub Kicinski Date: Thu Aug 27 13:13:18 2026 -0700 Merge tag 'nf-26-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net: 1) Use DEBUG_NET_WARN_ON_ONCE() instead of WARN_ON() from the tproxy datapath, a recent bug found a way to reach WARN_ON from datapath due to insufficient validation of xt_TPROTO checkentry. From Fernando F. Mancera. 2) Similar to previous patch to replace WARN_ON_ONCE by DEBUG_NET_WARN_ON_ONCE() for connlimit. Not known issue, but since this patch has been around for a while, let's merge it. Also from Fernando. 3) Move nf_tables harware offload commit path after chain blob and audit to reduce chances of leaving the hardware in inconsistent state. 4) Add missing vzeroupper to nf_tables pipapo AVX2 to address performace degradation to later user of SSE code, from Eric Biggers. 5) Remove pr_debug() in x_tables extensions, a recent bogus found a way to print a unsanitized string in xt_IDLETIMER, many of these pr_debug() calls are there for historical reasons. 6) Use pr_info_ratelimited() in x_tables .checkentry. 7) Fix an imbalance in module refcount due to incorrect override expression logic with sets. Remove unnecessary clone in control plane, use the existing expressions provided by set or dynset expression. Release override expressions only. 8) Tigthen nf_tables device name removal, it is possible to remove prefix strings with exact device name. From Fernando F. Mancera. 9) Set on the set dead bit earlier, otherwise it is possible to call .commit on deleted sets. This also addresses the re-introduction of a bug. * tag 'nf-26-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_tables: remove leftover set_update_list netfilter: nf_tables: set on dead bit when performing early element removal netfilter: nf_tables: skip double clone set expressions on element insert netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited() netfilter: x_tables: remove pr_debug netfilter: nft_set_pipapo_avx2: add missing vzeroupper netfilter: nf_tables: move hardware offload step after building the chain blob netfilter: conncount: use DEBUG_NET_WARN_ON_ONCE on reaching count limit netfilter: tproxy: use DEBUG_NET_WARN_ON_ONCE for protocol fallbacks ==================== Link: https://patch.msgid.link/20260827141733.423453-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski commit 3ba13f5e7180c034b0a1ef7e052fb780856b134e Merge: 9bb34313d94b17 5bb01c657ff9fc Author: Linus Torvalds Date: Thu Aug 27 12:53:43 2026 -0700 Merge tag 'devicetree-fixes-for-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fixes from Rob Herring: - Fix possible out-of-bounds access in of_alias_scan() - Fix refcount leak in of_irq_get_affinity() - Add Qualcomm SPMI PMIC haptics input which is already referenced * tag 'devicetree-fixes-for-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: of: fix out-of-bounds read in of_alias_scan() stem parser of/irq: Fix device node refcount leak in of_irq_get_affinity() dt-bindings: input: Add Qualcomm SPMI PMIC haptics commit d5dc1e69fd7258ea605c9952e5d5947539159ae3 Author: Xinyang Ge Date: Thu Aug 27 16:07:07 2026 +0200 inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list") and by commit 9e4b7a99a03a ("net: gso: fix panic on frag_list with mixed head alloc types") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 ("tun: Allow GSO using virtio_net_hdr"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged. Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr") Cc: stable@kernel.org Suggested-by: Eric Dumazet Signed-off-by: Xinyang Ge Signed-off-by: Paolo Abeni Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/937926e509f2acd8e0e66520dc2b30fd6b4d1687.1787839506.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski commit 729c4896ab829169f95915d65edd530325910b37 Author: Jamal Hadi Salim Date: Wed Aug 26 11:33:39 2026 -0300 net/sched: sch_htb: limit htb_classify inner-class filter hops htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Vega Co-developed-by: Victor Nogueira Signed-off-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260826143339.271935-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski commit 6a7e91f890eceb4fd9d3662e7ffba1fcb55cc00e Author: Jiayuan Chen Date: Wed Aug 26 22:11:27 2026 +0800 selftests/net: packetdrill: add tcp_urg_ptr_retransmit Drive a connection into urgent mode and force a multi-segment retransmit, checking that each retransmitted segment keeps its own urg_ptr. The test asserts the fixed behaviour: the hole is retransmitted as two independent skbs, each with its own urg_ptr (5001 and 4001) and no PSH. An unpatched kernel instead sends one super-skb whose GSO split copies urg_ptr onto the second segment and also sets PSH there, so on an unpatched kernel the mismatch shows up on the PSH bit (actual P.U ... urg 5001) before the urg_ptr: tcp_urg_ptr_retransmit.pkt:63: live packet field tcp_psh: expected: 0 (0x0) vs actual: 1 (0x1) script packet: .U 1001:2001(1000) ack 1 actual packet: P.U 1001:2001(1000) ack 1 win 1050 After the fix the retransmit carries a per-segment urg_ptr and the test passes. Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260826141145.67823-2-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski commit ce2b807f42ed5e55567b8864ab72963f90779270 Author: Jiayuan Chen Date: Wed Aug 26 22:11:26 2026 +0800 tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: /* tcp_write_xmit() */ limit = mss_now; if (tso_segs > 1 && !tcp_urg_mode(tp)) limit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: /* __tcp_retransmit_skb() */ len = cur_mss * segs; /* segs > 1, no urg_mode check */ ... /* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: seg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) seg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) seg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode. Fixes: 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit time") Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260826141145.67823-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski commit a60fd8c6dbaa76da4163cf225ed2b9e982540f39 Author: Deepanshu Kartikey Date: Wed Aug 26 19:02:58 2026 +0530 usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci. Fixes: c59bba75fa50 ("[PATCH] USB ATM: new usbatm core") Reported-by: syzbot+6665d3db5fef15914802@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6665d3db5fef15914802 Suggested-by: Eric Dumazet Link: https://lore.kernel.org/all/20260824024620.23485-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260826133258.8306-1-kartikey406@gmail.com Signed-off-by: Jakub Kicinski commit dd890ae29299636fb037276fc1b5238698d08b03 Author: bui duc phuc Date: Wed Aug 26 17:34:28 2026 +0700 net: fec: only stop PTP if it was initialized fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized. Fixes: 32cba57ba74b ("net: fec: introduce fec_ptp_stop and use in probe fail path") Reviewed-by: Wei Fang Reviewed-by: Frank Li Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260826103428.32807-1-phucduc.bui@gmail.com Signed-off-by: Jakub Kicinski commit 23c53269f2baaedf2d92784290cb9ef6db2a3bce Author: Eric Dumazet Date: Wed Aug 26 10:52:38 2026 +0000 slip: remove slip_hangup() to fix use-after-free in slip_receive_buf() Jaeyoung Chung and Eulgyu Kim reported a slab-use-after-free read in slip_receive_buf() when racing against tty hangup. tty_ldisc_hangup() calls ld->ops->hangup() while holding only a read lock on tty->ldisc_sem (via tty_ldisc_ref()). Because slip_hangup() simply called slip_close(), it ran concurrently with reader functions such as slip_receive_buf(). slip_close() unregisters and frees the net device and its private struct slip, causing concurrent reader threads in slip_receive_buf() to dereference freed memory. Line discipline close() is already guaranteed to be called under the write lock of tty->ldisc_sem during hangup processing (in tty_ldisc_reinit() or tty_ldisc_kill()). Remove slip_hangup() so teardown is serialized cleanly by slip_close(). Fixes: 5342b77c4123 ("slip: Clean up create and destroy") Reported-by: Jaeyoung Chung Reported-by: Eulgyu Kim Closes: https://lore.kernel.org/netdev/20260825150655.1450271-1-jjy600901@snu.ac.kr/ Cc: Qingfang Deng Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260826105238.3323436-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit 9bb34313d94b17a379ea68fae65be0810c88ee64 Merge: 6253a292069591 a9c2f0d401fd1e Author: Linus Torvalds Date: Thu Aug 27 12:38:05 2026 -0700 Merge tag 'spi-fix-v7.3-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A couple of fixes that came in during the merge window: Geert fixed an uninitialised data bug in the amlogic-spisg driver which could crash and in the Loongson driver Li Jun hooked up the existing suspend operations more fully to fix hibernation" * tag 'spi-fix-v7.3-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: loongson: pm: add .freeze .poweroff .thaw .restore spi: amlogic-spisg: Make sure clk_init_data is fully initialized commit 50e5c6605cc9c2dd57bd2d1b3459674d19738983 Author: Norbert Szetei Date: Wed Aug 26 11:12:27 2026 +0200 net: bridge: mcast: fix use-after-free of a master VLAN's multicast context br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context. Fixes: 7b54aaaf53cb ("net: bridge: multicast: add vlan state initialization and control") Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/D400F6C7-543A-4B79-9E5B-D1D8974DE5C9@doyensec.com Signed-off-by: Jakub Kicinski commit 6253a29206959128f5d99a119fcf29bd7fb3c106 Merge: 7cec13314dd893 44f7b876b7c6c7 Author: Linus Torvalds Date: Thu Aug 27 12:21:56 2026 -0700 Merge tag 'regulator-fix-v7.3-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fix from Mark Brown: "One fix here, for a race condition on startup in the tps65185 driver which is seen on actual boards - we need a delay after waking the chip before it is ready to talk to the host" * tag 'regulator-fix-v7.3-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: tps65185: wait for the IC to wake before the first I2C access commit 7cec13314dd8935afbfc0430d9d43fad75285b37 Merge: f7e3f4d9f425cf 1476cca098f6d3 Author: Linus Torvalds Date: Thu Aug 27 12:14:19 2026 -0700 Merge tag 'dma-mapping-7.3-2026-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux Pull dma-mapping fix from Marek Szyprowski: - integer overflow fix for kernel cmdline parser for DMA contiguous initialization code (Alexander Graf) * tag 'dma-mapping-7.3-2026-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux: dma-contiguous: fix truncation of numa_cma / cma_pernuma sizes >= 2G commit 8f735d64382dcf162f4276d6699d03ad2f859c0b Author: Jamal Hadi Salim Date: Tue Aug 25 04:14:03 2026 -0400 net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260825081403.133992-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski commit 88c71cc0ad9800d8814bd3627b21a0da9028e057 Author: Edoardo Pinci Date: Mon Aug 24 15:11:43 2026 +0200 net: dsa: mxl862xx: enable assisted learning on CPU port The MxL862xx driver enables FDB isolation but does not enable assisted learning on the CPU port. Consequently, MAC addresses learned through a physical switch port are not updated in hardware when the corresponding station moves to a foreign bridge port, such as a Wi-Fi interface. The stale hardware FDB entry continues directing return traffic toward the original physical port. Traffic entering that same port is then filtered instead of being forwarded to the CPU and software bridge. This causes downstream unicast traffic, including DHCP OFFER and ACK packets, to disappear after a client roams to a local wireless interface. The client eventually considers the connection unusable and disconnects. Enable assisted CPU-port learning so DSA installs foreign bridge FDB entries on the CPU port. This keeps the hardware FDB synchronized with the software bridge and allows return traffic to reach locally attached Wi-Fi clients after roaming. Tested on a BPI R4 PRO with a MxL862xx switch and a BE14000 WiFi interface. - Without patch, wired uplink on lan6 port (mxl path) Wifi clients connect but roam away not getting DHCP offers - Without patch, wired uplink on wan port (no mxl path) Wifi clients connect and roam successfully - With this patch, uplink on lan6 (mxl path) Wifi clients connect and roam successfully Fixes: 340bdf984613 ("net: dsa: mxl862xx: implement bridge offloading") Signed-off-by: Edoardo Pinci Link: https://patch.msgid.link/DU0P251MB069949C6DEB4D1D51F31FE87C4A02@DU0P251MB0699.EURP251.PROD.OUTLOOK.COM Signed-off-by: Jakub Kicinski commit 23680bf5f8c69c923546b84a8e6c401bef8b88fe Author: Pascal Kneuper Date: Mon Aug 24 14:50:14 2026 +0200 net: stmmac: restore NET_IP_ALIGN in the RX DMA offset Since the RX path was converted to zero-copy, the page pool page is handed to the stack directly as the skb head, and the offset the DMA engine writes at is what determines the alignment of the packet headers. Before the conversion the payload was copied into an skb obtained from napi_alloc_skb(), which reserves NET_SKB_PAD + NET_IP_ALIGN. The conversion moved the headroom into stmmac_rx_offset() but did not carry over NET_IP_ALIGN, so on architectures where NET_IP_ALIGN is 2 the IP header now lands misaligned: 64 (NET_SKB_PAD) + 14 (ethernet) + 20 (IP) = 98 Same for the XDP branch: 256 (XDP_PACKET_HEADROOM) + 14 (ethernet) + 20 (IP) = 290 On ARM32 this is fatal, because ldm and ldrd trap on unaligned addresses even when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set. Any received echo request panics the machine, e.g: Unhandled fault: alignment exception (0x001) at 0x81873062 Internal error: : 1 [#1] SMP ARM Hardware name: Altera SOCFPGA Arria10 PC is at icmp_echo+0x38/0xa8 LR is at icmp_rcv+0x22c/0x370 Call trace: icmp_echo from icmp_rcv+0x22c/0x370 icmp_rcv from ip_protocol_deliver_rcu+0x2c/0x224 ip_protocol_deliver_rcu from ip_local_deliver+0xc8/0x1a0 ip_local_deliver from ip_sublist_rcv_finish+0x3c/0x50 ip_sublist_rcv_finish from ip_list_rcv_finish+0x110/0x118 ip_list_rcv_finish from ip_list_rcv+0xc8/0xdc ip_list_rcv from __netif_receive_skb_list_core+0x170/0x1c0 ... napi_complete_done from stmmac_napi_poll_rx+0xcb0/0x1030 Code: e24dd068 e59020a0 e28dc010 e0822001 (e8920003) Kernel panic - not syncing: Fatal exception in interrupt The faulting instruction is the ldm of *icmp_hdr(skb) in icmp_echo(). Fix by adding NET_IP_ALIGN back to the RX offset, which restores the alignment the stack used to get. Note that commit a955318fe67e ("stmmac: align RX buffers") made a similar change in 2021 and was reverted by commit 12d125b4574b ("stmmac: Revert "stmmac: align RX buffers"") because it caused packet corruption. That patch raised the offset from 0 without adjusting the buffer size accounting, so the DMA engine could arguably write past the end of the RX buffers, though this was never root caused. Commit df542f669307 ("net: stmmac: Switch to zero-copy in non-XDP RX path") since derives the page pool allocation from stmmac_rx_offset(), so the extra bytes are accounted for. Fixes: df542f669307 ("net: stmmac: Switch to zero-copy in non-XDP RX path") Cc: Daniel Baldin Signed-off-by: Pascal Kneuper Link: https://patch.msgid.link/20260824125014.47862-1-PKneuper@dspace.de Signed-off-by: Jakub Kicinski commit f7e3f4d9f425cf4c5577cd84a096e6e618488083 Merge: 7cc2726d4847c4 cf1a12e0804515 Author: Linus Torvalds Date: Thu Aug 27 11:16:39 2026 -0700 Merge tag 'backlight-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight Pull backlight updates from Lee Jones: "New Support & Features: - Silergy SY7758: Add driver for the 6-channel high-efficiency LED driver Improvements & Fixes - Awinic AW99706: Fix device tree property names to match the binding, consistently validate all property values, and honor the core blank state in `update_status()` - Kinetic KTD2801: Add missing dependency on `GPIOLIB` in Kconfig - Qualcomm WLED: Remove redundant `dev_err()` calls Cleanups & Refactoring - Core: Use `sysfs_emit()` instead of `sprintf()` in sysfs show callbacks - Maintainers: Update Junjie Cao's email address for the Awinic AW99706 driver Device Tree Binding Updates - Marvell 88PM860X: Add missing bracket in the example - Silergy SY7758: Document the 6-channel high-efficiency LED driver" * tag 'backlight-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight: backlight: Use sysfs_emit() instead of sprintf() backlight: qcom-wled: Remove redundant dev_err() backlight: ktd2801: Fix unmet dependency on GPIOLIB backlight: aw99706: Honor the core blank state in update_status() backlight: aw99706: Validate all DT property values consistently backlight: aw99706: Fix DT property names to match binding dt-bindings: backlight: 88pm860x: Add missing bracket MAINTAINERS: Update my email address for the AW99706 backlight driver backlight: Add SY7758 6-channel High Efficiency LED Driver support dt-bindings: leds: backlight: Document the SY7758 6-channel High Efficiency LED Driver commit 7cc2726d4847c48844eb0ee16f973d449260f248 Merge: 79b4f3baae2fa6 f8cca63a0a4f34 Author: Linus Torvalds Date: Thu Aug 27 11:05:51 2026 -0700 Merge tag 'leds-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds Pull LED updates from Lee Jones: "New Support & Features: - Core: Extend netdev trigger speeds up to 100G - PWM Multicolor: Introduce default-intensity property - Analog Devices LTC3220: Add support for 18 channel LED driver - NXP PCA963x: Add multicolor LED class support Improvements & Fixes: - GPIO: Clear error pointers for skipped LEDs - Broadcom BCM63138: Use %pe to print pinctrl error instead of %ld - ISSI IS31FL319x: Modernize device registration by using fwnode APIs - NXP PCA9532: Fix inverted GPIO output polarity - NXP PCA9532: Fix phantom device registration on missing hardware - STMicroelectronics ST1202: Correct and extend hw_pattern documentation - STMicroelectronics ST1202: Fix channel disable logic on zero brightness and ensure brightness changes are applied in active mode - STMicroelectronics ST1202: Fix hardware pattern sequence programming, validate inputs, and correct pattern duration calculations - STMicroelectronics ST1202: Validate LED reg property against channel count - TI LP5860: Fix a potential double-unlock during device initialization and fix error handling path by using devm_mutex_init() Cleanups & Refactoring: - GPIO: Make legacy gpiolib interface optional Device Tree Binding Updates: - Core: Add default-intensity property - Core: Document "gpio" trigger - Analog Devices LTC3220: Add DT binding for LTC3220 18 channel LED driver - Broadcom BCM6358: Convert to DT schema - LaCie NS2: Convert to DT schema - NXP PCA963x: Add multicolor LED support - NXP PCA963x: Fix reg maximum for pca9635 - TI TPS65217: Convert backlight bindings to DT schema" * tag 'leds-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (29 commits) leds: is31fl319x: Modernize registration dt-bindings: leds: lacie,ns2-leds: Convert to DT schema leds: pca963x: Add multicolor LED class support dt-bindings: leds: nxp,pca963x: Add multicolor LED support dt-bindings: leds: nxp,pca963x: Fix reg maximum for pca9635 leds: gpio: Clear error pointers for skipped LEDs dt-bindings: leds: backlight: Convert TPS65217 to DT schema leds: pca9532: Fix phantom device registration on missing hardware leds: gpio: Make legacy gpiolib interface optional leds: bcm63138: Use %pe to print pinctrl error instead of %ld dt-bindings: leds: Add default-intensity property leds: ltc3220: Add Support for LTC3220 18 channel LED Driver dt-bindings: leds: Add LTC3220 18 channel LED Driver dt-bindings: leds: bcm6358: Convert to DT schema dt-bindings: leds: Document "gpio" trigger leds: st1202: Correct and extend hw_pattern documentation leds: st1202: Validate LED reg property against channel count leds: st1202: Disable channel when brightness is set to zero leds: st1202: Fix brightness having no effect while pattern mode is active leds: st1202: Fix spurious pattern sequence start in setup ... commit 9c24a504a3af1acb96da8d6a45a373fda8a9c687 Author: Lorenzo Bianconi Date: Mon Aug 24 11:59:08 2026 +0200 net: stmmac: drop gso_enabled_types and rely on netdev features The gso_enabled_types field is used by stmmac_xmit() to decide whether a GSO skb should be passed to stmmac_tso_xmit(). It is updated in stmmac_set_features() based solely on NETIF_F_TSO, so disabling IPv4 TSO while keeping IPv6 TSO (NETIF_F_TSO6) enabled zeroes the mask. As a result IPv6 GSO frames, which the networking stack still generates since NETIF_F_TSO6 is enabled, fall through to the non-TSO xmit path where they are not handled. The networking stack already manages the GSO logic: a GSO skb is only delivered to the driver when the matching offload feature (NETIF_F_TSO, NETIF_F_TSO6 or NETIF_F_GSO_UDP_L4) is enabled, otherwise the frame is segmented in software before reaching ndo_start_xmit(). stmmac_features_check() also validates each GSO frame against the TSO hardware constraints and falls back to software GSO when they are not met. Drop the gso_enabled_types field and rely on skb_is_gso() in stmmac_xmit() instead, which correctly routes IPv6 GSO frames to the TSO path when NETIF_F_TSO is disabled. This also removes the data race between stmmac_set_gso_types(), called from the feature-set path, and the lockless read of gso_enabled_types in stmmac_xmit(). Fixes: 2e4082e4b739 ("net: stmmac: simplify GSO/TSO test in stmmac_xmit()") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260824-stmmac-fix-tso6-features-v3-1-c73a7a4a0ec7@oss.qualcomm.com Signed-off-by: Jakub Kicinski commit 6fe66698b959357c8f780fd21c809b2d83d2a7ee Merge: e2a6641e3bfde5 96e8cb5527ce50 Author: Jakub Kicinski Date: Thu Aug 27 10:53:32 2026 -0700 Merge branch 'net-stmmac-more-selftest-related-fixes' Maxime Chevallier says: ==================== net: stmmac: More selftest related fixes This series addresses some (but not all) issues found while running the ethtool selftest on various stmmac platforms. As a reminder, ethtool selftest are run with 'ethtool -t ethX', and for stmmac the goal is to test hardware features and bugs from the IP integration in the platform. I've been running this on : - Altera CycloneV (dwmac-socfpga, dwmac1000 IP, v3.70a) - NXP imx8mp (dwmac-imx, dwmac4, v5.10a) - Allwinner H2S (dwmac-sun8i, dwmac1000) - Amlogic S905X3 (dwmac-meson8b, dwmac1000, v3.70a) - STM32mp157a (dwmac-stm32, dwmac4, v4.20a) - SiFive JH7110 (dwmac-starfive, dwmac4, v5.20) Here's the results before this series, noting that some bugs were already fixed, some are ongoing (cf. the IP proto patch here [1]) [1] : https://lore.kernel.org/netdev/20260825211748.360935-1-maxime.chevallier@bootlin.com/ Tests are OK if return is 0 or -95 (-EOPNOTSUPP), tests are KO otherwise Test imx socfpga sun8i meson8b stm32 starfive MAC Loopback 0 0 0 0 0 0 MMC Counters 0 0 -95 -22 0 -22 EEE -95 -95 -95 -95 -95 -95 Hash Filter MC 0 0 -95 0 0 0 Perfect Filter UC 0 0 0 0 0 0 MC Filter 0 0 -95 0 0 0 UC Filter 0 0 -95 -22 0 0 Flow Control -110 0 -110 0 0 -110 RSS -95 -95 -95 -95 -95 -95 VLAN Filtering -110 -95 -95 -95 -110 -110 VLAN Filtering (perf) -110 -95 -95 -95 -110 -110 Double VLAN Filter -110 -95 -95 -95 -110 -110 Double VLAN Filter (perf) -110 -95 -95 -95 -110 -110 Flexible RX Parser 0 -95 -95 -95 -95 -95 SA Insertion (desc) 0 -95 -95 -95 0 0 SA Replacement (desc) 0 -95 -95 -95 0 0 SA Insertion (reg 0 -95 -95 -95 0 0 SA Replacement (reg) 0 -95 -95 -95 0 0 VLAN TX Insertion -110 -95 -95 -95 -110 -110 SVLAN TX Insertion -110 -95 -95 -95 -110 -95 L3 DA Filtering 0 -95 -95 -95 -95 -95 L3 SA Filtering 0 -95 -95 -95 -95 -95 L4 DA TCP Filtering 0 -95 -95 -95 -95 -95 L4 SA TCP Filtering 0 -95 -95 -95 -95 -95 L4 DA UDP Filtering 0 -95 -95 -95 -95 -95 L4 SA UDP Filtering 0 -95 -95 -95 -95 -95 ARP Offload -95 -95 -95 -95 -110 -110 Jumbo Frame 0 0 0 0 0 0 Multichannel Jumbo 0 -95 -95 -95 -95 -95 Split Header -95 -95 -95 -95 -95 -95 TBS (ETF Scheduler) -95 -95 -95 -95 -95 -95 So, only sogfpga is all OK (in all fairness, it doesn't support much) Several issues : - MMC test failing on starfive and meson8b, solved by patch 1 MMC counters maintained by the MAC are optional, which one is implemented depends on how the IP is synthesized. On starfive and meson8b, the counter used by the selftest to validate the MMC counters feature isn't implemented. Solved by adding other counters in the validation step, kinda fragile as this doesn't guarantee this will work on all platforms. - Flow control test failing on starfive, imx8mp, sun8i, solved by patch 6 Turns out these platforms actually never emit any Pause frame, as they don't have enough room in their per-queue RX Fifo. They do correctly process RX Pause frames. The fix isn't to change the advertised pauseparams, as the pause negotiation process based on MAC capabilities doesn't allow us to say we "just" support RX pause, so let's just not run the Pause tests if the RX fifo is too small. - UC filter failing on meson8b, fixed by patches 2,3,4 and 5 This one is quite the rabbit hole, and is a combination of multiple issues. - Unicast filtering uses the same filter (perfect filter) to allow the primary MAC address and the secondary addresses (dev->uc) to flow through the interface. That means if we have say 64 slots in the perfect filter, only 63 can be used for the dev->uc list, as the first entry stores the MAC address. If the filter is full, we switch to UC promisc mode, were we let all UC frames flow. There's an off-by-one error in dwmac1000, dwmac4 and dwxgmac2. - The selftest itself needs an empty slot in the filter, so it has to check that sizeof(dev->uc) is $number_of_slots - 2 (one for primary MAC, one for the test). There's an off-by-two error in the selftest. - This leads to an interesting finding (not addressed by this series) : The size of the perfect filter isn't reported by the HW, so it comes from firmware (snps,perfect-filter-entries). A lot of platforms don't specify that in DT (e.g. imx8mp doesn't, it has 128 entries but the driver thinks there's only 1...). I've reached out to Synopsys to see if there's some sane default we could use on dwmac4, if anyone has a dwmac4 databook I'd appreciate if you could look this up, as I don't have access to them, I'm not a vendor... Otherwise, we'll have to patch all the .dtsi if we want to avoid going in UC promisc as soon as we add an entry in dev->uc. After this series, socfpga, starfive and sun8i are all OK :) Some issues are still out there, the VLAN filtering and tagging fails on imx8mp and stm32 (so, dwmac4) butI haven't got there yet. ARP offload doesn't work on stm32mp157a and starfive JH7110 either. ==================== Link: https://patch.msgid.link/20260826140500.616466-1-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit 96e8cb5527ce50c024a8e2d22d2bfedeccaf97d0 Author: Maxime Chevallier Date: Wed Aug 26 16:04:58 2026 +0200 net: stmmac: selftests: Don't test flow control for small rx fifos On dwmac1000, dwmac4 and dwxgmac, we only emit pause frames if there's at least 4096 bytes in each queue's fifo. The phylink mac capabilities are still MAC_ASYM_PAUSE | MAC_SYM_PAUSE as otherwise we won't be able to negotiate 'rx on' pause. ASYM only will prevent negotiating 'rx off tx on', while SYM only doesn't really matche the reality (not symmetric if we can only do RX pause). Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-7-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit cd8c3b2752c684141eab2282e294cae2971a9759 Author: Maxime Chevallier Date: Wed Aug 26 16:04:57 2026 +0200 net: stmmac: selftests: Account for the UC filter list for filtering tests On dwmac, one of the Unicast filter entries is used to store the local HW addr. This means that we have to use promisc mode for any kind of unicast filtering if we only have one slot in our unicast filter. The number of slots available depends on how the IP is integrated, and we can't autodiscover how many of these slots we have available, so the DT property snps,perfect-filter-entries can be used to specify how many are available. Most IP variants default to 1 if this isn't specified, which is the case for the amlogic variants (in this case, S905X3). The stmmac selftests for UC filtering look if we have enough slots in the filter to store the dev->uc list, but doesn't account for the device's own MAC address. The dev->uc list's size we get with netdev_uc_count() also doesn't account for the HW addr. As the selftest only requires one available slot, in the case of single-slot platforms, that means we erroneously consider we have enough room for the test, when we actually don't, and the filtering test fails. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-6-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit 2739d6f9a2b8729b0d85cbe0dc93e1d68670b6f2 Author: Maxime Chevallier Date: Wed Aug 26 16:04:56 2026 +0200 net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering The same filter slots are used to store the main MAC address as well as the address for the unicast filter. Let's account for that when deciding whether or not to use promisc when programming the UC list in hardware. Fixes: 0efedbf11f07 ("net: stmmac: xgmac: Fix XGMAC selftests") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-5-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit 82187f42c014d22520b9c3c4e2cfb519223fb29b Author: Maxime Chevallier Date: Wed Aug 26 16:04:55 2026 +0200 net: stmmac: dwmac4: Account for the primary MAC address for UC filtering The same filter slots are used to store the main MAC address as well as the address for the unicast filter. Let's account for that when deciding whether or not to use promisc when programming the UC list in hardware. Fixes: 477286b53f55 ("stmmac: add GMAC4 core support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-4-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit 9698b6da3714fd2ef47846cb63098d2b2d252e25 Author: Maxime Chevallier Date: Wed Aug 26 16:04:54 2026 +0200 net: stmmac: dwmac1000: Account for the primary MAC address for UC filtering The same filter slots are used to store the main MAC address as well as the address for the unicast filter. Let's account for that when deciding whether or not to use promisc when programming the UC list in hardware. Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-3-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit d29b399150b07796dfa81d8778d4804c08c2a41d Author: Maxime Chevallier Date: Wed Aug 26 16:04:53 2026 +0200 net: stmmac: selftests: Check multiple MMC counters The MMC counters report MAC statistics. Multiple counters can be enabled when the IP is integrated, however there's no way to know exactly which ones. Un-implemented counters seem to report 0. It was found that on StarFive JH7110 and Amlogic SM1, the counter that's used by the selftest (mmc_tx_framecount_g) isn't implemented, triggering an MMC selftest failure. Both the above SoCs seem to implement mmc_rx_framecount_gb, let's use this counter as well for MMC counter validation. Note that this doesn't guarantee that we won't encounter the same issue again if another IP implements yet another set of counters that don't include that new one. If the game of whack-a-mole with implemented counters becomes too hard to maintain, we may simply consider removing the MMC selftest entirely. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski commit 79b4f3baae2fa65060c30f827e3c0e8f1db99f98 Merge: 18fbf5151d2c0b 9d0e4b1ae5b045 Author: Linus Torvalds Date: Thu Aug 27 10:45:08 2026 -0700 Merge tag 'mfd-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "New Support & Features: - MediaTek MT6397: Add mt6323 AUXADC support - MediaTek MT6397: Add mt6323 EFUSE support - Spreadtrum SC27xx: Add SC2730 regulator cell Improvements & Fixes: - Apple SMC: Fix key count endianness annotation - Azoteq IQS62x: Reject zero-length firmware records - ChromeOS EC: Introduce cros_ec_read_features helper and read features during probe to catch transfer errors - Cirrus Logic CS42L43: Fix regmap defaults ordering - Cirrus Logic CS42L43: Remove redundant NULL checks on SoundWire - Congatec Board Controller: Fix teardown ordering in cgbc_remove() - HP iPAQ Micro: Fix out-of-bounds stack read in ipaq_micro_str - Marvell 88PM886: Initialize the battery page - QNAP MCU: Keep the reply buffer alive past a command timeout - RAVE SP: Validate received frame payload lengths - Silicon Labs Si476x: Drop duplicate NULL checks - Silicon Labs Si476x: Modernize GPIO handling - Silicon Motion SM501: Fix potential memory leaks during remove - UCB1x00: Convert Assabet gpio-keys to use software nodes and register software node for GPIO controller - Viperboard: Fix native fields type in structures as little-endian - Viperboard: Remove redundant NULL check before kfree() - X-Powers AXP20x: Preserve other control bits when powering off Cleanups & Refactoring: - Core: Drop unused assignment of spi_device_id driver data - Core: Initialize spi_device_id arrays using member names - Core: Unify style of spi_device_id arrays - Maintainers: Add Intel LPSS section to follow the changes - Maintainers: Add a mailing list entry to MFD - Cirrus Logic CS42L43: Format sdw_device_id table - Cirrus Logic CS42L43: Use new SoundWire enumeration helper - ROHM PMIC: Factor out power button registration and convert gpio-keys to use software nodes - ST-Ericsson DB8500: Fold dbx500 header into db8500 Device Tree Binding Updates: - Core: Add techvision vendor prefix - Marvell 88PM886: Allow vbus regulator - MediaTek MT8195 SCP: Add support for MT8189 SoC - Qualcomm SPMI PMIC: Document PMG1110 - Qualcomm SPMI PMIC: Document haptics device - Qualcomm TCSR: Add compatible for Hawi and Maili SoCs - Qualcomm TCSR: Add compatible for Shikra - Qualcomm TCSR: Document the IPQ9650 TCSR block - STMicroelectronics STMPE: Fix typo st,stmpe601 (should be st,stmpe610) - Syscon: Add ESWIN EIC7700 compatible - Syscon: Allow syscon compatible for Loongson-2K0300 chip id - Syscon: Disallow simple-bus with syscon - Syscon: Drop custom select for older dtschema - TI OMAP USBHS TLL: Convert to DT schema" * tag 'mfd-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (45 commits) mfd: cs42l43: Fix regmap defaults ordering dt-bindings: mfd: syscon: Allow syscon compatible for Loongson-2K0300 chip id dt-bindings: mfd: syscon: Add ESWIN EIC7700 compatible mfd: qnap-mcu: keep the reply buffer alive past a command timeout dt-bindings: mfd: qcom,tcsr: Document the IPQ9650 TCSR block mfd: macsmc: Fix key count endianness annotation dt-bindings: mfd: qcom,spmi-pmic: Document haptics device mfd: iqs62x: Reject zero-length firmware records mfd: rave-sp: validate received frame payload lengths mfd: sm501: Fix potential memory leaks during remove mfd: viperboard: Fix native fields type in structures as little-endian mfd: si476x-i2c: Get rid of duplicate NULL checks dt-bindings: mfd: Convert OMAP USB TLL to DT schema mfd: cgbc: Fix teardown ordering in cgbc_remove() mfd: mt6397-core: Add mt6323 AUXADC support dt-bindings: mfd: qcom,tcsr: Add compatible for Hawi and Maili SoCs mfd: rohm: Factor out power button registration mfd: ucb1x00: Convert Assabet gpio-keys to use software nodes mfd: ucb1x00: Register software node for GPIO controller mfd: cs42l43: Tidy up formatting on sdw_device_id table ... commit 18fbf5151d2c0bfe433c7428eef03cabf5fdb2fa Merge: 5e6ff28676dd92 0685630fdccb62 Author: Linus Torvalds Date: Thu Aug 27 09:17:06 2026 -0700 Merge tag 'mm-stable-2026-08-26-15-22' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull more MM updates from Andrew Morton: - "mm/rmap: index MAP_PRIVATE file-backed folios by anonymous pgoff" (Lorenzo Stoakes) Index MAP_PRIVATE file-backed folios by their anonymous page offset to resolve confusion around reverse mapping for zeroed and CoW'd file-backed memory. Use this new VMA anonymous page offset tracking to eliminate index conflicts and lay the foundation for scalable CoW performance improvements. - "promote mapped executable folios after first usage for MGLRU" (Baolin Wang) Make MGLRU's protection of mapped executable file folios more reliable. Follow the classical LRU's logic, promoting mapped executable file folios after their first usage to give executable code a better chance to stay in memory and improve workload performance. - "mm: vmscan: fix node reclaim ignoring swappiness parameter" (Ridong Chen) Fix per-node proactive reclaim interface's ignoring the swappiness parameter when CONFIG_MEMCG is disabled by consolidating sc_swappiness() into a single function that checks proactive_swappiness regardless of kernel configuration. - "mm/vmscan: reduce lru_lock contention via vmstat-derived scan-balance cost" (Usama Arif) Reduce lru_lock contention in the reclaim path by deriving scan-balance costs from vmstat counters rather than lock-acquired producer updates. Read and decay these cost signals on the reclaim side under a dedicated per-lruvec lock, reducing total LRU lock wait time by over 60% without impacting scan throughput. - "zram: fix zram issues reported by sashiko" (Sergey Senozhatsky) Fix two low-risk zram bugs which Sashiko spotted in drive-by review. - "Honor XA_FLAGS_ACCOUNT in xas_split_alloc() and charge to folio's memcg" (Zi Yan) Fix xas_split_alloc() by enabling target folio memcg charging during splits and adding the missing __GFP_ACCOUNT flag for proper XArray node memory accounting. - "selftests/mm: use pattern matching in .gitignore" (Pratyush Mallick) Replace hardcoded binary names in selftests/mm/.gitignore with a generic pattern-matching rule to automatically ignore generated test files and avoid manual updates when adding new tests. - "mm/page_ext: remove pgdat_page_ext_init()" (Sang-Heon Jeon) Make the incompatibility between FLATMEM and NUMA explicit in mm/Kconfig and remove the unused pgdat_page_ext_init() function. - "zram: fix zstd error paths and add parameter validation" (Haoqin Huang) Clean up zram compression backends by removing redundant error cleanup, adding parameter and dictionary validation, auto-prefixing algorithm error logs, and resetting parameters prior to reinitialization. - "zram: fix stale scan bounds after reinitialization" (Longlong Xia) Prevent out-of-bounds slot accesses during concurrent zram resets by moving table scan bound calculations under dev_lock in writeback_store() and read_block_state(). - "add anon mTHP collapse test cases" (Baolin Wang) Extend selftests helper functions to support arbitrary page orders and add new test cases and options for mTHP collapse in khugepaged. - "selftests/mm: Handle unsupported and transient test conditions" (Muhammad Usama Anjum) Update MM selftests to report a SKIP status instead of a failure when required kernel or filesystem features are unsupported, while adding retry logic for transient page migration errors. - "mm/zswap: Fixes and improves the zswap shrink" (Hao Jia) Fix the missing zswap global shrinker when CONFIG_MEMCG is disabled and extend shrink_memcg() to support batch writeback for improved writeback efficiency. - "alloc_tag: introduce IOCTL-based filtering for MAP" (Suren Baghdasaryan) Introduce an IOCTL-based binary interface for memory allocation profiling that enables kernel-side filtering before per-CPU counter aggregation. This eliminates the text-parsing overhead of /proc/allocinfo and provides up to a 20x speedup by transferring only filtered allocation data to userspace. - "better block swap batching and a different take on swap_ops v5" (Christoph Hellwig) Refactor block swap I/O to use swap_iocb for batching instead of single-bio requests and rebase the swap_ops interface, achieving faster swap throughput during kernel builds. - "mm: kmemleak: reduce transient false positives by confirming leaks" (Catalin Marinas) Reduce false-positive kmemleak reports by combining two kmemleak enhancements that add a second confirmation scan and a configurable minimum unreferenced scan count module parameter. - "mm: kmemleak: default min_unref_scans to 2 for verbose kernels" (Breno Leitao) Auto-scanning kernels can generate false-positive memory leak reports on single scans, so this patch defaults min_unref_scans to 2 when CONFIG_DEBUG_KMEMLEAK_VERBOSE is enabled to require a second confirming scan. - "swap_ops updates" (Christoph Hellwig) Batching I/O for synchronous swap devices causes performance regressions and filesystem-based swap suffers from double-indirection overhead. This series resolves both issues by reintroducing per-folio writes for synchronous swap and allowing filesystems to directly export their own swap_ops. - "mm/khugepaged: several cleanups" (Nico Pache) khugepaged accumulated redundant state-checking patterns and outdated comments following mTHP integration. Introduce dedicated helpers for PTE validation and event counting while refreshing the internal documentation. - "maple_tree: lock checking and clean ups" (Liam Howlett) Syzbot reports incorrectly blame memory management exit paths for locking bugs, maple tree erase operations risk allocation failures without gfp flags and internal documentation lacks clarity. Improve lock error detection, update docs, fix race and allocation edge cases and optimize erase allocations using a fallback to GFP_KERNEL | GFP_NOFAIL. * tag 'mm-stable-2026-08-26-15-22' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (172 commits) selftests/proc: make proc-maps-race work with READ_IMPLIES_EXEC memcg: move LRU size accounting on reparenting instead of copying it mm/vmscan: fix comment logic in balance_pgdat maple_tree: add helper mas_make_walkable() maple_tree: avoid extra gap calculation maple_tree: fix argument name in header maple_tree: change two GFP flags in tests maple_tree: document erase and allocations better maple_tree: avoid mas_erase() and mtree_erase() failures maple_tree: document that erase may use GFP_KERNEL for allocations maple_tree: catch race in mas_alloc_cyclic() maple_tree: add bulk parent set helper maple_tree: micro optimisation of mas_wr_store_type() maple_tree: optimise mas_wr_node_store() when not in rcu mode maple_tree: use prefetched value in mas_wr_store_type() maple_tree: clarify comments on mas_nomem() maple_tree: drop MAPLE_ALLOC_SLOTS maple_tree: drop dead code from mas_extend_spanning_null() maple_tree: documentation fix maple_tree: add write lock checking with lockdep sequence numbers ... commit a62212b35a214c2ff3bd1c785a440d7ad8205ec9 Author: Anoop Vijay Date: Tue Aug 25 10:28:28 2026 -0700 drm/xe/sysctrl: Read mailbox phase bit from hardware The mailbox PHASE bit in SYSCTRL_MB_CTRL is toggled per-message and was tracked in software as sc->phase_bit, reset to 0 on error paths. If the cached value ever drifts from what the hardware last saw, all following messages carry the wrong phase and get silently misread by firmware. Drop the cache and read PHASE directly from SYSCTRL_MB_CTRL before each frame instead, removing xe_sysctrl_mailbox_init() and its call sites along with it. Fixes: 1f95f618182b ("drm/xe/xe_sysctrl: Add System Controller mailbox communication support") Signed-off-by: Anoop Vijay Reviewed-by: Umesh Nerlige Ramappa Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260825172827.3801591-2-anoop.c.vijay@intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit 04984fcdbf6876c940c01026a7404c1e9cc91ba7) Signed-off-by: Rodrigo Vivi commit 244abef7f280a6a84297bfab5fd2e77147bc419a Author: Heikki Krogerus Date: Tue Aug 11 14:10:08 2026 +0200 drm/xe/i2c: Keep the i2c controller always enabled Some platforms make an assumption that the i2c controller's enabled state indicates also the power state of the controller. This can create a problem when the controller is in disabled state, because the hardware may assume incorrectly that it is then also in low-power state. To fix this, the controller is kept enabled by taking over the IC_ENABLE register. The controller has to be disabled when the configuration is updated and when the target address or the slave address are assigned, so disabling it when IC_CON, IC_TAR or IC_SAR registers are programmed, and then re-enabling it again. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260811121008.1493015-4-heikki.krogerus@linux.intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit 76cc14e2faed1adae20f4ee144ead0e3a7566c49) Signed-off-by: Rodrigo Vivi commit f43fa4b8522ba6038b77e86e5f0d94be35effcde Author: Heikki Krogerus Date: Tue Aug 11 14:10:07 2026 +0200 drm/xe/i2c: Fix the interrupt handling The platforms that support the interrupt from the I2C adapter can not handle the amount of interrupts the adapter generates because of the way the IRQ is routed in the hardware. The I2C controller driver has to be kept in polling mode because of that. The AMC MCU can still generate critical alerts that have to be handled. The interrupt from SMBus Alert is left enabled and handled separately in the Xe. The alerts from the AMC will cause the device to be declared wedged for now. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Cc: stable@vger.kernel.org Reviewed-by: Raag Jadav Co-developed-by: Ramesh Babu B Signed-off-by: Ramesh Babu B Signed-off-by: Heikki Krogerus Link: https://patch.msgid.link/20260811121008.1493015-3-heikki.krogerus@linux.intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit a55b76b8bc2c49b11d753c1c6d06ec3a2c61c85e) Signed-off-by: Rodrigo Vivi commit 874ef9a6f2fc45d3f6021842d92fa5420fa4c825 Author: Heikki Krogerus Date: Tue Aug 11 14:10:06 2026 +0200 i2c: designware: Global register definitions Moving the register definitions to a global header file include/linux/designware_i2c.h. That removes the need to duplicate them in the adaptation layers for this driver outside of drivers/i2c/busses/. There is at least one of those in drivers/gpu/drm/xe/xe_i2c.c. Suggested-by: Andy Shevchenko Suggested-by: Raag Jadav Reviewed-by: Raag Jadav Reviewed-by: Mika Westerberg Reviewed-by: Andy Shevchenko Signed-off-by: Heikki Krogerus Acked-by: Mika Westerberg Link: https://patch.msgid.link/20260811121008.1493015-2-heikki.krogerus@linux.intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit 2ab2fb31411a494e4579dfacda986a2672f80e65) Signed-off-by: Rodrigo Vivi commit e2a6641e3bfde58f2284f9859c2b0fdcc6d1c0da Merge: 6fe7e31a45e341 1d62b83fb75125 Author: Jakub Kicinski Date: Thu Aug 27 08:42:30 2026 -0700 Merge branch 'improve-stability-of-big_tcp_tunnels-sh-selftest' Alice Mikityanska says: ==================== Improve stability of big_tcp_tunnels.sh selftest This series addresses flakiness of big_tcp_tunnels.sh discussed at: https://lore.kernel.org/netdev/349c582c-73e3-468c-91cd-ad6cc3562700@app.fastmail.com/ Lower the thresholds to avoid failures like this (number of packets below the threshold): https://netdev-ctrl.bots.linux.dev/logview.html?f=/logs/vmksft/net-dbg/results/754376/28-big-tcp-tunnels-sh/stdout Tweak tcp_min_tso_segs and initcwnd to avoid failures like this (BIG TCP doesn't kick in in slow configurations): https://netdev-ctrl.bots.linux.dev/logview.html?f=/logs/vmksft/net-dbg/results/751124/21-big-tcp-tunnels-sh/stdout v2 changes: Use $KSFT_MACHINE_SLOW instead of probing kernel config. v1: https://lore.kernel.org/netdev/20260814194124.3102581-1-alice.kernel@fastmail.im/ ==================== Link: https://patch.msgid.link/20260822120308.1165200-1-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski commit 1d62b83fb75125344693db8ebf970653db529f40 Author: Alice Mikityanska Date: Sat Aug 22 15:03:08 2026 +0300 selftests: net: Fix slow configurations in big_tcp_tunnels.sh The combination of checksum offload disabled (that causes software GSO) and a debug kernel is inherently slow. Depending on the CPU power and load, RTT may increase, limiting sk_pacing_rate, so tcp_tso_autosize caps SKBs at around 40 segments, and zero BIG TCP packets are produced. Increase sysctl net.ipv4.tcp_min_tso_segs and set a bigger initial value of CWND in these configurations to force BIG TCP. Fixes: 5cb53743e1ff ("selftests: net: Add a test for BIG TCP in UDP tunnels") Signed-off-by: Alice Mikityanska Acked-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260822120308.1165200-5-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski commit f7d0400bd3452ed6915592b1929ba1d39d8e6552 Author: Alice Mikityanska Date: Sat Aug 22 15:03:07 2026 +0300 selftests: net: Lower threshold with csum offload off in big_tcp_tunnels.sh With checksum offload disabled, much fewer BIG TCP packets are generated due to overall loss of throughput. Use a separate threshold in these tests, which is 1/10 of the threshold set for the rest of tests. Fixes: 5cb53743e1ff ("selftests: net: Add a test for BIG TCP in UDP tunnels") Signed-off-by: Alice Mikityanska Acked-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260822120308.1165200-4-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski commit bb42c16f489f10144f7d2fbb1f57753f14e12ac8 Author: Alice Mikityanska Date: Sat Aug 22 15:03:06 2026 +0300 selftests: net: Lower threshold on debug kernels for big_tcp_tunnels.sh Debug kernels on upstream CI runners run slower and generate fewer BIG TCP packets, making the test flaky on upstream CI runners. Lower the default threshold for those kernels. Fixes: 5cb53743e1ff ("selftests: net: Add a test for BIG TCP in UDP tunnels") Signed-off-by: Alice Mikityanska Acked-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260822120308.1165200-3-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski commit dc170da3347e0f7b6d120d13882c4e1f04ca00d6 Author: Alice Mikityanska Date: Sat Aug 22 15:03:05 2026 +0300 selftests: net: Wait for netserver to launch Use wait_local_port_listen after starting netserver in big_tcp_tunnels.sh to ensure it's listening when the test starts. Fixes: 5cb53743e1ff ("selftests: net: Add a test for BIG TCP in UDP tunnels") Signed-off-by: Alice Mikityanska Acked-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260822120308.1165200-2-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski commit 6fe7e31a45e3418a39e6343a85126124feec1c2f Author: Daniel Pawlik Date: Thu Aug 20 10:59:40 2026 +0200 net: airoha: npu: fix missing streaming DMA mask The driver calls dma_set_coherent_mask() but never dma_set_mask(), leaving the streaming DMA mask at the bus default. On the non-coherent EN7581 platform (Cortex-A53), this causes the NPU mailbox to hang after approximately 41 calls when using streaming DMA mappings. Replace dma_set_coherent_mask() with dma_set_mask_and_coherent() to set both the streaming and coherent DMA masks, matching standard driver practice. Fixes: 6f884eb87a79 ("net: airoha: Fix DMA direction for NPU mailbox buffer") Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260814110017.2795022-1-pawlik.dan@gmail.com/ Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260809152813.585797-1-pawlik.dan@gmail.com/ Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260805070851.2885888-1-pawlik.dan@gmail.com/ Signed-off-by: Daniel Pawlik Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260820085941.380401-1-pawlik.dan@gmail.com Signed-off-by: Jakub Kicinski commit 20839d02c0cf7437bc508d4c5430538d9dc4f428 Author: Thierry Reding Date: Wed Aug 26 12:54:21 2026 +0200 drm/tegra: Add blend mode properties The default programming in the driver matches the "coverage" blend mode, so add the corresponding pixel blend mode property to let userspace know about it. Tested-by: Jon Hunter Acked-by: Jon Hunter Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260826105421.1825331-1-thierry.reding@kernel.org commit 5bb01c657ff9fc807c2c592ca18af34c4fc3bc6f Author: Abdurrahman Hussain Date: Wed Aug 5 13:31:00 2026 -0700 of: fix out-of-bounds read in of_alias_scan() stem parser The stem parser tests isdigit(*(end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first. Fixes: 611cad720148 ("dt: add of_alias_scan and of_alias_get_id") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 [Claude Code] Signed-off-by: Abdurrahman Hussain Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260805-nh-of-alias-overlay-v6-1-74f21d440819@nexthop.ai Signed-off-by: Rob Herring (Arm) commit 2bd533739234d79b74afabfece1abfe9c6d52c83 Author: Muhammad Usama Anjum Date: Tue Aug 25 12:18:37 2026 +0100 selftests/arm64: Add MTE test config fragment The arm64 selftest collection has no Kconfig fragment, so kernels built with the selftest requirements are not guaranteed to provide the support used by these tests. Add a fragment covering all tests in arm64. Reviewed-by: Mark Brown Signed-off-by: Muhammad Usama Anjum Reviewed-by: Vincenzo Frascino Signed-off-by: Will Deacon commit bb52892f9234e4ecd982fa51222aab33ce282f79 Author: Muhammad Usama Anjum Date: Tue Aug 25 12:18:36 2026 +0100 selftests/arm64: Fix MTE prctl TAP plan The MTE prctl test emits one result from check_basic_read() followed by one result for each of the seven entries in mte_modes[]. However, the TAP plan only accounts for the array entries, producing: # Planned tests != run tests (7 != 8) Include the basic read check in the plan so that all eight emitted results are declared. Reviewed-by: Mark Brown Fixes: 1f488fb91378 ("kselftest/arm64/mte: Add MTE_STORE_ONLY testcases") Signed-off-by: Muhammad Usama Anjum Reviewed-by: Vincenzo Frascino Signed-off-by: Will Deacon commit 1a0dba077f34a2f8faa98308d30d4b546d073145 Author: Muhammad Usama Anjum Date: Tue Aug 25 12:18:35 2026 +0100 selftests/arm64: Treat KSM merge_across_nodes as optional The MTE KSM test requires write access to KSM sysfs but does not check that it is running as root. It also unconditionally saves, enables and restores the merge_across_nodes attribute. The kernel only creates this attribute when CONFIG_NUMA=y, so a non-NUMA kernel prints the following message three times even though every KSM subtest passes: # ERR: missing /sys/kernel/mm/ksm/merge_across_nodes Skip the test when it is not running as root. Check that the optional attribute is readable and writable, treating ENOENT as its expected absence on non-NUMA kernels and skipping the test for other access failures. Only save, enable and restore the attribute when it is available. Check MTE availability before the privilege and sysfs checks so systems without MTE retain the existing feature-unavailable skip result. This preserves the existing behavior on NUMA kernels without requiring NUMA or reducing KSM coverage on single-node systems. Fixes: f981d8fa2646 ("kselftest/arm64: Verify KSM page merge for MTE pages") Signed-off-by: Muhammad Usama Anjum Reviewed-by: Vincenzo Frascino Reviewed-by: Mark Brown Signed-off-by: Will Deacon commit 8d2237e9d6902e234bb89aabb9cd6a9e91357223 Author: Muhammad Usama Anjum Date: Tue Aug 25 12:18:34 2026 +0100 selftests/arm64: Print missing MTE TAP headers Most MTE tests set a TAP plan and emit results without first printing the TAP version header. Direct execution therefore starts with a plan such as "1..20" instead of "TAP version 13". The problem is particularly visible in the GCR_EL1 context-switch test. It prints its plan before forking 1,024 child processes. When stdout is fully buffered, the plan remains in the stdio buffer. Each child inherits the pending "1..1" line and flushes its copy from exit(), producing repeated plan lines. ksft_print_header() prints the TAP header and enables line buffering. Call it in every MTE test that is missing it. In the GCR_EL1 test, call it before the plan so the plan is flushed before the children are forked. In the remaining tests, call it before setup and prerequisite checks so early failures and whole-test skips also retain the header. Fixes: 29f080881601 ("kselftest/arm64: check GCR_EL1 after context switch") Signed-off-by: Muhammad Usama Anjum Reviewed-by: Vincenzo Frascino Reviewed-by: Mark Brown Signed-off-by: Will Deacon commit f5b8b9037df387394a73aab47c5437bbac975077 Author: Karl Mehltretter Date: Thu Aug 20 00:27:12 2026 +0200 arm64: compat: Fix decrementing LDM/STM alignment emulation The compat alignment emulator inherited unsigned long data addresses from the 32-bit ARM implementation. In do_alignment_ldmstm(), nr_regs is an unsigned int holding the transfer size. The function uses the same address addition for both transfer directions, negating nr_regs first for a decrementing LDM or STM. The 32-bit negation wraps before the addition, so the handler adds nearly 4 GiB instead of subtracting the transfer size. The resulting address lies outside the compat task's address space, so decrementing LDM/STM emulation fails, while incrementing forms work. For example, a backwards-moving copy routine using decrementing LDM/STM can take an alignment fault when called with unaligned pointers. The compat handler should emulate the transfer, but this bug instead causes SIGBUS. The offset negated in do_alignment_finish_ldst() is offset_union.un, which is already unsigned long and does not have this width mismatch. Make nr_regs unsigned long so its negation and the address arithmetic use the same width. Fixes: 3fc24ef32d3b ("arm64: compat: Implement misalignment fixups for multiword loads") Cc: stable@vger.kernel.org Suggested-by: Arnd Bergmann Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon commit c4a0927f535f779700d5ccda8182c2db01e9d551 Merge: 74e3b979ce8b78 15596a87fcc6fa Author: Takashi Iwai Date: Thu Aug 27 16:15:47 2026 +0200 Merge tag 'asoc-fix-v7.3-merge-window' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v7.3 A fairly big batch of fixes that came in during the merge window. There's a lot of quirks for x86 systems and a bunch of driver specific fixes, the most critical being the fixes for Tegra's register definitions. It turned out that they had been relying on the regmap default handling bugs that were fixed in v7.2 and so audio was fairly badly broken, unfortunately the issue wasn't noticed in time for release. commit 74e3b979ce8b78a690f8b94ccf2e2c965f7f5c11 Author: Takashi Iwai Date: Thu Aug 27 13:39:03 2026 +0200 ALSA: control: Don't add invalid kcontrols to LED layer The kcontrol LED state layer tries to track the all associated kcontrol elements with naive assumptions that they are readable. But one can create a write-only element that has no get callback (even a user element can do it), and this may lead to a NULL dereference at the call chain of snd_ctl_led_notify(), as found by syzkaller. For avoiding the Oops, add a sanity check of the kcontrol's info and get callbacks, and just skip the invalid kcontrols before assigning the kctl to the LED layer. Reported-by: syzbot+b7fe2760ea6f1ee44b4d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a9007b3.1d9ded08.62e62.00cd.GAE@google.com Fixes: 22d8de62f11b ("ALSA: control - add generic LED trigger module as the new control layer") Reviewed-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260827113951.893291-1-tiwai@suse.de commit fc04229727d8fffbf02e0635de38413fe0102d02 Author: Pablo Neira Ayuso Date: Fri Aug 21 12:25:55 2026 +0200 netfilter: nf_tables: remove leftover set_update_list This list has been moved to per-netns, remove onstack list which is not used anymore. Fixes: b343ededb3f9 ("netfilter: nf_tables: move set_update_list to nftables per-netns") Signed-off-by: Pablo Neira Ayuso commit 132a02beb46fc4d497c41c81ed0dda7956fa4171 Author: Pablo Neira Ayuso Date: Thu Aug 20 10:26:32 2026 +0200 netfilter: nf_tables: set on dead bit when performing early element removal .commit call for sets is skipped if set->dead flag is set on, but this flag is set on later in the commit path. This also reintroduces the bug fixed in commit 7315dc1e122c8 ("netfilter: nf_tables: skip set commit for deleted/destroyed sets"). Fixes: 1e3b9e1c77fe ("netfilter: nf_tables: call set ops .commit when building new ruleset blob") Signed-off-by: Pablo Neira Ayuso commit 43559058d21e0493aa220ac167e0279334dea5f9 Author: Pablo Neira Ayuso Date: Wed Aug 19 13:42:36 2026 +0200 netfilter: nf_tables: skip double clone set expressions on element insert 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 commit 793d9eda4821f75b5f7cc9e6a870b72a58b44c2b Author: Pablo Neira Ayuso Date: Tue Aug 18 10:31:24 2026 +0200 netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited() Several xtables extension still use pr_err() or pr_info() without ratelimit. For xt_cgroup, while at this, remove redundant "xt_cgroup:" prefix since pr_fmt is already set on. Fixes: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match") Signed-off-by: Pablo Neira Ayuso commit f43358489db46c8ad63207ee229ebdf1e7932be9 Author: Pablo Neira Ayuso Date: Tue Aug 18 10:15:05 2026 +0200 netfilter: x_tables: remove pr_debug Remove pr_debug() for these xtables extensions, these have no use these days. Still, turn pr_debug() into pr_info_ratelimited() in the .checkentry path since this helps provide a hint via dmesg in legacy iptables. Exception is xt_IDLETIMER in the module init path, where pr_err() is used. Add missing pr_fmt() definition in xt_REDIRECT, xt_NETMAP and xt_MASQUERADE. Add missing \n to several pr_debug() that were translated to use pr_info_ratelimited(). Link: https://patch.msgid.link/cover.1786933680.git.rakukuip@gmail.com/ Signed-off-by: Pablo Neira Ayuso commit 55dd20f0f4b1be5c9c8a0275d8d763c86563eac2 Author: Eric Biggers Date: Sat Aug 15 13:57:50 2026 -0700 netfilter: nft_set_pipapo_avx2: add missing vzeroupper Since pipapo_get_avx2() uses YMM registers, execute vzeroupper before returning from it. This is needed to avoid degrading the performance of any later SSE code that may happen to be executed. Fixes: 7400b063969b ("nft_set_pipapo: Introduce AVX2-based lookup implementation") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Reviewed-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso commit b1881d362e1924b66f6016c3efd28807032b41bf Author: Pablo Neira Ayuso Date: Thu Aug 13 02:16:02 2026 +0200 netfilter: nf_tables: move hardware offload step after building the chain blob Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ. Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support") Signed-off-by: Pablo Neira Ayuso commit 3b446d169a93e6abae9a93535369fa18bbcbefd9 Author: Rafael J. Wysocki Date: Thu Aug 27 15:59:32 2026 +0200 Revert "ACPI: scan: Defer device power initialization" Revert commit dc948f8b384a ("ACPI: scan: Defer device power initialization") that is incomplete and may cause ACPI power management of devices to fail. The problem is that PCI devices are associated with the corresponding ACPI device objects before acpi_bus_attach() runs for them, so after commit dc948f8b384a, ACPI power management will not be initialized for them before making that association. Consequently, the reference counting of ACPI power resources may not work as expected going forward and power management issues may appear. If they appear, they may be elusive and hard to diagnose. While this is fixable, I am not sure if fixing it on top of commit dc948f8b384a is the best way to go, so it is better to revert that commit for now and revisit the whole thing in the next cycle. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/6029658.DvuYhMxLoT@rafael.j.wysocki commit 81eb1867e059bf1dbbfbba536385a5cb26f700cd Merge: 2c4e7c42d77e78 0b13256ce37b66 Author: Paolo Abeni Date: Thu Aug 27 15:47:19 2026 +0200 Merge branch 'guard-against-gso_segs-overflows' Alice Mikityanska says: ==================== Guard against gso_segs overflows This series is a follow-up on the discussion: https://lore.kernel.org/netdev/CAD0BsJWzSr2zduf5v3mVC4zd=Lj6ZAoC+V42-VBdg42aDY8XXw@mail.gmail.com/T/#m1e22fca273c36cc8844e516505d3251cc1418fea skb_segment is patched to avoid possible overflows in partial GSO. The primary possible source of too many GSO segments is also addressed: virtio-net clamps gso_size to >=8 in TCP, as suggested by Eric. v2: https://lore.kernel.org/netdev/20260813174613.2920246-1-alice.kernel@fastmail.im/ v1: https://lore.kernel.org/netdev/20260723155145.158572-1-alice.kernel@fastmail.im/ ==================== Link: https://patch.msgid.link/20260822120117.1163423-1-alice.kernel@fastmail.im Signed-off-by: Paolo Abeni commit 0b13256ce37b66dbd0e4ce78d5bee32fd38db1a5 Author: Alice Mikityanska Date: Sat Aug 22 15:01:17 2026 +0300 net: Guard for gso_segs overflow in skb_segment skb_segment calculates 32-bit partial_segs as len / gso_size, and then assigns it to the 16-bit gso_segs field. The division might overflow in some edge cases where the SKB is BIG TCP (65536 <= len <= 8*65535), and gso_size < TCP_MIN_GSO_SIZE = 8. While normally this can't happen due to TCP_MIN_GSO_SIZE, an AF_PACKET PACKET_VNET_HDR socket could generate such a malformed packet until the previous patch. Blocking malformed virtio_net packets was implemented in the previous patch, but this patch clamps partial_segs in skb_segment itself for more generic robustness. Should len / gso_size happen to be bigger than 65535 in partial GSO, skb_segment will now just produce more than two output SKBs, all of which will be valid with gso_segs <= 65535. In order to catch possible other cases of too many partial_segs, add a DEBUG_NET_WARN_ON_ONCE when len / gso_size happens to be too big. Signed-off-by: Alice Mikityanska Link: https://patch.msgid.link/20260822120117.1163423-3-alice.kernel@fastmail.im Signed-off-by: Paolo Abeni commit c27c449d455aafd9018a3cbab150f1c42c87923f Author: Alice Mikityanska Date: Sat Aug 22 15:01:16 2026 +0300 virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649. Fixes: 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") Signed-off-by: Alice Mikityanska Suggested-by: Eric Dumazet Link: https://patch.msgid.link/20260822120117.1163423-2-alice.kernel@fastmail.im Signed-off-by: Paolo Abeni commit 5e977521d21717edb8e91d004434697d6e3f248c Author: Arvind Yadav Date: Thu Aug 20 12:24:45 2026 +0530 drm/xe: Reject page faults from non-fault-mode scratch VMs Having scratch enabled does not make a VM capable of handling recoverable page faults. Allowing scratch VMs through the ASID lookup also admits dma-fence mode VMs. If such a VM faults on an already valid VMA, the handler reports success without fixing the fault, causing the GPU to retry indefinitely. Only allow fault-mode VMs through the ASID lookup. Fault-mode VMs using scratch remain supported, while faults from 3D VMs are rejected. Fixes: ad9843aac91a ("drm/xe/madvise: Implement purgeable buffer object support") Cc: Matthew Brost Cc: Thomas Hellström Cc: Himal Prasad Ghimiray Suggested-by: Matthew Brost Signed-off-by: Arvind Yadav Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260820065445.567228-1-arvind.yadav@intel.com (cherry picked from commit bfb24a06405b652d37831f3fb66b71d33a6605de) Signed-off-by: Rodrigo Vivi commit 369ba0d1efe91cccabe98ae53c53b7425f327edf Author: Balasubramani Vivekanandan Date: Wed Aug 19 13:04:58 2026 +0530 drm/xe/xe_gt_idle: Add CCS to the powergating info print While reading the main GT powergating info from debugfs, include both RCS and CCS engine masks. Fixes: 0914c1e45d3a1 ("drm/xe/xe_gt_idle: add debugfs entry for powergating info") Signed-off-by: Balasubramani Vivekanandan Link: https://patch.msgid.link/20260819073457.1812722-2-balasubramani.vivekanandan@intel.com Reviewed-by: Matt Roper Signed-off-by: Matt Roper (cherry picked from commit 8899e413c5ab85443ec9bbc50cffe924c6b596de) Signed-off-by: Rodrigo Vivi commit f0feab6e9e008faa406d189fb40cb7ab1bed420a Author: Daniele Ceraolo Spurio Date: Tue Aug 18 21:35:20 2026 +0000 drm/xe: Do not apply WA 14025883347 to media 3503 The database was updated and the WA is no longer listed as applicable to media 3503, so don't enable it there. Fixes: c57db41b8d2c ("drm/xe/guc: Add Wa_14025883347 for GuC DMA failure on reset") Signed-off-by: Daniele Ceraolo Spurio Cc: Sk Anirban Cc: Badal Nilawar Cc: Matt Roper Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260818213520.283063-1-daniele.ceraolospurio@intel.com (cherry picked from commit fae59d5de5de39bc51ac2839f74970312e0c8905) Signed-off-by: Rodrigo Vivi commit ac727d86fb84bdc9626ba9c756c26767459f3083 Author: Baolin Liu Date: Thu Aug 27 14:43:17 2026 +0800 ntfs: leave HasEA flag untouched on setxattr failure In ntfs_set_ea(), the exit path unconditionally updates the HasEA flag based on ea_info_qsize. When an error occurs before ea_info_qsize is updated, NInoClearHasEA() hides existing on-disk EAs until the inode is evicted. Only update the flag on success. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Signed-off-by: Baolin Liu Signed-off-by: Namjae Jeon commit 67aded1da114dc44808315f249bd9e7e440f799d Author: Hongling Zeng Date: Thu Aug 27 13:58:44 2026 +0800 ntfs: fix race between fallocate and mmap reads The fallocate implementation only takes invalidate_lock for punch hole, collapse range, and insert range operations. For standard allocation modes (mode == 0, FALLOC_FL_KEEP_SIZE), the lock is not held. During ntfs_attr_fallocate(), new clusters are mapped to the runlist via ntfs_attr_map_cluster() before being zeroed by ntfs_dio_zero_range(). This creates a window where concurrent mmap page faults can read uninitialized disk data. Since mmap uses filemap_fault() which takes invalidate_lock in shared mode, it can fault in pages during this window and expose old disk contents to userspace. This is an information leak and data integrity issue. Fix by taking invalidate_lock for all fallocate operations, not just for punch/collapse/insert modes. This prevents concurrent page faults from accessing unzeroed clusters during the allocation window. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Cc: stable@vger.kernel.org Reviewed-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Hongling Zeng Signed-off-by: Namjae Jeon commit acb1095fd2db884b417cb70808c886e4b615ff05 Author: Hongling Zeng Date: Mon Aug 24 15:59:35 2026 +0800 ntfs: fix memmove overlap in ntfs_new_attr_flags When the record shrinks while the payload offsets increase (e.g., enabling compression reduces padding, making arec_size < old_arec_size, but the header grows by 8 bytes), moving the name first can overwrite the old mapping_pairs before they are copied. Move mapping_pairs first in this case. Since mp_ofs is derived from name_ofs, they always change in the same direction. Checking name_ofs alone is sufficient. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 6faa235a649e78a82e3230b849607f446ba65ed5 Author: Dennis Tighe Date: Sun Aug 23 00:13:25 2026 -0700 ntfs: compute bi_sector in 512-byte units bi_sector counts in 512 byte sectors and not in multiples of the volume's sector size. Under "normal" circumstances (with 512 byte sectors in NTFS) the current code works as is; however, when we have a 4k sector size on the volume the current usage of NTFS_B_TO_SECTOR() and ntfs_bytes_to_sector() end up converting to the number of 4k sectors after mount. Reads work today on 4k volumes as bdev-io.c as performing the shift correctly inline. With writes, we end up with significant silent disk corruption on these volumes. This fixes changes to use the new ntfs_bytes_to_bio_sector() function everywhere we're performing this calculation (including the existing read path). For the change in inode.c it removes a dead code block rather than updating. Fixes: 40796051991d ("ntfs: update in-memory, on-disk structures and headers") Assisted-by: Claude:claude-opus-5 Signed-off-by: Dennis Tighe Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 9b4ab1f3fed89d8c1e953dc069a0ddd705a73f09 Author: Fernando Fernandez Mancera Date: Mon Jun 1 21:30:49 2026 +0200 netfilter: conncount: use DEBUG_NET_WARN_ON_ONCE on reaching count limit Replace WARN_ON_ONCE with DEBUG_NET_WARN_ON_ONCE in __nf_conncount_add. The function handles count limit breaches safely by returning -EOVERFLOW, so a production backtrace is not needed. This prevents unnecessary system panics when panic_on_warn=1 is enabled in production systems. Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso commit 1f0391aea883e99d402d0f77ba3530e4e879350d Author: Fernando Fernandez Mancera Date: Mon Jun 1 21:30:46 2026 +0200 netfilter: tproxy: use DEBUG_NET_WARN_ON_ONCE for protocol fallbacks Replace WARN_ON calls with DEBUG_NET_WARN_ON_ONCE in the default switch blocks of nf_tproxy_get_sock_v4 and v6. Unsupported transport protocols are already safely handled by returning a NULL socket pointer. This prevents unnecessary system panics when panic_on_warn=1 is enabled in production systems. Link: https://patch.msgid.link/cover.1786968834.git.zhilinz@nebusec.ai/ Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso commit 2c4e7c42d77e78ad595dbb9e4b5886b58b45d89d Author: Aleksandr Khromov Date: Mon Aug 24 13:05:47 2026 +0300 slip: fix use-after-free in sl_sync() slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: /* Snapshot list, allow later requests */ list_replace_init(&net_todo_list, &list); __rtnl_unlock(); ... if (dev->priv_destructor) dev->priv_destructor(dev); /* slip_devs[i] = NULL */ if (dev->needs_free_netdev) free_netdev(dev); ... /* Free network device */ kobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 ("slip: Fix use-after-free Read in slip_open") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: they run under the same RTNL section, so the slot cannot have been reused in between. This also removes the second symptom of the missing exclusion: a destructor running after sl_alloc() had already handed the slot out to another channel used to clear a live entry, so sl_sync() stopped at that NULL, sl_alloc() returned the same index again, and register_netdevice() failed with -EEXIST because slN was still there. Reproduced on x86_64 with several threads looping over open("/dev/ptmx") + ioctl(TIOCSETD, N_SLIP) + close(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 5342b77c4123 ("slip: Clean up create and destroy") Cc: stable@vger.kernel.org Suggested-by: Jakub Kicinski Signed-off-by: Aleksandr Khromov Link: https://patch.msgid.link/20260824100547.164773-1-haa@amicon.ru Signed-off-by: Paolo Abeni commit 9a56a27e6002e29a6707dc4238d469ec84c3a68e Author: Maxime Chevallier Date: Tue Aug 25 23:17:46 2026 +0200 net: stmmac: selftests: Pass the IP proto mask in the TC selftest The stmmac TC filtering rules have recently gained sanity checks to make sure the passed keys and their respective masks are aligned with the HW filtering abilities. The stmmac selftests failed to pass the mask in the match data for L4 filtering tests, and are now failing consistently with -EINVAL : $ ethtool -t eth1 [...] 23. L4 DA TCP Filtering -22 24. L4 SA TCP Filtering -22 25. L4 DA UDP Filtering -22 26. L4 SA UDP Filtering -22 Let's pass the ip_proto mask in the l4 filtering tests match data. Found on imx8mp, which now have passing L4 tests : $ ethtool -t eth1 [...] 23. L4 DA TCP Filtering 0 24. L4 SA TCP Filtering 0 25. L4 DA UDP Filtering 0 26. L4 SA UDP Filtering 0 While at it, initialize the masks and keys to avoid re-using whatever was on the stack. Fixes: 5536d7c84363 ("net: stmmac: fix l3l4 filter rejecting unsupported offload requests") Reviewed-by: Andrew Lunn Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260825211748.360935-1-maxime.chevallier@bootlin.com Signed-off-by: Paolo Abeni commit 63c885688f38a757947d7050b1ee4171215269ce Author: Jiawen Wu Date: Mon Aug 24 15:21:19 2026 +0800 net: wangxun: use BIT_ULL() to prevent shift overflow on 32-bit archs The macros TXGBE_INTR_MISC() and WX_INTR_Q() rely on the standard BIT() macro to generate interrupt masks based on the queue vector index. On 32-bit architectures, BIT() evaluates to a 32-bit `unsigned long`. Since the number of queue vectors can be up to 63 on txgbe devices, performing a left shift of 32 or more results in an integer overflow and undefined behavior. This causes incorrect interrupt masking and unmasking logic for both the queue and miscellaneous interrupts on 32-bit systems. Fix this by replacing BIT() with BIT_ULL() in these macros. This ensures that the bitwise shift is always performed safely on a 64-bit `unsigned long long` type, regardless of the underlying architecture. Fixes: e37546ad1f9b ("net: wangxun: revert the adjustment of the IRQ vector sequence") Signed-off-by: Jiawen Wu Reviewed-by: Aleksandr Loktionov Link: https://patch.msgid.link/45F5565CE6AC4329+20260824072119.48399-1-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni commit ea30dc5267e367b8a5e1e06cc074f813bcbf18b2 Author: Qing Ming Date: Tue Aug 25 15:20:33 2026 +0800 tcp: fix AO info use-after-free in tcp_ao_connect_init() tcp_v4_connect() adds a SYN-SENT socket to the ehash before calling tcp_connect(). If TCP-AO is configured, tcp_connect() first verifies that a key matches the peer and the bound device's current L3 master. tcp_ao_connect_init() later resolves the L3 master again and removes keys which do not match it. The socket lock does not stabilize the bound device's VRF membership. Detaching the device from its VRF between the initial validation and the L3-master calculation in tcp_ao_connect_init() can therefore make the validation succeed while initialization observes the default L3 domain and removes the only key. The subsequent AO lookup then fails, so the no-key path clears tp->ao_info and frees it directly. The receive path can find the socket in the ehash and load tp->ao_info under RCU before acquiring the socket lock. A reader which loaded the old pointer can thus continue into tcp_inbound_ao_hash() after the direct free. The issue was found during a static audit of TCP-AO object lifetime. An unprivileged reproducer in self-created user and network namespaces raced connect() with detaching a veth from its VRF while sending TCP-AO segments. It triggered the same KASAN report on two fresh boots: BUG: KASAN: slab-use-after-free in tcp_inbound_ao_hash+0x585/0x19f0 Write of size 8 at addr ffff88800bf88128 by task tcp_ao_vrf_race/232 Call Trace: tcp_inbound_ao_hash+0x585/0x19f0 tcp_inbound_hash+0x677/0xa80 tcp_v4_rcv+0x1c3e/0x3ab0 Allocated by task 235: tcp_ao_alloc_info+0x43/0xf0 tcp_ao_add_cmd+0xdf7/0x13b0 do_tcp_setsockopt+0x168c/0x2640 Freed by task 235: kfree+0x1b8/0x550 tcp_connect+0x252/0x4f00 tcp_v4_connect+0x1114/0x1720 The bad address is 40 bytes inside the freed 128-byte object, matching the tcp_ao_info counters.key_not_found field. The two runs used 1000 attempts each, reached the no-key path 366 and 411 times, and produced one and two KASAN reports respectively. With this change, the same reproducer reached the no-key path 366 times in 1000 attempts without a KASAN report or oops. Use tcp_ao_destroy_sock() for the no-key path. It unpublishes the AO info, updates the socket memory and static-key accounting, and defers the free until after an RCU grace period. Also drop the WARN_ON_ONCE() and its stale comment. The VRF detach race makes the no-key state reachable during normal operation, so it is a handled condition rather than an impossible assertion. On panic_on_warn kernels the WARN would turn this handled race into a kernel panic. Fixes: 248411b8cb89 ("net/tcp: Wire up l3index to TCP-AO") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: Qing Ming Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260825072033.6921-1-a0yami@mailbox.org Signed-off-by: Paolo Abeni commit 687e5b48c4f59c4b323c93fbe77918c2c440fe4a Author: Rastislav Szabo Date: Sat Aug 22 22:11:19 2026 +0200 selftests: net: tcp_ao: test VRF-scoped key deletion Verify that TCP_AO_DEL_KEY can remove a TCP-AO key scoped to a VRF. Assisted-by: Codex:GPT-5 Signed-off-by: Rastislav Szabo Reviewed-by: David Ahern Acked-by: Dmitry Safonov Link: https://patch.msgid.link/20260822201119.272269-2-rastislav.szabo@isovalent.com Signed-off-by: Paolo Abeni commit 94ad9e114a1c7b16ea418c1456ac3835e038ab3f Author: Rastislav Szabo Date: Sat Aug 22 22:11:18 2026 +0200 net/tcp: fix TCP-AO key deletion in VRFs TCP-AO keys with TCP_AO_KEYF_IFINDEX store the VRF L3 interface index in l3index. tcp_ao_del_cmd() validates the supplied ifindex, but does not assign it to its local l3index before matching keys. As a result, deleting a key scoped to a non-default VRF always fails with ENOENT because it is matched against l3index 0. Fixes: 248411b8cb89 ("net/tcp: Wire up l3index to TCP-AO") Cc: stable@vger.kernel.org Signed-off-by: Rastislav Szabo Reviewed-by: David Ahern Acked-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20260822201119.272269-1-rastislav.szabo@isovalent.com Signed-off-by: Paolo Abeni commit 03b4702fc5e311cbac9ba8654021a88f0dac914c Author: Vitaliy Sochnev Date: Sun Aug 23 14:06:36 2026 +0100 net: phy: air_en8811h: move LED GPIO configuration to config_init The LED GPIO pins (GPIO3/4/5, mapped to LED2/LED1/LED0) are only ever configured as outputs once, in .probe(). But .config_init() restarts the MD32 MCU via en8811h_restart_mcu() on every call after the first (priv->mcu_needs_restart), and that restart resets buckpbus-mapped MCU state, including EN8811H_GPIO_OUTPUT. As a result the LED GPIOs fall back to inputs after the first event that re-triggers .config_init() (link renegotiation, ifdown/ifup, resume), and the PHY's LEDs stop reflecting link/activity state even though they worked right after probe. Move the GPIO-as-output configuration from .probe() to the end of .config_init(), so it is reapplied every time the MCU may have been restarted. Fixes: 71e79430117d ("net: phy: air_en8811h: Add the Airoha EN8811H PHY driver") Suggested-by: Mikhail Zhilkin Signed-off-by: Vitaliy Sochnev Link: https://patch.msgid.link/20260823130638.1166453-2-sochnev.v.74@gmail.com Signed-off-by: Paolo Abeni commit 00eeab0c644a881a1dc86fbffb7e6047a6ce8ecd Author: Joe Damato Date: Tue Aug 25 17:02:33 2026 -0700 bnxt_en: Write doorbell when linearizing skb fails When the driver is handed a burst of packets, the doorbell is deferred until the end. If the last packet has a huge number of frags, but fails to linearize, the doorbell will not be written adding latency on TX for any packets in the ring and holding their DMA mappings until the next TX. Note that the queue is not stopped, so this issue would delay pending BDs until the next TX. This issue was discovered by Sashiko and reading the code verifies that, while unlikely, it is possible. Fix this by jumping to tx_free, which replicates the same pre-existing logic but also writes the doorbell. Fixes: b91e82129400 ("bnxt_en: Linearize TX SKB if the fragments exceed the max") Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Reviewed-by: Michael Chan Reviewed-by: Andy Gospodarek Link: https://patch.msgid.link/20260826000234.2031564-1-joe@dama.to Signed-off-by: Paolo Abeni commit cec261b0b4c5c0b044165303198d10ffcdf3414c Author: Yifei Chu Date: Mon Aug 24 10:27:19 2026 +0800 net/smc: release the internal TCP sock on IPPROTO_SMC socket creation failure IPPROTO_SMC sockets create an internal TCP sock ("clcsock") from the proto->init hook. When socket creation fails after proto->init has run - e.g. a cgroup BPF program attached to BPF_CGROUP_INET_SOCK_CREATE denies the socket - sk_common_release() only invokes sk_prot->destroy if it is set, but neither smc_inet_prot nor smc_inet6_prot defines it, and smc_destruct() returns early unless sk_state is SMC_CLOSED. As a result, every failing socket(AF_INET, SOCK_STREAM, IPPROTO_SMC) call leaks one tcp_sock, so an unprivileged task able to attach a deny-all BPF_CGROUP_INET_SOCK_CREATE program to its own cgroup can grow kernel memory unboundedly. Add a .destroy hook to both protos that releases the clcsock via smc_clcsock_release(). smc_sk_init() hashes the sock into the smc hashinfo before the clcsock is created, and smc_diag dumps walk that hash dereferencing smc->clcsock without taking clcsock_release_lock, while sk_common_release() calls .destroy before .unhash. Unhash the sock before releasing the clcsock, as __smc_release() does, so a concurrent dump cannot observe the release; the second unhash in sk_common_release() is a no-op. Fixes: d25a92ccae6b ("net/smc: Introduce IPPROTO_SMC") Reported-by: Abaci Assisted-by: abaci:qwen3.8-max Signed-off-by: Yifei Chu Reviewed-by: Dust Li Link: https://patch.msgid.link/178753843966.342810.566471390946765094@linux.alibaba.com Signed-off-by: Paolo Abeni commit 82aeed2400786bd3f79d88cb8b8f42e6127e5923 Author: Breno Leitao Date: Tue Aug 25 03:50:10 2026 -0700 net: fix spurious TX timeout after dev_activate() While debugging another issue today, I found out that my TX queue is reported as stopped for 4294907392 ms (49.7 days), on a machine that had been up for four minutes. bnxt_en 0002:01:00.0 eth0: NETDEV WATCHDOG: CPU: 28: transmit queue 23 timed out 4294907392 ms 4294907392 is not an elapsed time. It is the value of jiffies at that moment: INITIAL_JIFFIES is 4294667296, which leaves jiffies 59 seconds short of wrapping. dev_activate() runs transition_one_qdisc() over every TX queue, which resets trans_start to 0, and then stamps only queue 0 through netif_trans_update(). Stamp jiffies instead. A queue stopped across dev_activate() now gets a full watchdog_timeo of grace, and is still reported if it is stopped that long. Fixes: 9b36627acecd ("net: remove dev->trans_start") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Reviewed-by: Nicolai Buchwitz Reviewed-by: Jason Xing Link: https://patch.msgid.link/20260825-trans_start-v2-1-286b4d6d70cb@debian.org Signed-off-by: Paolo Abeni commit 991c2be78257cba5bf53cf935fe70f8836964288 Author: bui duc phuc Date: Mon Aug 24 17:09:01 2026 +0700 net: ethernet: sun4i-emac: Fix IRQ error handling irq_of_parse_and_map() returns 0 when parsing or mapping an IRQ fails. The current code checks for -ENXIO and therefore does not detect the failure. Check for a zero return value and convert it to -ENXIO. Fixes: 492205050d77 ("net: Add EMAC ethernet driver found on Allwinner A10 SoC's") Signed-off-by: bui duc phuc Reviewed-by: Andre Przywara Link: https://patch.msgid.link/20260824100901.31675-1-phucduc.bui@gmail.com Signed-off-by: Paolo Abeni commit c966d29e01bbf829f8bb4a39a49811c56cdb49c3 Author: Daeho Jeong Date: Wed Aug 26 08:36:44 2026 -0700 f2fs: support resizable tail section and unify pinned allocation Currently, zoned block devices restrict pinned file allocations to conventional zones at the beginning of the storage (before first_seq_zone_segno), triggering range GC when conventional space is exhausted. On regular block devices, when preparing for future online filesystem resizing (e.g. partition shrinking), pinned files must not be allocated in the tail area that will be truncated, as pinned files cannot be relocated by GC. Specifying the resizable tail area size (in sections) allows uniform mount configuration across devices of different storage capacities. To support this, introduce a unified `pinned_area_max_secno` boundary abstraction in `f2fs_sb_info`: 1. Add `-o resizable_tail_secno=%u` mount option to specify the number of sections at the tail of the filesystem reserved for resizing. 2. In `f2fs_fill_super()`, initialize `sbi->pinned_area_max_secno` as: min(MAIN_SECS(sbi) - resizable_tail_sec, zoned_max_sec). 3. In `get_new_segment()`, restrict segment allocation for pinned files (`pinning == true`) to `0 .. sbi->pinned_area_max_secno - 1`. If no free section is available in the pinned area, return -EAGAIN. 4. In `f2fs_allocate_pinning_section()`, unify the range GC trigger to run `f2fs_gc_range()` up to `sbi->pinned_area_max_secno` whenever `sbi->pinned_area_max_secno < MAIN_SECS(sbi)` and allocation returns -EAGAIN. 5. Expose `/sys/fs/f2fs//pinned_area_max_secno` as a read-only sysfs node. Signed-off-by: Daeho Jeong Signed-off-by: Sunmin Jeong Reviewed-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim commit ce6dcd0aed185432d02cafc82b738318af257ccd Author: Eduard Zingerman Date: Wed Aug 26 11:18:45 2026 -0700 selftests/bpf: a demo for check_cond_jmp_op() non-null inference bug A comparison between PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED and PTR_TO_MAP_VALUE_OR_NULL should not infer that map pointer is not null. A bug in check_cond_jmp_op() made such inference possible. Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260826-bug-029-bad-non-null-inference-v2-2-136789ace9e9@localhost Signed-off-by: Alexei Starovoitov commit d3ef6c097ba078e1f8c7239d76a0ce8b61e75095 Author: Eduard Zingerman Date: Wed Aug 26 11:18:44 2026 -0700 bpf: check_cond_jmp_op(): properly infer if register is null 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 commit 2d2a3adc91950f9a18829dadc7317fb5180a15c5 Author: GuoHan Zhao Date: Fri Jul 17 14:11:45 2026 +0800 accel/ethosu: fix job completion fence cleanup ethosu_ioctl_submit_job() allocates done_fence before validating buffer handles. Errors after allocation call ethosu_job_err_cleanup(), which frees the job but leaks the uninitialized fence. A scheduler dependency error also lets ethosu_job_run() return before dma_fence_init(). Normal cleanup then passes a zeroed refcount to dma_fence_put(). Release done_fence in the common cleanup path and use dma_fence_was_initialized() to distinguish initialized fences from raw allocations. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Cc: stable@vger.kernel.org Reported-by: Sashiko Link: https://sashiko.dev/#/patchset/20260716065219.931088-1-zhaoguohan@kylinos.cn?part=1 Signed-off-by: GuoHan Zhao Link: https://patch.msgid.link/20260717061145.1478139-6-zhaoguohan@kylinos.cn [robh: also fix goto] Signed-off-by: Rob Herring (Arm) commit 5e6ff28676dd92a608eb00eeb8d1319ad34024dc Merge: 73e3f0710014fe be0cfab740e58b Author: Linus Torvalds Date: Wed Aug 26 16:47:40 2026 -0700 Merge tag 'hyperv-next-signed-20260826' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull hyperv updates from Wei Liu: - Decrypt netvsc buffer on contiguous direct-map addresses (Kameron Carr) - Drop WS2012/2012R2 & Win8/8.1 Hyper-V support (Michael Kelley) - Use more meaningful errnos for hypercall status code (Hardik Garg) - Fix lost interrupts on CPU hot-unplug for Hyper-V PCI/MSI (Naman Jain) - Reserve more MSHV vectors for Linux root partition (Wei Liu) * tag 'hyperv-next-signed-20260826' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: clocksource: hyper-v: Remove support for stimer interrupts in message mode scsi: storvsc: Remove support for storvsc protocol of old Hyper-V hosts hv_netvsc: Remove GPADL teardown special case for old Hyper-V hosts hv_sock: Remove check for old Hyper-V hosts Drivers: hv: Remove support for WS2012/2012R2 & Win8/8.1 version of Hyper-V hv_netvsc: Allocate send/receive buffers using vmbus_alloc_buffer() Drivers: hv: vmbus: Add vmbus_alloc_buffer()/vmbus_free_buffer() for CoCo VMs Drivers: hv: vmbus: add vmbus_establish_gpadl_caller_decrypted() Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition x86/hyperv: reserve more vectors PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip Drivers: hv: Use meaningful errnos for hypercall status codes commit 15596a87fcc6fa07a162858e5fd00ba31752096b Author: Shengyu Qu Date: Thu Aug 27 01:20:50 2026 +0800 ASoC: amd: acp-config: change quirks to cover all ASUS FA401EA variants Existing quirk doesn't cover all known existing FA401EA devices, so use "FA401EA" to cover all of them. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221310#c49 Fixes: 27d090f3ccd4 ("ASoC: amd: acp: add ACP70 DMI override for new ASUS TUF platforms") Signed-off-by: Shengyu Qu Link: https://patch.msgid.link/20260826172050.15686-1-wiagn@4d2.org Signed-off-by: Mark Brown commit 53676a5e28231186c9f56d87b7998b640699bc15 Author: Frank Sorenson Date: Sun Aug 23 18:26:46 2026 -0500 cifs: add revalidation on FSCTL failure in smb2_duplicate_extents() smb2_duplicate_extents() has no handling for FSCTL_DUPLICATE_EXTENTS_TO_FILE failure: when the FSCTL fails, local inode metadata may be stale from the pre-extension or from concurrent remote writes, but is never refreshed. Force revalidation on FSCTL failure and use i_size_read() for the pre-extension check. Fixes: cfc63fc8126a ("smb3: fix cached file size problems in duplicate extents (reflink)") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Signed-off-by: Paulo Alcantara commit 73e3f0710014fe6d4ed98cfc02292f6121db7558 Merge: b035a8be20ddfb ee5a386cfe60f3 Author: Linus Torvalds Date: Wed Aug 26 15:09:21 2026 -0700 Merge tag 'nfs-for-7.3-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs Pull NFS client updates from Trond Myklebust: "Highlights include: Stable fixes: - Use-after-free fixes for the sunrpc client code - Delegation hash table leak - NULL dereference on lockowner allocation failure - Fix a handshake completion race in the TLS code - Fix an error sign checking issue when deciding whether the pNFS layout is still in use, or can be returned - Fix a layout segment leak in pnfs_layout_process() Other bugfixes: - Fix a missing NULL check in the rpcbind client - annotate shared socket callbacks with READ_ONCE/WRITE_ONCE - nfs_inode_set_delegation() error paths should return the delegation - Use clear_and_wake_up_bit() in nfs_clear_invalid_mapping() and the pNFS code. - Fix the nfs4_alloc_client() error paths to free the IDR allocation - fix folio dereference before NULL check in nfs_inode_remove_request() - Fix delayed delegation return - Fix another state manager race with umount - Fix device leaks on parse failure - Avoid cancelling in-flight I/O during a layout recall if the server doesn't require it - flexfiles: report cancelled I/O as a layout error - flexfiles: fix NULL dereference for NFSv4.0 data servers - Fix incorrect argument passed to nfs4_delete_lease() - Fix several symlink issues resulting from nfs_atomic_open_v23() - Fix an uninitialised variable issue in the NFSv4.1 callback code - fix LAYOUTSTATS send buffer exhaustion Features and cleanups: - NFSv4.2: Allow the server to specify that file data may not be cached - localio: optimise I/O submission when when not doing memory reclaim - localio: Remove duplicate wait code in nfs_local_commit - flexfiles: support loosely coupled NFSv4.x data servers - pNFS: key the data server cache on the NFS version" * tag 'nfs-for-7.3-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: (33 commits) NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget path NFSv4/pnfs: key the data server cache on the NFS version NFSv4.2: fix LAYOUTSTATS send buffer exhaustion pNFS: Fix EBUSY check in pnfs_layout_need_return NFSv4.1: zero referring call lists before decoding nfs: fix ENXIO on O_CREAT open of existing symlink over NFSv3 SUNRPC: wait for in-flight client TLS handshake callback NFSv4: Fix incorrect argument passed to nfs4_delete_lease() in nfs4_add_lease() lockd: fix NULL dereference on lockowner allocation failure NFS: fix delegation_hash_table leak when nfs4_server_common_setup() fails NFSv4/flexfiles: support loosely coupled data servers NFSv4/flexfiles: fix NULL dereference for NFSv4.0 data servers NFSv4: pin the superblock for active state owners sunrpc: fix use-after-free in __rpc_clnt_handle_event and __rpc_clnt_remove_pipedir NFS/localio: issue commit inline when not in a memory-reclaim context NFS/localio: remove dead FLUSH_SYNC handling from nfs_local_commit NFS/localio: issue IO inline when not in a memory-reclaim context NFS: Fix delayed delegation return list handling NFS: Verify symlink inode before caching target NFS: fix folio dereference before NULL check in nfs_inode_remove_request() ... commit b035a8be20ddfb932205beb9a1cbd80ea42e6cfb Merge: b81e34131907d2 ab0304fd69b076 Author: Linus Torvalds Date: Wed Aug 26 14:47:22 2026 -0700 Merge tag 'trace-rv-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull runtime verification fix from Steven Rostedt: - Use .old instead of .bak for rvgen kunit backup files The rvgen kunit command generates .bak backup files and these are checked in for selftests as "golden" files for make check. But 'make distclean' removes such files, leaving the tree dirty. Switch to .old to preserve a clean tree after make disclean. * tag 'trace-rv-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: verification/rvgen: Use .old instead of .bak for kunit backup files commit b81e34131907d2c243c51117a4aff8dbe22ccc9c Merge: 85671b807f82da 79a57e48822a88 Author: Linus Torvalds Date: Wed Aug 26 14:21:30 2026 -0700 Merge tag 'thermal-7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more thermal control updates from Rafael Wysocki: "This mostly consists of assorted updates of thermal drivers, including new hardware support (Airoha AN7583, Qualcomm Master BandGap thermal monitor, QCom PMIC5 Gen3 ADC), but it also includes two reverts of recent cosmetic thermal core updates that went against driver core plans to eliminate class_create(): - Fix missing bitfield include headers in Armada and QCom SPM BMG drivers (Daniel Lezcano) - Fix missed file when manually applying a change after a conflict resolution for the QCom SPMI ADC TM5 Gen3 (Daniel Lezcano) - Move thermal_zone_device_enable() to the right place in order to prevent calling it if the thermal zone registration failed (Dan Carpenter) - Improve bitfield manipulations on Armada (Bryan B. Lima) - Remove unneeded 'fast_io' on Sun8i and Armada (Wolfram Sang) - Fix wrong boundary when clamping the low values in the set_trips() callback and fix wrong mask when setting the temperature interval on Airoha (Christian Marangi) - Make use of the regmap API to support Airoha AN7583 (Christian Marangi) - Fix adc_tm5_get_temp() return check value on the QCom SPMI ADC sensor (Rakesh Kota) - Fix unbalanced clock enablement when the resume fails on the iMX driver (Can Peng) - Add Qualcomm Master BandGap thermal monitor support (Satya Priya Kakitapalli) - Add Maili Temperature bindings compatible (Haritha S K) - Add a devm action to clean hardware interrupts, sampling, and control registers on Spacemit K1 (Pei Xiao) - Fix trivial typo in a thermal OF code comment (Marek Vasut) - Remove unnecessary print on Qcom SPMI ADC driver when a call to devm_request_threaded_irq() fails as this one already prints a message (Jishnu Prakash) - Add support for QCom PMIC5 Gen3 ADC by using auxiliary driver and shared interrupt with the IIO driver (Jishnu Prakash) - Make resets optional on MT8196 and add the corresponding property in the DT bindings (AngeloGioacchino Del Regno) - Fix clock staying enabled on failing resume operation on Qoriq (Can Peng) - Fix wrong closing brace position in thermal library header (Andreas Haufler) - Fix low and high trip point validation by moving the check after the clamp on the spacemit driver (surendra) - Remove redundant error messages on IRQ request failure (Pan Chuang) - Add IIO_CONSUMER namespace import to the qcom-spmi-mbg-tm thermal driver to avoid modpost warnings that would appear after merging the iio tree against the thermal updates (Nathan Chancellor) - Revert two recent cosmetic updates of the thermal core conflicting with driver core plans to eliminate class_create() (Rafael Wysocki)" * tag 'thermal-7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (32 commits) thermal/drivers/qcom-spmi-mbg-tm: Add module namespace import for IIO_CONSUMER Revert "thermal/core: Allocate the thermal class dynamically" Revert "thermal/core: Use the thermal class pointer as init guard" thermal/drivers/armada: Fix missing bitfields include thermal/drivers/qcom/spm mbg tm: Fix missing bitfield header thermal/drivers/qcom: Fix missing spmi adc tm5 gen3 file thermal/drivers: Remove redundant error messages on IRQ request failure thermal/drivers/spacemit: Validate clamped trip thresholds tools/lib/thermal: Fix misplaced extern "C" closing brace thermal/drivers/qoriq: Disable clock on resume failure thermal/drivers/mediatek/lvts_thermal: Make reset optional for MT8196 dt-bindings: thermal: mediatek: Make resets optional for MT8196 thermal/drivers/qcom: add support for PMIC5 Gen3 ADC thermal monitoring iio: adc: qcom-spmi-adc5-gen3: Share SDAM0 IRQ with ADC_TM auxiliary driver iio: adc: qcom-spmi-adc5-gen3: Remove an unnecessary print thermal/of: Fix trivial enabled typo thermal/drivers/spacemit/k1: Add shutdown action and reorder registration order dt-bindings: thermal: qcom-tsens: Document the Maili Temperature Sensor thermal/drivers/qcom: Add support for Qualcomm MBG thermal monitoring dt-bindings: thermal: Add Qualcomm MBG thermal monitor support ... commit 85671b807f82dae7a88ccfc74e33a8374219841c Merge: 3382bfbca58c7d 76854b339b3fbb Author: Linus Torvalds Date: Wed Aug 26 14:13:26 2026 -0700 Merge tag 'pm-7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more power management updates from Rafael Wysocki: "These fix two issues in the intel_rapl power capping driver, fix a potential issue in the schedutil cpufreq governor on 32-bit systems, fix a runtime PM issue related to failing system suspend, and update the intel_pstate cpufreq driver: - Fix a kernel panic during PMU unbind in the intel_rapl power capping driver and sign-extend the PMU delta on counter wraparound in it to avoid misreporting energy (Sumeet Pawnikar and Yifan Li) - Unblock runtime PM when device prepare fails that was not done by mistake (Shibo Zhu) - Fix possible rate limit overflow on 32-bit systems in the schedutil cpufreq governor (Hui Su) - Consolidate HWP P-states initialization in the intel_pstate cpufreq driver and make that driver avoid using the DESIRED_PERF HWP hint when the Dynamic Efficiency Control (DEC) is enabled in the processor to avoid inconsistent behavior (Rafael Wysocki)" * tag 'pm-7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: powercap: intel_rapl: Fix kernel panic during PMU unbind PM: sleep: Unblock runtime PM when device prepare fails powercap: intel_rapl: Sign-extend the PMU delta on counter wraparound cpufreq: intel_pstate: Avoid using DESIRED_PERF when DEC is enabled cpufreq: intel_pstate: Consolidate HWP P-states initialization cpufreq: schedutil: Fix rate limit overflow commit 3382bfbca58c7d5ee3f31a7b37fbeb208e98e656 Merge: 502d45774af09f ea10c0b334e0dc Author: Linus Torvalds Date: Wed Aug 26 14:06:08 2026 -0700 Merge tag 'acpi-7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more ACPI support updates from Rafael Wysocki: "These update documentation to reflect recent changes in the upstream ACPICA project, fix issues in the core ACPI device enumeration code (one of which has been introduced recently), improve the primary "physical" device lookup for ACPI device objects in that code, and update ACPI device drivers: - Update MAINTAINERS, CREDITS and ACPI subsystem documentation to reflect recent changes in the upstream ACPICA project (Rafael Wysocki) - Prevent the core ACPI enumeration code from combining device resources that overlap completely in order to avoid resource conflicts during platform device registration because there are drivers that expect such resources to be present (Rafael Wysocki) - Defer device power initialization during ACPI-based device enumeration to the point when the given device is known to be present and functional and all of its dependencies have been met (Peixin Xie) - Fix bus ID cleanup on device_add() failures during ACPI device object registration (Hongyan Xu) - Introduce a new helper function for looking up the primary "physical" device for a given ACPI device object and update the core ACPI device enumeration code to use that function (Rafael Wysocki) - Protect all battery properties with a separated mutex in the ACPI battery driver to prevent race conditions from occurring and avoid evaluating the _BST ACPI control method multiple times in parallel for the same battery device (Rong Zhang) - Add DMI quirk for the Razer Blade Pro 17 early 2020 lid switch to the ACPI button driver (Robin Everaars) - Convert fixed clock rates in the ACPI driver for AMD SoCs (APD) to use HZ_PER_MHZ and add a clock frequency for the HJMC01 I2C controller to it (Hongnan Li and Xiangyang Yu) - Fix a stack buffer overflow in query_capability() in the ACPI platform firmware runtime update driver (Anirudh Prasad)" * tag 'acpi-7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: button: Add DMI quirk for Razer Blade Pro 17 early 2020 lid switch ACPI: scan: Do not combine resources that overlap completely ACPI: Update upstream ACPICA repository URL in documentation ACPI: Update MAINTAINERS entry for ACPICA ACPI: Add Bob Moore to CREDITS ACPI: pfr_update: fix stack buffer overflow in query_capability() ACPI: scan: Defer device power initialization ACPI: APD: Add clock frequency for HJMC01 I2C controller ACPI: APD: Convert fixed clock rates to use HZ_PER_MHZ ACPI: scan: Use acpi_bus_get_primary_device() ACPI: platform: Use acpi_bus_get_primary_device() ACPI: bus: Introduce acpi_bus_get_primary_device() ACPI: scan: fix bus ID cleanup on device_add() failures ACPI: battery: Protect all properties with a separated mutex commit 6727b7618f49401acf373fa3ec5712e2ec52e5cf Author: Haotian Zhang Date: Wed Aug 26 09:50:50 2026 +0800 samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-modify ftrace_direct_multi_init() assigns kthread_run()'s return value to simple_tsk without an IS_ERR() check. When kthread_run() fails it returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads with simple_tsk holding an error pointer. On unload, ftrace_direct_multi_exit() then passes that ERR_PTR to kthread_stop(), leading to a null-pointer-dereference. Check the return value of kthread_run() with IS_ERR(); on failure, unregister the ftrace direct call and propagate the error code. Link: https://patch.msgid.link/20260826015050.10772-1-vulab@iscas.ac.cn Fixes: e1067a07cfbc ("ftrace/samples: Add module to test multi direct modify interface") Suggested-by: Steven Rostedt Signed-off-by: Haotian Zhang Signed-off-by: Steven Rostedt commit d79fb758e7e2e7a181eab630c0545a56041c473d Author: Haotian Zhang Date: Wed Aug 26 09:50:34 2026 +0800 samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-modify ftrace_direct_init() assigns kthread_run()'s return value to simple_tsk without an IS_ERR() check. When kthread_run() fails it returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads with simple_tsk holding an error pointer. On unload, ftrace_direct_exit() then passes that ERR_PTR to kthread_stop(), leading to a null-pointer-dereference. Check the return value of kthread_run() with IS_ERR(); on failure, unregister the ftrace direct call and propagate the error code. Link: https://patch.msgid.link/20260826015034.10755-1-vulab@iscas.ac.cn Fixes: ae0cc3b7e7f5 ("ftrace/samples: Add a sample module that implements modify_ftrace_direct()") Suggested-by: Steven Rostedt Signed-off-by: Haotian Zhang Signed-off-by: Steven Rostedt commit 502d45774af09f1c681c754c4b7cdfb5d7f72fd9 Merge: 8fefe68784ae16 dd8eb789f18c4c Author: Linus Torvalds Date: Wed Aug 26 11:14:30 2026 -0700 Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk updates from Stephen Boyd: "Mostly the usual clk driver updates and new SoC additions plus non-critical data fixes for things that weren't used yet. One thing that's new here in the core is SSC spread spectrum support (SSC) in the clk provider API. The idea is that DT authors will configure SSC for certain clks and they'll be configured at clk provider registration time or when a consumer device is probed, similar to how we handle assigned clk rates or parents. On the clk driver side we have Qualcomm adding almost half the diff because they add support for 4 different SoCs and then a long tail of other SoCs like Mediatek, Renesas, Rockchip, SpaceMiT, etc. add more SoC support this time around. Luckily it's mostly clk data for these new SoCs because the actual clk_ops are already there. Beyond the new drivers we get all the little fixups for more compilation coverage or usage of more modern APIs. That all looks normal. Finally, I kinda buried the lede, I'm bringing on Brian and Jerome to help out with maintaining the clk subsystem. The current working model is already semi-distributed in that silicon vendors typically take care of their drivers and send me pull requests but I'm becoming a bottleneck for new drivers and core framework review because this has become a 100% volunteer effort on my part. Mike is stepping down after all these years (thanks Mike!) and that jump started the conversation around finding co-maintainers. Brian and Jerome have graciously offered to help me with the work load, meaning in the future they'll be sending pull requests and committing directly to the clk.git tree. They've both been around on the list for a while, I've met them both in person, and they've been making changes to the core clk framework along with helping review patches so I'm pretty confident this will work well. Core: - devm_clk_bulk_get_enable() consumer API - devm_clk_hw_register_composite_pdata() provider API - Spread Spectrum Clock (SSC) support via DT bindings and provider APIs - Divider clk rounding improved (and tested) New Drivers: - Cix Sky1 audio subsystem (AUDSS) - UltraRISC DP1000 - MediaTek MT8173 MFG_TOP - Si549 - Aspeed AST2700 PECI - Airoha EN7523 PCIe - Rockchip RV1106 - Mobileye EyeQ7H - Qualcomm Maili GCC, TCSR, RPMh, and video clks - Qualcomm Shikra GCC, RPM, GPU, display, and audio clks - Qualcomm Nord display and graphics clks - Qualcomm Glymur camera and EVA clks - Qualcomm Hawi video clks - Amlogic A9 AO and peripheral clks - Renesas R-Car X5H (R8A78000) CPG" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (269 commits) clk: microchip: mpfs: fix regmap_update_bits() mask/val order clk: visconti: Make sure clk_init_data is fully initialized clk: ti: Make sure clk_init_data is fully initialized MAINTAINERS: Add Brian Masney and Jerome Brunet as co-maintainers for clk subsystem Drop Michael Turquette's clk maintainer entry clk: ti: composite: resolve parent clocks by DT index, not by name clk: ti: mux: resolve parent clocks by DT index, not by name clk: devres: fix cleanup in devm_clk_get_optional_enabled_with_rate() dt-bindings: clock: ti,keystone-gate: Convert to DT schema dt-bindings: clock: ti: Convert APLL clock to DT schema clk: zynq: pll: Fix kernel-doc after determine_rate() conversion dt-bindings: clock: ti,clockdomain: Convert to DT schema dt-bindings: clock: Correct white-space style clk: samsung: Don't include clk: at91: Read "reg" with helper clk: renesas: Add R-Car X5H CPG driver clk: rockchip: rk3576: fix source muxes for SPI0..SPI4 clk: rockchip: Add clock controller for the RV1106 dt-bindings: clock: rockchip: Add RV1106 CRU support dt-bindings: clock: Document Renesas R-Car X5H Clock Pulse Generator ... commit 8fefe68784ae1606e11a5c65c04167c3b95051a0 Merge: 2bdcd6cf2ac418 3daad923a8685a Author: Linus Torvalds Date: Wed Aug 26 11:04:24 2026 -0700 Merge tag 'apparmor-pr-2026-08-26' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor Pull AppArmor updates from John Johansen: "The biggest functional change is Jann Horn's fix for how aparmor is doing stale cred updates after a policy replacement. apparmor: fix cred UAF caused by begin_current_label_crit_section() It moves the update to be done during task_work at the end of the syscall. One major feature is allowing policy to be compressed in userspace instead of after the fact (in kernel) if we need to hold onto it for CRIU/introspection. The other major change is to do with network mediation. It is a lot of code churn but does not do any functional changes to mediation. It moves the code around, and refactors it to use newer patterns for consistency, and in preparation for some improvements in mediation in a future patchset. Features: - support loading compressed policies - add audit mode to provide a mechanism to silence complain messages - refactor network mediation to use new patterns, and prepare to for extended inet mediation (no functional change) Cleanups: - switch website link to https - make include headers self-contained, and fix circular include - constify aa_label, aa_dfa, aa_profile, and aa_perms paraneters - mark static tables and structs as read only - drop use of _confined variant for iteration - refactory mount to use check_perms - refactor network mediation code to be together - refactor xattr attachment, to take the file path - optimize current_label_crit_section() - leverage audit_log_n_untrustedstring() when possible Bug Fixes: - initialized policy lists heads before fail path - fix deadlock in complain-mode change_hat - auditing of mount binary data - fix error debug output in fn_label_build - fix race condition in label replacement - fix unconfined user namespace restriction forced stack - fix error handling for copy_from_user in policy_update - fix out-of-bounds write when null terminating a label vec - fix integer overflow in verify_tags() bounds check - fix cred UAF caused by begin_current_label_crit_section() - use SEND_SIG_NOINFO instead of NULL in aa_audit()" * tag 'apparmor-pr-2026-08-26' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor: (40 commits) apparmor: policy_int make sure list heads are initialized before fail path apparmor: fix deadlock in complain-mode change_hat apparmor: constify aa_label parameters on read-only query helpers apparmor: constify aa_dfa parameters on read-only compute paths apparmor: constify aa_profile parameters on read-only compute paths apparmor: constify aa_perms parameters that are read-only apparmor: drop use of _confined variant for iteration apparmor: refactory mount to use check_perms apparmor: fix auditing of mount binary data apparmor: add audit mode to provide a mechanism to silence complain messages apparmor: mark static tables and structs as read only apparmor: fix error debug output in fn_label_build apparmor: make table entry count last enum for static tables apparmor: fix race condition in label replacement apparmor: refactor xattr attachment, to take the file path apparmor: fix unconfined user namespace restriction forced stack apparmor: reserve mediation class for packet mediation apparmor: move sock_rcv_skb() next to inet_conn_request apparmor: move netfilter functions next to the LSM network operations apparmor: refactor network socket mediation to support compatibility ... commit 8fdf946445732c2bcd685abc8bd0e509d2ebc158 Author: Max Kellermann Date: Tue Aug 18 20:40:05 2026 +0200 ceph: force a cap message when a deferred revoke can't be acked immediately When the MDS revokes capabilities, handle_cap_grant() normally guarantees a response by setting `CHECK_CAPS_FLUSH_FORCE` (see commit 31634d7597d8 ("ceph: force sending a cap update msg back to MDS for revoke op")), so ceph_check_caps() sends a cap message even if the client would otherwise decide it has nothing to do. That guarantee is skipped whenever the revoke has to be deferred (via revoke_wait): revoking Fb while dirty data is still buffered (writeback is queued first) or revoking Fc while pages are cached (async invalidation is queued first). In those cases, the ack is left to the deferred completion (ceph_put_wrbuffer_cap_refs() after writeback, or the invalidate worker after invalidation); both of which call ceph_check_caps(ci,0) i.e. without `CHECK_CAPS_FLUSH_FORCE`. Nothing gets sent under one of the following conditions: - the inode is retaining caps because the file was used recently (file_wanted != 0; retain |= CEPH_CAP_ANY) - the revoked cap is still used because the page was re-cached (e.g. a file being re-read) - the MDS has meanwhile re-granted, so `issued==implemented` and the client sees nothing being revoked The client then never emits the cap message which the MDS is waiting for. The MDS blocks on the revoke indefinitely and logs, for minutes or hours: client.NNN isn't responding to mclientcaps(revoke), ino 0x... pending pAsxLsXsxFsxcrwb issued pAsxLsXsxFsxcrwb, sent 964.899182 seconds ago The client-side state at that point shows the full cap set still issued, nothing in the revoking/flushing sets. Thus nothing gets sent. This patch fixes it by remembering that a forced response is expected. When a revoke is deferred, set `CEPH_I_FLUSH_FORCE` on the inode. ceph_check_caps() replays it as `CHECK_CAPS_FLUSH_FORCE`, so whichever path re-checks the inode next (the writeback/invalidate completion, the delayed worker, or any other caller) is guaranteed to send a cap message to the MDS. __prep_cap() clears the flag once a message is actually built. This is the deferred-path counterpart of the existing `CHECK_CAPS_FLUSH_FORCE` handling; a normal (non-deferred) revoke still forces the response inline as before. Cc: stable@vger.kernel.org Fixes: 31634d7597d8 ("ceph: force sending a cap update msg back to MDS for revoke op") Fixes: 257e6172ab36 ("ceph: don't let check_caps skip sending responses for revoke msgs") Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit 3cde4a8302301679937474a5f7a851394cc1bd11 Author: Jérémy Jean Date: Sat Aug 15 21:46:37 2026 +0000 libceph: reject buckets with mismatched CRUSH ids crush_decode() stores bucket data by array slot, and the mapper later derives the per-bucket workspace index from the decoded bucket id. A malformed map can therefore make one bucket reuse another bucket's workspace by encoding an id different from -1 - slot. For uniform buckets, the second replica selection expands the source bucket's permutation into that aliased workspace buffer. If the source bucket is larger than the aliased bucket, the write runs past the smaller permutation array and can escape the kvmalloc'd CRUSH workspace. KASAN reports a slab OOB write of 4 bytes in bucket_perm_choose(). Reject buckets whose encoded id does not match their array slot. Valid CRUSH maps already use the canonical negative id corresponding to the bucket slot, so this restores the invariant expected by work->work[-1 - in->id] without changing valid map behavior. Cc: stable@vger.kernel.org Fixes: 66a0e2d579db ("crush: remove mutable part of CRUSH map") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit aedc9053d909508a5f56c3f49f885fc030df4730 Author: Jérémy Jean Date: Thu Aug 13 14:00:00 2026 +0200 ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode MDSMap export_targets entries are monitor controlled. check_new_map() uses each entry as a bit number in a fixed stack bitmap, so a rank outside the protocol namespace can make set_bit() write past the end of the array. Reject ranks outside CEPH_MAX_MDS while decoding the map. Do not validate against possible_max_rank here because maps may legitimately reference ranks beyond a temporarily reduced max_mds. Cc: stable@vger.kernel.org Fixes: d517b3983dd3 ("ceph: reconnect to the export targets on new mdsmaps") Signed-off-by: Jérémy Jean Reviewed-by: Alex Markuze Signed-off-by: Alex Markuze Signed-off-by: Ilya Dryomov commit c25aee9c630fb86f98d79eccb75765067079b972 Author: Matthew Brown Date: Wed Aug 12 18:13:21 2026 +0100 ceph: fix leaked inode reference on writeback abort at umount ceph_dirty_folio() takes a wrbuffer claim on each newly dirtied folio: it bumps i_wrbuffer_ref (taking an ihold() on the 0->1 transition) and attaches the snap_context to folio->private. That claim is released only by ceph_put_wrbuffer_cap_refs(), which for a submitted write runs from writepages_finish(). In ceph_submit_write(), if ceph_inc_osd_stopping_blocker() fails -- which happens during umount -- the request is aborted before submission: the already-collected folios are only redirtied and unlocked, so writepages_finish() never runs and the claim is leaked. redirty_page_for_writepage() -> folio_redirty_for_writepage() -> filemap_dirty_folio() sets PG_dirty directly and does not go through ->dirty_folio, so ceph_dirty_folio() is not re-entered to rebalance it. Because every subsequent writeback also fails the osd_stopping_blocker, i_wrbuffer_ref never returns to 0, the ihold() is never dropped, and the inode cannot be evicted: VFS: Busy inodes after unmount of ceph kernel BUG at fs/super.c:650! Release the orphaned claim in the abort path before redirtying, via ceph_undo_wrbuffer_claim(): detach the snap_context, drop the wrbuffer reference (letting i_wrbuffer_ref reach 0 and iput() the inode), and drop the snap_context reference -- i.e. do what writepages_finish() would have done for these never-submitted folios. Only the locked_pages entries are undone; folios still in the fbatch were never dirty-cleared by this call (folio_clear_dirty_for_io() is the ownership-transfer point, and a successful move NULLs the fbatch slot), so they hold no claim this call owns. Cc: stable@vger.kernel.org Fixes: fd7449d937e7 ("ceph: fix generic/421 test failure") Signed-off-by: Matthew Brown Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov commit 2a2f98e17e1d322a94027daf0c6df88af2f9af50 Author: Tal Zussman Date: Mon Aug 17 15:29:17 2026 -0400 libceph: remove ceph_put_page_vector() ceph_put_page_vector() was paired with ceph_get_direct_page_vector(), which was removed in commit 97a385e55829 ("libceph: remove ceph_get_direct_page_vector()"). Its only remaining caller, finish_netfs_read(), uses it to put a page vector allocated with iov_iter_get_pages_alloc2(), which is confusing. Open-code the put_page() loop and kvfree() there instead. The caller passed dirty = false, so this also removes the dead dirty branch and with it a call to the deprecated set_page_dirty_lock(). Signed-off-by: Tal Zussman Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov commit f374967fcdf04001c9b66df1c19106fa83cd91f7 Author: Aleksandr Nogikh Date: Fri Jul 31 10:14:50 2026 +0000 libceph: validate banner payload length When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error. Fixes: cd1a677cad99 ("libceph, ceph: implement msgr2.1 protocol (crc and secure modes)") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+87c7c2d63c44e41c77a3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=87c7c2d63c44e41c77a3 Link: https://syzkaller.appspot.com/ai_job?id=c8ca3d63-717a-4933-89ec-f3d761b8690d Signed-off-by: Aleksandr Nogikh Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit 5f074d7f2938d7461facbbd073b9394b1496e73e Author: Alex Markuze Date: Mon Jul 6 13:11:27 2026 +0000 ceph: make nearfull sync writes opt-in The kernel CephFS client has historically treated a cluster or pool NEARFULL condition as a request to force successful writes through generic_write_sync(). That effectively turns otherwise buffered writes into synchronous writes and can cause a severe throughput drop as soon as a single OSD or the file data pool crosses the nearfull threshold. On modern large clusters, NEARFULL is primarily an operator health signal rather than an immediate client-side capacity failure. Operators can still have substantial usable capacity while a cluster is rebalancing, splitting PGs, or expanding onto new devices. RBD, RGW and the userspace CephFS client do not impose this extra client-side sync-write throttle, so the kernel client behavior is surprising and operationally painful. Change the default behavior so NEARFULL no longer changes normal write-sync semantics. FULL and pool FULL still fail with -ENOSPC, and explicitly synchronous writes continue to be synced by generic_write_sync(). Add a nearfull_sync mount option for deployments that want the legacy backpressure behavior. When this option is set, successful writes are promoted to IOCB_DSYNC if the cluster or file data pool is marked NEARFULL, preserving the old behavior for conservative deployments. Link: https://tracker.ceph.com/issues/74849 Signed-off-by: Alex Markuze Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov commit e7d7aa7b730178278109c41fa1b17b06873065d5 Author: Max Kellermann Date: Tue Jul 7 23:42:28 2026 +0200 ceph: do not repeat ceph_trim_dentries() if no progress possible ceph_cap_reclaim_work() re-queues itself for as long as ceph_trim_dentries() returns -EAGAIN, which happens whenever a lease walk exhausts its `nr_to_scan` budget. This creates a busy loop that consumes CPU without making any progress when there is nothing to reclaim: with no cap pressure (`count==0`) and every scanned lease still valid, each pass runs the full scan budget down to zero and returns `-EAGAIN`, only to be queued again immediately. The dir-lease walk made this worse. When `expire_dir_lease` is `false` (i.e. we have no intention of reclaiming dir leases), __dir_lease_check() returned `TOUCH` for every valid lease. `TOUCH` moves the dentry to the tail of the list and resets `di->time` via __dentry_dir_lease_touch(), so a walk over N valid leases pointlessly rewrote the list, refreshed the timestamps (preventing them from ever aging out) and always drained `nr_to_scan`, guaranteeing the `-EAGAIN` requeue. Fix this in three steps: - Return `KEEP` instead of `TOUCH` when `expire_dir_lease` is `false`. If we are not going to reclaim the lease, leave it in place instead of churning the list and resetting its timestamp; the walk then terminates naturally (or via `STOP` at the first fresh lease). - Only return `-EAGAIN` from the first (dentry-lease) walk when something was actually freed. A full batch that frees nothing means retrying the same list immediately is futile; fall through to the dir-lease walk instead. - After both walks, bail out with success (0) when nothing was freed and there is no cap pressure (`count==0`). There is no reason to keep retrying when we are not over the cap limit and made no progress. Under real cap pressure (`count>0`) the reclaim path is unchanged and still retries via `-EAGAIN`. Without this patch, I saw 500 ceph_trim_dentries() calls per second on our web servers. This is very visible in `/proc/lock_stat` (5 minute capture): class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &mdsc->dentry_list_lock: 126180 128218 0.04 8063.44 15986965.20 124.69 1573354 5296812 0.04 8291.28 74164526.48 14.00 ----------------------- &mdsc->dentry_list_lock 111736 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2631 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 3878 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8 &mdsc->dentry_list_lock 9973 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 ----------------------- &mdsc->dentry_list_lock 123621 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 1822 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2720 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 &mdsc->dentry_list_lock 55 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8 With this patch: class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &mdsc->dentry_list_lock: 1203 1215 0.16 408.88 33082.88 27.23 4320501 7357389 0.04 500.64 1961578.00 0.27 ----------------------- &mdsc->dentry_list_lock 1029 [<000000003c9aea8a>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 169 [<000000002038c577>] __dentry_lease_unlist+0x50/0xa0 &mdsc->dentry_list_lock 16 [<00000000c991106d>] __ceph_dentry_lease_touch+0x5c/0xa8 &mdsc->dentry_list_lock 1 [<00000000612fe15f>] __dentry_leases_walk+0x64/0x2c8 ----------------------- &mdsc->dentry_list_lock 158 [<000000002038c577>] __dentry_lease_unlist+0x50/0xa0 &mdsc->dentry_list_lock 858 [<000000003c9aea8a>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 182 [<00000000612fe15f>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 17 [<00000000c991106d>] __ceph_dentry_lease_touch+0x5c/0xa8 __dentry_leases_walk() is almost gone. The total wait time is reduced by a factor of 483. That will give some latency gains to ceph_readdir(). Cc: stable@vger.kernel.org Fixes: 37c4efc1ddf9 ("ceph: periodically trim stale dentries") Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit 1319b97dfe9eaa0e15132af95efe6513718f9123 Author: Max Kellermann Date: Wed Jul 8 22:40:22 2026 +0200 ceph: drop mdsc->mutex before decoding the MDS reply handle_reply() held `mdsc->mutex` across parse_reply_info(), i.e. across the full decode of the reply message. For large replies (a big readdir allocates and parses many dir_entries), this can take a while and blocks ceph_mdsc_submit_request() calls meanwhile. The decode does not need `mdsc->mutex`: parse_reply_info() mostly fills the request's `r_reply_info`. Create replies may also add delegated inode numbers to the session xarray, but that xarray is protected by its own lock and is not serialized by `mdsc->mutex` today. By the time we reach parse_reply_info(), all `mdsc->mutex`-protected state has already been updated under the lock (the request has either been unregistered (safe reply) or added to the session's unsafe list (unsafe reply)) and the request is pinned by the reference taken in lookup_get_request(). Drop `mdsc->mutex` before calling parse_reply_info() so reply decoding no longer blocks request submission. This only widens the existing unlocked window that already covers the heavier ceph_fill_trace() / ceph_readdir_prepopulate() processing, so no new races are introduced. Signed-off-by: Max Kellermann Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov commit ee611a7509554c4ca1f54f6aefe592fb1df7ea70 Author: Xiubo Li Date: Tue Jul 14 16:13:44 2026 +0800 ceph: fix UAF in check_new_map() on session freed during unlock 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 commit 7af4c4f01305b0935adf6d4301b1ec407025485d Author: Xiubo Li Date: Tue Jul 14 16:13:43 2026 +0800 ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory. The race timeline: __kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration. Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again. Cc: stable@vger.kernel.org Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov commit 0cb176595797466da1792aaff1124b74d9df6e81 Author: Max Kellermann Date: Mon Jul 6 09:38:12 2026 +0200 ceph: pass inode pointer around instead of reloading it All these functions already have a ceph_inode_info pointer, so let's use that instead of letting every function reload it from RAM (i.e. `ceph_cap.ci`). This eliminates several memory accesses. Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit af05588c9700de133aad9f8ba623ad0469e174fe Author: Max Kellermann Date: Mon Jul 6 09:38:11 2026 +0200 ceph: mark cap remove with RB_CLEAR_NODE() instead of setting ci=NULL __ceph_remove_cap() erases the ceph_cap object from the RB tree, thus it seems natural to use RB_CLEAR_NODE() / RB_EMPTY_NODE() for the removal check. Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit 8619a36ff55ac8723bc449332460368f9a090a77 Author: Max Kellermann Date: Mon Jul 6 09:38:10 2026 +0200 ceph: add helper function ceph_cap_is_removed() Having it as a wrapper allows replacing the implementation, which the next patch will do. Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit 6cd69ea0f04c481b7b104c32824546e7df1806a5 Author: Max Kellermann Date: Mon Jul 6 09:38:09 2026 +0200 ceph: make __ceph_remove_cap() static It's only used from within caps.c. Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit 4bd3158bd62466d57ed72a3f7bc5f205fedd6919 Author: Michael Bommarito Date: Tue Jul 7 14:06:00 2026 -0400 ceph: cap delegated inode count in ceph_parse_deleg_inos() ceph_parse_deleg_inos() decodes interval sets of delegated inode numbers from an MDS create-with-delegation reply. For each set it reads a 64-bit start and a 64-bit len with ceph_decode_64_safe(), which only validates that the eight bytes are present in the message, not the value, and then loops over len while inserting entries into s_delegated_inos. len is fully attacker controlled. A malicious or compromised MDS can send one huge interval, many intervals in one reply, duplicate intervals, or repeated replies that accumulate delegated inodes on the same session. The original code bounded none of these and could spin the insert loop or grow the xarray without limit. Bound both dimensions with a single enforcement point. Track the number of delegated inodes held by each MDS session in an atomic counter and grow it only in ceph_insert_deleg_ino(), which uses atomic_add_unless() to refuse to push the count past CEPH_MAX_DELEG_INOS. Because that helper is the only place the counter grows, the per-session population can never exceed the cap, so no separate per-session pre-check is needed. The counter is decremented when async create consumes a delegated inode or when an insert fails, incremented when a delegated inode is restored, initialized with the session xarray, and reset when reconnect destroys the xarray. A per-session cap alone still lets one reply spin the insert loop on duplicate ranges without growing the counter, so also cap the aggregate interval length accepted from a single reply. Together these bound both the loop trip count per reply and the xarray population across replies. The cap is a fixed, client-chosen constant rather than a value derived from the MDS. mds_client_prealloc_inos is a userspace MDS configuration option; it is never sent to the kernel client on the wire, and a server-supplied bound could not be trusted for a defensive limit in any case. The constant is set well above that option's documented default of 1000 (a generous multiple), so legitimate refill behavior is unaffected while the CPU and xarray memory a malformed delegation stream can consume stays bounded. Impact: a malicious or compromised Ceph MDS can no longer make a client spin through an unbounded delegated-inode interval or grow one session's delegated-inode xarray without limit. Cc: stable@vger.kernel.org Fixes: d48464878708 ("ceph: decode interval_sets for delegated inos") Suggested-by: Viacheslav Dubeyko Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov commit a3eb169ee297aa99670ba927c659990bd1e453f3 Author: Michael Bommarito Date: Tue Jul 7 14:05:59 2026 -0400 ceph: bound num_export_targets array for mds info v2/v3 ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from each per-mds info record and advances the decode cursor by num_export_targets * sizeof(u32) without first checking that many bytes remain. The only upper-bound check that catches a runaway cursor (*p > info_end) is gated on info_v >= 4, because info_end is left NULL for info_v 2 and 3. When the monitor sends an MDS map whose per-mds info version is 2 or 3 with an oversized num_export_targets, the cursor moves past the message front buffer and the later export-targets loop calls the unchecked ceph_decode_32() on out-of-bounds memory. A kernel client processes CEPH_MSG_MDS_MAP from its monitor session (net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an on-path attacker on an unsigned/unencrypted messenger session, can therefore drive an out-of-bounds read in the client kernel; on x86_64 with KASAN it is reported as a slab-out-of-bounds read in ceph_mdsmap_decode(). The decoded values land in the internal info->export_targets[] array, so the consequence is a kernel out-of-bounds read, not an information leak to the attacker. Impact: a malicious or compromised Ceph monitor sending an MDS map with a per-mds info version of 2 or 3 and an oversized num_export_targets field triggers an out-of-bounds read in the CephFS client kernel. Add a ceph_decode_need() for the export-targets array before advancing the cursor, so the bound is enforced for every info_v >= 2, not only info_v >= 4. This mirrors the count-then-need idiom already used for m_data_pg_pools later in the same function. Compute the export-targets byte count with size_mul() and reuse that checked length when advancing the cursor, so the attacker-controlled num_export_targets multiplication fails closed on overflow rather than relying on the later kcalloc() guard. Cc: stable@vger.kernel.org Fixes: d463a43d69f4 ("ceph: CEPH_FEATURE_MDSENC support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov commit 77933e22adfe813be2bd10be08d6e950103c3967 Author: Michael Bommarito Date: Tue Jul 7 14:05:58 2026 -0400 ceph: bound MDSCapAuth path and fs_name decode in handle_session() handle_session() decodes the MDSCapAuth records carried by a CEPH_SESSION_OPEN message (msg_version >= 6). For each record the match.path and match.fs_name byte strings are read by first decoding a 32-bit length and then copying that many bytes with the bare ceph_decode_copy(). Unlike the surrounding fields, which all use the _safe decode variants, these two copies are not preceded by a ceph_decode_need() bounds check, and the enclosing MDSCapAuth and MDSCapMatch struct_len fields are skipped rather than enforced as an upper bound. A length larger than the bytes remaining in the message front makes ceph_decode_copy() read past the end of the front buffer. The message front is a dedicated allocation (ceph_msg_new2() -> kvmalloc), so the over-read runs off that object. A malicious or compromised MDS can trigger this with the first post-connect message on mount, with no client-side user interaction; under KASAN it is reported as a slab-out-of-bounds read in handle_session(). Impact: a malicious MDS can force the kernel client to read up to 4 GiB past the message front allocation during session setup, crashing the client (out-of-bounds read). Switch both copies to ceph_decode_copy_safe(), which performs the ceph_decode_need() bounds check before the copy and branches to the existing bad label, matching the rest of the decoder and the error path that frees the partially decoded cap_auths array. Cc: stable@vger.kernel.org Fixes: 1d17de9534cb ("ceph: save cap_auths in MDS client when session is opened") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov commit 68d541754d6cd3bb98d1fd8314f57e5eb533557d Author: Michael Bommarito Date: Tue Jul 7 14:05:57 2026 -0400 ceph: bound xattr value length in __build_xattrs() __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare "p += len" and no ceph_decode_need() check that "len" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored. Cc: stable@vger.kernel.org Fixes: 355da1eb7a1f ("ceph: inode operations") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov commit eff8013c5a8916613c742ae5a2cc341cb605c0ae Author: Michael Bommarito Date: Sat Jul 11 11:07:05 2026 -0400 ceph: bound copied dentry name length in NFS export get_name ceph_get_name() copies the MDS-supplied name into the caller's NAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len) and then writes name[rinfo->dname_len] = 0, without checking dname_len against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply with dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies rde->name / rde->name_len the same unchecked way. Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name buffer in a client's NFS-export get_name path, a slab out-of-bounds write reported by KASAN. Reachable when a CephFS mount is re-exported over NFS. Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and __get_snap_name(). Cc: stable@vger.kernel.org Fixes: 19913b4eac4a ("ceph: add get_name() NFS export callback") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov commit 9ec08b7499a62c6d4afa93d36ab47a43fcad57d1 Author: Michael Bommarito Date: Tue Jul 14 07:51:39 2026 -0400 libceph: validate OSD extent maps before cursor advance net/ceph/osd_client.c:osd_sparse_read() validates that the sparse-read data length matches the summed extent lengths, but it does not validate that each OSD-supplied extent is monotonic and lies inside the original request range. A malformed authenticated OSD reply can advertise a far-forward nonzero extent offset with a matching data length and make the client advance the message-data cursor beyond the request buffer. This reaches the BUG_ON(!*length) assertion in ceph_msg_data_next() from the client receive path. Impact: A malicious or compromised authenticated Ceph OSD peer can crash a kernel Ceph client via a malformed sparse-read reply. Reject sparse extent maps that overflow, move backwards, overlap, or extend outside the original sparse-read request before advancing the cursor. [ idryomov: perform sparse_extent_map_valid() check a bit earlier, in CEPH_SPARSE_READ_DATA_LEN instead of CEPH_SPARSE_READ_DATA_PRE state ] Cc: stable@vger.kernel.org Fixes: f628d7999727 ("libceph: add sparse read support to OSD client") Assisted-by: Codex:gpt-5-5-xhigh Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov commit d2a8d446a09c74c8ddfe108b50dd791c889983fc Author: Xiubo Li Date: Tue Jul 21 13:06:53 2026 +0800 ceph: revalidate ki_pos for O_APPEND writes after cap acquisition For O_APPEND writes, ki_pos is set to the current EOF via generic_write_checks() after fetching i_size from the MDS. However, ceph_get_caps() may need to wait for Fwx exclusive caps if the write extends the file (endoff > i_max_size). While waiting for Fwx, the previous Fwx holder (another client) may have already extended the file. When the MDS grants us Fwx, the cap grant message updates the local i_size, but ki_pos remains at the old EOF, causing the append write to land at a stale offset and overwrite data from the other client. Fix by re-reading i_size_read(inode) after ceph_get_caps() returns. At this point we hold Fwx exclusive caps, no other client can modify the file, and i_size reflects the true EOF from the MDS cap grant. No extra MDS round-trip is needed. Only adjust ki_pos when the EOF has actually changed. After adjusting ki_pos forward, the write range [pos, pos+count) may now exceed the i_max_size that was validated by ceph_get_caps() for the old range. Re-check against i_max_size and truncate the write if necessary to stay within the MDS-granted limit. Link: https://tracker.ceph.com/issues/7333 Fixes: 8e4473bb50a1 ("ceph: do not execute direct write in parallel if O_APPEND is specified") Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov commit a354d7eaa1a57f1532c8072a424cc2d339a73cc0 Author: Xiubo Li Date: Tue Jul 14 14:20:37 2026 +0800 ceph: fix use-after-dereference of NULL ci in __ceph_remove_cap() The NULL check for "ci" in __ceph_remove_cap() was dead code because ci was dereferenced via &ci->netfs.inode before the check, and cap->session was dereferenced via session->s_mdsc->fsc->client even earlier. On a double-remove, both cap->ci and cap->session are set to NULL by the first call, so the second call would crash before ever reaching the guard. Move ci, session, cl, and inode initializations after the NULL check so that the early-return actually works. Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov commit af59562a5b3d34fb3aa7753f2543393578d06dbf Author: Xiubo Li Date: Thu Jul 23 14:28:19 2026 +0800 ceph: do not cache negative dentries for snapped directories When a LOOKUP/LOOKUPSNAP in a snapped directory returns ENOENT without a trace, ceph_finish_lookup() creates a negative dentry via d_add(dentry, NULL). For live directories this is fine — the dentry naturally expires. But for snapped directories, ceph_d_revalidate() unconditionally trusts all cached dentries (valid = 1), so a negative dentry created by a transient error persists forever, hiding entries that genuinely exist in the snapshot. Only cache negative dentries for live (non-snapshotted) parent directories. For snapped parents, skip the negative dentry so that VFS retries the lookup on the next access. Since the conditions that trigger a negative dentry (MDS transient error, local ENOENT shortcut, or MDS null dentry lease) are all rare in snapped directories, the performance impact of this change is negligible. Link: https://tracker.ceph.com/issues/78529 Reported-by: Andras Pataki Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov commit 699411a3534139e0edde1e7fc190c3eea0786ffc Author: Xiubo Li Date: Wed Aug 12 00:36:26 2026 -0700 ceph: use GFP_KERNEL consistently in __ceph_pool_perm_get() __ceph_pool_perm_get() has six allocations for building OSD STAT requests, five of which used GFP_NOFS and one (the page vector allocation) used GFP_KERNEL, making them inconsistent. The function is only called from ceph_try_get_caps() and __ceph_get_caps(), both of which are in the user I/O path (read, write, fallocate, mmap fault), not in the writeback path. There is no risk of recursive writeback, so GFP_NOFS is unnecessarily restrictive. Use GFP_KERNEL consistently for all six allocations. Signed-off-by: Xiubo Li Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit 9be23efacbac35ebd6ff1512cb22e69c25e4861d Author: Xiubo Li Date: Thu Jul 23 13:47:42 2026 +0800 ceph: use GFP_NOFS for cap flush allocation in writeback path ceph_alloc_cap_flush() is called from ceph_writepages_start() inside the writeback layer, where other allocations in the same path (ceph_osdc_alloc_request, ceph_osdc_alloc_messages) already use GFP_NOFS. A GFP_KERNEL allocation here can trigger direct reclaim that recursively enters the filesystem writeback path: ceph_writepages_start() // inode A writeback ceph_alloc_cap_flush() kmem_cache_alloc(..., GFP_KERNEL) [direct reclaim] try_to_free_pages() shrink_slab() super_cache_scan() prune_icache_sb() inode_lru_isolate() iput() -> evict(inode_B) [inode_B has dirty pages] filemap_flush() ceph_writepages_start() // re-enters writeback ceph_alloc_cap_flush() -> RECURSION / STACK OVERFLOW All 11 callers of ceph_alloc_cap_flush() are in write or writeback contexts: writepages (x2), write_iter, fallocate, copy_file_range, setxattr, setattr, and page_mkwrite. Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit ac9d69ae4835807fc1ecdab9c85fe7eca682de08 Author: Max Kellermann Date: Thu Jul 9 12:48:56 2026 +0200 ceph: use detach_cap_releases() in ceph_send_cap_releases() Eliminate some redundant code. Signed-off-by: Max Kellermann Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov commit e33752c8510076f3ef63198ee2bce15ed1ae14d9 Author: Max Kellermann Date: Mon Jul 6 16:59:25 2026 +0200 ceph: skip __touch_cap() most of the time __touch_cap() moves one capability to the end of the LRU list; this list is sorted by access time for just one thing: ceph_trim_caps(). That function is supposed to discard the least-recently used capabilities. __touch_cap() is called extremely often - several times for every system call, but ceph_trim_caps() is only called rarely. __touch_cap() causes considerable lock contention on `ceph_mds_session.s_cap_lock`; this is a /proc/lock_stat I captured on one of our web servers for 5 minutes: class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &s->s_cap_lock: 336304046 341686597 0.04 4905.76 418498578.76 1.22 892783632 1957814739 0.04 959.40 355752146.24 0.18 -------------- &s->s_cap_lock 339379730 [<00000000a2197200>] __ceph_caps_issued_mask+0x1bc/0x240 &s->s_cap_lock 1268054 [<00000000c96a24b7>] ceph_add_cap+0x234/0x3e0 &s->s_cap_lock 1021360 [<00000000aa76f996>] ceph_add_cap+0x108/0x3e0 &s->s_cap_lock 16042 [<0000000099463548>] __ceph_remove_cap+0x1f4/0x270 -------------- &s->s_cap_lock 338509619 [<00000000a2197200>] __ceph_caps_issued_mask+0x1bc/0x240 &s->s_cap_lock 1937864 [<00000000c96a24b7>] ceph_add_cap+0x234/0x3e0 &s->s_cap_lock 1203451 [<00000000aa76f996>] ceph_add_cap+0x108/0x3e0 &s->s_cap_lock 202 [<00000000888f212a>] __ceph_remove_cap+0x7c/0x270 In this /proc/lock_stat output, __touch_cap() is inlined in __ceph_caps_issued_mask(). It is responsible for 99% of all contentions. Since __touch_cap() is called so often, it is acceptable to just skip most calls. The most busy capabilities will still gravitate towards the end of the linked list, and if not, it doesn't hurt as much as the lock contention. This is still good enough for ceph_trim_caps(). This patch adds a static variable that gets incremented with each call, and 255 out of 256 calls will just be skipped. I didn't bother to make the increment atomic or use READ_ONCE because I don't think that makes a practical difference for this use case. Another /proc/lock_stat for 5 minutes with this patch (__touch_cap() is no longer inlined probably because it contains a static variable): class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &s->s_cap_lock: 1043711 1065182 0.04 502.72 737472.88 0.69 10522578 25069948 0.04 796.44 11053669.64 0.44 -------------- &s->s_cap_lock 1043074 [<00000000f4367d73>] __touch_cap.isra.0+0x50/0xa8 &s->s_cap_lock 12147 [<0000000096f45706>] ceph_add_cap+0x234/0x3e0 &s->s_cap_lock 9472 [<0000000038a23e0f>] ceph_add_cap+0x108/0x3e0 &s->s_cap_lock 471 [<00000000e2eba934>] __ceph_remove_cap+0x1f4/0x270 -------------- &s->s_cap_lock 978499 [<00000000f4367d73>] __touch_cap.isra.0+0x50/0xa8 &s->s_cap_lock 57794 [<0000000038a23e0f>] ceph_add_cap+0x108/0x3e0 &s->s_cap_lock 27226 [<0000000096f45706>] ceph_add_cap+0x234/0x3e0 &s->s_cap_lock 1581 [<00000000e2eba934>] __ceph_remove_cap+0x1f4/0x270 __touch_cap() is still responsible for 91% of all contentions, but the number of contentions has been reduced by a factor of 320 and the total wait time by a factor of 567. Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit ad2d093781a0d9a9e49f4e102055d9e9b8f3b463 Author: Marco Crivellari Date: Mon Jul 6 18:04:50 2026 +0200 ceph: Change system_unbound_wq with system_dfl_wq system_wq (per-CPU) and system_unbound_wq (unbound) are the older workqueue name, replaced by system_{percpu|dfl}_wq. The new workqueues have been introduced by: 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") Usage of older workqueues will now trigger a pr_warn_once() because they are marked as deprecated as per commit: 64d8eae3f895 ("workqueue: Add warnings and fallback if system_{unbound}_wq is used") So change the used workqueue with the newer, keeping the same behavior. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit 76854b339b3fbbc144f7ad6dd96e7495b94aab62 Merge: 916b61abba586d d657aa1b8ed345 cb258d651d747a Author: Rafael J. Wysocki Date: Wed Aug 26 19:49:23 2026 +0200 Merge branches 'pm-cpufreq' and 'pm-sleep' Merge additional cpufreq updates and one update related to system sleep for 7.3-rc1: - Unblock runtime PM when device prepare fails that was not done by mistake (Shibo Zhu) - Fix possible rate limit overflow on 32-bit systems in the schedutil cpufreq governor (Hui Su) - Consolidate HWP P-states initialization in the intel_pstate cpufreq driver and make that driver avoid using the DESIRED_PERF HWP hint when the Dynamic Efficiency Control (DEC) is enabled in the processor to avoid inconsistent behavior (Rafael Wysocki) * pm-cpufreq: cpufreq: intel_pstate: Avoid using DESIRED_PERF when DEC is enabled cpufreq: intel_pstate: Consolidate HWP P-states initialization cpufreq: schedutil: Fix rate limit overflow * pm-sleep: PM: sleep: Unblock runtime PM when device prepare fails commit ea10c0b334e0dca944de2b5ecf57cf7e366674f4 Merge: bbc981bd541e62 9e409f1dff7841 415125669c2ddc 6d2d4627485595 ced45be0073a8a Author: Rafael J. Wysocki Date: Wed Aug 26 19:26:49 2026 +0200 Merge branches 'acpi-battery', 'acpi-button', 'acpi-soc' and 'acpi-pfrut' Merge updates of assorted ACPI drivers for 7.3-rc1: - Protect all battery properties with a separated mutex in the ACPI battery driver to prevent race conditions from occurring and avoid evaluating the _BST ACPI control method multiple times in parallel for the same battery device (Rong Zhang) - Add DMI quirk for Razer Blade Pro 17 early 2020 lid switch to the ACPI button driver (Robin Everaars) - Convert fixed clock rates in the ACPI driver for AMD SoCs (APD) to use HZ_PER_MHZ and add a clock frequency for the HJMC01 I2C controller to it (Hongnan Li and Xiangyang Yu) - Fix a stack buffer overflow in query_capability() in the ACPI platform firmware runtime update driver (Anirudh Prasad) * acpi-battery: ACPI: battery: Protect all properties with a separated mutex * acpi-button: ACPI: button: Add DMI quirk for Razer Blade Pro 17 early 2020 lid switch * acpi-soc: ACPI: APD: Add clock frequency for HJMC01 I2C controller ACPI: APD: Convert fixed clock rates to use HZ_PER_MHZ * acpi-pfrut: ACPI: pfr_update: fix stack buffer overflow in query_capability() commit e939fc6a7bd969a58a150b7f188c1047138403e3 Author: Sam Edwards Date: Fri May 29 20:06:46 2026 -0700 ceph: properly decrypt filenames in vmalloc() buffers The fscrypt subsystem uses the scatterlist crypto API, inheriting its requirement that any buffers are in the linear mapping region. However, the messenger client uses kvmalloc() to create buffers for messages, which will occasionally place those buffers in the vmalloc() region when physical memory fragmentation doesn't permit a large enough kmalloc(). The various callers of ceph_fname_to_usr() directly pass (slices of) raw messages from the MDS without considering that the messages may be in vmalloc() buffers, resulting in oopses especially on non-x86 platforms (see 'Closes:' for more details and a reproducer). Make ceph_fname_to_usr() explicitly tolerant of vmalloc()-allocated fname->ctext, fname->name, and/or oname->name buffers, using `tname` (which, when non-null, must be a linear address; when null, is briefly allocated as necessary) as a bounce buffer to avoid passing any inappropriate addresses to fscrypt_fname_disk_to_usr(). Additionally change parse_reply_info_readdir() -- the only function to supply its own `tname` -- to follow the new "tname must never come from vmalloc()" rule by passing NULL when the message is not in the linear region. Though this causes a per-dentry kmalloc()+kfree(), this overhead exists only when processing the minority of messages that spill into vmalloc(). My (crude) testing puts this at only about 1 in 8,000 readdir messages. Still, if the overhead proves unreasonable in the future, it is easy enough to mitigate: a future change could allocate a bounce buffer in parse_reply_info_readdir() and use that as `tname` instead. Cc: stable@vger.kernel.org # 888d33b208bd: ceph: pass fscrypt `tname` buffers directly Cc: stable@vger.kernel.org Fixes: 457117f077c6 ("ceph: add helpers for converting names for userland presentation") Closes: https://lore.kernel.org/ceph-devel/20260415034020.11530-1-CFSworks@gmail.com/ Signed-off-by: Sam Edwards Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit 888d33b208bd6929808abdc0728e3e5f744b60dc Author: Sam Edwards Date: Fri May 29 20:06:45 2026 -0700 ceph: pass fscrypt `tname` buffers directly ceph_fname_to_usr() needs a temporary buffer for some operations (currently only base64-decoding ciphertext) and it is convenient to allow the caller to specify this buffer to avoid a heap allocation, so it has a (nullable) `tname` argument. Until now, this argument was a `struct fscrypt_str`; however, this is unnecessary for two reasons: 1. `tname->len` isn't used anywhere: ceph_fname_to_usr() assumes a buffer large enough to hold the ciphertext, and parse_reply_info_readdir() -- the only caller to use tname -- doesn't set it. 2. While the `tname` parameter is documented "may be NULL," parse_reply_info_readdir() always passes it but with `tname->name` sometimes NULL in violation of the contract, indicating that the unnecessary container creates actual confusion. Therefore, change the type to `unsigned char *` and pass the buffer directly. Signed-off-by: Sam Edwards Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov commit 4f49c3f8a5a86d237bb202ecb17c2802ddc8fd2f Author: Hongling Zeng Date: Thu Jun 4 15:43:25 2026 +0800 ceph: Fix ERR_PTR(0) in ceph_mkdir() When mkdir succeeds, ceph_mkdir() sets ret to ERR_PTR(0) which is incorrect. It should return NULL instead for success. Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *") Signed-off-by: Hongling Zeng Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov commit bbc981bd541e62760c4c0dbf326427a4751e3586 Merge: 4c2cebc89db985 87ee7d704f69f3 Author: Rafael J. Wysocki Date: Wed Aug 26 19:22:52 2026 +0200 Merge branch 'acpi-bus' Merge changes related to primary "physical" device lookup for a given ACPI device object that include the introduction of a new lookup helper function and core ACPI device enumeration code updates putting that new function to use (Rafael Wysocki) * acpi-bus: ACPI: scan: Use acpi_bus_get_primary_device() ACPI: platform: Use acpi_bus_get_primary_device() ACPI: bus: Introduce acpi_bus_get_primary_device() commit 4c2cebc89db9852a0815d4c3cbdea4e102230e8c Merge: a6fa4d6e38d6d5 7617cc05df28dc Author: Rafael J. Wysocki Date: Wed Aug 26 19:14:10 2026 +0200 Merge branch 'acpi-scan' Merge core ACPI device enumeration code changes for 7.3-rc1: - Prevent the core ACPI enumeration code from combining device resources that overlap completely in order to avoid resource conflicts during platform device registration because there are drivers that expect such resources to be present (Rafael Wysocki) - Defer device power initialization during ACPI-based device enumeration to the point when the given device is known to be present and functional and all of its dependencies have been met (Peixin Xie) - Fix bus ID cleanup on device_add() failures during ACPI device object registration (Hongyan Xu) * acpi-scan: ACPI: scan: Do not combine resources that overlap completely ACPI: scan: Defer device power initialization ACPI: scan: fix bus ID cleanup on device_add() failures commit 2bdcd6cf2ac4186c3640ac54cfc48c14de80948c Merge: a5218c6474df97 94509f50d696bf Author: Linus Torvalds Date: Wed Aug 26 09:25:12 2026 -0700 Merge tag 'docs-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux Pull more documentation updates from Jonathan Corbet: "A handful of late-arriving fixes, a Japanese translation that was ready long ago but fell through the cracks, and an update to the Italian translations" * tag 'docs-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux: docs: panic: Disclaimer about console verbosity when using panic_print with pstore docs: kernel-parameters: add CPU_FREQ, CPU_IDLE build options doc:it_IT: align Italian documentation in process docs: threat-model: fix /dev/kmsg reference docs: block: fix dead http link in blk-mq.rst docs/ja_JP: translate submitting-patches.rst (tag usage) commit 16b10f64c63f78220c3b4035f1ed6cd3bdcb0b02 Author: Michail Tatas Date: Thu Aug 13 20:36:50 2026 +0300 gpiolib: Put fwnode reference on failure We get a reference to the fwnode handle which we pass to gpio_shared_make_ref. In case it fails we do not put the reference. Fix by putting the reference in the failure case Fixes: 49416483a953 ("gpio: shared: allow sharing a reset-gpios pin between reset-gpio and gpiolib") Cc: stable@vger.kernel.org Signed-off-by: Michail Tatas Link: https://patch.msgid.link/an4Asr4tx3D2QvLD@michalis-linux Signed-off-by: Bartosz Golaszewski commit a5218c6474df97f2e7f3af15dcdfc674bae5c137 Merge: 45c13f3f9e3bb1 d51fc9d4cd6eb1 Author: Linus Torvalds Date: Wed Aug 26 08:45:09 2026 -0700 Merge tag 'pwrseq-updates-for-v7.3-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull another power sequencing update from Bartosz Golaszewski: "A single tree-wide rename of two of the public functions to better reflect their actual semantics: - rename pwrseq_power_on/off() to pwrseq_enable/disable() tree-wide" * tag 'pwrseq-updates-for-v7.3-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: rename pwrseq_power_on/off() to pwrseq_enable/disable() commit 9642a5e843758686e02a7f0d1df9eb0f7f96603c Author: Bob Song Date: Wed Aug 26 19:53:44 2026 +0800 ALSA: hda/conexant: Always enable the headset-mic pin on plugin Rename the function to cx_process_headset_detect_plug_type() to reflect that it only reports the detected plug type, and move the pin control write into cx_update_headset_mic_vref() so that node 0x19 is always set to enable the headset mic with the 80% VREF whenever the mic is present, regardless of the type detection result. Signed-off-by: Bob Song Link: https://patch.msgid.link/20260826115344.2128835-1-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai commit 14511c9b54ceeeef487409d73947c89ee8563590 Author: HyeongJun An Date: Tue Aug 25 21:57:45 2026 +0900 ASoC: dapm: Fix off-by-one check on the second enum channel The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off. Fixes: 3727b4968453 ("ASoC: dapm: Consolidate MUXs and value MUXs") Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260825125745.932832-1-sammiee5311@gmail.com Signed-off-by: Mark Brown commit fe66c3ff85e85d492673c6dc95c3d624a63e0282 Author: Fuad Tabba Date: Wed Aug 26 12:22:34 2026 +0100 of/irq: Fix device node refcount leak in of_irq_get_affinity() of_irq_parse_one() raises the refcount of the interrupt controller node on success, and of_irq_get_affinity() returns without putting it, so every call past the parse leaks one reference. It is reached from platform_get_irq_affinity(), used by arm_pmu, arm_spe_pmu and coresight-trbe. Put it once irq_populate_fwspec_info() has run: no in-tree ->get_fwspec_info() returns a mask that lives in the node. Fixes: 5404f5c06dd4 ("of/irq: Add interrupt affinity reporting interface") Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260826112234.1033974-1-fuad.tabba@linux.dev Signed-off-by: Rob Herring (Arm) commit 4d6642d64cd00f276549ec2c0b0278aea2f8c1aa Author: Sehat Mahde Date: Tue Aug 25 17:46:40 2026 -0500 ASoC: amd: acp-config: force SoundWire probe on HP OmniBook X Flip 16 The BIOS on the HP OmniBook X Flip 16-cc0xxx (board 8EA2) reports acp-audio-config-flag = FLAG_AMD_LEGACY_ONLY_DMIC. This binds the legacy ACP driver and registers a PDM-only card, so the SoundWire links are never scanned and the two TAS2783 speaker amplifiers and RT712-VB codec do not enumerate. Add a DMI entry for board 8EA2 to the ACP70 ACPI flag override table so the firmware-provided flag is overridden and snd_pci_ps probes instead. On the affected system, an otherwise identical upstream kernel without this entry binds snd_acp_pci, enumerates no SoundWire slave devices and exposes no internal speaker PCM. With the entry added, snd_pci_ps binds, both TAS2783 amplifiers and the RT712-VB enumerate over SoundWire, and the amd-soundwire card exposes the internal speaker playback PCM. Developed with AI assistance. ChatGPT helped analyze the ACP and SoundWire behavior, structure the controlled A/B testing, and draft the patch changelog. All hardware measurements, kernel builds, reboots and playback tests were performed by the submitter. The submitter has reviewed the change, understands it and takes responsibility for it. Assisted-by: ChatGPT:GPT-5.6 Sol Signed-off-by: Sehat Mahde Link: https://patch.msgid.link/20260825224640.13662-1-hskmahde@gmail.com Signed-off-by: Mark Brown commit c1a39c228aceebc0ede83781ea906d257e324009 Author: Mehmet Aysel Date: Tue Aug 25 12:24:32 2026 +0300 ASoC: amd: acp3x-es83xx: Add HVY-WXX9/M1060 DMI quirk Add matching DMI table entry for the ES83xx machine driver, so the HUAWEI HVY-WXX9 / M1060 board (MateBook D16 2021, Ryzen 5 4600H) can successfully probe its ES8316 codec via the acp3x-es83xx machine driver, consistent with the existing M1010/M1020/M1040 entries for the same board name. Signed-off-by: Mehmet Aysel Link: https://patch.msgid.link/20260825092432.56292-2-mehmet4ysel@gmail.com Signed-off-by: Mark Brown commit 032bb633e0c34a88b70a4bfc65ebd4e2b510f706 Author: Mehmet Aysel Date: Tue Aug 25 12:24:31 2026 +0300 ASoC: amd: acp-config: Add HVY-WXX9/M1060 DMI quirk Add DMI match table entry for HUAWEI HVY-WXX9 board, product version M1060, a MateBook D16 2021 (Ryzen 5 4600H) revision not covered by the existing M1010/M1020/M1040 entries. This board uses the same FLAG_AMD_LEGACY / ACP_PCI_DEV_ID configuration as the other HVY-WXX9 variants. Signed-off-by: Mehmet Aysel Link: https://patch.msgid.link/20260825092432.56292-1-mehmet4ysel@gmail.com Signed-off-by: Mark Brown commit 385c7af4e3b95d0769fd211831674e83b16a2ebf Author: Ahmad Byagowi Date: Sun Aug 23 09:34:36 2026 -0700 i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data. Fixes: bc45449b1444 ("i2c/of: Automatically populate i2c mux busses from device tree data.") Signed-off-by: Ahmad Byagowi Cc: # v3.5+ Acked-by: Peter Rosin Signed-off-by: Andi Shyti Link: https://patch.msgid.link/b3e46bbee781b3cb4029aca9a71316cc5e36dc17.1787502619.git.ahmadexp@gmail.com commit 84d2d96ac3f1bb467aca65adf2c19431e6eeb151 Author: bui duc phuc Date: Tue Aug 25 15:19:49 2026 +0700 ASoC: soc-generic-dmaengine: Fix DMA channel request warning The DMA channel request code currently warns about legacy DMA failures when the channel name is not present in dma-names. This can report a firmware lookup failure as a legacy DMA failure. Furthermore, failures from the legacy DMA path are already reported by find_candidate(), making these warnings redundant. Only warn when the channel name is present in dma-names but the request fails, avoiding misleading and duplicate error messages. Fixes: 9167f260477b ("ASoC: soc-generic-dmaengine: Handle DMA channel request failures correctly") Reported-by: Sebastian Reichel Link: https://lore.kernel.org/all/aoyBuho270dTWYBL@jupiter.universe/ Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260825081949.55537-1-phucduc.bui@gmail.com Signed-off-by: Mark Brown commit 4d7fa28e151a6a6f24098d9e60f558f8ea61ddaa Author: Roman Vivchar Date: Fri Aug 14 16:13:52 2026 +0300 dt-bindings: input: mediatek,mt6779-keypad: add mt6572 Add a compatible string for the mt6572 keypad, that is compatible with mt6779. Signed-off-by: Roman Vivchar Reviewed-by: Mattijs Korpershoek Acked-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260814-6572-dt-keypad-v1-1-2ceff2373211@protonmail.com Signed-off-by: Dmitry Torokhov commit 21efadc62272cabee9bec27777ae75d84a9ca8a8 Author: Alvin Šipraga Date: Tue Aug 18 18:00:02 2026 +0200 Input: adp5588-keys - cache GPIO state before registering the gpiochip So as not to clobber any pre-programmed GPIO state in the execution of its gpiochip ops, the driver caches things during probe time. However, since those ops can be called both during and immediately after the call to devm_gpiochip_add_data(), it is imperative that things are cached before that. That's not the case right now, so reorder the two steps to prevent any clobbering. In the concrete example which motivated this change, a bootloader was preconfiguring an important GPIO output to HIGH before booting the kernel. Linux would then inadvertently set that output to LOW while configuring a GPIO hog on a discrete GPIO line within the same 8-bit bank (because the cached value was 0=LOW). Fixes: ba9f507a1bea ("Input: adp5588-keys - export unused GPIO pins") Signed-off-by: Alvin Šipraga Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20260818-adp5588-gpio-cache-v1-1-650a2674fc0d@analog.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov commit 323751a604e7533fa473874d999371592a614207 Author: Dennis Tighe Date: Tue Aug 25 22:09:34 2026 -0700 ntfs: reject invalid sectors_per_cluster in the boot sector is_boot_sector_ntfs() checks the boot sector's sectors_per_cluster field with a range test that rejects 0x81..0xf3 but accepts 0 and other non-power-of-two counts. A zero value reaches parse_ntfs_boot_sector(): sectors_per_cluster_bits = ffs(sectors_per_cluster) - 1; ... vol->cluster_size = vol->sector_size << sectors_per_cluster_bits; ffs(0) is 0, so sectors_per_cluster_bits becomes (unsigned)-1 and the shift is undefined: UBSAN: shift-out-of-bounds in fs/ntfs/super.c:673:39 shift exponent 4294967295 is too large for 32-bit type 'int' This change rejects any non-power-of-two value, since it feeds the aforementioned shift via ffs() - 1, which only yields the correct shift for a power of two. Fixes: 6251f0b0de7d ("ntfs: update super block operations") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dennis Tighe Signed-off-by: Namjae Jeon commit c8504fc1245f5322af5fa5c325ab05f9cf792b87 Author: Dennis Tighe Date: Tue Aug 25 21:44:24 2026 -0700 ntfs: bound $AttrDef table walk to the loaded table size ntfs_attr_find_in_attrdef() walks the in-memory $AttrDef table, but the loop condition bounds only the start of each entry, not the whole entry: for (ad = vol->attrdef; (u8 *)ad - (u8 *)vol->attrdef < vol->attrdef_size && ad->type; ++ad) struct attr_def is 160 bytes; the guard reads ad->type at offset 128 and the loop body reads further fields. vol->attrdef is kvzalloc(i_size), where i_size is the on-disk $AttrDef data size, checked in load_and_init_attrdef() only as 0 < i_size <= 0x7fffffff. A volume whose $AttrDef data size is smaller than one entry (e.g. 120 bytes) makes the read of ad->type run past the allocation. Creating a file reaches this through ntfs_attr_size_bounds_check() and reads out of bounds: BUG: KASAN: slab-out-of-bounds in ntfs_attr_find_in_attrdef+0x66/0xa0 Read of size 4 at addr ffff888005833280 by task init/1 ntfs_attr_find_in_attrdef ntfs_attr_size_bounds_check ntfs_attr_can_be_non_resident ntfs_attr_add Require the whole entry to lie within attrdef_size in the loop guard, and reject at mount a $AttrDef too small to hold one attr_def entry. Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dennis Tighe Signed-off-by: Namjae Jeon commit a79899ca38af4ce5518a59a22f0eb1f59f7e6089 Author: Hongling Zeng Date: Tue Aug 25 17:54:05 2026 +0800 ntfs: fix undefined behavior in mft/index record size calculation The boot sector validation allows clusters_per_mft_record and clusters_per_index_record to range from 0xE1 (-31) to 0xF7 (-9) when interpreted as signed values. When these are used as negative shift counts in expressions like `1 << -clusters_per_mft_record`, values like 0xE1 cause `1 << 31`, which shifts into the sign bit of a 32-bit signed integer, resulting in undefined behavior. Fix by using unsigned shift (1U << ...) instead of signed shift. This prevents undefined behavior while preserving the full valid range of negative values (-31 to -9) that may appear in NTFS boot sectors. The encoding scheme uses negative values to represent record sizes smaller than cluster_size: -log2(record_size). Common values include -10 (1024 bytes) for mft_record_size and -12 (4096 bytes) for index_record_size. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon commit 607a9478833db656e7ceac8e9e382fa4acfde545 Author: Wentao Guan Date: Tue Aug 25 13:46:59 2026 +0800 ntfs: treat any nonzero dio zero-range return as an error ntfs_dio_zero_range() returns either 0 or a negative errno from blkdev_issue_zeroout(); it never returns a positive value. The zeroing failure check in ntfs_attr_fallocate() therefore never fired, so a failed zeroing operation was silently ignored: the loop kept going, the newly allocated clusters were folded into initialized_size and the write could succeed leaving stale on-disk data. Treat any nonzero return as an error and abort the allocation. Fixes: 495e90fa33482 ("ntfs: update attrib operations") Assisted-by: atomcode:deepseek-v4-flash Signed-off-by: Wentao Guan Signed-off-by: Namjae Jeon commit 8d139e3635c86e2c97c78d55538ce0b00b6d9986 Author: Hongling Zeng Date: Mon Aug 24 13:41:15 2026 +0800 ntfs: fix incorrect MFT record pointer passed to ntfs_attr_record_resize ntfs_new_attr_flags() passes the wrong MFT record to ntfs_attr_record_resize(). When the attribute is in an extent record, ctx->mrec points to the extent but the function receives the base record pointer m, causing incorrect size calculations in memmove. Fix by passing ctx->mrec (the actual MFT record containing the attribute) instead of m (the base MFT record) to ntfs_attr_record_resize(). Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 0e4c839905418d55bafe571a92533a1d1ac7b0a8 Author: Dennis Tighe Date: Sun Aug 23 22:08:40 2026 -0700 ntfs: do not mark the volume clean in sync_fs when errors were recorded ntfs_put_super() and the remount-read-only path both clear the dirty bit only when NVolErrors(vol) is false. ntfs_sync_fs() clears it unconditionally, so any sync() on a volume that recorded an error marks that volume clean. A volume without this set is then seen as not needing recovery and it does not run one, so whatever went wrong is never repaired. This change skips resetting the dirty bit when there are volume errors. Reproduced on a volume whose $MFTMirr does not match $MFT, which sets the error flag while leaving the mount read-write: after a write and a sync, the on-disk volume flags read 0x0000 with this driver and 0x0001 with the guard in place. Fixes: 6251f0b0de7d ("ntfs: update super block operations") Assisted-by: claude:claude-opus-5 Signed-off-by: Dennis Tighe Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 5f2a22b36fe34c98f6d5e35ddb759ee53d684145 Author: Baolin Liu Date: Fri Aug 21 13:32:38 2026 +0800 ntfs: skip free cluster decrement when rollback fails When the rollback in __ntfs_cluster_free() fails, the recursive call returns a negative errno and the subsequent ntfs_dec_free_clusters(vol, delta) subtracts that negative value, adding bogus clusters to the counter on an already-failing volume. Skip the decrement when the rollback failed. Fixes: 11ccc9107dc4 ("ntfs: update runlist handling and cluster allocator") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit be9e89ccb8e52a3e4b67feeb03ebd8133091dc7e Author: Baolin Liu Date: Fri Aug 21 13:32:37 2026 +0800 ntfs: only count successfully cleared runs when freeing clusters ntfs_cluster_free_from_rl_nolock() adds a run's length to nr_freed whenever the error bookkeeping condition is false, which includes cases where ntfs_bitmap_clear_run() actually failed - e.g. a second run failing with the same errno as an earlier one, or any failure after a non-ENOMEM error was already recorded. Since a failed ntfs_bitmap_clear_run() rolls back its partial modifications, no bits were cleared for that run, yet its length still inflates vol->free_clusters, corrupting statfs output and the allocator's free space gate. Only count runs whose bitmap clear succeeded. Fixes: 11ccc9107dc4 ("ntfs: update runlist handling and cluster allocator") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit cf06dcd572845723821b54a608fc2da995c3c8e2 Author: Baolin Liu Date: Fri Aug 21 13:32:36 2026 +0800 ntfs: fix kmap_local leak in write_mft_record_nolock() error paths write_mft_record_nolock() maps the MFT record folio with kmap_local_folio(), but the pre_write_mst_fixup() and bio_add_folio() failure paths jump to the error label without unmapping it. kmap_local mappings are stack-ordered per task, so leaking one corrupts the nesting for any outer mapping. Unmap the folio on those error paths too. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit ba1b61ddaa764f31b14abe1d547049682cc5824e Author: Baolin Liu Date: Fri Aug 21 13:32:35 2026 +0800 ntfs: return real error from ntfs_non_resident_attr_record_add() ntfs_non_resident_attr_record_add() returns -1 at its put_err_out label, which callers propagate as -EPERM to userspace. Return the actual error code. Every path reaching the label has err set to a negative errno. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 8efe00b098b5b3618c885d2a35a5edccfbfbec7d Author: Baolin Liu Date: Fri Aug 21 13:32:34 2026 +0800 ntfs: preserve error code in ntfs_resident_attr_record_add() ntfs_resident_attr_record_add() collapses every failure to -EIO at its put_err_out label. This defeats the resident-to-non-resident fallback in ntfs_attr_add(), which relies on seeing -ENOSPC to convert the attribute when the MFT record has no room, and also hides -EEXIST and -ENOMEM from callers. Return the actual error code. Every path reaching the label has err set to a negative errno. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit ada728801999e25e610091362447372f1b25dd25 Author: Baolin Liu Date: Fri Aug 21 13:32:33 2026 +0800 ntfs: return -ERANGE for undersized xattr buffer When the value buffer passed to getxattr(2) for system.dos_attrib, system.ntfs_attrib or system.ntfs_attrib_be is smaller than the attribute value, ntfs_getxattr() returns -ENODATA, which tells userspace the attribute does not exist. The xattr API expects -ERANGE in this case, and ntfs_get_ea() in the same file already returns -ERANGE for regular EAs. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 9692b1b4fc00cf89628bc43f71729ab21f14f8d3 Author: Baolin Liu Date: Fri Aug 21 13:32:32 2026 +0800 ntfs: propagate reparse index insertion failure update_reparse_data() ignores the return value of set_reparse_index(). When index insertion fails, the code removes the just-written reparse data as cleanup but still returns 0, so symlink(2) (and WSL special file creation) reports success while no reparse data exists on disk. When there was no previous reparse data (oldsize == 0), the failure was likewise silently ignored. Propagate the error to the caller. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 3d3de2aee17d1431694aa085039479b5679e5ad4 Author: Baolin Liu Date: Fri Aug 21 13:32:30 2026 +0800 ntfs: return DT_UNKNOWN on inode lookup failure in readdir ntfs_reparse_tag_dt_types() returns PTR_ERR(vi) when ntfs_iget() fails, but its return type is unsigned int and the caller passes the value straight to dir_emit() as d_type. A stale or corrupt MFT reference in a directory index thus makes readdir report a garbage d_type value to userspace. Return DT_UNKNOWN on lookup failure instead. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Signed-off-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 4d4be202165e832d74849b4a68e289a2a377039c Author: Thadeu Lima de Souza Cascardo Date: Mon Jul 27 17:45:49 2026 -0300 drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used Commit 1c6ceeee6ebb ("drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms. Fixes: 24835e442f28 ("drm: reference count event->completion") Cc: stable@vger.kernel.org Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260727-drm_crtc_atomic_commit_leak-v1-1-23d9948a9d7c@igalia.com commit d32b08284f44c20edb2ea3f64ba0a6a165036fb2 Author: Thadeu Lima de Souza Cascardo Date: Mon Aug 17 15:45:20 2026 -0300 drm/atomic: remove bogus check for file_priv Since file_priv can never be NULL at prepare_signaling() as it is only called by drm_mode_atomic_ioctl(), remove the check. If that was not the case, skipping the rest of the block here would cause the drm_pending_vblank_event object to leak and fail to set up the fence in case out_fence_ptr is set. Since the check is unreachable, there is no possible leak. Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260817-drm_atomic_bogus_check-v2-1-2b9e60f32a7e@igalia.com commit f967455fb2a5a2079b9eb5823e9ccf359174bf9f Author: Zhiling Zou Date: Sat Aug 22 16:49:27 2026 +0800 seg6: reset IP6CB after IPv6 decapsulation decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet. The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports: BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu ip6_protocol_deliver_rcu+0x1118/0x1450 ip6_input_finish+0x11b/0x240 seg6_local_input_core+0xed/0x2e0 lwtunnel_input+0x1e9/0x4e0 ipv6_rthdr_rcv+0x525f/0x6c50 ip6_protocol_deliver_rcu+0xcb7/0x1450 Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field. Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can replace skb_iif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKB_L3SLAVE for the same reason. Fixes: d7a669dd2f8b ("ipv6: sr: add helper functions for seg6local") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Reviewed-by: Andrea Mayer Signed-off-by: David S. Miller commit d51fc9d4cd6eb18ac82913d83ecf7bd8c85f71ee Author: Bartosz Golaszewski Date: Fri Jul 31 15:42:18 2026 +0200 power: sequencing: rename pwrseq_power_on/off() to pwrseq_enable/disable() The way power sequencing works means that a call to pwrseq_power_on() does not necessarily result in the pwrseq target being powered-on at that time: it may have already been powered on before. Similarly: a call to pwrseq_power_off() does not have to result in an actual powering off of resources: there may still be other users that requested a power-on before. We will also introduce the concept of "non-controllable" pwrseq targets soon which further increases the disconnect between the naming convention and the actual semantics. What consumers of pwrseq descriptors actually do is: they *vote* for a powering on of a given target or retract that vote. These operations could be called get/put in line with runtime PM but this could become confusing since we already provide pwrseq_get/put() for a different purpose. pwrseq_vote_on/off() also have been rejected as unusual in the tree. Change the name of the two functions to pwrseq_enable/disable() which better reflects their purpose and semantics and also mirrors other enable-counted resources like regulators and clocks. No functional change intended. If at any point users need to know *when* the exact power event happens, we can provide that information in the form of a notifier. Acked-by: Jeff Johnson Acked-by: Bjorn Helgaas Acked-by: Manivannan Sadhasivam Acked-by: Alessio Belle # imagination Link: https://patch.msgid.link/20260731-pwrseq-vote-rename-v3-1-44e60b8be053@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski commit 3daad923a8685adb66087e0d819559b7eb6ba975 Author: John Johansen Date: Mon Aug 24 11:01:18 2026 -0700 apparmor: policy_int make sure list heads are initialized before fail path If profile create fails before policy_init is complete the list heads are not properly initialized causing profile_free() sanity checks to trigger the following splat. AppArmor WARN aa_policy_destroy: (((!list_empty(&policy->profiles) && (&policy->profiles)->prev != ((void *) 0x122 + (0xdead000000000000UL))))): WARNING: security/apparmor/lib.c:509 at aa_policy_destroy+0x164/0x1b0 security/apparmor/lib.c:509, CPU#0: syz.0.17/5541 Modules linked in: CPU: 0 UID: 0 PID: 5541 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:aa_policy_destroy+0x16b/0x1b0 security/apparmor/lib.c:509 Code: 85 ed 7e 4d e8 96 bc 37 fd 5b 41 5c 41 5e 41 5f 5d e9 19 27 4e 07 cc e8 83 bc 37 fd 48 8d 3d 0c f0 d3 0b 48 c7 c6 a4 eb 38 8e <67> 48 0f b9 3a e9 04 ff ff ff e8 66 bc 37 fd 48 8d 3d ff ef d3 0b RSP: 0018:ffffc9000345eaa0 EFLAGS: 00010293 RAX: ffffffff848f530d RBX: ffff88803f734800 RCX: ffff88801af2a580 RDX: 0000000000000000 RSI: ffffffff8e38eba4 RDI: ffffffff90634320 RBP: 0000000000000000 R08: 0000000000000cc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d95913 R12: dead000000000122 R13: ffff88803f734800 R14: ffff88803f734828 R15: dffffc0000000000 FS: 00007f5f6a1836c0(0000) GS:ffff88808c519000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d02407b048 CR3: 0000000012aa9000 CR4: 0000000000352ef0 Call Trace: aa_free_profile+0x9d/0x9f0 security/apparmor/policy.c:334 aa_alloc_profile+0x1e4/0x3e0 security/apparmor/policy.c:416 unpack_profile security/apparmor/policy_unpack.c:1153 [inline] aa_unpack+0x17db/0x7430 security/apparmor/policy_unpack.c:1748 aa_replace_profiles+0x226/0x2a20 security/apparmor/policy.c:1183 policy_update+0x234/0x4a0 security/apparmor/apparmorfs.c:505 profile_load+0x1cb/0x320 security/apparmor/apparmorfs.c:522 vfs_write+0x296/0xba0 fs/read_write.c:685 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f6939e0d9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f5f6a183028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f5f69625fa0 RCX: 00007f5f6939e0d9 RDX: 0000000000000041 RSI: 0000200000000400 RDI: 0000000000000003 RBP: 00007f5f6a183090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f5f69626038 R14: 00007f5f69625fa0 R15: 00007ffe23725c18 Reported-by: syzbot+faed97c4ed43bfe7fee5@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=faed97c4ed43bfe7fee5 Fixes: fe6bb31f590c9 ("apparmor: split out shared policy_XXX fns to lib") Signed-off-by: John Johansen commit 92312d333bf700798f92f30406c721bce87506f3 Author: Slawomir Stepien Date: Tue Aug 25 14:07:29 2026 +0200 drm/cirrus-qemu: Validate BAR0 size during probe The `cirrus-qemu` driver relies on `CIRRUS_VRAM_SIZE` (4 MB) to validate framebuffer sizes. However, during PCI probe, the driver mapped BAR0 without verifying that its size matches `CIRRUS_VRAM_SIZE`. If a PCI device with a BAR0 smaller than 4 MB is bound to the driver, the mapped VRAM will be smaller than expected. Because validation checks assume 4 MB VRAM, framebuffers larger than the mapped memory can be created. When the display plane is updated (e.g. during release), `cirrus_primary_plane_helper_atomic_update()` copies the framebuffer to VRAM using `drm_fb_memcpy()`. Writing past the end of the mapped I/O memory causes a supervisor write page fault: BUG: unable to handle page fault for address: ffffc9000389c000 ... RIP: 0010:memcpy_toio+0x7c/0xe0 arch/x86/lib/iomem.c:110 ... Call Trace: iosys_map_memcpy_to include/linux/iosys-map.h:285 [inline] drm_fb_memcpy+0x325/0x5d0 drivers/gpu/drm/drm_format_helper.c:442 cirrus_primary_plane_helper_atomic_update+0x98a/0xb00 drivers/gpu/drm/tiny/cirrus-qemu.c:358 drm_atomic_helper_commit_planes+0x626/0xea0 drivers/gpu/drm/drm_atomic_helper.c:3038 drm_atomic_helper_commit_tail+0x60/0x510 drivers/gpu/drm/drm_atomic_helper.c:1989 commit_tail+0x2b1/0x3c0 drivers/gpu/drm/drm_atomic_helper.c:2074 drm_atomic_helper_commit+0xa77/0xb10 drivers/gpu/drm/drm_atomic_helper.c:2312 Fix this by validating in `cirrus_pci_probe()` that the PCI BAR0 resource is not less than `CIRRUS_VRAM_SIZE`, returning `-ENODEV` if it is less. Fixes: ab3e023b1b4c ("drm/cirrus: rewrite and modernize driver.") Assisted-by: Gemini:gemini-3.6-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+2442951a6abb004df963@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2442951a6abb004df963 Link: https://syzkaller.appspot.com/ai_job?id=ba262a3a-bccf-4ad8-a1b0-583c55d34fd6 Signed-off-by: Slawomir Stepien Signed-off-by: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Link: https://patch.msgid.link/20260825120729.493611-1-sst@poczta.fm commit 958f35cbb8955ca3fa439cd9f2092cb42414aa8c Author: Shixiong Ou Date: Fri Jul 31 19:17:29 2026 +0800 drm/sysfb: ofdrm: Fix is_avivo() constant comparison bug The is_avivo() function has a logic error where it compares a constant to another constant instead of checking the device parameter: (PCI_VENDOR_ID_ATI_R600 >= 0x9400) Signed-off-by: Shixiong Ou Reviewed-by: Thomas Zimmermann Fixes: f496834e1674 ("drm/ofdrm: Add per-model device function") Signed-off-by: Thomas Zimmermann Cc: # v6.2+ Link: https://patch.msgid.link/20260731111729.703116-1-oushixiong1025@163.com commit c6f48e59ece0123f6a11527ad4d89b21c2d65b87 Author: Shixiong Ou Date: Tue Aug 25 18:41:34 2026 +0800 drm/sysfb: ofdrm: Fix integer overflow in fb_size calculation The framebuffer size calculation `fb_size = linebytes * height` can overflow when both values are large (e.g., 46341 * 46341 > INT_MAX). Since linebytes and height are both int types, the multiplication is performed as int * int, which results in undefined behavior on overflow. Use check_mul_overflow() to detect and prevent this overflow, consistent with the approach used in simpledrm.c and corebootdrm.c. Signed-off-by: Shixiong Ou Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Fixes: c8a17756c425 ("drm/ofdrm: Add ofdrm for Open Firmware framebuffers") Cc: # v6.2+ Link: https://patch.msgid.link/20260825104134.669676-1-oushixiong1025@163.com commit 24c1a47f1ed28f8b31db9a36eb26d1ffbd089d7a Author: Jaegeuk Kim Date: Tue Aug 18 19:37:23 2026 +0000 f2fs: don't leave the hashed inode while it's unlinked f2fs_symlink() 1. f2fs_new_inode 2. f2fs_add_link 3. write_being|end to fill the symlink path 4. flush dirty pages and or checkpoint Step 4 is nice to succeed, which doesn't become a reason to roll back the created symlink. OTOH, if we get an error till step 3, don't leave its dentry and its inode. Reviewed-by: Chao Yu Reviewed-by: Wenjie Qi Signed-off-by: Jaegeuk Kim commit ee440d4fc0d2f15894ab1f64c474a3adbc858880 Author: Jérémy Jean Date: Sat Aug 15 10:09:18 2026 +0000 crypto: acomp - allocate async request context when cloning ACOMP_REQUEST_ON_STACK() reserves only enough storage for the synchronous fallback. When an async implementation is selected, callers clone that stack request before retrying, but acomp_request_clone() currently copies only the stack-sized object. The clone therefore has no storage for the async provider request context, and providers such as QAT write past the allocation through acomp_request_ctx(). KASAN does report a slab OOB write. Allocate a zeroed clone large enough for the runtime acomp request size, copy only the bytes present in the source object, and preserve the existing fallback-on-allocation-failure behavior. Use the runtime reqsize because an implementation may adjust it during tfm initialization. Fixes: 097c432caaa6 ("crypto: acomp - Add ACOMP_REQUEST_CLONE") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Herbert Xu commit 05ec76cfbce653e07cec19b9b8b20e33449d5d87 Author: Yifei Gao Date: Tue Aug 25 23:46:29 2026 +0000 ipmi: Fix use-after-free of cmd_rcvr in _ipmi_destroy_user() Commit 9e91f8a6c868 ("ipmi:msghandler: Remove srcu for the ipmi_interfaces list") dropped the synchronize_rcu() between unlinking the command receivers from intf->cmd_rcvrs and freeing them, updating only the comment that explains why the barrier is needed. The cmd_rcvrs list is still traversed under plain RCU: find_cmd_rcvr() walks it inside rcu_read_lock(), and handle_ipmb_get_msg_cmd() borrows rcvr->user from that lookup within the same read-side section. Without the grace period, _ipmi_destroy_user() can kfree() a cmd_rcvr while a reader still holds a pointer to it, causing a use-after-free. The rework only made srcu unnecessary for the interfaces list; the cmd_rcvrs list still relies on plain RCU. Restore the synchronize_rcu() before freeing the receivers. Fixes: 9e91f8a6c868 ("ipmi:msghandler: Remove srcu for the ipmi_interfaces list") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yifei Gao Message-ID: <20260825234630.1196170-1-gyf161023@gmail.com> Signed-off-by: Corey Minyard commit 92a9eebd2a1f892fe482154d83f9f1626bc73d3b Author: Linkai Gong Date: Wed Aug 19 13:47:42 2026 +0800 drm/amd/display: fix dc_lock leak on GPU reset error paths On GPU reset, dm_suspend() takes dc_lock and leaves it for dm_resume() to drop. If amdgpu_dm_commit_zero_streams() or dm_dmub_hw_init() fails, the function returns with the lock still held. The matching resume path is then skipped, so every later dc_lock take hangs. Release the cached DC state and unlock before returning the error. Fixes: 3cf7a0bc87f0 ("drm/amd/display: Catch failures for amdgpu_dm_commit_zero_streams()") Fixes: 2b6943df5413 ("drm/amd/display: Pass up errors for reset GPU that fails to init HW") Cc: stable@vger.kernel.org Signed-off-by: Linkai Gong Reviewed-by: Mario Limonciello Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher commit 84298acf1c8be2b1b03c0339bf1eb63102c51728 Author: Srinivasan Shanmugam Date: Thu Aug 20 15:46:01 2026 +0530 drm/amd/display: Fix redundant GPUVMEnable checks in dcn6 flip schedule Inside dcn6_calculate_flip_schedule(), GPUVMEnable is already checked in the outer if block. But the same GPUVMEnable is checked again in two inner if blocks inside it. Since GPUVMEnable is always true at that point, the inner else branches that assign meta_row_height are never reached. Remove the redundant inner GPUVMEnable checks and directly assign dpte_row_height, which is always the correct value here. Fixes: 7f7d7ea1fa51 ("drm/amd/display: Add new sources for DCN6") Reported-by: Dan Carpenter Cc: Roman Li Cc: Alex Hung Cc: Tom Chung Cc: Aurabindo Pillai Signed-off-by: Srinivasan Shanmugam Reviewed-by: George Zhang Signed-off-by: Alex Deucher commit fdc290ff4ab19c7e0dde36c4cd1e2771b61f6bf5 Author: Srinivasan Shanmugam Date: Thu Aug 20 15:29:43 2026 +0530 drm/amd/display: Fix wrong bytes-per-pixel value for dml2_422_packed_10 The pixel format dml2_422_packed_10 needs BytePerPixelDETY set to 8.0/3. But it was accidentally placed in the wrong group that sets it to 4, so the correct value was never used. This caused wrong DET buffer size and bandwidth calculations whenever this format was used. Fix it by moving dml2_422_packed_10 out of the wrong group so it gets the correct value of 8.0/3. Fixes: 7f7d7ea1fa51 ("drm/amd/display: Add new sources for DCN6") Reported-by: Dan Carpenter Cc: Roman Li Cc: Alex Hung Cc: Tom Chung Cc: Aurabindo Pillai Signed-off-by: Srinivasan Shanmugam Reviewed-by: George Zhang Signed-off-by: Alex Deucher commit 6aa530642f95d5c48aa336416f94a35e7949b647 Author: Vladimir Marioukhine Date: Wed Aug 12 12:58:12 2026 -0400 drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore Both create_queue_cpsch() and create_queue_nocpsch() unconditionally call mqd_mgr->restore_mqd() when a CRIU restore is in progress (qd != NULL), with no NULL guard. On any system where restore_mqd is not implemented for the given queue type, a user holding CAP_CHECKPOINT_RESTORE can trigger a kernel NULL pointer dereference and panic the machine by issuing KFD_IOC_CRIU_OP_RESTORE with a crafted queue restore object. Note that checkpoint_mqd is likewise unimplemented on GFX12, so no legitimate CRIU image can reach this path — only a hand-crafted restore payload. Add a NULL guard for restore_mqd immediately after mqd_mgr is resolved, unwinding via the existing error labels and returning -EOPNOTSUPP if the callback is not implemented. This mirrors the existing checkpoint_mqd guard in checkpoint_mqd(). Fixes: 48f0bdf4e38e ("drm/amdkfd: Added MQD manager files for GFX12.") Cc: stable@vger.kernel.org Signed-off-by: Vladimir Marioukhine Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher commit a04ea08ddb516f9f21f17574b6a2e7b540dfadf8 Author: Prike Liang Date: Fri Aug 7 09:46:22 2026 +0800 drm/amdgpu/userq: fix lock missing for userq fence error set amdgpu_userq_fence_driver() and amdgpu_userq_fence_driver_destroy() don't acquire the dma_fence spinlock, so locking the dma_fence lock before test the signaled state and set error state to avoid missing lock assert error. Signed-off-by: Prike Liang Acked-by: Alex Deucher Signed-off-by: Alex Deucher commit 520e345ffe05aabef1db82beda4288afb1757ff2 Author: Xiaogang Chen Date: Sun Aug 23 15:47:15 2026 -0500 drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram When migration vm range is hole at cpu side(MIGRATE_PFN_MIGRATE set + MIGRATE_PFN_VALID unset) driver still allocates device pages. There is no dma map of src pages and migration. j is 0 and svm_migrate_copy_memory_gart() will return an uninitialized r. That can trigger out_free_vram_pages to drop all VRAM just set up. Initialize r and only call the last svm_migrate_copy_memory_gart if j > 0. Current code postponed the last page to the final copy. This patch flushes on the last page when reach to the end of current drm_buddy_block; avoids another svm_migrate_copy_memory_gart. Cc: stable@vger.kernel.org Signed-off-by: Xiaogang Chen Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher commit 960c4a8069bfd352c48cc88592618f1ebe24c69e Author: Xiaogang Chen Date: Sun Aug 23 15:22:54 2026 -0500 drm/amdkfd: Fix error path at svm_migrate_copy_to_ram If page migration from device to sys ram fails for some reasons driver needs release and unlock allocated system pages. To do that driver should use page physical address, or pfn, then get struct page*. Current driver uses dma address(for adev) that is not correct with IOMMU enabled, or even in general. The patch releases and unlocks allocated system pages based on where migration failed by struct page* of sys ram pages. Also dma_unmap correspodent system ram pages at error path. Cc: stable@vger.kernel.org Signed-off-by: Xiaogang Chen Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher commit 9e8bcfde0039238e904b4e720e66b7f4fbf82c0e Author: Timur Kristóf Date: Fri Aug 21 23:50:59 2026 +0200 drm/amd/display: Log details when failing to register HPD IRQ This should help diagnose HPD IRQ related issues in the future. Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260821215059.312868-2-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher commit 52536ce677a3470c0e5323b940791efb33975450 Author: Timur Kristóf Date: Fri Aug 21 23:50:58 2026 +0200 drm/amd/display: Fix HPD consideration for VGA/LVDS connectors on DCE After a refactor that landed in Linux 7.0, DC now crashes when it is initialized on GPUs that have a VGA or LVDS connector. This is because these connectors have no HPD so the hpd_gpio is NULL and therefore DC takes the code path meant for DCN 4.2+ which sets irq_source_hpd = 255 that causes the subsequent code to try to register the HPD interrupt, which fails, and causes a crash. This commit should be backported to Linux 7.0 and newer. Cc: stable@vger.kernel.org Cc: Dmytro Laktyushkin Cc: Roman Li Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5490 Fixes: def3488eb0fd ("drm/amd/display: refactor HPD to increase flexibility") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260821215059.312868-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher commit b30900566642ceb2c9e12b56c2afec28d0fd91a0 Author: Xiang Liu Date: Fri Aug 21 17:41:57 2026 +0800 drm/amdgpu: clamp the isolation index for rings outside a partition adev->isolation[] has one slot per partition, but a ring that is not assigned to one keeps AMDGPU_XCP_NO_PARTITION, which is ~0, so indexing the array with it is out of bounds. SDMA submissions hit this on both the isolation enforcement and the VM flush path and trip UBSAN. Fall back to the first slot the way the cleaner shader path already does, and stop taking the address before the ring type check that makes it relevant. Cc: stable@vger.kernel.org Signed-off-by: Xiang Liu Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher commit 40ba09e11188d1b7f79d51fc28aca5ea45e0c138 Author: Sunday Clement Date: Thu Aug 6 10:59:34 2026 -0400 drm/amdkfd: Reject zero-sized AQL queue allocations after size halving KFD_IOC_ALLOC_MEMORY_OF_GPU with flag KFD_IOC_ALLOC_MEM_FLAGS_AQL_QUEUE_MEM and size=1 triggers the AQL wraparound workaround (size >>= 1), reducing size to 0. The resulting zero passes through PAGE_ALIGN(0) = 0 without validation, bypassing the per-process VRAM quota check in reserve_mem_limit() (vram_used + 0 > vram_available is always false). The fix adds post-halving zero-size validation in the primary allocation path (amdgpu_amdkfd_gpuvm.c). The check happens after size halving but before reserve_mem_limit(), and uses err_alignment_size error path to properly clean up the allocated kgd_mem structure and mutex. Cc: stable@vger.kernel.org Signed-off-by: Sunday Clement Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher commit 2ee9836545e690c9e66ec203445d7705959fd7a8 Author: David Rosca Date: Thu Aug 20 16:32:51 2026 +0200 drm/amdgpu: Fix VCE 3 ring align_mask The largest frame is 20 dwords, so 0xf mask is too small. This was always wrong, but we were lucky with the VCE_CMD_END commands inserted after fence and vm_flush. Fixes: 8897ea8c761b ("drm/amdgpu: Implement insert_end for VCE 3") Cc: stable@vger.kernel.org Acked-by: Alex Deucher Signed-off-by: David Rosca Signed-off-by: Alex Deucher commit fb62f7f031155fe6c1095d2fc921654ad51f87c2 Author: David Belanger Date: Fri Aug 14 13:26:17 2026 -0400 drm/kfd: Add CU occupancy support to GFX12.1 Port changes from GFX9 to GFX12.1 mostly as-is. Minor changes to register access code. Assisted-by: Claude:Sonnet 4.6 Signed-off-by: David Belanger Reviewed-by: Sreekant Somasekharan Signed-off-by: Alex Deucher commit fb1e65a80dd9167e8dfdfdfef178d1d012d8bb58 Author: David Belanger Date: Fri Aug 14 13:25:56 2026 -0400 drm/kfd: Add CU occupancy support to GFX12 Port changes from GFX9 to GFX12 mostly as-is. Minor changes to register access code. Assisted-by: Claude:Sonnet-4-6 Signed-off-by: David Belanger Acked-by: Alex Deucher Reviewed-by: Sreekant Somasekharan Signed-off-by: Alex Deucher commit 290e0be2abb7d9f1473d12ef2ed3220b071c42c3 Author: David Belanger Date: Fri Aug 14 12:57:18 2026 -0400 drm/kfd: Add CU occupancy support to GFX11 Port changes from GFX9 to GFX11 mostly as-is. Minor changes to register access code. Assisted-by: Claude:Sonnet-4-6 Signed-off-by: David Belanger Acked-by: Alex Deucher Reviewed-by: Sreekant Somasekharan Signed-off-by: Alex Deucher commit 6760f5cb12d2366ddd58a2d8637f7583d73f596b Author: Bob Zhou Date: Wed Aug 19 14:23:49 2026 +0800 drm/amdgpu: avoid force-completing uninitialized UVD rings uvd_v7_0_sw_init() does not initialize the UVD decode ring for an SR-IOV VF. However, amdgpu_uvd_resume() unconditionally force-completes the decode ring when restoring its fence sequence. Skip fence completion when the fence driver is not initialized. Fixes: 0a33b11d26c6 ("drm/amdgpu: mark force completed fences with -ECANCELED") Cc: stable@vger.kernel.org Signed-off-by: Bob Zhou Acked-by: Leo Liu Acked-by: Frank Min Signed-off-by: Alex Deucher commit d36fbf82189319e9af564c93900d30e55e87e7e0 Author: Jesse Zhang Date: Fri Aug 14 15:01:44 2026 +0800 drm/amdgpu/userq: lock and validate wptr BOs before reading their GPU offset on restore On resume, amdgpu_userq_vm_validate_and_restore_queue() updates each queue's wptr GPU address via amdgpu_bo_gpu_offset(). WPTR BOs are VM-mapped, but each BO has its own reservation object and is not implicitly covered by the VM validation path here. This can leave offset reads without proper BO locking/placement state and trigger WARN_ONs. ------------[ cut here ]------------ WARNING: amdgpu_object.c:1486 at amdgpu_bo_gpu_offset+0x75/0xa0 [amdgpu], CPU#3: kworker/3:1/116 Workqueue: events amdgpu_userq_restore_worker [amdgpu] RIP: 0010:amdgpu_bo_gpu_offset+0x75/0xa0 [amdgpu] Call Trace: amdgpu_userq_vm_validate_and_restore_queue+0x629/0x960 [amdgpu] amdgpu_userq_restore_worker+0xa6/0x180 [amdgpu] process_scheduled_works+0xa6/0x460 worker_thread+0x13c/0x290 kthread+0xfb/0x140 ret_from_fork+0x1b6/0x2b0 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- ------------[ cut here ]------------ WARNING: amdgpu_object.c:1485 at amdgpu_bo_gpu_offset+0x9a/0xa0 [amdgpu], CPU#2: kworker/2:1/127 Workqueue: events amdgpu_userq_restore_worker [amdgpu] RIP: 0010:amdgpu_bo_gpu_offset+0x9a/0xa0 [amdgpu] Add each queue's WPTR BO to the drm_exec ww context and validate it to its allowed placement before the later offset update. v2: - Clarify that WPTR BOs are VM-mapped (fix incorrect "not part of VM" wording). (Christian) - Describe both parts of the fix: lock BO reservations in drm_exec and validate BO placement before offset reads. Acked-by: Alex Deucher Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher commit aef2ca9353c2f26dbacfb3b8e6f33fecfbf2e67d Author: Prike Liang Date: Wed Aug 19 15:23:56 2026 +0800 drm/amdgpu/mes: fix the inconsistent indenting for mes_userq_map() Fix the inconsistent indenting warning for mes_userq_map(). Fixes: d0827dda8fa7 ("drm/amdgpu/mes: refactor the amdgpu_mes_alloc/free_proc|gang()") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202608190252.8XCa0HqR-lkp@intel.com/ Signed-off-by: Prike Liang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher commit 5bb489b333237c1bf63a891a4362986253a0060a Author: Mohamed Ahmed Date: Tue Aug 25 04:14:06 2026 +0400 drm/nouveau/gsp: fix vblank interrupts on GB20x The GSP path programs per-head timing (vblank) interrupts the same way on every generation. NVD5.0 (GB20x) reworked the FE interrupt frontend around four message-based kernel vectors (high latency, low latency, PMU, and GSP) and moved RM head-timing interrupts to the dedicated low-latency vector: - The enable is NV_PDISP_FE_RM_INTR_EN1_HEAD_TIMING, 0x611ef0 + head*4 (570.144 kernel_head_0501.c, renamed kernel_head_0502.c from 575.51.02 on, and v05_01 dev_disp.h). - The vector is reported as a separate interrupt table entry, MC_ENGINE_IDX_DISP_LOW (intr_gb202.c, intrCacheDispIntrVectors). - The vector must be re-armed through NV_PDISP_FE_INTR_RETRIGGER(1) at 0x611f34 after servicing (kdispServiceInterrupt -> kdispIntrRetrigger_v05_01). The event latch (0x611800), per-head status (0x611c00), and dispatch summary (0x611ec0) the interrupt handler uses are unchanged on GB20x (kheadReadPendingVblank_v03_00 and kheadResetPendingLastData_v03_00 remain for DISPv0502+). On GB20x the old code enables head timing onto the legacy vector, leaves its handler there, and never re-arms the message-based vectors. Page flips still complete (nv50 sends those events from the commit path), so the desktop looks fine while DRM vblank waits and vblank sequence queries are affected. Supply GB20x vblank enables and an interrupt handler that re-arms the vector after servicing through gb202_gsp_disp, translate the low-latency interrupt table entry as a second NVKM_ENGINE_DISP instance, and add a gsp.intr_low_latency flag so r535_disp_oneinit() attaches the handler to that instance. GB20x was the last cross-file user of the TU1xx vblank enables, so make those static and drop their head.h prototypes. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-9-mohamedahmedegypt2001@gmail.com commit 9421dfe912e55360e6b9301a110acb00df7e7320 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:05 2026 +0400 drm/nouveau/disp: fix head state readback on GB20x The GSP path reads armed head state and the RG scanout position through gv100_head_state() and gv100_head_rgpos() on every generation. gv100_head_state() reads the core channel's state mirror at a 0x400 per-head stride, which NVD5.0 (GB20x) doubled. Per NVIDIA's published CA7D class header every HEAD_SET method sits at 0x2000 + head * 0x800, while the mirror bases are unchanged (assembly at 0x680000, armed at +0x8000, per OpenRM's v03_00 channel-user-base HAL which is still used on DISPv0502). Add gb202_head_state(), the same readback at the 0x800 stride, and a gb202_gsp_head table to supply it. gv100_head_rgpos() is kept. The RG registers keep their per-head 0x800 stride on NVD5.0, and OpenRM's kdispReadRgLineCountAndFrameCount_v03_00 still reads NV_PDISP_RG_DPCA on DISPv0502. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-8-mohamedahmedegypt2001@gmail.com commit 39fd4b742720c68da8695ee1ffa85c5fea4f8e11 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:04 2026 +0400 drm/nouveau/gsp: use per-version DP_CONFIG_STREAM params on r570 firmware NVIDIA removed the deprecated actualPclkHz/linkClkFreqHz fields and the whole Legacy{activeCnt, activeFrac, activePolarity, mvidWarEnabled, MvidWarParams} block from the SST sub-struct of NV0073_CTRL_CMD_DP_CONFIG_STREAM_PARAMS between the 535 and 570 releases (compared in OpenRM tags 535.113.01 vs 570.144), shrinking the struct. Everything nouveau writes sits at identical offsets in both layouts except the trailing SST.bEnableAudioOverRightPanel (written as zero), but the size is wrong on r570, which means r535_sor_dp_sst() and r535_sor_dp_vcpi() are sent with an incorrect size. Route the .sst/.vcpi IOR functions through nvkm_rm_api_disp the same way bl_ctrl and dp.get_caps/set_indexed_link_rates already are. Keep the existing implementation for r535 and add an r570 implementation built against the 570.144 layout, which already exists in r570/nvrm/disp.h but was unused until now. Also add the NV0073_CTRL_CMD_DP_CONFIG_STREAM define that was missing from the layout. Other DP controls sent through shared r535 code did not change layout between the tags. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-7-mohamedahmedegypt2001@gmail.com commit 764deff8450c9a83e335c17c32ea258ec25bb71e Author: Mohamed Ahmed Date: Tue Aug 25 04:14:03 2026 +0400 drm/nouveau/disp: fix HDMI GCP AVMute register offsets on GB20x The GSP path brackets audio enablement with a General Control Packet AVMute toggle. r535_sor_hdmi_audio() calls the gsp.hdmi_gcp hook, which every chip so far serves with tu102_sor_hdmi_gcp() and the legacy GCP unit at 0x6f00c0/0x6f00cc. On GB20x the SF packet units were compacted and the old generic and VSI units are gone (ACR keeps slot 2) and the GCP unit moved from slot 3 to slot 1 (control 0x6f0040 and subpack 0x6f004c from NVIDIA's published clc971.h. The same offsets are also used by OpenRM's hdmiWriteGeneralCtrlPacketC871() on these chips). The old addresses are reserved on GB20x, so the AVMute writes were silent no-ops and mitigated only by the equivalent GCP r535_sor_hdmi_audio() already sends through the SET_OD_PACKET RM control. Add a GB20x GCP writer using the new offsets and hook it into gb202_gsp_disp, keeping the direct MMIO path in sync with the hardware as on earlier chips. Only SB0 (the AVMute bit) is written. On NVD5.0 the subpack register also carries SB1_CTRL (bit 24), which selects where the deep-color CD/PP fields are generated (hardware or from the driver, with the default being HW). hdmiWriteGeneralCtrlPacketC871() likewise writes only SB0-SB2. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-6-mohamedahmedegypt2001@gmail.com commit 92f09dcb4e8473ab25764e950994ab7b6abce6dd Author: Mohamed Ahmed Date: Tue Aug 25 04:14:02 2026 +0400 drm/nouveau/disp: fix HDMI vendor infoframes on GB20x The GSP path reuses the GV100 direct-MMIO infoframe writers on every chip. On GB20x that is only half right as while the legacy SF AVI unit is unchanged, the legacy VSI unit at 0x6f0100 was removed, so gv100_sor_hdmi_infoframe_vsi() writes into a reserved area and no vendor infoframe ever reaches the HW. This affects HDMI-VIC signalling which can impact some 4K modes for legacy HDMI 1.4 sinks. GB20x (NVDisplay 5.0+) reorganised the SF HDMI packet units. Per NVIDIA's published C971/CA71 DISP_SF_USER class headers, only three legacy units remain (AVI at +0x000, GCP at +0x040, ACR at +0x080), and vendor infoframes must instead be sent through the shared generic infoframe units at +0x130, whose 9-dword packet slots are loaded through the shared data port at +0x3f0/+0x3f4. Add a VSI writer using the same programming sequence OpenRM uses on these chips (nvhdmipkt_C971.c, programAdvancedInfoframeC971()): disable the unit and wait for it to idle, clear the SENT status, write the packet through the data port with a zero inserted in HB3 after the three header bytes, then enable the unit for every-frame transmission during vblank. Generic unit 1 is used for the VSI, matching the slot assignment in NVIDIA's nvkms (NVHDMIPKT_TYPE_SHARED_GENERIC2, unit 0 is reserved for extended metadata packets and unit 2 for the HDR DRM infoframe, if those are wired up later). GB20x so far shared GA10x's display entry point. Give it its own, gb202_disp_new(), with a gb202_gsp_disp table that supplies the VSI writer to the GSP path and otherwise carries the same hooks as GA10x. The following fixes fill in the rest of the GB20x differences there. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-5-mohamedahmedegypt2001@gmail.com commit 9886aad51f4b5e7082209a153e404bcd8101356c Author: Mohamed Ahmed Date: Tue Aug 25 04:14:01 2026 +0400 drm/nouveau/disp: route GSP-RM display MMIO through nvkm_disp_func hooks The GSP-RM display code in rm/r535/disp.c borrows a few register-programming routines from engine/disp (the head-timing interrupt handler, vblank enables, armed head state and scanout position readback, the AVI/VSI infoframe writers and the GCP AVMute write) and so far picked them by name, which means it has to know which chip it runs on the moment a generation changes any of them. Give nvkm_disp_func a .gsp table that each chip fills with exactly those hooks, add tu102_gsp_disp (TU1xx) and ga102_gsp_disp (GA10x onwards) carrying the current functions, hand them to r535_disp_new() instead of the full hardware tables, and make rm/r535/disp.c call through the hooks. The head hooks are a whole nvkm_head_func, so r535_head goes away and the chip's own table is handed to nvkm_head_new_(). r535_sor_hdmi gets infoframe forwarders, r535_sor_hdmi_audio() calls the GCP hook, and the interrupt handler comes from the table. The tables are per chip even though the two currently coincide, so a generation that changes a hook only touches its own file. rm/r535/disp.c no longer contains chip-specific register code, and a new display generation only has to provide its own table. No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-4-mohamedahmedegypt2001@gmail.com commit eb1ffc3dc72d379a41e367a44b99fb61a15bf8ba Author: Mohamed Ahmed Date: Tue Aug 25 04:14:00 2026 +0400 drm/nouveau/disp: move the GSP HDMI GCP AVMute write to engine/disp r535_sor_hdmi_audio() pairs two RM controls (a SET_OD_PACKET carrying the same General Control Packet, and the audio mute-stream toggle) with a direct write of the GCP AVMute bit through the SF GCP unit. The controls are RM and stay, but the direct write is register programming and moves next to the other per-chip display code as tu102_sor_hdmi_gcp(). No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-3-mohamedahmedegypt2001@gmail.com commit c6659e0ffc19b4ef0b3273c185cb8409a154eada Author: Mohamed Ahmed Date: Tue Aug 25 04:13:59 2026 +0400 drm/nouveau/disp: move GSP head-timing ISR and vblank helpers to tu102.c The GSP-RM display code in rm/r535/disp.c owns a handful of direct MMIO routines: the head-timing (vblank) interrupt handler and the per-head vblank enable/disable. They program display registers, not RM, so they belong with the rest of the per-chip register code in engine/disp/. Move them to tu102.c (Turing is the first GSP-capable generation) as tu102_disp_intr() and tu102_head_vblank_get()/put(), exported for rm/r535/disp.c, which keeps calling them by name for now. No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-2-mohamedahmedegypt2001@gmail.com commit 554ab79cfd104fbd76f3be82b0dfa8fc2b324799 Author: Lyude Paul Date: Tue Apr 28 23:03:40 2026 -0400 drm/nouveau/disp/r535: Add scanline position support + head state support That's right! It looks like this never actually got finished, something which I just noticed today when I saw this fun message spamming one of my test machine's kernel logs when enabling display debug output for nouveau: [drm:drm_crtc_vblank_helper_get_vblank_timestamp_internal] crtc 0 : scanoutpos query failed. So it looks like we've been falling back to DRM's core fallback for a while now, whoops. So, while it seems that we do have the option of doing this through GSP - that doesn't seem like a great idea. Mainly because reading this from GSP would involve a lot more latency then we should have for vblank handling due to the RPC communication. So instead of implementing that, just use gv100_head_state and gv100_head_rgpos for implementing .state and .rgpos. It seems to work perfectly fine! Fixes: 9e9944449023 ("drm/nouveau/disp/r535: initial support") Cc: Ben Skeggs Cc: Dave Airlie Cc: Timur Tabi Cc: Ben Skeggs Cc: James Jones Cc: Faith Ekstrand Cc: Suraj Kandpal Cc: Lyude Paul Cc: Aaron Kling Cc: Danilo Krummrich Cc: Zhang Enpei Cc: # v6.7+ Signed-off-by: Lyude Paul Signed-off-by: Dave Airlie Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260429030348.3930866-1-lyude@redhat.com (cherry picked from commit 804cb093b245c752f15d17186e0d404f10303593) Signed-off-by: Lyude Paul commit 45c13f3f9e3bb15fd89ff2864c6f627a3b4b4229 Merge: f2ed28dce9396b e088ffa9a00eaa Author: Linus Torvalds Date: Tue Aug 25 14:21:47 2026 -0700 Merge tag 'hwlock-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull hwspinlock updates from Bjorn Andersson: "Propagate single-lock registration failures from radix_tree_insert(), making caller sanity checks effective. Update the hwspinlock MAINTAINERS repository URL to the current remoteproc tree" * tag 'hwlock-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: hwspinlock: propagate errno when registering single lock MAINTAINERS: Update remoteproc repo url for hwspinlock commit f2ed28dce9396b94097376643527112228c2eb83 Merge: fc710de0dd25ed 786439ad58763e Author: Linus Torvalds Date: Tue Aug 25 14:13:38 2026 -0700 Merge tag 'rpmsg-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull rpmsg updates from Bjorn Andersson: "Fix a GLINK endpoint teardown deadlock during driver detach and order SMEM FIFO reads after the remote-updated availability check. Prevent duplicate rpmsg character endpoint teardown when remoteproc shutdown races with RPMSG_DESTROY_EPT_IOCTL. Replace unsafe string and sysfs formatting helpers, and correct the unregister_rpmsg_driver() return value documentation" * tag 'rpmsg-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: rpmsg: glink: smem: order FIFO read after availability check rpmsg: glink: fix deadlock in endpoint destroy during driver detach rpmsg: char: Check for ongoing chrdev destroy rpmsg: glink: Replace strcpy() with strscpy() rpmsg: core: Fix incorrect return value documentation rpmsg: Replace sprintf() with sysfs_emit() in sysfs show commit fc710de0dd25ed50a087833b4171eb1a46737a9e Merge: 73ae59e975966d bb840ea69347af Author: Linus Torvalds Date: Tue Aug 25 14:03:31 2026 -0700 Merge tag 'rproc-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux Pull remoteproc updates from Bjorn Andersson: "Add a remoteproc driver and binding for AMD MicroBlaze/V soft cores executing from dual-port BRAM, with clock and reset control and support for firmware without a resource table. Introduce a generic Qualcomm PAS service with SCM and OP-TEE backends, and migrate the PAS, MSS, and WCNSS remoteproc drivers to it. Add Nord ADSP and CDSP support, Eliza CDSP support, Maili ADSP/CDSP bindings, and late-attach SoCCP support for Kaanapali, Hawi, Maili, and Glymur. Enable BAM-DMUX child devices for PAS modems and fix PAS memory protection, handover, shutdown, and resource lifetime handling. Harden remoteproc lifecycle handling by attaching asynchronously, stopping crashed processors, synchronizing crash work with removal, and forcing shutdown before device resources are released. Reallocate resources during attach recovery and fix several reference and error-path leaks. Add Xilinx R5 crash detection and move RPU start and stop sequencing into the platform firmware driver. Consolidate write-combining carveout mapping callbacks, use correct I/O-memory accessors, and share optional ELF resource-table handling across drivers. Convert the TI Wakeup M3 binding to DT schema, correct Qualcomm and generic remoteproc bindings, and harden resource-table iteration against signed-offset out-of-bounds accesses" * tag 'rproc-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (60 commits) remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() remoteproc: replace BSD blurb with SPDX identifier in rsc_table.h remoteproc: replace BSD blurb with SPDX identifier in remoteproc.h remoteproc: fix coding style issues in remoteproc.h MAINTAINERS: add rsc_table.h to remoteproc entry remoteproc: qcom: pas: Add Nord ADSP and CDSP support dt-bindings: remoteproc: qcom,nord-pas: Document Nord PAS remoteproc: qcom: pas: Drop unused dtb_mem_region field remoteproc: qcom: pas: Map/unmap subsystem region before auth_and_reset remoteproc: qcom: pas: Fix the PAS context creation placement remoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id check remoteproc: qcom: annotate mem_region fields with __iomem arm64: dts: qcom: eliza: Add fallback compatible for ADSP remoteproc dt-bindings: remoteproc: qcom,milos-pas: Move Eliza ADSP to SM8550 schema remoteproc: qcom: pas: Add Eliza CDSP support dt-bindings: remoteproc: qcom,sm8550-pas: Add Eliza CDSP compatible remoteproc: qcom: q6v5: Request shutdown if crash is triggered host-side remoteproc: Force shutdown during device removal remoteproc: Prevent crash handling to race with rproc_del() remoteproc: Allow shutdown of crashed processors ... commit 1b0bab4a873f1034c27573cfc613394cff7e0a5b Author: Miguel Ojeda Date: Sun Aug 23 21:35:29 2026 +0200 rust: kbuild: disambiguate `zerocopy_derive` for `rusttest` The `rustc-dev` components for Rust 1.82.0 through 1.87.0 include a precompiled `zerocopy_derive` procedural macro in the sysroot. This range includes Rust 1.85.0, our minimum supported version. This makes `rusttest` fail because the compiler finds both the sysroot copy and the copy built in `rust/test`: error[E0464]: multiple candidates for `dylib` dependency `zerocopy_derive` found --> rust/kernel/prelude.rs:70:9 | 70 | pub use zerocopy_derive::{ | ^^^^^^^^^^^^^^^ | = note: candidate #1: .../lib/rustlib/x86_64-unknown-linux-gnu/lib/libzerocopy_derive-54d2b38896fa6bc5.so = note: candidate #2: .../rust/test/libzerocopy_derive.so Commit fe39a233ea52 ("rust: kbuild: disambiguate `zerocopy` for `rusttest`") fixed the equivalent ambiguity for `zerocopy`. Thus point to the dependency explicitly in this case too. Cc: Antoni Boucher Cc: stable@vger.kernel.org Fixes: 506054980429 ("rust: zerocopy-derive: enable support in kbuild") Link: https://patch.msgid.link/20260823193529.156066-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda commit 73ae59e975966d24e32926247ddb45a537ebe184 Merge: 7bb6284aa7b3c3 a7d28aa0e9b2c9 Author: Linus Torvalds Date: Tue Aug 25 12:27:41 2026 -0700 Merge tag 'erofs-for-7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs Pull more erofs updates from Gao Xiang: - Fix up the EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS default logic so that "make savedefconfig" won't write the needless default value to the defconfig file - Add support for SEEK_{HOLE,DATA}, splice() as well as enable large folios in inode_share mode - Fix z_erofs_gbuf_growsize() after the previous buffer resizing fails * tag 'erofs-for-7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs: erofs: simplify z_erofs_gbuf_growsize() erofs: skip sufficiently large global buffers when resizing erofs: support large folios in inode_share mode erofs: support splice() in inode_share mode erofs: support SEEK_HOLE/SEEK_DATA in inode_share mode erofs: Fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS default logic commit 79a57e48822a88f082a4dadb366abaf3c0988b5d Author: Nathan Chancellor Date: Wed Aug 12 18:17:22 2026 -0700 thermal/drivers/qcom-spmi-mbg-tm: Add module namespace import for IIO_CONSUMER Commit ebf1d03dab96 ("iio: inkern: Use namespaced exports") in the iio tree restricts certain exported core functions that a driver added in commit c3dce117333c ("thermal/drivers/qcom: Add support for Qualcomm MBG thermal monitoring") from the thermal tree uses, causing modpost to warn (or error without CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS): ERROR: modpost: drivers/thermal/qcom/qcom-spmi-mbg-tm.ko: module uses symbol 'devm_iio_channel_get' from namespace 'IIO_CONSUMER', but does not import it. ERROR: modpost: drivers/thermal/qcom/qcom-spmi-mbg-tm.ko: module uses symbol 'iio_read_channel_processed' from namespace 'IIO_CONSUMER', but does not import it. Add the IIO_CONSUMER namespace import to clear up the error. Signed-off-by: Nathan Chancellor Acked-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://patch.msgid.link/20260812-qcom-spmi-mbg-tm-ns-modpost-error-v1-1-d849390d2714@kernel.org Signed-off-by: Rafael J. Wysocki commit aa4174127fe63f3b6521529d0f1d66470ae4d8ad Author: Rafael J. Wysocki Date: Mon Aug 24 19:53:00 2026 +0200 Revert "thermal/core: Allocate the thermal class dynamically" This reverts commit 34f54003643e ("thermal/core: Allocate the thermal class dynamically") that went against driver core changes aiming at the elimination of class_create() [1]. No intentional functional impact. Link: https://lore.kernel.org/linux-pm/2026082411-flask-rewire-434f@gregkh/ Signed-off-by: Rafael J. Wysocki Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/4761117.LvFx2qVVIh@rafael.j.wysocki commit 1087c29d9c5f0ca6793ad5b117943b45e000364b Author: Rafael J. Wysocki Date: Mon Aug 24 19:52:08 2026 +0200 Revert "thermal/core: Use the thermal class pointer as init guard" This reverts commit 499274d078d0 ("thermal/core: Use the thermal class pointer as init guard") because it depends on another commit that needs to be reverted. Signed-off-by: Rafael J. Wysocki Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/6301222.lOV4Wx5bFT@rafael.j.wysocki commit 7bb6284aa7b3c369b41e7f33fcbe193161f008e7 Merge: 70f5376dbdefa6 76671054f9a1ff Author: Linus Torvalds Date: Tue Aug 25 11:48:04 2026 -0700 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull kvm updates from Paolo Bonzini: "ARM64: - Add support for 'slot' based PMU events, paired with new UAPI that compels the user to select a specific PMU implementation - Lazy save/restore of vCPU state for pKVM, along with various fixes and cleanups to the management of vCPU state between the untrusted host and pKVM hypervisor - Disable traps of EL1 registers for nested hypervisors when FEAT_NV2p1 is present, guaranteeing that EL2-specific register bits are stateful in the EL1 counterpart - Leverage FEAT_NV3 to avoid unnecessary ERET/TLBI traps when the scope of those instructions remains 'in host' (i.e. L1 kernel/userspace) - Pile of fixes for the management of the VNCR pseudo-TLB, such as under-invalidations and races with concurrent TLBIs on other vCPUs - Consolidate the non-protected and pKVM view of ICH_VTR_EL2 to a runtime-patched constant, allowing the same data to be shared with pKVM prior to dropping host privileges - Considerable pile of LLM-assisted fixes around the shop but mostly in the VGIC, our in-kernel generator of bugs (and sometimes interrupts) LoongArch: - Advertise already-supported capabilities - Some bug fixes about timer and MMIO - Some hardening about interrupt injection - Replace kvm_err() with kvm_pr_unimpl() - Add FPU/LSX/LASX test cases for selftests RISC-V: - Svadu/Zicfiss/Zicfilp FWFT support for Guest - Use try_cmpxchg for IMSIC MRIF RMW - More arch-specific tracepoints in KVM RISC-V - Eager page splitting when enabling dirty logging - Optimize hfence request handling for SMP Guests - Improve dirty log clearing by skipping zero bits in mask - Guard HFENCE range loops against overflow - CPU PM notifiers in KVM RISC-V for non-retentive idle states - Fix kernel-mode vector context save/restore for Guest s390: - Fixes for vfio-ap - Fixes for the gmap rework - Fixes for vsie - AI triggered fixes all over - diag9c tracing - code move preparation for the additional arm64 support - enable CONTEXT_ANALYSIS x86: - Perform spring cleaning on x86.{c,h} and asm/kvm_host.h, by adding regs.c (the kvm_cache_regs.h => regs.h is already applied) and msrs.{c,h}, and moving relevant code out of x86.c - Split kvm_mmu in three parts, respectively to describe the format of page tables, walking the guest page tables and building the page tables. Always use the same page table walker kvm->arch.gva_walk as the entry point to convert a guest's virtual address, where the previous code used two different kvm_mmu structs depending on whether the walk included nested EPT/NPT or not. Make page fault vmexits reuse the permission checking machinery that is used for guest page faults. This is both a cleanup and a baby step towards supporting XS/XU memory permissions - Document some of the "fun" gotchas with the APIC base when creating IRQCHIPs on x86 - Remove a defunct masterclock update from kvm_xen_shared_info_init(). It could result in incorrect kvmclock due to triggering an unnecessary switch to/from masterclock mode - Skip Xen runstate time updates if time has effectively gone backwards, so that the guest doesn't report 100% steal time for a very, very long time - Drop KVM's runtime updates of the Xen PV timing CPUID leaf, as KVM was updating the wrong sub-leaf, and upstream KVM will soon provide all the information needed by userspace to populate the CPUID field itself - Fix a bug where KVM would walk a newly created rmap without holding the rmap lock (or mmu_lock) during aging - Fix a bug where aging TDP MMU SPTEs could clobber FROZEN SPTEs - Fix a variety of #DB priority bugs - Fix a class of races related to enabling Hyper-V emulation on a vCPU after the vCPU is visible to the rest of KVM - Use static calls for nested virtualization ops - Move more KVM-internal code out of x86's kvm_host.h - Enumerate support for a variety of Zhaoxin instructions that don't require explicit virtualization - Fix missing EFER validation bugs, including in the KVM_SET_SREGS* path - Harden kvm_vcpu_map() against double-mapping and thus leaking references - Misc fixes and cleanups, e.g. for largely benign syzkaller splats x86 (Intel): - Zero a vCPU's entry in VMX's Posted Interrupt Descriptor table used for IPI virtualization when the vCPU is freed, to fix a use-after-free where hardware will write to a freed vCPU's PID - Service local TLB flushes on a failed nested VM-Enter to fix a bug where KVM could miss a TLB on a future, successful VM-Enter with the same L2 VPID - Cap the maximum value shoved into the VMX Preemption Timer to workaround an erratum that affects all existing Intel CPUs that support CPUID 0x15 - Fix VPID virtualization bugs where KVM would fail to flush hardware TLBs - Harden the TDX "populate" ioctls against bad input, and to prepare for supporting in-place private<=>shared conversion x86 (AMD): - Forcefully invalidate SNP VMSA pages if their backing guest_memfd page is zapped/invalidated, e.g. due to a PUNCH_HOLE in response to a Page-State Change request - Remove a dying VM from the GA Log notifier list before the VM is actually destroyed, to fix a potential use-after-free - While FOLL_WRITE was needed in the past to trigger CoW unsharing, nowadays FOLL_LONGTERM does that already even without FOLL_WRITE, and in fact, get_user_pages() actually disallows FOLL_WRITE together with FOLL_LONGTERM. So don't pass FOLL_WRITE when registering encrypted memory regions, i.e. when pinning SEV/SEV-ES guest memory, to fix a regression with file-backed memory introduced by KVM's (correct) usage of long-term pins (This was reviewed by mm maintainers; for more information, see commit ee1a586dd1fa "KVM: SEV: Drop FOLL_WRITE for encrypted region registration") - Allocate full pages for SEV/SEV-ES {DE,EN}CRYPT ops on SNP-enabled hosts to fix a data corruption issue due to the PSP driver assigning to-be-written pages to firmware (as required by the SNP specs) - Unconditionally intercept ICBEP so that KVM generates the correct guest RIP when handling an ICEBP-induced TASK_SWITCH #VMEXIT - Harden the SNP "populate" ioctls against bad input, and to prepare for supporting in-place private<=>shared conversion Generic: - Remove kvm_debugfs_dir if kvm_init() fails after creating KVM's debugfs - Add a per-VM bitmap to track which vCPU IDs have been "claimed" but for which the vCPU isn't yet online, and use the bitmap to reject duplicate IDs before calling into arch code. This allows arch code to consume vcpu_id without having to worry about cross-vCPU clobbering (at least s390 and x86 have had related bugs) - Rework the so called "prepare" and "invalidate" guest_memfd hooks to prepare for in-place private<=>shared conversion, and clean up a few warts along the way Selftests: - Automatically allocate a full page for L2 guest stacks on x86 instead of requiring test-specific L1 guest code to carve out a portion of the L1 stack for L2 usage, and to ensure the L2 stack also adheres to the x86-64 calling convention ABI - Add a selftest to verify {Guest,Host}-Only behavior in x86's mediated PMU - Clean up nested SVM's handling of GPRs on L2<=>L1 transitions, reuse the functionality for nested VMX, and drop the ucall hack that was fudging around the lack of GPR switching on nVMX - Add a stress test to verify KVM doesn't clobber/drop #PF state, e.g. CR2, across save/restore, including when L2 is active - Add a test to verify KVM_CREATE_VM accepts exactly what is reported by KVM_CAP_VM_TYPES - Misc selftests fixes and cleanups - Fix several issues with seeding the pRNG, and rework the pRNG APIs to that the pRNG can be sanely used in host code, not just guest code - Add an IRQ test to validate virtual IRQ deliverty for IRQs wired up via KVM_IRQFD + KVM_SET_GSI_ROUTING, with optional support for triggering IRQs via writes to an assigned VFIO device - Add syscall wrappers to assert success on a variety of pthreads and CPU affinity APIs - Set vCPU pthread affinity as early as possible to reduce contention issues that were surfaced by PREEMPT_LAZY, which result in runtimes of over a minute on large hosts, versus the expected ~5 seconds - Rework the PMU counters test to run each testcase using a single VM with many vCPUs for each sub-testcase, instead of using a unique VM for each sub-testcase. This cuts the runtime by ~20x Miscellaneous: - MAINTAINERS updates for vfio-ap, guest_memfd, kvm-x86. Mostly representing the status quo more accurately, but also... welcome David Hildenbrand as guest_memfd reviewer!" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (413 commits) KVM: arm64: Validate GICv5 timer PPIs before claiming ownership KVM: arm64: vgic: Reject out-of-range GICv5 PPI IDs KVM: arm64: vgic: Prevent speculative SPI array underflow KVM: arm64: vgic: Free gic_kvm_info on initialization failure KVM: arm64: Avoid mismatched accesses to 'struct kvm_nvhe_init_params' s390/vfio-ap: Fix NULL deref in status_show() during queue probe s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove s390/vfio-ap: Fix required lock not held during update of ap_matrix_mdev object s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL s390/vfio-ap: Fix stale do_remove flag across iterations in vfio_ap_mdev_cfg_remove RISC-V: KVM: fix vcpu vector context handling for kernel-mode vector riscv: vector: allow non-preemptible kernel-mode vector with IRQs off riscv: vector: refactor riscv_v_start_kernel_context KVM: s390: gmap: Make prefix handling optional KVM: s390: gmap: Make CMMA optional KVM: s390: gmap: Make storage keys optional KVM: s390: Prepare gmap for a second KVM implementation ... commit 70f5376dbdefa675adec0800e9f21f20a0dc0cbd Merge: f4d50813c0958b 8b0b29fdcb4790 Author: Linus Torvalds Date: Tue Aug 25 10:59:12 2026 -0700 Merge tag 'tty-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull TTY / serial driver updates from Greg KH: "Here is the "big" set of tty and serial driver updates for 7.3-rc1. Not really all that much happened this development cycle for this subsystem, changes in here are: - removal of the ipwireless driver as it's no longer used or needed - new 8250_mxpcie driver added - qcom serial driver updates and additions - vt mode validation addition - lots of other small serial driver updates and additions All of these have been in linux-next for weeks with no reported issues" * tag 'tty-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (97 commits) serial: imx: serialize imx_uart_ports[] lifetime tty: clear cdev pointer after cdev_add() failure tty: skip cdev_del() when no cdev is registered serial: core: clear freed pointers on uart_register_driver() failure serial: core: do fallible allocations before the console can be registered serial: 8250_mxpcie: implement rx_trig_bytes callbacks via MUEx50 RTL serial: 8250_mxpcie: introduce per-port private data structure serial: 8250: allow UART drivers to override rx_trig_bytes handling serial: 8250_mxpcie: add break support for RS485 using MUEx50 features serial: 8250: allow low-level drivers to override break control serial: 8250_mxpcie: support serial interface mode switching serial: 8250_mxpcie: speed up TX using memory-mapped FIFO window serial: 8250_mxpcie: speed up RX using memory-mapped FIFO window serial: 8250_mxpcie: add custom handle_irq callback serial: 8250_mxpcie: offload XON/XOFF flow control to MUEx50 hardware serial: 8250_mxpcie: enable automatic RTS/CTS flow control serial: 8250_mxpcie: enable enhanced mode and program FIFO trigger levels serial: 8250: add Moxa MUEx50 UART port type serial: 8250: split Moxa PCIe serial board support out of 8250_pci serial: qcom-geni: Use geni_se_set_perf_level() for baud rate perf level ... commit 2cf20c4e0f72d523b8673053e7120d092ff1f074 Author: Hui Su Date: Tue Aug 18 18:33:37 2026 +0800 io_uring/waitid: avoid siginfo copy during ring teardown During ring teardown, io_ring_exit_work() cancels outstanding requests from a kworker with a NULL tctx. The waitid cancellation path eventually reaches io_waitid_finish(), which copies the stored siginfo to the userspace pointer supplied with the request. Ring-wide teardown does not run in the task context that submitted the request, so it must not access that task's userspace pointer. Depending on the address and mm state, the copy may fail with -EFAULT, but the uaccess itself is inappropriate from the teardown kworker. Use a no-copy cancellation callback when io_waitid_remove_all() is called without an owning task context. Complete the request with -ECANCELED while releasing the waitid state without touching siginfo. Keep the existing siginfo handling for explicit async cancellation and task-scoped cancellation. Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Cc: stable@vger.kernel.org Signed-off-by: Hui Su Link: https://patch.msgid.link/20260818103336.1922818-3-sh_def@163.com Signed-off-by: Jens Axboe commit 14572de82e5022899e5856008bc9cac97004a88c Author: Hui Su Date: Tue Aug 18 18:33:36 2026 +0800 io_uring/waitid: honor task_work cancellation io_waitid_cb() may run through the fallback task_work path when task_work_add() can no longer queue work to the originating task. The fallback runs from a kworker and io_uring marks such task work as canceled through tw.cancel. io_waitid_cb() currently ignores tw.cancel and calls __do_wait(). waitid is task-context dependent: __do_wait() performs child lookup relative to current, and the retry path also uses current->signal->wait_chldexit. If the callback runs from the fallback kworker, current is therefore not the task that submitted the request. Honor tw.cancel before entering __do_wait(). Complete the request with -ECANCELED and skip the siginfo copy, since canceled task work may run without the submitting task's userspace execution context. Keep the existing siginfo handling for normal waitid completion and explicit cancellation. Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Cc: stable@vger.kernel.org Signed-off-by: Hui Su Link: https://patch.msgid.link/20260818103336.1922818-2-sh_def@163.com Signed-off-by: Jens Axboe commit ba77efee1b95b4ad7559b1cdbe7cd7fa36dca95b Author: Laxman Acharya Padhya Date: Fri Aug 21 16:18:17 2026 +0545 io_uring/query: cap user size passed to copy_struct_to_user io_handle_query_entry() clamps hdr.size for the inbound copy_from_user() but keeps the original user value as usize. copy_struct_to_user() uses that usize and, when it is larger than the kernel result, clear_user()s the trailing bytes. As hdr.size is a __u32, a query can request nearly 4 GiB of zeroing, including on the error path where res_size stays 0. The interface is reachable without a ring via IORING_REGISTER_QUERY. Reject sizes larger than PAGE_SIZE, as recommended for copy_struct_* interfaces. Fixes: c265ae75f900 ("io_uring: introduce io_uring querying") Cc: stable@vger.kernel.org # 6.18+ Signed-off-by: Laxman Acharya Padhya Reviewed-by: Gabriel Krisman Bertazi Link: https://patch.msgid.link/20260821103317.91437-1-acharyalaxman8848@gmail.com Signed-off-by: Jens Axboe commit f4d50813c0958b7d6bc79a7e0a77193372cbfd03 Merge: 29b0977977d7b7 e1e6e541c5c9cf Author: Linus Torvalds Date: Tue Aug 25 10:44:46 2026 -0700 Merge tag 'usb-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB / Thunderbolt updates from Greg KH: "Here is the big set of USB and Thunderbolt driver updates for 7.3-rc1. Lots of driver work for new devices and systems, and many other minor fixes and updates. Included in here are: - Thunderbolt subsystem driver updates and additions - typec driver updates and additions - usb gadget fixes all over the place, seems like people are finally paying attention to these drivers for some reason - xhci driver updates and fixes based on lots of reports - usb-serial driver updates and additions - new device ids - other minor USB driver updates and fixes All of these have been in linux-next for a while with no reported issues" * tag 'usb-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (163 commits) usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind() usb: typec: hd3ss3220: fix VBUS regulator error message usb: usbfs: fix use-after-free of usb_device in usbdev_release() usb: gadget: u_audio: Fix use-after-free on sound card disconnect usb: dwc3: gadget: Fix use-after-free in dwc3_gadget_free_endpoints due to race condition usb: gadget: f_tcm: keep port count until LUN teardown completes usb: usbtest: disable dynamic ID support usb: typec: tcpci: pass correct rx_type to tcpm_pd_receive() USB: c67x00: fix use-after-free in c67x00_add_iso_urb() usb: typec: ucsi: use UCSI_TIMEOUT_MS for sync command completion usb: gadget: snps_udc_plat: clean up PHY on probe deferral usb: gadget: f_tcm: fix deadlock in usbg_make_tpg() usb: dwc2: gadget: Exit partial power down state when changing USB pull-up usb: gadget: f_fs: Fix Use-After-Free in AIO error path usb: gadget: f_fs: Prevent deadlock during ep0 read loop usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed usb: gadget: midi2: remove default configfs groups on teardown usb: gadget: uvc: Fix null pointer dereference in uvcg_video_init() usb: typec: thunderbolt: Disable work before freeing tbt on remove usb: xhci: Handle bogus TRB pointers in Missed Service Error events ... commit 29b0977977d7b77b192e434d1a94628cf006f795 Merge: 93e4b3076b5f2d c6eb4dc5964fdf Author: Linus Torvalds Date: Tue Aug 25 10:16:19 2026 -0700 Merge tag 'staging-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging driver updates from Greg KH: "Here is the big set of drivers/staging/ updates for 7.3-rc1. Nothing major in here at all, just lots of tiny coding style cleanups, refactoring, and minor "fixes" as found by some tools. Included in here - loads of coding style and refactoring in the rtl8723bs wireless driver - minor greybus driver cleanups - minor sm750fb driver cleanups - other even smaller driver cleanups All of these have been in linux-next for a weeks with no reported issues" * tag 'staging-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (186 commits) staging: rtl8723bs: add blank line after declaration staging: rtl8723bs: remove unused enumerations staging: rtl8723bs: use !psta instead of comparison to NULL staging: rtl8723bs: Replace custom RotR1 macro with ror16 staging: rtl8723bs: Remove multiple assignments staging: rtl8723bs: fix several line spaces in wifi.h staging: rtl8723bs: remove redundant goto in rtw_free_xmitframe() staging: rtl8723bs: rename Restore_DM_Func_Flag functions to avoid CamelCase staging: rtl8723bs: rename Save_DM_Func_Flag functions to avoid CamelCase staging: rtl8723bs: wrap line over 100 characters staging: rtl8723bs: remove unnecessary whitespace staging: rtl8723bs: remove extra blank lines in rtw_qos.h staging: rtl8723bs: remove redundant ReadChipVersion8723B wrapper staging: rtl8723bs: remove debug fields from hal_com_data staging: rtl8723bs: remove 'rf_chip' from struct hal_com_data staging: rtl8723bs: remove unused spinlock 'SdioTxFIFOFreePageLock' staging: rtl8723bs: remove unused 'UsbRxHighSpeedMode' from hal_com_data staging: rtl8723bs: hal: remove unused readings from the chip staging: rtl8723bs: remove unused 'bNeedIQK' from struct hal_com_data staging: rtl8723bs: remove unused 'bIQKInitialized ' from hal_com_data ... commit 93e4b3076b5f2d853462b9777d083c77fc0b7b23 Merge: 5f5ef9c407cfdc 8992f32c57607b Author: Linus Torvalds Date: Tue Aug 25 09:38:50 2026 -0700 Merge tag 'char-misc-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc/IIO/etc driver updates from Greg KH: "Here is the big set of char, misc, iio, counter, fpga, and other small driver subsystems for 7.3-rc1. Overall, due to some driver removals we only added a bit more code than removed, which was a nice change. Highlights in this merge request are: - Loads of IIO driver updates and additions - binder driver updates (more on that below...) - Removal of the SGI XP and GRU drivers as they are not used anymore and turn out to be pretty insecure overall - Removal of the obsolete ibmasm driver as it's not being used anymore - Coresight driver updates and additions - Mei driver udpates - Counter driver updates - FPGA driver updates - ICC driver updates - lots and lots of other tiny driver updates to resolve reported issues All of these have been in linux-next for a while" * tag 'char-misc-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (513 commits) iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF iio: adc: pac1921: fix wrong channel used in trigger handler read iio: light: gp2ap002: re-enable irq if runtime suspend fails iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes iio: light: apds9306: fix PM reference leak in apds9306_read_data() iio: gyro: mpu3050: fix sign of raw angular velocity readings iio: srf04: fix pm_runtime handling on probe error path iio: adc: ad4080: configure backend data size iio: adc: adi-axi-adc: add data size support for AD408X backend iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable iio: dac: ad5446: fix OF module device table iio: light: opt4001: Fix reversed GENMASK() arguments in fault count mask iio: light: opt4001: Reject integration times with a non-zero seconds part iio: light: opt4001: Fix incompatible pointer type passed to div_u64_rem() iio: light: opt4001: Fix power down clearing bits of the wrong register iio: light: opt4060: Fix incorrect register name in threshold read error message iio: light: opt4060: Fix pointer type passed to div_u64_rem() iio: light: opt4060: Reject integration times with a non-zero seconds part iio: light: ltrf216a: fix runtime PM reference leak in error path iio: pressure: dps310: fix NULL pointer dereference on ACPI probe ... commit 5f5ef9c407cfdc524a1aaeb4196d933f61ecf21a Merge: 7f22f3a1939e56 85595d3f964825 Author: Linus Torvalds Date: Tue Aug 25 08:59:09 2026 -0700 Merge tag 'bootconfig-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull bootconfig updates from Masami Hiramatsu: - Support build-time command line building for embedded bootconfig - Fix xbc_snprint_cmdline() to render descendant keys when the root has both a value and subkeys, and treats empty subtrees correctly. - Add build-time pipeline using tools/bootconfig -C to render the embedded bootconfig "kernel" subtree into .init.rodata as a cmdline string. - Clean build-time tools/bootconfig from make clean - Add helper to prepend embedded bootconfig cmdline into boot_command_line early before parse_early_param() - Wire early prepend helper in x86 setup_arch() so early_param handlers see values from the embedded bootconfig (currently x86 only) - Avoid duplicating "kernel" keys in setup_boot_config() - Refactor setup_boot_config() to share bootconfig_cmdline_requested() - Document CONFIG_CMDLINE_FROM_BOOTCONFIG usage, requirements, and precedence * tag 'bootconfig-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: init/main.c: use bootconfig_cmdline_requested() for the runtime opt-in bootconfig: skip runtime kernel.* render once prepended early x86/setup: prepend embedded bootconfig cmdline before parse_early_param Documentation: bootconfig: document build-time cmdline rendering bootconfig: add xbc_prepend_embedded_cmdline() helper bootconfig: clean build-time tools/bootconfig from make clean bootconfig: render embedded bootconfig as a kernel cmdline at build time bootconfig: render descendant keys when xbc_snprint_cmdline() root has a value commit 7f22f3a1939e56669b1e5dc9a873ce303f93a1c0 Merge: 9cebfe65044881 a7b842f182d126 Author: Linus Torvalds Date: Tue Aug 25 08:33:43 2026 -0700 Merge tag 'ntfs-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/ntfs Pull ntfs updates from Namjae Jeon: "This contains improvements to compression support, metadata handling, error propagation, and filesystem robustness. New feature: - Add optional read support for Windows System Compression (WOF) Add CONFIG_NTFS_FS_WOF_COMPRESSION and support reading WOF-compressed files through the NTFS page-read path. This includes parsing REPARSE_TAG_WOF, handling resident and non-resident WOF metadata and compressed chunks, and adding kernel-side XPRESS 4K/8K/16K and LZX 32K decompressors. The codecs use a common transparent compression interface shared with LZNT1. WOF support is read-only and disabled unless explicitly enabled. Other changes: - Harden malformed filesystem handling and error paths. Add bounds and consistency checks for mapping pairs, run lengths, MFT locations, update-sequence offsets, non-resident attributes, compressed attributes, index roots, and bitmap scans. Prevent out-of-bounds accesses in decompression, MFT allocation, and index conversion paths, clean up MFT mappings and attribute search contexts on failure, and propagate attribute and inode initialization errors correctly. - Improve compressed-file I/O path. Fix compressed writes on large-page and highmem systems, reuse compression contexts and output workspaces, avoid unnecessary reads for full-unit overwrites, and submit one bio per compressed write unit. Write replacement data before publishing the new mapping, correctly handle zero-filled compressed blocks, and fix initialized-size and folio state updates after compressed writes. - Synchronize resident reads with MFT record updates. - Validate the final EA stream size before modifying existing data, rewrite the stream safely when replacing entries, restore the previous state when metadata updates fail, and remove the EA attribute pair when the last entry is deleted. - Apply Windows filename restrictions only when windows_names is enabled. - Allow index roots to relocate to extent MFT records when the base record lacks sufficient space. - Move non-resident attribute payload data before shrinking its record. - Correct resident-to-non-resident conversion when compression or sparse flags are enabled. - Prepare file allocation and initialized-size updates before buffered or direct I/O submission, and use pagecache_isize_extended() when extending the file size. - Fix highmem and page/folio access in compressed I/O paths by using the correct local mappings and page helpers. - Apply per-file $LXMOD permissions instead of mount masks when available, and prevent unprivileged writes to reserved $LX* attributes - Update the NTFS maintainer mailing list - Small cleanups" * tag 'ntfs-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/ntfs: (52 commits) ntfs: support resident WOF decompression ntfs: add non-resident WOF decompression ntfs: implement codec ops for LZX and XPRESS ntfs: port lzx/xpress decompressors from ntfs-3g-system-compression ntfs: return errors from inode initialization ntfs: parse REPARSE_TAG_WOF ntfs: return errors from ntfs_attr_readall ntfs: add WOF compression config option ntfs: define LZNT1 codec ops under transparent codec interface ntfs: introduce transparent compression codec interface ntfs: reject invalid empty mapping pairs ntfs: fix resource leak in ntfs_new_attr_flags ntfs: validate usa_ofs before preserving the update sequence number ntfs: fix off-by-one page overflow in ntfs_decompress() ntfs: do not update ctime when setxattr fails ntfs: reject invalid MFT LCNs from boot sector ntfs: serialize resident iomap reads with mrec_lock ntfs: verify run length exceeding volume boundary ntfs: allow index root relocation ntfs: validate non-resident attribute offsets ... commit 8c963d1738fdca400082ff5f9d99e083de4f4e70 Author: Daeho Jeong Date: Mon Aug 24 18:53:03 2026 -0700 f2fs: accurately adjust free_sections during free_segment_range In free_segment_range(), MAIN_SECS(sbi) is temporarily reduced by `secs` to restrict block allocation to the safe remaining main area while valid blocks in the truncated range are evacuated by GC. However, FREE_I(sbi)->free_sections tracks the total number of free sections across the whole filesystem. If any sections within the truncated range were already free upon entering free_segment_range(), failing to deduct them from free_sections causes the filesystem to overestimate available free sections in the active, reduced main area. This leads to inconsistent free section accounting during GC data migration and can trigger unexpected allocation failures or assertion errors when space is tight. Fix this by calculating the number of already-free sections in the truncated range, deducting them from free_sections upon entering free_segment_range(), and restoring them on exit. Fixes: b4b10061ef98 ("f2fs: refactor resize_fs to avoid meta updates in progress") Cc: stable@vger.kernel.org Signed-off-by: Daeho Jeong Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim commit 55ba91d4c54ab31ee8387bae40e799de467f8269 Author: Ross Philipson Date: Sat Jul 11 09:01:10 2026 -0700 tpm-buf: Add TPM buffer support header for standalone reuse Extract all the functions and definitions for TPM buffer handling and separate them into their own header. Signed-off-by: Ross Philipson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 3d9e043dab0a038a53a43570f60bbf4b1e27d63f Author: Jarkko Sakkinen Date: Sat Jul 11 09:01:09 2026 -0700 tpm-buf: Memory-safe allocations Decouple kzalloc from buffer creation, so that a managed allocation can be used: struct tpm_buf *buf __free(kfree) buf = kzalloc(TPM_BUFSIZE, GFP_KERNEL); if (!buf) return -ENOMEM; tpm_buf_init(buf, TPM_BUFSIZE); Alternatively, other allocations are also possible (static data, stack, etc) for example: u8 buf_data[512]; struct tpm_buf *buf = (struct tpm_buf *)buf_data; tpm_buf_init(buf, sizeof(buf_data)); This is achieved by embedding buffer's header inside the allocated blob, instead of having an outer wrapper. Reviewed-by: Stefan Berger Signed-off-by: Jarkko Sakkinen Tested-by: Srish Srinivasan Message-ID: <20260522013555.1063716-1-jarkko@kernel.org> Signed-off-by: Ross Philipson commit 065cfba1f4545e5948a2ddc5888a27c7641d5bfc Author: Jarkko Sakkinen Date: Sat Jul 11 09:01:08 2026 -0700 tpm-buf: Remove chip parameter from tpm_buf_append_handle() Remove the TPM driver chip parameter from the function tpm_buf_append_handle(). The chip parameter is only for error logging which can be done with other facilities like WARN(). Message-ID: <20260125192526.782202-11-jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen Signed-off-by: Ross Philipson commit 0b9551c189518544b65000a234277298e931c8f3 Author: Jarkko Sakkinen Date: Sat Jul 11 09:01:07 2026 -0700 tpm-buf: Merge TPM_BUF_BOUNDARY_ERROR and TPM_BUF_OVERFLOW Merge TPM_BUF_BOUNDARY_ERROR and TPM_BUF_OVERFLOW flags into the TPM_BUF_INVALID flag, as their behavior is identical (the only difference being the associated log messages). Message-ID: <20260125192526.782202-11-jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen Reviewed-by: Jonathan McDowell Signed-off-by: Ross Philipson commit 71ab22dbcfb5cf4c99d167a7e0452a40a74a192e Author: Alec Brown Date: Sat Jul 11 09:01:06 2026 -0700 tpm: Remove main TPM header from TPM event log header Allow the TPM event log functionality to be used without including the main TPM driver definitions. Signed-off-by: Alec Brown Signed-off-by: Ross Philipson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 5467ade151973477742af922cc33bb30e816af42 Author: Ross Philipson Date: Sat Jul 11 09:01:05 2026 -0700 tpm: Move platform specific definitions to the new PTP header These are definitions for TPM 2.0 interface and interactions with the platform as defined in the TCG specification: These definitions are located here in a separate file to avoid conflicts with vendor specific TIS/FIFO definition (e.g. STMicroelectronics, Infineon Technologies, etc). This allows the TCG defined TIS/FIFO interface to be in a public header while the former chip specific implementations contain their own definitions. TPM 1.x family chips that adhere to the TCG specifications use the TIS/FIFO interface as defined here. TCG PC Client Platform TPM Profile (PTP) Specification - https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/ Co-developed-by: Daniel P. Smith Signed-off-by: Daniel P. Smith Co-developed-by: Alec Brown Signed-off-by: Alec Brown Signed-off-by: Ross Philipson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 88c5a62c3af7ca6f36dc6ffc52bcfb29cd2990cb Author: Ross Philipson Date: Sat Jul 11 09:01:04 2026 -0700 tpm: Move TPM common base definitions to the command header These are top level definitions shared by both TPM 1 and 2 family chips. This includes core definitions like TPM localities, common crypto algorithm IDs, and the base TPM command header. Co-developed-by: Daniel P. Smith Signed-off-by: Daniel P. Smith Co-developed-by: Alec Brown Signed-off-by: Alec Brown Signed-off-by: Ross Philipson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 7a5ec92813bc794ab3674aab993fe8f8b5cee9f0 Author: Ross Philipson Date: Sat Jul 11 09:01:03 2026 -0700 tpm: Move TPM2 specific definitions to the command header Gather all the TPM2 definitions and structures in the internal header file drivers/char/tpm/tpm.h into the command header, including: - Command codes, return codes and definitions from the public and internal tpm.h files. - Structures defined in numerous TPM driver C modules. The definitions moved to these files correspond to the TCG specification for TPM 2 family: TPM 2.0 Library - https://trustedcomputinggroup.org/resource/tpm-library-specification/ Co-developed-by: Daniel P. Smith Signed-off-by: Daniel P. Smith Co-developed-by: Alec Brown Signed-off-by: Alec Brown Signed-off-by: Ross Philipson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 94d48062eb9626244f6ddb5a682cdaae40540030 Author: Ross Philipson Date: Sat Jul 11 09:01:02 2026 -0700 tpm: Move TPM1 specific definitions to the command header Gather all the TPM1 definitions and structures from the internal header file drivers/char/tpm/tpm.h into the command header. In addition, bring in the single RNG structure from tpm1-cmd.c. The definitions moved to these files correspond to the TCG specification for TPM 1 family: TPM 1.2 Main Specification - https://trustedcomputinggroup.org/resource/tpm-main-specification/ Co-developed-by: Daniel P. Smith Signed-off-by: Daniel P. Smith Co-developed-by: Alec Brown Signed-off-by: Alec Brown Signed-off-by: Ross Philipson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit e06f28d32f31206c0be32a08b0273e26cfc1fc92 Author: Ross Philipson Date: Sat Jul 11 09:01:01 2026 -0700 tpm: Initial step to reorganize TPM public headers Consolidate TPM1 constants in tpm_command.h and remove duplicate constants from tpm1-cmd.c. Co-developed-by: Daniel P. Smith Signed-off-by: Daniel P. Smith Co-developed-by: Alec Brown Signed-off-by: Alec Brown Signed-off-by: Ross Philipson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 264216889d39df509b9c8045df53529480b0b718 Author: Ruoyu Wang Date: Thu Aug 13 23:30:32 2026 +0800 tpm: st33zp24: Validate locality read result check_locality() treats every nonzero transport return as success. SPI errors remain negative, while the I2C path can convert a negative write error through its byte-sized status variable. Either result is nonzero even though the TPM_ACCESS byte can remain unwritten, so indeterminate ACTIVE_LOCALITY and VALID bits can falsely report an active locality. Require recv() to return exactly the requested byte before examining TPM_ACCESS. Transport errors and short reads now report an inactive locality, while successful reads retain the existing behavior. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 251a7b08213a ("TPM: STMicroelectronics ST33 I2C KERNEL 3.x") Signed-off-by: Ruoyu Wang Link: https://lore.kernel.org/r/20260813153032.3951878-2-ruoyuw560@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 8b92687708f5ef980de01c2042dbd76d11f78547 Author: Ruoyu Wang Date: Fri Aug 21 04:38:05 2026 +0300 tpm: st33zp24: Return zero on status read failure st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 251a7b08213a ("TPM: STMicroelectronics ST33 I2C KERNEL 3.x") Signed-off-by: Ruoyu Wang Link: https://lore.kernel.org/r/20260813153032.3951878-1-ruoyuw560@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit b4d1adc70471d0752bba674552d19971ed9fa869 Author: Li Jun Date: Wed Aug 12 18:09:14 2026 +0800 tpm: tpm_tis_spi: fix nodef CR50 tpm_tis_spi_resume is null if no define CONFIG_TCG_TIS_SPI_CR50 in config, the add of tpm_tis_spi_resume is null, this cause the tpm chip to fail to resume. Signed-off-by: Li Jun Link: https://lore.kernel.org/r/20260812100914.3540149-1-lijun01@kylinos.cn Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit 4bfacee94f309346bef0b598ea091088b9150af9 Author: Karl Mehltretter Date: Sun Jul 12 20:32:34 2026 +0200 tpm: atmel: depend on X86 tpm_atmel probes for the chip at fixed x86 Super-I/O ports (0x4e) with inb()/outb(), so it only works on x86. TCG_ATMEL nevertheless depends only on HAS_IOPORT_MAP/HAS_IOPORT, which arm and arm64 also satisfy. There the probe is useless, and on platforms whose unbacked I/O access faults it oopses in init_atmel() at boot (e.g. arm/versatile): Unable to handle kernel paging request at virtual address fee0004e PC is at init_atmel+0x34/0x244 TCG_NSC and TCG_TIS already "depends on X86" (commit 2f592f2a7d74 ("TPM: NSC and TIS drivers X86 dependency fix")); TCG_ATMEL was missed. Add the same dependency. Signed-off-by: Karl Mehltretter Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260712183234.23125-1-kmehltretter@gmail.com Signed-off-by: Jarkko Sakkinen commit cf92237e81130e50337456dc2bedbc7818f75269 Author: Pan Chuang Date: Sat Jul 11 20:36:37 2026 +0300 tpm: Remove redundant dev_err() Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err() calls. Signed-off-by: Pan Chuang Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260710105318.376496-3-panchuang@vivo.com Signed-off-by: Jarkko Sakkinen commit 705c4ed0643366963547b2616d53165f2519c81f Author: Myeonghun Pak Date: Fri Jun 26 19:35:52 2026 +0300 tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper. Cc: stable@vger.kernel.org # v5.10+ Fixes: 4c336e4b1556 ("tpm: Add support for the Nuvoton NPCT501 I2C TPM") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260626091653.54929-1-mhun512@gmail.com Signed-off-by: Jarkko Sakkinen commit 9cebfe6504488198b012e746bc6b313f88b95439 Merge: ce14fe4cd756d2 34b5c4a6e4fb9d Author: Linus Torvalds Date: Tue Aug 25 07:59:44 2026 -0700 Merge tag 'fuse-update-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse Pull fuse updates from Miklos Szeredi: - Improve performance of the io-uring transport by introducing buffer pools and zero-copy (Joanne) - Fix lots of bugs (Baokun Li) - Fix io-uring initialization issues (Joanne, Bernd) - More prep work for large folios (Joanne) - Don't limit buffered read to 128k (Jim Harris) - Fix zeroing of page end (dirtied with mmap) on file size extension (Jimmy Zuber) - Improve performance in certain cases with wake_up_sync() when queuing request (Xuewen Yan) - Misc fixes and cleanups (Xuewen Yan) * tag 'fuse-update-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse: (35 commits) fuse: zero the partial EOF page when extending a file io_uring: Add missing include for ITER_SOURCE and ITER_DEST fuse: Fix the condition to enable over-io-uring fuse: invalidate the correct range after O_APPEND direct write selftests/fuse: test post-EOF page zeroing when a file is extended fuse: wake one waiter per freed slot when raising max_background fuse: use min_not_zero() in fuse_init_server_timeout() fuse: copy request headers via a stack buffer for io-uring fuse: give wakeup hints to the scheduler for synchronous requests fuse: check for NULL root inode in fuse_fill_super_submount fuse: reject a duplicate fd= mount option cuse: wait for pending RCU callbacks on module exit fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse: fix invalidate lock leak on setattr writeback failure fuse: wait for FR_FINISHED on abort_on_kill to prevent use-after-free fuse: make dentry_tree_work static docs: fuse: document io-uring buffer pool and zero-copy uapi fuse: add zero-copy over io-uring fuse: support registered buffer pools in io-uring fuse: add io-uring buffer pools ... commit fe967191e5851ea79818c5fe4e781c3882139218 Author: Moritz Tanner Date: Fri Aug 21 10:54:51 2026 +0200 fs: don't return -EINVAL for successful nested thaw Commit 7366f8b6fc6a ("fs: handle freezing from multiple devices") replaced the freeze_holders bitmask with per-holder counters to allow nested freezes. In the bitmask version, a thaw that released a shared hold while another holder remained returned 0. Since the rework, thaw_super_locked() drops the freeze reference via freeze_dec() but then returns -EINVAL when other freezers remain, misinforming the caller: the thaw did succeed, the superblock just stays frozen for the remaining holders. This breaks bdev-initiated freezing. When a filesystem is frozen with FIFREEZE and additionally frozen via bdev_freeze() -- which nests by design, see fs_bdev_freeze() -- the subsequent bdev_thaw() receives -EINVAL from the holder op although its freeze reference was dropped, and therefore keeps bd_fsfreeze_count elevated. Then device-mapper's unlock_fs() ignores bdev_thaw()'s return value, so nothing rebalances the count. After the user's FITHAW and umount, the block device can never be mounted again: dm-1: Can't mount, blockdev is frozen There is no way for userspace to drop the leaked count; only destroying the block device (or a reboot) recovers the device. Reproducer (any kernel since v6.8): dmsetup create dut --table "0 $(blockdev --getsz "$DEV") linear $DEV 0" mkfs.ext4 /dev/mapper/dut mount /dev/mapper/dut /mnt fsfreeze --freeze /mnt # freeze_ucount == 1 dmsetup suspend dut # bd_fsfreeze_count == 1, ucount == 2 dmsetup resume dut # ucount 2 -> 1, but thaw_super() # returns -EINVAL, so bdev_thaw() # keeps bd_fsfreeze_count at 1 fsfreeze --unfreeze /mnt # filesystem thaws fine umount /mnt mount /dev/mapper/dut /mnt # EBUSY, forever The same happens with fsfreeze held across an LVM snapshot of the origin volume. fs_bdev_thaw()'s documentation already describes the intended semantics: "If this function returns zero it doesn't mean that the filesystem is unfrozen as it may have been frozen multiple times". Restore them by returning 0 when a nested thaw drops its hold while other freezers remain. Thawing without holding a freeze still fails with -EINVAL as may_unfreeze() rejects that case before the reference count is touched. Fixes: 7366f8b6fc6a ("fs: handle freezing from multiple devices") Cc: stable@vger.kernel.org # needs adjustments for < 6.17 (no may_unfreeze()) Signed-off-by: Moritz Tanner Link: https://patch.msgid.link/20260821085451.65206-1-moritz.tanner@linbit.com Tested-by: Lars Ellenberg Reviewed-by: Lars Ellenberg Signed-off-by: Christian Brauner (Amutable) commit 58c1c30074a8d1179e17a0188cd695b2f416bf75 Author: Takashi Iwai Date: Tue Aug 25 15:49:31 2026 +0200 ALSA: rawmidi: Another workaround for false-positive mutex lockdep warning While we attempted to work around the false-positive lockdep warning due to the nested mutex lock in rawmidi at the open path for a UMP legacy rawmidi, it didn't cover the similar locking at its close path, and this still caused another false-positive reports by syzkaller. Add a similar workaround to snd_rawmidi_kernel_release() as done in the former commit 9c04742e73b3 ("ALSA: rawmidi: Work around false-positive mutex lockdep warning") to cover completely. Reported-by: syzbot+7d1edf0ff6a05961020c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a8c7e4d.4d75e56a.c9a88.0052.GAE@google.com Link: https://patch.msgid.link/20260825134942.1289272-1-tiwai@suse.de Signed-off-by: Takashi Iwai commit fd8ed52ecea6b93e23d52cb2758fb4fb4029067f Author: Zhang Heng Date: Mon Aug 24 21:03:02 2026 +0800 ASoC: amd: yc: Add DMI entry for Alienware m18 R1 AMD Add DMI entry so the YC machine driver probes on this model and the internal DMIC works. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221485 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260824130302.553419-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown commit dc4b95b8fee95113587e93ca116356032d271371 Author: Victor Nogueira Date: Mon Aug 24 08:59:28 2026 -0300 net/sched: sch_teql: restore skb->dev on the slave failure path teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration. Fixes: 0cc0c2e661af ("net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit") Reported-by: Vega Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260824115928.4099988-1-victor@mojatatu.com Signed-off-by: Paolo Abeni commit 08edfb34ee9ca54383970c65ed3a6013e84f5e16 Author: Ali Ahmet Memis Date: Sat Aug 1 04:39:32 2026 +0300 ufs: do not treat unreadable directory blocks as empty ufs_empty_dir() scans every directory block to decide whether a directory is empty before rmdir() removes it. When ufs_get_folio() cannot read or validate a block it returns an error pointer, and the loop currently skips that block with continue and keeps scanning the remaining blocks. If none of the readable blocks hold an entry, the function returns 1 and the caller unlinks the directory. A directory whose contents live in a block that cannot be read, for example because of an I/O error or corrupted directory metadata, is therefore seen as empty and removed, losing the entries it still holds. Follow the ext2 behaviour and treat an unreadable block as a reason to consider the directory not empty, so rmdir() fails instead of discarding data that could not be verified. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260801013942.279992-1-ali@iusegentoo.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit 31c7755e4f379159429e038e508507f573f45eb8 Merge: 82e9343260dfc6 c9d263be26806d Author: Christian Brauner Date: Tue Aug 25 14:41:53 2026 +0200 Merge patch series "ufs: harden the mount path against malformed images" Ali Ahmet Memis says: Two robustness fixes for the ufs mount path, both reachable by mounting a crafted UFS image. Patch 1 reorders ufs_fill_super() so the root dentry is created after the cylinder group metadata is loaded. Today a failure while reading the cylinder groups drops UFS_SB(sb) but leaves s_root installed, so the generic teardown oopses on a NULL pointer in ufs_sync_fs() and the put_super operation. Patch 2 validates the cylinder group index and the rotor positions in ufs_read_cylinder() before they are cached. Unchecked, c_cgx indexes the cylinder summary array (a 32 bit write outside s_csp), and the rotors become bitmap scan offsets that can wrap an unsigned length and walk past the cylinder group buffers during an ordinary allocation. * patches from https://patch.msgid.link/20260801071306.59484-1-ali@iusegentoo.com: ufs: validate cylinder group metadata before caching it ufs: create the root dentry after loading cylinder metadata Link: https://patch.msgid.link/20260801071306.59484-1-ali@iusegentoo.com Signed-off-by: Christian Brauner (Amutable) commit c9d263be26806d388129fab8c6904bed197fc6af Author: Ali Ahmet Memis Date: Sat Aug 1 10:12:58 2026 +0300 ufs: validate cylinder group metadata before caching it ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: ucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); ucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); ucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); ucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32 bit count outside the s_csp allocation. - c_frotor becomes a bitmap scan start, start = c_frotor >> 3, and then length = ((s_fpg + 7) >> 3) - start. A start beyond the block bitmap wraps the unsigned length to a huge value, so ubh_scanc() walks far past the cylinder group buffers. c_irotor drives the inode bitmap the same way. A crafted image can set any of these freely, turning an ordinary allocation into an out of bounds access. Reject a cylinder group whose recorded index does not match the group being read, or whose rotors fall outside the group, before the metadata is cached. Valid filesystems keep cg_cgx equal to the group number and the rotors within the group, so only malformed images are rejected. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260801071306.59484-3-ali@iusegentoo.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit 55a4c98abb9694b067c6a031d11501f06b6b523c Author: Ali Ahmet Memis Date: Sat Aug 1 10:12:57 2026 +0300 ufs: create the root dentry after loading cylinder metadata ufs_fill_super() installed sb->s_root before it loaded the cylinder group structures for a writable mount: sb->s_root = d_make_root(inode); ... if (!sb_rdonly(sb)) if (!ufs_read_cylinder_structures(sb)) goto failed; When ufs_read_cylinder_structures() failed, the error path freed the in-core superblock information and set sb->s_fs_info to NULL while sb->s_root stayed installed. get_tree_bdev() then reached deactivate_locked_super(), and because s_root was present, generic_shutdown_super() called sync_filesystem() and the put_super operation. Both dereference UFS_SB(sb), which is now NULL, so a mount that fails only while reading the cylinder groups oopses during teardown. A crafted image whose first cylinder group cannot be read reaches this path. Load the cylinder group metadata first and create the root dentry last, so the superblock is published to the VFS only once it is fully set up. ufs_setup_cstotal() and ufs_read_cylinder_structures() take only the super_block and do not use the root inode, so the reordering is safe. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260801071306.59484-2-ali@iusegentoo.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) commit e2aa5ad3be41accfcdcccc62348f21af7baa3a38 Author: Christopher Tolang Date: Sun Aug 23 19:32:21 2026 +0800 ASoC: amd: yc: Add DMI entry for MSI Thin A15 B7UC This model requires an additional detection quirk to enable the internal microphone. Fixes: fa991481b8b2 ("ASoC: amd: add YC machine driver using dmic") Cc: stable@vger.kernel.org Assisted-by: OpenAI Codex Signed-off-by: Christopher Tolang Link: https://patch.msgid.link/20260823113221.19744-1-christophertolang@gmail.com Signed-off-by: Mark Brown commit adb176c1407a7f802b21627a7ec912ff649ab6a9 Author: Habil Eren Türker Date: Tue Aug 25 11:40:14 2026 +0300 ALSA: hda/realtek: Fix speaker mute LED for HP Laptop 15-fd0039nt HP Laptop 15-fd0039nt (SSID 103c:8bb6) needs a quirk to control the speaker mute LED via VREF100 on NID 0x1a (active-high). This patch replaces the previous ALC236_FIXUP_HP_MICMUTE_LED_ONLY with ALC236_FIXUP_HP_15_FD0XXX, which covers both mic mute (GPIO0) and speaker mute (NID 0x1a) LEDs. Use spec->no_shutup_pins instead of a custom shutup hook, as suggested by Takashi Iwai. Fixes: e711ebfadc9a ("ALSA: hda/realtek: Add quirk for HP Laptop 15-fd0039nt") Tested-by: Habil Eren Türker Signed-off-by: Habil Eren Türker Link: https://patch.msgid.link/20260825084125.4103-1-habilerenturker@hotmail.com Signed-off-by: Takashi Iwai commit a8e04f3f894ccb52cfcd7e60125a9f35da4a616d Author: Ibrahim Hashimov Date: Mon Jul 13 11:34:14 2026 +0200 HID: wacom: validate report length in wacom_intuos_pro2_bt_irq wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: wacom_intuos_pro2_bt_pen(wacom); if (type == INTUOSP2_BT || type == INTUOSP2S_BT) { wacom_intuos_pro2_bt_touch(wacom); wacom_intuos_pro2_bt_pad(wacom); wacom_intuos_pro2_bt_battery(wacom); } else { wacom_intuos_gen3_bt_pad(wacom); wacom_intuos_gen3_bt_battery(wacom); } Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] (the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT ("gen3"): wacom_intuos_gen3_bt_battery() reads data[45], so the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 ("HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior. Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Acked-by: Jason Gerecke Signed-off-by: Jiri Kosina commit ab0304fd69b07605553e9f161d65ecf9ccc2e2fe Author: Gabriele Monaco Date: Mon Aug 24 10:15:19 2026 +0200 verification/rvgen: Use .old instead of .bak for kunit backup files The rvgen kunit command generates .bak backup files and these can be checked in for selftests (make check). Clean targets like make disclean remove such files, leaving the tree dirty. Switch to .old to preserve a clean tree after make disclean. Reported-by: Kuan-Wei Chiu Closes: https://lore.kernel.org/lkml/aosuwKH5GOEo0xTN@google.com Fixes: 7b6246294eb0 ("verification/rvgen: Add selftests for rvgen kunit") Reviewed-by: Nam Cao Tested-by: Kuan-Wei Chiu Link: https://lore.kernel.org/r/20260824081519.81103-2-gmonaco@redhat.com Signed-off-by: Gabriele Monaco commit b95dbcdd718f38fd27eb13e63d8bfe4bf6e26ab3 Merge: a687f2ae995fc3 3faf13aff243ca Author: Paolo Abeni Date: Tue Aug 25 13:33:10 2026 +0200 Merge branch 'sctp-handle-wrapped-and-duplicate-reconf-responses' Jun Yang says: ==================== sctp: handle wrapped and duplicate RECONF responses Fix response sequence zero lookup first, then make RECONF response handling idempotent with an outstanding-request bitmask. ==================== Link: https://patch.msgid.link/20260824081832.98717-1-juny24602@gmail.com Signed-off-by: Paolo Abeni commit 3faf13aff243ca9f78d08b1a2956ef5a6fc77b6e Author: Jun Yang Date: Mon Aug 24 16:18:20 2026 +0800 sctp: fix stream->outcnt underflow on duplicate RECONF responses A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADD_OUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it. Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored. Fixes: 11ae76e67a17 ("sctp: implement receiver-side procedures for the Reconf Response Parameter") Cc: stable@kernel.org Reported-by: TencentOS Corvus AI Link: https://lore.kernel.org/netdev/20260730110225.37371-1-juny24602@gmail.com/ Suggested-by: Xin Long Assisted-by: tencentos-corvus-ai:kimi-k3 Signed-off-by: Jun Yang Link: https://patch.msgid.link/20260824081832.98717-3-juny24602@gmail.com Signed-off-by: Paolo Abeni commit 63f44178f0a0f86060c9b576d6efab8a3ffa403e Author: Jun Yang Date: Mon Aug 24 16:18:19 2026 +0800 sctp: distinguish sequence zero from wildcard in reconf lookup Zero is a valid response sequence after strreset_outseq wraps, but sctp_chunk_lookup_strreset_param() currently treats it as a wildcard. Add match_seq so response lookups match zero exactly while the one type-only lookup can still ignore the sequence. Fixes: 50a41591f110 ("sctp: implement receiver-side procedures for the Add Outgoing Streams Request Parameter") Cc: stable@kernel.org Suggested-by: Simon Horman Acked-by: Xin Long Signed-off-by: Jun Yang Link: https://patch.msgid.link/20260824081832.98717-2-juny24602@gmail.com Signed-off-by: Paolo Abeni commit ffe0486b139e45cd9c9ca2584f04a1910fe4f8a6 Author: Johan Hovold Date: Wed Aug 19 15:38:53 2026 +0200 console: fix /dev/kmsg reference in flags kernel doc Fix typo in the CON_EXTENDED flag kernel doc which is supposed to refer to '/dev/kmsg'. Fixes: 717a5651b109 ("console: Use BIT() macros for @flags values") Signed-off-by: Johan Hovold Reviewed-by: Petr Mladek Link: https://patch.msgid.link/20260819133853.286658-1-johan@kernel.org Signed-off-by: Petr Mladek commit a687f2ae995fc366a6f2ef180451e6db4c6b4530 Merge: 728836ebca2398 816e90057ab187 Author: Paolo Abeni Date: Tue Aug 25 13:09:34 2026 +0200 Merge branch 'net-sched-fix-quantum-mtu-overflow-in-fq-fq_codel-sch_codel-fq_pie-hhf-sfq' Jamal Hadi Salim says: ==================== net: sched: fix quantum/mtu overflow in fq, fq_codel, sch_codel, fq_pie, hhf, sfq Several qdiscs derive their per-flow quantum or CoDel mtu from psched_mtu() without an overflow or zero clamp, which can drive the dequeue/credit-refill loop into a soft lockup or silently disable the AQM. vega@nebusec.ai provided reports and PoCs for the following qdiscs: sch_fq, sch_fq_codel, sch_fq_pie, sch_hhf, and sch_sfq. sch_codel was found by inspection for the same pattern. It's TheLinuxWay (i.e cutnpaste code from somewhere for your new feature) and the AIs are having a lot of fun finding patterns. We must overcome! Clamp the quantum (and, for the codel family, the cparams/params mtu) to a sane range at init/change time so the dequeue loops terminate and the AQM stays armed. The clamps live in the init/change paths, not the per-packet fast path, so no hot-path cost is added for a configuration issue. This series depends on "net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup", which caps qdisc_pkt_len() at GSO_MAX_SIZE in __qdisc_calculate_pkt_len(). That cap closes the fq_codel TCA_STAB backlog-wrap vector (qdisc_pkt_len inflated to ~1 GiB wrapping the u32 per-flow backlog to 0 and NULL-derefing in fq_codel_drop()); with it upstream this series no longer needs the fq_codel_drop() hardening hunk that the earlier respin carried. The five quantum/mtu fixes here are psched_mtu()-driven and orthogonal to the qdisc_pkt_len() cap. Q: Why not bound the MTU at the source instead? dummy's max_mtu == 0 is intentional (dev_validate_mtu() treats 0 as unbounded), other drivers can legitimately advertise large MTUs, and qdiscs must not trust psched_mtu() regardless. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps 2 * psched_mtu() or psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting a huge MTU). Requires CAP_NET_ADMIN in a user namespace. ==================== Link: https://patch.msgid.link/20260822195509.112717-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni commit 816e90057ab1879562a5b7cc688e35bb9027ae97 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:09 2026 -0400 net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-7-jhs@mojatatu.com Signed-off-by: Paolo Abeni commit 2164b512b97bb053e8ce4d6e95576f11bed6a005 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:08 2026 -0400 net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare "tc qdisc add ... hhf" succeeds with a clamped quantum but "tc qdisc add ... hhf limit 1000" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-6-jhs@mojatatu.com Signed-off-by: Paolo Abeni commit c86cd7ed0b0e44779a3d1683f03e4353baf4bdc9 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:07 2026 -0400 net/sched: fq_pie: clamp default quantum to avoid signed overflow fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-5-jhs@mojatatu.com Signed-off-by: Paolo Abeni commit 6439461f1618ae176c048673ad28bdb6c68efbfc Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:06 2026 -0400 net/sched: sch_codel: clamp default mtu to avoid disabling CoDel codel_init() sets q->params.mtu = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000. In codel_should_drop() the test "*backlog <= params->mtu" then compares the backlog against ~2 GiB; with the default sch->limit of DEFAULT_CODEL_LIMIT (1000) packets the backlog can never reach it, so the test is always true and CoDel is silently and completely disabled i.e no drops, no ECN marking, codel degrades to a tail-drop FIFO. codel_change() never updates params.mtu, so the init path is the only place to clamp it. Constrain to [256, 1 << 20], matching the fq_codel bound; 256 is a sane floor that only makes CoDel slightly more willing to act on very small queues, which is the safe direction. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-4-jhs@mojatatu.com Signed-off-by: Paolo Abeni commit d9ebd8f9aa8b2773235889cb903fafd61f2d8585 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:05 2026 -0400 net/sched: fq_codel: clamp default quantum and mtu fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests "*backlog <= params->mtu"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: 4b549a2ef4be ("fq_codel: Fair Queue Codel AQM") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-3-jhs@mojatatu.com Signed-off-by: Paolo Abeni commit 709f34f7c28dc4dd6c40343d101850f11e172312 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:04 2026 -0400 net/sched: fq: add overflow bounds to quantum and initial quantum fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup. Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCA_FQ_QUANTUM in fq_change(). Conditions to recreate the bug: a device whose MTU (plus hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: afe4fd062416 ("pkt_sched: fq: Fair Queue packet scheduler") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-2-jhs@mojatatu.com Signed-off-by: Paolo Abeni commit 728836ebca239810f164262b10211ef59182f811 Author: Chengfeng Ye Date: Sun Aug 23 00:45:56 2026 +0800 vsock/virtio: flush works in dependency order virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush. Fixes: 0ea9e1d3a9e3 ("VSOCK: Introduce virtio_transport.ko") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Link: https://patch.msgid.link/20260822164556.3750959-1-nicoyip.dev@gmail.com Signed-off-by: Paolo Abeni commit 3220b62fbb8a55feebd2a826d5ead0f49f09ed5a Author: Tetsuo Handa Date: Sat Aug 22 17:18:31 2026 +0900 net: fix a resource leak in copy_net_ns() error handling path Currently, preinit_net() does two things: (1) call ns_common_init() which might fail (2) initialize resources which does not fail However, preinit_net() is returning early when (1) fails, and copy_net_ns() is jumping to the dec_ucounts: label. As a result, resources allocated by net_alloc() are leaking. We need to call key_remove_domain() and net_passive_dec() in order to release resources allocated by net_alloc(). We cannot simply jump to the put_userns: label when preinit_net() failed, for (2) is not yet done. But we can reorder (1) and (2), for there is no dependency between (1) and (2). Therefore, this patch decouples (1) from preinit_net() and changes preinit_net() back to a void function, and calls ns_common_init() after preinit_net() succeeded. Then, we can jump to immediately after ns_common_free() of the put_userns: label. Reported-by: sashiko (no mail address) Closes: https://sashiko.dev/#/patchset/af7dabf3-d0d7-46dc-a878-e1715b3c9ac6%40I-love.SAKURA.ne.jp Fixes: 08027f6b790b ("net: use ns_common_init()") Signed-off-by: Tetsuo Handa Link: https://patch.msgid.link/c182cf90-1ed7-435b-88f7-9f00e88a0487@I-love.SAKURA.ne.jp Signed-off-by: Paolo Abeni commit e8e60b6439eed340a611e9d7a5b9bcbd0ef62725 Author: Dave Carey Date: Thu Jul 30 08:43:36 2026 -0400 HID: multitouch: Fix stale MT slots when contact count drops to zero The INGENIC 17EF:6161 touchscreen (Lenovo Yoga Book 9 14IAH10) reports HID_DG_CONTACTCOUNT=0 in the frame immediately following the last finger lift rather than omitting the frame entirely. In mt_touch_report() the existing code only updates num_expected when contact_count is non-zero, so a zero contact count on the first packet of a new frame leaves num_expected at its previous value (e.g. 2 for a two-finger gesture). The sync check "num_received >= num_expected" then evaluates "0 >= 2" and never fires, preventing INPUT_MT_DROP_UNUSED from releasing the stale slots. Those slots remain active in the kernel MT layer until the next touch, at which point they are released in a batch alongside the new contact — causing the userspace event consumer to miss the intervening finger-up sequence and corrupt its gesture session state. Fix by resetting num_expected to 0 when contact_count is zero and num_received is still 0 (i.e., this is the first and only packet of the frame, not a continuation packet in a multi-packet sequence). With num_expected=0 the sync check "0 >= 0" fires immediately, calling input_mt_sync_frame() which drops the stale slots via INPUT_MT_DROP_UNUSED. The num_received==0 guard is critical: continuation packets in a multi-packet frame arrive after at least one contact has already been processed (num_received>0), so they are correctly excluded from this path and the existing multi-packet logic is unaffected. Signed-off-by: Dave Carey Tested-by: Dave Carey Signed-off-by: Benjamin Tissoires commit 97148bcb751105cd7cf86a21344887028f329890 Author: Mina Almasry Date: Sun Aug 23 18:36:02 2026 +0000 net: core: fix head-page leak in skb_zerocopy When skb_orphan_frags() throws -ENOMEM, skb_copy_ubufs() may have already reallocated and replaced 'from->head'. Accessing from->head to drop the old refcount leaks the original head page, and erroneously puts an unrelated new buffer. Use the local 'page' tracker variable instead to drop the reference properly. Fixes: 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors") Signed-off-by: Mina Almasry Link: https://patch.msgid.link/20260823183602.1051453-2-almasrymina@google.com Signed-off-by: Paolo Abeni commit 00e11ee9831b3439264e0ae6762a0470126515af Author: Mina Almasry Date: Sun Aug 23 18:36:01 2026 +0000 net: core: check skb_frags_readable before uncloning in skb_copy_ubufs skb_copy_ubufs drops clones and modifies the SKB via pskb_expand_head() before checking for !skb_frags_readable(skb). This alters the SKB geometry prior to throwing an -EFAULT on an invalid SKB. Check readability first. Fixes: 65249feb6b3d ("net: add support for skbs with unreadable frags") Signed-off-by: Mina Almasry Link: https://patch.msgid.link/20260823183602.1051453-1-almasrymina@google.com Signed-off-by: Paolo Abeni commit 2db9bfa3e27bdea15e05ea70b56bad3d21e570ec Author: Weiming Shi Date: Mon Aug 24 01:28:58 2026 +0800 sctp: fix NULL deref on untransmitted RECONF completion sctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out() and sctp_process_strreset_resp() complete a pending stream reconfiguration request by stopping the reconf timer on the transport it was sent on: t = asoc->strreset_chunk->transport; if (timer_delete(&t->reconf_timer)) sctp_transport_put(t); chunk->transport is assigned by __sctp_packet_append_chunk() when the chunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms the reconf timer at that same point. A request already published in asoc->strreset_chunk but not yet transmitted has neither, so completing it dereferences NULL. Two ways to get there. sctp_send_asconf_del_ip() sets asoc->src_out_of_asoc_ok without sending anything when the address being removed is the association's last one, and sctp_outq_flush_ctrl() then leaves every non-ASCONF control chunk queued; as only sctp_process_asconf_ack() clears that flag, it persists. An unprivileged process that removes such an address and then asks for a stream reset panics the kernel from softirq. A peer needs neither ASCONF nor local help: sctp_cmd_interpreter() uncorks the outqueue only once the whole packet has been processed, so a reply built while walking a RECONF chunk stays untransmitted for the rest of that walk, and one RECONF chunk carrying [Incoming SSN Reset Request, Outgoing SSN Reset Request, Response] -- or two RECONF chunks in one packet -- reaches the same dereference. KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] RIP: 0010:timer_delete+0x67/0x110 Call Trace: sctp_process_strreset_addstrm_out (net/sctp/stream.c:832) sctp_sf_do_reconf (net/sctp/sm_statefuns.c:4212) sctp_do_sm (net/sctp/sm_sideeffect.c:1172) sctp_assoc_bh_rcv (net/sctp/associola.c:1044) sctp_rcv (net/sctp/input.c:243) ip_local_deliver (net/ipv4/ip_input.c:262) process_backlog (net/core/dev.c:6680) A response can only acknowledge a request that was actually sent, so do not match asoc->strreset_chunk while chunk->transport is NULL. Guarding the lookup covers all three completion sites. Fixes: 810544764536 ("sctp: implement receiver-side procedures for the Outgoing SSN Reset Request Parameter") Cc: stable@vger.kernel.org Reported-by: Xiang Mei Suggested-by: Xin Long Assisted-by: Claude:claude-opus-5 Signed-off-by: Weiming Shi Acked-by: Xin Long Link: https://patch.msgid.link/20260823172857.896146-2-bestswngs@gmail.com Signed-off-by: Paolo Abeni commit 81d0d1e64f30d9989c829c0953cd6e6c68d9c5fb Author: Eric Dumazet Date: Sun Aug 23 18:22:41 2026 +0000 net/sched: act_skbmod: fix length calculations and avoid invalid header warnings syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER. Fixes: 56af5e749f20 ("net/sched: act_skbmod: Add SKBMOD_F_ECN option support") Reported-by: syzbot+1d56f14f95c0480cfdc9@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a8b39c0.dbb3a75c.13dd47.0051.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260823182241.1958695-1-edumazet@google.com Signed-off-by: Paolo Abeni commit 1c942462c3969b287a86ab6dbb143324289d564e Author: Vadim Klishko Date: Mon Jul 27 22:17:18 2026 -0600 HID: i2c-hid: Add a quirk for a Cirque I2C device. Cirque touchpads with PID D0C1 generate an error when probed by the I2C HID driver, resulting in no hidraw device created. Adding I2C_HID_QUIRK_NO_IRQ_AFTER_RESET fixes the issue. Signed-off-by: Vadim Klishko Signed-off-by: Benjamin Tissoires commit b17cf742eaad70ae29ac558cefb3aa9bbeea03d4 Author: Jiayuan Chen Date: Sun Aug 23 16:47:56 2026 +0800 tls: device: fix out-of-bounds write in tls_append_frag() Found with syzkaller and a local syzbot instance running on top of a netdevsim TLS offload emulation; tls_device.c is otherwise only reachable on a machine with a NIC that implements the offload. tls_push_data() only checks whether the open record still has room for another frag at the bottom of its loop, and the MSG_MORE early break skips that check. The record survives to the next syscall with the frag count it already had, and tls_append_frag() does not check either, so with TLS_TX_ZEROCOPY_RO every splice(SPLICE_F_MORE) of a byte or two adds a non-coalescing pipe page and num_frags walks off the end of tls_record_info.frags[MAX_SKB_FRAGS]. Once the record is pushed, tls_push_record() runs the same index over sg_tx_data[MAX_SKB_FRAGS] and the sg_set_page() writes land on the destruct_work that follows it, which the workqueue then calls. The byte limit is fine because copy drops to 0 and the loop falls through to the same check; the frag count has no such feedback. Push the record rather than keep a full one open, which is what a plain TCP socket does - tcp_sendmsg_locked() uses tcp_mark_push() and new_segment in both the copy and the MSG_SPLICE_PAGES paths, and tls_sw already sets full_record when the sk_msg ring fills up, MSG_MORE or not. BUG: KASAN: slab-out-of-bounds in tls_append_frag ( net/tls/tls_device.c:269) Write of size 8 at addr ffff8881104d1530 by task tls_oob/450 CPU: 2 UID: 0 PID: 450 Comm: tls_oob Not tainted 7.2.0-rc7+ #329 PREEMPT Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) tls_append_frag (net/tls/tls_device.c:269) tls_push_data (net/tls/tls_device.c:518) tls_device_sendmsg (net/tls/tls_device.c:583) inet_sendmsg (net/ipv4/af_inet.c:865) sock_sendmsg (net/socket.c:775 net/socket.c:790 net/socket.c:813) splice_to_socket (fs/splice.c:884) do_splice (fs/splice.c:936 fs/splice.c:1349) __do_splice (fs/splice.c:1431) __x64_sys_splice (fs/splice.c:1634 fs/splice.c:1616) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) and, once the record is pushed: UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:300:24 index 18 is out of range for type 'skb_frag_t [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:301:41 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:302:39 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:307:38 index 26 is out of range for type 'scatterlist [17]' kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle page fault for address: ffffea000411a680 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0011) - permissions violation Oops: Oops: 0011 [#1] SMP KASAN PTI Workqueue: ktls_device_destruct 0xffffea000411a680 RIP: 0010:0xffffea000411a680 Call Trace: worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260823084758.20936-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni commit 1739a976312e110c93a8dee66a1cdf893a1b187e Author: Will Porter Date: Mon Aug 24 17:57:57 2026 -0500 ALSA: usb-audio: Complete cleanup after system-resume errors A failed system resume can leave the card unusable until reboot. usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or snd_usb_mixer_resume() fails. The error path skips the out: block, which restores D0 and decrements chip->num_suspended_intf. The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in snd_power_ref_and_wait(). USB core logs an interface resume callback error. It does not retry that callback, so a later callback cannot complete the skipped cleanup. usb_audio_suspend() increments num_suspended_intf before returning success. A system-resume callback must consume the system-suspend count even if a component resume fails. Otherwise, the stranded count skews later suspend and resume cycles. Do not apply this cleanup to runtime-resume errors. Runtime PM can retry -EAGAIN or -EBUSY without another suspend callback. The count must continue to describe that suspended interface. Other runtime-resume errors latch runtime_error in the PM core and do not cause an immediate callback retry. Both parts of the system-resume error path are longstanding. Commit 88a8516a2128a ("ALSA: usbaudio: implement USB autosuspend") introduced err_out past the D0 restore. Commit 862b2509d157c ("ALSA: usb-audio: Fix inconsistent card PM state after resume") later moved num_suspended_intf-- into the out: block. The error path now skips both operations. No third-party code is needed to reach the error path. snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the result of usb_submit_urb() for devices that have a mixer status URB. Its mixer->private_resume hook can also fail through scarlett2_init_notify(). snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It can return -EPIPE or -EIO when the device stalls the request. Route a component error through out: only when system_suspend is nonzero. Continue to return runtime-resume errors through err_out. Later component resume stages remain skipped. The original error still reaches USB core. A later transfer can fail if the device did not recover. I reproduced the system-resume failure on an Audient iD14 MkI with an out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched core left control readers in uninterruptible sleep in snd_power_ref_and_wait() until a reboot. With this patch, the same failure restored control access. A second system suspend and resume also succeeded after I disabled fault injection. Assisted-by: Claude:claude-opus-5 Assisted-by: Antigravity:gemini-3.1-pro-high Assisted-by: Codex:gpt-5.6-sol Fixes: 88a8516a2128a ("ALSA: usbaudio: implement USB autosuspend") Fixes: 862b2509d157c ("ALSA: usb-audio: Fix inconsistent card PM state after resume") Cc: Signed-off-by: Will Porter Link: https://patch.msgid.link/20260824225757.26749-1-mrwillporter@gmail.com Signed-off-by: Takashi Iwai commit be79a45e2ec289eb9fad519e8f5a3d4fc3789dd0 Author: Zhang Heng Date: Mon Aug 24 20:37:52 2026 +0800 ALSA: hda/realtek: Add quirk for Lenovo IdeaPad Slim 3 15ABR8 The internal microphone on Lenovo IdeaPad Slim 3 15ABR8 (subsystem 17aa:3862) exhibits severe distortion at default gain levels. The Capture Volume is fixed at 63 (max) and cannot be lowered without explicit userspace intervention. The existing fixup ALC269_FIXUP_LIMIT_INT_MIC_BOOST limits the gain range and resolves the issue. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221891 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260824123752.525173-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai commit 15fd93cbbff7d9d92cd19f38a94355462fa91930 Author: bui duc phuc Date: Mon Aug 24 17:07:30 2026 +0700 ALSA: aoa: i2sbus: Check IRQ before requesting it irq_of_parse_and_map() returns 0 when parsing or mapping an IRQ fails. The return value was passed to request_irq() without checking for failure. Check the return value before passing it to request_irq(). Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260824100730.31601-1-phucduc.bui@gmail.com Signed-off-by: Takashi Iwai commit 4c0ec35e011309bd7091053ad5bbc01420967a66 Author: Federico Valentín Andrade Date: Mon Aug 24 11:02:11 2026 -0300 ALSA: usb-audio: Skip mixer creation on M-Audio Venom The M-Audio Venom (0763:2084) does not answer any GET_CUR request of its feature units, hanging up the USB microcontroller and "responding" with timeouts. So the mixer building lasts around 47 seconds, and the device does not stream at all. The same GET_CUR requests issued through libusb (with no kernel driver bound) complete correctly and blazingly fast. So it seems to only happen during the initial probe. I defined an explicit composite quirk to bypass the mixer creation, as it is not needed (the synth already comes with volume controls). With both this and the device flag applied, the synth works flawlessly. Signed-off-by: Federico Valentín Andrade Link: https://patch.msgid.link/20260824140211.17003-3-fandrade@frba.utn.edu.ar Signed-off-by: Takashi Iwai commit b3be0e5bed8ab9adbf127a3eee3806e61190ec14 Author: Federico Valentín Andrade Date: Mon Aug 24 11:02:10 2026 -0300 ALSA: usb-audio: Skip reading sample rate on M-Audio Venom The M-Audio Venom (0763:2084) is an USB Audio Class 1 compliant synth with an integrated audio interface, it does not implement GET_CUR on SAMPLING_FREQ_CONTROL, hanging up if requested on endpoint 0. The first class request issued by the driver after enumeration is a GET_CUR on endpoint 0x02, freezing the device's USB microcontroller. Timing out on every transfer afterwards with -ETIMEDOUT, such as SET_INTERFACE, so neither the mixer nor any streaming interface is set up. Analyzing a USBPcap capture of the Windows driver I found it never requests the sampling frequency, as the synth exposes a single discrete of 44100Hz on both streaming interfaces, thus asking for it is unnecessary. So I applied get_sample_rate to avoid this check, and disable_autosuspend because the synth doesn't come back from being suspended. Signed-off-by: Federico Valentín Andrade Link: https://patch.msgid.link/20260824140211.17003-2-fandrade@frba.utn.edu.ar Signed-off-by: Takashi Iwai commit c5f2613e69ccdf04aeb0848a704ecf4f481961da Merge: b70b7b71561f2b f66bdb1cc0fcd2 Author: Paolo Abeni Date: Tue Aug 25 09:36:49 2026 +0200 Merge branch 'net-don-t-strip-zerocopy-frag-markers-from-a-forwarded-skb' Norbert Szetei says: ==================== net: don't strip zerocopy frag markers from a forwarded skb queue_userspace_packet() calls skb_tx_error() on the packet skb in its error path, but it only borrows that skb: on the OVS_ACTION_ATTR_USERSPACE action path do_execute_actions() ignores output_userspace()'s return value and keeps forwarding the same skb through the flow's remaining actions. skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and with it SKBFL_SHARED_FRAG. For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is what makes esp_input() skb_cow_data() instead of taking the in-place AEAD path. Once it is stripped, a later local ESP delivery decrypts in place over pages the sender still shares with the page cache. Patch 1 moves the skb_tx_error() into the one path that does drop the packet, the "default" arm of ovs_dp_process_packet()'s switch(error). Patch 2 removes a second such strip, in skb_zerocopy(), which calls skb_tx_error() on its source when skb_orphan_frags() fails. A copy helper should not perform a destructive action on its source, and both callers already report the error on their own drop path. MSG_ZEROCOPY skbs cannot reach that one -- SKBFL_DONT_ORPHAN makes skb_orphan_frags() return early -- but producers that do not set that flag, such as vhost-net, can. Patch 3 is new in v2. It stops skb_tx_error() from touching skb_shinfo() state that is shared with clones, so patch 1's new call site cannot reach a live skb either. For a non-last OVS_ACTION_ATTR_RECIRC action clone_execute() sends a skb_clone() into ovs_dp_process_packet() while do_execute_actions() keeps forwarding the original, and skb_clone() does not privatise the frags for these skbs -- skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN -- so a flow miss on the clone strips SKBFL_SHARED_FRAG from the packet still in flight. Confirmed on a KASAN build with a flow matching recirc_id 0 and actions RECIRC(1),OUTPUT(0): with patches 1 and 2 applied it still reproduces the page-cache write, with patch 3 on top it no longer does (5/5 runs). A kprobe on skb_tx_error() shows the datapath drop path is still reached in both cases, so the difference is the guard and not the reproducer. As Ilya noted, that makes patch 3 the general fix -- an skb can enter any skb_tx_error() caller already cloned elsewhere in the stack -- while patches 1 and 2 keep the callers from acting on an skb they do not own. Removing skb_tx_error() altogether looks like the right long-term cleanup and is planned as a net-next follow-up. v3: https://lore.kernel.org/netdev/F3B9E5BA-0AC1-4AD1-A7D9-F38033304270@doyensec.com/ v2: https://lore.kernel.org/netdev/AD1B7BEE-C04C-4A1B-982C-8385F1908911@doyensec.com/ v1: https://lore.kernel.org/netdev/8063260C-05C9-4997-B9B6-2135063C4858@doyensec.com/ ==================== Link: https://patch.msgid.link/4B5CCA6E-2C49-4F86-8C4E-E1BE15C16C0A@doyensec.com Signed-off-by: Paolo Abeni commit f66bdb1cc0fcd227a062378f8be0b5873aa5600a Author: Norbert Szetei Date: Sat Aug 22 11:15:08 2026 +0200 net: skbuff: don't touch shared zerocopy state in skb_tx_error() skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone shares, while the caller only owns the reference it is about to drop. Through a clone it tells the producer its pages are free and drops SKBFL_SHARED_FRAG for an skb that is still in flight. Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC: clone_execute() sends a skb_clone() into ovs_dp_process_packet() while do_execute_actions() keeps forwarding the original, and skb_clone() does not privatise the frags here -- skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker from the packet still being forwarded, and a later local ESP delivery decrypts in place over frags it does not own privately. Skip it for a cloned skb. Nothing is lost: skb_release_data() clears the zerocopy state once the last reference to the shared data goes. Fixes: 25121173f7b1 ("skb: api to report errors for zero copy skbs") Cc: stable@vger.kernel.org Suggested-by: Ilya Maximets Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Tested-by: Jongmin Jang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/CFAB292A-674B-4C14-BB2C-BB8830AD5659@doyensec.com Signed-off-by: Paolo Abeni commit 8ece906150128d5ec2462aabcc978c568433eca4 Author: Norbert Szetei Date: Sat Aug 22 11:13:47 2026 +0200 net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers. Fixes: 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors") Cc: stable@vger.kernel.org Suggested-by: Ilya Maximets Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/6E3A780D-FB87-421F-9964-B1D457D7D106@doyensec.com Signed-off-by: Paolo Abeni commit 0dbc2398fca3bb33eda963849f865ddb1b3aa05e Author: Norbert Szetei Date: Sat Aug 22 11:12:11 2026 +0200 openvswitch: only skb_tx_error() a packet we are about to drop queue_userspace_packet() borrows the packet skb -- it only copies it into a private netlink message (user_skb) and does not own it; on return do_execute_actions() keeps forwarding it through the flow's remaining actions. Its error path nevertheless calls skb_tx_error(skb), which via skb_zcopy_clear() does skb_shinfo(skb)->flags &= ~SKBFL_ALL_ZEROCOPY, stripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s kerneldoc says "skb must be freed afterwards"). For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is what makes esp_input() skb_cow_data() before in-place AEAD; once it is stripped a later local ESP-in-UDP delivery decrypts in place over pages the sender does not own -- an unprivileged page-cache write (the "Fragnesia" primitive). do_execute_actions() ignores output_userspace()'s return value, so any action after a failed USERSPACE upcall inherits the stripped skb. Move the skb_tx_error() to the flow-miss drop path - the "default" branch of ovs_dp_process_packet()'s switch(error), before kfree_skb(). The call has been here since commit 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors") but was harmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate in-place decrypt; only then did stripping it on a still-forwarded skb become a page-cache write primitive. Fixes: 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors") Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Tested-by: Jongmin Jang Link: https://patch.msgid.link/55A52703-7548-4A55-A9CE-2A37145BDCAD@doyensec.com Signed-off-by: Paolo Abeni commit ce366bfa821ec81dd45bde547ee31e659306cc61 Author: Chao Yu Date: Mon Aug 24 21:17:29 2026 +0800 f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages() There is potential deadloop in race condition: Thread A Thread B - fsync - f2fs_do_sync_file - f2fs_fsync_node_pages - last_fsync_dnode - folio_get(last_folio) - f2fs_setattr - f2fs_truncate - f2fs_truncate_blocks - f2fs_do_truncate_blocks - f2fs_truncate_inode_blocks - truncate_dnode - truncate_node - invalidate_mapping_pages - folio->mapping = NULL - is_node_folio alwasy return false - atomic && !marked is always true, then goto retry Cc: stable@kernel.org Fixes: 608514deba38 ("f2fs: set fsync mark only for the last dnode") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim commit 0685630fdccb62dcb0e3f44525a40578da5f6dc8 Author: Karl Mehltretter Date: Sat Aug 8 22:03:12 2026 +0200 selftests/proc: make proc-maps-race work with READ_IMPLIES_EXEC test_maps_tearing_from_split times out when READ_IMPLIES_EXEC is set. This happens by default on pre-ARMv6 CPUs, which lack no-execute support. split_vma() re-maps the first page with mod_info->prot | PROT_EXEC to make it differ from its neighbours. With READ_IMPLIES_EXEC the original mapping is already executable, so no split occurs and the test hangs waiting for the modifier child. Use PROT_NONE for the split mapping, which always differs from its readable neighbours. Link: https://lore.kernel.org/20260808200312.6326-1-kmehltretter@gmail.com Fixes: beb69e817246 ("selftests/proc: add /proc/pid/maps tearing from vma split test") Assisted-by: Codex:gpt-5.6-terra Signed-off-by: Karl Mehltretter Acked-by: Suren Baghdasaryan Cc: Alexey Dobriyan Cc: Jann Horn Cc: Liam R. Howlett Cc: Shuah Khan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 0e0ac326c511d514817cc7b6d7741afd59098ce2 Author: Shakeel Butt Date: Fri Aug 21 19:47:07 2026 -0700 memcg: move LRU size accounting on reparenting instead of copying it When a memory cgroup is offlined its LRU folios are reparented to the parent. lruvec_reparent_lru() splices the child's lists into the parent's and credits the parent with the child's per-zone lru_zone_size[], but never clears the child's copy, so the size is copied rather than moved. lru_gen_reparent_memcg() does the same for MGLRU. The parent is left correct, credited with exactly the folios it took over. The stale value sits on the child and nothing will correct it: folio->memcg_data now resolves to the parent, so every later update_lru_size() for those folios goes there. Dying cgroups are not freed immediately and mem_cgroup_iter() still walks them, so shrink_lruvec() keeps being called on them. get_scan_count() reads the phantom counter through lruvec_lru_size() and the scan loop then grinds through nr[] in SWAP_CLUSTER_MAX steps against an empty list, for as long as the dead cgroup lives. Under MGLRU the MGLRU scanner runs instead, but count_shadow_nodes() sums all of NR_LRU_LISTS through lruvec_lru_size() and over-budgets the shadow node limit just the same. On one 251 GiB host a sweep of every mz->lru_zone_size[] found 380 counters describing folios on no list at all: 124777314 pages, 476 GiB, 1.89x the machine's RAM, across 57 cgroups. All were on memcgs with CSS_DYING set and CSS_ONLINE clear, and parent/child pairs reported byte-identical sizes. LRU_UNEVICTABLE needs its size moved too. Its list is deliberately not spliced because lruvec_init() poisons the head - the unevictable LRU is imaginary and folios are never threaded on it - but the size is kept by lruvec_add_folio()/lruvec_del_folio() and those folios account to the parent from here on. This depends on commit bf4ade7dbd76 ("memcg: keep folio's objcg same as its node") and must not be backported ahead of it. Without that invariant a folio's objcg can belong to another node, so a folio already spliced onto the parent's list can still resolve to the child's lruvec until the objcg's node is reparented in a later iteration of memcg_reparent_objcgs(); clearing the child's counter early then lets lruvec_del_folio() underflow it and trip the WARN_ONCE()/VM_BUG_ON() in mem_cgroup_update_lru_size(). Link: https://lore.kernel.org/20260822024707.77192-1-shakeel.butt@linux.dev Fixes: 07a6e9a2c199 ("mm: vmscan: prepare for reparenting traditional LRU folios") Fixes: f304652609ea ("mm: vmscan: prepare for reparenting MGLRU folios") Signed-off-by: Shakeel Butt Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Roman Gushchin Cc: Muchun Song Cc: # After: bf4ade7dbd76: memcg: keep folio's objcg same as its node Signed-off-by: Andrew Morton commit 5d3fe91b70e7b71174d2a29eb9731a5601e7df0c Author: Enlin Mu Date: Fri Aug 21 14:40:57 2026 +0800 mm/vmscan: fix comment logic in balance_pgdat In balance_pgdat(), when the low watermark is met, processes sleeping on pfmemalloc_wait are woken up because they are able to safely make forward progress. However, the comment incorrectly states "they should not be able", which contradicts the actual code behavior. Fix this typo to accurately reflect the logic. Link: https://lore.kernel.org/20260821064057.4081-1-enlin.mu@linux.dev Signed-off-by: Enlin Mu Signed-off-by: Enlin Mu Reviewed-by: Barry Song Acked-by: Johannes Weiner Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: David Hildenbrand Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton commit d17c749d32b2d6d16981ac003ff1cae85860e819 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:27 2026 -0400 maple_tree: add helper mas_make_walkable() A check in mas_walk() was incorrect and caused inefficient use of the maple state. The same issue existed in mas_erase(), but was left unfixed. Making a helper function is the obvious answer. Link: https://lore.kernel.org/20260821192627.4085470-20-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit 4e4fe9d7271edf83ee4475e92b96aa89bd2ccd7e Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:26 2026 -0400 maple_tree: avoid extra gap calculation Prior to ending the ascension loop of larger operations like split, rebalance, and spanning store the gap in the node had been calculated. Once the node is inserted into the tree, the gap is recalculated in mas_update_gap(). This can be avoided by creating a helper for mas_update_gap() that accepts the known gap value, which reduces the operations required for gap updating path. Link: https://lore.kernel.org/20260821192627.4085470-19-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit 00f67814a14e614b749ebe54076ef1e3e6454f2b Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:25 2026 -0400 maple_tree: fix argument name in header The mas_prev_range() function takes a min and not a max. Link: https://lore.kernel.org/20260821192627.4085470-18-liam@infradead.org Fixes: 6b9e93e01020 ("maple_tree: add mas_prev_range() and mas_find_range_rev interface") Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit 18d4f8e6e6ce9b2ebd1c733777babec67356acd3 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:24 2026 -0400 maple_tree: change two GFP flags in tests The GFP flags in two tests are obviously incorrect. Make the tests correctly run by updating the GFP flags. Link: https://lore.kernel.org/all/d9cbb89faa5bdb71d451781d214a51ce8923a83e.camel@perches.com/ Link: https://lore.kernel.org/20260821192627.4085470-17-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Reported-by: Joe Perches Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit ee2487d9ba6ccf1b10c55fbae2cb0526c7b775e3 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:23 2026 -0400 maple_tree: document erase and allocations better During a discussion on the maple tree erase process and GFP flags, Jason suggested there be an amendment to the documentation to clarify the situation on allocations within the tree. The added text is an attempt to better explain that the tree may allocate, even when erasing, and provide some guidance on how to work around such issues. [akpm@linux-foundation.org: tweak mtree_erase() description, per Jason] Link: https://lore.kernel.org/all/20260617180419.GA231643@ziepe.ca/ Link: https://lore.kernel.org/20260821192627.4085470-16-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Suggested-by: Jason Gunthorpe Cc: Rik van Riel Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Joe Perches Cc: Peter Zijlstra Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit f1681380b5f928e147954d87d875f57a25df189c Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:22 2026 -0400 maple_tree: avoid mas_erase() and mtree_erase() failures Failures to remove entries using the two APIs to erase the entries may result in allocation failures. The failures may go unnoticed and an unexpected entry may remain. Instead, fall back to retrying with GFP_KERNEL | __GFP_NOFAIL so that the entry will be removed. Link: https://lore.kernel.org/20260821192627.4085470-15-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Rik van Riel Cc: Jason Gunthorpe Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Joe Perches Cc: Peter Zijlstra Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit 3f06ef1f34a7ee3b77ee03c13a0c50db8fd3c536 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:21 2026 -0400 maple_tree: document that erase may use GFP_KERNEL for allocations State that the mas_erase() and mtree_erase() functions may use GFP_KERNEL on allocation retry. Don't just depend on people reading the documentation by adding a check that will warn of the use. Link: https://lore.kernel.org/20260821192627.4085470-14-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Reviewed-by: Rik van Riel Cc: Jason Gunthorpe Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Joe Perches Cc: Peter Zijlstra Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit 35f1342e5b893a740eff2ef9ab337bfaa63ab76d Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:20 2026 -0400 maple_tree: catch race in mas_alloc_cyclic() If mas_alloc_cyclic() is called during a low memory situation, it is possible the lock may be dropped so reclaim can occur. There is a window where some other task may allocate the same id and cause the mas_insert() to fail with -EEXIST. In this scenario the function will return -EEXIST, which is not expected. Modifying the retry on mas_nomem() to re-search for a slot means that any race with other writes will not matter as the lock will be held between finding the index and writing the index. Moving the flag logic avoids cases where the flag is modified on drop lock/reacquire or when the write fails after clearing the flag. No existing users are exposed to this issue. Link: https://lore.kernel.org/20260821192627.4085470-13-liam@infradead.org Fixes: 9b6713cc7522 ("maple_tree: Add mtree_alloc_cyclic()") Signed-off-by: Liam R. Howlett (Oracle) Reported-by: Chris Mason Reviewed-by: Chuck Lever Cc: Boqun Feng Cc: Breno Leitao Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit cf1f9bae5dac2082db374a0acfe41e55aaf909e2 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:19 2026 -0400 maple_tree: add bulk parent set helper Instead of calculating the parent pointer each time for a child, cache the majority of the parent pointer and only change the slot per child. Drop the mas_set_parent() function since the last user has been removed. Testing on a tree containing 2048 entries of height 4 had an increased gain of 3.51% on nodes tracking gaps. Link: https://lore.kernel.org/20260821192627.4085470-12-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit f0a3892cd726909b0e9c30ec9b5b05f1f63a5fbf Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:18 2026 -0400 maple_tree: micro optimisation of mas_wr_store_type() Use three new local booleans instead of reading other structures. This has shown an increase of 0.62% on a 2048 entry tree of height 4. Link: https://lore.kernel.org/20260821192627.4085470-11-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit 88f87f881240da3f09541d8232255376778b8f1c Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:17 2026 -0400 maple_tree: optimise mas_wr_node_store() when not in rcu mode Clearing the entire node on the stack is unnecessary since most of the node will be overwritten anyways. Just clear what isn't used after the data is in place. Benchmarking shows a speedup of 0.67% on a height 4 tree with 2048 entries. Link: https://lore.kernel.org/20260821192627.4085470-10-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit 4bd59d5bc2c8f3e7e1bd62f3a5029471a6b531bb Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:16 2026 -0400 maple_tree: use prefetched value in mas_wr_store_type() The slot contents exist in wr_mas->content, which has less overhead than reading the slot again. Link: https://lore.kernel.org/20260821192627.4085470-9-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit 7d1e34352727cf1073eccbacd13fac075defc7a4 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:15 2026 -0400 maple_tree: clarify comments on mas_nomem() When an allocation completely fails, the return is false. If the allocation succeeds or partially succeeds, return true to indicate a retry of the operation. Note that since the lock may have been dropped, the operation is retried from the start - including potentially allocating more memory. Link: https://lore.kernel.org/20260821192627.4085470-8-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit 3526e09d8cab0aea3f3737dbeb613ccb52660359 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:14 2026 -0400 maple_tree: drop MAPLE_ALLOC_SLOTS MAPLE_ALLOC_SLOTS is no longer used, so remove it. Link: https://lore.kernel.org/20260821192627.4085470-7-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit acac9108a6a1a897f66060cafd98c452af1442c1 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:13 2026 -0400 maple_tree: drop dead code from mas_extend_spanning_null() mas_extend_spanning_null() had a clause if the end of the range being written (mas->last) is the same as the end of the existing range it is overwriting (wr_mas->r_max), action will be taken. This code path is not possible because the only calling function increments mas->last (unless it's ULONG_MAX) to walk to one beyond the write and then resets the value back to the initial value. In the case of mas->last == ULONG_MAX, then the second part of the statement will always be false - mas->last cannot be less than the node max. This code never executed and is flawed anyways (the arguments are incorrectly ordered), so removing it is the safest action. Since the code never executes, it is not fixing any issue so Fixes tag is not given. Link: https://lore.kernel.org/20260821192627.4085470-6-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit 5e0b9b71bcf405a0390ea9efc853bd07186c65a0 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:12 2026 -0400 maple_tree: documentation fix Don't include the word flag in the quotes with the actual flag. Link: https://lore.kernel.org/20260821192627.4085470-5-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit 19e269917dc416f932474686bf1fcf3e91a740bd Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:11 2026 -0400 maple_tree: add write lock checking with lockdep sequence numbers Use the lockdep sequence numbers to ensure the write lock is not dropped between write operations. The lockdep sequence is recorded on any walk that starts from the top of the tree and re-checked prior to any operation using an active node. When lockdep detects an issue, it sets debug_locks to 0 disabling further reports. __lock_sequnece() will return u32 ~0 when debug_locks is zero, and the real sequnece count cannot return such a high value as it is less than 32bits. By always updating the sequence number, regardless of lock state and by ignoring ~0 value in the sequence number will avoid ever printing a WARN_ON when lockdep sets debug_locks to 0. Link: https://lore.kernel.org/20260821192627.4085470-4-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Breno Leitao Tested-by: Breno Leitao Cc: Boqun Feng Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit 8f2109843137da8068f19a120d79e58ef3838429 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:10 2026 -0400 locking/lockdep: add sequence counter to held_lock Add an 8 bit small sequence counter to the held_lock struct to detect if the lock as been dropped and reacquired. This is useful when a data structure depends on a constant locking context, but is not able to detect locking and unlocking of the lock through its own API. Since the __lock_unpin_lock() will no longer detect underflow by casting the unsigned int to a signed int, update the casting code to use a temp variable for calculations using a signed int. Link: https://lore.kernel.org/20260821192627.4085470-3-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Suggested-by: Peter Zijlstra Cc: Ingo Molnar Cc: Will Deacon Cc: Boqun Feng Cc: Waiman Long Link: https://lore.kernel.org/all/h3tpnj5kzcrxms5picmimtkpg4aypcpip5wbd6bt2rpdj5k7eb@nhtzs3lefrkq/ Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Jason Gunthorpe Cc: Joe Perches Cc: Rik van Riel Signed-off-by: Andrew Morton commit 9e32ec53b1ec2ab28b29c82a95a65bf3d3a5d32c Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:09 2026 -0400 maple_tree: add rcu locking check when LOCKDEP is enabled Patch series "maple_tree: lock checking and clean ups", v3. In this series: 1. Try to detect lock issues A number of syzbot reports are incorrectly pointing to the mm exit as a source of the locking error. The first three patches attempt to help users detect errors in their locking - but they still have to use LOCKDEP. I guess it's still down to hope and prayers. 2. Documentation fixes The documentation was lacking clarity, there are updates to try and help the users, especially around the erase() cases. 3. Two benign issues The cyclic allocator may have a race, although no in-kernel user can hit it. The erase functions may cause allocation issues if used with the incorrect locking type, but none are present in-tree. 4. The erase gfp uses mas_erase() and mtree_erase() do not take a gfp argument. To improve reliability of the erase, the first attempt to allocate will be GFP_NOWAIT, followed by a retry (if necessary of GFP_KERNEL | GFP_NOFAIL. This will ensure the data is gone. I've updated the documentation to make it more clear as well. mas_store() is not addressed in the same way, but may need to be updated at a later date, but that may require changing callers so it is out of scope here. Beyond these goals there are some test fixes, some general speed-up patches targeting extra work and cycles, and dropping dead code. This patch (of 19): When CONFIG_LOCKDEP and CONFIG_RCU_STRICT_GRACE_PERIOD is enabled, check for rcu locking issues by recording the grace period in the maple state and checking the rcu window is still valid whenever the maple state is reused with a state that is not MA_START or MA_PAUSED. Link: https://lore.kernel.org/20260821192627.4085470-1-liam@infradead.org Link: https://lore.kernel.org/20260821192627.4085470-2-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton commit d16e52a9ba9ed5060f97ed3191017a21b5fc25a2 Author: Anshuman Date: Wed Aug 19 17:44:26 2026 +0530 selftests/mm: check stat() return value in khugepaged get_finfo() get_finfo() calls stat() to get metadata about the target directory, but never checks the return value. On failure, stat() returns -1 and leaves path_stat unmodified, so path_stat.st_mode may contain uninitialized stack data. The code then checks S_ISDIR(path_stat.st_mode) against this potentially garbage value. This can produce a misleading "Not a directory" error when the real problem is a nonexistent or inaccessible path, or, in the worst case, the check could pass by chance on garbage data and let the function continue using an invalid path_stat for the rest of its logic. Check the return value and fail with a clear error message if stat() fails, matching the error-handling style already used for statfs() and read_file() later in the same function. Link: https://lore.kernel.org/20260819121426.49500-1-anshumantewari123@gmail.com Signed-off-by: Anshuman Reviewed-by: Andrew Morton Reviewed-by: SJ Park Reviewed-by: Sarthak Sharma Acked-by: David Hildenbrand (Arm) Cc: Lorenzo Stoakes Cc: Shuah Khan Signed-off-by: Andrew Morton commit f9dc428249ed962a70acf301f01eae8578449161 Author: Breno Leitao Date: Tue Aug 18 02:03:40 2026 -0700 mm, swap: ratelimit bad swap entry reports A corrupt page table hands the same bogus entry to get_swap_device() on every access to the mapping, and every rejection is logged. One machine logged 6185620 copies of the same line in a few hours. swap_dup_entry_direct() prints the same message from the fork path, once per call: the WARN_ON_ONCE() guarding it warns once, the pr_err() inside does not. Rate limit all three prints. Link: https://lore.kernel.org/20260818-swap_part_one-v1-1-a4fc58119fc0@debian.org Fixes: 23b230ba8ac3 ("mm/swap: print bad swap offset entry in get_swap_device") Signed-off-by: Breno Leitao Reviewed-by: Barry Song Reviewed-by: Nhat Pham Acked-by: Kairui Song Acked-by: David Hildenbrand (Arm) Cc: Baoquan He Cc: Chris Li Cc: Kemeng Shi Cc: Miaohe Lin Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton commit c7a4e939f87cc75a9a664485b10c0bf7db632156 Author: Anshuman Date: Tue Aug 18 19:02:06 2026 +0530 selftests/mm: fix unchecked ftruncate return value in soft-dirty test test_mprotect() calls ftruncate() to resize the backing file before mmap()'ing it, but never checks the return value. If ftruncate() fails, the file may remain shorter than the requested mapping size. The subsequent mmap() with MAP_SHARED can still succeed in this case, but the very next line writes directly into the mapped memory (*map = 1), which can trigger SIGBUS if the mapping extends beyond the actual file size. Check the return value and fail cleanly with ksft_exit_fail_msg() if ftruncate() fails, matching the error-handling style already used for the mmap() call immediately below it. Link: https://lore.kernel.org/20260818133206.39503-1-anshumantewari123@gmail.com Signed-off-by: Anshuman Reviewed-by: Andrew Morton Reviewed-by: Sarthak Sharma Cc: David Hildenbrand Cc: Shuah Khan Signed-off-by: Andrew Morton commit 48863da10ba1ffe3889fc5945d3292b4e4bf1c60 Author: Song Hu Date: Tue Aug 18 21:01:35 2026 +0800 mm: memcg: release the css reference when a stock slot empties consume_stock() can drive a stock slot's nr_pages to zero while its cached[] pointer stays set, so the slot keeps pinning the css reference that refill_stock() took. The offlining drain only flushes slots with cached pages, so the reference is never released unless the slot happens to be displaced by an unrelated charge or by CPU hotplug, and the memcg lingers in the dying state - up to NR_MEMCG_STOCK (7) of them per CPU under container churn. Keeping the slot populated past the last page only saves a css_get()/css_put() pair on the next charge of the same memcg, and costs more than that: the offlining drain has to know about empty slots, and refill_stock() cannot reuse them either, so a charge under a different memcg evicts a live batch through the drain_idx rotation instead. Drop the reference in consume_stock() when the slot empties. Empty slots stop existing, so is_memcg_drain_needed() and the drain path stay as they are, and refill_stock() reuses emptied slots directly. The cost is one refcount pair per emptied slot, at most once per MEMCG_CHARGE_BATCH pages. Link: https://lore.kernel.org/20260818130135.154315-1-husong@kylinos.cn Fixes: d1a05b6973c7 ("memcg: do not try to drain per-cpu caches without pages") Signed-off-by: Song Hu Acked-by: Michal Hocko Acked-by: Shakeel Butt Reviewed-by: Joshua Hahn Cc: Audra Mitchell Cc: Johannes Weiner Cc: Matthew Wilcox (Oracle) Cc: Muchun Song Cc: Roman Gushchin Cc: Nico Pache Signed-off-by: Andrew Morton commit dd1638dfbb1c48f13cfb4f4f4e55e6570e25384b Author: Kiryl Shutsemau (Meta) Date: Tue Aug 18 12:50:26 2026 +0100 mm: include swap.h in swapops.h swapops.h uses MAX_SWAPFILES_SHIFT, SWP_MIGRATION_READ and SWP_PTE_MARKER, all of which swap.h defines, but does not include swap.h. It compiles only where the translation unit pulled swap.h in first. leafops.h includes swapops.h on the line above swap.h, so a file whose include list reaches leafops.h before swap.h gets: In file included from include/linux/leafops.h:11: include/linux/swapops.h:88:21: error: use of undeclared identifier 'MAX_SWAPFILES_SHIFT' A header that uses a definition has to include the header that provides it. Link: https://lore.kernel.org/20260818115026.656406-1-kirill@shutemov.name Signed-off-by: Kiryl Shutsemau (Meta) Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202608181757.mza9RRj7-lkp@intel.com/ Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Barry Song Cc: Baoquan He Cc: Chris Li Cc: Kairui Song Cc: Kemeng Shi Cc: Nhat Pham Signed-off-by: Andrew Morton commit 9add2cc22de6c56881eabd9f1bd6c85bf98157d0 Author: Hui Su Date: Mon Aug 17 14:08:46 2026 +0800 mm/migrate_device: fix cache flush when replacing huge zero PMD migrate_vma_insert_huge_pmd_page() calls flush_cache_page() before replacing an existing huge zero PMD. However, the third argument to flush_cache_page() is a PFN, while addr + HPAGE_PMD_SIZE is an end virtual address. More importantly, the mapping being invalidated is PMD-sized rather than PAGE_SIZE-sized. Flush the whole PMD range with flush_cache_range(), matching other huge PMD invalidation paths. There is no userspace-visible effect today. The architectures that currently enable ARCH_ENABLE_THP_MIGRATION use no-op implementations of flush_cache_page()/flush_cache_range(). 32-bit ARM has non-trivial implementations, but does not enable ARCH_ENABLE_THP_MIGRATION. So this appears to be a latent API misuse rather than a currently observable bug, and I don't think a stable backport is necessary. Link: https://lore.kernel.org/20260817060845.377800-2-sh_def@163.com Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages") Signed-off-by: Hui Su Reviewed-by: Balbir Singh Reviewed-by: Zi Yan Acked-by: David Hildenbrand (Arm) Cc: Alistair Popple Cc: Byungchul Park Cc: Gregory Price Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Signed-off-by: Andrew Morton commit dd14e6cd33927fff38c78ce55c436bc0959ace27 Author: Hongfu Li Date: Mon Aug 17 16:06:16 2026 +0800 selftests/mm: drop redundant open() in mprotect_tests() Remove duplicate open() for local pagemap_fd in mprotect_tests() that shadows the global pagemap_fd already opened in main(). The local fd is never used in the function. Link: https://lore.kernel.org/20260817080616.52946-1-hongfu.li@linux.dev Signed-off-by: Hongfu Li Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Muhammad Usama Anjum Reviewed-by: SJ Park Acked-by: David Hildenbrand (Arm) Reviewed-by: Anshuman Khandual Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit c1afbd5de131f5e3c4fc7559acf055f8d9d86868 Author: Usama Arif Date: Mon Aug 17 03:38:35 2026 -0700 mm/memcontrol: avoid false sharing between vmstats and events Moving v1 userspace eventfd handling into memcontrol-v1.c shrank struct vmpressure from 112 to 24 bytes when CONFIG_MEMCG_V1 is disabled. This moved memory_events_local[MEMCG_SWAP_FAIL] and the hot vmstats_percpu pointer onto the same cacheline. The stress-ng mremap stressor exercises MADV_PAGEOUT with swap disabled, generating about 20 million MEMCG_SWAP_FAIL updates per 60-second run on a 176-CPU test system. Those writes bounce the line while memcg statistics paths load vmstats_percpu. Move cgwb_list into the existing alignment gap and cacheline-align vmstats_percpu. This separates the pointer from the event counters without increasing the size of struct mem_cgroup in the tested configuration. The blamed commit reduced median mremap throughput by 4.38% on the test system with one socket. The patched kernel brings the performance to within 0.5% of the parent which is within the observed boot-to-boot spread (up to 1.2%). Link: https://lore.kernel.org/20260817103835.2937733-1-usama.arif@linux.dev Fixes: ea928e9e18da ("mm/vmpressure: move v1 userspace eventfd code into memcontrol-v1.c") Signed-off-by: Usama Arif Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202608131743.c6a7dda4-lkp@intel.com Tested-by: kernel test robot Link: http://lore.kernel.org/aoAABX59IzUXz/Rv@ly-workstation Acked-by: Shakeel Butt Acked-by: Michal Hocko Cc: David Hildenbrand Cc: Johannes Weiner Cc: Muchun Song Cc: Roman Gushchin Cc: Yi Lai Signed-off-by: Andrew Morton commit f2b1cb39d5ccab090d8353788f186f7e7a1fffd4 Author: Nathan Chancellor Date: Thu Aug 13 20:12:55 2026 -0700 arch_numa: avoid false positive fortify warning in setup_node_to_cpumask_map() When building ARCH=riscv using clang with CONFIG_FORTIFY_SOURCE and CONFIG_UBSAN_BOUNDS enabled, CONFIG_NR_CPUS > 64, and the default value of 2 for CONFIG_NODES_SHIFT, there is a compiletime warning from the fortify routines. In file included from mm/arch_numa.c:11: In file included from include/linux/acpi.h:14: In file included from include/linux/resource_ext.h:11: In file included from include/linux/slab.h:17: In file included from include/linux/gfp.h:7: In file included from include/linux/mmzone.h:8: In file included from include/linux/spinlock.h:60: In file included from include/linux/interrupt_rc.h:17: In file included from include/linux/smp.h:13: In file included from include/linux/cpumask.h:11: In file included from include/linux/bitmap.h:13: In file included from include/linux/string.h:383: include/linux/fortify-string.h:430:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribue-warning] 430 | __write_overflow_field(p_size_field, size); | ^ include/linux/fortify-string.h:430:4: note: called by function 'fortify_memset_chk(unsigned long, unsigned long, unsigned long)' include/linux/bitmap.h:248:3: note: inlined by function 'setup_node_to_cpumask_map' 248 | memset(dst, 0, len); | ^ include/linux/fortify-string.h:462:25: note: expanded from macro 'memset' 462 | #define memset(p, c, s) __fortify_memset_chk(p, c, s, \ | ^ include/linux/fortify-string.h:453:2: note: expanded from macro '__fortify_memset_chk' 453 | fortify_memset_chk(__fortify_size, p_size, p_size_field), \ | ^ include/linux/fortify-string.h:430:4: note: use '-gline-directives-only' (implied by '-g1') or higher for more accurate inlining chain locations 430 | __write_overflow_field(p_size_field, size); | ^ 1 warning generated. In this configuration, MAX_NUMNODES is 4. clang unrolls the for loop in setup_node_to_cpumask_map() past this, which triggers the fortify check when accessing node_to_cpumask_map on the theoretical fifth loop iteration because it would be an out of bounds write. Make it clear to clang that nr_node_ids is bounded by MAX_NUMNODES due to the logic in setup_nr_node_ids() by early returning in setup_node_to_cpumask_map() should that condition be violated. Link: https://lore.kernel.org/20260813-arch_numa-avoid-fortify-warning-v2-1-093ad97a78df@kernel.org Signed-off-by: Nathan Chancellor Closes: https://github.com/ClangBuiltLinux/linux/issues/2174 Reviewed-by: Mike Rapoport (Microsoft) Cc: Kees Cook Cc: Bill Wendling Cc: Justin Stitt Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Signed-off-by: Andrew Morton commit f52b3b89faba20cb347f4b908f649fa6351ff10d Author: Eric Kim Date: Fri Aug 14 15:30:51 2026 +0900 mm/rmap: synchronize lock and unlock target in anon_vma_clone Currently, in anon_vma_clone(), src vma's anon_vma is assigned to active_anon_vma and is used when unlocking anon_vma after linking new AVCs. However, the anon_vma is locked using src->anon_vma, instead of active_anon_vma, making the lock and unlock target inconsistent. Use active_anon_vma for both locking and unlocking. Link: https://lore.kernel.org/OS7PR01MB139142FE16EC63B892559D40496DA2@OS7PR01MB13914.jpnprd01.prod.outlook.com Signed-off-by: Eric Kim Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang Cc: David Hildenbrand Cc: Harry Yoo Cc: Jann Horn Cc: Liam R. Howlett Cc: Rik van Riel Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 556147fc27b5d9c3c731ae4c5599457831102735 Author: Andrew Morton Date: Mon Aug 10 13:16:37 2026 -0700 mm/hmm.c:hmm_do_fault(): suppress sparse warning mm/hmm.c:673 hmm_do_fault() error: we previously assumed 'hmm_vma_walk->locked' could be null (see line 654) Stanislav says this can't happen. Waste a few cycles to make the warning go away. [akpm@linux-foundation.org: WARN_ON_ONCE() if the handler didn't set ->locked, per Stanislav] Link: https://lore.kernel.org/anu1N-DOnQwxO1kF@skinsburskii Fixes: 121170831228 ("mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support") Reported-by: kernel test robot Closes: https://lore.kernel.org/202608101053.PhnVUM4u-lkp@intel.com Cc: Stanislav Kinsburskii Cc: David Hildenbrand Signed-off-by: Andrew Morton commit a1b114b4cec1263e693cd6e7aa5c8321295143c6 Author: Xie Yuanbin Date: Thu Aug 13 21:49:16 2026 +0800 mm/Kconfig: make MEMORY_FAILURE select MIGRATION For embedded devices, lacking support for NUMA, memory hotplug/hotremove, CMA and huge pages is a quite common scenario. In this scenario, the demand for contiguous physical memory allocation is very low. To reduce the kernel image size, some devices disable the compaction. However, their SoCs do support DDR ECC, meaning that memory-failure may be needed. Migration is very useful for soft_offline_page() in memory-failure, which may be triggered by correctable memory errors. Most anonymous and file-mapped faulty pages can be migrated to other healthy pages. Currently, MEMORY_FAILURE does not explicitly select MIGRATION. When COMPACTION, MEMORY_HOTREMOVE, NUMA_MIGRATION and CMA are all disabled, MEMORY_FAILURE can be enabled, but MIGRATION cannot be selected. Make MEMORY_FAILURE select MIGRATION to handle this situation. Link: https://lore.kernel.org/20260813134916.292733-1-xieyuanbin1@huawei.com Signed-off-by: Xie Yuanbin Suggested-by: Mike Rapoport Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Mike Rapoport (Microsoft) Acked-by: Zi Yan Acked-by: David Hildenbrand (Arm) Acked-by: Miaohe Lin Cc: Alistair Popple Cc: "Borislav Petkov (AMD)" Cc: Byungchul Park Cc: David Hildenbrand Cc: Gregory Price Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Liam R. Howlett Cc: liaohua Cc: "Luck, Tony" Cc: Matthew Brost Cc: Michal Hocko Cc: Naoya Horiguchi Cc: Rakie Kim Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Yuanbin Xie Signed-off-by: Andrew Morton commit 0d0878fd7c9b49b8eff95c4426a2121c5f8f31cc Author: Qiang Liu Date: Wed Aug 12 17:28:56 2026 +0800 lib/test_hmm: fix garbage pfn and wrong direction in devmem fault debug Move pr_debug() inside the `if (dpage)` block to avoid printing garbage pfn for NULL dpage, and correct the direction label from "sys to dev" to "dev to sys". Link: https://lore.kernel.org/20260812092856.55296-1-liuqiangneo@163.com Signed-off-by: Qiang Liu Assisted-by: Qoder:Qwen-3.8-MAX-Preview Cc: Jason Gunthorpe Cc: Leon Romanovsky Signed-off-by: Andrew Morton commit f525001b3309a0decdcdcdaeceafd7ab9dc927fe Author: Tejun Heo Date: Wed Aug 12 09:47:43 2026 -1000 percpu: drop CONFIG_DEBUG_FORCE_WEAK_PER_CPU alpha requires percpu variables in modules to be defined as weak so that the compiler generates GOT based external references for them. This puts two extra restrictions on percpu variable definitions. The symbol must be globally unique even when static and a static percpu variable can't be defined inside a function. DEBUG_FORCE_WEAK_PER_CPU exists to give generic code build coverage for these restrictions without building for alpha. MEM_ALLOC_PROFILING defines a static percpu counter at each allocation call site and thus can't be built with weak percpu definitions, so it depends on !DEBUG_FORCE_WEAK_PER_CPU. As allmodconfig enables DEBUG_FORCE_WEAK_PER_CPU, this knocks MEM_ALLOC_PROFILING out of allmodconfig build coverage. allmodconfig coverage for MEM_ALLOC_PROFILING is worth more than build coverage for restrictions which only matter to alpha module builds. Drop DEBUG_FORCE_WEAK_PER_CPU. Restriction violations will now show up only on alpha builds. Link: https://lore.kernel.org/178656406317.2437052.7257990869957704195@slm.duckdns.org Signed-off-by: Tejun Heo Reported-by: Andrew Morton Reviewed-by: Suren Baghdasaryan Acked-by: Gabriele Monaco [include/rv/da_monitor.h] Cc: Dennis Zhou Cc: Kent Overstreet Cc: Steven Rostedt Signed-off-by: Andrew Morton commit f7e698e326b239a91ea15844817551921209e826 Author: Kairui Song Date: Wed Aug 12 20:22:39 2026 +0800 mm/mglru: fix and remove redundant unevictable folio handling sort_folio() has a shortcut for moving folios that are no longer evictable but are still sitting on a generation list. However, this shortcut is buggy. It does not follow the PG_lru usage convention, and it has a more serious issue. Unevictable folios are not threaded on lists[LRU_UNEVICTABLE], so that folio->lru can be reused to hold folio->mlock_count (see the comment in lruvec_init()). Hence lruvec_add_folio() skips the list_add() for them, and every other place that turns a folio unevictable initialises mlock_count explicitly: lru_add() sets it to 0, __mlock_folio() and __mlock_new_folio() set it to !!folio_test_mlocked(folio). sort_folio() sets nothing, and the lru_gen_del_folio() right above it may have already poisoned folio->lru via list_del(), so mlock_count ends up aliasing LIST_POISON2, which reads as 0x122, i.e. 290. The result is user visible. On munlock, __munlock_folio() decrements that bogus count, finds it still non-zero and bails out before clearing PG_mlocked, so the folio remains unevictable and the Mlocked accounting stays inflated until the folio is freed. The shortcut also touches the LRU flags in the wrong order. It calls lru_gen_del_folio() while PG_lru is still set, so a concurrent folio_test_clear_lru() (e.g. compaction, folio_isolate_lru()) can succeed on a folio that has already been taken off the generation list, which may lead to unexpected behavior. So fix it by isolating them as common folios and letting the generic shrink path cull them. This matches the classical LRU behavior, and there should be no visible effect on the generic eviction or isolation behavior. There is no performance concern either, such a folio goes through this once, and then it is off the generation lists for good. Link: https://lore.kernel.org/20260812-mglru-mlock-fix-v2-1-a3fec5853c08@tencent.com Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") Signed-off-by: Kairui Song Reviewed-by: Barry Song Reviewed-by: Baolin Wang Cc: Axel Rasmussen Cc: Brian Geffon Cc: David Hildenbrand Cc: Jan Alexander Steffens (heftig) Cc: Johannes Weiner Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Oleksandr Natalenko Cc: Shakeel Butt Cc: Steven Barrett Cc: Suleiman Souhlal Cc: Wei Xu Cc: Yuanchu Xie Cc: Yu Zhao Cc: Signed-off-by: Andrew Morton commit 73b5d07990a0e6ea9cdf2c07fa8fbc865d398c1d Author: Song Hu Date: Wed Aug 12 15:57:39 2026 +0800 Docs/mm: fix outdated "radix tree" in page_migration Steps 7 and 9 of the migration description still say "radix tree", unlike steps 5 and 11 which already use "i_pages lock". The page cache moved to the XArray at mapping->i_pages long ago. Use "page cache tree" for the two remaining references. Link: https://lore.kernel.org/20260812075739.325441-1-husong@kylinos.cn Signed-off-by: Song Hu Cc: David Hildenbrand Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Randy Dunlap Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Matthew Wilcox Cc: Jan Kara Signed-off-by: Andrew Morton commit 2a0be246e342e239ef91d28e2658b6bf508cc065 Author: Nico Pache (Red Hat) Date: Tue Aug 11 06:48:39 2026 -0600 mm: Documentation: clarify where the mTHP stats live The note about khugepaged counters references /proc/vmstat for the PMD case, but never mentions where the mTHPs stats can be found (i.e.: /sys/kernel/mm/transparent_hugepage/hugepages-kB/stats/) Add a small addition to this section for clarity. Also fix a missing period while we are at it. Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-7-ddac39d61c4a@linux.dev Signed-off-by: Nico Pache (Red Hat) Reviewed-by: Baolin Wang Suggested-by: Lorenzo Stoakes Acked-by: David Hildenbrand (Arm) Reviewed-by: Zi Yan Acked-by: Pedro Falcato Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang Cc: Barry Song Cc: Dev Jain Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Usama Arif Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 27490db7ec048175522368ac0aa2e99249e5c48d Author: Nico Pache (Red Hat) Date: Tue Aug 11 06:48:38 2026 -0600 mm/khugepaged: unmap pte before releasing vma write lock We are currently dropping the anon_vma write lock before unmapping the PTE. Although this is safe, due to us still holding the mmap_write_lock, its safer and less confusing to switch the order of these two operations. Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-6-ddac39d61c4a@linux.dev Signed-off-by: Nico Pache (Red Hat) Suggested-by: David Hildenbrand Acked-by: David Hildenbrand (Arm) Reviewed-by: Zi Yan Reviewed-by: Baolin Wang Acked-by: Pedro Falcato Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang Cc: Barry Song Cc: Dev Jain Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Usama Arif Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit cc044178edc9d7b5cd291ef0e2daf060379e6447 Author: Nico Pache (Red Hat) Date: Tue Aug 11 06:48:36 2026 -0600 mm/khugepaged: fix outdated comments Fix comment in collapse_scan_pmd() that still described the old folio_mapcount() > folio_ref_count() check and a "512" false-positive scenario. The code now uses folio_expected_ref_count() != folio_ref_count() which doesn't suffer from the same limitation. Fix comment in collapse_huge_page() that referenced ptep_clear_flush, when the code actually uses pmdp_collapse_flush. Fix comment in __collapse_huge_page_swapin() that referenced the old function name khugepaged_scan_pmd, now collapse_scan_pmd. Also clean up some simple typos and stale terminology (mmap_sem -> mmap_lock, PG_lock -> folio lock, page -> folio, grammar). We also clarify a comment regarding where the max_ptes_none check is deferred to in mthp_collapse() from the original collapse_scan_pmd check. Update all comments that references a function to include parentheses. [nico.pache@linux.dev: fix outdated comments] Link: https://lore.kernel.org/1c96e2f3-802f-472b-81e6-4af17a721a3c@linux.dev Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-4-ddac39d61c4a@linux.dev Signed-off-by: Nico Pache (Red Hat) Acked-by: Usama Arif Assisted-by: Cursor(claude-sonnet-4):4.6 Acked-by: David Hildenbrand (Arm) Reviewed-by: Zi Yan Acked-by: Pedro Falcato Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 948ec48e568649bc639088c605515afbc1bf9e18 Author: Nico Pache (Red Hat) Date: Tue Aug 11 06:48:35 2026 -0600 mm/khugepaged: introduce a count_collapse_event() helper Provide a simple helper function to help reduce a often used, and duplicate pattern across the khugepaged code. When collapsing to a PMD we need to record a vm_event and the mTHP_stat event. When doing mTHP collapse we only update the mTHP stat. Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-3-ddac39d61c4a@linux.dev Signed-off-by: Nico Pache (Red Hat) Reviewed-by: Baolin Wang Acked-by: David Hildenbrand (Arm) Acked-by: Usama Arif Reviewed-by: Zi Yan Reviewed-by: Pedro Falcato Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang Cc: Barry Song Cc: Dev Jain Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit e8122742cfb4e28f3a499c09c08f968a692647d4 Author: Nico Pache (Red Hat) Date: Tue Aug 11 06:48:34 2026 -0600 mm/khugepaged: extract reference check into folio_pte_referenced() helper This change deduplicates the "is this PTE/folio referenced enough to be considered for a collapse" condition that was repeated in both __collapse_huge_page_isolate() and collapse_scan_pmd(), extracting it into a single inline helper function. Also move the comment and use it as the function header. While we are at it, updated the comment to clarify that a young pte is a recently accessed one. [nico.pache@linux.dev: drop the trivial helper kerneldoc and inline marker per review] Link: https://lore.kernel.org/9038f552-926b-4c4c-b023-69271f45e3d5@linux.dev Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-2-ddac39d61c4a@linux.dev Signed-off-by: Nico Pache (Red Hat) Acked-by: Usama Arif Acked-by: David Hildenbrand (Arm) Reviewed-by: Zi Yan Reviewed-by: Baolin Wang Reviewed-by: Lance Yang Cc: Barry Song Cc: Dev Jain Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Lorenzo Stoakes (ARM) Cc: Michal Hocko Cc: Mike Rapoport Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Pedro Falcato Signed-off-by: Andrew Morton commit b86a7d03ea5368a0943afe7e0648ce3edf83eef8 Author: Nico Pache (Red Hat) Date: Tue Aug 11 06:48:33 2026 -0600 mm/khugepaged: refactor per-scan state clearing into collapse_control_init_scan() Patch series "mm/khugepaged: several cleanups", v4. The following changes stem from a number of reviews during my khugepaged mTHP support series [1]. Some of these are minor code cleanups, issues or reviews that we decided to deferred to a followup series, or in the case of the more major patch of the series, changes [2] Lance Yang attempted while my series was in-flight and we decided to wait till later to try. The first 3 patches introduce helper functions to increase code reuse and readability. This includes a per-scan state clearing function, extracting the young page check into a helper, and a count_collapse_event() function to reduce a repetative pattern used across mTHP collapse. The 4th patch was the byproduct of me throwing Claude at all the comments in khugepaged verifying and looking for any outdated info. The 5th patch is based on Lance Yang's commit series [2] trying to extract the PTE state checking into a helper function. This required a bit of rewriting due to differences after mTHP collapse was introduced. I also took into account the changes requested during his patches review cycle. The remaining 2 patches were review points during my mTHP series that we agreed can be deferred to a later series. Thank you to those whos reviews and work I leveraged to achieve these cleanups. This patch (of 6): Extract the repeated clearing of node_load, alloc_nmask, and mthp_present_ptes into a helper to reduce duplication in collapse_scan_pmd() and collapse_scan_file(). Althought file scans do not current use the bitmap, they will in the future, and clearing it now is harmless. Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-0-ddac39d61c4a@linux.dev Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-1-ddac39d61c4a@linux.dev Link: https://lore.kernel.org/all/20260605161422.213817-1-npache@redhat.com/ [1] Link: https://lore.kernel.org/all/20251008043748.45554-1-lance.yang@linux.dev/ [2] Signed-off-by: Nico Pache (Red Hat) Reviewed-by: Baolin Wang Acked-by: Usama Arif Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Zi Yan Reviewed-by: Pedro Falcato Reviewed-by: Lance Yang Cc: Barry Song Cc: Dev Jain Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 3372b6631b52b3442a1e3fe379bacc433bd7eec8 Author: Lorenzo Stoakes (ARM) Date: Wed Aug 12 08:43:31 2026 +0100 MAINTAINERS: add drivers/char/mem.c to mm misc, memory mapping sections This file is a 'special' driver that implements /dev/zero and /dev/mem among other things. As such it makes sense for mm to be cc'd on mails and to have some say in how things are changed there, so add it to the mm misc section. Uniquely, it provides the 'old way' of obtaining an anonymous mapping - MAP_PRIVATE of /dev/zero - so is directly tied to memory mapping, therefore also add it to the memory mapping section. scripts/get_maintainer.pl copes perfectly fine with files in multiple sections so everything should work correctly. Link: https://lore.kernel.org/20260812-add-drivers-mem-to-mm-maintainers-v1-1-6218b861f4c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Acked-by: Mike Rapoport (Microsoft) Acked-by: SJ Park Reviewed-by: Anshuman Khandual Cc: Arnd Bergmann Cc: Jann Horn Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Pedro Falcato Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 508537753b5ca06c1de9658239648510c9a999cc Author: Hui Zhu Date: Wed Aug 12 14:59:33 2026 +0800 mm/mglru: fix young counter undercount for large folios lru_gen_look_around() feeds its local 'young' counter into suitable_to_scan(), which decides whether the current PMD is added to the bloom filter and checked again on the next aging round. The folio triggering the look-around is processed at function entry: test_and_clear_young_ptes_notify() clears the accessed bits of the nr PTEs it maps, and the function bails out if none of them is young. The loop that follows therefore never recounts this folio, since its accessed bits are already cleared. Every other young folio the loop finds is accounted as a batch (young += nr), where nr is the number of consecutive PTEs it maps. The triggering folio, however, still contributes a fixed young = 1 regardless of its size -- a leftover from before PTE batching. A large triggering folio is thus accounted inconsistently with the rest of the window. Initialize young to nr so the triggering folio is accounted the same way as any other young folio batch in the loop. Note this is a deliberate overestimate, not a measured value. The test-and-clear helper only reports whether any of the nr PTEs is young, not how many were accessed, so the true number of accessed PTEs in a large folio is unknown and can be smaller than nr. Counting the full batch is intentional: the mm core tracks accessed/dirty state per folio, not per page, so a per-page count is neither obtainable nor meaningful. The only consumer is suitable_to_scan(), and the bloom filter it feeds tolerates error. Overestimating is also the safe direction: at worst a PMD that saw little access is rescanned, whereas underestimating could skip rescanning a PMD whose folios are still hot and reclaim them incorrectly. (nr here is the PTE batch size, not necessarily folio_nr_pages().) Link: https://lore.kernel.org/20260813061019.49806-1-hui.zhu@linux.dev Link: https://lore.kernel.org/20260812065933.103627-1-hui.zhu@linux.dev Fixes: 56e5b60b2114 ("mm: support batched checking of the young flag for MGLRU") Signed-off-by: Hui Zhu Reviewed-by: Baolin Wang Reviewed-by: Barry Song Cc: Axel Rasmussen Cc: David Hildenbrand Cc: Johannes Weiner Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Shakeel Butt Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton commit 6f615890b84820c2e223bd14238319f0415eae88 Author: Wilson Felipe Pereira Date: Tue Aug 11 05:14:11 2026 +0000 selftests/cgroup: test_zswap: skip test_no_kmem_bypass if debugfs is unavailable test_no_kmem_bypass() needs to read /sys/kernel/debug/zswap/stored_pages via get_zswap_stored_pages() to verify that compressed pages are charged to the memcg. When running in an environment where debugfs is not mounted or CONFIG_DEBUG_FS is disabled, get_zswap_stored_pages() fails, causing the loop to terminate early and report a false negative (KSFT_FAIL). Selftests should not fail if debugfs is unavailable, and it should print a message when it is skipped. While I'm here, also add a warning message if the test is being skipped due to totalram size and make the check for totalram more readable. [akpm@linux-foundation.org: clarify debugfs-unavailable error message] Link: https://lore.kernel.org/20260812050848.848882-1-wfelipe@google.com Link: https://lore.kernel.org/20260811051434.3805648-1-wfelipe@google.com Signed-off-by: Wilson Felipe Pereira Reviewed-by: Anshuman Khandual Reviewed-by: SJ Park Cc: Chengming Zhou Cc: Johannes Weiner Cc: Michal Koutný Cc: Nhat Pham Cc: Shuah Khan Cc: Tejun Heo Signed-off-by: Andrew Morton commit bd1ad3cf07d11fbf203ac362222807113321dfbb Author: Hui Su Date: Tue Aug 11 15:33:32 2026 +0800 kasan: fix quarantine_size accounting during cache removal quarantine_size tracks the total number of bytes stored in global_quarantine[]. It is incremented when per-CPU quarantine objects are moved into the global quarantine and decremented when a global batch is evicted by kasan_quarantine_reduce(). kasan_quarantine_remove_cache() also removes objects from the global quarantine. qlist_move_cache() rebuilds the source batch and updates its .bytes field, but quarantine_size is not adjusted accordingly. As a result, quarantine_size remains over-counted by the size of the removed objects. The stale accounting accumulates across cache removals. Once the inflated value exceeds quarantine_max_size, kasan_quarantine_reduce() can evict a batch even though the actual number of bytes in global_quarantine[] is still below quarantine_max_size, shortening the quarantine window. Fix the accounting by recording each batch's size before qlist_move_cache() and subtracting the number of bytes actually removed from quarantine_size while holding quarantine_lock. A KUnit reproducer used during testing observed the over-count grow by 4698864 bytes after one kasan_quarantine_remove_cache() call with the fix reverted. With this change applied, the over-count did not grow. Link: https://lore.kernel.org/20260811073332.1351893-1-sh_def@163.com Fixes: 64abdcb24351 ("kasan: eliminate long stalls during quarantine reduction") Signed-off-by: Hui Su Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260808031459.3032812-1-sh_def%40163.com Reviewed-by: Andrey Ryabinin Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Dmitry Vyukov Cc: Vincenzo Frascino Signed-off-by: Andrew Morton commit 22779ae8175aad7c04827db44e934e53bf2bd2d4 Author: Christoph Hellwig Date: Thu Jul 23 07:46:06 2026 +0200 mm/swap: move swap_ops into file systems for file system-based swap Currently swap to and from file systems goes through two indirect calls between the swap ops and the swap_rw method. Reduce this by directly providing the swap_ops from the file system. For this refactor swap_fs_submit into a swap_fs_prepare_rw helper that initializes the iov_iter on the callers stack so that file systems can call it directly, and use that to initialize file system specific ops in the NFS and SMB clients, which then get passed to swap_fs_activate. Link: https://lore.kernel.org/20260723054622.3460249-4-hch@lst.de Signed-off-by: Christoph Hellwig Acked-by: Chris Li Cc: Baoquan He Cc: Kairui Song Cc: Kairui Song Cc: Kemeng Shi Cc: Nhat Pham Cc: Steve French Cc: Usama Arif Signed-off-by: Andrew Morton commit 52d85ca90c7db41f8cfc72e5fe7dc62c2f983032 Author: Christoph Hellwig Date: Thu Jul 23 07:46:05 2026 +0200 mm/swap: add a new swap_ops.h header to allow for pluggable swap ops Add a new header to declare the swap_iocb, swap_ops and swap_ctx to allow for swap_ops implementations outside of mm/page_io.c. This will be used to remove the double indirection for file system-based swap. There is no functional change, just a move of the declarations. Note that there already is a swapops.h header, which is totally unrelated to struct swap_ops. The close naming is a bit unfortunate, but I could not think of a better name for this header. Link: https://lore.kernel.org/20260723054622.3460249-3-hch@lst.de Signed-off-by: Christoph Hellwig Acked-by: Chris Li Cc: Baoquan He Cc: Kairui Song Cc: Kairui Song Cc: Kemeng Shi Cc: Nhat Pham Cc: Steve French Cc: Usama Arif Signed-off-by: Andrew Morton commit 3c5194eb2e644b8360a368a1637bb2851be0a9c3 Author: Christoph Hellwig Date: Thu Jul 23 07:46:04 2026 +0200 mm/swap: revert to single-folio writes for synchronous swap devices Patch series "swap_ops updates", v2. This series is a follow on to the swap ops series now in mm-unstable. The first patch reintroduces direct folio writes for synchronous swap files, the other two remove the double indirect for file system based swap. This patch (of 3): Kairui Song reported that zram benefits from submitting each folio directly instead of batching up I/O because the classic LRU scanning benefits from clearing the folio writeback bit in the scan loop. Accommodate that by kicking off writes for synchronous devices for each iteration. Link: https://lore.kernel.org/20260723054622.3460249-1-hch@lst.de Link: https://lore.kernel.org/20260723054622.3460249-2-hch@lst.de Signed-off-by: Christoph Hellwig Acked-by: Usama Arif Acked-by: Chris Li Cc: Baoquan He Cc: Kairui Song Cc: Kairui Song Cc: Kemeng Shi Cc: Nhat Pham Cc: Steve French Signed-off-by: Andrew Morton commit f7bf5cd5b5f2b13fe2361860880c4e214c08b440 Author: Longlong Xia Date: Sun Aug 9 19:55:18 2026 +0800 zsmalloc: account for handle size in class lookup zs_lookup_class_index() lets zram recompression decide whether a newly compressed object would use a smaller size class. It currently classifies the payload size directly, while zs_malloc() adds ZS_HANDLE_SIZE before selecting the class. This makes lookup disagree with allocation near size-class boundaries. With 4 KiB pages, CONFIG_ZSMALLOC_CHAIN_SIZE=8, and 64-bit handles, a 1025-to-1024-byte recompression appears to move from class 64 to class 62 although both allocations use class 64. Conversely, a 1049-to-1025-byte recompression appears to stay in class 64 although the allocations move from class 65 to class 64. As a result, zram can accept replacements with no allocation benefit or reject ones that would save memory, potentially marking the object incompressible. Factor size-class selection into lookup_size_class(), account for the handle there, and use the helper for both lookup and allocation. Link: https://lore.kernel.org/20260809115518.3791787-1-xialonglong2025@163.com Fixes: 7c2af309abd2 ("zram: add size class equals check into recompression") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Longlong Xia Reviewed-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Signed-off-by: Andrew Morton commit 1dea8e081ec3833e5150250b9fa3afd0dc8768db Author: Jann Horn Date: Mon Aug 10 20:10:01 2026 +0200 mm/page-writeback: document folio_mark_dirty() locking more explicitly We have had bugs where set_page_dirty() was used on a page from GUP without appropriate locking, leading to UAF, in: - KVM, see https://lore.kernel.org/r/20260810-x86-kvm-setpagedirty-v1-1-85f180892d4f@google.com - i915, see commit 0d4bbe3d407f ("drm/i915/userptr: Try to acquire the page lock around set_page_dirty()"). - VMCI, see commit 5a16c535409f ("VMCI: Use set_page_dirty_lock() when unregistering guest memory") - kpc2000 staging driver, see commit b6d13bd9f2c1 ("staging: kpc2000: kpc_dma: Convert set_page_dirty() --> set_page_dirty_lock()") I think set_page_dirty() and folio_mark_dirty() need more explicit documentation on how they should be used with pages from GUP; so add a comment on top of set_page_dirty() and make the comment above folio_mark_dirty() more explicit. Link: https://lore.kernel.org/20260810-set-page-dirty-warnings-v2-1-1bd40fadfacd@google.com Signed-off-by: Jann Horn Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig Cc: Matthew Wilcox (Oracle) Signed-off-by: Andrew Morton commit a8b5875741d416703e19ad8eeac6fce8a12bd6e4 Author: David Carlier Date: Mon Aug 10 21:22:37 2026 +0100 zram: fix slot lock bit position on big-endian 64-bit The slot lock is a bit operation on the whole __lock word, which flags and ac_time alias as two u32s. On little-endian the lock bit lands in the position ZRAM_ENTRY_LOCK reserves in flags, so the aliasing works out. On 64-bit big-endian it lands in ac_time instead: with ZRAM_TRACK_ENTRY_ACTIME enabled, storing the access time from mark_slot_accessed() or slot_free() wipes out the held lock bit, letting another CPU take the same slot lock; an access time value with that bit set makes the slot look locked forever. Shift the lock bit into the flags half of the word on big-endian 64-bit. Link: https://lore.kernel.org/20260810202241.2436603-1-devnexen@gmail.com Fixes: 2e8ff2f51dde ("zram: use u32 for entry ac_time tracking") Signed-off-by: David Carlier Reviewed-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Signed-off-by: Andrew Morton commit cdd719b3f2b88437aa5a6ca8ee2bea6f7015c35b Author: Mark Sercombe Date: Thu Aug 13 20:38:47 2026 +0200 maple_tree: fix comment typo Fix a spelling mistake n a code comment. This is a comment only change with no functional impact. Link: https://lore.kernel.org/20260813183847.474357-1-sercombe.joel.mark@gmail.com Signed-off-by: Mark Sercombe Reviewed-by: Andrew Morton Reviewed-by: Liam R. Howlett (Oracle) Cc: Alice Ryhl Cc: Andrew Ballance Signed-off-by: Andrew Morton commit 972195eb9b4c9a70f04d5677cff799c2524786d8 Author: Breno Leitao Date: Fri Jul 31 03:13:06 2026 -0700 selftests/mm: kmemleak: drop stale min_unref_scans default from comments The test writes min_unref_scans explicitly for every case, so its comments describing 1 as the default are both unnecessary and, since the default is now conditional, wrong. Refer to the threshold values directly. No functional change. Link: https://lore.kernel.org/20260731-kmemleak_hardened-v2-3-7b9689ac77cb@debian.org Signed-off-by: Breno Leitao Acked-by: Catalin Marinas Cc: David Hildenbrand Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 09dde5e9bac0429fa565d3a9fcb0e80d0f668f19 Author: Breno Leitao Date: Fri Jul 31 03:13:05 2026 -0700 Documentation: kmemleak: document the conditional min_unref_scans default min_unref_scans now defaults to 2 when CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN and CONFIG_DEBUG_KMEMLEAK_VERBOSE are both enabled, but the documentation still states that the default is unconditionally 1. Link: https://lore.kernel.org/20260731-kmemleak_hardened-v2-2-7b9689ac77cb@debian.org Signed-off-by: Breno Leitao Acked-by: Catalin Marinas Cc: David Hildenbrand Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit dd0dcfe8ef21fb73dbc48af5c630ef2a6f4ab27c Author: Breno Leitao Date: Fri Jul 31 03:13:04 2026 -0700 mm: kmemleak: default min_unref_scans to 2 for verbose auto-scan Patch series "mm: kmemleak: default min_unref_scans to 2 for verbose kernels", v2. When CONFIG_DEBUG_KMEMLEAK_VERBOSE is set, which means the host is in auto scan mode, set min_unref_scans to 2, avoiding false positives. CONFIG_DEBUG_KMEMLEAK_VERBOSE depends on CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN, so a kernel built with it already runs the scan thread periodically and the user has asked for detailed leak reports. The confirming second scan comes for free there, so default min_unref_scans to 2 in that case and keep it at 1 everywhere else. CONFIG_DEBUG_KMEMLEAK_VERBOSE defaults to n, so nothing changes for kernels that do not opt in. The other two patches bring the documentation and the selftest comments in line with the new conditional default. PS: A similar patch (v1 of this patchset) is applied to Meta's kernel, in real production hosts. This patch (of 3): min_unref_scans defers reporting an object as leaked until it has stayed unreferenced for that many consecutive scans, filtering out objects that are only transiently unreferenced during a scan. It defaults to 1, which reports on the first unreferenced scan. CONFIG_DEBUG_KMEMLEAK_VERBOSE depends on CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN, so a kernel built with it runs the scan thread periodically and the user has opted into detailed leak reporting. A second confirming scan then happens on its own. Default min_unref_scans to 2 there to suppress transient false positives, and keep it at 1 otherwise, where a manually triggered scan is expected to report immediately. The value stays writable through the module parameter. CONFIG_DEBUG_KMEMLEAK_VERBOSE defaults to n, so this does not change the default for kernels that do not opt in. Link: https://lore.kernel.org/20260731-kmemleak_hardened-v2-0-7b9689ac77cb@debian.org Link: https://lore.kernel.org/20260731-kmemleak_hardened-v2-1-7b9689ac77cb@debian.org Signed-off-by: Breno Leitao Acked-by: Catalin Marinas Cc: David Hildenbrand Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 8f07855f579ae8b06a90703cd8a4d02849728890 Author: Breno Leitao Date: Mon Jul 13 04:48:07 2026 -0700 selftests: mm: test kmemleak's N-consecutive-scan leak confirmation Add a functional test for the min_unref_scans kmemleak module parameter. Using samples/kmemleak's helper module it checks that min_unref_scans=1 reports an orphan on the first scan, min_unref_scans=2 reports nothing on the first scan but does on the second, and that the parameter reads back what was written. It counts only the helper module's own orphans (matched by their [kmemleak_test] backtrace, with the module kept loaded so the symbols resolve) so unrelated leaks already present on the system do not perturb the result. The test skips when run as non-root, without CONFIG_DEBUG_KMEMLEAK / CONFIG_SAMPLE_KMEMLEAK, on a kernel without the parameter, or when the helper yields no detectable orphan. Link: https://lore.kernel.org/20260713-catalin_pto-v1-4-5b93b1131089@debian.org Signed-off-by: Breno Leitao Reviewed-by: Catalin Marinas Cc: David Hildenbrand Cc: Geert Uytterhoeven Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 70a964bafe5541d3d319399d814526b26690cddc Author: Breno Leitao Date: Mon Jul 13 04:48:06 2026 -0700 mm: kmemleak: factor leak confirmation into a helper The reporting loop in kmemleak_scan() decided whether to tag an object as a reported leak with a four-term compound condition whose last operand also had a side effect (++object->unref_scans). Mixing the candidate tests with the counter update made the check hard to read. Move the state transition into confirm_leak(): it returns true when a still-unreferenced suspect crosses min_unref_scans consecutive scans and is newly flagged OBJECT_REPORTED, leaving only the reporting bookkeeping in the caller. No functional change. Link: https://lore.kernel.org/20260713-catalin_pto-v1-3-5b93b1131089@debian.org Signed-off-by: Breno Leitao Reviewed-by: Catalin Marinas Cc: David Hildenbrand Cc: Geert Uytterhoeven Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit e776db8e710165c2bc47566b62edcf36ff46bbdd Author: Breno Leitao Date: Mon Jul 13 04:48:05 2026 -0700 mm: kmemleak: report leaks only after N consecutive unreferenced scans kmemleak reports an object the first scan it is found unreferenced. Its mark phase runs without stopping the rest of the kernel and without a write barrier, so a live object whose only reference is briefly invisible during a concurrent RCU update -- e.g. a VMA moved between maple tree nodes, or a page-cache xa_node -- can be seen as unreferenced for that one scan. Because an object is flagged as reported only once, such a transient race turns into a permanent false positive. Track how many consecutive scans each object has been seen unreferenced and only report it once that reaches min_unref_scans, a new module parameter. It defaults to 1, leaving the behaviour unchanged; setting it higher (e.g. 2) still reports a genuine leak, one scan later, while an object referenced again before the threshold restarts its run and is never reported. min_unref_scans can be set at boot with kmemleak.min_unref_scans= or at run-time via /sys/module/kmemleak/parameters/min_unref_scans. Link: https://lore.kernel.org/20260713-catalin_pto-v1-2-5b93b1131089@debian.org Signed-off-by: Breno Leitao Reviewed-by: Catalin Marinas Cc: David Hildenbrand Cc: Geert Uytterhoeven Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit fb496eb062306f0a447f6059012205e10ab7b900 Author: Catalin Marinas Date: Mon Jul 13 04:48:04 2026 -0700 mm: kmemleak: confirm suspected leaks with a second scan Patch series "mm: kmemleak: reduce transient false positives by confirming leaks". This series combines two kmemleak enhancements that were originally submitted separately but both required rebasing after commit 79c37ae3733e9 ("mm/kmemleak: fix checksum computation for per-cpu objects"). The first feature introduces a second scan to confirm suspected leaks: https://lore.kernel.org/all/20260709173347.689607-1-catalin.marinas@arm.com/ The second feature adds a module parameter controlling the minimum number of consecutive unreferenced scans before a leak is reported, as discussed in: https://lore.kernel.org/all/20260626-kmemleak_twice-v1-0-ab28f7cc0971@debian.org/ Changes from v1: Now that commit 79c37ae3733e9 is upstream, the selftest includes an additional priming phase scan as requested by Catalin. Additionally, I've factored out the leak-detection conditional into a helper function to be more digestible for the reader's eye. This 4-patch series resolves all outstanding kmemleak issues I've been tracking. This patch (of 4): The kmemleak marking phase is not atomic. While the object graph is traversed, the kernel can modify pointers, free objects or allocate new ones. If a reference to an object is moved from one location to another, kmemleak scanning may miss it. We have explicit annotations like kmemleak_transient_leak() but identifying and maintaining them is not trivial. Given that such transient leaks are short-lived, rather than just reporting such objects as leaks, do another scan to confirm the suspected objects. If no new leaks are found during the first scan, skip the confirmation one. Link: https://lore.kernel.org/20260713-catalin_pto-v1-0-5b93b1131089@debian.org Link: https://lore.kernel.org/20260713-catalin_pto-v1-1-5b93b1131089@debian.org Signed-off-by: Catalin Marinas Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Breno Leitao Cc: David Hildenbrand Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Geert Uytterhoeven Signed-off-by: Andrew Morton commit 534b19bbb67717eea2272573bc0ff7ba4ba109c1 Author: David Hildenbrand (Arm) Date: Mon Aug 10 13:31:14 2026 +0200 mm/gup_test: keep longterm pin state per file The pin longterm test currently stores its data globally, shared among multiple concurrent users of the interface (multiple open file descriptors -> multiple "struct file"'s). That makes the gup_test interface problematic to use concurrently: two users, such as concurrent selftest runs, can interfere with the same longterm pin state. While this has not been observed as a problem so far in practice, let's just handle it cleanly. There could be a way to trigger selftest failures by e.g., running the cow.c and gup_longerm.c selftests concurrently, but we usually run them sequentially. Let's add a "Fixes" tag to be safe, but not need to CC stable. Link: https://lore.kernel.org/20260810-gup_test_data-v1-1-fb1d41be5bb4@kernel.org Fixes: c77369b437f9 ("mm/gup_test: start/stop/read functionality for PIN LONGTERM test") Signed-off-by: David Hildenbrand (Arm) Reported-by: yunhui cui Closes: https://lore.kernel.org/r/20260608025043.88087-1-cuiyunhui@bytedance.com Tested-by: Yunhui Cui Tested-by: Lance Yang Cc: Jason Gunthorpe Cc: John Hubbard Cc: Peter Xu Cc: Yang Li Signed-off-by: Andrew Morton commit 8790303cbaac52a11dfed4aab261f8ea60682525 Author: Hui Su Date: Sat Aug 8 11:14:59 2026 +0800 kasan: fix cache shrink race with CPU hotplug kasan_quarantine_remove_cache() first invokes per_cpu_remove_cache() on all online CPUs. Each callback moves objects belonging to the cache from cpu_quarantine to the CPU's shrink_qlist, where they can later be freed from task context. kmem_cache_destroy() invokes the quarantine removal path while holding cpus_read_lock(), but kmem_cache_shrink() does not. The latter can therefore race with CPU offlining as follows: kmem_cache_shrink() CPU hotplug ------------------- ----------- on_each_cpu() CPU1 moves objects to CPU1's shrink_qlist on_each_cpu() returns CPU1 goes offline kasan_cpu_offline() drains cpu_quarantine leaves shrink_qlist untouched for_each_online_cpu() skips CPU1 The objects left on CPU1's shrink_qlist are not returned to the slab allocator. This may prevent kmem_cache_shrink() from releasing slabs that would otherwise become empty. If CPU1 remains offline, a later kmem_cache_destroy() also skips the list and can report that the cache still contains objects. An intermittent occurrence was observed with a virtio-9p filesystem. The mount and umount commands both returned 0, but the kernel logged the following during the userspace-triggered teardown: [ 2994.380134][ T111] BUG 9p-fcall-cache-1 (Tainted: G B ): Objects remaining on __kmem_cache_shutdown() [ 2994.381140][ T111] Object 0xff11000004361118 @offset=4376 [ 2994.381607][ T111] Allocated in p9_fcall_init+0x201/0x400 age=19564 cpu=1 pid=104 [ 2994.382591][ T111] p9_fcall_init+0x201/0x400 [ 2994.382810][ T111] p9_tag_alloc+0x12f/0x700 [ 2994.382982][ T111] p9_client_prepare_req+0x102/0x3e0 [ 2994.383165][ T111] p9_client_rpc+0x1ab/0xa50 [ 2994.383334][ T111] p9_client_getattr_dotl+0xb0/0x1a0 [ 2994.383515][ T111] v9fs_vfs_getattr_dotl+0x115/0x360 [ 2994.383719][ T111] vfs_getattr_nosec+0x22c/0x3a0 [ 2994.383910][ T111] vfs_statx+0xd7/0x170 [ 2994.384062][ T111] vfs_fstatat+0x45/0x80 [ 2994.384215][ T111] __do_sys_newfstatat+0x84/0xe0 [ 2994.384386][ T111] do_syscall_64+0x115/0x6a0 [ 2994.384566][ T111] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2994.399720][ T111] WARNING: mm/slub.c:1244 at __kmem_cache_shutdown+0x363/0x500, CPU#0: busybox/111 [ 2994.405655][ T111] Call Trace: [ 2994.406325][ T111] kmem_cache_destroy+0x73/0x1b0 [ 2994.406630][ T111] p9_client_destroy+0x271/0x3c0 [ 2994.407210][ T111] v9fs_session_close+0x3c/0x260 [ 2994.407409][ T111] v9fs_kill_super+0x48/0x90 [ 2994.407584][ T111] deactivate_locked_super+0xa3/0x160 [ 2994.407778][ T111] cleanup_mnt+0x1dd/0x3e0 Thus, a successful umount left objects in the 9p fcall cache and prevented the cache from being destroyed cleanly. Per-CPU shrink_qlist storage exists for every possible CPU, and each list is protected by its own raw spinlock. Iterate over possible CPUs so that a list populated before its CPU went offline is drained as well. for_each_possible_cpu() can do more work than for_each_online_cpu(), but this change only affects CONFIG_KASAN_GENERIC kernels. The extra work is limited to cache shrink and cache destruction paths and does not affect the normal allocation/free fast path. It adds one raw-spinlock-protected scan of each possible CPU's shrink list. These lists are normally empty; a non-empty list is traversed to remove objects belonging to the cache being shrunk or destroyed. Link: https://lore.kernel.org/20260808031459.3032812-1-sh_def@163.com Fixes: 07d067e4f2ce ("kasan: fix sleeping function called from invalid context on RT kernel") Signed-off-by: Hui Su Reviewed-by: Andrey Ryabinin Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Dmitry Vyukov Cc: Vincenzo Frascino Cc: "Zhang, Qiang1" Cc: Signed-off-by: Andrew Morton commit 097492865fbef3af59200e31fef9148ecea80aad Author: Hongfu Li Date: Mon Aug 10 17:32:15 2026 +0800 mm/cma: remove stray newline from auto-generated CMA area name When no name is supplied, cma_new_area() generates names with format "cma%d\n", introducing an unintended newline character ('\n') in the CMA name. Most CMA regions are created with explicit names, so this path is seldom hit. The newline only creates cosmetic noise in debug logs, traces and debugfs with no functional impact. Link: https://lore.kernel.org/20260810093215.91419-1-hongfu.li@linux.dev Signed-off-by: Hongfu Li Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: SJ Park Reviewed-by: Anshuman Khandual Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 1f2b4b28aafeeeded553812c70f4a8bd054ac38a Author: Yunzhao Li Date: Thu Jul 2 11:07:35 2026 -0700 mm/zswap: use ratelimited stats flush in zswap_shrinker_count() zswap_shrinker_count() calls mem_cgroup_flush_stats(), which takes the global cgroup rstat lock synchronously. On machines with many CPUs and NUMA nodes, this creates severe lock contention in the kswapd reclaim path: - Multiple kswapd threads (one per NUMA node) run concurrently. - do_shrink_slab() invokes zswap_shrinker_count() for each memcg-aware shrinker pass. - Each call flushes the full cgroup rstat hierarchy under the global lock. On AMD EPYC 9684X machines (96 cores, 192 threads, 12 NUMA nodes) running production workloads with zswap enabled, perf shows 2.88% of kernel cycles in osq_lock contention from this path: 2.88% [k] osq_lock --__mutex_lock.constprop.0 --__cgroup_rstat_lock --cgroup_rstat_flush_locked --cgroup_rstat_flush --zswap_shrinker_count do_shrink_slab shrink_slab shrink_node balance_pgdat kswapd 84% of kswapd kernel cycles are spent in shrink_slab -> zswap_shrinker_count -> cgroup_rstat_flush, not in actual page reclaim (shrink_lruvec). Controlled A/B on identical hardware and workload: shrinker=Y: 2.88% osq_lock, memory PSI 1.58% shrinker=N: 0.00% osq_lock, memory PSI 0.57% eBPF-based rstat lock wait measurement across 8 production metals confirms the contention splits cleanly along shrinker enablement: shrinker=Y: 50-250x more contended lock acquisitions (248/s vs 1.1/s) shrinker=N: baseline lock wait (0.0017 s/s vs 1.04 s/s) zswap_shrinker_count() only produces a heuristic estimate, scaled by compression ratio via mult_frac(). The actual writeback happens in zswap_shrinker_scan(). Slightly stale stats are acceptable here. Switch to mem_cgroup_flush_stats_ratelimited(), which only flushes if the periodic 2-second flusher is one full cycle late. This matches the approach already used in prepare_scan_control() (mm/vmscan.c) for the same reclaim path. After applying this patch, rstat flush latency and lock wait time on shrinker=Y machines dropped to the same level as shrinker=N controls, while the zswap shrinker continues to function (pool size remains bounded under the max_pool_percent cap). Previously discussed: - Chengming Zhou (Dec 2023): rstat contention from zswap_shrinker_count [1] - Shakeel Butt (Aug 2024): zswap_shrinker_count still uses sync flush [2] - Yosry Ahmed (Aug 2024): suggested eliminating in-kernel flushers [3] - Jesper Dangaard Brouer (Sep 2024): cgroup/rstat V11 patch [4] Link: https://lore.kernel.org/20260702180908.150136-1-yunzhao@cloudflare.com Link: https://lore.kernel.org/linux-mm/20231206103935.3440502-1-zhouchengming@bytedance.com/ [1] Link: https://lore.kernel.org/linux-mm/CALvZod7LFxLCxVpOFH8b2Ppm8T40HPGMKQwX_=NPCWB_mFW+oQ@mail.gmail.com/ [2] Link: https://lore.kernel.org/linux-mm/CAJD7tkYvFyOSX+rP_FKGBhxvZiCDxtpsNp-c5CGOA-4Bq9oXSg@mail.gmail.com/ [3] Link: https://lore.kernel.org/linux-mm/172616070094.2055617.17676042522679701515.stgit@firesoul/ [4] Suggested-by: Jesper Dangaard Brouer Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Yunzhao Li Tested-by: Yunzhao Li Acked-by: Johannes Weiner Acked-by: Jesper Dangaard Brouer Acked-by: Nhat Pham Cc: Chengming Zhou Cc: Shakeel Butt Cc: Yosry Ahmed Cc: Yunzhao Li Cc: Sourav Panda Signed-off-by: Andrew Morton commit b090524f775b412d12c34b71d6d39fe46aa72e30 Author: Hongfu Li Date: Fri Jul 17 15:11:04 2026 +0800 mm/swap: fix swap_cluster_lock() !CONFIG_SWAP stub signature mismatch The !CONFIG_SWAP stub for swap_cluster_lock() has mismatched prototype: it has an extra unused irq argument and uses pgoff_t instead of unsigned long for offset. All callers are under CONFIG_SWAP so the extra parameter is dead. Delete the unused stub function entirely. Link: https://lore.kernel.org/20260717071104.73467-1-hongfu.li@linux.dev Signed-off-by: Hongfu Li Reviewed-by: Baoquan He Acked-by: Kairui Song Cc: Barry Song Cc: Chris Li Cc: Hongfu Li Cc: Kemeng Shi Cc: Nhat Pham Signed-off-by: Andrew Morton commit c01e6df60e7be422ee5ce5e2a76d43fb05fab4c2 Author: Christoph Hellwig Date: Mon Jul 13 11:33:44 2026 +0200 mm/vmstat: add NRSWP{IN,OUT} counters Count how many swap I/Os we cause. Due to batching this can be different than the current counter number of pages written/read, and tracking this information is useful to see how efficient the batching is. The counters are added at the end of enum vm_event_item and the vmstat_text array under the assumption that the order of fields in /proc/vmstat is an ABI. If that is not the case, they could be grouped with the other swap counters. Link: https://lore.kernel.org/20260713093350.2154226-8-hch@lst.de Signed-off-by: Christoph Hellwig Reviewed-by: Nhat Pham Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Chris Li Cc: Kairui Song Cc: Kemeng Shi Cc: Youngjun Park Signed-off-by: Andrew Morton commit 0df74c11587941b35596d1e8990dcab06bdbfeb5 Author: Christoph Hellwig Date: Mon Jul 13 11:33:43 2026 +0200 mm/swap: remove SWP_FS_OPS Provide a swap_fs_activate helper that directly sets up swap_fs_ops, and a flag in struct swap_ops to indicate of NOFS swapping is allowed. Link: https://lore.kernel.org/20260713093350.2154226-7-hch@lst.de Signed-off-by: Christoph Hellwig Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Chris Li Cc: Kairui Song Cc: Kemeng Shi Cc: Nhat Pham Cc: Youngjun Park Signed-off-by: Andrew Morton commit 563597895e65113b4dafea6cacd1df23b0cf6660 Author: Christoph Hellwig Date: Mon Jul 13 11:33:42 2026 +0200 mm/swap: use swap_ops to register swap device's methods This simplifies codes and makes logic clearer. And also makes later any new swap device type being added easier to handle. Currently there are two types of swap devices: fs and bdev. [hch@lst.de: updated for the new submit and can_merge abstraction] Link: https://lore.kernel.org/20260713093350.2154226-6-hch@lst.de Signed-off-by: Baoquan He Signed-off-by: Christoph Hellwig Suggested-by: Chris Li Reviewed-by: Nhat Pham Cc: Baolin Wang Cc: Barry Song Cc: Kairui Song Cc: Kemeng Shi Cc: Youngjun Park Signed-off-by: Andrew Morton commit 4e915b16ded278e57519e54793ab84b4a094fa83 Author: Christoph Hellwig Date: Mon Jul 13 11:33:41 2026 +0200 mm/swap: remove count_swpout_vm_event There is only one caller left, so merge it into that. Link: https://lore.kernel.org/20260713093350.2154226-5-hch@lst.de Signed-off-by: Christoph Hellwig Reviewed-by: Baoquan He Reviewed-by: Nhat Pham Cc: Baolin Wang Cc: Barry Song Cc: Chris Li Cc: Kairui Song Cc: Kemeng Shi Cc: Youngjun Park Signed-off-by: Andrew Morton commit dda8fb68b5907d0a3c6216e5e31e45adca582b68 Author: Christoph Hellwig Date: Mon Jul 13 11:33:40 2026 +0200 mm/swap: also use struct swap_iocb for block I/O Block I/O benefits from batching just as much as remote file systems. Extend struct swap_iocb to support building a bio on the fly as well, and rewrite the block based swap code for it. This especially benefits submit_bio based drivers that do not have the block plugging available, but also saves allocating extra bios for blk-mq drivers. Add a pre-allocated bio to struct swap_iocb in a union with kiocb used for file system based swap so that struct swap_iocb can be used for all swap I/O, and initialize the pool for it unconditionally. Various low-level bdev and fs functions are now replaced with a unified can_merge/add/submit scheme. Note that the block based swap code now uses the same memcg-based check previously added for file system based swap as well. Link: https://lore.kernel.org/20260713093350.2154226-4-hch@lst.de Signed-off-by: Christoph Hellwig Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Chris Li Cc: Kairui Song Cc: Kemeng Shi Cc: Nhat Pham Cc: Youngjun Park Signed-off-by: Andrew Morton commit 8f29aa226f82d8f9e7cf75f0ed5964960c7fe682 Author: Christoph Hellwig Date: Mon Jul 13 11:33:39 2026 +0200 mm/swap: introduce struct swap_io_ctx Generalize the context currently provided by double pointers to struct swap_iocb to an on-stack context. This cleans up the code and prepares for adding more fields and supporting batching multiple folios into a single bio for block-based swap as well. This new swap_io_ctx is required for all functions using it, the old way of allowing a NULL iocb for some callers is removed to keep the interface consistent. To reduce code duplication caused by this, a new swap_cache_read_folio_sync helper is added to consolidate the code to call swap_cache_read_folio with a local swap_io_ctx. The unpug helpers are renamed to use the submit wording as they are generalized. Link: https://lore.kernel.org/20260713093350.2154226-3-hch@lst.de Signed-off-by: Christoph Hellwig Reviewed-by: Nhat Pham Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Chris Li Cc: Kairui Song Cc: Kemeng Shi Cc: Youngjun Park Signed-off-by: Andrew Morton commit a8efc69a65fbef61bed0923c0de3425d74817c1c Author: Christoph Hellwig Date: Mon Jul 13 11:33:38 2026 +0200 shmem: provide a shmem_write_folio wrapper Patch series "better block swap batching and a different take on swap_ops v5". This series makes use of the swap_iocb for block as well so that it doesn't do inefficient single-bio I/O, and then rebases the swap_ops from Baoquan on top of the now very different method structure. When running doing kernels builds, which is a workload that doesn't really do much THP anonymous memory it still gets 2x clustering for writeout and 1.2x for reading back swap in. The overall times do not actually change, though. This patch (of 7): Provide a wrapper for the shmem abuses in drm to prepare for swap I/O refactoring by keeping swap_iocb handling entirely contained in mm/. Link: https://lore.kernel.org/20260713093350.2154226-1-hch@lst.de Link: https://lore.kernel.org/20260713093350.2154226-2-hch@lst.de Signed-off-by: Christoph Hellwig Reviewed-by: Baoquan He Reviewed-by: Nhat Pham Reviewed-by: Baolin Wang Acked-by: Chris Li Reviewed-by: Kairui Song Cc: Kemeng Shi Cc: Barry Song Cc: Youngjun Park Signed-off-by: Andrew Morton commit a44730dd05a3f3a663f79fde62d6731393046655 Author: Zhiling Zou Date: Fri Jul 31 11:22:51 2026 +0800 mm: shmem: reject page-aligned fallocate end overflow shmem_fallocate() validates offset + len with inode_newsize_ok(), but then rounds that end offset up to a page boundary before entering the preallocation loop. For a valid request ending at MAX_LFS_FILESIZE, such as offset = 0 and len = LLONG_MAX, adding PAGE_SIZE - 1 to the validated end can overflow the signed loff_t used for the rounded end calculation. If that wrapped value is then converted into a page index, shmem_fallocate() can enter the folio allocation loop with an invalid range. Use check_add_overflow() when calculating the page-aligned end, and fail before entering the allocation loop if the rounded end cannot be represented. Link: https://lore.kernel.org/1929a466735dcbb9438936ff50b7a4fc2332a8a4.1785377919.git.zhilinz@nebusec.ai Fixes: e2d12e22c59c ("tmpfs: support fallocate preallocation") Signed-off-by: Zhiling Zou Reported-by: Vega Reviewed-by: Baolin Wang Cc: Hugh Dickins Signed-off-by: Andrew Morton commit 923690d8099349ec46c8930c0e73b462ea41632b Author: Abhishek Bapat Date: Wed Jul 8 18:01:28 2026 +0000 kselftest: alloc_tag: extend the allocinfo ioctl kselftest Add the following 2 scenarios to the allocinfo ioctl kselftest: 1. Validate size based filtering 2. Validate lineno based filtering The first test uses "do_init_module" as the candidate function for the test. This is because the associated site will only allocate memory when a kernel module is loaded. The return value of get_content_id() changes every time modules are loaded or unloaded. Hence, as long as get_content_id() values at the start and the end of the test are the same, the memory allocated by the do_init_module call site should also remain the same. Consequently, the test can assume consistency between the value returned by the ioctl and the procfs resulting in less flakiness. Link: https://lore.kernel.org/e5171926b48802531284c1cb5f04734017141341.1783532853.git.abhishekbapat@google.com Signed-off-by: Abhishek Bapat Tested-by: Hao Ge Acked-by: Hao Ge Cc: Jonathan Corbet Cc: Kent Overstreet Cc: Sourav Panda Cc: Suren Baghdasaryan Signed-off-by: Andrew Morton commit 2f252a7a6c90c94be042c10ca3b85f37038d1070 Author: Abhishek Bapat Date: Wed Jul 8 18:01:27 2026 +0000 kselftest: alloc_tag: add kselftest for ioctl interface Introduce a kselftest to verify the new IOCTL-based interface for /proc/allocinfo. The test covers: 1. Validation of the filename filter. 2. Validation of the function filter. The first test validates the functionality of the filename filter. Using "mm/memory.c" as the candidate filename filter, it retrieves filtered entries from both procfs and ioctl and matches the first VEC_MAX_ENTRIES entries. The second test validates the functionality of the function filter. It uses "dup_mm" as the candidate function as we do not expect this function name to change frequently and hence won't be needing to modify this test often. Note that both the tests match line no, function name and file name fields. Bytes allocated and calls are not matched as those values may change in the time when the data is being read from procfs and ioctl and hence can lead to false negatives. [abhishekbapat@google.com: fix a typo in the selftest] Link: https://lore.kernel.org/e4e49ec4a5960292aeeb9e196526c18dc95228a2.1785867739.git.abhishekbapat@google.com Closes: https://sashiko.dev/#/patchset/cover.1783532853.git.abhishekbapat@google.com Link: https://lore.kernel.org/e2a3795677a14aeab249758ba570cd5e98402032.1783532853.git.abhishekbapat@google.com Signed-off-by: Abhishek Bapat Tested-by: Hao Ge Acked-by: Hao Ge Cc: Jonathan Corbet Cc: Kent Overstreet Cc: Sourav Panda Cc: Suren Baghdasaryan Signed-off-by: Andrew Morton commit 33588e0b81df2972922f2591767a4e3c16813ab9 Author: Abhishek Bapat Date: Wed Jul 8 18:01:26 2026 +0000 alloc_tag: add accuracy based filtering to ioctl Extend the allocinfo filtering mechanism to allow users to filter tags based on their accuracy. [abhishekbapat@google.com: move `inaccurate` filtering criteria from `struct allocinfo_tag` to `struct allocinfo_filter`] Link: https://lore.kernel.org/e4e49ec4a5960292aeeb9e196526c18dc95228a2.1785867739.git.abhishekbapat@google.com Link: https://lore.kernel.org/396a5e4bc3b2990223ab355f2cd3ceb6aa15499e.1783532853.git.abhishekbapat@google.com Signed-off-by: Abhishek Bapat Acked-by: Hao Ge Acked-by: Suren Baghdasaryan Cc: Jonathan Corbet Cc: Kent Overstreet Cc: Sourav Panda Signed-off-by: Andrew Morton commit 6f6769ea88f89116e8d66a4ac77056e2e3b377c5 Author: Abhishek Bapat Date: Wed Jul 8 18:01:25 2026 +0000 alloc_tag: add size-based filtering to ioctl Extend the allocinfo filtering mechanism to allow users to filter tags based on the total number of bytes allocated [min_size, max_size]. The size range is inclusive. Filtering by size involves retrieving allocinfo per-CPU counters, which is an expensive operation. Hence, the performance of size-based filtering will be worse than other filters. Link: https://lore.kernel.org/0a7653b70ae0d64e967fbea0e933bc35f8ac656e.1783532853.git.abhishekbapat@google.com Signed-off-by: Abhishek Bapat Acked-by: Hao Ge Acked-by: Suren Baghdasaryan Cc: Jonathan Corbet Cc: Kent Overstreet Cc: Sourav Panda Signed-off-by: Andrew Morton commit 5732a4e4c18acac152768df9ce48e057232edbf4 Author: Abhishek Bapat Date: Wed Jul 8 18:01:24 2026 +0000 alloc_tag: add ioctl filters to /proc/allocinfo Extend the capability of the IOCTL mechanism to filter allocations based on tag's module name, function name, file name and line number. Link: https://lore.kernel.org/6a6100c0c58cb2911f39126b9fe177a8c17db16f.1783532853.git.abhishekbapat@google.com Signed-off-by: Abhishek Bapat Acked-by: Hao Ge Acked-by: Suren Baghdasaryan Cc: Jonathan Corbet Cc: Kent Overstreet Cc: Sourav Panda Signed-off-by: Andrew Morton commit 1d581ab2348cdbb6d4d0a467382926b68e374ec9 Author: Suren Baghdasaryan Date: Wed Jul 8 18:01:23 2026 +0000 alloc_tag: add ioctl to /proc/allocinfo Patch series "alloc_tag: introduce IOCTL-based filtering for MAP", v8. Currently, memory allocation profiling data is primarily exposed through /proc/allocinfo. While useful for manual inspection, this text-based interface poses challenges for production monitoring and large-scale analysis: 1. Userspace must parse large amounts of text to extract specific fields. 2. To find specific tags, userspace must read the entire dataset, requiring many context switches and high data copying. 3. The kernel currently aggregates per-CPU counters for every allocation size, even those the user intends to filter out immediately. This series introduces a new IOCTL-based binary interface for allocinfo that supports kernel-side filtering. By allowing the user to specify a filter mask, we significantly reduce the work performed in-kernel and the amount of data transferred to userspace. The IOCTL mechanism was chosen for allocinfo to address the per-CPU counter aggregation bottleneck. A traditional read() operation must report the total allocation count and sizes for every code tag in the system. Doing so requires iterating across all CPUs to sum their per-CPU counters for thousands of tags, which introduces substantial runtime overhead. The IOCTL interface allows userspace to push selective filtering criteria directly into the kernel before the per-CPU counter aggregation. The kernel aggregates per-CPU counters only for a small subset of tags that match the filter. This results in significant performance improvement. Beyond fast filtered retrieval, the IOCTL foundation allows introducing a context capture mechanism in the future to capture the context for specific allocations. Performance measurements were conducted on an Intel Xeon Platinum 8481C (224 CPUs) with caches dropped before each run. The IOCTL mechanism shows a ~20x performance improvement for filtered queries. The kernel avoids the expensive per-CPU counter aggregation (alloc_tag_read) for any tags that fail the initial string or location filters. Scenario 1: Specific File Filtering (arch/x86/events/rapl.c) 1. Traditional (cat /proc/allocinfo | grep): 22ms (sys) 2. IOCTL Interface: 1ms (sys) Scenario 2: Compound Filtering (Filename + Size) 1. Traditional: (cat ... | grep | awk): 21ms (sys) 2. IOCTL Interface: 1ms (sys) Scenario 3: Size-Based Filtering (min_size = 1MB) 1. Traditional: (cat ... | awk): 21ms (sys) 2. IOCTL Interface: 14ms (sys) This patch (of 6): Add the following ioctl commands for /proc/allocinfo file: ALLOCINFO_IOC_CONTENT_ID - gets content identifier which can be used to check whether the file content has changed specifically due to module load/unload. Every time a module is loaded / unloaded, the returned value will be different. By comparing the identifier value at the beginning and at the end of the content retrieval operation, users can validate retrieved information for consistency. ALLOCINFO_IOC_GET_AT - gets the record at the specified position. This is the position of a record in /proc/allocinfo. ALLOCINFO_IOC_GET_NEXT - gets the record next to the last retrieved one. If no records were previously retrieved, returns the first record. Note, function file and module names often have the same prefixes, therefore when filtering for them, we compare the last 64 characters to minimize the chances of name collisions. [akpm@linux-foundation.org: include compat.h, per Suren] Closes: https://lore.kernel.org/oe-kbuild-all/202607091820.qbjlGhKK-lkp@intel.com/ Link: https://lore.kernel.org/cover.1783532853.git.abhishekbapat@google.com Link: https://lore.kernel.org/15596de2607ef13e7c77c6d74763f4ae992ec475.1783532853.git.abhishekbapat@google.com Signed-off-by: Suren Baghdasaryan Signed-off-by: Abhishek Bapat Acked-by: Hao Ge Cc: Jonathan Corbet Cc: Kent Overstreet Cc: Sourav Panda Signed-off-by: Andrew Morton commit 22709abff9d0e3b0c61434cad58a9f7e86d68384 Author: Ethan Nelson-Moore Date: Wed Jun 10 18:22:44 2026 -0700 mm: fix CONFIG_STACK_GROWSUP typo in tools/testing/vma/include/dup.h Commit 2b6a3f061f11 ("mm: declare VMA flags by bit") significantly refactored the header file include/linux/mm.h. In that step, it introduced a typo in an ifdef, referring to a non-existing config option STACK_GROWS_UP, whereas the actual config option is called STACK_GROWSUP. Commit 40a4af52e047 ("mm: fix CONFIG_STACK_GROWSUP typo in mm.h") fixed this typo in the mm.h header file, but did not update the copy of the code in tools/testing/vma/include/dup.h. Update this copy as well. Commit message adapted from the above-referenced fix to mm.h. Link: https://lore.kernel.org/20260611012258.432043-1-enelsonmoore@gmail.com Signed-off-by: Ethan Nelson-Moore Reviewed-by: Lorenzo Stoakes Cc: Alice Ryhl Cc: Jann Horn Cc: Liam R. Howlett Cc: Pedro Falcato Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 4050b5b0b60c93160a816d68ea1eb9ae92739a73 Author: Hongfu Li Date: Fri Aug 7 09:35:55 2026 +0800 selftests/mm: fix read_file() return value check read_file() returns 0 on open/read failures and never returns negative values. Existing < 0 error checks never trigger, so read failures are silently ignored. Check for zero return to detect read_file() failures. Also fix misleading error message in get_finfo(). The error string incorrectly references read_num when reading uevent files. Link: https://lore.kernel.org/20260807013555.36525-1-hongfu.li@linux.dev Fixes: e0c13f9761df ("khugepaged: add self test") Signed-off-by: Hongfu Li Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Ryan Roberts Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton commit 34e0849142c317eed68f3a4818dd3808fb1c47db Author: Sourav Panda Date: Fri Aug 7 04:00:03 2026 +0000 mm/hugetlb_cma: support percentage-based hugetlb_cma reservation Currently, hugetlb_cma reservation only supports absolute sizes (e.g., hugetlb_cma=2G or hugetlb_cma=0:1G,1:1G). This can be restrictive in heterogeneous environments or when deploying common kernel command lines across machines with different memory capacities. Add support for percentage-based hugetlb_cma reservation (e.g., hugetlb_cma=20% or hugetlb_cma=0:20%,1:10%). The percentage is calculated against the total memory (for global settings) or against the node-specific memory (for node-specific settings) using memblock APIs during early boot. Link: https://lore.kernel.org/20260807040003.2156630-1-souravpanda@google.com Signed-off-by: Sourav Panda Acked-by: Usama Arif Cc: David Hildenbrand Cc: David Rientjes Cc: Frank van der Linden Cc: Greg Thelen Cc: Muchun Song Cc: Oscar Salvador Cc: Suren Baghdasaryan Signed-off-by: Andrew Morton commit 28b13c3c4c6592da8dd59a7b06655e39665ee624 Author: Bart Van Assche Date: Fri Aug 7 10:13:10 2026 -0700 mm: make VM_FAULT_RESULT_TRACE compatible with sparse Fix the following sparse warnings that appear while building f2fs: ./include/trace/events/f2fs.h:1469:1: warning: incorrect type in initializer (different base types) ./include/trace/events/f2fs.h:1469:1: expected unsigned long mask ./include/trace/events/f2fs.h:1469:1: got restricted vm_fault_t Link: https://lore.kernel.org/e56c9e2aead04f79192c3110de80d846e41e3791.1786122711.git.bvanassche@acm.org Signed-off-by: Bart Van Assche Acked-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Reviewed-by: Anshuman Khandual Signed-off-by: Andrew Morton commit 3774c56cc38b9ddcdf46dd717d4de954b40d8986 Author: Mike Rapoport (Microsoft) Date: Thu Aug 6 09:58:38 2026 +0300 drivers/base, mm: move arch_numa.c to mm/ arch_numa.c implements boot time discovery and initialization of NUMA topology on architectures that select GENERIC_ARCH_NUMA (currently arm64 and riscv). Since this is step in the initialization of the memory management subsystem, it's logical to have arch_numa.c in mm/ alongside numa.c, numa_memblks.c and numa_emulation.c. Move arch_numa.c to mm/ and add its F: entry to "MEMBLOCK AND MEMORY MANAGEMENT INITIALIZATION" in MAINTAINERS. Link: https://lore.kernel.org/20260806-arch-numa-v1-1-968ec128121e@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Acked-by: Greg Kroah-Hartman Acked-by: Lorenzo Stoakes (ARM) Acked-by: Vlastimil Babka (SUSE) Acked-by: David Hildenbrand (Arm) Acked-by: Danilo Krummrich Cc: Albert Ou Cc: Alexandre Ghiti Cc: Catalin Marinas Cc: Liam R. Howlett Cc: Michal Hocko Cc: Palmer Dabbelt Cc: "Rafael J. Wysocki" Cc: Suren Baghdasaryan Cc: Will Deacon Signed-off-by: Andrew Morton commit 6f34b4126b8bb7b24c2d6b6541d51d9655287fb4 Author: Hao Jia Date: Thu Aug 6 15:09:43 2026 +0800 mm/zswap: support batch writeback in shrink_memcg() Currently, shrink_memcg() writes back at most one entry per-node during its traversal. This makes shrink_worker() inefficient, as it must repeatedly re-enter shrink_memcg() to make any substantial progress. Under high memory pressure, this can cause the writeback speed to be too slow to keep up with refaults, leading to zswap store failures and forcing pages to skip zswap and go directly to disk, which results in an LRU inversion. To address this, extend the per-node scan budget in shrink_memcg() from a single entry to up to SWAP_CLUSTER_MAX pages, enabling batch writeback for both the shrink_worker() and zswap_store() paths. Test Setup: - Total memory: 32 GB, 1 NUMA node. - zswap settings: accept_threshold_percent=50, shrinker_enabled=N. Test Case 1: Set max_pool_percent=1, allocate 512MB of anonymous pages, and fill them with random data (to avoid compression). Then, use cgroup memory.reclaim to force a large amount of anonymous pages into zswap. At an interval of 2ms, allocate a 4K anonymous page where the first 4 bytes are random numbers and the rest are zeros, and then trigger reclamation of this 4K page through cgroup memory.reclaim. When the pool threshold is reached, shrink_memcg() will be triggered. The test data after running for 120s is as follows: Baseline Patched shrink_worker wakeups 5,363 169 shrink_memcg calls 11,373,201 350,703 written_back pages 40,212 40,241 zswap_store calls 161,190 163,753 store succeeded (ret=1) 102,743 117,183 store rejected (ret=0) 58,447 46,570 store reject rate ~36% ~28% pool_limit_hit delta 55,826 33,760 pswpout 98,659 86,811 pswpin 2 0 Test Case 2: We evaluated the following two sub-configurations using stress-ng inside a cgroup capped at memory.max=1G for 120 seconds: Test Case 2a (max_pool_percent=1): Continuously triggers the global zswap pool limit, thereby waking up shrink_worker() to perform asynchronous shrinking. Test Case 2b (zswap.max=320M, max_pool_percent=50): Continuously triggers the cgroup's zswap.max limit, thereby invoking synchronous shrinking. Command executed for both setups: bash -c 'echo $$ > /sys/fs/cgroup/zswaptest/cgroup.procs ; \ exec stress-ng --vm 4 --vm-bytes 4G --vm-keep --vm-method rand-set -t \ 120s -q' Test Case 2a (max_pool_percent=1): Baseline Patched shrink_worker wakeups 5,640 1,308 shrink_memcg calls 8,481,500 3,140,972 written_back pages 260 468,216 zswap_store calls 2,742,756 2,011,269 store succeeded (ret=1) 934,640 947,988 store rejected (ret=0) 1,808,116 1,063,281 store reject rate ~66% ~52% pool_limit_hit delta 1,181,310 196,882 pswpout 1,808,376 1,531,497 pswpin 4,288,497 3,635,365 Test Case 2b (zswap.max=320M, max_pool_percent=50): Baseline Patched shrink_worker wakeups 0 0 shrink_memcg calls 687,608 54,002 written_back pages 639,176 846,663 zswap_store calls 1,224,222 1,228,548 store succeeded (ret=1) 992,816 1,208,123 store rejected (ret=0) 231,431 20,425 store reject rate ~19% ~2% pool_limit_hit delta 0 0 pswpout 870,745 867,360 pswpin 1,707,823 1,216,814 Under identical workloads and runtimes, batched zswap shrinking exhibits a significant reduction in both shrink_worker() wakeups and shrink_memcg() calls. Furthermore, the sharp drop in both pswpin and zswap_store() rejections demonstrates that batching zswap shrink operations effectively mitigates zswap_store() failures caused by hitting the pool limit. This significantly prevents pages from bypassing zswap and falling back directly to disk, thereby reducing LRU inversion. Link: https://lore.kernel.org/20260806070943.95542-3-jiahao.kernel@gmail.com Signed-off-by: Hao Jia Suggested-by: Yosry Ahmed Suggested-by: Johannes Weiner Acked-by: Yosry Ahmed Acked-by: Nhat Pham Cc: Chengming Zhou Cc: Michal Hocko Cc: Michal Koutný Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Tejun Heo Signed-off-by: Andrew Morton commit dc8458f43fe964d8ade74c9b0fce54fe71d156de Author: Hao Jia Date: Thu Aug 6 15:09:42 2026 +0800 mm/zswap: fix global shrinker when memory cgroup is disabled Patch series "mm/zswap: Fixes and improves the zswap shrink", v4. This series fixes and improves the zswap global shrinker (shrink_worker()): Patch 1: Fix missing global shrinker when memory cgroup is disabled. Patch 2: Extend shrink_memcg() to support batch writeback and thereby improving the writeback efficiency in the shrink_worker() and zswap_store() paths. This patch (of 2): Zswap writeback when the global pool limit is hit fails when memory cgroup is disabled. The pool remains full until it is organically drained by swapins or memory freeing, leading to zswap store failures and pages bypassing getting written directly to the backing swap device, causing LRU inversion (hotter pages with higher fault latency). This happens because mem_cgroup_iter() always returns NULL when memory cgroups are disabled. As a result, the global shrinker shrink_worker() repeatedly takes empty walks. After MAX_RECLAIM_RETRIES failed attempts, the worker gives up without writing back any pages. Therefore, when memory cgroup is disabled, fall through with the !memcg branch and shrink the root memcg directly. With memcg disabled, shrink_memcg() only returns -ENOENT when the root LRU is empty, which means the total pages are already below thr. In the absence of heavy concurrent zswap stores, the loop then safely bails out via the zswap_total_pages() <= thr check; otherwise, it will resume shrinking the memcg after processing the reschedule check. For any other return value from shrink_memcg(), the loop is guaranteed to terminate, either after MAX_RECLAIM_RETRIES failures or once the threshold is met. This is a potential performance regression for people using zswap without memcg that was introduced by the commit in "Fixes". Link: https://lore.kernel.org/20260806070943.95542-1-jiahao.kernel@gmail.com Link: https://lore.kernel.org/20260806070943.95542-2-jiahao.kernel@gmail.com Fixes: a65b0e7607cc ("zswap: make shrinking memcg-aware") Signed-off-by: Hao Jia Suggested-by: Nhat Pham Acked-by: Nhat Pham Acked-by: Yosry Ahmed Reported-by: Yosry Ahmed Cc: Chengming Zhou Cc: Johannes Weiner Cc: Michal Hocko Cc: Michal Koutný Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Tejun Heo Cc: Signed-off-by: Andrew Morton commit 746c94b7cb7900327a6ca7c1fcbfdd0243729253 Author: Muhammad Usama Anjum Date: Mon Jul 27 10:52:21 2026 +0100 selftests/mm: retry migration failures for the full runtime move_pages() is best effort and can temporarily fail when concurrent faults race with page unmapping. A busy shared-anon workload can exhaust the current 100 retries long before the intended 20-second runtime and produce a false failure. Use the full runtime as the retry window. Since the initial page location is unknown, require it to reach both alternating NUMA targets to confirm that cross-node migration made progress despite transient contention. Link: https://lore.kernel.org/20260727095225.372655-6-usama.anjum@arm.com Signed-off-by: Muhammad Usama Anjum Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Cc: Sarthak Sharma Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Usama Arif Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton commit e14e52a7ce02f6b62cecbf5c61425b4137422df2 Author: Muhammad Usama Anjum Date: Mon Jul 27 10:52:20 2026 +0100 selftests/mm: skip hard dirty page-cache test on NFS The hard dirty_pagecache variant uses MADV_HWPOISON to exercise recovery of a dirty file-backed page. The recovery path records -EIO in the address_space mapping, which NFS later reports when the test closes the file. This makes the test fail after the hwpoison checks have completed. Skip this variant when the test file is on NFS. Keep the hard clean-page and both soft-offline variants enabled because they use folio removal, invalidation, or migration rather than recording a delayed writeback error. The unsupported-filesystem path in clean_pagecache() also returns without closing the opened test file. Close the descriptor before skipping there and in dirty_pagecache(). Link: https://lore.kernel.org/20260727095225.372655-5-usama.anjum@arm.com Signed-off-by: Muhammad Usama Anjum Reviewed-by: Miaohe Lin Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Cc: Sarthak Sharma Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Usama Arif Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton commit e5220e4d934f8c06ef7734ed56bdd9b62307ea9c Author: Muhammad Usama Anjum Date: Mon Jul 27 10:52:18 2026 +0100 selftests/mm: skip guard hole-punch test if MADV_REMOVE is unsupported The hole_punch case verifies that guard regions survive MADV_REMOVE and that the backing range is punched out. MADV_REMOVE delegates the hole punch to the backing filesystem, which may reject the operation with EOPNOTSUPP. That result means the test cannot establish the state whose guard semantics it intends to validate. Treating the missing filesystem capability as a guard-region failure creates a false regression. Unmap the range and skip only when MADV_REMOVE fails with EOPNOTSUPP. Preserve the assertion for all other errors so failures on supported configurations remain visible. Link: https://lore.kernel.org/20260727095225.372655-3-usama.anjum@arm.com Signed-off-by: Muhammad Usama Anjum Tested-by: Sarthak Sharma Acked-by: Usama Arif Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton commit 4004c130c358b1561a55323b0e747f20f5133f7b Author: Muhammad Usama Anjum Date: Mon Jul 27 10:52:17 2026 +0100 selftests/mm: skip COW tmpfile cases when fallocate() is unsupported Patch series "selftests/mm: Handle unsupported and transient test conditions", v3. Several MM selftests report failures when the test environment lacks an underlying prerequisite, such as fallocate() support, MADV_REMOVE, local page-cache semantics, or swap. This series converts those unsupported cases to SKIP while preserving failures for unexpected errors. It also allows migration tests to retry transient move_pages() failures. This patch (of 4): The tmpfile-backed COW cases allocate a one-page file with fallocate() before exercising private and shared mappings. When the filesystem backing tmpfile() does not implement fallocate(), setup fails with EOPNOTSUPP and no COW behavior is exercised. This occurs when the temporary directory resides on a filesystem with limited allocation support, such as NFSv3. Reporting a failure adds noise because the test prerequisite is absent rather than the COW implementation being broken. Report EOPNOTSUPP as a skip. Continue treating every other fallocate() error as a failure so unexpected setup regressions remain visible. Link: https://lore.kernel.org/20260727095225.372655-1-usama.anjum@arm.com Link: https://lore.kernel.org/20260727095225.372655-2-usama.anjum@arm.com Fixes: f8664f3c4a08 ("selftests/vm: cow: basic COW tests for non-anonymous pages") Signed-off-by: Muhammad Usama Anjum Tested-by: Sarthak Sharma Acked-by: Usama Arif Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton commit 20d4d490bc0ca5fbfa3f99e1e8e7d398b7971ccb Author: Henry Elderman Date: Fri Aug 7 11:19:58 2026 +0200 mm/execmem: fix fallback_end description in kernel-doc The kernel-doc for struct execmem_range incorrectly describes @fallback_end as "start". Correct it to "end". Link: https://lore.kernel.org/20260807091958.4735-1-henry.elderman.edu+linux@gmail.com Signed-off-by: Henry Elderman Reviewed-by: Mike Rapoport (Microsoft) Signed-off-by: Andrew Morton commit 36a9799b2c86fd0f86d54f3eec8ea37ac467be25 Author: Zhan Xusheng Date: Wed Aug 5 15:05:29 2026 +0800 maple_tree: remove unused mas_is_root_limits() The last callers of mas_is_root_limits() were removed by commit b8852ef30c67 ("maple_tree: remove maple big node and subtree structs"), together with the maple subtree state (mast_*) code that used it. As a static inline it does not trigger -Wunused-function, so it went unnoticed. Remove it. No functional change. Link: https://lore.kernel.org/20260805070529.4118794-1-zhanxusheng@xiaomi.com Signed-off-by: Zhan Xusheng Reviewed-by: Liam R. Howlett (Oracle) Cc: Alice Ryhl Cc: Andrew Ballance Signed-off-by: Andrew Morton commit dc924f0f85afd5a211357e2f2b670772853d1ce3 Author: Audra Mitchell Date: Thu Aug 6 11:00:34 2026 -0400 selftests/mm/vm_util.c: correct __pagemap_scan_get_categories return value Currently __pagemap_scan_get_categories returns the result from the ioctl call which should be an int, not uint64_t. The ioctl may return -1 on error, which will be interpreted as UINT64_MAX. Adjust the return type to use the correct value. Link: https://lore.kernel.org/20260806150339.1824251-2-audra@redhat.com Signed-off-by: Audra Mitchell Reviewed-by: Liam R. Howlett (Oracle) Acked-by: David Hildenbrand (Arm) Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 54cc9b38470905e7fdf4a8786e9b1b85ac045f0a Author: Ye Liu Date: Thu Aug 6 08:45:55 2026 +0800 mm: debug_page_alloc: fix NULL buf in debug_guardpage_minorder_setup If the kernel command line includes "debug_guardpage_minorder" without an equals sign (i.e., no value is provided), the early parameter parser passes a NULL buf pointer to the setup function. kstrtouint() does not perform a NULL check on its input and calls directly into kstrtoull() which dereferences s[0] unconditionally, leading to a NULL pointer dereference and early boot crash. Additionally, the error path's pr_err("%s", buf) would also crash with a NULL format argument. Link: https://lore.kernel.org/20260806004556.2633049-1-ye.liu@linux.dev Fixes: c0a32fc5a2e4 ("mm: more intensive memory corruption debugging") Signed-off-by: Ye Liu Acked-by: Zi Yan Reviewed-by: John Hubbard Reviewed-by: Andrew Morton Cc: Johannes Weiner Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 4b82a0b91be5f8cf7a3a46d6fa3931224150b6b4 Author: Hongfu Li Date: Thu Aug 6 11:08:50 2026 +0800 selftests/mm: drop duplicate test_seal_mprotect_two_vma_with_gap() call mseal_test main() invokes test_seal_mprotect_two_vma_with_gap() twice. The second run repeats all assertions with no benefit. Drop the duplicate call. Link: https://lore.kernel.org/20260806030850.76077-1-hongfu.li@linux.dev Signed-off-by: Hongfu Li Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Reviewed-by: SJ Park Reviewed-by: Anshuman Khandual Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 76f134aabb623dfcec5c9cd9bece23365dd04cfd Author: Baolin Wang Date: Thu Aug 6 11:34:15 2026 +0800 selftests: mm: add mTHP collapse test cases Added a new command 'mthp_khugepaged' for mTHP collapse, along with the '-c' parameter to specify the collapse order. Additionally, added mTHP collapse test cases for 'collapse_full', 'collapse_empty', and 'collapse_single_mthp' for anonymous folios. All khugepaged test cases passed. Link: https://lore.kernel.org/f260058520214a9611922a96326bc54ba282fb73.1785985999.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang Reviewed-by: Nico Pache (Red Hat) Tested-by: Nico Pache (Red Hat) Acked-by: Kiryl Shutsemau (Meta) Acked-by: Zi Yan Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Ryan Roberts Signed-off-by: Andrew Morton commit 6dedaf0d46a96cb659ba57a959f5493dbab0de31 Author: Baolin Wang Date: Thu Aug 6 11:34:14 2026 +0800 selftests: mm: implement the mTHP-sized hugepage check helpers Implement mTHP-sized hugepage checking helpers using gather_folio_orders(). Also rename the existing PMD-sized huge page check function to __check_pmd_huge() for clarity. Link: https://lore.kernel.org/56b16691f605426b33b5cf47319233de6127a6b3.1785985999.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang Reviewed-by: Nico Pache (Red Hat) Tested-by: Nico Pache (Red Hat) Acked-by: Kiryl Shutsemau (Meta) Reviewed-by: Zi Yan Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Ryan Roberts Signed-off-by: Andrew Morton commit 6995150ede2805914b2fbc3a2ba674d06784c04b Author: Baolin Wang Date: Thu Aug 6 11:34:13 2026 +0800 selftests: mm: move gather_after_split_folio_orders() into vm_util.c file Move gather_after_split_folio_orders() to vm_util.c as a helper function in preparation for implementing checks for mTHP collapse. While we are at it, rename this function to indicate that it is not only used for large folio splits. No functional changes. Link: https://lore.kernel.org/30a0a99556adf11c2bf97aa08d6da4830bb43f6f.1785985999.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang Reviewed-by: Nico Pache (Red Hat) Tested-by: Nico Pache (Red Hat) Reviewed-by: Zi Yan Acked-by: Kiryl Shutsemau (Meta) Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Ryan Roberts Signed-off-by: Andrew Morton commit e4ce743a8f3a8ac1428e220e4d0311f39d64ff87 Author: Baolin Wang Date: Thu Aug 6 11:34:12 2026 +0800 selftests: mm: extend the check_huge() to support mTHP check Patch series "add anon mTHP collapse test cases", v3. This patch (of 4): To support checking for various sized mTHPs during mTHP collapse, extend the check_huge() function prototype to accept two new parameters specifying the address range and mTHP size, in preparation for the following patches. No functional changes. Link: https://lore.kernel.org/cover.1785985999.git.baolin.wang@linux.alibaba.com Link: https://lore.kernel.org/e5039cbc70f8de853e6c21048d65803a5fe41042.1785985999.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang Reviewed-by: Nico Pache (Red Hat) Tested-by: Nico Pache (Red Hat) Acked-by: Zi Yan Acked-by: Kiryl Shutsemau (Meta) Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Ryan Roberts Signed-off-by: Andrew Morton commit 184bf187c45ba6c1141aa7fe10bf10f85d5a7634 Author: Sergey Senozhatsky Date: Thu Aug 6 12:16:32 2026 +0900 zram: switch to unsigned long indexing zram has always used "unsigned int" for (page) index calculations, which unnecessarily limited max zram disksize. Switch to "unsigned long" and permit much larger zram devices. Link: https://lore.kernel.org/20260806031640.536615-1-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Suggested-by: Andrew Morton Co-developed-by: Longlong Xia Cc: Minchan Kim Signed-off-by: Andrew Morton commit 8be7c167be5792ce9c9fcb784b4cd086624feed2 Author: Ye Liu Date: Wed Aug 5 10:15:55 2026 +0800 mm/show_mem: fix format string inconsistencies and type mismatches Fix five format string issues in show_free_areas() and __show_mem(): 1-2. reserved_highatomic and free_highatomic: %luKB -> %lukB The uppercase "KB" is inconsistent with all other fields in the same output block and with /proc/meminfo convention. 3. local_pcp: %ukB -> %lukB with explicit (unsigned long) cast per_cpu_pages.count is int, so K(count) yields int. Using %u was a signed/unsigned mismatch. Cast to unsigned long and use %lu for consistency with all other K() usages in the file. 4. total pagecache pages: %ld -> %lu global_node_page_state() returns unsigned long. Using %ld is a signedness mismatch caught by gcc -Wformat-signedness. 5. hwpoisoned pages: %lu -> %ld atomic_long_read() returns long (signed). Using %lu is a signedness mismatch caught by gcc -Wformat-signedness. Verified with: make KCFLAGS="-Wformat -Wformat-signedness" mm/show_mem.o Link: https://lore.kernel.org/20260805021556.1908807-1-ye.liu@linux.dev Signed-off-by: Ye Liu Acked-by: Vlastimil Babka (SUSE) Acked-by: Johannes Weiner Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Zi Yan Signed-off-by: Andrew Morton commit e73aeb8a411e5327da9c0746b2f93924ab081113 Author: Muchun Song Date: Wed Aug 5 10:25:36 2026 +0800 mm/sparse: keep mem_section_usage_size() internal mem_section_usage_size() is only needed by sparsemem implementation code after commit ae751d567baa ("mm/bootmem_info: stop marking mem_section_usage as MIX_SECTION_INFO"), so keeping the declaration in mmzone.h now exposes the helper to all mmzone.h users for no reason. Move the helper to sparse.h so sparse.c and sparse-vmemmap.c can share it through the internal header. While doing so, calculate the allocation size with struct_size_t(), which ties the expression to the pageblock_flags trailing array instead of open-coding the struct header plus bitmap size. Link: https://lore.kernel.org/20260805022536.1206575-1-songmuchun@bytedance.com Signed-off-by: Muchun Song Acked-by: Mike Rapoport (Microsoft) Acked-by: David Hildenbrand (Arm) Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit afff109c2f8b35b88ea783d345c1067a311a57d8 Author: Abhishek Bapat Date: Wed Aug 5 17:29:52 2026 +0000 alloc_tag: expose boot-time compression configuration Currently, userspace has limited visibility into the exact active runtime state of memory allocation profiling and its page extension compression ('sysctl.vm.mem_profiling={0|1|never}[,compressed]'). While reading the sysctl provides basic on/off status, it is currently impossible for userspace to natively determine whether page-tag compression was successfully enabled without scraping dmesg boot logs. Add a new read-only sysctl representing how compression was configured at boot time. Link: https://lore.kernel.org/c795f8089f82841e8a6e00d7ca286da2b23aeb7b.1785950530.git.abhishekbapat@google.com Signed-off-by: Abhishek Bapat Acked-by: Suren Baghdasaryan Cc: Hao Ge Signed-off-by: Andrew Morton commit bb3e3c5c2d63fa55566a4b0647fffd68172ee17f Author: Ye Liu Date: Wed Aug 5 17:31:07 2026 +0800 mm: debug_page_alloc: fix type mismatch for debug_guardpage_minorder The debug_guardpage_minorder local variable is declared as unsigned int, but debug_guardpage_minorder_setup() uses unsigned long and kstrtoul() to parse the value. Use kstrtouint() with unsigned int local variable to match the actual type of _debug_guardpage_minorder. Also fix the format specifier from %lu to %u accordingly. Link: https://lore.kernel.org/20260805093108.2352900-1-ye.liu@linux.dev Signed-off-by: Ye Liu Reviewed-by: Andrew Morton Cc: Johannes Weiner Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton commit 391f057f44a51cc9418da5cba78b014324174264 Author: Longlong Xia Date: Tue Aug 4 14:59:19 2026 +0800 zram: fix out-of-bounds access in read_block_state() read_block_state() calculates nr_pages before taking dev_lock. If the device is reset and reinitialized with a smaller disksize before lock acquisition, nr_pages still describes the old table. The subsequent loop can then call slot_lock() past the end of the newly allocated table. Read disksize after acquiring dev_lock and checking that the device is initialized. The read lock then keeps the table and its bound stable for the duration of the scan. Link: https://lore.kernel.org/20260804065919.3970386-3-xialonglong2025@163.com Fixes: c0265342bff4 ("zram: introduce zram memory tracking") 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 commit 894913e2d35c46ff19a77530907771ae57862b96 Author: Longlong Xia Date: Tue Aug 4 14:59:18 2026 +0800 zram: fix out-of-bounds access in writeback_store() 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 commit 702c5a799db20e49fe67cdfa27bac65374ad00ab Author: Haoqin Huang Date: Tue Aug 4 17:38:41 2026 +0800 zram: reset per-priority params when changing algorithm before init Parameters validated against one algorithm may be invalid for another (e.g. lz4 accepts level=65535 but zstd does not). Although algorithm changes are blocked after disksize is set, they are allowed before device initialization. Reset per-priority params on algorithm change so that stale parameters do not silently carry over. Link: https://lore.kernel.org/20260804093841.67920-6-haoqinhuang7@gmail.com Signed-off-by: Haoqin Huang Signed-off-by: Rongwei Wang Reviewed-by: Sergey Senozhatsky Tested-by: Sergey Senozhatsky Cc: David Sterba Cc: Jens Axboe Cc: Minchan Kim Cc: Nick Terrell Signed-off-by: Andrew Morton commit 7b0f677c7bd539bd5695b14f9a195e257c3b4463 Author: Haoqin Huang Date: Tue Aug 4 17:38:40 2026 +0800 zram: validate parameters in each backend's setup_params Dict and level parameters are silently accepted even for backends that do not support them. Validate these parameters in each backend's .setup_params() to reject unsupported combinations and out-of-range levels with a specific error message. Link: https://lore.kernel.org/20260804093841.67920-5-haoqinhuang7@gmail.com Signed-off-by: Haoqin Huang Signed-off-by: Rongwei Wang Reviewed-by: Sergey Senozhatsky Tested-by: Sergey Senozhatsky Cc: David Sterba Cc: Jens Axboe Cc: Minchan Kim Cc: Nick Terrell Signed-off-by: Andrew Morton commit 70922d5ef84a5863ac80d4b13f574cb9e461a716 Author: Haoqin Huang Date: Tue Aug 4 17:38:39 2026 +0800 zram: add pr_fmt to backend files Add pr_fmt to each backend so that pr_err() messages are auto-prefixed with the algorithm name. While at it, tweak the deflate winbits pr_err to avoid a duplicated "deflate" prefix. Link: https://lore.kernel.org/20260804093841.67920-4-haoqinhuang7@gmail.com Signed-off-by: Haoqin Huang Signed-off-by: Rongwei Wang Reviewed-by: Sergey Senozhatsky Tested-by: Sergey Senozhatsky Cc: David Sterba Cc: Jens Axboe Cc: Minchan Kim Cc: Nick Terrell Signed-off-by: Andrew Morton commit 6dc404d433adf09045565054aecf85714db95b46 Author: Haoqin Huang Date: Tue Aug 4 17:38:38 2026 +0800 zram: reject zero-size dictionary kernel_read_file_from_path() already rejects empty files (i_size <= 0) and returns -EINVAL, but the current implementation only checks for sz < 0 without logging any information. Use sz == 0 to reject the zero-size case and print distinct error messages for each failure type. Link: https://lore.kernel.org/20260804093841.67920-3-haoqinhuang7@gmail.com Signed-off-by: Haoqin Huang Signed-off-by: Rongwei Wang Reviewed-by: Sergey Senozhatsky Tested-by: Sergey Senozhatsky Cc: David Sterba Cc: Jens Axboe Cc: Minchan Kim Cc: Nick Terrell Signed-off-by: Andrew Morton commit 45214458d6b50124afef3187f6352adeddf74d6f Author: Haoqin Huang Date: Tue Aug 4 17:38:37 2026 +0800 zram: do not release zstd global params from error paths Patch series "zram: fix zstd error paths and add parameter validation", v6, Patch 1 removes zstd_release_params() from both zstd_create() and zstd_setup_params() error paths -- the former is a layering violation in a per-CPU callback, the latter is redundant as zcomp_init() already calls release_params() on setup failure. Patch 2 rejects zero-size dictionaries and prints distinct error messages for sz < 0 (returns the original error code) and sz == 0 ("empty file"). Currently errors are silently swallowed. Patch 3 adds pr_fmt to each backend file so that pr_err() messages are auto-prefixed with the algorithm name. Patch 4 validates dict and level parameters in each backend's .setup_params(), rejecting unsupported combinations and out-of-range levels. Patch 5 resets per-priority params on algorithm change before init. This patch (of 5): zstd_setup_params() creates global cdict and ddict stored in params->drv_data, shared across all per-CPU contexts. The per-CPU zstd_create() error path called zstd_release_params(), which freed those globally-shared objects. This is a layering violation: a per-CPU callback should only clean up its own context, not release resources owned by the compression lifecycle. zstd_setup_params() called zstd_release_params() on its own error path as well, but zcomp_init() already calls release_params() when setup fails, so this is redundant. Remove zstd_release_params() from both error paths. Link: https://lore.kernel.org/20260804093841.67920-1-haoqinhuang7@gmail.com Link: https://lore.kernel.org/20260804093841.67920-2-haoqinhuang7@gmail.com Signed-off-by: Haoqin Huang Signed-off-by: Rongwei Wang Reviewed-by: Sergey Senozhatsky Tested-by: Sergey Senozhatsky Cc: David Sterba Cc: Jens Axboe Cc: Minchan Kim Cc: Nick Terrell Signed-off-by: Andrew Morton commit 0ddb8bb85b98ff59f4643b7e4500e45f650dddcf Author: Sang-Heon Jeon Date: Wed Aug 5 00:11:42 2026 +0900 mm/page_ext: remove pgdat_page_ext_init() pgdat_page_ext_init() sets pgdat->node_page_ext to NULL only on FLATMEM. FLATMEM depends on !NUMA, so the pgdat is always the zero-initialized contig_page_data and the store has no effect. So remove the call site, the unused function and its declaration. No functional change. Link: https://lore.kernel.org/20260804151145.3419768-3-ekffu200098@gmail.com Signed-off-by: Sang-Heon Jeon Acked-by: Zi Yan Acked-by: David Hildenbrand (Arm) Cc: Johannes Weiner Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 34568000f3c9aa3a14073f20857d79983345a7df Author: Sang-Heon Jeon Date: Wed Aug 5 00:11:41 2026 +0900 mm/Kconfig: make FLATMEM depend on !NUMA Patch series "mm/page_ext: remove pgdat_page_ext_init()", v2. pgdat_page_ext_init() has no effect on FLATMEM. The pgdat is always the zero-initialized contig_page_data, because no architecture supports FLATMEM + NUMA. That constraint is only implicit in the arch Kconfig files. So patch 1 makes it explicit in mm/Kconfig, and patch 2 removes pgdat_page_ext_init(). No functional change. This patch (of 2): FLATMEM + NUMA is not supported by any architecture and fails to build. The constraint is only implicit in the arch Kconfig files. So make it explicit in mm/Kconfig. No functional change. Link: https://lore.kernel.org/20260804151145.3419768-1-ekffu200098@gmail.com Link: https://lore.kernel.org/20260804151145.3419768-2-ekffu200098@gmail.com Signed-off-by: Sang-Heon Jeon Suggested-by: Zi Yan Acked-by: Zi Yan Acked-by: David Hildenbrand (Arm) Acked-by: Mike Rapoport (Microsoft) Cc: Johannes Weiner Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 6fd3e592c09dd19d5ba47e45dc5f38837629d1ba Author: Lorenzo Stoakes (ARM) Date: Tue Aug 4 11:08:59 2026 +0100 mm: add some missing includes to mm-local headers There are a number of internal headers local to mm/ which reference functions and data types without including the relevant headers. mm/vma.h is a special case that intentionally does not include additional headers, but the others are not. This breaks tooling like clangd (which is where I noticed this), though the build is OK due to the C files including the headers happening to include required dependencies. It's better to be explicit about dependencies anyway, so add the missing includes and fix clangd as a bonus. Link: https://lore.kernel.org/20260804-fix-some-local-headers-v1-1-a7beb173c116@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: Vlastimil Babka (SUSE) Acked-by: David Hildenbrand (Arm) Acked-by: Zi Yan Reviewed-by: Barry Song Reviewed-by: Baoquan He Cc: Chris Li Cc: Johannes Weiner Cc: Kairui Song Cc: Kemeng Shi Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Nhat Pham Cc: Oscar Salvador Cc: Roman Gushchin Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: "Uladzislau Rezki (Sony)" Signed-off-by: Andrew Morton commit b9183788a2def7b26785eccc8c23dba2bbf9e5b1 Author: Uladzislau Rezki (Sony) Date: Sun Aug 2 12:46:27 2026 +0200 mm/vmalloc: do not warn on -ENOMEM from va_alloc() Since vmalloc() accepts non-blocking GFP flags, allocation requests may fail when callers pass restrictive GFP masks. va_clip() may return -ENOMEM when its GFP_NOWAIT fallback allocation fails during NE_FIT_TYPE splitting. This is an expected failure, so va_alloc() should return the error without triggering a kernel splat. Link: https://lore.kernel.org/20260802104627.63892-1-urezki@gmail.com Signed-off-by: Uladzislau Rezki (Sony) Reported-by: syzbot+61c997e6be1d9bb300ba@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a6d3cbd.6ce73036.24301b.000e.GAE@google.com Reviewed-by: Anshuman Khandual Reviewed-by: Baoquan He Signed-off-by: Andrew Morton commit a44ab4bd1ec0432d686c25f9c160379ffa1e694c Author: Hongfu Li Date: Wed Aug 5 18:59:07 2026 +0800 ksm: update comments and docs to reference folio->mapping The KSM code already stores and checks the stable node key via folio->mapping, but the comment in ksm_get_folio() and the reverse mapping documentation in ksm.rst still refer to page->mapping. This is a pure wording update to match the folio-based implementation. No functional change is intended. Link: https://lore.kernel.org/20260805105927.41987-1-hongfu.li@linux.dev Signed-off-by: Hongfu Li Acked-by: David Hildenbrand (Arm) Reviewed-by: Xu Xin Reviewed-by: Dongliang Mu Cc: Alex Shi Cc: Chengming Zhou Cc: David Hildenbrand Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Yanteng Si Signed-off-by: Andrew Morton commit 3c37cac718fa407b6656d925c4437ed5410fcdda Author: Longlong Xia Date: Wed Aug 5 21:27:34 2026 +0800 mm/ksm: avoid missing ksmd wakeups in ksm_enter __ksm_enter() decides whether ksmd needs a wakeup by checking if the mm slot list is empty before inserting the new slot. The empty check is currently outside ksm_mmlist_lock. Another CPU can remove the last slot and let ksmd go back to sleep after the unlocked check, while this CPU inserts a new slot and skips the wakeup based on the stale result. Take ksm_mmlist_lock before checking the list so the empty-to-nonempty transition and the insertion are observed as one critical section. Link: https://lore.kernel.org/20260805132736.1063408-1-xialonglong2025@163.com Fixes: 6e15838425ac ("ksm: keep quiet while list empty") Signed-off-by: Longlong Xia Acked-by: David Hildenbrand (Arm) Reviewed-by: Andrew Morton Cc: Chengming Zhou Cc: Izik Eidus Cc: xu xin Signed-off-by: Andrew Morton commit 2bee308f3adbd09aa7f6b01fd2271de36538973c Author: Pratyush Mallick Date: Mon Aug 3 22:17:32 2026 +0000 selftests/mm: use pattern matching in .gitignore The current .gitignore hardcodes each generated test binary by name, requiring updates every time a new test is added. Switch to the pattern-matching approach similar to KVM:selftests. Ignore everything by default and then allow source extensions (.c, .h, .sh) and tracked non-source files. Note that local_config.h was renamed to local_config.h_gen in a previous patch so that un-ignoring *.h files does not cause generated build artifacts to become untracked. [akpm@linux-foundation.org: fix botched merge resolution] Link: https://lore.kernel.org/20260803221732.3651981-3-pratmal@google.com Signed-off-by: Pratyush Mallick Reviewed-by: Lorenzo Stoakes Acked-by: Mike Rapoport (Microsoft) Suggested-by: Yosry Ahmed Reviewed-by: SJ Park Acked-by: David Hildenbrand (Arm) Cc: Jason Gunthorpe Cc: John Hubbard Cc: "Liam R. Howlett" Cc: Michal Hocko Cc: Peter Xu Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 8bc69b8d209f2c08b8a311e63b910b8a718eee79 Author: Warren Xiong Date: Tue Aug 4 20:16:58 2026 +0800 selftests/mm: read memory information without popen read_memory_info() invokes two shell pipelines to obtain MemFree and Hugepagesize from /proc/meminfo. It does not check whether popen() returns NULL before passing the result to fgets(), and it does not call pclose() when fgets() fails. Open /proc/meminfo directly and obtain both values in a single pass. This removes the unchecked NULL path, closes the file on all paths, and avoids dependencies on external commands. The compaction test continues to pass after this change. Link: https://lore.kernel.org/1785845818-3131-1-git-send-email-warren.xiong@ugreen.com Signed-off-by: Warren Xiong Acked-by: David Hildenbrand (Arm) Acked-by: Mike Rapoport (Microsoft) Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 4e7e499b750f0ba1806a9f60ad091364c3382ad1 Author: Pratyush Mallick Date: Mon Aug 3 22:17:31 2026 +0000 selftests/mm: rename local_config.h to local_config.h_gen Patch series "selftests/mm: use pattern matching in .gitignore", v4. The current selftests/mm/.gitignore hardcodes each generated test binary by name, which requires manual updates every time a new test is added. This series switches to a pattern-matching approach (similar to KVM selftests), ignoring everything by default and allowing specific source extensions. To accommodate this without tracking generated headers, local_config.h is renamed to local_config.h_gen. This patch (of 2): Because local_config.h is a generated build artifact, un-ignoring all .h files in .gitignore causes it to incorrectly show up as an untracked file in git status. Rename it to local_config.h_gen so it no longer matches the !*.h inclusion rule, preparing for a subsequent patch that switches .gitignore to a pattern-matching approach. Update Makefile, check_config.sh, and affected test sources (cow.c, gup_longterm.c) accordingly. Link: https://lore.kernel.org/20260803221732.3651981-1-pratmal@google.com Link: https://lore.kernel.org/20260803221732.3651981-2-pratmal@google.com Signed-off-by: Pratyush Mallick Reviewed-by: Lorenzo Stoakes Acked-by: Mike Rapoport (Microsoft) Suggested-by: David Hildenbrand Cc: Jason Gunthorpe Cc: John Hubbard Cc: "Liam R. Howlett" Cc: Michal Hocko Cc: Peter Xu Cc: SeongJae Park Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Yosry Ahmed Signed-off-by: Andrew Morton commit 32c9625638c2fda23b9301be5184b8abf84c92a7 Author: Daniel Palmer Date: Sat May 23 22:04:45 2026 +0900 tmpfs/ramfs: let memfd_create() work on nommu Currently trying to use memfd_create() on nommu returns an error with errno set to EFBIG. The manpage memfd_create() doesn't have EFBIG as a possible error value. Doing some digging this is coming from 0 getting passed as newsize to ramfs_nommu_expand_for_mapping() and that getting into get_order() and there "The result is undefined if the size is 0". Whatever comes out of get_order() is then used in the following logic and that results in the EFBIG that causes the syscall to fail and the errno in userspace. If newsize is 0 there is nothing to do so just return. Roughly tested on m68k nommu by creating a process, creating an memfd, forking another process, mmap()ing the memfd in the child, writing into the mapping, then mmap()ing in the parent and checking that the right data is there. Link: https://lore.kernel.org/20260523130445.1101818-1-daniel@thingy.jp Signed-off-by: Daniel Palmer Acked-by: Lorenzo Stoakes Cc: "Liam R. Howlett" Cc: Al Viro Cc: Christian Brauner Signed-off-by: Andrew Morton commit 8282cb36d021835e6574c393df6a4aed1bf6ada3 Author: Jianlin Shi Date: Thu Aug 6 16:27:34 2026 +0800 mm/page_alloc: only update lowmem_reserve_ratio on sysctl write lowmem_reserve_ratio_sysctl_handler() ignores the return value of proc_dointvec_minmax() and always calls setup_per_zone_lowmem_reserve(), even for read operations. Fix three issues: 1. Propagate errors from proc_dointvec_minmax() instead of always returning success. For example, writing non-integer garbage to the sysctl now returns an error instead of silently succeeding with unchanged values. 2. Only call setup_per_zone_lowmem_reserve() when the sysctl is actually written, matching the write-only refresh pattern of min_free_kbytes and watermark_scale_factor handlers. 3. On write, parse into a temporary ratio[] array and only copy into sysctl_lowmem_reserve_ratio[] and refresh derived state after the full vector is validated. This avoids leaving the ratio array partially updated while skipping setup when proc_dointvec_minmax() returns an error on a later element (suggested by Andrew Morton). Drop the manual "< 1 -> 0" sanitization loop and set .extra1 = SYSCTL_ZERO on the ctl_table entry so proc_dointvec_minmax() enforces the minimum on write; negative values now return -EINVAL instead of being silently coerced to 0 (suggested by Vlastimil Babka). [akpm@linux-foundation.org: add comment, per hannes] Link: https://lore.kernel.org/anSRGASe5FIrqwlg@cmpxchg.org Link: https://lore.kernel.org/linux-mm/tencent_FFD4F4D728AAE8A8AE0AF277A59854A29A06@qq.com/ Link: https://lore.kernel.org/tencent_A860C873956A52E26AD8D309A308A241BA08@qq.com Signed-off-by: Jianlin Shi Acked-by: Vlastimil Babka (SUSE) Cc: Brendan Jackman Cc: Johannes Weiner Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Zi Yan Cc: Joel Granados Signed-off-by: Andrew Morton commit c310a8932a3107c9bc8f01d473e9d085f8aa9c98 Author: Eric Biggers Date: Mon Aug 3 11:04:26 2026 -0700 mm/swap: reject swapon() on filesystem-level encrypted files ext4 and f2fs don't prevent filesystem-level encrypted files from being set up directly as swap files. In this case, encryption is bypassed. No one should be doing this, vs. the methods of encrypted swap that actually do work (such as swapping to a dm-crypt device, or swapping to a loopback device on top of a filesystem-level encrypted file). Nevertheless, to prevent user error, make swapon() explicitly reject this case. Document this behavior in fscrypt.rst as well. Link: https://lore.kernel.org/20260803180426.3123-1-ebiggers@kernel.org Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support") Fixes: f424f664f0e8 ("f2fs crypto: add encryption policy and password salt support") Signed-off-by: Eric Biggers Reviewed-by: Baoquan He Reviewed-by: Muhammad Usama Anjum Reviewed-by: "Darrick J. Wong" Cc: Barry Song Cc: Chris Li Cc: Kairui Song Cc: Kemeng Shi Cc: Nhat Pham Cc: Signed-off-by: Andrew Morton commit 272b0d84b17f72f6396254dbaa6264f2f74a7997 Author: Artem Lytkin Date: Sat Aug 1 14:49:15 2026 +0300 mm/vmalloc: make vm_struct.nr_pages an unsigned long vm_struct::nr_pages is an unsigned int, and the file keeps deriving byte counts from it as nr_pages << PAGE_SHIFT. A shift is evaluated in the type of its promoted left operand, so those are 32-bit arithmetic and wrap at 4 GiB of bytes, which is 2^20 pages. Every site depends on a cast being remembered; vmap() has one, two recent commits did not. vread_iter() then computes a size of zero for a 4 GiB VM_ALLOC area and /proc/kcore returns it as zeros while reporting a successful read, which drgn, crash or gdb cannot tell from real memory, and the vrealloc() grow-in-place check declines a request that would have fit. Widen the field so the class of bug goes away instead of one site at a time. Everything feeding or consuming it widens too: vm_area_alloc_pages() and its accumulators, nr_small_pages, new_nr_pages and old_nr_pages, the index range of vm_area_free_pages(), and three page indexes that were plain int. Five casts go. Two prints needed fixing as well, %u in vmalloc_dump_obj() and %d for the unsigned field in vmalloc_info_show(). No bug report behind this, I found it reading the code. The 4 GiB wrap needs only a machine with over 4 GiB of memory. Neither larger threshold is a practical concern: 2^32 pages, where the field itself truncates, is 16 TiB and beyond what hardware can populate, and 2^31, where the plain int indexes break, is 8 TiB and larger than anything in the tree asks for. The int *nr cursor in the mapping path is unchanged and is separate work. Users outside mm/vmalloc.c need no change either. Those handing the count to a narrower parameter cannot drive it near 2^31, and kho_preserve_vmalloc() stores it into a 32-bit ABI field that still receives the same low bits; above 2^32 pages the truncation just moves out of vm_struct into that store. sizeof(struct vm_struct) on x86-64 stays 72 bytes with CONFIG_HAVE_ARCH_HUGE_VMALLOC=n and goes from 72 to 80 with it enabled, both inside the kmalloc-96 bucket it already comes from. Link: https://lore.kernel.org/20260801114915.115224-1-iprintercanon@gmail.com Fixes: 0bca23804632 ("mm/vmalloc: use physical page count in vread_iter() for VM_ALLOC areas") Fixes: d57ac904ffdc ("mm/vmalloc: use physical page count for vrealloc() grow-in-place check") Signed-off-by: Artem Lytkin Suggested-by: Andrew Morton Reviewed-by: Uladzislau Rezki (Sony) Assisted-by: Claude:claude-fable-5 Cc: Matthew Wilcox (Oracle) Cc: Cc: Signed-off-by: Andrew Morton commit fc6415a384f026f48b414a48588c0970c060679f Author: David Hildenbrand (Arm) Date: Thu Aug 6 20:09:06 2026 +0200 mm/gup: factor out LRU cache draining for folio into lru_cache_drain_for_folio() KVM with guest_memfd wants to remove any folio references due to LRU caches, as it really must only allow to convert folios from shared to private when there are no unexpected folio references (e.g., from GUP references). So, to drive the refcount down, it needs a way to flush the LRU caches. Let's factor out what we have in lru_cache_drain_for_folio(). Document it, and also mention that concurrent folio (un)mapping might, in theory, miss detecting LRU cache references. Keep obtaining the expected refcount twice to minimize the possibility. For the current and future user that should work, and we don't really have a better alternative: we could detect if the mapcount changed, but it would still be racy and add more complexity with questionable benefit. Maybe there is a chance to avoid the draining entirely in the future, by avoiding extra references from the LRU cache: Hugh thinks there might be a way. But for the time being, this handling is unfortunately required. Make folio_may_be_lru_cached() accept a const pointer so lru_cache_drain_for_folio() can accept a const pointer as well. Link: https://lore.kernel.org/20260806-lru_cache_drain_for_folio-v1-1-c6287d295e99@kernel.org Signed-off-by: David Hildenbrand (Arm) Reviewed-by: Fuad Tabba Cc: Ackerley Tng Cc: Baoquan He Cc: Barry Song Cc: Chris Li Cc: Jason Gunthorpe Cc: John Hubbard Cc: Kairui Song Cc: Kemeng Shi Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Nhat Pham Cc: Peter Xu Cc: Sean Christopherson Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 078e1a0fc41a42baaf113383b52dab8874c0b967 Author: David Hildenbrand (Arm) Date: Fri Jul 31 22:27:53 2026 +0200 mm/gup: fix always draining LRU caches in collect_longterm_unpinnable_folios() folio_may_be_lru_cached() is currently only true for small folios, and for small folios FOLL_PIN adds GUP_PIN_COUNTING_BIAS references instead of 1 in try_grab_folio()/try_grab_folio_fast(). Consequently, our folio_ref_count(folio) != folio_expected_ref_count(folio) + 1 check in collect_longterm_unpinnable_folios() will currently always identify "reference mismatch" and first drain the local LRU cache to then drain the LRU cache on all CPUs, as collect_longterm_unpinnable_folios() is really called after pinning the folios with FOLL_PIN. Add a comment because the current code is not quite intuitive: we used to drain only to make sure the folio_isolate_lru() would succeed. But then we also started draining to make later migration more reliable. We'll refactor that code soon a bit, to also make it usable in other context where we really want to remove any references from LRU caches. Let's add CC stable, because having an easy way for excessive LRU cache draining on all CPUs does not sound right. In common scenarios we don't expect to ever have to drain. Link: https://lore.kernel.org/20260731-check_and_migrate_movable_folios-v1-1-e0002d7b791e@kernel.org Fixes: 98c6d259319e ("mm/gup: check ref_count instead of lru before migration") Fixes: a09a8a1fbb37 ("mm/gup: local lru_add_drain() to avoid lru_add_drain_all()") Signed-off-by: David Hildenbrand (Arm) Acked-by: Hugh Dickins Cc: Ackerley Tng Cc: Jason Gunthorpe Cc: John Hubbard Cc: Kiryl Shutsemau Cc: Peter Xu Cc: Signed-off-by: Andrew Morton commit 789763523fb43cdc328de5cb5dcd19240ccf90d8 Author: Zi Yan Date: Tue Aug 4 17:04:28 2026 -0400 xarray: honor XA_FLAGS_ACCOUNT in xas_split_alloc() XArray operations that allocate xa_nodes, such as xas_nomem() and xas_alloc(), add __GFP_ACCOUNT when the array has XA_FLAGS_ACCOUNT set. This charges the allocated memory and avoids the workingset convergence issue described by commit 7b785645e8f13 ("mm: fix page cache convergence regression"). xas_split_alloc() does not add _GFP_ACCOUNT when XA_FLAGS_ACCOUNT is present. Fix it. Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-2-38cb3ff325c5@nvidia.com Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache") Signed-off-by: Zi Yan Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: Johannes Weiner Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Matthew Wilcox (Oracle) Cc: Ryan Roberts Cc: William Kucharski Cc: Signed-off-by: Andrew Morton commit c299a2285d9d8bda4da024455de65e3d00de6f17 Author: Zi Yan Date: Tue Aug 4 17:04:27 2026 -0400 mm/huge_memory: use folio's memcg inside __folio_split() Patch series "Honor XA_FLAGS_ACCOUNT in xas_split_alloc() and charge to folio's memcg", v3. __GFP_ACCOUNT is needed for xarray node allocation accounting when XA_FLAGS_ACCOUNT is set. Commit 7b785645e8f13 ("mm: fix page cache convergence regression") fixed a workingset regression with it. xas_split_alloc() does not have it and needs to be fixed. In addition, based on Sashiko's review[1] and Johannes' confirmation[2], to charge the right memcg, folio's memcg needs to be active during folio split. Add that before adding __GFP_ACCOUNT. There is no workingset convergence regression related to missing __GFP_ACCOUNT in xas_split_alloc() and the impact to userspace should be minor. This patch (of 2): During a pagecache folio split, an xarray node allocation can happen and needs to charge at folio's memcg instead of folio split invoker's memcg, because for example folio split can happen during reclaim and reclaim's active memcg might not be folio's memcg. Switch to folio's memcg at the beginning and switch back afterwards. Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-0-38cb3ff325c5@nvidia.com Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-1-38cb3ff325c5@nvidia.com Link: https://sashiko.dev/#/patchset/20260727-add-gfp_account-to-xas_split_alloc-v1-1-9fae6bf64838%40nvidia.com?part=1 [1] Link: https://lore.kernel.org/all/amtcBZ-_QVRgCd6b@cmpxchg.org/ [2] Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache") Signed-off-by: Zi Yan Suggested-by: Johannes Weiner Reviewed-by: Baolin Wang Acked-by: Lorenzo Stoakes (ARM) Acked-by: Johannes Weiner Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Matthew Wilcox (Oracle) Cc: Ryan Roberts Cc: William Kucharski Cc: Signed-off-by: Andrew Morton commit 34a00895d032a414830d41106a09329ae6c251b6 Author: Arvind Yadav Date: Tue Jul 28 11:58:32 2026 +0530 mm/migrate_device: clear stale mapping after freeing swapcache __migrate_device_pages() reads the folio mapping before calling folio_free_swap(). When folio_free_swap() succeeds, the folio is removed from the swap cache, but the saved mapping still points to swap_space. Passing the stale mapping to folio_migrate_mapping() makes it use the mapped-folio path for a folio that is no longer in swapcache. It can then operate on swap_space.i_pages with invalid reference accounting, eventually triggering a folio reference count BUG. After a successful split, nr still contains the number of pages in the original large folio, although each resulting page is now a separate order-0 folio. Reset nr to 1 so each split folio is processed separately, including its own swapcache removal and mapping lookup. Refresh the saved mapping after folio_free_swap() so the current folio state is used during migration. Link: https://lore.kernel.org/20260728062832.1107127-1-arvind.yadav@intel.com Fixes: df263d9a7dff ("mm/migrate_device: try to handle swapcache pages") Signed-off-by: Arvind Yadav Reviewed-by: Zi Yan Reviewed-by: Balbir Singh Cc: David Hildenbrand Cc: Matthew Brost Cc: Joshua Hahn Cc: Rakie Kim Cc: Byungchul Park Cc: Gregory Price Cc: Ying Huang Cc: Alistair Popple Cc: Signed-off-by: Andrew Morton commit 7822fa5f4f647d05d31eea3edd01382c6183e4cd Author: Wilson Felipe Pereira Date: Fri Jul 31 05:37:06 2026 +0000 mm: zswap: drop list_lru param from zswap_lru_add() and _del() Since zswap_lru_add() and zswap_lru_del() are only called with the global zswap_list_lru, remove the redundant list_lru argument and use zswap_list_lru directly. Link: https://lore.kernel.org/20260731053721.1412304-1-wfelipe@google.com Signed-off-by: Wilson Felipe Pereira Acked-by: Johannes Weiner Acked-by: Yosry Ahmed Reviewed-by: SJ Park Acked-by: Nhat Pham Cc: Chengming Zhou Signed-off-by: Andrew Morton commit 8380671909bfcdd44818abf6b93f82bd3669bc8c Author: Sang-Heon Jeon Date: Sat Aug 1 01:47:55 2026 +0900 mm/sparse: correct init section annotations The !SPARSEMEM_EXTREME stub of sparse_index_init() has no annotation but the SPARSEMEM_EXTREME variant is __meminit. So mark the stub __meminit too. mminit_validate_memmodel_limits() is only called by memory_present(), which is __init. So mark it __init. sparse_usagebuf and sparse_usagebuf_end are only used by sparse_init_early_section(), sparse_usage_init() and sparse_usage_fini(), which are all __init. So mark them __initdata. Link: https://lore.kernel.org/20260731164758.1210668-1-ekffu200098@gmail.com Signed-off-by: Sang-Heon Jeon Reviewed-by: Andrew Morton Acked-by: David Hildenbrand (Arm) Acked-by: Mike Rapoport (Microsoft) Reviewed-by: Anshuman Khandual Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 7a39f03bc9da3499c2423758f353ab72d23faa16 Author: Pratyush Mallick Date: Fri Jul 31 19:37:05 2026 +0000 mm/page_reporting: add page_reporting_delay_ms module parameter Free page reporting currently hardcodes a 2-second interval between reports. This rigid delay cannot accommodate diverse guest workloads. This patch introduces a module parameter, page_reporting_delay_ms (default: 2000), allowing users to tune the reporting rate: - Lower values enable aggressive memory reclamation by returning unused pages to the host immediately. - Higher values help batch pages during spiky allocation/free churn, reducing hypercalls and nested page fault overheads. Setting the delay to 0 is safe and execution is strictly gated by: - reporting is only triggered by high-order page frees. - expensive hypercalls are bounded by a slot capacity watermark check before proceeding. Link: https://lore.kernel.org/20260731193705.2902728-1-pratmal@google.com Signed-off-by: Pratyush Mallick Reviewed-by: SJ Park Acked-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Anshuman Khandual Cc: Brendan Jackman Cc: Greg Thelen Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: SeongJae Park Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton commit 5120b1e048d48596ffaec1a8412012a91adba73b Author: Guillaume Morin Date: Tue Jul 28 21:29:03 2026 +0200 hugetlb: only adjust reservation during unmapping if mapcount is 0 Since df7a6d1f6405, __unmap_hugepage_range can adjust reservations. In the case of folio mapped in both a parent and a child, if the parent unmaps the range first, the reservation adjustment will result in an underflow of the reserved count. Once the child unmaps the range, the count is restored. Change __unmap_hugepage_range() to check the mapcount before adjusting the reservation. Link: https://lore.kernel.org/all/alEJkwn5VlTTH_ZX@bender.morinfr.org/ Link: https://lore.kernel.org/amkC_1Ya6OiUoiLZ@bender.morinfr.org Fixes: df7a6d1f6405 ("mm/hugetlb: restore the reservation if needed") Signed-off-by: Guillaume Morin Reviewed-by: Breno Leitao Reviewed-by: Rik van Riel Cc: Muchun Song Cc: David Hildenbrand Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton commit 62e39381b7804eb94a43bd1e0b0c216aad3e5f08 Author: Alexander Gordeev Date: Mon Jul 20 16:16:33 2026 +0200 mm: use proper PTE accessor in move_ptes() Follow the pattern established by commit c33c794828f2 ("mm: ptep_get() conversion") and use the proper PTE accessor instead of a direct pointer dereference. Link: https://lore.kernel.org/20260720141633.501799-1-agordeev@linux.ibm.com Fixes: b36b701bbcd9 ("mm: expose abnormal new_pte during move_ptes") Signed-off-by: Alexander Gordeev Acked-by: David Hildenbrand (Arm) Cc: Ryan Roberts Signed-off-by: Andrew Morton commit 6b0d1083364fc8e7cc2f7d1f93ee3ee78f4d52f7 Author: Shakeel Butt Date: Tue Jul 28 19:46:12 2026 -0700 memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done At Meta, we are seeing instances where an OOM killed job is stuck in the exit path for several hours. In one particular case, the job was stuck for more than 8 hours and I had to manually remove the memory.max limits to allow the process to exit. The job was a single process job and had ~55 GiB memory.max and zswap enabled. It had almost 0 anon in memory and ~111 GiB in zswap compressed to ~51 GiB zswap pool (i.e. almost all of memory.current was zswap). Nothing was left on the LRUs to reclaim. On further inspection, I observed ~20k threads of that process stuck with the following stack: [<0>] mem_cgroup_out_of_memory+0x4e/0xa0 [<0>] charge_memcg+0x8bf/0x990 [<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80 [<0>] __read_swap_cache_async+0x10c/0x260 [<0>] swapin_readahead+0x116/0x3f0 [<0>] do_swap_page+0x13c/0x1ce0 [<0>] handle_mm_fault+0x61d/0x11f0 [<0>] do_user_addr_fault+0x3e7/0x6d0 [<0>] exc_page_fault+0x8f/0x110 [<0>] asm_exc_page_fault+0x22/0x30 [<0>] __get_user_8+0x14/0x20 [<0>] futex_cleanup+0x27/0x1c0 [<0>] futex_exit_release+0x47/0x60 [<0>] do_exit+0x107/0x940 [<0>] do_group_exit+0x81/0xa0 [<0>] get_signal+0x2b1/0x6e0 [<0>] arch_do_signal_or_restart+0x1a/0x1c0 [<0>] exit_to_user_mode_loop+0xa8/0x1c0 [<0>] do_syscall_64+0x152/0x250 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 In addition the dmesg was filled with "Out of memory and no killable processes..." messages. I have no idea why oom reaper was not able to reap/unmap the process. My guess is that since oom reaper tries to acquire mmap_lock in read mode limited number of times and then gives up, there might be a thread of that process which had mmap_lock in write mode at that time. My initial suspicion was the futex_cleanup and kernel page fault causing infinite fault and charge retries but that was put to rest in previous discussions happened on similar problem [1]. My current theory is that it is just a simple slow serialization behind the oom_lock. Unlike page allocator, memcg charge code takes the oom_lock without the "try". Though memcg oom code uses mutex_lock_killable(), note that in the call stack get_signal() consumes SIGKILL (or sigdelset(SIGKILL)) before calling do_group_exit(). So this mutex_lock_killable() is just a mutex_lock() here. Therefore 10s of thousands of threads are waiting on oom_lock and one by one they get -EFAULT from get_user() in the futex cleanup code and bails out. Discussion from [1] led to commit a75ffa26122b ("memcg, oom: do not bypass oom killer for dying tasks") which routes dying tasks into the OOM path precisely so the oom_reaper can reap their mm and free the memory asynchronously. But the reaper is best-effort and one-shot: if it cannot take mmap_lock for read (e.g. a sibling thread holds it for write) it sets MMF_OOM_SKIP and never retries, leaving only the glacial oom_lock-serialized synchronous drain. Once MMF_OOM_SKIP is set there is no more asynchronous reclaim coming for the mm, so a dying task charging against it has nothing left to wait for: it frees its memory only once it finishes exiting. Running reclaim and the (no-victim) OOM killer for it is then pointless, and doing it for 10s of thousands of exiting threads is what serializes them behind oom_lock. So before reclaim, if current is an OOM victim whose reaper is done, fail the charge. Reproduced with 20k threads, each parking a robust futex head on its own zswapped page, OOM-group-killed while a sibling holds mmap_lock for write so the reaper gives up and sets MMF_OOM_SKIP. Tested on next-20260728 and baseline show ~90 seconds exit time while with the patch the exit time reduced to ~3 seconds. Link: https://lore.kernel.org/20260729024612.3369005-1-shakeel.butt@linux.dev Link: https://lore.kernel.org/7a4e5591f45df455e6a485fc5400989569d3d22d.camel@surriel.com/ [1] Signed-off-by: Shakeel Butt Acked-by: Johannes Weiner Acked-by: Michal Hocko Cc: David Rientjes Cc: Muchun Song Cc: Nhat Pham Cc: Rik van Riel Cc: Roman Gushchin Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton commit f74e6dff5440f662bced614b723a7d8f2b05919d Author: Sergey Senozhatsky Date: Thu Jul 30 16:51:46 2026 +0900 Documentation: zram: correct algo parameters configuration documentation zram has always reset all previously set parameters for the given algorithm in comp_params_store(). Make documentation more clear and explicitly state that all relevant/necessary parameters should be set in one configuration write. Link: https://lore.kernel.org/20260730075158.1339787-1-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Jonathan Corbet Cc: Minchan Kim Signed-off-by: Andrew Morton commit 9477820c63cbf4d97114238f3d1ff10dfd6bee3f Author: Guopeng Zhang Date: Fri Jul 24 10:18:05 2026 +0800 mm: memcg: stop reclaim when a limit update is superseded kernfs serializes file operations only per open file, so separate open files can update the same memory.high or memory.max file concurrently. Both handlers store the new limit before synchronous reclaim, but continue to use the writer's local target in the reclaim loop. If another writer raises or removes the limit, the first writer can continue reclaiming toward a stale target. For memory.max, this can leave the writer looping indefinitely once reclaim retries are exhausted. The OOM path sees sufficient margin under the current limit and returns true without killing, while the writer still compares usage against its stale target and records another OOM event. Check the current limit at the start of each reclaim iteration and stop if it no longer matches the writer's target. Reproducer: Populate a cgroup with anonymous memory and disable swapping. Lower memory.max from one open file, then restore it to "max" through another open file after the new limit becomes visible. Without the patch, the first writer remains blocked and repeatedly increments the OOM event counter. With the patch, it returns normally. This was not motivated by a reported production workload. We found it through automated randomized testing for our cgroup observability work and reduced it to the reproducer above. Link: https://lore.kernel.org/20260724021805.1234583-1-guopeng.zhang@linux.dev Fixes: 8c8c383c04f6 ("mm: memcontrol: try harder to set a new memory.high") Fixes: b6e6edcfa405 ("mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage") Signed-off-by: Guopeng Zhang Acked-by: Tao Cui Acked-by: Johannes Weiner Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton commit ec7607ac4717ff521c9c1e9d8271c26293345513 Author: Sergey Senozhatsky Date: Wed Jul 29 13:57:36 2026 +0900 zram: validate deflate params We must validate user-supplied deflate winbits before we pass it to zlib_deflate_workspacesize(), which triggers BUG_ON() if winbits value is outside of valid ranges. Link: https://lore.kernel.org/20260729045745.775973-3-senozhatsky@chromium.org Fixes: dc75a0d93bd5 ("zram: support deflate-specific params") Link: https://sashiko.dev/#/patchset/20260728092935.31139-1-haoqinhuang7@gmail.com Signed-off-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Haoqin Huang Cc: Signed-off-by: Andrew Morton commit dde75313eed0b014c437f48dd75c0308b592cbf9 Author: Sergey Senozhatsky Date: Wed Jul 29 13:57:35 2026 +0900 zram: set default primary compressor in zram_destroy_comps() Patch series "zram: fix zram issues reported by sashiko". Sashiko drove by and reported [1] a couple of zram issues: a possible BUG_ON() in zlib code due to missing winbits range validation and one possible NULL-ptr dereference in zcomp. Both are low risk yet still worth fixing. This patch (of 2): zram_destroy_comps() resets all compressors and leaves them set to NULL, including the primary one, which is invalid device state, as now comp_algorithm_show()->strcmp() can be called on a NULL compressor. Set default primary compressor in zram_destroy_comps(). Link: https://lore.kernel.org/20260729045745.775973-2-senozhatsky@chromium.org Fixes: 486fd58af7ac ("zram: don't free statically defined names") Link: https://sashiko.dev/#/patchset/20260728092935.31139-1-haoqinhuang7@gmail.com [1] Signed-off-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Haoqin Huang Cc: Signed-off-by: Andrew Morton commit 7b9f4e5f81013bcb0d16bf54b349ee323ce0ac01 Author: Usama Arif Date: Mon Jul 27 09:23:25 2026 -0700 mm/vmscan: reduce lru_lock contention via vmstat-derived scan-balance cost The anon/file scan balance in get_scan_count() is driven by two scalars in struct lruvec, anon_cost and file_cost, accumulated by every reclaim producer under lruvec->lru_lock. The acquisition sites for cost work specifically are: - shrink_inactive_list() re-takes lru_lock at function exit purely to call lru_note_cost_unlock_irq() with (nr_pageout, nr_scanned - nr_reclaimed). One acquisition per inactive shrink. - shrink_active_list() does the same with (0, nr_rotated). One acquisition per active shrink. - workingset_refault() takes the lock via folio_lruvec_lock_irq() purely to record the refault cost. One acquisition per refault. - prepare_scan_control() takes lru_lock just to snapshot the two scalars into sc->{anon,file}_cost. - lru_note_cost_unlock_irq() itself walks parent_lruvec and re-acquires lru_lock on each ancestor to propagate the update, adding O(memcg-depth) acquisitions per producer call. This hurts because lru_lock is already a heavy contention point on memory-heavy workloads: every isolate_lru_folios(), move_folios_to_lru() and folio_add_lru() takes it. The cost work itself is trivial (two scalar bumps and one comparison), but it contends with and causes contention for actual LRU manipulation. The parent_lruvec() walk also multiplies cost-update overhead by memcg hierarchy depth. The balance formula for anon and file, respectively, is this: cost = nr_io * SWAP_CLUSTER_MAX + nr_rotated Instead of recording cost and running averaging logic directly when these events occur, snapshot running vmstat counters once per reclaim cycle and derive the balance from event deltas since the last run. Use PGROTATE_* from the preceding patch for the rotation input. WORKINGSET_RESTORE_* and NR_VMSCAN_WRITE provide the remaining event counters. Charge NR_VMSCAN_WRITE through lruvec stats so all inputs can be sampled per lruvec and aggregated through the memcg hierarchy. This is overall cheaper and has fewer lock acquisition sites. Moving accumulation and decay to the reclaim side also improves the cost model across reclaim gaps. With producer-side decay, events that happen while reclaim is idle still age each other before reclaim ever samples the costs. If a workload refaults a large anon set and then a smaller file set before reclaim runs again, the later file activity can age the earlier anon activity out of the cost model. The new scheme observes the whole between-reclaim delta and decays anon and file proportionally, so the scan-balance history better represents what happened since the last reclaim pass. A dedicated per-lruvec spinlock, cost_lock, serialises the delta extraction, the cost->count update and the halving loop against concurrent reclaimers in the same memcg+node. NR_VMSCAN_WRITE is accounted at writeout(), so reclaim_stat.nr_pageout is no longer needed and is removed. memcg-v1's memory.stat anon_cost/file_cost is now sourced from cost[].count instead of the removed lruvec anon_cost/file_cost fields. The reported values only refresh when prepare_scan_control() runs and are bounded at ~lrusize/4 by the halving loop; the scan-balance signal they express is unchanged. Under pure MGLRU the scan-balance signal itself is not consumed (both prepare_scan_control() and get_scan_count() are short-circuited on the MGLRU paths, and MGLRU's own type/tier selection comes from read_ctrl_pos() on lrugen->{avg_refaulted,avg_total,refaulted,evicted}, not from anon_cost/file_cost). NR_VMSCAN_WRITE naturally covers writeout from either reclaim implementation. The preceding patch also bumps PGROTATE_{ANON,FILE} from evict_folios(), so rotation-driven reclaim work is accounted consistently across both implementations. Link: https://lore.kernel.org/20260727162550.2032-4-usama.arif@linux.dev Signed-off-by: Usama Arif Acked-by: Shakeel Butt Acked-by: Johannes Weiner Acked-by: Vlastimil Babka (SUSE) Cc: Axel Rasmussen Cc: Baoquan He Cc: Chris Li Cc: David Hildenbrand Cc: David Rientjes Cc: Kairui Song Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Nhat Pham Cc: Roman Gushchin Cc: Suren Baghdasaryan Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton commit 1b089def0fb8833ec4b331b61908f29d6b491ccb Author: Usama Arif Date: Mon Jul 27 09:23:24 2026 -0700 mm/vmscan: add pgrotate_anon and pgrotate_file vmstat counters Reclaim can spend substantial work on an LRU type without immediately reclaiming or demoting a corresponding amount of memory. Record this work in PGROTATE_ANON and PGROTATE_FILE. For classic LRU reclaim: - Inactive-list reclaim adds nr_scanned - nr_reclaimed to the corresponding anon/file counter when isolation succeeds. - Active-list reclaim adds referenced executable file folios that are retained on the active list to PGROTATE_FILE. Active anon reclaim does not contribute this component. For MGLRU, add the number of initially isolated pages that remain unreclaimed after both the initial and retry passes to the counter for the selected anon/file type. These counters are distinct from the existing pgrotated vm event. pgrotated records an actual move to the inactive-list tail, primarily after reclaim-marked writeback completes or failed invalidation leaves a folio for accelerated reclaim. PGROTATE_ANON and PGROTATE_FILE measure reclaim cost and do not imply that a folio moved to an LRU tail. A subsequent patch will consume these counters for anon/file scan balancing. Link: https://lore.kernel.org/20260727162550.2032-3-usama.arif@linux.dev Signed-off-by: Usama Arif Acked-by: Shakeel Butt Acked-by: Johannes Weiner Reviewed-by: Vlastimil Babka (SUSE) Cc: Axel Rasmussen Cc: Baoquan He Cc: Chris Li Cc: David Hildenbrand Cc: David Rientjes Cc: Kairui Song Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Nhat Pham Cc: Roman Gushchin Cc: Suren Baghdasaryan Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton commit a69797fb36452865252f10c8ac9ef6781d07e3d7 Author: Usama Arif Date: Mon Jul 27 09:23:23 2026 -0700 mm/vmstat, mm/memcontrol: add _monotonic vmstat readers Patch series "mm/vmscan: reduce lru_lock contention via vmstat-derived scan-balance cost", v5. The anon/file scan balance heuristic in get_scan_count() is fed by two scalars in struct lruvec (anon_cost, file_cost) that every reclaim producer updates under lruvec->lru_lock. The cost-recording work itself is trivial, but it both contends for and contributes to contention on lru_lock - which is often a contention point on memory-pressured workloads. Specifically: - shrink_inactive_list() re-acquires lru_lock at function exit just to call lru_note_cost_unlock_irq(). - shrink_active_list() does the same after rotation accounting. - workingset_refault() takes folio_lruvec_lock_irq() purely to record the refault cost. - prepare_scan_control() snapshots anon_cost/file_cost under lru_lock. - lru_note_cost_unlock_irq() itself walks parent_lruvec() and re-acquires lru_lock on every ancestor, multiplying the cost of every update by memcg-hierarchy depth. This series removes those producer-side acquisitions entirely. The rotation inputs become per-LRU PGROTATE_{ANON,FILE} vmstat counters. NR_VMSCAN_WRITE already captures reclaim-driven pageout at writeout(); charge it through lruvec_stat_mod_folio() so it is available per lruvec and aggregated through the memcg hierarchy. Reclaim does not submit filesystem folios for writeback from this path, so pageout contributes only to anon cost. WORKINGSET_RESTORE_* already captures the refault input. PGROTATE_* are also useful independently of scan balancing. They are cumulative base-page events, not unique-page counts. Classic inactive reclaim records scan work that does not produce immediate reclaim or demotion, while active reclaim records referenced executable file folios retained on the active list. MGLRU records initially isolated pages that remain unreclaimed after its retry passes. Read alongside pgscan_* and pgsteal_*, their deltas identify which LRU type is consuming reclaim CPU without producing immediate yield. Unlike the existing pgrotated event, they do not imply a move to the inactive-list tail. prepare_scan_control() reads the raw cost signals without lru_lock: anon = PGROTATE_ANON + (NR_VMSCAN_WRITE + WORKINGSET_RESTORE_ANON) * SWAP_CLUSTER_MAX file = PGROTATE_FILE + WORKINGSET_RESTORE_FILE * SWAP_CLUSTER_MAX It folds the deltas into a per-lruvec accumulator. A dedicated per-lruvec cost_lock, not touched by isolate_lru_folios(), move_folios_to_lru(), or folio_add_lru(), serialises the accumulator RMW and the lrusize/4 halving check. Hierarchy aggregation is implicit in rstat propagation, so the parent_lruvec() walk and the lru_reparent_memcg() cost-splice both disappear. Moving accumulation and decay to the reclaim side also improves the cost model across reclaim gaps. With producer-side decay, events that happen while reclaim is idle still age each other before reclaim ever samples the costs. If a workload refaults a large anon set and then a smaller file set before reclaim runs again, the later file activity can age the earlier anon activity out of the cost model. The new scheme observes the whole between-reclaim delta and decays anon and file proportionally, so the scan-balance history better represents what happened since the last reclaim pass. Trade-offs: - Cost reads see rstat-aggregated values that can lag until periodic / reader-triggered flushing. - Per-lruvec footprint grows by 4 unsigned longs + a spinlock (a struct lru_cost { count, last_rotated, last_io } per side), which is a small cost. - NR_VMSCAN_WRITE now also updates the folio's lruvec/memcg stat, adding memcg stat accounting to the reclaim writeout path while preserving the existing node-level total. == Numbers == Tested on a 176-core, 256 GB host. The benchmark drives sustained swap-out/refault inside a tight memcg using vm-scalability/usemem: usemem -n 16 --prealloc --prefault --random $((256*1024*1024)) run inside a two-level memcg with memory.max=512M on the leaf (4 GB anon working set has to fit in 512 MB -> continuous shrink_inactive_list + workingset_refault). A 16 GB swap file is used. Measurement is a 30 s `perf lock record -a` window over otherwise-idle hardware. Workload rates are identical on both kernels (the bench drives the same memory pressure): baseline patched delta pgscan_direct / s 172,662 171,817 ~0% pgsteal_direct / s 67,162 66,306 ~0% workingset_refault_anon / s 40,696 39,830 ~0% perf lock contention (total wait per 30 s window): Lock Name Before After % change shrink_lruvec+0x770 722.84 ms 0 -100% (eliminated) (= lru_note_cost_unlock_irq) workingset_refault+0x167 385.26 ms 0 -100% (eliminated) (= lru_note_cost_refault) shrink_node+0x4ad 689.43 ms 26.95 ms -96% shrink_active_list 208.34 ms 15.97 ms -92% lru_add_drain_cpu+0x34 1.96 s 917.71 ms -53% Total LRU lock wait ~4.23 s ~1.66 s -61% The two specific contention sites the patch removes (shrink_lruvec+0x770 = lru_note_cost_unlock_irq; workingset_refault+0x167 = lru_note_cost_refault) are completely absent from the patched perf-lock-contention output. Secondary reductions in shrink_node, shrink_active_list, lru_add_drain_cpu and pgrefill/pgactivate look like knock-on effects from removing the cost-recording overhead and the parent_lruvec walk. The remaining ~1.66 s of LRU lock wait on the patched kernel is dominated by the per-CPU pagevec drain (lru_add_drain_cpu) and the main reclaim path in shrink_lruvec. The numbers above can be reproduced using the script in [1]. This patch (of 3): lruvec_page_state(), node_page_state(), and global_node_page_state() all clamp negative reads to zero on CONFIG_SMP so that a transient per-CPU delta skew presents as zero pages rather than as a garbage unsigned value. This is the right behaviour for non-monotonic page-count readers. It is however incorrect for callers that snapshot a monotonically- incremented event counter and compute a delta from two samples. Once the underlying signed long wraps past LONG_MAX, the clamped read drops to zero while the previously-recorded snapshot still holds the pre-wrap value; the unsigned subtraction then underflows into a ~2^31 spurious delta for 32-bit architecture and corrupts the caller's accumulator. Add non-clamping siblings that return the underlying state value cast to unsigned long: global_node_page_state_monotonic() node_page_state_monotonic() lruvec_page_state_monotonic() With both samples read via the _monotonic variant, unsigned modular subtraction stays correct across a signed-long wraparound as long as the true growth between two samples fits in unsigned long (< 2^32 on 32-bit, < 2^64 on 64-bit); the 32-bit bound is the practically-reachable one that motivates this helper. The variants are only safe for monotonically-incremented counters. Non-monotonic page-count readers must keep using the existing clamped helpers so transient negative reads still present as zero. This is a prerequisite for a later patch which replaces the producer-side anon_cost/file_cost accumulators with a read-side accumulator in prepare_scan_control() that samples monotonic per-LRU vmstat counters (PGROTATE_*, NR_VMSCAN_WRITE, WORKINGSET_RESTORE_*) via lruvec_page_state_monotonic() and folds their unsigned modular deltas into lruvec->cost[].count. Link: https://lore.kernel.org/20260727162550.2032-1-usama.arif@linux.dev Link: https://lore.kernel.org/20260727162550.2032-2-usama.arif@linux.dev Link: https://gist.github.com/uarif1/a4eb33a86c5b2d7bbc55b42f0956e884 [1] Signed-off-by: Usama Arif Acked-by: Johannes Weiner Acked-by: Shakeel Butt Acked-by: Vlastimil Babka (SUSE) Cc: Axel Rasmussen Cc: Baoquan He Cc: Chris Li Cc: David Hildenbrand Cc: David Rientjes Cc: Kairui Song Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Nhat Pham Cc: Roman Gushchin Cc: Suren Baghdasaryan Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton commit 8a905195850d383c0465ab5bdd3c91d94269b242 Author: Ridong Chen Date: Thu Jul 23 11:24:34 2026 +0800 mm: vmscan: fix node reclaim ignoring swappiness parameter sc_swappiness() had two separate definitions depending on CONFIG_MEMCG. The !CONFIG_MEMCG variant simply returned vm_swappiness, ignoring the proactive_swappiness value passed through scan_control. This caused the swappiness parameter written to /sys/devices/system/node/nodeX/reclaim to have no effect when CONFIG_MEMCG is disabled. Fix this by consolidating sc_swappiness() into a single definition that checks sc->proactive_swappiness first, then falls back to mem_cgroup_swappiness() which already handles both CONFIG_MEMCG and !CONFIG_MEMCG. Before fix (swappiness=max ignored, mostly file pages reclaimed): # cat /proc/sys/vm/swappiness 60 # cat /proc/vmstat | grep pgsteal pgsteal_kswapd 0 pgsteal_direct 0 pgsteal_khugepaged 0 pgsteal_proactive 1840 pgsteal_anon 25 pgsteal_file 1815 # echo "64M swappiness=max" > /sys/devices/system/node/node0/reclaim # cat /proc/vmstat | grep pgsteal pgsteal_kswapd 0 pgsteal_direct 0 pgsteal_khugepaged 0 pgsteal_proactive 18013 pgsteal_anon 337 pgsteal_file 17676 After fix (swappiness=max honored, anon pages reclaimed as expected): # cat /proc/vmstat | grep pgsteal pgsteal_kswapd 0 pgsteal_direct 0 pgsteal_khugepaged 0 pgsteal_proactive 0 pgsteal_anon 0 pgsteal_file 0 # echo "64M swappiness=max" > /sys/devices/system/node/node0/reclaim # cat /proc/vmstat | grep pgsteal pgsteal_kswapd 0 pgsteal_direct 0 pgsteal_khugepaged 0 pgsteal_proactive 16283 pgsteal_anon 16283 pgsteal_file 0 Link: https://lore.kernel.org/20260723032434.2016749-3-ridong.chen@linux.dev Fixes: b980077899ea ("mm: introduce per-node proactive reclaim interface") Signed-off-by: Ridong Chen Acked-by: Johannes Weiner Reviewed-by: Barry Song Acked-by: Qi Zheng Tested-by: Song Hu Reviewed-by: Song Hu Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: Baoquan He Cc: Chris Li Cc: David Hildenbrand Cc: Davidlohr Bueso Cc: Kairui Song Cc: Kemeng Shi Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Nhat Pham Cc: Roman Gushchin Cc: Wei Xu Cc: Yuanchu Xie Cc: [6.17+] Signed-off-by: Andrew Morton commit 1b7c8fe294a6bf913832e998f519029cad47dbcb Author: Ridong Chen Date: Thu Jul 23 11:24:33 2026 +0800 memcg: move mem_cgroup_swappiness and vm_swappiness to mm/swap.h Patch series "mm: vmscan: fix node reclaim ignoring swappiness parameter", v4. The per-node proactive reclaim interface (/sys/devices/system/node/nodeX/reclaim) accepts a swappiness parameter, but it is silently ignored when CONFIG_MEMCG is disabled. The root cause is that sc_swappiness() has separate implementations for CONFIG_MEMCG and !CONFIG_MEMCG, and the latter never checks proactive_swappiness. Patch 1 moves mem_cgroup_swappiness() and vm_swappiness out of the public include/linux/swap.h into the mm-private mm/swap.h, and makes the helper handle both CONFIG_MEMCG and !CONFIG_MEMCG in a single inline function. This is a prerequisite for unifying sc_swappiness(). Patch 2 consolidates sc_swappiness() into a single definition that works regardless of CONFIG_MEMCG, fixing the node reclaim swappiness bug. This patch (of 2): The per-memcg swappiness knob is v1-only; v2 always uses global vm_swappiness and ignores the per-cgroup field. Both mem_cgroup_swappiness() and vm_swappiness are only used within mm/ (memcontrol.c, memcontrol-v1.c, vmscan.c), so move them out of the public include/linux/swap.h into the mm-private mm/swap.h. This keeps unrelated declarations out of include/linux/swap.h. Guard memcg->swappiness with CONFIG_MEMCG_V1 as well, so v2-only kernels drop the unused field. No functional change for v1; v2-only kernels drop the unused field. Link: https://lore.kernel.org/20260723032434.2016749-1-ridong.chen@linux.dev Link: https://lore.kernel.org/20260723032434.2016749-2-ridong.chen@linux.dev Signed-off-by: Ridong Chen Acked-by: Johannes Weiner Reviewed-by: Barry Song Reviewed-by: Song Hu Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: Baoquan He Cc: Chris Li Cc: David Hildenbrand Cc: Davidlohr Bueso Cc: Kairui Song Cc: Kemeng Shi Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Nhat Pham Cc: Roman Gushchin Cc: Wei Xu Cc: Yuanchu Xie Cc: Qi Zheng Signed-off-by: Andrew Morton commit 0ee06ee38aed1a9949510624a1b4abdc7e39815a Author: Baolin Wang Date: Mon Jul 20 19:12:02 2026 +0800 mm: mglru: promote mapped executable folios after first usage Classical LRU protects mapped executable file folios through commit 8cab4754d24a0 ("vmscan: make mapped executable pages the first class citizen") and commit c909e99364c8 ("vmscan: activate executable pages after first usage"), giving executable code a better chance to stay in memory, avoiding IO thrashing and improving workload performance. However, MGLRU's protection of mapped executable file folios is less reliable. Although shrink_folio_list() checks references, the access flag of mapped executable file folios may have already been checked and cleared by lru_gen_look_around() or walk_mm(). Additionally, folio_update_gen() or lru_gen_set_refs() only sets the 'PG_referenced' flag for mapped executable file folios, which causes shrink_folio_list() to ignore the first usage of these mapped executable file folios and reclaim them easily. Follow the classical LRU's logic, promoting mapped executable file folios after their first usage in folio_update_gen() and lru_gen_set_refs(), giving executable code a better chance to stay in memory. On my 32-core Arm machine, with the memcg limit set to 2G, running 'make -j32' to build kernel showed some improvement in sys time. base patched 9248.543s 7861.579s Link: https://lore.kernel.org/f57d94b1d85bb3d620d89bb739128f0d929bf9c6.1784509721.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang Acked-by: Johannes Weiner Reviewed-by: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Harry Yoo Cc: Jann Horn Cc: Kairui Song Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Rik van Riel Cc: Shakeel Butt Cc: Vlastimil Babka Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton commit b64727d264782a5441aa625eba60b3c53fd2842e Author: Baolin Wang Date: Mon Jul 20 19:12:01 2026 +0800 mm: vmscan: add a helper to identify file-backed executable folios Add a helper to identify file-backed executable folios to avoid duplicate code. No functional changes. Link: https://lore.kernel.org/2ee74f9f98ac45a2f0db0ceb018e086bdb671d17.1784509721.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang Acked-by: Johannes Weiner Reviewed-by: Axel Rasmussen Reviewed-by: David Hildenbrand (Arm) Reviewed-by: Kairui Song Reviewed-by: Barry Song Cc: Harry Yoo Cc: Jann Horn Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Rik van Riel Cc: Shakeel Butt Cc: Vlastimil Babka Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton commit 3bf07ce8058bcab03ea1cb9cd11ec1d6b2ee5af0 Author: Baolin Wang Date: Mon Jul 20 19:12:00 2026 +0800 mm: vmscan: convert folio_referenced() to use vma_flags_t Patch series "promote mapped executable folios after first usage for MGLRU", v4. Now MGLRU's protection of mapped executable file folios is less reliable. Follow the classical LRU's logic, promoting mapped executable file folios after their first usage to give executable code a better chance to stay in memory and improve workload performance (See patch 2 for more details). This patch (of 3): Replace use of the legacy vm_flags_t flags with vma_flags_t values for folio_referenced() and related logic. This is also a preparation for the following changes. No functional changes. Link: https://lore.kernel.org/cover.1784509721.git.baolin.wang@linux.alibaba.com Link: https://lore.kernel.org/2bd39e16ec19e3e3c4716aa9a1a25775c26cac57.1784509721.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang Acked-by: David Hildenbrand (Arm) Acked-by: Johannes Weiner Reviewed-by: Barry Song Reviewed-by: Kairui Song Reviewed-by: Axel Rasmussen Cc: Harry Yoo Cc: Jann Horn Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Rik van Riel Cc: Shakeel Butt Cc: Vlastimil Babka Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton commit 3541a2b06ecd78ba333188df04368dcf97273d6a Author: Breno Leitao Date: Mon Jul 20 06:23:45 2026 -0700 mm/kmemleak: report RCU-tasks quiescent states during the scan kmemleak_scan() can run for ages on large debug kernels. It was causing some soft-lockups which I got fixed with commit 3175fcfec8b16baeb ("mm/kmemleak: avoid soft lockup when scanning task stacks") with our beloved cond_resched(). I've got the fix above deployed in the Meta fleet, and now I am seeing: INFO: rcu_tasks detected stalls on tasks: task:kmemleak state:R ... nvcsw: 274/274 holdout: 1 idle_cpu: -1/3 scan_block scan_gray_list kmemleak_scan and, worse, blocks the callers waiting on that grace period. Here a BPF struct_ops map free, which waits via synchronize_rcu_mult(call_rcu, call_rcu_tasks), is stuck long enough to also trip the hung task check: INFO: task kworker/...:bpf_map_free_deferred blocked for 122 seconds __wait_rcu_gp bpf_struct_ops_map_free Then I've learned that cond_resched() is not an RCU-tasks quiescent state, so, we need to use stronger primitives. Use cond_resched_tasks_rcu_qs() at the scan reschedule points so the scan reports an RCU-tasks quiescent state as it proceeds. Inspired by commit b96285e10aad ("tracing: Have osnoise_main() add a quiescent state for task rcu"). Link: https://lore.kernel.org/20260720-kmemleak_rcu_task-v1-1-5b460ade777d@debian.org Fixes: c4b28963fd79 ("mm/kmemleak: rely on rcu for task stack scanning") Signed-off-by: Breno Leitao Reviewed-by: Paul E. McKenney Reviewed-by: SJ Park Reviewed-by: Catalin Marinas Cc: Breno Leitao Cc: Puranjay Mohan Cc: Signed-off-by: Andrew Morton commit fb580e196497738d98dbad5b8459913435b376e7 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:33 2026 +0100 tools/testing/selftests/mm: test anonymous page offset merge behaviour While maintaining anonymous page offsets for VMAs has no impact for most merge cases, it does impact MAP_PRIVATE-mapped file-backed mappings which happen to have matching page offset but not matching anonymous page offset. Assert this behaviour by attempting to map an unfaulted MAP_PRIVATE-memfd region with a faulted one with compatible file page offsets but incompatible anonymous page offsets. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-16-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 6b7460ad1af8b10cc6b629649979d9d0d844046e Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:32 2026 +0100 tools/testing/vma: expand VMA merge tests to assert anon pgoff Now we have introduced the VMA anonymous page offset attribute and update it when VMAs are manipulated, update VMA merge tests to assert that the anonymous page offset is as expected. Also update instances where we could use vma_start_pgoff() to do so. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-15-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 93c0c8dc87f6eb9f6ce71c4ac379bef88965192c Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:31 2026 +0100 mm/rmap: use anon pgoff to track MAP_PRIVATE file-backed anon folios Currently anonymous folios belonging to CoW'd MAP_PRIVATE file-backed mappings are indexed by their page offset within the file in which they were originally mapped. This differs from anonymous folios belonging to pure anon mappings which are indexed by their anonymous page offset (the address at which they'd belong in the VMA when first faulted). This change fixes this inconsistency, always indexing anonymous folios by their anonymous page offset regardless of the VMA to which they belong. The foundations have been laid such that we need only switch this functionality on such by: * Using linear_anon_page_index() in __folio_set_anon() to assign the folio's index to the anonymous linear index rather than the file-backed one. * Otherwise using linear_anon_page_index() in all instances where anonymous folios are being referenced or manipulated. * Replacing vma_address() with vma_filebacked_address() or vma_anon_address() as appropriate. * Updating the merging logic to check that anonymous page offsets are aligned as well as filebacked ones for MAP_PRIVATE file-backed VMAs, introducing needs_adjacent_anon_pgoff() to figure out when this is required. * Updating linear_folio_page_index() to invoke linear_anon_page_index() if the folio is anonymous. * Updating vma_address_end() to use the VMA's anonymous page offset when pvmw->pgoff is anonymous. * Correcting folio_within_range() to use anonymous page offset for anonymous folios. This will have no impact on merging of anonymous VMAs, whose page offset and anonymous page offset are identical, nor will it impact shared file-backed VMAs, which will continue to be merged based on the file-backed page offset. However, MAP_PRIVATE file-backed mappings must now be aligned on anonymous page offset as well. In most instances this should have no impact on merging of file-backed mappings, which are usually not merged all that often, let alone MAP_PRIVATE mapped ones, and rarely remapped and faulted before being moved back in place (the case in which a merge may now fail). One subtle impact of this change is in NUMA interleaving - since commit 88c91dc58582 ("mempolicy: migration attempt to match interleave nodes"), migration heuristically tries to maintain interleaving behaviour matching the policy using folio indices. When doing migration of CoW'd MAP_PRIVATE-file backed ranges, the 'base' upon which the interleaving behaviour is performed will vary for these ranges. However the commit notes that ranges spanning multiple VMAs will already cause varying bases, and that this is an acceptable approximation. It is very unlikely real world use-cases will be impacted by this (MAP_PRIVATE file-backed mappings are already an edge case), and all that will happen is that such ranges will cause interleaving to be rotated over the CoW'd range, with little to no impact. This commit lays the foundations for future scalable CoW work which needs to track some remaps, meaning that most remap tracking can be avoided, and in nearly all cases the anonymous page offset will be able to be used to quickly find the VMA in an mm. Note that the need_rmap_locks check doesn't need to be updated, as any remapping will offset both the anonymous and file-backed page offset, so it suffices to check only one. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-14-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 5f653f8b7a3469524b1dd9fbd4b803baa34f14a7 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:30 2026 +0100 mm/migrate: calculate large folio page index using PFN Rather than having to figure out the page index to use using linear_page_index(), calculate it using PFN. This is a more natural fit as the linear page index is immaterial to determining the folio page index. Derive the page index from the offset between migration entry PFN and folio PFN - pvmw.pfn (set via DEFINE_FOLIO_VMA_WALK() which uses folio_pfn() to obtain it). Additionally remove a not so useful comment and clean the code layout up. No functional change intended. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-13-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Suggested-by: David Hildenbrand (Arm) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 8e658ecc3be21e43573e6639af2d1c536bbfe67d Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:29 2026 +0100 mm/huge_memory: update remove_migration_pmd() to accept a folio This function does not need to accept a page and requiring it to is unnecessary and misleading. make_[writable, readable]_device_private_entry() must be passed a PMD-aligned PFN as they immediately used to obtain a softleaf PMD entry and the same argument applies to folio_add_[anon, file]_rmap_pmd(). While we are here, update a VM_BUG_ON() to a VM_WARN_ON_ONCE(). No functional change intended. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-12-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit e7006fbd608f490f1a687df9d724de4454f8e164 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:28 2026 +0100 mm: clean up vma_address_end() vma_address_end() is a confusing function with a lot of moving parts so clean it up prior to extending it for anon page indexed mappings. Const-ify some variables and establish pgoff_vma_start and pgoff_end variables to clearly identify the page offset for the start of the VMA and the end of the page offset range specified by the page walk. This simplifies the function significantly and lays the groundwork for a future change to update this function to account for anonymously page indexed folios. No functional change intended. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-11-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 50c5f35a64aad82e3fd22e26f2b9c9c7395fa206 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:27 2026 +0100 mm/rmap: track whether the page VMA mapped pgoff is anonymous Update the page_vma_mapped_walk structure to track whether the pgoff being tracked is an anonymous pgoff or not and update the comments to reflect this. This is necessary in order to determine the correct VMA page offset in vma_address_end() when pvmw->nr_pages > 1. Also document that pvmw->pgoff is meaningless for pvmw->nr_pages == 1 and for KSM. Do not set this field where pgoff is not specified. This is laying the groundwork for eventually using anonymous page offsets as the index for all anonymous folios. No functional change intended. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-10-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 6a993c7fbc3e99431e148eb261c9b2e38525fce4 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:26 2026 +0100 mm: propagate VMA anonymous page offset on map, remap, split + merge We must correctly update VMA anonymous page offset state on all VMA operations that would result in it changing, with special attention given to remapping. We cover most cases by simply updating vma_set_range() to do so (with a new anonymous page offset parameter), but also notably must update the merging and mapping logic to propagate this parameter correctly. The remap logic remains the same - we may update the anonymous page offset if the VMA is unfaulted, but now this applies to MAP_PRIVATE file-backed mappings too, so we update the code to reflect this. Note that we use __linear_anon_page_index() upon remap as the VMA may be shared, in order that we update the field consistently regardless of VMA type. Similarly, pass through anon page offset to the merge logic, updating the vma_merge_struct struct to propagate it, and also use __linear_anon_page_index() to obtain the anonymous page index so it can be safely used for both shared and MAP_PRIVATE file-backed mappings. In copy_vma(), the anonymous page offset is updated regardless of whether the mapping is a CoW mapping or not. This is both to keep the anonymous page offset consistent even for non-CoW mappings (it is set so should at least remain correct) and makes the logic cleaner. A self-merge however remains permitted only for mappings which can have a populated vma->anon_vma and do not require alignment on a separate file offset - that is pure anonymous VMAs, so only set can_self_merge if vma_is_anonymous(). Finally, we update insert_vm_struct() to correctly set the anonymous page offset on insertion of a VMA. We simply ensure state is correctly propagated here, so no functional changes are intended. Also update VMA userland tests to reflect this change. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-9-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 746b9e0a4777e8e883d70b4292a6c3d8c435712c Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:25 2026 +0100 tools/testing/vma: add tests for copy_vma() self-merge Assert that a VMA can be moved backwards, forwards and between a preceding VMA and its old self. In the cases in which the VMA merges only with itself expect that to be achieved by expanding its old self, so assert that these function correctly. However in the case of a merge between a preceding VMA and itself the original VMA is removed, so assert that the preceding VMA replaces the one passed in as vmap and the merge is as expected. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-8-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 9998bc06d75bfbb17b8ff7f83183d133923c5829 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:24 2026 +0100 mm/vma: fix self-merge check in copy_vma() The existing logic is very confusing so improve things. Firstly rename the confusing faulted_in_anon_vma variable to can_self_merge and update this when the page offset is updated. What is being checked for is a 'self-merge' - that is between the VMA being remapped and its prior VMA (remember that this is copy_vma() - if a non-MREMAP_DONTUNMAP remap the original VMA is only removed afterwards). This can happen if the VMA is moved immediately adjacent to itself, either before or after it: |----------------|----------------| | | | v | v |...............||---------------||...............| | new || old || new | |...............||---------------||---------------| In these cases the old VMA is simply expanded to cover the new range. It is also possible for the move to both self-merge and merge with a prior VMA if it is placed between a preceding VMA and its old self: |---------------| | | v | |---------------||...............||---------------| | prev || new || old | |---------------||...............||---------------| In this case, the old VMA is removed and 'prev' is expanded and replaces it. Since copy_vma_and_data() which calls copy_vma() intends to reference the old VMA after the merge, it must have this pointer updated. This kind of self-merge is not possible with a succeeding merge, as the merge always prefers to expand the preceding VMA if possible. copy_vma() accounts for this by explicitly checking to see if a self-merge occurred and updating the vmap pointer if so. However it incorrect did so even for a subsequent merge (this is simply a noop so it had no impact). So change this to only check for the case which matters - a backwards merge - and rearrange the parameters to make it clearer we're doing that - i.e. check new_vma->vm_start < old_vma_start (having already renamed vma_start to old_vma_start to make it clear this is the previous VMA). Also update the existing wall-of-text comment to be a lot clearer. While we're here, replace the VM_BUG_ON_VMA() with a VM_WARN_ON_ONCE_VMA() and update the VMA userland tests accordingly. No functional change intended. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-7-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit dba10745e9b4dcf2d8b6a0c44a23eec4f58365f0 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:23 2026 +0100 mm: introduce and use vma_filebacked_address() In cases where we know that the VMA is file-backed, use vma_filebacked_address() rather than vma_address(). This lays the foundation for using the anonymous page offset via vma_anon_address(). Also add an assert to ensure that the VMA whose address is required is not anonymous. No functional change intended. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-6-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Tested-by: syzbot@syzkaller.appspotmail.com Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 2a8de2d1d6a5f10251e89c77b547fd3243c8c3a8 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:22 2026 +0100 mm: update print_bad_page_map() to show anon index if appropriate If the VMA is a CoW mapping page offset may differ from anon page offset, indicating different positions in the relevant rmap trees. Update print_bad_page_map() to reflect that - if the mapping is non-CoW or the indexes match, then output only one index as before, otherwise output both with (file) or (anon) suffixes to reflect which is which. It's not possible to give only one index as there is no folio available to perform folio_test_anon() upon (the page table entry is bad so this is unavailable). This is potentially useful debugging information and matches the existing page offset provided. Use the raw __linear_anon_page_index() function so as to always output this value regardless of whether the mapping is file-backed or not and to avoid asserts that shouldn't apply here. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-5-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Reviewed-by: Gregory Price (Meta) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit c02fe674feaf3529b4d8c808c363aa1bcf955979 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:21 2026 +0100 mm: abstract vma_address() and introduce vma_anon_address() Introduce __vma_address() which abstracts the VMA start page offset field as pgoff_start, then update vma_address() to use it. Then introduce vma_anon_address() which does the equivalent of vma_address(), only using the anonymous page offset of the VMA rather than the file-backed one. Also add an assert to ensure that the function is not called for mappings which are file-backed but not MAP_PRIVATE to ensure it is only used in the correct places. This will be necessary for determining the address of a folio's index within a VMA when the folio belongs to a MAP_PRIVATE file-backed VMA but has been CoW'd, and thus is anonymous, once the anonymous VMA page offset field is used for the reverse mapping. No callers are updated, so no functional change intended. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-4-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 7e6543d1f939eaaca008c13395e52cbd07605cb0 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:20 2026 +0100 mm: introduce linear_anon_page_index() This function provides the anonymous equivalent of linear_page_index(), instead offsetting based on the anonymous page offset of the VMA. It is valid only for anonymous or MAP_PRIVATE file-backed mappings, in other words CoW mappings. For pure anon VMAs, this will be equal to linear_page_index(). Assert that both of these invariants are true in linear_anon_page_index() and implement the algorithm in __linear_anon_page_index(). Note that MAP_PRIVATE-/dev/zero mappings will satisfy vma_is_anonymous() but not fulfill this invariant, so when asserting this we check vma->vm_file to account for this. We do not update callsites yet, so no functional change intended. Also const-ify vma_is_anonymous() to make it compatible with the const-ified linear_anon_page_index(). While we're here, update linear_page_index() to be more succinct. VMA userland tests are also updated accordingly. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-3-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Gregory Price (Meta) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 51943a18ad4bd6ff8baea2da7b8cce2f86f1a959 Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:19 2026 +0100 mm: provide vma_[flags_]is_cow_mapping() and remove is_cow_mapping() All remaining callers of is_cow_mapping() are invoking it in the form of is_cow_mapping(vma->vm_flags) or an indirected version of this. Therefore, provide a helper - vma_is_cow_mapping() to directly test the VMA. Additionally provide a new helper vma_flags_is_cow_mapping() which performs the check using the new vma_flags_t type, and share this logic between vma_is_cow_mapping() and vma_desc_is_cow_mapping(). With these changes, no callers of is_cow_mapping() remain, so remove it. Also update the userland VMA tests to reflect the change. No functional change intended. [akpm@linux-foundation.org: fix kerneldoc comment typo, per Lorenzo] Link: https://lore.kernel.org/aob1goSSPH6sTN9y@gremlin Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-2-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Gregory Price (Meta) Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 0bd14001eb264247d565a5a44a71675df273640d Author: Lorenzo Stoakes (ARM) Date: Thu Aug 13 18:32:18 2026 +0100 mm/vma: introduce VMA anon page offset field and add helpers Patch series "mm/rmap: index MAP_PRIVATE file-backed folios by anonymous pgoff", v5. In memory management we've managed to manufacture a great deal of confusion around the concept of anonymous memory. We have: 1. 'Pure anon' memory - anonymous VMAs whose folios are anonymous and swap-backed (thus for reclaim purposes, treated as anonymous). These are simple enough. 2. shmem - file-backed VMAs, file-backed folios (from rmap perspective) so present in the page cache and mapped by an address_space object, but whose folios are also swap-backed (thus treated as anonymous for reclaim purposes). 3. MAP_PRIVATE-mapped /dev/zero - a strange beast whose VMAs have vma->vm_file set, but which clears vma->vm_ops to satisfy vma_is_anonymous(), resulting in VMAs that were mmap()'d referencing a file, but are in every other sense anonymous, including the folios. 4. Other MAP_PRIVATE-file backed mappings - These possess file-backed VMAs and have file-backed folios until CoW'd, at which point those CoW'd folios are anonymous. This series fixes issue 3. In order for us to traverse VMAs using the reverse mapping, we require two fields - folio->mapping and folio->index. The first tells the rmap code where to look for VMAs, and the second tells it at which offset the folio starts within the referenced object. For anonymous folios, folio->mapping points at an anon_vma object. For file-backed folios, it points at an address_space. And: * For file-backed folios folio->index is simply the page offset of the start of the folio within the file. * For anonymous folios belonging to pure anon mappings, folio->index is equal to the anonymous page offset of the folio. * For anonymous folios belonging to file-backed mappings (i.e. CoW'd folios of a MAP_PRIVATE file-backed mapping), folio->index is equal to the file page offset. This series establishes a new anonymous page offset property of VMAs to allow us to map anonymous folios at their anonymous page offset, consistent with pure anon. The purpose of doing so is to lay the foundations for the scalable CoW work. This is necessary because scalable CoW looks in the maple tree for the VMA located at folio->index << PAGE_SHIFT, before falling back to looking up tracked remaps if necessary. The MAP_PRIVATE file-backed case means that folio indices will very often conflict with one another and this remap tracking becomes substantially more contended, and of course the fast path can never be used. This also makes it possible, in future, to unshare anonymously mapped folios with deep fork hierarchies on remap, eliminating the need for remap tracking in the vast majority of cases. Similar to page offset of pure anonymous VMAs, we update the anonymous page offset of unfaulted file-backed VMAs on remap, but do not once CoW'd (i.e. vma->anon_vma is non-NULL). Overall, there is little impact on mergeability, which remains exactly the same for pure anonymous and shared file-backed mappings, with the only impact being on MAP_PRIVATE-mapped file-backed mappings, which must now match on anonymous page offset as well as file page offset to be merged. To fail to merge like this would require CoW'ing the mapping, then finding another VMA with identical file and compatible page offset to remap next to. This is therefore very much an edge case that should have very little impact (and which scalable CoW may very well address in any case). This patch (of 16): Establish fields in vm_area_struct to store the anonymous page offset of VMAs. Initially, the anonymous page offset of a VMA is vma->vm_start >> PAGE_SHIFT. When a VMA is remapped to new_address its anonymous page offset is either updated to new_address >> PAGE_SHIFT if unfaulted or, if faulted, remains equal to the anonymous page offset it had when first faulted. Currently, anonymous folios belonging to CoW'd MAP_PRIVATE-mapped file-backed VMAs are tracked by their file offsets. By adding anonymous offset as a property of VMAs, we can now track them by their anonymous page offset instead. By tracking this, we provide the means by which to eliminate this inconsistency, and more importantly lay the foundations for future work for the scalable CoW anonymous rmap rework. This patch simply adds the fields and some simple helpers. Subsequent patches will update mm code to make use of these fields correctly. The fields chosen are packed in the VMA such that, for 64-bit kernel builds, no additional space is taken up. The first field is present on cacheline 0 containing key VMA fields, and the second on cacheline 3, which contains file-backed reverse mapping fields. Given the relative time spent accessing reverse mapping fields as well as updating them, there shouldn't be any performance impact here from false sharing. Update the VMA userland tests to account for this change. No callsites are updated yet, so no functional change intended. Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-0-c21581c0c3c8@kernel.org Link: https://lore.kernel.org/20260813-b4-scalable-cow-virt-pgoff-v5-1-c21581c0c3c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Reviewed-by: Gregory Price (Meta) Reviewed-by: Xu Xin Cc: Adrian Hunter Cc: Alexander Deucher Cc: Alexander Gordeev Cc: Alexander Shishkin Cc: Alistair Popple Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Boris Brezillon Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christan König Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: Dave Airlie Cc: Dev Jain Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Harry Yoo Cc: Heiko Carstens Cc: Huang Ray Cc: "Huang, Ying" Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Jiri Olsa Cc: John Hubbard Cc: Joshua Hahn Cc: Kairui Song Cc: Kees Cook Cc: Kemeng Shi Cc: Lance Yang Cc: Liam R. Howlett Cc: Liviu Dudau Cc: Maarten Lankhorst Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Matthew Auld Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Maxime Ripard Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Namhyung kim Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oleg Nesterov Cc: Oscar Salvador Cc: Pedro Falcato Cc: Peter Xu Cc: Peter Zijlstra Cc: Rakie Kim Cc: Rik van Riel Cc: Rodrigo Vivi Cc: Ryan Roberts Cc: Steven Price Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Thomas Hellström Cc: Thomas Zimemrmann Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: xu xin Cc: Zi Yan Signed-off-by: Andrew Morton commit 0b4268ac77fa6e2c05fc8b90441b0832b211385d Author: Kaitao Cheng Date: Sun Jul 12 17:33:26 2026 +0800 mm/kconfig: drop redundant dependency wrappers Some mm Kconfig entries repeat dependencies that are already expressed by their surrounding blocks or menus. The zsmalloc allocator options menu already depends on ZSMALLOC, so the outer if ZSMALLOC block does not add any extra constraint. MEMORY_HOTREMOVE and MHP_MEMMAP_ON_MEMORY are both inside the if MEMORY_HOTPLUG block, so their local depends on MEMORY_HOTPLUG entries are redundant. PTE_MARKER_UFFD_WP is the only entry under if USERFAULTFD. Move the USERFAULTFD dependency into the symbol itself and combine it with the architecture support dependency. This keeps the same visibility and defaults while avoiding duplicate dependency expressions. Link: https://lore.kernel.org/20260712093326.8313-1-kaitao.cheng@linux.dev Signed-off-by: Kaitao Cheng Suggested-by: Julian Braha Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 092836fedd82cdafc6e2085c4b7a7878bfa3ca1d Author: David Hildenbrand (Arm) Date: Thu Jul 9 10:13:34 2026 +0530 mm: standardize printing for pgtable entries Bad page map reporting currently stores page table entry values in an unsigned long long and prints them with fixed 64-bit-oriented format strings. This is inconsistent across call sites and does not work well for architectures where page table entry values are not naturally represented as 64-bit values, such as 32-bit or 128-bit entries. Introduce a common helper to convert raw page table entry values into a fixed-width hexadecimal string based on the actual entry size. Use it for bad page map reporting and for dumping the page table walk in __print_bad_page_map_pgtable(). Pass page table entry values to the reporting path as raw bytes together with their size, instead of forcing them through an unsigned long long. It keeps the printed output consistent and avoids truncation or misleading formatting for non-64-bit page table entries. Link: https://lore.kernel.org/20260709044334.1741263-1-anshuman.khandual@arm.com Signed-off-by: David Hildenbrand (Arm) Co-developed-by: Anshuman Khandual Signed-off-by: Anshuman Khandual Cc: Andriy Shevchenko Cc: David Hildenbrand Cc: Hugh Dickins Cc: Matthew Wilcox (Oracle) Cc: Ryan Roberts Signed-off-by: Andrew Morton commit 1eba458a54d073aa8bd62627ad0e9264ef0f51e3 Author: Kaitao Cheng Date: Tue Jul 7 17:03:31 2026 +0800 mm/kconfig: drop redundant memory hotplug dependencies MHP_MEMMAP_ON_MEMORY is defined inside the MEMORY_HOTPLUG block, and MEMORY_HOTPLUG already depends on SPARSEMEM_VMEMMAP. Keep the explicit MEMORY_HOTPLUG dependency for local readability, but drop the redundant SPARSEMEM_VMEMMAP dependency. ZONE_DEVICE depends on MEMORY_HOTREMOVE, which depends on MEMORY_HOTPLUG. MEMORY_HOTPLUG in turn depends on SPARSEMEM_VMEMMAP. Drop the direct MEMORY_HOTPLUG and SPARSEMEM_VMEMMAP dependencies from ZONE_DEVICE. This does not change the set of valid configurations. Link: https://lore.kernel.org/20260707090331.52971-1-kaitao.cheng@linux.dev Signed-off-by: Kaitao Cheng Acked-by: David Hildenbrand (Arm) Acked-by: Muchun Song Reviewed-by: Lorenzo Stoakes Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit 9b5e4809806cb300cc163b26fa70dfd36e3577b3 Author: Ethan Nelson-Moore Date: Wed Jun 10 15:09:04 2026 -0700 maple_tree: remove undocumented CONFIG_MAPLE_RCU_DISABLED macro consults the macro CONFIG_MAPLE_RCU_DISABLED to determine whether to disable the mt_in_rcu() function (by making it always return false). This macro is not reachable via Kconfig, despite its name, and is not documented anywhere. Remove it to avoid polluting the CONFIG_* namespace. Discovered while searching for CONFIG_* symbols referenced in code but not defined in any Kconfig file. Link: https://lore.kernel.org/20260610220905.99860-1-enelsonmoore@gmail.com Signed-off-by: Ethan Nelson-Moore Acked-by: SeongJae Park Reviewed-by: Liam Howlett Reviewed-by: Alice Ryhl Cc: Andrew Ballance Signed-off-by: Andrew Morton commit 644ad84870ab503f5619d21cf3d37efb134e82de Author: Hajime Tazaki Date: Thu Jul 2 10:25:46 2026 +0900 mm: nommu: point to the write iterator upon split_vma When a user invokes munmap(2) on a partial region allocated by mmap(), the kernel may split the original region if necessary and shrink it to the correct size. At the beginning of vmi_shrink_vma(), the unused part is cleared; however, an assertion is triggered if the shrink occurs after split_vma(). This commit fixes the issue by correctly configuring the pointer to the iterator at the end of split_vma(). This bug was detected using the Linux Test Project (LTP) test linked below, running on a nommu UML (User-Mode Linux) environment (via an out-of-tree extension to UML). Here is a minimal reproducible chunk of code for this issue: void *addr; size_t pagesize = getpagesize(); addr = mmap(NULL, pagesize * 4, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); munmap(addr + pagesize * 1, pagesize); This is the console output with CONFIG_DEBUG_MAPLE_TREE=y. nommu: WARN at __mas_set_range:791 (1) MAS: tree=0000000091c23b08 enode=0000000065057663 (ma_active) Store Type: node_store [9/9] index=70af8000 last=ffffffffffffffff min=0 max=ffffffffffffffff sheaf=0000000000000000, request 0 depth=0, flags=0 maple_tree(0000000091c23b08) flags 307, height 1 root 0000000083394c06 0-ffffffffffffffff: node 0000000010c90bd6 depth 0 type 1 parent 0000000050e1ddf8 contents: 0000000000000000 707A 7FFF 00000000eb0ac2b5 707AFFFF 0000000000000000 7093FFFF 0000000045ead616 7095FFFF 0000000000000000 7096CFFF 000 00000681c7151 7096FFFF 0000000000000000 70AF3FFF 000000006c78b9e9 70AF4FFF 000000001914ab0b 70AF7FFF 00000000000 00000 FFFFFFFFFFFFFFFF 0000000000000000 0 0000000000000000 0 0000000000000000 0 0000000000000000 0 0000000000000 000 0 00000000bca8be4f 0-707a7fff: 0000000000000000 707a8000-707affff: 00000000eb0ac2b5 707b0000-7093ffff: 0000000000000000 70940000-7095ffff: 0000000045ead616 70960000-7096cfff: 0000000000000000 7096d000-7096ffff: 00000000681c7151 70970000-70af3fff: 0000000000000000 70af4000-70af4fff: 000000006c78b9e9 70af5000-70af7fff: 000000001914ab0b 70af8000-ffffffffffffffff: 0000000000000000 nommu: Pass: 796 Run:797 Link: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/mseal/mseal02.c Link: https://lore.kernel.org/20260702012546.665383-1-thehajime@gmail.com Signed-off-by: Hajime Tazaki Cc: Jann Horn Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Pedro Falcato Cc: Vlastimil Babka Signed-off-by: Andrew Morton commit d230991493b521eeff39f32434fddcbcdb109eb0 Author: Johannes Weiner Date: Mon Jun 29 12:33:37 2026 -0400 mm: mempolicy: fix automatic numa balancing for shmem Neha reports that mapped shmem aren't considered for NUMA balancing, noting convergence problems and bandwidth bottlenecking for cachelib based workloads on tiered memory systems. Looking at the code and going through the git history, this doesn't actually seem intentional: Commit fc3147245d19 ("mm: numa: Limit NUMA scanning to migrate-on-fault VMAs") added a vma_policy_mof() gate to task_numa_work() so VMAs whose policy lacks MPOL_F_MOF are skipped from NUMA balancing scans. The motivation was a real usecase: Oracle was pinning shared segments with mbind(MPOL_BIND) so trapping faults was both expensive and pointless. The handling of NULL from vm_ops->get_policy, however, treated "user explicitly opted out" the same as "user never specified anything." For VMAs whose shared policy is absent - the common case for shmem - the scan was disabled too. This issue is old. It probably hurts less in conventional NUMA. But it's very noticeable on tiered systems, where entire tmpfs workingsets can get stuck on lower-bandwidth memory. Fix this by having vma_policy_mof() use __get_vma_policy() directly, and thereby handle the fallback to task policy (-> preferred_node_policy() has MPOL_F_MOF per default). Every other consumer of vm_ops->get_policy already handles it this way, the scan-eligibility check was the outlier. This preserves Mel's intended fix: don't scan stuff the user explicitly pinned. But allow default policy vmas to participate in balancing. Link: https://lore.kernel.org/20260629163337.1264881-1-hannes@cmpxchg.org Fixes: fc3147245d19 ("mm: numa: Limit NUMA scanning to migrate-on-fault VMAs") Signed-off-by: Johannes Weiner Reported-by: Neha Gholkar Tested-by: Neha Gholkar Reviewed-by: Gregory Price Acked-by: David Hildenbrand (Arm) Acked-by: Balbir Singh Cc: Alistair Popple Cc: Byungchul Park Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: Zi Yan Cc: Signed-off-by: Andrew Morton commit 4b47e81e5657ea0d9c157399b366776a042ac8d8 Merge: 08745c62350126 aedf2efd18977e Author: Andrew Morton Date: Mon Aug 24 18:40:27 2026 -0700 Merge branch 'mm-hotfixes-stable' into mm-stable to pick up already-upstream changes to memcontrol.c, needed by "memcg: move mem_cgroup_swappiness and vm_swappiness to mm/swap.h". commit ce14fe4cd756d2ad75a1f5b53816872b4e69f7cc Merge: 66498c75b4f801 6c322f5cf7476d Author: Linus Torvalds Date: Mon Aug 24 18:11:49 2026 -0700 Merge tag 'cifs-fixes-7.3-rc1' of https://git.manguebit.org/linux Pull smb client updates from Paulo Alcantara: - clear sensitive data after use (stack and heap cryptographic keys/hashes) - file size and cache synchronization fixes (fscache cookie serialization and truncation handling) - protocol validation and buffer safety fixes (prevent OOB access and loff_t underflow) - metadata and POSIX attribute fixes (proper hard-link counts and setuid/setgid stripping) - DFS cache and unmount fixes (prevent target-hint UAF and unmount hangs) - general client improvements (fix read request leaks, stats loops, handle servers that don't support O_TMPFILE) * tag 'cifs-fixes-7.3-rc1' of https://git.manguebit.org/linux: (33 commits) cifs: fix loff_t underflow in cifs_remap_file_range() when len == 0 smb: client: reject a tree connect response whose byte count is too small cifs: call pagecache_isize_extended() in cifs_setsize() when extending smb: client: fix copy-paste error in WSL EA length accounting for $LXDEV smb: client: remove redundant NULL check before kfree() smb: client: restore the data_offset bound in is_valid_oplock_break() cifs: clear tcon after cifsFileInfo_put() in cifs_file_set_size() smb: client: Avoid leaking sensitive data to the heap in connect.c smb: client: Clear sensitive stack data in smb1encrypt.c smb: client: Clear sensitive stack data in cifsencrypt.c smb: client: Clear sensitive stack and heap data in smb2ops.c smb: client: Clear sensitive stack data in smb2transport.c Revert "cifs: remove all cifs files before kill super" smb: client: fix use-before-check of ReparseDataLength in reparse_buf_ptr() smb: client: fix ALIGN() overflow in symlink_data() error context loop smb: client: simplify __build_path_from_dentry_optional_prefix() smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2 smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2() smb/client: decode reparse metadata using its payload type smb/client: preserve open info type across compound queries ... commit 64f74d8f728877858372c52067e5c0c091f8db24 Author: Thomas Weißschuh Date: Wed Aug 19 09:24:21 2026 +0200 um: Use asm-generic/timex.h over the host architecture one The removal of the architecture-specific asm/timex.h was meant to fall back to asm-generic/timex.h. However on UML, the host architecture headers are earlier on the include path and therefore asm/timex.h from the host architecture is used. On x86 that header in turn requires the generation of cpufeaturemasks.h, which is not set up for UML and the build fails. In file included from ../arch/x86/include/asm/tsc.h:9, from ../arch/x86/include/asm/timex.h:6, from ../include/linux/timex.h:67, from ../include/linux/time32.h:13, from ../include/linux/time.h:60, from ../include/linux/jiffies.h:10, from ../include/linux/ktime.h:25, from ../include/linux/timer.h:6, from ../include/linux/uprobes.h:18, from ../include/linux/mm_types.h:16, from ../include/linux/mmzone.h:22, from ../include/linux/gfp.h:7, from ../include/linux/slab.h:17, from ../include/linux/crypto.h:18, from ../arch/um/kernel/asm-offsets.c:6: arch/x86/include/asm/tsc.h: In function ‘get_cycles’: arch/um/include/asm/cpufeature.h:52:39: error: implicit declaration of function ‘DISABLED_MASK_BIT_SET’ [-Wimplicit-function-declaration] 52 | (__builtin_constant_p(bit) && DISABLED_MASK_BIT_SET(bit) ? 0 : _static_cpu_has(bit)) | ^~~~~~~~~~~~~~~~~~~~~ arch/x86/include/asm/tsc.h:79:14: note: in expansion of macro ‘cpu_feature_enabled’ 79 | if (!cpu_feature_enabled(X86_FEATURE_TSC)) | ^~~~~~~~~~~~~~~~~~~ arch/um/include/asm/cpufeature.h:115:17: error: implicit declaration of function ‘_static_cpu_has’ [-Wimplicit-function-declaration] 115 | _static_cpu_has(bit) \ | ^~~~~~~~~~~~~~~ ... The x86-specific timex.h also doesn't make sense on UML in general. Reintroduce the UML-specific asm/timex.h and add a comment to document its necessity. [ bp: Improve that comment to actually state why stuff is there. ] Fixes: 3ed403bbc967 ("treewide: Remove CLOCK_TICK_RATE") Signed-off-by: Thomas Weißschuh Signed-off-by: Borislav Petkov (AMD) Reviewed-by: David Gow Link: https://patch.msgid.link/20260819-uml-timex-fix-v1-1-f690b514fc9f@linutronix.de commit db9deec5a345abc538d081fb221dc0b00a9695bd Author: Tomeu Vizoso Date: Mon Aug 24 17:26:11 2026 +0200 accel: ethosu: Don't read the U65 rounding mode as a storage mode Bits 15:14 of NPU_SET_{IFM,OFM}_PRECISION select the activation storage mode on U85 only. On U65 the same field holds the rounding mode, and the command stream parser has read it as a storage mode since the driver was added. That went unnoticed while unknown values fell through the switch, but now that they are rejected, every U65 command stream that asks for natural rounding (2) fails CMDSTREAM_BO_CREATE with -EINVAL. Mesa emits it for average pooling, concatenation, split, unpack, strided slice, LUT and argmax, which is 72 failures of the Teflon test suite on an i.MX93. Truncating rounding (1) is misread as well: it picks the two-tile address path and computes a bogus feature map size from tile bases the command stream never set. Read the field as a storage mode only on the hardware where it is one. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Fixes: 6b7e0066294d ("accel: ethosu: Handle U85 internal chaining buffer") Assisted-by: Claude:claude-opus-5 Signed-off-by: Tomeu Vizoso Link: https://patch.msgid.link/20260824152612.751007-1-tomeu@tomeuvizoso.net Signed-off-by: Rob Herring (Arm) commit 7ab64476a610fe65858fdc37c7a30caa13e334ac Author: GuoHan Zhao Date: Thu Jul 16 14:52:19 2026 +0800 accel/ethosu: check MMIO mapping errors in probe devm_platform_ioremap_resource() returns an error pointer when the register resource cannot be mapped. ethosu_probe() stores it and continues until initialization dereferences it through MMIO accessors. Return the mapping error before initializing the device. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Cc: stable@vger.kernel.org Signed-off-by: GuoHan Zhao Link: https://patch.msgid.link/20260716065219.931088-1-zhaoguohan@kylinos.cn Signed-off-by: Rob Herring (Arm) commit 1704aaaf5d22bc765c168402350d191e24e245bc Author: Deepanshu Kartikey Date: Mon Aug 24 20:16:53 2026 +0530 eventfs: Initialize ei->children and ei->list in init_ei() eventfs_create_dir() allocates the eventfs_inode and initializes it with init_ei(). But this does not initialize the eventfs_inode list_heads. If the eventfs_create_dir() fails due to memory pressure, it will call free_ei() before it initialized the lists, and that checks to make sure the eventfs_inode has no children. But because the list wasn't initialized, it will give a false warning. Fix it by moving the list initialization into init_ei(). Cc: stable@vger.kernel.org Fixes: 5790b1fb3d67 ("eventfs: Remove eventfs_file and just use eventfs_inode") Reported-by: syzbot+3ef80b4ed02226d04a06@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3ef80b4ed02226d04a06 Link: https://patch.msgid.link/20260824144653.54044-1-kartikey406@gmail.com Signed-off-by: Deepanshu Kartikey [ Rewrote change log ] Signed-off-by: Steven Rostedt commit 6c322f5cf7476ded7a9a20f7be72462065a03c68 Author: Frank Sorenson Date: Sat Aug 22 16:55:17 2026 -0500 cifs: fix loff_t underflow in cifs_remap_file_range() when len == 0 With len == 0 (clone to EOF), the effective length is computed as: len = src_inode->i_size - off; If off > i_size, this is a negative loff_t, corrupting the ByteCount in the FSCTL_DUPLICATE_EXTENTS_TO_FILE request and inverting the range in filemap_write_and_wait_range(). The existing off >= i_size check fires only after the ioctl has already been sent. Snapshot i_size_read() once for both the bounds check and the length calculation, eliminating the TOCTOU and 32-bit torn-read risk. Reject off > src_size with -EINVAL. Treat off == src_size as a no-op, consistent with __generic_remap_file_range_prep(). Fixes: 04b38d601239 ("vfs: pull btrfs clone API to vfs layer") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 65deb18359341141d37dc86fc7853511be3c87a7 Author: Bryam Vargas Date: Fri Aug 21 07:36:16 2026 -0500 smb: client: reject a tree connect response whose byte count is too small CIFSTCon() bounds its strnlen() over the byte area with the server's ByteCount minus two, which for ByteCount 0 or 1 goes negative as an int and converts to a huge size_t. The later subtraction wraps the __u16 bytes_left, and that is what bounds cifs_strndup_from_utf16(): a bound of up to 65535 against a ~16 KB cifs_req_poolp object runs off the end of the slab object, and the bytes reach userspace through tcon->nativeFileSystem in /proc/fs/cifs/DebugData. Reject a byte area too small for what the parser consumes. Two bytes is the least it can consume, and no conformant response carries fewer. The new trace point is the 129th smb_eio_trace entry, which __mode(byte) cannot represent, so the attribute goes with it. Fixes: cc20c031bb06 ("cifs: convert CIFSTCon to use new unicode helper functions") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit c510edb9734af1c274d18f4f31a471a166bbc7e8 Author: Frank Sorenson Date: Thu Aug 20 16:13:10 2026 -0500 cifs: call pagecache_isize_extended() in cifs_setsize() when extending 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 commit 5d14030b46af1a958fd104b020fbb93631c98822 Author: Frank Sorenson Date: Thu Aug 20 16:22:10 2026 -0500 smb: client: fix copy-paste error in WSL EA length accounting for $LXDEV The LXDEV block in cifs_query_path_info() uses SMB2_WSL_XATTR_MODE_SIZE (4) instead of SMB2_WSL_XATTR_DEV_SIZE (8), undercounting eas_len by 4 bytes per $LXDEV EA. eas_len is used only as a zero/non-zero presence flag so there is no current functional impact, but the value is incorrect and misleading. Fixes: 97db41604555 ("smb: client: parse uid, gid, mode and dev from WSL reparse points") Cc: stable@vger.kernel.org Cc: Paulo Alcantara Signed-off-by: Frank Sorenson Acked-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 019716ca2633998c0e9c57df08b4e34d384d4b58 Author: Mohammad Shahid Date: Fri Jul 3 17:51:04 2026 +0530 smb: client: remove redundant NULL check before kfree() kfree() safely handles NULL pointers, so the explicit NULL check before calling kfree() is unnecessary. This issue was reported by ifnullfree.cocci. Signed-off-by: Mohammad Shahid Signed-off-by: Paulo Alcantara commit ba22f575de9deeae4ae0859ca4315a7698226237 Author: Bryam Vargas Date: Tue Jul 28 13:06:13 2026 -0500 smb: client: restore the data_offset bound in is_valid_oplock_break() Commit 83bfbd0bb902 ("cifs: Remove the RFC1002 header from smb_hdr") changed the quantity this bound is measured against. It used to be srv->total_read minus the 4-byte RFC1002 preamble that total_read then included, so it was the SMB message length. The same commit stopped counting the preamble, and the mechanical substitution to srv->total_read - srv->pdu_size left an expression that is identically zero: standard_receive3() reads MID_HEADER_SIZE() bytes and then exactly pdu_length - MID_HEADER_SIZE() more, adding both to total_read. len is therefore 0, the subtraction below it wraps, and no __u32 DataOffset can exceed the result, so the check from commit 097f5863b1a0 ("cifs: read overflow in is_valid_oplock_break()") no longer rejects anything. Use total_read, which is now the message length on its own. Fixes: 83bfbd0bb902 ("cifs: Remove the RFC1002 header from smb_hdr") Cc: stable@kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Paulo Alcantara commit b96db32fed8dfb2478d7c208f89bf383beed1535 Author: Frank Sorenson Date: Thu Aug 6 21:41:56 2026 -0500 cifs: clear tcon after cifsFileInfo_put() in cifs_file_set_size() When the else branch of cifs_file_set_size() finds a writable file handle via find_writable_file(), it borrows tcon and server from the handle's tlink, attempts the handle-based set_file_size() RPC, and then releases the handle with cifsFileInfo_put(). If set_file_size() fails, execution falls through to the path-based fallback, which reuses the borrowed tcon and server under the "if (tcon == NULL)" guard. Since tcon is not NULL at that point, the guard is skipped. If cifsFileInfo_put() dropped the last reference on a tlink that was already removed from the tlink tree (TCON_LINK_IN_TREE cleared, as happens during reconnection or session teardown), cifs_put_tlink() will have freed tcon; the subsequent set_path_size() call is then a use-after-free. Setting tcon = NULL after cifsFileInfo_put() causes the existing guard to take the cifs_sb_tlink() path, which acquires a fresh reference for the path-based operation or fails cleanly if the session is gone. Fixes: 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC") Cc: stable@vger.kernel.org Cc: Paulo Alcantara Signed-off-by: Frank Sorenson Signed-off-by: Paulo Alcantara commit 111a2b8717efbd9729d36828308d5163fdc977c3 Author: Thomas Huth Date: Wed Aug 12 15:01:52 2026 +0200 smb: client: Avoid leaking sensitive data to the heap in connect.c TCP_Server_Info contains a preauth_sha_hash[] and a cryptkey[] array that might contain sensitive data. Thus free its memory with kfree_sensitive() to avoid that we are leaking this information to the heap. Signed-off-by: Thomas Huth Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 2f9af06e30b78ccb6f2708d89793180c29e4feef Author: Thomas Huth Date: Wed Aug 12 15:01:51 2026 +0200 smb: client: Clear sensitive stack data in smb1encrypt.c Make sure to not leak signature data via the stack, clear it with memzero_explicit() before leaving the function. To avoid that we have to introduce "goto"-cleanup here, we re-arrange the code a little bit (and drop the commented cifs_dump_mem debug code that looks like a leftover from very early days). Signed-off-by: Thomas Huth Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 1a6bd74a27f1007b02c5a30aaa35608286bd0d23 Author: Thomas Huth Date: Wed Aug 12 15:01:50 2026 +0200 smb: client: Clear sensitive stack data in cifsencrypt.c Make sure to not leak hash data via the stack, clear it with memzero_explicit() before leaving the function. Signed-off-by: Thomas Huth Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 55a1ad8413f5bae504381b9bf90849c8cf283892 Author: Thomas Huth Date: Wed Aug 12 15:01:49 2026 +0200 smb: client: Clear sensitive stack and heap data in smb2ops.c Make sure to not leak key-related data via the heap or the stack by using kfree_sensitive() or memzero_explicit() here. Signed-off-by: Thomas Huth Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 3d93986f68f4a58002755794a17411b5fe6d339b Author: Thomas Huth Date: Wed Aug 12 15:01:48 2026 +0200 smb: client: Clear sensitive stack data in smb2transport.c Sensitive data like keys that are stored in stack-local arrays could be leaked via the stack to the calling functions. There is no known vulnerability for this right now, but it's good security style to explicitly zeroize this sensitive material as soon as possible to avoid that it could be exploited together with other bugs later. Signed-off-by: Thomas Huth Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit ce31ec06d3c0ee9279dddb848343c62b90322ac3 Author: Zizhi Wo Date: Tue Aug 18 11:06:34 2026 +0800 Revert "cifs: remove all cifs files before kill super" This reverts commit 6d9a4aaaa8b2612b5ef9d581e2f286a458b71ee1. First, directly flushing fileinfo_put_wq in that commit cannot guarantee that all in-flight I/O has run its cleanup_work on system_dfl_wq and subsequently called queue_work(fileinfo_put_wq, ...). Flushing only the latter workqueue may therefore miss puts that have not yet been queued, so the fix is not reliable in the first place. Moreover, this fix flushes inside cifs_umount(), which means the busy-dentry warning can still be triggered when umount_check() is called inside kill_anon_super(), because kill_anon_super() is executed before cifs_umount(). Second, commit 75f5c412fa86 ("smb: client: fix busy dentry warning on unmount after DIO") already drains both serverclose_wq and fileinfo_put_wq in cifs_kill_sb(), before kill_anon_super(). By adding a per-superblock outstanding-rreq counter, it guarantees that all cleanup_work for this sb have run, and thus all relevant cfile puts are queued on fileinfo_put_wq or serverclose_wq. Third, no path between those drains and cifs_umount() can queue new work onto either workqueue. In the "cifs_sb->root == NULL" path there are no file-related workers either, so that case is safe as well. Therefore the busy-dentry and null-ptr-deref problems cannot arise, and the flush added by commit 6d9a4aaaa8b2 ("cifs: remove all cifs files before kill super") is redundant and can be removed. Signed-off-by: Zizhi Wo Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 05f78e6cf34ea3a285053bd5999e08e8ac298bd5 Author: Frank Sorenson Date: Mon Aug 17 12:16:57 2026 -0500 smb: client: fix use-before-check of ReparseDataLength in reparse_buf_ptr() reparse_buf_ptr() reads buf->ReparseDataLength before checking that count covers the full fixed header: buf = (struct reparse_data_buffer *)((u8 *)io + off); len = sizeof(*buf); /* 8 bytes */ rdlen = le16_to_cpu(buf->ReparseDataLength); /* offset 4, 2 bytes */ if (count < len || count < rdlen + len) /* check comes after */ struct reparse_data_buffer has ReparseDataLength at offset 4. If a server returns OutputCount < 6, the read at offset 4-5 reaches past the end of the received data. The off+count bounds against iov_len were already validated, but that does not protect against count being smaller than sizeof(*buf). Split the check: verify count >= sizeof(*buf) before reading ReparseDataLength, then verify count covers the data region. Fixes: a158bb66b137 ("smb: client: optimise reparse point querying") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 62656b024efc21c3230eade1a847f25871c3d2bb Author: Frank Sorenson Date: Mon Aug 17 12:16:51 2026 -0500 smb: client: fix ALIGN() overflow in symlink_data() error context loop The check added by commit 7d9a7f1f96cd ("smb/client: fix possible infinite loop and oob read in symlink_data()") compared the post-ALIGN length against the remaining buffer, but ALIGN() itself can overflow: for ErrorDataLength near UINT32_MAX (e.g. 0xFFFFFFF9), ALIGN(x, 8) wraps to 0, so the subsequent bounds check passes, and the loop advances by zero bytes leaving 'p' pointing into stale data. Fix by checking the raw ErrorDataLength against the remaining space before applying ALIGN(), then checking again after. Since raw_len is bounded by the buffer, raw_len + 7 cannot overflow, so the second check is an exact post-alignment bounds guard. Fixes: 76894f3e2f71 ("cifs: improve symlink handling for smb2+") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 3fffaa8a646c5bee02a553014b7f80e6ea2a76dd Author: Dmitry Antipov Date: Fri Aug 14 07:14:18 2026 +0300 smb: client: simplify __build_path_from_dentry_optional_prefix() Use the convenient 'strreplace()' to simplify '__build_path_from_dentry_optional_prefix()'. Signed-off-by: Dmitry Antipov Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 730d0bb19507b9e19c2fe5343109ac618e2fbce5 Author: Frank Sorenson Date: Wed Aug 12 21:39:51 2026 -0500 smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2 When a valid primary TRANSACT2 response has been received (mid->resp_buf set, mid->multiRsp true) and a subsequent secondary response causes cifs_check_trans2() to return false -- either because the SMB header is invalid (malformed != 0) or because check2ndT2() rejects the PDU -- handle_mid() overwrites mid->resp_buf with the new buffer (leaking the primary buffer) and, because mid->multiRsp is set, skips the server->smallbuf/bigbuf NULL-out. When the user thread frees mid->resp_buf, server->smallbuf or server->bigbuf is left dangling; the demux thread reuses it for the next packet, resulting in a use-after-free. Combine both early-exit conditions and, when mid->multiRsp is already set, abort the pending transaction inline: set multiEnd, call dequeue_mid() with malformed=true, and return true so handle_mid() exits without touching mid->resp_buf or the server buffer pointers. Fixes: 316cf94a910f ("CIFS: Move trans2 processing to ops struct") Cc: stable@vger.kernel.org # cifs_check_trans2() is in smb1ops.c on kernels < 7.0 Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 6343c1da561962688f203362d80d6a3bfa39fa1b Author: Frank Sorenson Date: Tue Aug 11 21:41:26 2026 -0500 smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2() coalesce_t2() computes data pointers directly from server-supplied DataOffset fields with no validation against buffer bounds: data_area_of_tgt = (char *)&pSMBt->hdr.Protocol + get_unaligned_le16(&pSMBt->t2_rsp.DataOffset); data_area_of_src = (char *)&pSMBs->hdr.Protocol + get_unaligned_le16(&pSMBs->t2_rsp.DataOffset); data_area_of_tgt += total_in_tgt; ... memcpy(data_area_of_tgt, data_area_of_src, total_in_src); A small DataOffset can push a pointer below the actual byte area, overwriting header fields; a large one can push it past the buffer end, causing out-of-bounds heap reads (source) or writes (target). The BCC overflow guard does not prevent this: BCC reflects how much data is present, while DataOffset controls where in the buffer it starts. The "validate target area" comment present since the function was first written in 2005 was a placeholder that was never implemented. Add lower- and upper-bound checks for both data pointers before the memcpy, and before any target header fields are modified. Fixes: e4eb295d38b5 ("[PATCH] cifs: Handle multiple response transact2 part 1 of 2") Cc: stable@vger.kernel.org Reported-by: Shen Yongchao Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 43549eb84266c424ee6c004f149574e2ae4b6515 Author: Ze Tan Date: Tue Aug 11 14:00:47 2026 +0800 smb/client: decode reparse metadata using its payload type cifs_open_info_data stores FILE_ALL_INFORMATION and SMB3 POSIX query information in a union. reparse_info_to_fattr() selects a union member from the mount mode, while several directory checks always read fi.Attributes. The metadata can instead come from an SMB2 CREATE response on a POSIX mount, or from a POSIX query while processing a reparse point. In those cases the mount mode and hard-coded fi accesses select the wrong union member. See the procedures below: cifs_nt_open smb2_open_file SMB2_open data->fi = SMB2 CREATE response data->contains_posix_file_info = false cifs_get_inode_info reparse_info_to_fattr if (tcon->posix_extensions) // true smb311_posix_info_to_fattr data->posix_fi // wrong union member smb311_posix_get_fattr smb2_query_path_info smb2_compound_op data->posix_fi = SMB3 POSIX query response data->contains_posix_file_info = true reparse_info_to_fattr data->fi.Attributes // wrong union member Add a common DOS attribute accessor and use contains_posix_file_info both for attribute reads and for the final fattr conversion. Signed-off-by: Ze Tan Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 9437f2113b60a5a8593aa4b41b6f6632f5cabcfd Author: Ze Tan Date: Tue Aug 11 14:00:46 2026 +0800 smb/client: preserve open info type across compound queries contains_posix_file_info describes the metadata stored in the fi/posix_fi union. GET_REPARSE and QUERY_WSL_EA do not update that union, so clearing the flag while processing those responses can make POSIX metadata look like FILE_ALL_INFORMATION. Set the flag when CREATE or a validated query response actually populates the union, and leave it unchanged for auxiliary compound operations. This also avoids changing the type when a query fails before copying any metadata. The issue can be reproduced against a Samba server with SMB3 UNIX extensions enabled: mount -t cifs /// /mnt/cifs \ -o vers=3.1.1,posix,reparse=nfs,actimeo=0 mkfifo /mnt/cifs/test-fifo umount /mnt/cifs mount -t cifs /// /mnt/cifs \ -o vers=3.1.1,posix,reparse=nfs,actimeo=0 stat -c '%F %s' /mnt/cifs/test-fifo Before this change, stat reports "fifo 1024" although the server-side EOF is zero. After this change, it reports "fifo 0". Fixes: 9df23801c83d ("smb311: failure to open files of length 1040 when mounting with SMB3.1.1 POSIX extensions") Signed-off-by: Ze Tan Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit ebdc1afb1e268de4c01814fa960286392801b604 Author: Ze Tan Date: Tue Aug 11 14:00:45 2026 +0800 smb/client: mark missing nlink values as unknown Several SMB1 fallback and open responses do not provide the hard link count. The SMB2 create-only query fallback has the same limitation. These paths currently leave a zero link count or synthesize a value of one and then expose it as authoritative metadata. Mark those results with unknown_nlink so existing inodes keep their cached link count and new inodes receive the usual sane default. This was tested against Samba with "server min protocol = NT1". Mount the share using SMB1 with Unix extensions disabled: mount -t cifs /// /mnt/cifs \ -o username=,vers=1.0,nounix Create three names for the same inode and cache its real link count: TESTDIR=/mnt/cifs/nlink-repro-$$ mkdir "$TESTDIR" touch "$TESTDIR/file1" ln "$TESTDIR/file1" "$TESTDIR/file2" ln "$TESTDIR/file1" "$TESTDIR/file3" stat -c 'before open: %h' "$TESTDIR/file1" Open the file and read the link count through the open descriptor: exec 3<"$TESTDIR/file1" stat -Lc 'after open: %h' /proc/$$/fd/3 exec 3<&- Clean up the test files: rm -f "$TESTDIR/file1" "$TESTDIR/file2" "$TESTDIR/file3" rmdir "$TESTDIR" Before this change, the two stat commands report 3 and 1 because the SMB1 open response overwrites the known link count. With this change, both commands report 3. Signed-off-by: Ze Tan Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit 48cab1fd5720508148673f59d8ed52c7c7fffca2 Author: Frank Sorenson Date: Sat Aug 8 15:29:03 2026 -0500 cifs: fix clearing stats for fastest execution of each smb2 command The code to clear the 'fastest_cmd' statistics has a typo that repeatedly clears the stat for cmd 0, rather than iterating through each cmd. Fix the typo (0->i). Fixes: 433b8dd7672be ("SMB3: Track total time spent on roundtrips for each SMB3 command") Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara commit b70b7b71561f2be1183b6046964d950c2b203bfc Merge: 3b11a77f699809 ebe6674292fda9 Author: Jakub Kicinski Date: Mon Aug 24 13:02:35 2026 -0700 Merge tag 'for-net-2026-08-24' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: Core: - hci_core: use skb_get() instead of skb_clone() for req_skb - hci_conn: re-enable advertising only for peripheral role - hci_event: clear HCI_LE_ADV only on a created connection - hci_sync: Clear HCI_CMD_PENDING when dropping the last request - hci_sync: add conditional locking annotations - hci_sync: do not leak an hci_conn when a second LE connect is rejected - eir: Fix OOB read in eir_get_service_data() - mgmt: fix 'hdev->discovery.uuids' NULL dereference - L2CAP: access chan->conn safely in get/setsockopt - L2CAP: reject accept queue add unless BT_LISTEN - L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan - RFCOMM: serialize security confirmation handling - RFCOMM: serialize session teardown - RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop - ISO: fix use-after-free of listener socket in iso_conn_ready Drivers: - btnxpuart: Validate the FW dump header length - btnxpuart: Check remote M.2 connector availability before pwrseq - btmtksdio: Take exclusive ownership of the SKB before TX - btmtksdio: Fix out-of-bounds DMA read in the TX path - hci_uart: Fix false success return in hci_uart_setup() - hci_bcm: fix usage_count leak when autosuspend_delay is negative - hci_h5: fix usage_count leak when autosuspend_delay is negative - hci_intel: fix usage_count leak when autosuspend_delay is negative - btmtk: Do not report success when subsys reset fails - btmtk: Do not discard the subsystem reset timeout - btusb: limit RTL8761B BROKEN_EXT_SCAN quirk to 0bda:a728 - hci_bcm4377: Ignore reserved PHY in ext adv reports on BCM4378 * tag 'for-net-2026-08-24' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: (27 commits) Bluetooth: RFCOMM: serialize session teardown Bluetooth: do not leak an hci_conn when a second LE connect is rejected Bluetooth: RFCOMM: serialize security confirmation handling Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN quirk to 0bda:a728 Bluetooth: hci_uart: Fix false success return in hci_uart_setup() Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready Bluetooth: hci_core: use skb_get() instead of skb_clone() for req_skb Bluetooth: hci_event: clear HCI_LE_ADV only on a created connection Bluetooth: hci_conn: re-enable advertising only for peripheral role Bluetooth: hci_bcm4377: Ignore reserved PHY in ext adv reports on BCM4378 Bluetooth: eir: Fix OOB read in eir_get_service_data() Bluetooth: btnxpuart: Validate the FW dump header length Bluetooth: hci_sync: add conditional locking annotations Bluetooth: btnxpuart: Check remote M.2 connector availability before pwrseq Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX Bluetooth: btmtk: Do not discard the subsystem reset timeout Bluetooth: btmtk: Do not report success when subsys reset fails Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan ... ==================== Link: https://patch.msgid.link/20260824180639.3570348-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski commit 66498c75b4f8017f62d720d9b59675bdf3abce91 Merge: 16e6a1a3cb3fa5 0d995da5fb97e8 Author: Linus Torvalds Date: Mon Aug 24 12:21:15 2026 -0700 Merge tag 'dmaengine-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine Pull dmaengine updates from Vinod Koul: "Core: - New API to combine configuration and preparation and users New hardware support: - Mediatek MT8189 SoC uart dma support Updates: - Designware dma driver flatten desc structures and simplify code, interrupt-path groundwork changes, first part of PCI EP DMA support - Updates to zynqmp_dma with runtime PM and device removal improvments - Xilinx dma optimizations for AXIDMA and MCDMA channel management" * tag 'dmaengine-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: (73 commits) dmaengine: dw-edma: Mark emulated IRQ as level-triggered dmaengine: idxd: assign all engines to group 0 in IAA defaults dmaengine: qcom_hidma: remove conditional return with no effect dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal dmaengine: fsl-edma: tracing: no ptr dereference during log output dmaengine: dw-edma: Program endpoint function numbers dmaengine: dw-edma-pcie: Add chip flags to match data dmaengine: dw-edma-pcie: Handle optional data blocks dmaengine: dw-edma-pcie: Factor out descriptor block address lookup dmaengine: dw-edma-pcie: Add register offset match flag dmaengine: dw-edma-pcie: Add platform ops to match data dmaengine: dw-edma-pcie: Rename vsec_data to dma_data dmaengine: dw-edma-pcie: Add capability match data dmaengine: dw-edma-pcie: Track non-LL mode in DMA data dmaengine: dw-edma: Add partial channel ownership mode dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dmaengine: dw-edma: Add core quiesce operations dmaengine: dw-edma: Add per-channel interrupt routing control dmaengine: dw-edma: Factor out HDMA interrupt setup helper dmaengine: dw-edma: Defer channel IRQ handling to workqueue ... commit 16e6a1a3cb3fa5fa11cd76a9d71235d927923329 Merge: ab9b9b51baa9bb ba8376e8c76c65 Author: Linus Torvalds Date: Mon Aug 24 12:19:23 2026 -0700 Merge tag 'phy-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy Pull phy updates from Vinod Koul: "As usual bunch of new device and driver support and updates to existing drivers and addition of Manivannan to help with reviews. New Support: - Mediatek MT8196 DSI PHY support - Renesas RZ/G3L usb2 support - Qualcomm SM8475 QMP USB PHY and PCIe phy, IPQ9650 QMP PCIe PHY, QUSB2 Phy for Shikra SoC, Hawi support for QMP PCIe phy and UFS PHY. Glymur QMP PCIe Multi-PHY driver and multiple link-mode support, ipq5210 PCIe phy support - Spacemit USB3/PCIe comb PHY driver Updates: - Samsung hdptx driver improvements for modernizing the register access and code cleanup - Qualcomm drop duplicate v8 DP headers, improved runtime handling for qmp drivers - Rockchip clock lane phase tuning and 2500 Mbps support and TMDS rate handling - Freescale imx8mq improvements for runtime pm, pd handling" * tag 'phy-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (76 commits) MAINTAINERS: Add Manivannan Sadhasivam as the Reviewer for Generic PHY Framework phy: rockchip-samsung-dcphy: fix out-of-range max_register phy: qcom: qmp-pcie: Add QMP PCIe Multi-PHY driver dt-bindings: phy: qcom: Add Glymur QMP PCIe multiple link-mode PHY phy: rockchip: samsung-hdptx: Consistently use bitfield macros phy: rockchip: samsung-hdptx: Simplify GRF access with FIELD_PREP_WM16() phy: rockchip: samsung-hdptx: Drop restrict_rate_change handling phy: rockchip: samsung-hdptx: Consolidate consumer_put on error path phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaround phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes phy: rockchip: samsung-hdptx: Fix rate recalculation for 3.2GHz FRL phy: rockchip: samsung-hdptx: Guard against clk rate integer underflow phy: rockchip: samsung-hdptx: Prevent divide-by-zero when computing clk rate phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy phy: qcom: qmp-combo: Correct pre-emphasis table for QMP v4 DP PHYs phy: renesas: rcar-gen3-usb2: Ignore missing VBUS regulator phy: qcom: qmp-pcie: Add support for SM8475 Gen3x1 PCIe0 port phy: qcom: qmp-pcie: Add pcs_lane1 offset to V5 offsets dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add SM8475 QMP PHY ... commit ab9b9b51baa9bb964e9219f81682c4f1761ee47d Merge: 2f43193b88188b 5b08a3afd2995e Author: Linus Torvalds Date: Mon Aug 24 12:16:16 2026 -0700 Merge tag 'soundwire-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire Pull soundwire updates from Vinod Koul: - Intel dmi quirks ghost list handling for Asus Zenbook Duo, Asus ROG Zephyrus Duo and Asus Expertbook. Intel Peripheral bra_block_alignment handling - Cadence library BRA_NumBytes[8] support - Qualcomm SCP address paging, bus mclk_freq support. Increase of data ports to 17 and driver improvements * tag 'soundwire-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: soundwire: dmi-quirks: Disable ghost Realtek on Asus ROG Zephyrus Duo soundwire: stream: validate slave port properties soundwire: honor clock_reg_supported in the clock scaling check soundwire: qcom: set the bus mclk_freq property soundwire: dmi-quirks: Disable ghost Realtek on Asus Zenbook Duo soundwire: intel_ace2x: handle the max_data_per_frame property soundwire: get mipi-sdw-bra-mode-max-data-per-frame property soundwire: intel: handle Peripheral bra_block_alignment soundwire: Add bra_block_alignment property support soundwire: cadence_master: add BRA_NumBytes[8] support soundwire: bus.h: repair kernel-doc comments soundwire: intel_auxdevice: Add cs42l44 to wake_capable_list soundwire: qcom: add SCP address paging support soundwire: dmi-quirks: add a global ghost list soundwire: dmi-quirks: Disable ghost Realtek on Asus Expertbook soundwire: qcom: Allocate sruntime array dynamically soundwire: qcom: Fix port exhaustion check in stream_alloc_ports dt-bindings: soundwire: qcom: Increase max data ports to 17 commit 3b11a77f69980932c3924054d66e565c9a135747 Author: Sai Krishna Date: Fri Aug 21 15:53:37 2026 +0530 octeontx2-af: fix cn20k mailbox lifetime on repeated rvu_mbox_init() 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 commit b09a0503c755b6609fad59a84cc7f05b6843a03c Author: Suman Ghosh Date: Fri Aug 21 16:25:35 2026 +0530 octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup af_xdp_zc_qidx tracks receive queues using AF_XDP zero-copy and is allocated during PF/VF probe. Representors and other non-AF_XDP paths leave the pointer NULL, but several call sites used test_bit() on it unconditionally. Switching to devlink eswitch mode creates representors and runs otx2_init_hw_resources(), which reaches otx2_pool_aq_init() and oopses when dereferencing the NULL bitmap. Add NULL checks before every af_xdp_zc_qidx test_bit() use in the RSS, ethtool, XSK, and pool init paths. Fixes: efabce290151 ("octeontx2-pf: AF_XDP zero copy receive support") Signed-off-by: Suman Ghosh Signed-off-by: Geetha sowjanya Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260821105536.2998765-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski commit 80230a18c164a4b5bbc048fe2768b219ac17bc5a Author: Alexandra Winter Date: Fri Aug 21 14:55:01 2026 +0200 net/iucv: filter frames in afiucv_hs_rcv() by ingress device afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Cc: stable@vger.kernel.org Co-developed-by: Bryam Vargas Signed-off-by: Alexandra Winter Link: https://patch.msgid.link/20260821125501.3718748-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski commit d4f484661961636eb90d287050959e613795f73a Author: Allison Henderson Date: Fri Aug 21 22:26:47 2026 -0700 net/rds: use wq_has_sleeper() in rds_cong_map_updated() rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern. Fixes: 922cb17a5c81 ("RDS: Congestion-handling code") Signed-off-by: Allison Henderson Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260822052647.88318-1-achender@kernel.org Signed-off-by: Jakub Kicinski commit 2c7493f980140a5c40eb4f98f97c557193a2c330 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 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 commit 5b483f7791b079bb97d411f1066652ff659207ff Author: Victor Nogueira Date: Fri Aug 21 13:40:31 2026 -0300 net/sched: act_ife: Only operate on Ethernet frames act_ife encapsulates/decapsulates the original Ethernet header and uses skb->dev->hard_header_len as the length of that header. That is only correct for Ethernet devices: on a device where hard_header_len does not match the L2 header that was actually pulled (PPP reports PPP_HDRLEN while nothing is stripped on ingress), the ingress skb_push()/skb_pull() use the wrong length and can hit skb_under_panic when headroom is tight. IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites h_source/h_dest/h_proto, and calls eth_type_trans() on decode - so instead of trying to make the offsets work for arbitrary link types, simply drop packets that do not carry an Ethernet header. Checking skb->dev->type alone is not enough. We have to cater for a corner case where mirred can redirect an skb from a non-Ethernet device to an Ethernet one, and skb->dev then says nothing about the framing the skb actually has: an skb redirected from ppp0 reaches the target's ingress hook with mac_len 0 and no Ethernet header at all. So at ingress also require mac_len to be ETH_HLEN. On egress mac_len is not maintained, so the device type is all we have; a bogus redirect there yields a malformed frame rather than an out-of-bounds push, and it would be malformed with or without IFE. That corner case is not theoretical - redirecting from ppp0 into a veth that has an ife encode action on its ingress hook panics without this patch: skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000 data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3 kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657) tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874) tc_run (net/core/dev.c:4463) netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522) tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328) tcf_mirred_act (net/sched/act_mirred.c:489) tc_run (net/core/dev.c:4463) process_backlog (net/core/dev.c:6728) With Ethernet framing guaranteed, use ETH_HLEN instead of hard_header_len. Fixes: 295a6e06d21e ("net/sched: act_ife: Change to use ife module") Reported-by: vega@nebusec.ai Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260821164031.32824-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski commit 5c07193ebe4718f71752c11d30cf389fa7b4c870 Author: Manush Prajwal Date: Fri Aug 21 15:37:14 2026 +0530 net: ethernet: renesas: rswitch: fix device_node refcount leak in rswitch_get_port_node() On an of_property_read_u32() failure, rswitch_get_port_node() set port to NULL and jumped to the out label before releasing the reference the for_each_available_child_of_node() iterator was holding on it. Once port was overwritten with NULL, that reference could never be released since out: only put "ports", the parent node. Rework the function around for_each_available_child_of_node_scoped() instead of adding a manual of_node_put(), so the iterator's reference is dropped automatically on every exit path. Since port is the function's return value, take an explicit reference with of_node_get() on the match before breaking out of the loop. Signed-off-by: Manush Prajwal Link: https://patch.msgid.link/6a882352.ee10049a.267d65.7a31@mx.google.com Signed-off-by: Jakub Kicinski commit 01ba856c3604ec01c83619a05c2d405f7532a7b0 Merge: 9edf8d4876e8a2 fa1a8457b85817 Author: Jakub Kicinski Date: Mon Aug 24 11:56:39 2026 -0700 Merge branch 'net-enetc-restore-rx-ring-congestion-mode-after-ring-reconfiguration' Wei Fang says: ==================== net: enetc: restore RX ring congestion mode after ring reconfiguration The RX BD ring congestion mode (CM) enables the ENETC MAC to generate PAUSE frames when ingress congestion occurs. It is configured only in the phylink .mac_link_up() callback, which is invoked when the link status changes. However, enetc_reconfigure() tears down and re-creates the RX BD rings at runtime without any link status change, for example when enabling or disabling PTP RX hardware timestamping. enetc_setup_rxbdr() rebuilds the RBMR register from zero, which clears the CM bit, and since the link status does not change, .mac_link_up() is not called again to restore it. As a result, flow control silently stops working after such a reconfiguration. To solve this issue, track the desired CM state in a software flag ENETC_RXBDR_CM, which is maintained by the .mac_link_up() / .mac_link_down() callbacks and consulted by enetc_setup_rxbdr() when the RX BD rings are (re)configured. Both ENETC v1 and ENETC v4 are affected and are fixed in the same way. ==================== Link: https://patch.msgid.link/20260821064140.1315611-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski commit fa1a8457b8581725ae237efefb2358eddd7e05c9 Author: Wei Fang Date: Fri Aug 21 14:41:40 2026 +0800 net: enetc: restore RX ring congestion mode for ENETC v4 ENETC v4 has the same problem as ENETC v1: the RX BD ring congestion mode (CM) is only configured in the phylink .mac_link_up() callback, so it is cleared when enetc_reconfigure() rebuilds the RX BD rings at runtime (for example when enabling or disabling PTP RX hardware timestamping) without a link status change, and it is never restored. As a result, the MAC can no longer generate PAUSE frames on ingress congestion and flow control stops working. Fix it in the same way as ENETC v1. Track the desired CM state in the software flag ENETC_RXBDR_CM. Route enetc4_set_tx_pause() through the shared helper enetc_set_congestion_mode(), which sets or clears the flag according to tx_pause and updates the ENETC_RBMR_CM bit under si->gen_lock. When the RX BD rings are (re)enabled, enetc_enable_rxbdr() consults this flag and restores the CM bit accordingly, so flow control survives ring reconfiguration even when the link status does not change. Fixes: f5b9a1cde0a2 ("net: enetc: add PTP synchronization support for ENETC v4") Signed-off-by: Wei Fang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821064140.1315611-3-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski commit 9e94d8e14ae45e3fda8c0919f745db3ed3715433 Author: Wei Fang Date: Fri Aug 21 14:41:39 2026 +0800 net: enetc: restore RX ring congestion mode after ring reconfiguration The RX ring congestion mode (CM) is only configured in the phylink .mac_link_up() callback enetc_pl_mac_link_up(), which sets the ENETC_RBMR_CM bit when tx_pause is enabled. This callback runs only when the link status changes. However, enetc_reconfigure() tears down and re-creates the RX BD rings at runtime without any link status change, for example when attaching or detaching an XDP program, or when enabling/disabling PTP RX hardware timestamping. The rings are rebuilt from a cleared RBMR, so the CM bit is lost. Since the link status does not change, enetc_pl_mac_link_up() is not called again and the CM bit is never restored. As a result, the ENETC MAC can no longer generate PAUSE frames on ingress congestion, and flow control stops working after such a reconfiguration. Track the desired CM state in a software flag ENETC_RXBDR_CM. Set or clear this flag in enetc_pl_mac_link_up() according to tx_pause. When the RX BD rings are (re)enabled, enetc_enable_rxbdr() consults this flag and restores the ENETC_RBMR_CM bit accordingly, so flow control survives ring reconfiguration even when the link status does not change. RBMR is now written as a whole word from enetc_enable_rxbdr() rather than by read-modify-write from several call sites. Serialize the remaining RBMR read-modify-write paths, the congestion mode update and the RX VLAN offload update, with the new si->gen_lock so they cannot race each other. Fixes: 5093406c784f ("net: enetc: implement ring reconfiguration procedure for PTP RX timestamping") Signed-off-by: Wei Fang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821064140.1315611-2-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski commit 9edf8d4876e8a2471e66f54d36208eaff2858392 Author: Naveen Mamindlapalli Date: Fri Aug 21 11:24:45 2026 +0530 octeontx2-af: Fix TL3/TL2 link config ENA clearing Clear and restore the ENA bit for each TL3/TL2 link entry during SMQ flush instead of repeatedly using the same link index. Fixes: 019aba04f08c ("octeontx2-af: Modify SMQ flush sequence to drop packets") Signed-off-by: Nitin Shetty J Signed-off-by: Naveen Mamindlapalli Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821055445.2517568-1-nshettyj@marvell.com Signed-off-by: Jakub Kicinski commit c745d091fc6fe59bc4c4024d6cee8b8bd120f298 Merge: 719296c4aa8213 c924884743e948 Author: Jakub Kicinski Date: Mon Aug 24 11:52:02 2026 -0700 Merge branch 'net-smc-fix-use-after-free-in-smc_rx_pipe_buf_release' Hidayath Khan says: ==================== net/smc: fix use-after-free in smc_rx_pipe_buf_release() smc_rx_pipe_buf_release() tests sk_state before taking the socket lock and then dereferences conn->rmb_desc and conn->lgr. A concurrent close runs smc_conn_free() in between, which releases those structures. On the is_reg_err path smcr_buf_unuse() frees the descriptor outright, so this is a use-after-free. Patch 2/2 fixes this by taking the socket lock first and testing conn->freed instead. smc_conn_free() sets that flag before releasing anything, under the same lock, so the two paths exclude each other. Patch 1/2 is a prerequisite. conn->freed shares a byte with killed and out_of_sync as single-bit bitfields. out_of_sync is written from the receive tasklet without the socket lock, so a concurrent store to freed from process context can be lost in the read-modify-write. Patch 1/2 gives each flag its own byte so stores do not interfere. ==================== Link: https://patch.msgid.link/20260820074642.966856-1-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski commit c924884743e948e25625b7fbf3ee2a9325a204a7 Author: Hidayath Khan Date: Thu Aug 20 09:46:42 2026 +0200 net/smc: fix use-after-free in smc_rx_pipe_buf_release() smc_rx_splice() hands RMB pages to a pipe and takes a socket reference per entry so the smc_sock stays alive until the reader finishes. The connection does not: a concurrent close runs smc_conn_free(), which releases the receive buffer back to the link group pool. smc_rx_pipe_buf_release() tests sk_state before taking the socket lock. The state can change between the test and the lock, and smc_rx_update_cons() then dereferences conn->rmb_desc and walks conn->lgr, which smc_conn_free() has already released. On the is_reg_err path smcr_buf_unuse() frees the descriptor outright, so this is a use-after-free. Take the socket lock first and test conn->freed instead. smc_conn_free() sets that flag before releasing anything, and every caller holds the socket lock. The two paths exclude each other: either the pipe release runs first with everything valid, or it sees the flag and skips the update. Fixes: 9014db202cb7 ("smc: add support for splice()") Cc: stable@vger.kernel.org Reviewed-by: Mahanta Jambigi Signed-off-by: Hidayath Khan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260820074642.966856-3-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski commit db51a8658c11a82432b64999519a269c3aabb447 Author: Hidayath Khan Date: Thu Aug 20 09:46:41 2026 +0200 net/smc: stop killed, freed and out_of_sync sharing a byte The three connection state flags are single-bit bitfields, so they occupy one byte of struct smc_connection and every store to one is a read-modify-write of the other two: u8 killed : 1; u8 freed : 1; u8 out_of_sync : 1; They are not written under a common lock. smc_cdc_msg_validate() sets out_of_sync from the receive tasklet, while smc_conn_kill() sets killed from process context under lock_sock(), and the receive path does not defer to the backlog when the socket is owned -- smc_cdc_msg_recv() takes only bh_lock_sock(). Give each flag its own byte so a store no longer touches its neighbours. All readers test them as booleans and are unchanged. struct smc_connection grows by two bytes. Fixes: b286a0651e44 ("net/smc: handle incoming CDC validation message") Cc: stable@vger.kernel.org Reviewed-by: Mahanta Jambigi Signed-off-by: Hidayath Khan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260820074642.966856-2-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski commit 719296c4aa8213d4ac8002e77d5956d436bc98d0 Author: Hidayath Khan Date: Thu Aug 20 16:47:29 2026 +0200 net/smc: fix socket refcount leak in smc_switch_conns() smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The second error exit is not affected, because sock_put() has already run by then. A leaked sk_refcnt means the smc_sock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down. smc_cdc_get_free_slot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smc_switch_conns() run in the first place. Restructure so there is a single sock_put() covering both outcomes, instead of adding a second one to the error path. Fixes: 95f7f3e7dc6b ("net/smc: improved fix wait on already cleared link") Cc: stable@vger.kernel.org Reviewed-by: Mahanta Jambigi Reviewed-by: Breno Leitao Signed-off-by: Hidayath Khan Link: https://patch.msgid.link/20260820144729.1019399-1-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski commit 317fe168f4c0fc30e5c375c22d9c8911940aea9b Author: Md Rabbani Date: Fri Aug 21 11:57:18 2026 +0600 net: stmmac: fix device node reference leaks in stmmac_mtl_setup() In stmmac_mtl_setup(), q_node is shared across the RX and TX queue parsing loops. When the RX queue loop breaks early because the number of parsed queues reaches plat->rx_queues_to_use, q_node retains an acquired reference count. If the error check passes (queue == plat->rx_queues_to_use), execution proceeds directly to the TX queue loop, where of_get_next_child() immediately overwrites q_node with the first TX child, permanently leaking the retained RX child device node reference. Switch both loops to for_each_child_of_node_scoped() so child node references are automatically dropped upon loop exit or early break, and remove the now-unnecessary function-scoped q_node variable and its manual of_node_put() at the exit label. Signed-off-by: Md Rabbani Link: https://patch.msgid.link/20260821055718.57-1-rabbanyhmm@gmail.com Signed-off-by: Jakub Kicinski commit af20e269f7459d2ce69887fdf2fad7caf986c865 Author: Zihan Xi Date: Thu Aug 20 18:40:28 2026 +0000 net: l2tp: do not propagate multicast notification errors The tunnel create, tunnel modify, session create, and session modify netlink handlers send multicast notifications through helpers that can fail while allocating or encoding a message, or while multicasting it. For tunnel and session create/modify, a notification is sent after the live operation has completed. Returning a best-effort notification error as the command result can therefore report failure for an operation that already committed and can cause callers to retry and accumulate live objects. Keep sending notifications for listener visibility, but do not propagate their best-effort status as the command result. This also keeps the tunnel modify command consistent with the other notification-only paths. Fixes: 33f72e6f0c67 ("l2tp : multicast notification to the registered listeners") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zihan Xi Reviewed-by: Simon Horman Link: https://patch.msgid.link/54f48e812ca0424c47ffdb9a8182180921f7e6b2.1787247008.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski commit a66734a1c5e36525ea07e9f4547fddc51e916de3 Author: Xiang Mei Date: Thu Aug 20 12:52:40 2026 -0700 net: qualcomm: rmnet: restore skb->dev on deaggregated frames rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt Fixes: 378e25357ac7 ("net: qualcomm: rmnet: Remove unnecessary device assignment") Reported-by: co+4638111fe2a12980@bugs.sh Closes: https://lore.kernel.org/netdev/ijg79FFMfIvKJbivdJEKvTO90Q9dTvyBkJck@bugs.sh/T/#u Signed-off-by: Xiang Mei Reviewed-by: Subash Abhinov Kasiviswanathan Link: https://patch.msgid.link/20260820195240.1631458-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski commit 0a90e8f4e268e7cabe6a355e76f0e199be3ee185 Merge: 403f96c32c9e24 11e41444a3f6d8 Author: Jakub Kicinski Date: Mon Aug 24 11:40:32 2026 -0700 Merge branch 'selftests-net-fixes-for-fin_ack_lat' Qingshuang Fu says: ==================== selftests/net: fixes for fin_ack_lat This series fixes two bugs in the fin_ack_lat self-test. Patch 1 fixes the swapped kill() arguments in sig_handler(), so the server actually forwards SIGTERM to the client. It also makes the wrapper script's cleanup tolerant of ESRCH, since the client may now exit before the kill command reaches its PID. Patch 2 adds a missing fork() error check: on failure the code falls into server()'s infinite accept loop, producing empty output that the wrapper script treats as a passing test. ==================== Link: https://patch.msgid.link/20260821030922.1123754-1-fffsqian@163.com Signed-off-by: Jakub Kicinski commit 11e41444a3f6d854937672343a040607c219db0f Author: Qingshuang Fu Date: Fri Aug 21 11:14:42 2026 +0800 selftests/net: check fork() return value in fin_ack_lat main() never checks fork() for failure. When fork() returns -1 (EAGAIN/ENOMEM/RLIMIT_NPROC), the !child_pid test is false and the process falls into server()'s infinite accept() loop with no client ever connecting, producing empty output. The wrapper script treats an empty log as a passing test, producing a false positive. Check fork() for failure with error(), as is done for every other syscall in this file. Signed-off-by: Qingshuang Fu Reviewed-by: Hangbin Liu Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821031442.1124777-2-fffsqian@163.com Signed-off-by: Jakub Kicinski commit 2d83aa65dc983368ce14f1a1daa05ca56d38ab5c Author: Qingshuang Fu Date: Fri Aug 21 11:14:41 2026 +0800 selftests/net: fix kill() argument order and wrapper cleanup in fin_ack_lat sig_handler() passes its arguments to kill() in the wrong order: it sends signal number child_pid to PID SIGTERM (15) instead of sending SIGTERM to the client process. The call therefore always fails and the signal is never forwarded: when only the server process receives SIGTERM, the client keeps running its infinite connect loop as an orphan process. Swap the arguments so that the server forwards SIGTERM to the client. Guard the call with child_pid > 0: the client inherits the handler and sees child_pid == 0, and a plain argument swap would make it call kill(0, SIGTERM), signaling the whole process group instead of exiting quietly. Now that the server actually terminates the client before the wrapper script's cleanup runs, kill() may fail with ESRCH for the already-exited client. The script uses set -e, so make the kill tolerant to avoid aborting the EXIT trap and leaking temporary files. Signed-off-by: Qingshuang Fu Reviewed-by: Hangbin Liu Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821031442.1124777-1-fffsqian@163.com Signed-off-by: Jakub Kicinski commit 403f96c32c9e24600093d7d0c61c17daeedca957 Author: Yuqi Xu Date: Fri Aug 21 11:19:38 2026 +0800 openvswitch: Fix CT limit teardown use-after-free Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state. An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down. Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists. Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization. The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace. Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit") Cc: stable@vger.kernel.org Reported-by: Vega Link: https://lore.kernel.org/all/cover.1784711445.git.xuyuqiabc@gmail.com Co-developed-by: Nan Li Signed-off-by: Nan Li Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/288fbd5459d92b9dd0dcc6faf625f04819161ff3.1787280296.git.xuyuqiabc@gmail.com Signed-off-by: Jakub Kicinski commit 2f43193b88188b184a967c9427602e019f1b8708 Merge: 918e25291ce95e 121f9fd1c30833 04a19b35dc0535 Author: Linus Torvalds Date: Mon Aug 24 11:35:46 2026 -0700 Merge tags 'dma-mapping-7.3-2026-08-24' and 'dma-mapping-7.3-2026-08-24-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux Pull dma-mapping updates from Marek Szyprowski: - swiotlb: - new configuration option for the default pool size (Jagadeesh Pagadala) - reduce overhead for high watermark tracking (chenhuguanshen) - minor code cleanups and improvements (Vova Sharaienko, Honglei Huang and Marek Szyprowski) - add proper tracking of the shared DMA state through direct, pool and swiotlb paths (Aneesh Kumar K.V) This is important for confidential-computing * tag 'dma-mapping-7.3-2026-08-24' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux: dma/swiotlb: decouple high watermark tracking from CONFIG_DEBUG_FS MAINTAINERS: update tree for DMA MAPPING HELPERS dma/swiotlb: introduce Kconfig option for compile-time default pool size dma-direct: Improve readability of the dma_direct_map_sg() for P2PDMA case iommu/dma: simplify dma_iova_destroy() and drop the free_iova helper dma-coherent: use KiB in DMA allocation logs dma-coherent: fix spacing coding style issue * tag 'dma-mapping-7.3-2026-08-24-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux: (23 commits) swiotlb: remove unused SWIOTLB_FORCE flag dma: swiotlb: handle set_memory_decrypted() failures dma: swiotlb: free dynamic pools from process context dma-direct: rename ret to cpu_addr in alloc helpers dma-direct: select DMA address encoding from __DMA_ATTR_ALLOC_CC_SHARED dma-direct: set decrypted flag for remapped DMA allocations dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED dma-direct: Move dma_direct_map_phys() to dma/direct.c dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks dma-mapping: make dma_pgprot() honor __DMA_ATTR_ALLOC_CC_SHARED dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED dma: swiotlb: pass mapping attributes by reference dma-pool: track decrypted atomic pools and select them via attrs dma-direct: use __DMA_ATTR_ALLOC_CC_SHARED in alloc/free paths dma-mapping: Add internal shared allocation attribute coco: arm64: s390: powerpc: Mark secure guests with CC_ATTR_GUEST_MEM_ENCRYPT dma-direct: swiotlb: handle swiotlb alloc/free outside __dma_direct_alloc_pages s390: Expose protected virtualization through cc_platform_has() swiotlb: Preserve allocation virtual address for dynamic pools dma: free atomic pool pages by physical address ... commit 3ba97ff4f873481d370bee7f7dfb87f8296af9be Author: Anshumali Gaur Date: Thu Aug 20 14:06:34 2026 +0530 octeontx2-vf: fix workqueue and netdev race in probe/remove Initialize the VF workqueue before register_netdev() so ndo_set_rx_mode does not queue work on a NULL workqueue. Unregister the netdev before destroying the workqueue, and add proper probe error cleanup. Fixes: cbc100aa2205 ("octeontx2-nicvf: add ndo_set_rx_mode support for multicast & promisc") Signed-off-by: Nitin Shetty J Signed-off-by: Anshumali Gaur Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260820083634.1641740-1-nshettyj@marvell.com Signed-off-by: Jakub Kicinski commit 4d5df98369c5f45710b786499f8bd7ffc3196433 Author: Anshumali Gaur Date: Thu Aug 20 11:24:51 2026 +0530 octeontx2-af: fix out-of-bounds read setting MSI-X irq affinity rvu_register_interrupts() walks every MSI-X vector and uses strstr() to match "Mbox" or "FLR" in irq_name before pinning those interrupts to CPU 0. irq_name is a per-vector NAME_SIZE buffer, but not every slot is populated before this loop runs. strstr() keeps scanning until it finds a NUL terminator, so an uninitialized slot can trigger a KASAN slab-out-of-bounds read at boot when debug options are enabled. Use strnstr() with NAME_SIZE to bound the search within each vector's name buffer. Fixes: 4e527f1e5c15 ("octeontx2-af: npc: cn20k: Add new mailboxes for CN20K silicon") Signed-off-by: Anshumali Gaur Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260820055451.2642358-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski commit ec65631bd5ec251cdf67a4919fac7a3149a6e235 Author: Anshumali Gaur Date: Thu Aug 20 10:33:33 2026 +0530 octeontx2-af: fix NULL deref in NIX TM tree debugfs read path rvu_dbg_nix_tm_tree_display() dereferences pfvf->sq_ctx without checking whether the SQ context has been allocated. Reading /sys/kernel/debug/octeontx2/nix/tm_tree for a NIX LF whose transmit queues are not set up triggers a kernel oops. Guard the read path the same way rvu_dbg_nix_tm_tree_write() already does and return -EINVAL with a seq_file message when sq_ctx is NULL. Fixes: b907194a5d5b ("octeontx2-af: Add debugfs support to dump NIX TM topology") Signed-off-by: Anshumali Gaur Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260820050333.2606095-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski commit d989e22ae9802c52c56ad4284d0caf26696cf6ae Author: Cen Zhang (Microsoft) Date: Wed Aug 19 22:07:35 2026 -0400 gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets(). Fixes: 459aa660eb1d8ce6 ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Xiang Mei (Microsoft) Reported-by: Cen Zhang (Microsoft) Signed-off-by: Cen Zhang (Microsoft) Link: https://patch.msgid.link/20260820020735.59474-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski commit 3e995a30b9e3812e61e50669d4ea4642d3362ef6 Merge: c0ef04232f9fac a6e4b9a6deb936 Author: Jakub Kicinski Date: Mon Aug 24 11:12:03 2026 -0700 Merge branch 'xsk-pre-existing-af_xdp-tx-metadata-fixes-from-sashiko' Stanislav Fomichev says: ==================== xsk: pre-existing AF_XDP TX metadata fixes from Sashiko A few fixes to address pre-existing issues from Sashiko review. Notes on the feedback from net-next v1 posting [0]: - It correctly complains about ABI breakage for 32 bit systems, added an explanation why I think we unlikely to have any 32 bit users with launch time - mlx5 batching (pre existing) - I think my point in the comment still stays (that we do not make it worse) 0: from https://netdev-ai.bots.linux.dev/sashiko/#/message/20260810184753.135756-1-sdf%40fomichev.me ==================== Link: https://patch.msgid.link/20260819160535.1472459-1-sdf@fomichev.me Signed-off-by: Jakub Kicinski commit a6e4b9a6deb9362ef7a0706c70d674e92fe1411a Author: Stanislav Fomichev Date: Wed Aug 19 09:05:34 2026 -0700 xsk: honor XDP_TX_METADATA in zero-copy path The zero-copy path reads TX metadata whenever the UMEM has metadata space, even if the descriptor does not set XDP_TX_METADATA. Pass descriptor options through the metadata helpers and ignore metadata unless the option is set. This does not fix the existing per-WQE metadata handling for mlx5 MPWQEs. Only the descriptor that starts a session passes through xsk_tx_metadata_request() and configures offload state shared by the batch. Metadata on descriptors joining an open session is therefore not validated and does not configure its requested offloads. In addition, a non-NULL metadata pointer from such a descriptor is treated as a timestamp completion request even when XDP_TXMD_FLAGS_TIMESTAMP is not set, so its metadata union can be overwritten with an unrequested timestamp. Fixing mixed metadata states within one MPWQE requires a separate change. Fixes: 48eb03dd2630 ("xsk: Add TX timestamp and TX checksum offload support") Reviewed-by: Alexander Lobakin Signed-off-by: Stanislav Fomichev Reviewed-by: Maciej Fijalkowski Reviewed-by: Aleksandr Loktionov Link: https://patch.msgid.link/20260819160535.1472459-3-sdf@fomichev.me Signed-off-by: Jakub Kicinski commit bd7d30bd1d3856d8354b5acef947d68ad1faf886 Author: Stanislav Fomichev Date: Wed Aug 19 09:05:33 2026 -0700 xsk: align TX metadata layout across ABIs Add explicit padding before launch_time so xsk_tx_metadata has the same layout on 32-bit and 64-bit systems. On several architectures (csky, i386, nios2, m65k, openrisc, sh), the old native 32-bit layout put launch_time at offset 12 and had a natural size of 20 bytes. Using sizeof(struct xsk_tx_metadata) as tx_metadata_len was already rejected because the length must be a multiple of eight, so the straightforward use of the interface was broken on those ABIs. Userspace could still register a padded length of 24 bytes, though; mixing the old and new layouts then silently reads launch_time from the wrong offset and misprograms packet launch times. This intentionally replaces that incompatible layout because the affected architectures are unlikely to have any notable users. (x86_64 and arm64 have the most users and are _not_ affected) Fixes: ca4419f15abd ("xsk: Add launch time hardware offload support to XDP Tx metadata") Reviewed-by: Simon Horman Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20260819160535.1472459-2-sdf@fomichev.me Signed-off-by: Jakub Kicinski commit c0ef04232f9fac083c3d8a77ce58ba32243e6734 Author: Shiji Yang Date: Wed Aug 19 21:07:07 2026 +0800 net: ethernet: mtk_wed: increase WED v2 WDMA RESV_BUFF to 0x80 Change WDMA RESV_BUFF from 0x40 to 0x80 to avoid CDM TX FIFO overflow. Without this patch mt7986 and mt7981 may have WDMA TX hang issue. This patch was pulled from mtk-openwrt-feeds GPL open source project. Link: https://github.com/mediatek/mtk-openwrt-feeds/commit/07c87502e854b68b48544d101b6fe17ec059b97b Signed-off-by: Shiji Yang Reviewed-by: Simon Horman Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/OSZPR01MB779537889255E2F606E47EABBCA52@OSZPR01MB7795.jpnprd01.prod.outlook.com Signed-off-by: Jakub Kicinski commit 918e25291ce95ef26c288234b088e9d433ecd94e Merge: a0300e8cf0ed68 564ed40708ebc6 Author: Linus Torvalds Date: Mon Aug 24 10:58:57 2026 -0700 Merge tag 'slab-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab Pull slab updates from Vlastimil Babka: - Add kfree_rcu_nolock() that can be used from contexts where spinning on a lock might be unsafe, such as a BPF program attached to an arbitrary function, or in NMI context. This complements the existing kfree_nolock() support (Harry Yoo) - Runtime instead of compile-time slabobj_ext sizing. Avoid wasting memory when memory allocation profiling is compiled but not enabled, with initial partial support to also avoid wasting memory for objcg pointers when those are not needed, while profiling is enabled (Vlastimil Babka) - Various non-urgent fixes, cleanups and optimizations (Hao Li, Hongling Zeng, Li RongQing, Li Xiasong, Seongjun Hong, Shengming Hu) * tag 'slab-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab: (31 commits) mm/slab, kfence, memcg: completely remove obj_ext for kfence objects mm/slab: stop allocating objcg pointers when unnecessary mm/slab: add cache_ and slab_needs_objcg() helpers mm/slab: stop exporting kvfree_rcu_barrier[_on_cache]() slub_kunit: extend the test for kfree_rcu_nolock() mm/slab: introduce kfree_rcu_nolock() mm/slab: introduce struct kvfree_rcu_head for kvfree_rcu batching mm/slab: reduce slabobj_ext memory with allocation profiling disabled mm/slab: introduce slab_obj_ext_has_codetag() mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT mm/slab: extend deferred free mechanism to handle rcu sheaves mm/slab: use call_rcu() in unknown context if irqs are enabled mm/slab: handle the !allow_spin case in kfree_rcu_sheaf() mm/slab: change struct slabobj_ext to a union mm/slab: replace slab.stride with obj_exts_in_object mm/slab: abstract slabobj_ext.ref access mm/slab: abstract slabobj_ext.objcg access mm/slab: make slab_obj_ext() determine object index mm: move struct slabobj_ext to mm/slab.h mm/slab: remove objs_per_slab() ... commit a0300e8cf0ed685851232973ccadbf62681f7f6d Merge: 5b05bb3f6c5716 41a9c2b48e258e Author: Linus Torvalds Date: Mon Aug 24 10:51:49 2026 -0700 Merge tag 'configfs-for-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/linux Pull configfs update from Andreas Hindborg: "Update configfs MAINTAINERS entry. Breno Leitao will maintain configfs C code going forward. I will continue maintaining configfs Rust parts" * tag 'configfs-for-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/linux: MAINTAINERS: configfs: split configfs entry in C and Rust parts commit cf9c8aaea0d47410df8708bec195889f3a85cd3c Author: Yao Kai Date: Mon Aug 24 11:58:52 2026 +0800 workqueue: Fix unbound pool lifetime for pending pwqs KASAN reports a use-after-free of an unbound worker_pool in node_activate_pending_pwq(): BUG: KASAN: slab-use-after-free in _raw_spin_trylock+0x6d/0x120 Read of size 4 at addr ffff8880089ce000 by task kworker/u22:0/318 CPU: 1 UID: 0 PID: 318 Comm: kworker/u22:0 Not tainted 7.2.0 #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: 0x0 (flush-8:0) Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x610 kasan_report+0xce/0x100 _raw_spin_trylock+0x6d/0x120 pwq_dec_nr_in_flight+0x4b4/0xcb0 process_one_work+0x921/0x11a0 worker_thread+0x4d0/0xd20 kthread+0x2de/0x3c0 ret_from_fork+0x3aa/0x620 ret_from_fork_asm+0x1a/0x30 Allocated by task 311: alloc_pwq+0x439/0xca0 apply_wqattrs_prepare+0x75e/0xd10 apply_workqueue_attrs_locked+0x44/0xa0 wq_nice_store+0x350/0x450 Freed by task 0: kfree+0x127/0x3b0 rcu_core+0x523/0x1780 handle_softirqs+0x1b3/0x610 Last potentially related work creation: put_unbound_pool+0x3f3/0x7d0 pwq_release_workfn+0x494/0x8e0 kthread_worker_fn+0x1ff/0x790 Canceling the last inactive work skips pwq_dec_nr_active(), so an empty pwq can remain on pending_pwqs when its refcnt reaches zero. pwq_release_workfn() currently puts the pool before removing that pwq. If this drops the last pool reference, the pool can be RCU-freed while the pwq remains reachable, and node_activate_pending_pwq() may trylock the freed pool->lock. Remove the pwq from pending_pwqs before putting the pool. Fixes: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues") Cc: stable@vger.kernel.org Signed-off-by: Yao Kai Signed-off-by: Tejun Heo commit 5b05bb3f6c5716fab6911e12d60dd1f43ad9806a Merge: 8bfab832ad6905 54745d563114b7 Author: Linus Torvalds Date: Mon Aug 24 10:16:35 2026 -0700 Merge tag 'platform-drivers-x86-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver updates from Ilpo Järvinen "Highlights: Major refactoring effort: stop setting acpi_device_name/class() and pnp.device_class to facilitate their eventual removal Many rollback/remove path fixes (presumably mostly found by AI) Miscellaneous cleanups / refactoring / improvements amd/halo: - Add Halo RGB LED driver amd/hsmp: - Properly serialize probe, remove, and data paths - Add support for protocol v7 used by Family 1AH Model 80H - Fix error checking corner cases (largely from AI review) - Reject negative power cap amd/pmc: - Improve behavior on platforms that do not support STB - Add T14 Gen2 AMD (20XL) to s2idle quirk list amd/pmf: - Add ioctl interface to retrieve device metrics - Add support for new metrics tables used by Family 1AH Model 80H qcom-hamoa-ec (arm64): - Reject short responses asus-nb-wmi: - Support ProArt key on ASUS ProArt PX13 asus-armoury: - Gate PPT writes behind active fan curve - Add power limits for more models dell-wmi-base: - Fix handling of ultra performance key dell-wmi-sysman: - Don't hex dump attribute security buffer hp-bioscfg: - Various fixes - Improve reduced ACPI packages support (necessary for HP EliteBook 840 G2) lg-laptop: - Fix LED resource handling - Add support for events used in newer models - Fix keyboard backlight support on LG Gram 16T90SP hp-wmi: - Generalize thermal params to board params - Manage CPU and GPU PWM independently - Add GPU MUX switch support - Add Victus 15-fb0xxx support - Add OMEN MAX 16-ak0xxx, OMEN 16-n0xxx, OMEN 16-wd0xxx, OMEN 16-wf0xxx, and OMEN board ID 8D88 support - Add OMEN Transcend 16-u0xxx support huawei: - Add support for Fn-lock ACPI interface found on newer Huawei laptops such as MateBook 14 2024 ISST: - Improve input validation (many fixes) - Disallow SST-CP (core-power) feature if perf profile add fails lenovo/yb9-kbdock: - Add driver for Yoga Book 9 14IAH10 lenovo/ymc: - Extend hinge switch query to support Yoga 9 2-in-1 14IPH11 - Prevent loading on Yoga Book 9 14IAH10 to avoid duplicated input nodes msi-ec: - Add MSI Raider A18 HX A9WJG and MSI Katana GF76 11UEK support msi-wmi: - Add MSI Claw M-Center keys support oxpec: - Add support for OneXPlayer X2 Mini Pro redmi-wmi: - Report kbd backlight cycle, OEM preset power mode, and FnLock toggle events to userspace samsung-galaxybook: - Add Samsung Galaxy Book6 Pro support thinkpad_acpi: - Add USB-C Security support uniwill-laptop: - Add keyboard backlight, AC auto boot, and USB powershare support - Add MACHENIKE L16 Pro, AiStone X4SP4NAL, and Avell A60 MUV support - Make lightbar max brightness configurable and add support for LAPQC71A/B" * tag 'platform-drivers-x86-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (152 commits) platform/x86: think-lmi: Fix current password length check platform/x86: redmi-wmi: report EC state change events MAINTAINERS: update Intel PMC Core maintainer contact platform/x86: oxpec: Add support for OneXPlayer X2 Mini Pro platform/x86: thinkpad_acpi: Fix fan speed reporting on Edge E330 platform/x86: msi-ec: Add MSI Katana GF76 11UEK EC firmware platform/x86: think-lmi: Fix certificate thumbprint sysfs output mlxbf-bootctl: fix the build error with FIELD_PREP() platform/x86: think-lmi: Free system certificate signatures platform/x86: ISST: Add a NULL check for sst_inst[] platform/x86: ISST: Return error during profile addition platform/x86: ISST: Just allow 2 bits for SST feature enable platform/x86: ISST: Use PP level enable mask platform/x86: ISST: Validate parameter for frequency and priority platform/x86: ISST: Validate parameter for core power state platform/x86: ISST: Validate max level for set feature platform/x86: ISST: Validate logical CPU id and clos id platform/x86: ISST: Validate level in perf mask ioctls platform/x86: ISST: Validate socket ID in clos_assoc ioctl platform/x86/amd/hsmp: Reject negative power cap writes in hwmon ... commit ebe6674292fda9a58e6f3adffd6d277560857169 Author: Chengfeng Ye Date: Sat Aug 22 23:06:19 2026 +0800 Bluetooth: RFCOMM: serialize session teardown rfcomm_kill_listener() walks session_list and deletes every session without holding rfcomm_mutex, unlike the normal session processing and connect error paths. Under normal operation, an open RFCOMM socket pins rfcomm.ko, so rfcomm_kill_listener() does not run concurrently with rfcomm_dlc_open(). However, forced module unload via delete_module(O_TRUNC) can stop krfcommd while a failed connect is still unwinding. connect task forced unload / krfcommd ------------ ------------------------ rfcomm_lock() rfcomm_session_add() delete_module("rfcomm", O_TRUNC) rfcomm_kill_listener() fetch session from session_list kernel_connect() fails rfcomm_session_del() remove and free session rfcomm_session_del(session) The final call then reads the freed session and may corrupt the list. KASAN reported with mdelay() to enlarge critical window: BUG: KASAN: slab-use-after-free in rfcomm_run+0x3802/0x3f00 [rfcomm] Read of size 8 at addr ffff888111058d40 by task krfcommd/79 Tainted: [R]=FORCED_RMMOD Allocated by task 86: rfcomm_session_add+0xa1/0x300 [rfcomm] rfcomm_dlc_open+0x8b2/0xf30 [rfcomm] rfcomm_sock_connect+0x34c/0x530 [rfcomm] Freed by task 86: kfree+0x121/0x3c0 rfcomm_dlc_open+0xab7/0xf30 [rfcomm] rfcomm_sock_connect+0x34c/0x530 [rfcomm] Hold rfcomm_mutex across the teardown traversal so every reachable session_list walk uses the same serialization. Reviewed-by: Ali Ahmet Memis Tested-by: Ali Ahmet Memis Reviewed-by: Pauli Virtanen Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz commit 7e1e4047200fd7519f9bdfe8a001437715e618b4 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 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 commit 759c185d0bbdb131357408f50b8735e04ed3caff Author: Chengfeng Ye Date: Sun Aug 23 00:43:41 2026 +0800 Bluetooth: RFCOMM: serialize security confirmation handling rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink() rfcomm_session_del() kfree(s) rfcomm_unlock() walk s->dlcs The callback can then read a freed session list head and touch freed DLCs while updating their flags or timers. Serialize the session lookup and DLC traversal in rfcomm_security_cfm() with rfcomm_mutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink() from tearing the objects down while the callback is using them. KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hci_rx_work Call Trace: rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 69: rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0 Fixes: 08c30aca9e698faddebd34f81e1196295f9dc063 ("Bluetooth: Remove RFCOMM session refcnt") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz commit ca0583c24661749508a0979189c254388a685559 Author: Junjie Cao Date: Mon Aug 24 13:32:27 2026 +0800 Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN quirk to 0bda:a728 Commit 5ead2063611a ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan") set HCI_QUIRK_BROKEN_EXT_SCAN for every CHIP_ID_8761B device to cure repeated 0x2042 failures on an 0bda:a728 dongle. The brokenness is per-dongle, not per-chip: on a TP-Link UB500 (2357:0604, RTL8761BU, fw 0xdfc6d922) extended scan works, and the legacy scan path the quirk forces is what is broken -- LE Set Scan Enable (0x200c) times out with -110 about 30 s after firmware load, btusb resets the device, and the adapter re-enumerates in an endless loop (382 firmware reloads in one boot). 7.1.8, which predates the stable backport, runs clean on this unit; 7.1.9 loops. Move the quirk from btrtl's chip-wide switch to a btusb device-table flag on the USB id the original fix was verified against. Other 8761B dongles return to their earlier long-standing behaviour. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2521504 Fixes: 5ead2063611a ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan") Cc: stable@vger.kernel.org Signed-off-by: Junjie Cao Signed-off-by: Luiz Augusto von Dentz commit a9355799343e10014f2acfd4b6844d2335ecafea Author: Gongwei Li Date: Fri Aug 21 10:45:55 2026 +0800 Bluetooth: hci_uart: Fix false success return in hci_uart_setup() When reading the local version information for vendor detection fails, the error is only printed and 0 is returned, which masks the setup failure from the HCI core. Return PTR_ERR(skb) instead. Fixes: fb2ce8d11f039 ("Bluetooth: hci_uart: Add support for vendor detection flag") Fixes: 82f5169bf3d3b ("Bluetooth: hci_uart: add serdev driver support library") Cc: stable@vger.kernel.org Signed-off-by: Gongwei Li Signed-off-by: Luiz Augusto von Dentz commit 44c98fd082eafd49d55a8a4077ff488175b2fe24 Author: Hyunwoo Kim Date: Fri Mar 20 00:14:58 2026 +0900 Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Hyunwoo Kim Signed-off-by: Luiz Augusto von Dentz commit 560bef609fa5992745929e8d7d458b9d88dd2830 Author: Hang Nan <2122295973@qq.com> Date: Wed Aug 19 08:57:58 2026 +0800 Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready iso_conn_ready() looks up the BIS listener socket with iso_get_sock(), which takes a reference, and then, without re-checking its state, creates a child socket from it: parent = iso_get_sock(hdev, ...); if (!parent) return; lock_sock(parent); sk = iso_sock_alloc(sock_net(parent), NULL, BTPROTO_ISO, ...); ... iso_chan_add(conn, sk, parent); ... release_sock(parent); sock_put(parent); If the listener socket is closed concurrently, between iso_get_sock() and lock_sock(), the reference taken by iso_get_sock() may be the last one: the close path drops the link-list reference, and once iso_conn_ready() drops its own reference at the end of the function the socket is freed. The child socket, however, is already linked to the freed parent, and a later disconnect of the child runs iso_chan_del() -> bt_accept_unlink(), which dereferences the dangling parent pointer into the freed accept queue (a use-after-free). The same dangling pointer is also dereferenced through parent->***() in iso_chan_del(). Fix it the same way the connected (non-BIS) path was fixed in commit 0d255e63fcf3 ("Bluetooth: ISO: hold sk properly in iso_conn_ready"): after taking the socket lock, re-check that the parent is still a listening, alive socket, and bail out otherwise. Fixes: ccf74f2390d60 ("Bluetooth: Add BTPROTO_ISO socket type") Cc: stable@vger.kernel.org Signed-off-by: Hang Nan <2122295973@qq.com> Signed-off-by: Luiz Augusto von Dentz commit 94509f50d696bff745fe26457ce421cea8525bee Author: Guilherme G. Piccoli Date: Wed Aug 19 15:31:30 2026 -0300 docs: panic: Disclaimer about console verbosity when using panic_print with pstore Users of panic_print / panic_sys_info are usually aware of the potentially huge amount of information displayed with such options - their goal by using them is indeed to dump more information during panic! What might come unnoticed at first is the impact that the console_verbose() call on panic path has, specially in cases that users rely on pstore as a means to collect the panic logs. Recent experience shows that dumping all tasks in an ARM64 system (with qcom_geni tty driver) gets a 2 minute delay on panic time due to writing such information to console. But in that case, pstore was used, so there was no need for console printing, and suppressing that reduced the full time to less than 0.5 second. The option "printk.console_no_auto_verbose" aims exactly at this use case: avoid automatically increasing the loglevel during panic path. So, let's officially document this to avoid users wasting their time either on long panic printing or debugging the panic delays. While at it, improve the readability of the panic_print text, by adding some line breaks. Suggested-by: Petr Mladek Reviewed-by: Bradley Morgan Reviewed-by: Feng Tang Signed-off-by: Guilherme G. Piccoli Reviewed-by: Petr Mladek Signed-off-by: Jonathan Corbet Message-ID: <20260819183419.2203903-1-gpiccoli@igalia.com> commit f5afdff569a09d1cb8cf19826199d024725576cb Author: Xin Chen Date: Wed Aug 19 21:53:21 2026 +0800 Bluetooth: hci_core: use skb_get() instead of skb_clone() for req_skb BT enable fails intermittently with -ETIMEDOUT (-110). The kernel log shows the HCI Read Local Version command was sent and the firmware replied with status 0x00 (logged by hci_req_cmd_complete() BT_DBG), but the waiter in __hci_cmd_sync_sk() never woke up and timed out after 10 s: bluetooth hci0: Opcode 0xfc00 // __hci_cmd_sync_sk bluetooth hci0: opcode 0xfc00 plen 1 // hci_cmd_sync_add bluetooth hci0: skb len 4 // hci_cmd_sync_alloc bluetooth hci0: length 1 // hci_req_sync_run Bluetooth: hci0 cmd_cnt 1 cmd queued 1 // hci_cmd_work Bluetooth: hci0 type 1 len 4 // hci_send_frame Bluetooth: opcode 0xfc00 status 0x00 // hci_req_cmd_complete <-- req_skb NULL: req_complete_skb not set, hci_cmd_sync_complete() never called, req_status stays HCI_REQ_PEND --> <-- 10 s later: wait_event_interruptible_timeout expires --> bluetooth hci0: end: err -110 // __hci_cmd_sync_sk The root cause is that hci_send_cmd_sync() clones the sent command into hdev->req_skb so that hci_req_cmd_complete() can locate the registered completion callback. Under memory pressure this skb_clone() fails, leaving hdev->req_skb NULL. The firmware reply is received and processed, but hci_req_cmd_complete() finds NULL req_skb, so hci_cmd_sync_complete() is never called, req_status stays HCI_REQ_PEND, and the waiter times out with -ETIMEDOUT. req_skb is only used to read bt_cb(skb)->hci callbacks and opcode -- it is never modified. Replace skb_clone() with skb_get(), which simply increments the reference count of hdev->sent_cmd without allocating new memory and therefore cannot fail. This issue was first observed as a use-after-free in ttyport_close() when ttyport_open() failed, which was investigated in an earlier patch series [1]. That investigation led to the discovery of the true root cause described above. [1] https://lore.kernel.org/all/20250430111617.1151390-1-quic_cxin@quicinc.com/ Fixes: 2615fd9a7c25 ("Bluetooth: hci_sync: Fix overwriting request callback") Cc: stable@vger.kernel.org Signed-off-by: Xin Chen Signed-off-by: Luiz Augusto von Dentz commit 941929abe5feaed672b9a52e330e547d333240c6 Author: Valentin Kindschi Date: Tue Aug 18 15:29:35 2026 +0200 Bluetooth: hci_event: clear HCI_LE_ADV only on a created connection le_conn_complete_evt() clears HCI_LE_ADV before looking at the event status, on the premise stated in its comment that all controllers stop advertising when a connection is created. That premise only holds when a connection was actually created. On a non-zero status none was, and the controller is still advertising: after the host issues LE Create Connection Cancel the event arrives with Unknown Connection Identifier (0x02), and a connection timeout behaves the same way. Clearing the flag there leaves the host believing advertising is off while the controller has it on. It is also wrong for extended advertising, where several sets can be advertising at once. hci_cc_le_set_ext_adv_enable() is careful about this - on disabling one set it walks hdev->adv_instances and only clears HCI_LE_ADV once no instance is still enabled. The unconditional clear here discards that bookkeeping, so one set connecting drops the flag while the others keep advertising. The direction of the error matters. A flag left set is self-correcting: hci_disable_advertising_sync() sends LE Set Advertising Enable(0) and the command complete puts the state back. A flag left clear is not, because that same function returns early without sending anything while the flag is clear: - LE Set Advertising Parameters is then sent to a controller that is still advertising, and is correctly rejected with Command Disallowed (0x0c); - hci_enable_advertising_sync() returns at that point, before the LE Set Advertising Enable that would set HCI_LE_ADV again. On a controller without LE Extended Advertising that is reachable from here: hci_schedule_adv_instance_sync() re-arms adv_instance_expire every HCI_DEFAULT_ADV_DURATION (2 s) and its "already advertising" shortcut tests HCI_LE_ADV, which can no longer become true, so the parameter write is retried for as long as advertising is configured: Bluetooth: hci0: Opcode 0x2006 failed: -16 Only clear the flag when a connection was established. Note this is not on its own sufficient to stop that retry loop - the redundant enable queued by hci_le_conn_failed() clears HCI_LE_ADV itself and recreates the same mismatch, which patch 1 addresses. This patch fixes the event handler reporting a state the controller is not in. Verified on the affected device (BCM43455, legacy advertising only) with this patch and patch 1 applied. A 221 s btmon capture with an out-of-range peer at -90 dBm contains two outgoing connection attempts that the host cancelled, each producing exactly the event this patch changes: < LE Set Advertising Parameters 0x2006 Success < LE Set Advertising Enable 0x200a Success < LE Create Connection Cancel 0x200e Success > LE Connection Complete Unknown Connection Identifier (0x02), central Nothing follows either one; the next command is an unrelated scan restart 70 ms later. Over the whole capture: 7 LE Set Advertising Parameters sent, all Success; 10 LE Set Advertising Enable, all Success; no Command Disallowed of any opcode, and no 2 s cadence anywhere. Two central connections to other peers completed normally afterwards, with feature exchange and a connection parameter update, so advertising was still live across the cancelled attempts. The extended advertising case above is a code argument, not a measurement: this controller has no LE Extended Advertising, so that path is not exercised by the capture. Fixes: fbd96c151cdc ("Bluetooth: Fix clearing HCI_LE_ADV for LE connections") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 btmon Signed-off-by: Valentin Kindschi Signed-off-by: Luiz Augusto von Dentz commit ed5fb41d3b6b6e665e7f97fd54bd1f9531c7477f Author: Valentin Kindschi Date: Tue Aug 18 15:29:34 2026 +0200 Bluetooth: hci_conn: re-enable advertising only for peripheral role hci_le_conn_failed() unconditionally calls hci_enable_advertising(), although its own comment states advertising should be re-enabled only when the failed attempt was made as a peripheral. hci_le_conn_failed() is reached from hci_conn_failed() for every failed LE connection, including outgoing central connections. For a central attempt this enable is redundant: hci_le_create_conn_sync() already restores advertising via hci_resume_advertising_sync() in its done: block. Because hci_enable_advertising() only queues the work on cmd_sync_work, it runs *after* that resume has already succeeded and set HCI_LE_ADV. The resulting HCI sequence, captured on a BCM43455 (no LE Extended Advertising, so legacy advertising is used): LE Create Connection Status Success ... 13.8 s, peer never answers ... LE Set Advertising Parameters (0x2006) Success <- done: resume, LE Set Advertising Enable (0x200a) Success HCI_LE_ADV set LE Create Connection Cancel (0x200e) Success LE Connection Complete Unknown Conn Id LE Set Advertising Parameters (0x2006) Command Disallowed (0x0c) The last command is the queued enable from hci_le_conn_failed() running as a second hci_enable_advertising_sync() pass. It clears HCI_LE_ADV (hci_sync.c, "Clear the HCI_LE_ADV bit temporarily"), then sends LE Set Advertising Parameters while the controller is still advertising, which the controller correctly rejects with Command Disallowed. The disable-first call at the top of hci_enable_advertising_sync() cannot prevent this: hci_disable_advertising_sync() returns early without sending anything when HCI_LE_ADV is clear, so it is a no-op exactly when the flag is wrong. hci_enable_advertising_sync() then returns without sending LE Set Advertising Enable, so HCI_LE_ADV is never set again. The legacy software rotation loop re-arms hci_schedule_adv_instance_sync() every HCI_DEFAULT_ADV_DURATION (2 s), and its "already advertising" shortcut tests HCI_LE_ADV, which can no longer become true. The command is therefore retried every 2 s indefinitely: Bluetooth: hci0: Opcode 0x2006 failed: -16 Observed on a gateway as 5326 occurrences over 3 hours, ending only when bluetoothd was restarted. Connection attempts that succeed do not call hci_le_conn_failed() and never trigger this. Add the role test the comment already describes. Both other hci_enable_advertising() call sites reached from a failed/closed LE connection (hci_cs_disconnect() and hci_disconn_complete_evt()) already guard on conn->role == HCI_ROLE_SLAVE; this one was missed. Reproducing needs legacy advertising (ext_adv_capable() false, so the software rotation loop is used), simultaneous peripheral advertising and outgoing central connects, and a central connect that times out rather than failing fast. The Fixes tag points at the commit that introduced the advertising restart into this path for the directed-advertising (peripheral) case; the role test that the later commit 0b1db38ca26b ("Bluetooth: Fix check for direct advertising") added to the sibling paths was never applied here. Fixes: 3c857757ef6e ("Bluetooth: Add directed advertising support through connect()") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 btmon Signed-off-by: Valentin Kindschi Signed-off-by: Luiz Augusto von Dentz commit aec6a8d80e3da0ab5c9303a0281fd06d077f8716 Author: Lorenzo Stoakes (ARM) Date: Tue Aug 18 10:49:34 2026 +0100 Bluetooth: hci_bcm4377: Ignore reserved PHY in ext adv reports on BCM4378 Commit ed2a2ef16a6b ("Bluetooth: Add quirk to ignore reserved PHY bits in LE Extended Adv Report") added a quirk to handle creative use of the reserved bits in the PHY fields for 4388 controllers in Apple silicon. I observed the same issue with the BCM4378 Bluetooth controller (14e4:5f69, rev 05) on an Apple MacBook Pro (13-inch, M2, 2022): > HCI Event: LE Meta Event (0x3e) plen 51 LE Extended Advertising Report (0x0d) Num reports: 1 Entry 0 Event type: 0x2513 Props: 0x0013 Connectable Scannable Use legacy advertising PDUs Data status: Complete Reserved (0x2500) Legacy PDU Type: Reserved (0x2513) Address type: Random (0x01) Address: EA:C1:82:F0:24:C6 (Static) Primary PHY: Reserved Secondary PHY: No packets SID: no ADI field (0xff) TX power: 127 dBm RSSI: -57 dBm (0xc7) Periodic advertising interval: 0.00 msec (0x0000) Direct address type: Public (0x00) Direct address: 00:00:00:00:00:00 (OUI 00-00-00) Data length: 25 This results in the firmware rejecting connection attempts with "Unsupported Feature or Parameter Value" (0x11). Fix the issue by using the same quirk for BCM4378 devices too. I tested this locally and confirmed that the issue is resolved. This was observed when attempting to connect a Kinesis Advantage 360 keyboard to the MacBook. Assisted-by: Claude:claude-fable-5 Fixes: 2e7ed5f5e69b ("Bluetooth: hci_sync: Use advertised PHYs on hci_le_ext_create_conn_sync") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Sven Peter Signed-off-by: Luiz Augusto von Dentz commit 4beb198bc59b242404a47c21990bc84165052c8a Author: HyeongJun An Date: Sat Aug 15 15:24:19 2026 +0900 Bluetooth: eir: Fix OOB read in eir_get_service_data() eir_get_service_data() walks the advertising data for a Service Data field with a matching UUID. On a mismatch it advances: eir += dlen; eir_len -= dlen; eir_get_data() reports dlen as the field's data length, but the field spans dlen + 2 bytes once its length and type bytes count, and more when non-Service-Data fields were skipped to reach it. The pointer lands correctly on the next field. eir_len does not, and the shortfall compounds across fields until eir_get_data() reads the length and type bytes of a "field" past the end of the buffer. For an ISO broadcast sink that buffer is hcon->le_per_adv_data[], filled from the periodic advertising reports of a remote broadcaster. A PA payload packed with mismatching Service Data fields walks off the array into the rest of struct hci_conn. A drifted field that matches the BAA UUID puts those bytes in iso_pi(sk)->base, where user space reads them back with getsockopt(BT_ISO_BASE). Recompute eir_len from the end of the buffer each iteration. Fixes: 8f9ae5b3ae80 ("Bluetooth: eir: Add helpers for managing service data") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Signed-off-by: Luiz Augusto von Dentz commit 060fa7592bdc043a93b6b7870f5b8551206d315d Author: Ali Ahmet Memis Date: Fri Aug 14 18:28:48 2026 +0000 Bluetooth: btnxpuart: Validate the FW dump header length nxp_process_fw_dump() pulls the ACL header off the frame and then reads seq_num and buf_len from a struct nxp_fw_dump_hdr placed at skb->data, without checking that the ACL payload is long enough to contain it. h4_recv_buf() collects HCI_ACL_HDR_SIZE bytes of header followed by the number of payload bytes named in that header, so skb->len is 4 + dlen with dlen supplied by the controller and possibly smaller than the 8 byte dump header, or zero. A short frame with connection handle 0xfff therefore reads both fields from beyond the received data. Beyond the read itself, buf_len is what terminates a dump: a value of zero makes the driver call hci_devcd_complete() and reset the controller, so a truncated frame can end a dump early. Use skb_pull_data() to validate and pull the FW dump header before accessing its fields. Warn and reject the chunk if the header is truncated. Fixes: 998e447f443f ("Bluetooth: btnxpuart: Add support for HCI coredump feature") Signed-off-by: Ali Ahmet Memis Signed-off-by: Luiz Augusto von Dentz commit e5bbf81def17930d0450ecf174a439eb07a09d46 Author: Randy Dunlap Date: Sat Aug 15 10:29:34 2026 -0700 docs: kernel-parameters: add CPU_FREQ, CPU_IDLE build options CPU_FREQ and CPU_IDLE are used in descriptions of some kernel parameters so add their descriptions to the build options list. Signed-off-by: Randy Dunlap Acked-by: Rafael J. Wysocki (Intel) Signed-off-by: Jonathan Corbet Message-ID: <20260815172934.3604009-1-rdunlap@infradead.org> commit 5b9b68abb5fa548478e20ee38a0ef5c18e9cf4b7 Author: Pauli Virtanen Date: Sun Aug 16 11:59:01 2026 +0300 Bluetooth: hci_sync: add conditional locking annotations Add context analysis annotations to functions doing conditional locking, to suppress analysis warnings. Fixes: cdc36db204ff ("Bluetooth: hci_sync: Fix advertising data UAFs") Tested-by: Nathan Chancellor # build Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz commit 3b8f8d632381fdeb4c4f54fd516d49d4f513b9aa Author: Sherry Sun Date: Mon Aug 17 10:27:39 2026 +0800 Bluetooth: btnxpuart: Check remote M.2 connector availability before pwrseq The current code uses of_graph_is_present() to decide whether to enter the pwrseq path. However, of_graph_is_present() only checks for the structural presence of a port/ports sub-node and does not check the status property. This causes problems when a DT overlay disables the remote M.2 connector node (e.g., switching from PCIe WiFi to SDIO WiFi): the port node still exists, so of_graph_is_present() returns true, but the pwrseq provider never registers because the connector is disabled, leading to an infinite -EPROBE_DEFER loop. Replace of_graph_is_present() with a new helper that traverses the OF graph to the remote port parent (the M.2 connector node) and checks of_device_is_available(). When the remote connector is disabled, the pwrseq path is skipped, allowing the BT driver to fall through to the direct bluetooth child node path. Fixes: e48e332d84d8 ("Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq") Signed-off-by: Sherry Sun Signed-off-by: Luiz Augusto von Dentz commit fa0ad2d277c7adead61d1c22411c55cea6990c2a Author: Chris Lu Date: Mon Aug 17 17:53:32 2026 +0800 Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: err = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which "Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX" ensures. Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Signed-off-by: Chris Lu Assisted-by: Claude:claude-opus-5 Signed-off-by: Luiz Augusto von Dentz commit 155e3003d1e614f85566b636973df7118e1b4851 Author: Chris Lu Date: Mon Aug 17 17:53:31 2026 +0800 Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX btmtksdio_tx_packet() prepends the MediaTek SDIO header with skb_push() and writes into that space after only checking the headroom size. On a cloned SKB that headroom belongs to a buffer shared with the other owner, which the driver has no right to write to. Cloned SKBs do reach this path: hci_send_cmd_sync() keeps a clone of every HCI command in hdev->sent_cmd before handing the SKB to the driver, and l2cap_ertm_send() clones SKBs for retransmission. Replace the open-coded headroom check with skb_cow_head(), which both guarantees the headroom and reallocates a private buffer when the SKB is cloned. The cost is one reallocation and copy per cloned packet, the usual price of this pattern in network drivers. This has no observable effect on its own, as the driver only writes in front of skb->data where no other owner looks. It is a prerequisite for "Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path", which writes padding behind skb->tail, and carries the same Fixes: tag so that both are backported together. Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Signed-off-by: Chris Lu Assisted-by: Claude:claude-opus-5 Signed-off-by: Luiz Augusto von Dentz commit 21b50c24843b51f88ac4316dd470d2803da0c42f Author: Ismail Tarim Date: Sat Aug 15 14:56:24 2026 +0300 Bluetooth: btmtk: Do not discard the subsystem reset timeout When the MTK_BT_RST_DONE poll times out, btmtk_usb_subsys_reset() logs "Reset timeout" and keeps the error in err, but err is then overwritten by the return value of the following btmtk_usb_id_get() call, so the timeout is never reported to the caller. Commit 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work") discarded the return value of the chip id read, so the function returned the timeout error as intended. Commit 3dcb122b3064 ("Bluetooth: btusb: mediatek: return error for failed reg access") started assigning err at that call and silently dropped it. Keep the timeout in a separate variable and return it, restoring the original behaviour without changing the control flow. Fixes: 3dcb122b3064 ("Bluetooth: btusb: mediatek: return error for failed reg access") Signed-off-by: Ismail Tarim Signed-off-by: Luiz Augusto von Dentz commit 59c3ee19ca88210bfc0e22ce59218091cb1a3c48 Author: Ismail Tarim Date: Sat Aug 15 14:56:23 2026 +0300 Bluetooth: btmtk: Do not report success when subsys reset fails btmtk_usb_subsys_reset() validates the subsystem reset by reading the chip id back. When that read succeeds at the bus level but yields an id of zero, the reset has demonstrably not taken effect: the function logs "Can't get device id, subsys reset fail." and then returns the return value of btmtk_usb_id_get(), which in that case is zero, i.e. success. btusb_mtk_reset() returns that value unchanged, so its caller cannot tell a completed reset from a failed one. Return -ENODEV when the chip id reads back as zero, leaving the existing MT6639 exemption intact. Observed on an MT7902 [13d3:3579]. The path can be reached on demand by asking the controller for a coredump, since btmtk requests a reset once the dump completes: # echo 1 > /sys/class/bluetooth/hci0/device/coredump Bluetooth: hci0: Mediatek coredump end Bluetooth: hci0: Can't get device id, subsys reset fail. usb 3-10: reset high-speed USB device number 5 using xhci_hcd usb 3-10: device descriptor read/64, error -110 usb usb3-port10: attempt power cycle usb usb3-port10: unable to enumerate USB device The same sequence occurs unprompted when the controller firmware asserts on its own. Note that this corrects the error reporting only; it does not by itself make the controller recoverable in the case above. Fixes: 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work") Signed-off-by: Ismail Tarim Signed-off-by: Luiz Augusto von Dentz commit 66d6ef18548ae6d7dd452b84115fc82c0a73a4ea Author: Pauli Virtanen Date: Sat Aug 8 12:08:45 2026 +0300 Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read. [Task 1] [Task 2 (hdev->workqueue)] l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref) Task 1 may observe NULL which causes null-ptr-deref. Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL. Clarify code comments vs. locking. Fixes: 6fef032af009 ("Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()") Reported-by: syzbot+e6382a2f53f5fc7453ac@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e6382a2f53f5fc7453ac Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz commit 59eecbe2f2f38d8f3e1104bd11da97f9a2c58998 Author: Pavel Shpakovskiy Date: Sat Aug 8 19:31:11 2026 +0300 Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference 'uuid_count' member of struct 'discovery_state' is assigned and read without any locks, so there is a chance of situation when uuid_count != 0, but uuids is NULL and there will be NULL pointer dereference. Possible race: 'hci_update_passive_scan_sync' 'hci_discovery_filter_clear' hdev->discovery.uuid_count = 0; <----------------------preempted-----------------------------> 'start_service_discovery' // Set uuid_count to value != 0 hdev->discovery.uuid_count = uuid_count; hdev->discovery.uuids = kmemdup(...); <----------------------preempted-----------------------------> spin_lock(&hdev->discovery.lock); kfree(hdev->discovery.uuids); hdev->discovery.uuids = NULL; spin_unlock(&hdev->discovery.lock); Now uuids == NULL and uuid_count != 0. So 'mgmt_device_found' -> 'is_filter_match' -> 'eir_has_uuids' receives non consistent discovery state, where NULL dereference of uuids happens. To fix it let's add discovery.lock around every read/write of uuid_count, uuids pair of struct members. It is also important to assign uuid_count value only after success kmemdup() allocation in start_service_discovery(), otherwise uuids is NULL, because kmemdup failed, but uuid_count is already assigned to non zero value. The following panic happens: [ ] ------------[ cut here ]------------ [ ] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ ] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP [ ] CPU: 0 PID: 15056 Comm: kworker/u9:2 [ ] Workqueue: hci0 hci_rx_work [ ] pstate: 10400009 (nzcV daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : eir_has_uuids+0x2d8/0x590 [ ] lr : is_filter_match+0x258/0x320 ... [ ] Call trace: [ ] eir_has_uuids+0x2d8/0x590 [ ] is_filter_match+0x258/0x320 [ ] mgmt_device_found+0x5b0/0xafc [ ] process_adv_report.part.0+0x8c8/0xf14 [ ] hci_le_adv_report_evt+0x338/0x3f0 [ ] hci_le_meta_evt+0x1f0/0x4c8 [ ] hci_event_packet+0x440/0xc9c [ ] hci_rx_work+0x44c/0xaf8 [ ] process_one_work+0x54c/0x103c [ ] worker_thread+0x6c4/0x10c4 [ ] kthread+0x274/0x2ec [ ] ret_from_fork+0x10/0x20 [ ] Code: 14000004 91004021 eb14003f 54000180 (f9400024) [ ] ---[ end trace 0000000000000000 ]--- Fixes: 2935e556850e ("Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'") Signed-off-by: Pavel Shpakovskiy Signed-off-by: Luiz Augusto von Dentz commit 6586705bc2dc06908309bf65d79efa53a347c9f0 Author: Tao Cui Date: Mon Aug 24 21:21:16 2026 +0800 docs/sched_ext: document that cgroup CPU knobs are scheduler-dependent The scheduler core communicates the initial cpu controller settings to the BPF scheduler through ops.cgroup_init() and reports subsequent changes through the corresponding ops.cgroup_set_*() callbacks. Whether and how a knob takes effect is up to the loaded scheduler: it may implement the corresponding callback partially or not at all, so cpu.max, cpu.weight and friends can silently have no effect. Document this in the basics section of sched-ext.rst. Signed-off-by: Tao Cui Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo commit d4bfa78fd67929b62b02013c107973e0c5b7aa9a Author: Pauli Virtanen Date: Sun Aug 9 01:06:05 2026 +0300 Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN New sk should not be added to parent socket accept queue after last l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and state set to BT_CLOSED, as that can result to UAF on dereferencing the dangling parent reference. l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking: [Task 1] [Task 2] l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */ Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes where missing, to avoid data races. Although the data races on pchan->state should be fixed too, this defensive sk_state check probably makes sense in any case. Fixes: 2ff1a41a912d ("Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()") Reported-by: syzbot+9265e754091c2d27ea29@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9265e754091c2d27ea29 Signed-off-by: Pauli Virtanen Reported-by: syzbot+9265e754091c2d27ea29@syzkaller.appspotmail.com Tested-by: syzbot+9265e754091c2d27ea29@syzkaller.appspotmail.com Signed-off-by: Luiz Augusto von Dentz commit ca2c4c26498643f421d35ffe258fafbd3ed461c3 Author: Pauli Virtanen Date: Sun Aug 9 20:42:41 2026 +0300 Bluetooth: L2CAP: access chan->conn safely in get/setsockopt 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 commit c7e9a8cb6918656884a0757c92465075c7555ffa Author: Guangshuo Li Date: Sat Aug 8 13:30:57 2026 +0800 Bluetooth: hci_intel: fix usage_count leak when autosuspend_delay is negative intel_set_power() calls pm_runtime_use_autosuspend() when powering on the device, but the power-off path does not call the matching pm_runtime_dont_use_autosuspend() before disabling runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before disabling runtime PM. This issue was found by manual code inspection. Fixes: 74cdad37cd24 ("Bluetooth: hci_intel: Add runtime PM support") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Luiz Augusto von Dentz commit 853a92b97ca547a7ddd9790ff90651b2fd943498 Author: Guangshuo Li Date: Sat Aug 8 13:26:54 2026 +0800 Bluetooth: hci_h5: fix usage_count leak when autosuspend_delay is negative h5_btrtl_open() calls pm_runtime_use_autosuspend(), but h5_btrtl_close() does not call the matching pm_runtime_dont_use_autosuspend() when tearing down runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during driver teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before disabling runtime PM. This issue was found by manual code inspection. Fixes: d9dd833cf6d2 ("Bluetooth: hci_h5: Add runtime suspend") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Luiz Augusto von Dentz commit dc6b7c771a963e20aedf4a21ffa22543b9837ba8 Author: Guangshuo Li Date: Sat Aug 8 13:15:32 2026 +0800 Bluetooth: hci_bcm: fix usage_count leak when autosuspend_delay is negative bcm_request_irq() calls pm_runtime_use_autosuspend(), but bcm_close() does not call the matching pm_runtime_dont_use_autosuspend() when tearing down runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during driver teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before disabling runtime PM. This issue was found by manual code inspection. Fixes: e88ab30d3669 ("Bluetooth: hci_bcm: Add suspend/resume runtime PM functions") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Luiz Augusto von Dentz commit 8bfab832ad6905ba70e69bad87a78f6d90cce64a Merge: 47096fc3d064a0 14af7a96afa39f Author: Linus Torvalds Date: Mon Aug 24 10:03:49 2026 -0700 Merge tag 'mailbox-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox Pull mailbox updates from Jassi Brar: - mhuv2: - convert channel translation to fw_xlate() - use generic device property APIs - axiado: - add AX3005 mailbox controller driver and DT bindings - bcm2835: - use platform_get_irq() - simplify probe error handling - cix: - fix DT property string typo - use dev_err_probe() - exynos: - add Exynos850 mailbox driver support and DT bindings - microchip: - add null check for devm_kasprintf() - pcc: - fix missed-interrupt command timeout - verify shared memory signature - notify clients on polled completion - qcom: - fix CPUCP PREEMPT_RT deadlock and NULL data crash - fix IPCC duplicate channel allocation across holes - add IPQ5210 APCS and Nord IPCC bindings - riscv: - validate RPMI notification buffer lengths and event payload bounds - rockchip: - manage peripheral clock with devm helper - drop unused struct field - ti-msgmgr: - convert bindings to DT schema - remove redundant dev_err()/dev_err_probe() on IRQ request failures across drivers * tag 'mailbox-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox: (22 commits) mailbox: add Axiado AX3005 mailbox driver dt-bindings: mailbox: add Axiado AX3005 mailbox dt-bindings: mailbox: Convert TI Message Manager to DT schema mailbox: cix: fix DT property name string typo and use dev_err_probe() mailbox: riscv-sbi-mpxy: validate RPMI notification lengths mailbox: bcm2835: use platform_get_irq and simplify probe mailbox: qcom-ipcc: fix duplicate channel allocation across holes mailbox: mchp-ipc-sbi: Add null check for devm_kasprintf() mailbox: Remove redundant dev_err()/dev_err_probe() dt-bindings: mailbox: qcom: Add IPQ5210 APCS compatible dt-bindings: mailbox: qcom-ipcc: Document Nord IPCC mailbox: exynos: Add support for Exynos850 mailbox dt-bindings: mailbox: google,gs101-mbox: Add samsung,exynos850-mbox mailbox: pcc: Fix command timeout due to missed interrupt mailbox: pcc: Check shared memory signature on request mailbox: pcc: Notify clients on polled completion mailbox: rockchip: drop unneeded runtime pointer (pclk) mailbox: rockchip: disable pclk on probe failure and unbind mailbox: qcom-cpucp: handle NULL data in send_data callback mailbox: qcom-cpucp: fix PREEMPT_RT self-deadlock in IRQ handler ... commit f7f11bdddababc9947138001a2f5c80d2cccf1a7 Author: Federico Vaga Date: Sun Aug 16 19:39:28 2026 +0000 doc:it_IT: align Italian documentation in process This commit updates the Italian translation in `process/` following these changes: commit 44abc8fcbff2 ("Documentation: process: Arbitrarily bump kernel major version number") commit ba2457109d5b ("Documentation: process: Also mention Sasha Levin as stable tree maintainer") commit 5ce70894f6ca ("Doc: correct spelling and wording mistakes") commit 46298375477b ("linux-next: update maintainer info.") commit 43e9076a00b1 ("docs: Fix conflicting contributor identity info") commit b27f9e8079bf ("docs: remove Documentation/dontdiff") commit 9734b3e753ad ("docs: 5.Posting: mentioned Suggested-by: tag") commit 4e6b7141d169 ("docs: clarify rules wrt tagging other people") commit 944df7a31452 ("docs: update the guidance for Link: tags") commit 0a83293322fd ("doc: development-process: add notice on testing") commit a037699da0a1 ("docs: Add debugging section to process") commit 78d979db6cef ("docs: add AI Coding Assistants documentation") commit a66437c27979 ("Documentation: Provide guidelines for tool-generated content") commit a592a36e4937 ("Documentation: use a source-read extension for the index link boilerplate") commit 102606402f4f ("Documentation: Project continuity") commit a03ef333fbd6 ("Documentation: security-bugs: explain what is and is not a security bug") commit d0b343605f1b ("kernel-docs: Add new section for Rust learning materials") commit 57937eac1f78 ("kernel-docs: Add book to process/kernel-docs.rst") commit d8c949c577b5 ("docs/licensing: Clarify wording about "GPL" and "Proprietary"") commit ebf1bafd0907 ("LICENSES: Explicitly allow SPDX-FileCopyrightText") commit 9fa7153c31a3 ("rust: conclude the Rust experiment") commit 47cb33cedf47 ("docs: clarify wording in programming-language.rst") commit 45a92c0b91d7 ("docs: maintainers: add SPDX license to the file") commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() and family") commit e4c8b46b924e ("slab: Introduce kmalloc_flex() and family") commit d957b4184aee ("Documentation: deprecated.rst: kmalloc-family: mark argument as optional") commit 120a64c8021d ("Documentation: process: fix brackets") commit 079a028d6327 ("string: Remove strncpy() from the kernel") commit e551bd4109d2 ("Documentation: remove :kyb: tags") commit 4971ca2007e3 ("docs: process: email-client: add Thunderbird "Toggle Line Wrap" extension") commit f44a29784f68 ("Documentation: update maintainer-pgp-guide for latest best practices") commit 273aa250f138 ("Documentation: Improve wording on requirements for a free Nitrokey") commit 6c5c07bc8589 ("docs: process: maintainer-pgp-guide: update kernel.org docs link") commit 54857c52452a ("docs: maintainer-pgp-guide.rst: add a reference for kernel.org sign") commit a556bd882b94 ("docs: align with scripts/syscall.tbl migration") commit e5b1c0fa4ff2 ("Documentation: Remove :manpage: from non-existing man pages") commit 78a00cac1e96 ("docs: fix 're-use' -> 'reuse' in documentation") commit ec6fd28baf61 ("docs: remove unneeded maintainer_handbooks_main label") commit 8eae6da5f56c ("docs: auto-generate maintainer entry profile links") commit bda185c30593 ("docs: maintainers_include: Only show main entry for profiles") commit 2783096fb1dd ("docs: submit-checklist: Expand on build tests against different word sizes") commit fb12098d8ee4 ("docs: submit-checklist: Allow creating cross-references for ABI README") commit 5a63f0369bda ("docs/.../submit-checklist: Use Documentation/admin-guide/abi.rst for cross-ref of README") commit e5880f95a979 ("docs: process: discourage pointless boilerplate kdoc") commit 2c62e2e874d1 ("coding-style: fix verb typo") commit 197bbebd2581 ("docs: Update documentation to avoid mentioning of kernel.h") commit eba6ffd126cd ("docs: kdoc: move kernel-doc to tools/docs") commit 7c6d969d5349 ("Documentation: adopt new coding style of type-aware kmalloc-family") commit 323fa4b9608b ("Documentation: Fix syntax of kmalloc_objs example in coding style doc") commit d49172bbd7eb ("Documentation: clarify the expected collaboration with security bugs reporters") commit 3a68841d1d9b ("Documentation: smooth the text flow in the security bug reporting process") commit ceddb2c001d9 ("Documentation: insist on the plain-text requirement for security reports") commit f2b1cbef1536 ("Documentation: minor updates to the security contacts") commit a72b832a4823 ("Documentation: explain how to find maintainers addresses for security reports") commit 496fa1befba1 ("Documentation: clarify the mandatory and desirable info for security reports") commit f387e2e2b9d3 ("Documentation: fix two typos in latest update to the security report howto") commit aed3c3346765 ("Documentation: security-bugs: do not systematically Cc the security team") commit 4bf85afb9f3e ("Documentation: security-bugs: clarify requirements for AI-assisted reports") commit 561458db0d6b ("docs: security-bugs: add a link to the threat-model documentation") commit 5f5e7344322f ("kbuild: generate offset range data for builtin modules") commit 41047d53bcff ("docs:process:changes: fix version command for btrfs-progs") commit 82a1978d0fdc ("kheaders: use 'tar' instead of 'cpio' for copying files") commit d2b239099cf0 ("docs: changes: update Sphinx minimal version to 3.4.3") commit 5e25b972a22b ("docs: changes: update Python minimal version") commit 118c40b7b503 ("kbuild: require gcc-8 and binutils-2.30") commit 28d51df0dbaa ("Documentation: update binutils-2.30 version reference") commit fc6edeea53f4 ("docs: Remove reiserfsprogs from dependencies.") commit bc20c56e98e0 ("docs: changes: better document Python needs") commit 20c098928356 ("kbuild: Bump minimum version of LLVM for building the kernel to 15.0.0") commit 903922cfa0e6 ("lib/Kconfig.debug: Set the minimum required pahole version to v1.22") commit 8913632998fc ("Documentation: Fix typos and grammatical errors") commit c99fcb58501e ("docs: Fix an erroneous reference to sphinx.rst") commit d8a224f519c6 ("docs: changes/ver_linux: fix entries and add several tools") commit ece7e57afd51 ("docs: changes.rst and ver_linux: sort the lists") commit f32fb9c58a5b ("rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)") commit c3a00a3f31ff ("rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie)") commit ce3267a39a92 ("kbuild: Bump minimum version of LLVM for building the kernel to 17.0.1") commit 2c1ccd9a1d78 ("docs: changes.rst: restore pahole 1.26 minimum (regressed by sort)") commit 3f997cbf676b ("docs: process: submitting-patches: split canonical patch format section") commit 6356f18f09dc ("Align git commit ID abbreviation guidelines and checks") commit cd9123eeb224 ("docs: submitting-patches: clarify Acked-by and introduce "# Suffix"") commit 25fb101385f7 ("docs: submitting-patches: clarify difference between Acked-by and Reviewed-by") commit 08c035da54a3 ("docs: submitting-patches: clarify that signers may use their discretion on tags") commit 95767a592dc9 ("docs: submitting-patches: document the format for affiliation") commit dc896f853e1a ("docs: submitting-patches: adjust Fixes definition slightly") commit 22014a230093 ("Documentation/process: submitting-patches: fix typo in "were do"") commit e36a7b1e1734 ("docs: submitting-patches: Clarify that removal of Acks needs explanation too") commit 8a12e3fbf2c3 ("docs: submitting-patches: suggest adding previous version links") commit 6252e5c1c20e ("docs: add an Assisted-by mention to submitting-patches.rst") commit 48c3876a6a6f ("docs: submitting-patches: Clarify that "reviewer" is a person") commit 83f71fbc66fb ("docs: submitting-patches: Fix section structure around DCO") Signed-off-by: Federico Vaga Signed-off-by: Jonathan Corbet Message-ID: <20260816193906.68808-1-federico.vaga@vaga.pv.it> commit 87d347a8c8545a9234d1dd215023064413284c34 Author: Guopeng Zhang Date: Mon Aug 24 10:01:40 2026 +0800 selftests/cgroup: Add test for preserving boot-isolated CPUs Put a CPU isolated at boot into an isolated partition, change the partition back to member and check that the CPU remains isolated. Signed-off-by: Guopeng Zhang Reviewed-by: Waiman Long Signed-off-by: Tejun Heo commit 60763c2f834dbeb6c30064f845109358e775e64b Author: Johan Hovold Date: Wed Aug 19 15:40:39 2026 +0200 docs: threat-model: fix /dev/kmsg reference Fix a '/dev/kmsg' reference which got replaced with '/proc/kmsg' (which is not accessible to regular users). Fixes: a03ef333fbd6 ("Documentation: security-bugs: explain what is and is not a security bug") Signed-off-by: Johan Hovold Acked-by: Willy Tarreau Signed-off-by: Jonathan Corbet Message-ID: <20260819134039.286793-1-johan@kernel.org> commit 6c37d7e074a4be1ba8da59f4ed5df8977b3daa43 Author: Guopeng Zhang Date: Mon Aug 24 10:01:39 2026 +0800 cgroup/cpuset: Preserve boot-isolated CPUs on partition release isolated_cpus tracks CPUs isolated with isolcpus= as well as CPUs in isolated cpuset partitions. When an isolated partition is released, isolated_cpus_update() removes its whole CPU mask. This also clears CPUs which were already isolated at boot. This can be reproduced on a cgroup v2 system booted with isolcpus=domain,15: cd /sys/fs/cgroup echo +cpuset > cgroup.subtree_control mkdir cpuset-repro echo 15 > cpuset-repro/cpuset.cpus echo isolated > cpuset-repro/cpuset.cpus.partition echo member > cpuset-repro/cpuset.cpus.partition cat cpuset.cpus.isolated CPU 15 is absent before the change. It must remain in cpuset.cpus.isolated after the partition is released. Update isolated_cpus one CPU at a time and keep CPUs outside the boot-time domain housekeeping mask isolated. Fixes: c188f33c864e ("cgroup/cpuset: Account for boot time isolated CPUs") Signed-off-by: Guopeng Zhang Acked-by: Waiman Long Signed-off-by: Tejun Heo commit 2bf404b1bd94f50747443234c0a4a5e18e2569bf Author: Guopeng Zhang Date: Mon Aug 24 10:01:38 2026 +0800 selftests/cgroup: Drop invalid boot isolation comparison check_isolcpus() clears ISOLCPUS before rebuilding it from sched domain data. Comparing that empty value with /sys/devices/system/cpu/isolated makes the test fail whenever isolcpus=domain is present. That sysfs file is generated from HK_TYPE_DOMAIN_BOOT and does not change when cpuset updates HK_TYPE_DOMAIN. Re-reading it cannot validate dynamic housekeeping updates. The cpuset.cpus.isolated and sched domain checks already cover the two dynamic interfaces, so remove the invalid comparison. This can be reproduced on a kernel booted with isolcpus=domain,15: # tools/testing/selftests/cgroup/test_cpuset_prs.sh The test fails its first state-matrix isolation check before the change and continues past that check afterward. Fixes: 6df415aa46ec ("cgroup/cpuset: Defer housekeeping_update() calls from CPU hotplug to workqueue") Signed-off-by: Guopeng Zhang Reviewed-by: Waiman Long Signed-off-by: Tejun Heo commit b40a680ea4efe4ef2addada63e304a94d19500d1 Author: Jenson Johnathon Reggentin Date: Wed Aug 19 21:23:59 2026 +0200 docs: block: fix dead http link in blk-mq.rst The current link http://kernel.dk/blk-mq.pdf leads to a 404 error page. https://www.kernel.dk/blk-mq.pdf leads to the correct document. v2 to add the missing www. prefix in the actual file change. Signed-off-by: Jenson Johnathon Reggentin Acked-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20260819192422.42189-1-mail@jregg.de> commit bbc2de7fa5b42ee024ae82cd848252152d219a4e Author: Akiyoshi Kurita Date: Thu Jul 30 22:00:30 2026 +0900 docs/ja_JP: translate submitting-patches.rst (tag usage) Translate the Acked-by:, Cc:, and Co-developed-by: section into Japanese. Signed-off-by: Akiyoshi Kurita Acked-by: Akira Yokosawa Signed-off-by: Jonathan Corbet Message-ID: <20260730130030.1078990-1-weibu@redadmin.org> commit 909a3f0e9d8b0d8001cf6e99808f88eca8e44328 Author: Cheng Lingfei Date: Mon Aug 24 20:45:46 2026 +0800 docs: cgroup-v2: fix misc.events key format description In misc cgroup, misc.events does not output a simple "max" key. Instead, each registered misc resource outputs a separate key suffixed with ".max" (i.e., ".max"). Update the documentation to clarify that the entry key is ".max". Suggested-by: Michal Koutný Signed-off-by: Cheng Lingfei Signed-off-by: Tejun Heo commit cb19774faa57c51efa189d8b8606aeabccebc53b Author: Ibrahim Abdelkader Date: Tue Aug 11 10:37:29 2026 +0200 Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last request A synchronous HCI command that never receives a response leaves HCI_CMD_PENDING set: hci_req_cmd_complete() is the only place that clears it, and it only runs when a response matching the last command sent arrives. hci_send_cmd_sync() populates hdev->req_skb only when the flag transitions from clear to set, while hci_dev_open_sync() and hci_dev_close_sync() drop req_skb without clearing the flag. After a timeout followed by either, the two disagree: the flag claims a request is outstanding while req_skb is NULL. Subsequent synchronous commands are then sent with no req_skb, so hci_event_packet() has nothing to match an arriving event against, and the caller times out even though the controller answered. Commands answered by Command Complete recover on their own, since hci_req_cmd_complete() clears the flag as a side effect. Drivers using __hci_cmd_sync_ev() with a custom event do not, because a vendor event never reaches that path. On a WCN3988 (hci_qca over UART) this makes a controller firmware hang unrecoverable: the driver injects a hardware error and re-runs qca_setup(), qca_read_soc_version() waits for HCI_EV_VENDOR, the reply arrives within 4 ms and is discarded, and every retry fails the same way. The adapter is left down until the driver is unbound and rebound, or power is removed. Clear the flag wherever the last request is dropped, restoring the invariant that req_skb is non-NULL exactly when HCI_CMD_PENDING is set. Verified on hardware by forcing a command timeout: without this change setup fails on every attempt, with it setup succeeds on the first. Fixes: 2615fd9a7c25 ("Bluetooth: hci_sync: Fix overwriting request callback") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Abdelkader Signed-off-by: Hans de Goede Signed-off-by: Luiz Augusto von Dentz commit 76671054f9a1ff6abb976583cd8da37650acdc97 Merge: d75b4846055942 aa8e5dc6a7a2a1 Author: Paolo Bonzini Date: Mon Aug 24 12:42:07 2026 -0400 Merge tag 'kvmarm-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 changes for 7.3 - Add support for 'slot' based PMU events, paired with new UAPI that compels the user to select a specific PMU implementation - Lazy save/restore of vCPU state for pKVM, along with various fixes and cleanups to the management of vCPU state between the untrusted host and pKVM hypervisor - Disable traps of EL1 registers for nested hypervisors when FEAT_NV2p1 is present, guaranteeing that EL2-specific register bits are stateful in the EL1 counterpart - Leverage FEAT_NV3 to avoid unnecessary ERET/TLBI traps when the scope of those instructions remains 'in host' (i.e. L1 kernel/userspace) - Pile of fixes for the management of the VNCR pseudo-TLB, such as under-invalidations and races with concurrent TLBIs on other vCPUs - Consolidate the non-protected and pKVM view of ICH_VTR_EL2 to a runtime-patched constant, allowing the same data to be shared with pKVM prior to dropping host privileges - Considerable pile of LLM-assisted fixes around the shop but mostly in the VGIC, our in-kernel generator of bugs (and sometimes interrupts) commit 7e33ba3a1d48c2d20ed270dec9d2d08332585c8e Author: Taimuraz Kaitmazov Date: Thu Aug 20 02:08:52 2026 +0300 accel/amdxdna: put the chained BO when its mapping fails amdxdna_cmd_set_error() looks up the first BO of a command chain, which takes a reference, and drops it at the end of the function. The mapping of that BO is established in between, and the failure path returns without the put, so the reference is leaked. Ordinary use does not reach it. The chain has been submitted before any of this runs, so aie2_cmdlist_fill_slot() has already called amdxdna_cmd_get_op() on that BO and amdxdna_gem_vmap() has cached its address. What makes it reachable is that the BO is resolved again by handle here, and the handle is userspace's to recycle: closing it after submission and importing a dma-buf whose exporter implements no vmap onto the same id leaves amdxdna_gem_get_obj() returning an object this cannot map, since prime_import() types every import AMDXDNA_BO_SHARE. Fixes: d76856beb4a4 ("accel/amdxdna: Refactor GEM BO handling and add helper APIs for address retrieval") Signed-off-by: Taimuraz Kaitmazov Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260819230852.287751-1-taimuraz@kaitmazov.com commit ef6d27af71e1dc43181ec797a6aaa77c27c36786 Author: Taimuraz Kaitmazov Date: Tue Aug 18 03:00:19 2026 +0300 accel/amdxdna: reject a command chain that carries no commands A chain whose command_count is zero passes the payload length check, because struct_size(payload, data, 0) is just the header. The fill loop then does not run, so offset stays zero and the request is submitted with a zero-length buffer. On firmware without AIE2_NPU_COMMAND that ends at the opcode check, since op is still ERT_INVALID_CMD and aie2_get_chain_msg_op() answers MSG_OP_MAX_OPCODE. aie2_get_npu_chain_msg_op() answers MSG_OP_CHAIN_EXEC_NPU whatever it is given, so there the submission continues to drm_clflush_virt_range(cmd_buf, 0), which reads the byte before the buffer and faults on the vmap guard page. EXEC_CMD is reachable by any process that can open the render node. Reject the request instead. Fixes: 8ed8b0239617 ("accel/amdxdna: Add debug prints for command submission") Signed-off-by: Taimuraz Kaitmazov Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260818000019.369366-1-taimuraz@kaitmazov.com commit b3709d354545e70388177500761f92d906c4dfd6 Author: Lizhi Hou Date: Thu Aug 20 20:35:43 2026 -0700 accel/amdxdna: Remove __counted_by from struct amdxdna_cmd_chain struct amdxdna_cmd_chain contains a flexible array annotated with __counted_by(command_count). Since the structure is stored in shared AMDXDNA_BO_SHARE memory, userspace can modify command_count concurrently. If command_count is changed to zero, the bounds check generated from __counted_by may fail and trigger a kernel panic. Remove __counted_by to avoid relying on the userspace-controlled command_count for the flexible array bounds check. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260821033543.1839719-1-lizhi.hou@amd.com commit 47096fc3d064a07c0842f748b99ebf01be120f2b Merge: cf9610f9116d55 d576a9561a1c80 Author: Linus Torvalds Date: Mon Aug 24 09:07:15 2026 -0700 Merge tag 'i2c-7.3-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull more i2c updates from Andi Shyti: "Fixes and cleanups around probe error handling, resource management and a minor Rust cleanup. Drivers: - several drivers: drop duplicate IRQ error reporting - imx-lpi2c: improve probe initialization and error cleanup - mxs: fix DMA channel leak on probe failure - ocores: fix clock cleanup on resume failure - rcar: handle reset controllers without status support Muxes: - demux-pinctrl: fix OF node leak on allocation failure Rust: - mark trivial I2cAdapter reference-counting methods inline" * tag 'i2c-7.3-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: i2c: rust: mark I2cAdapter methods as inline i2c: rcar: fix reset handling for Gen5 i2c: mxs: fix DMA channel leak on probe error i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure i2c: ocores: Disable clock on failed resume i2c: imx-lpi2c: reset controller in probe stage i2c: imx-lpi2c: properly unwind resources on probe failure i2c: busses: drop redundant dev_err_probe() around irq helpers commit cf9610f9116d55c5a66ef9f1faecacabd93a9322 Merge: 0b0e645ed2c858 d067f0f4c96cb5 Author: Linus Torvalds Date: Mon Aug 24 08:46:03 2026 -0700 Merge tag 'pinctrl-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control updates from Linus Walleij: "Core changes: - Use the non-blocking mux_state_try_select() in the generic MUX pin control back-end - Free pin maps on pinctrl_generic_to_map() failure in the core helpers New hardware pin control: - Qualcomm Maili TLMM SoC, PMG1110 PMIC, and Eliza LPASS LPI TLMM SoC (this is for the low power audio, LPASS = Low Power Audio SubSystem portions) - Upboard support on top of the Intel pin controller - Apple T6030 and T6031 support (just compatible strings) - Samsung Exynos 8855 SoC - Mediatek MT6858 SoC - Rockchip RK3308B and RV1106 SoCs - Airoha EN7523 and AN7563 SoCs Improvements: - Qualcomm TLMM GPIOs are unconditionally marked as wakeup capable - Qualcomm improvements on top of the Qualcomm PDC (power domain controller) irqchip improvements from tglx:s tree - Qualcomm IPQ806x and IPQ9650 non-urgent pin grop fixups - The NPCM8xx driver has been put into shape fixing many pin and group definitions - Some non-urgent Tegra 264 pin assignments are fixed up - Some non-urgent fixups to Airoha AN7581 and AN7583 registers and pin assignments, missing features etc" * tag 'pinctrl-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (130 commits) dt-bindings: pinctrl: Convert TI DA850 pupd to DT schema pinctrl: meson: sync some modify from A4 pinctrl: meson: a4: Add input enable pin configuration pinctrl: realtek: rtd1625: remove unused group name spdif_sel pinctrl: realtek: rtd1625: fix base_bit for VE4 GPIO 13 dt-bindings: pinctrl: microchip,pic32mzda-pinctrl: Convert to DT schema Revert "Merge branch 'ib-rsk7204' into devel" pinctrl: rockchip: Add RV1106 pinctrl support dt-bindings: pinctrl: rockchip: Add RV1106 compatible pinctrl: rockchip: Decode drive strength in the get function pinctrl: fix PINCTRL_GENERIC_MUX not always being selectable pinctrl: airoha: add support of an7563 SoC dt-bindings: pinctrl: airoha: add support of an7563 pin controller pinctrl: airoha: try to find chip scu node by phandle first pinctrl: airoha: add support of en7523 SoC dt-bindings: pinctrl: airoha: add support of en7523 pin controller pinctrl: airoha: an7583: add support for olt pinmux pinctrl: airoha: an7583: add support for pon_alt pinmux pinctrl: airoha: an7583: add support for npu_uart pinmux dt-bindings: pinctrl: airoha: an7583: add missed features ... commit 3b2c5d35cf4398edf47c4a3ad076838654a30015 Author: Seongjae Jeong Date: Mon Aug 24 02:32:31 2026 +0000 f2fs: use adjusted write range after f2fs_write_checks() generic_write_checks() in f2fs_write_checks() can adjust iocb->ki_pos for append writes and truncate the iterator to limit the number of bytes to write. In f2fs_file_write_iter(), the pinned-file overwrite check currently uses the position and count saved before f2fs_write_checks(), so it can check a range different from the actual write range. The forced buffered I/O cleanup also uses orig_pos saved before f2fs_write_checks(). For O_APPEND writes, this can make the cleanup flush and invalidate the wrong page cache range. Move the pinned-file overwrite check after f2fs_write_checks() and use the adjusted iocb->ki_pos and iov_iter_count(from). Also save the adjusted write position and use it for the forced buffered I/O cleanup. Fixes: 3fdd89b452c2 ("f2fs: prevent writing without fallocate() for pinned files") Fixes: 92318f20d703 ("f2fs: preserve direct write semantics when buffering is forced") Signed-off-by: Seongjae Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim commit 0b0e645ed2c858978a8de877ecb6355d30a6ba91 Merge: 0a0d1d55dad570 e3e3bf40916c1e Author: Linus Torvalds Date: Mon Aug 24 08:15:59 2026 -0700 Merge tag 'auxdisplay-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay Pull auxdisplay updates from Andy Shevchenko: - Cancel backlight work on panel registration failure - Miscellaneous cleanups * tag 'auxdisplay-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay: auxdisplay: charlcd: cancel backlight work on registration failure auxdisplay: panel: Remove unused callback binding code auxdisplay: Remove redundant dev_err() commit 34b5c4a6e4fb9dbb3f9d87f3b0fb0372105c8302 Author: Jimmy Zuber Date: Mon Aug 24 14:30:51 2026 +0000 fuse: zero the partial EOF page when extending a file Extending a fuse file past a non-page-aligned EOF does not zero the tail of the old last page. When that page is cached and has been mmap-dirtied beyond the old EOF, the now in-bounds tail is served to later reads as stale data rather than zeros, which violates POSIX file-extension semantics. Some file systems get this zeroing automatically at writeback time (block_write_full_folio() / iomap_writeback_handle_eof() zero the tail of the folio straddling i_size). A non-writeback caching fuse file system uses neither path, so it has to zero the tail itself from the size-extending paths, like XFS (xfs_file_write_zero_eof()) and ext4 (ext4_block_zero_eof()) do. Call truncate_pagecache_range() over the newly-exposed range up front from the three paths that extend a file, before the new size is published: - a buffered write whose position is past the old EOF (fuse_perform_write()); - a size-extending setattr/truncate (fuse_do_setattr()); - a size-extending fallocate (fuse_file_fallocate()). This unmaps the stale mappings and zeroes the partial tail of the old EOF folio, so a later read returns zeros. Truncating [old EOF, write start) before a buffered write keeps the dropped range disjoint from the written data, so a write that lands inside the old EOF folio is preserved. writeback_cache connections are unaffected, as their writes go through iomap_file_buffered_write(), which zeroes post-EOF folios. The bug is observable on a non-writeback_cache server that returns FOPEN_KEEP_CACHE on writable files (without FOPEN_DIRECT_IO), and is caught by the new write_extend_eof fuse selftest. Signed-off-by: Jimmy Zuber Signed-off-by: Miklos Szeredi commit b8f070ac3167595069feb1f794c127b805115645 Author: Vladimir Murzin Date: Wed Aug 19 15:48:59 2026 +0100 arm64: process: Fix context switching MTE store-only tag check SCTLR_EL1.TCSO0 is set when user opt-in for MTE store-only tag check mode. However, it is not part of SCTLR_USER_MASK which imply that on context switch we never clear SCTLR_EL1.TCSO0, so we are leaking that setting into another task. Fix that by including SCTLR_EL1_TCSO0_MASK into SCTLR_USER_MASK Fixes: 4d51ff5bba00 ("arm64/kernel: Support store-only mte tag check") Signed-off-by: Vladimir Murzin Reviewed-by: Catalin Marinas Reviewed-by: Yeoreum Yun Signed-off-by: Will Deacon commit 1476cca098f6d3a553fcec6fe9b7d86e15c00b59 Author: Alexander Graf Date: Fri Aug 21 22:42:52 2026 +0000 dma-contiguous: fix truncation of numa_cma / cma_pernuma sizes >= 2G numa_cma=0:4G reserves nothing at all. dma_numa_cma_reserve() copies the requested size into a local int before handing it to cma_declare_contiguous_nid(), so 0x100000000 truncates to zero and the loop skips the node silently. Both parameters are documented in kernel-parameters.txt as nn[MG], so that is the syntax the documentation invites. Which bits survive decides what a request turns into: 4G, 8G and 16G reserve nothing, 2G, 3G and 6G sign-extend into a size the allocator rejects with a warning, and 5G quietly reserves 1G. It reaches further than those parameters. On a CMA_SIZE_PERNUMA kernel with no per-node parameter, dma_numa_cma_reserve() takes the per-node size from the default area, so a plain cma=4G on a multi-node machine feeds that size through the same local and loses every per-node area. numa_cma_size[] and pernuma_size_bytes are both phys_addr_t, so use it for the local too, and give early_numa_cma() separate variables for the node id and the size while in there. Fixes: d5cae2261b86 ("dma-contiguous: simplify numa cma area handling") Cc: stable@vger.kernel.org Assisted-by: Kiro:claude-opus-5 Signed-off-by: Alexander Graf Reviewed-by: Feng Tang Link: https://lore.kernel.org/r/20260821224252.70640-1-graf@amazon.com Signed-off-by: Marek Szyprowski commit beca1b97a21d81eae9cbd267ecc44b5d2193e60a Author: Wei-Lin Chang Date: Fri Aug 14 23:24:58 2026 +0100 KVM: arm64: ptdump: Flush the last region Currently the stage-2 ptdump calls note_page() at each leaf entry visit. This simply misses the output of the last region, because note_page() only dumps output when it detects a change in level/prot, or when the walk enters a next marker section. The last region in the guest IPA space with the same level/prot is not dumped since there is no change after it. Call note_page_flush() to dump the final region. note_page_flush() uses ptdump_pg_state.end_address to call the final note_page(), so also provide the end address. Also change the second marker's start address to ULONG_MAX so we never cross it. This avoids dumping redundant marker names (which are NULL), and advancing beyond the end of the marker array. Fixes: 7c4f73548ed1 ("KVM: arm64: Register ptdump with debugfs on guest creation") Reported-by: Sashiko AI Closes: https://lore.kernel.org/kvmarm/20260630122758.891011F00A3A@smtp.kernel.org/ Reviewed-by: Dev Jain Tested-by: Dev Jain Signed-off-by: Wei-Lin Chang Reviewed-by: Marc Zyngier Signed-off-by: Will Deacon commit 902caade3cfd60f99bf71b355e7c86344bd831e5 Author: Wei-Lin Chang Date: Fri Aug 14 23:24:57 2026 +0100 arm64: ptdump: Make note_page_flush() range aware note_page_flush() calls note_page() with addr == 0 and level == -1 to dump the last row of a ptdump. addr == 0 (1 << 64 wrapped around) renders a huge region with enormous size for address spaces with IA bits < 64. For example the stage-2 page tables and the EFI runtime page table. More importantly, the last region of the address space and everything after the address space up to 1 << 64 are merged into one row of output. If the last region within the address space is valid, it will appear to remain valid up to 1 << 64 with the same attributes. Currently only the EFI runtime ptdump is affected by this, but KVM will soon fix its stage-2 ptdump by using note_page_flush(). Here is an example of an EFI runtime ptdump (last row): 0x0000008000000000-0x0000000000000000 17179868672G PGD With this patch: 0x0000008000000000-0x0001000000000000 261632G PGD To fix this, cache the end address of a ptdump in ptdump_pg_state so note_page_flush() can call the final note_page() with the correct end address. Fixes: 9d80448ac92b ("efi/arm64: Add debugfs node to dump UEFI runtime page tables") Signed-off-by: Wei-Lin Chang Reviewed-by: Marc Zyngier Signed-off-by: Will Deacon commit 60e73c07b3fc12958a63de77b482d18bda413a6a Author: Shuming Fan Date: Mon Aug 24 18:39:36 2026 +0800 ASoC: rt766: add RT766/RT767 VA1 device IDs This patch adds the RT766/RT767 VA1 device IDs, which support SoundWire v1.3. Signed-off-by: Shuming Fan Link: https://patch.msgid.link/20260824103936.3524080-1-shumingf@realtek.com Signed-off-by: Mark Brown commit 72dd0ec09e7cc98ed58ddeac26575e5d1ab8a93d Author: Tetsuo Handa Date: Tue Aug 4 22:52:19 2026 +0900 printk: Don't WARN on kthread_run failure. 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 commit 564ed40708ebc60a78f280944799cbe8e3401816 Merge: 160dcfe7f94346 648294a02bfcd0 Author: Vlastimil Babka (SUSE) Date: Mon Aug 24 15:01:27 2026 +0200 Merge branch 'slab/for-7.3/kfree_rcu_nolock' into slab/for-next Merge series "mm/slab: introduce kfree_rcu_nolock() and improve slub_kunit coverage" from Harry Yoo. From the cover letter [1]: This series improves kmalloc_nolock() and kfree_nolock() coverage in slub_kunit and introduces kfree_rcu_nolock() for unknown context as suggested by Alexei Starovoitov. Unknown context means the caller does not know whether spinning on a lock is safe (e.g., a BPF program attached to an arbitrary kernel function or in NMI context). The slab allocator already supports unknown context via kmalloc_nolock() and kfree_nolock(), but te slab allocator does not support freeing objects by RCU in unknown context. It is not ideal to have completely separate batching for unknown context because the worst scenario where spinning on a lock would lead to deadlock is very rare, and in most cases, it is safe to use the existing mechanism (kfree_rcu_sheaf()). Since most part of the slab allocator already supports unknown context and sheaves support batching kvfree_rcu() calls for slab objects, implement kfree_rcu_nolock() with minimal changes by teaching kfree_rcu_sheaf() how to support unknown context and making it a little bit harder to allocate an empty sheaf, instead of making intrusive changes to the existing kvfree_rcu batching logic. kfree_rcu_nolock() tries to free the object to the rcu sheaf if trylock succeeds. Once the rcu sheaf becomes full, it is submitted to RCU via call_rcu() if spinning is allowed or IRQs are enabled (to avoid calling call_rcu() in the middle of call_rcu()). Otherwise, call_rcu() is deferred via irq work. When there is no sheaf available, kfree_rcu_sheaf() falls back to defer_kfree_rcu(). It submits the object to kvfree_rcu batching via irq work. To do this, patch 6 converts kvfree_rcu to use kvfree_rcu_head without visible changes to the API for now. Unlike kfree_rcu(), only the 2-argument variant is supported. This is because the last resort of the 1-arg variant is synchronize_rcu(), which cannot be used in an unknown context. As suggested by Alexei Starovoitov, kfree_rcu_nolock() can be used with struct kvfree_rcu_head (8 bytes), which is smaller than struct rcu_head (16 bytes). Link: https://lore.kernel.org/all/20260729-kfree_rcu_nolock-v5-0-a28cdcda9673@kernel.org/ [1] commit 160dcfe7f94346623abe9e3c9cb4173908698422 Merge: 7e98f856395618 a6172cca157f3f Author: Vlastimil Babka (SUSE) Date: Mon Aug 24 14:57:07 2026 +0200 Merge branch 'slab/for-7.3/objext_split' into slab/for-next Merge series "mm/slab, alloc_tag: reduce obj_ext memory waste" from myself. From the cover letter [1]: It's been bothering me that the memory usage of struct slabobj_ext depend only on config options and not whether the fields are actually used. So with both CONFIG_MEMCG=y and CONFIG_MEM_ALLOC_PROFILING=y there is always objcg field and codetag_ref field. And thus: 1) Having memory allocation profiling config-enabled but not boot-enabled means wasted memory on unused codetag_refs. This makes it less suitable for a general distro config and the page allocator side doesn't suffer from this, only slab and percpu. 2) Complementary, with memory allocation profiling enabled, there are caches/slabs that don't need the objcg field, so memory is wasted on those. This series should solve the point 1) fully for slab; pcpuobj_ext handling can be perhaps improved similarly, haven't looked into that. For 2) it avoids allocating objcg fields for KMALLOC_NORMAL and KMALLOC_NO_OBJ_EXT caches where we know they are not necessary because kmalloc() with __GFP_ACCOUNT will pick a KMALLOC_CGROUP type (except with SLUB_TINY). The named kmem_caches are tricky. They can be created with SLAB_ACCOUNT and then we know objcg fields are always needed. But also they can be created without SLAB_ACCOUNT and then some allocations have __GFP_ACCOUNT and some not and we don't know that in advance. This series introduces a SLAB_MAY_ACCOUNT flag that's currently internal only and is applied to all caches (unless kmem accounting is disabled) except KMALLOC_NORMAL (unless that aliases KMALLOC_RECLAIM) and KMALLOC_NO_OBJ_EXT. As a followup we can make SLAB_MAY_ACCOUNT explicit and add it to to caches where we know __GFP_ACCOUNT is used. Then we could only honour __GFP_ACCOUNT for those, while warning for an unexpected usage elsewhere. To check for regressions, I forward-ported a microbenchmark hacked into slub_kunit that was used to evaluate sheaves. Tried 3 scenarios, MEMCG and KFENCE were always enabled: - CONFIG_MEM_ALLOC_PROFILING=n - CONFIG_MEM_ALLOC_PROFILING=y but _ENABLED_BY_DEFAULT=n - same but booted with sysctl.vm.mem_profiling=1 The results are quite noisy, but no regression was apparent, except perhaps few percents for the last case. I don't expect it will be visible in any real workloads. Link: https://lore.kernel.org/all/20260727-b4-objext_split-v3-0-c29ef0f1f257@kernel.org/ [1] commit c9e17e381e021536a9f0fe36f4c9c693d6c0f27c Author: Daniel Palmer Date: Mon Jul 13 22:39:19 2026 +0900 rtc: msc313: Select by default on MSTARV7 All of the ARCH_MSTARV7 chips have this RTC so it's more likely ARCH_MSTARV7 wants it than doesn't. At the same time fix up the indent on the depends on line that looks like it got converted from a tab to spaces at some point. Signed-off-by: Daniel Palmer Link: https://patch.msgid.link/20260713133919.1356748-1-daniel@thingy.jp Signed-off-by: Alexandre Belloni commit 93847823b6761e1791a7db10f55bbd4f79fa0dbc Author: Babanpreet Singh Date: Fri Aug 21 05:03:23 2026 +0000 tee: qcomtee: fix kernel-doc warnings Fix kernel-doc issues present since the driver was added in commit d6e290837e50 ("tee: add Qualcomm TEE driver"): - async_release() documents its second parameter as @msg, but the parameter is named async_msg (msg is a local variable); - struct qcomtee_msg_object_invoke documents member @ctx, but the member is named cxt; - enum qcomtee_arg_type leaves QCOMTEE_ARG_TYPE_NR undescribed. The cxt spelling is part of the QTEE message format and is used throughout the driver; struct qcomtee_msg_callback in the same header already documents it as @cxt, so the comment is corrected rather than the member. No functional changes. Fixes: d6e290837e50 ("tee: add Qualcomm TEE driver") Reviewed-by: Amirreza Zarrabi Assisted-by: Claude:claude-opus-5 [kernel-doc] Signed-off-by: Babanpreet Singh Signed-off-by: Jens Wiklander commit 8985cbc927fd3e23dfebaa099ae0b6d2b38d3258 Author: Baineng Shou Date: Mon Aug 17 13:04:57 2026 +0800 selftests: dmabuf-heaps: add fd-leak-on-EFAULT regression test Add a test case that verifies no file descriptor is leaked when DMA_HEAP_IOCTL_ALLOC succeeds internally but copy_to_user() fails to deliver the fd number back to userspace. The failure is triggered by placing the ioctl argument in a private anonymous page and flipping it to PROT_READ (via mprotect) between the kernel's copy_from_user() and copy_to_user() calls. With the buggy kernel the ioctl returns -EFAULT but leaves an extra open fd in the process's fd table; with the fixed kernel the fd count is unchanged. This serves as a regression test for: "dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds" Suggested-by: Sumit Semwal Reviewed-by: T.J. Mercier Acked-by: Sumit Semwal Signed-off-by: Baineng Shou Link: https://lore.kernel.org/r/20260817050457.1005285-5-shoubaineng@gmail.com Signed-off-by: Christian König commit 3e164bf592bbbdde269c5cadc60a96f69cc6eed7 Author: Baineng Shou Date: Mon Aug 17 13:04:56 2026 +0800 drm/prime: use dma_buf_fd_install() to preserve export tracing drm_gem_prime_handle_to_fd() open-codes fd reservation and install using get_unused_fd_flags() + fd_install() directly. This bypasses the DMA_BUF_TRACE() call that dma_buf_fd() emits, so observability tools relying on the trace_dma_buf_fd tracepoint silently miss all DRM PRIME exports. Replace the bare fd_install() with dma_buf_fd_install(), which wraps fd_install() together with DMA_BUF_TRACE(), restoring full tracepoint coverage. No functional change; the fd lifecycle (get_unused_fd_flags → work → install) is already correct. Note: this patch depends on dma_buf_fd_install() introduced in "dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds" [1]. [1] https://lore.kernel.org/dri-devel/20260714114654.3885457-2-shoubaineng@gmail.com/ Suggested-by: Christian König Acked-by: Sumit Semwal Reviewed-by: Christian König Signed-off-by: Baineng Shou Link: https://lore.kernel.org/r/20260817050457.1005285-4-shoubaineng@gmail.com Signed-off-by: Christian König commit eb049bdbf2b98d103d93daef44a5e1a0164d01eb Author: Anthony Iliopoulos Date: Thu Aug 20 14:36:51 2026 +0200 xtensa: remove unused setup_profiling_timer function setup_profiling_timer() is not used by any code at this point. Since a default weak implementation exists, there is no need to keep this arch-specific definition around. Remove it along with the now-redundant profile header includes. Signed-off-by: Anthony Iliopoulos Message-ID: <20260820123711.142005-1-ailiop@suse.com> Signed-off-by: Max Filippov commit a4a1a2bfcb29785292d634d7787edc6fb550714d Author: Baineng Shou Date: Mon Aug 17 13:04:55 2026 +0800 misc: fastrpc: don't publish fd before copy_to_user() succeeds fastrpc_ioctl_alloc_dmabuf() calls dma_buf_fd() which installs the fd into the caller's fd table before copy_to_user() copies the fd number back to userspace. If copy_to_user() fails, the fd is already visible to other threads in the same process but the ioctl returns -EFAULT. The existing comment in the code even acknowledges the problem: "The usercopy failed, but we can't do much about it, as dma_buf_fd() already called fd_install()..." Now that dma_buf_fd_install() is available (introduced to fix the same issue in dma-heap), apply the same pattern here: reserve the fd with get_unused_fd_flags(), attempt copy_to_user(), and only on success call dma_buf_fd_install() to publish it atomically with the tracepoint. On copy_to_user() failure, put_unused_fd() and dma_buf_put() cleanly unwind without any user-visible side effects. Fixes: 6cffd79504ce ("misc: fastrpc: Add support for dmabuf exporter") Cc: stable@vger.kernel.org Acked-by: Christian König Acked-by: Sumit Semwal Signed-off-by: Baineng Shou Link: https://lore.kernel.org/r/20260817050457.1005285-3-shoubaineng@gmail.com Signed-off-by: Christian König commit 30d0aff2c65a277135cfd8ea28fa1ee75e0ea4e0 Author: Baineng Shou Date: Mon Aug 17 13:04:54 2026 +0800 dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/ remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/ Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework") Cc: stable@vger.kernel.org Reviewed-by: T.J. Mercier Acked-by: Christian König Acked-by: Sumit Semwal Signed-off-by: Baineng Shou Link: https://lore.kernel.org/r/20260817050457.1005285-2-shoubaineng@gmail.com Signed-off-by: Christian König commit 94e6a058b16820e02f25e1221a4c4e713ba23550 Author: Helge Deller Date: Sat Aug 22 12:03:15 2026 +0200 fbcon: Fix KASAN slab-out-of-bounds Read in fbcon_prepare_logo Ensure the logo will not exceed the screen size, which then should fix a reported KASAN: slab-out-of-bounds Read in fbcon_prepare_logo. Reported-by: syzbot+0c815b25cdb3678e7083@syzkaller.appspotmail.com Signed-off-by: Helge Deller commit 72e91bba1190c91c76ef2f81476399eb66b87ed2 Author: Helge Deller Date: Sat Aug 22 11:43:08 2026 +0200 fbdev: omapfb: Fix __be32 sparse warning in panel_enabled() This commit resolves a sparse warning in panel_enabled() by explicitly reading the display status into a __be32 variable. It then converts this value to CPU endianness using __be32_to_cpu() before checking the bits. This should fix this sparse warning: ../omapfb/displays/panel-sony-acx565akm.c:218:23: sparse: sparse: cast to restricted __be32 Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202608211811.lps93xao-lkp@intel.com/ Signed-off-by: Helge Deller commit 7dd6343fc127935425a81a8f1989907996c2868d Author: Younes Akhouayri Date: Sat Aug 22 10:44:47 2026 +0200 rust: num: restrict bool conversion to unsigned Bounded From turns true into 1. A signed Bounded with N = 1 can hold only -1 and 0. The current implementation can therefore create a value that breaks Bounded's invariant. Deref relies on that invariant and calls unreachable_unchecked() when it is broken, so safe Rust can reach undefined behavior. The other primitive conversions require the source and destination to have the same signedness. Treat bool as an unsigned one-bit value and allow conversions between bool and Bounded only when the backing integer type is unsigned. Fixes: 01e345e82ec3 ("rust: num: add Bounded integer wrapping type") Closes: https://lore.kernel.org/rust-for-linux/OzuVxu0--J-9@younes.io/ Cc: stable@vger.kernel.org Suggested-by: Alexandre Courbot Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Younes Akhouayri Reviewed-by: Alexandre Courbot Link: https://patch.msgid.link/20260822-fix-rust-bounded-from-bool-submit-v4-1-aa780bfe7f30@younes.io Signed-off-by: Miguel Ojeda commit 46094a7708b7945cb7eba9eb887e3ea9757440a7 Author: Peter Zijlstra Date: Mon Aug 24 12:49:10 2026 +0200 locking: Revert switching guards to _irq_{disable,enable}() Revert commit 1b0866874833 ("locking: Switch to _irq_{disable,enable}() variants in cleanup guards"). While the guards are properly nested, not all wrapped code is nice, as already highlighted by that fair.c hunk. Syzbot found another instance of this pattern in posix_timer_delete(), which does spin_unlock_irq()+spin_lock_irq() inside scoped_guard(spinlock_irq). Combined with this patch, that goes sideways most spectacular. Undo this until we've developed stronger tools / debug for such issues. Fixes: 1b0866874833 ("locking: Switch to _irq_{disable,enable}() variants in cleanup guards") Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260824105523.GA4121620%40noisy.programming.kicks-ass.net commit 1b04ca2aca2d4015e7e1e17e7911f9484fe16fd9 Author: Mark Brown Date: Tue Aug 18 19:42:09 2026 +0100 io_uring: Add missing include for ITER_SOURCE and ITER_DEST Fix IWYU issues: /tmp/next/build/include/linux/io_uring_types.h:56:32: error: 'ITER_DEST' undeclared here (not in a function) 56 | IO_BUF_DEST = 1 << ITER_DEST, | ^~~~~~~~~ /tmp/next/build/include/linux/io_uring_types.h:57:32: error: 'ITER_SOURCE' undeclared here (not in a function) 57 | IO_BUF_SOURCE = 1 << ITER_SOURCE, | ^~~~~~~~~~~ Fixes: 95961b72c57b2 ("io_uring/rsrc: rename and export IO_IMU_DEST / IO_IMU_SOURCE") Signed-off-by: Mark Brown Signed-off-by: Miklos Szeredi commit 916b61abba586d950a4d8264e2841cc5ccfa4df1 Author: Sumeet Pawnikar Date: Sat Aug 22 15:16:57 2026 +0530 powercap: intel_rapl: Fix kernel panic during PMU unbind rapl_package_add_pmu() fails internally at perf_pmu_register(), and rapl_pmu_update() leaves the global rapl_pmu.pmu structure zero-initialized via memset and returns an error. But any previously probed packages retain has_pmu = true. When the driver is subsequently unbound or removed, rapl_package_remove_pmu_locked() sees has_pmu == true and unconditionally calls perf_pmu_unregister(&rapl_pmu.pmu) on the zeroed-out structure. This attempts a list_del_rcu() on a NULL list head, immediately causing a kernel panic. Fix this by checking if the PMU is actually registered before attempting to unregister it. Signed-off-by: Sumeet Pawnikar Reviewed-by: Abel Vesa [ rjw: Added empty line after the new conditional ] Link: https://patch.msgid.link/20260822094657.12489-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki commit 41a9c2b48e258ed97e9a7153110ab583a2f3145b Author: Andreas Hindborg Date: Wed Aug 12 13:21:51 2026 +0200 MAINTAINERS: configfs: split configfs entry in C and Rust parts Split configfs MAINTAINERS entry in C and Rust parts. Mark Breno Leitao as maintainer of configfs C parts. Mark Andreas Hindborg as maintainer of configfs Rust parts. Acked-by: Breno Leitao Signed-off-by: Andreas Hindborg commit 1f59015e958174e89be58cc8db16d70a60d17255 Author: Bernd Schubert Date: Fri Aug 21 18:19:09 2026 +0200 fuse: Fix the condition to enable over-io-uring 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 commit 26d7e1f5c407b5859122b5cd47d7ebbf4b4c1cd2 Author: Baokun Li Date: Wed Aug 19 17:07:28 2026 +0800 fuse: invalidate the correct range after O_APPEND direct write fuse_direct_write_iter() captures pos before generic_write_checks(), which moves ki_pos to EOF for O_APPEND writes: fuse_direct_write_iter() { pos = iocb->ki_pos; /* 0 (user-supplied) */ generic_write_checks(); /* ki_pos -> EOF */ fuse_direct_io(); /* writes at EOF, correct */ invalidate(pos, pos + res); /* [0, res) -- wrong */ } The post-write invalidation targets a stale range instead of the actual written range at EOF. This can cause data inconsistency when the file size is not page-aligned. The tail page straddling EOF has a valid portion before EOF that concurrent readers can fault back in during the DIO write window: Tail page (file size X not page-aligned): page_start X (EOF) page_end |--- valid data ----|-- stale --| CPU0 (O_APPEND DIO writer) CPU1 (buffered reader) -------------------------- ---------------------- invalidate [X, X+len) tail page evicted FUSE_WRITE in flight ... read [page_start, X) tail page re-faulted [X, page_end) = stale FUSE_WRITE completes i_size = X + len invalidate [0, len) <- WRONG tail page still cached read [X, X+len) hits stale tail page returns old data Fix by reading pos back from iocb->ki_pos after generic_write_checks(), as generic_file_direct_write() does. Also fix a typo in the comment ("may have" -> "may have competed"). Fixes: 2b0408d0284f ("fuse: invalidate page cache after DIO and async DIO writes") Signed-off-by: Baokun Li Reviewed-by: Bernd Schubert Signed-off-by: Miklos Szeredi commit 60dbcce1567f6502215b36ba4066e8fd1f86d706 Author: Jimmy Zuber Date: Fri Jul 31 20:38:42 2026 +0000 selftests/fuse: test post-EOF page zeroing when a file is extended Add a regression test for the bug where extending a file left the tail of the old partial EOF page exposing stale mmap-dirtied data instead of zeros. The test is a self-contained raw /dev/fuse server (no libfuse dependency) that runs without writeback_cache and returns FOPEN_KEEP_CACHE, the configuration in which the bug is visible. Its backing data is always zero in the hole, so any non-zero byte a read sees is stale page-cache data. All offsets are relative to the runtime page size. Four cases: - write_extend: pollute the post-EOF tail, extend past it by writing into a later page, and verify the tail reads back as zero; - ftruncate_extend: same, but extend via ftruncate(); - fallocate_extend: same, but extend via fallocate() at the old EOF; - extend_into_eof_page_preserves_data: an extending write landing inside the old EOF page must not be clobbered by the zeroing. Each case fails without the fix and passes with it. Signed-off-by: Jimmy Zuber Signed-off-by: Miklos Szeredi commit e72d5659a2606056a0c34af212b46a3275a55bbf Author: Eckhart Mohr Date: Fri Aug 21 16:44:34 2026 +0200 ALSA: hda/realtek: Add quirk for TongFang XxAF5xxx Fix microphone detection on built in headphone jack for some devices Signed-off-by: Eckhart Mohr Cc: stable@vger.kernel.org Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260821144437.27233-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai commit f89416eb3db151170a6f3c6dfc5239d26cdce4d2 Author: Maher Azzouzi Date: Mon Aug 17 14:37:52 2026 +0100 esp: downgrade zerocopy managed frags before mutating skb frags On the out-of-place output path (esp->inplace == false) ESP rewrites the skb frag array: esp_output_head() appends a trailer frag and esp_output_tail() replaces the frags with a destination page, both referenced with get_page(). When the skb carries zerocopy managed frags (SKBFL_MANAGED_FRAG_REFS) the payload frags are owned by the ubuf and must not be referenced or unreferenced individually, but ESP mutates the frag array without ever downgrading the skb. This breaks the managed-frag invariant two ways: - esp_ssg_unref() walks the source scatterlist and drops a page reference for every frag, including the ubuf-owned payload frags, pushing their refcount below the GUP pin bias while the pages are still pinned, i.e. a use-after-free of the zerocopy pages; - esp_output_tail() installs its destination page as frag 0 with get_page() but leaves SKBFL_MANAGED_FRAG_REFS set, so skb_release_data() takes the skip_unref branch and never drops that reference, leaking the x->xfrag page at packet rate. Fix this the way every other frag-mutating site does (__ip_append_data(), __ip6_append_data(), tcp_sendmsg_locked()) and call skb_zcopy_downgrade_managed() before ESP touches the frag array: it takes a real reference on each existing frag and clears SKBFL_MANAGED_FRAG_REFS, so the per-frag unref in esp_ssg_unref() and the frag release in skb_release_data() are both balanced and no mixed-ownership frag array is left behind. Fixes: 753f1ca4e1e5 ("net: introduce managed frags infrastructure") Signed-off-by: Maher Azzouzi Signed-off-by: Steffen Klassert commit 1035a8f63bae28e498b0e7b5ac91d749844a7158 Author: Marouane El Moufid Date: Sun Aug 23 13:55:48 2026 +0000 ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() snd_usbmidi_novation_output() lays out a two-byte header at transfer_buffer[0..1] and passes &transfer_buffer[2] together with a length of ep->max_transfer - 2 to snd_rawmidi_transmit(): count = snd_rawmidi_transmit(ep->ports[0].substream, &transfer_buffer[2], ep->max_transfer - 2); ep->max_transfer comes from the output endpoint's wMaxPacketSize via usb_maxpacket(). A malformed or malicious device can advertise a bulk OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this value downwards - so ep->max_transfer becomes 1 and the count argument becomes -1. snd_rawmidi_transmit() passes the negative count on to __snd_rawmidi_transmit_peek(), where "if (count1 > count) count1 = count" leaves count1 negative; get_aligned_size() keeps it negative for a byte-stream substream, so the following memcpy(buffer, ..., count1) runs with a (size_t)-1 length and writes far past the transfer buffer, which was allocated with usb_alloc_coherent(ep->max_transfer). This is the same class of bug that was fixed for snd_usbmidi_akai_output() in commit 0970274613fb ("ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()"); the novation output routine was left unguarded. Bail out when the endpoint cannot hold the two-byte header plus at least one payload byte. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Marouane El Moufid Link: https://patch.msgid.link/178749334830.543645.13722252148340572274@espilon.net Signed-off-by: Takashi Iwai commit 2afb8dc1f4390f164db8352f8e685e126e9db566 Author: Siwei Zhang Date: Thu Jul 30 19:40:08 2026 +0800 xfrm: use hlist_del_init_rcu for state_cache and state_cache_input Commit 14acf9652e56 ("xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete") converted bydst/bysrc/byseq/byspi from hlist_del_rcu() to hlist_del_init_rcu() so that a second __xfrm_state_delete() on the same object becomes a no-op rather than a write through LIST_POISON pprev. It missed state_cache and state_cache_input, which kept hlist_del_rcu(): - hlist_del_rcu() leaves pprev = LIST_POISON2 (non-NULL), so hlist_unhashed() returns false. - hlist_del_init_rcu() leaves pprev = NULL, so hlist_unhashed() returns true. A second __xfrm_state_delete() therefore enters __hlist_del() on the already-deleted state_cache/state_cache_input nodes and does WRITE_ONCE(*pprev, next) through LIST_POISON2 — a write use-after-free once the slab is reused. The corruption can in turn cause a subsequent hlist_for_each_entry_rcu traversal to follow a dangling next pointer, producing the read use-after-free reported in xfrm_input_state_lookup(). Switch state_cache and state_cache_input to hlist_del_init_rcu() to match the other four lists, closing the write use-after-free and, with it, the read use-after-free it spawns. Assisted-by: CodeBuddy:GLM-5.2 Fixes: 0045e3d80613 ("xfrm: Cache used outbound xfrm states at the policy.") Fixes: 81a331a0e72d ("xfrm: Add an inbound percpu state cache.") Cc: stable@vger.kernel.org Signed-off-by: Siwei Zhang Signed-off-by: Steffen Klassert commit a7d28aa0e9b2c983b915d091f9596f0e3b253355 Author: Gao Xiang Date: Sun Aug 23 22:23:05 2026 +0800 erofs: simplify z_erofs_gbuf_growsize() - Use guard(mutex)() to manage gbuf_resize_mutex; - Nullify tmp_pages after successful allocation, so that the error path becomes clearer. Reviewed-by: Chao Yu Signed-off-by: Gao Xiang commit a7d097cf01301c5da37927c8f26123d006f0fd8a Author: Nikhil Gurudasani Date: Sat Aug 22 19:30:17 2026 +0530 erofs: skip sufficiently large global buffers when resizing z_erofs_gbuf_nrpages is advanced only after every global buffer has been grown. If a resize fails after some buffers were enlarged, a retry revisits those enlarged buffers. Retrying the same size then returns -ENOMEM because alloc_pages_bulk() has no pages to add and the unchanged return value is treated as a failure. Retrying an intermediate size allocates a temporary pointer array smaller than gbuf->nrpages and copies more existing pointers than the array can hold. Skip buffers that already satisfy the request. Once all remaining buffers have caught up, advancing z_erofs_gbuf_nrpages again describes the guaranteed minimum size across the pool. Fixes: d6db47e571dc ("erofs: do not use pagepool in z_erofs_gbuf_growsize()") Cc: stable@vger.kernel.org # 6.10+ Signed-off-by: Nikhil Gurudasani Reviewed-by: Gao Xiang Reviewed-by: Chao Yu Signed-off-by: Gao Xiang commit c77516e1e6fe914eb74d5f7a8ba9851f4ce31867 Author: Jingbo Xu Date: Fri Aug 21 19:25:40 2026 +0800 erofs: support large folios in inode_share mode erofs_fill_inode() calls mapping_set_large_folios() on each erofs file's own mapping, but in inode_share mode reads are routed to the shared inode's page cache instead, whose mapping never had large folio support enabled. Set up large folios for the shared inode's mapping as well. Signed-off-by: Jingbo Xu Reviewed-by: Gao Xiang Reviewed-by: Chao Yu Signed-off-by: Gao Xiang commit e8325399d6e18d2acc670999632a461d424611b9 Author: Zhan Xusheng Date: Fri Aug 21 09:56:41 2026 +0800 erofs: support splice() in inode_share mode erofs_ishare_fops routes everything that touches the page cache to the backing file in ->private_data: read_iter clones the iocb onto it, mmap does vma_set_file(), fadvise calls vfs_fadvise() on it. splice_read was left as filemap_splice_read(), which works on the user file's own mapping: it does init_sync_kiocb(&iocb, in), and filemap_get_pages() then takes iocb->ki_filp->f_mapping. So splice() and sendfile() fill the per-inode page cache rather than the shared one. The content is the same either way, since erofs_fill_inode() sets a_ops on that mapping too, which is why this went unnoticed. Two identical 8 MiB files under inode_share, reading one of them with splice(2) alone, in pages: before own 2048 shared 0 after own 0 shared 2048 "own" is cachestat(fd), which reports the file's own mapping; "shared" is mmap()+mincore(), which erofs_ishare_mmap() redirects to the backing file. Read through the backing file, as read_iter already does. Link: https://lore.kernel.org/all/b7dc7192-d586-45a2-bc4a-b41dc681c9bb@linux.alibaba.com/ Signed-off-by: Zhan Xusheng Reviewed-by: Jingbo Xu Reviewed-by: Chao Yu Signed-off-by: Gao Xiang commit 8ebf9589788575f8868c236d077dbe612395e084 Author: Jingbo Xu Date: Thu Aug 20 21:40:06 2026 +0800 erofs: support SEEK_HOLE/SEEK_DATA in inode_share mode When inode_share is enabled, erofs_ishare_fops.llseek falls back to generic_file_llseek, which treats the whole file as data and always returns i_size for SEEK_HOLE, hiding real holes in sparse files. Switch it to erofs_file_llseek instead. For user files f_mapping->host is always the real erofs inode, so SEEK_HOLE/SEEK_DATA resolve the per-file on-disk layout via iomap_seek_hole()/iomap_seek_data(). Reviewed-by: Gao Xiang Signed-off-by: Jingbo Xu Reviewed-by: Chao Yu Signed-off-by: Gao Xiang commit ab74edaeb1ae7c7194e79007e6afdfe788111a3f Author: Geert Uytterhoeven Date: Thu Aug 20 12:00:23 2026 +0200 erofs: Fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS default logic When NR_CPUS is less than 16, or when SMP is disabled, the default value of 16 is invalid. While actual configuration picks up a sensible and valid default (NR_CPUS or 1), "make savedefconfig" will still write a line like CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1 to the defconfig file, even if that matches the sensible default. Avoid needlessly enlarging the defconfig files, and reduce churn for updating them, by specifying valid defaults depending on SMP and NR_CPUS. While at it, make the prompt depend on SMP, as there is no point in asking the user about the maximum number of decompression streams if there is only one valid answer. Fixes: c9b47e6b23114e93 ("erofs: cap LZMA stream pool size") Signed-off-by: Geert Uytterhoeven Reviewed-by: Guenter Roeck Reviewed-by: Chao Yu Signed-off-by: Gao Xiang commit 12e67eb89eb2b9516685c744d3f7de0a2d1bd701 Author: Chen Changcheng Date: Mon Jul 27 15:34:38 2026 +0800 scsi: snic: Fix SCSI host leak on workqueue allocation failure In snic_add_host(), if scsi_add_host() succeeds but alloc_ordered_workqueue() fails, the function returns -ENOMEM with shost->work_q left as NULL. The caller's error path then calls snic_del_host(), which returns early when !shost->work_q without calling scsi_remove_host(). The Scsi_Host remains registered in sysfs as a zombie device even after the probe has failed. This causes: - The leaked host remains visible in /sys/class/scsi_host/ after probe failure, with state "running". - Subsequent SCSI host numbering is permanently shifted (the leaked host ID from ida_alloc() is never reclaimed). - Memory leak: the Scsi_Host allocation can never be freed because device_add() took a reference that can only be released by device_del() inside scsi_remove_host(). Fix by adding scsi_remove_host() in the workqueue allocation failure path inside snic_add_host(), undoing the successful scsi_add_host() before returning the error. This is cleaner than modifying snic_del_host() because snic_del_host() is called from a shared error label that also serves paths where snic_add_host() was never invoked. Reproducer (requires no real SNIC hardware): - Build CONFIG_SCSI_SNIC=y (built-in) - Add snic.test_mode=1 snic.inject_wq_fail=1 to kernel cmdline - Boot with a PCI device matching the snic driver (e.g. QEMU edu device, PCI ID 0x1234:0x11e8, temporarily added to the driver's PCI ID table) Before the fix: # /sys/class/scsi_host/ contains a zombie host0: $ cat /sys/class/scsi_host/host0/proc_name snic_scsi $ cat /sys/class/scsi_host/host0/state running # ata_piix gets host1, host2 (host0 stuck): scsi host1: ata_piix scsi host2: ata_piix After the fix: # host0 is properly freed and reused by ata_piix: scsi host0: ata_piix scsi host1: ata_piix # No zombie host in /sys/class/scsi_host/ Signed-off-by: Chen Changcheng Acked-by: Narsimhulu Musini Link: https://patch.msgid.link/20260727073438.209673-1-chenchangcheng@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) commit df125bd16280b19835bfa2eef6504b505790f1f6 Author: Martin K. Petersen (Oracle) Date: Sun Aug 23 22:08:18 2026 -0400 scsi: MAINTAINERS: Update my email address Use my kernel.org address for Linux development. Signed-off-by: Martin K. Petersen (Oracle) commit 0a0d1d55dad570724bf8c7ea83409639cfb4be9b Merge: 83684c4e4d62cb 8b5b048277e2c4 Author: Linus Torvalds Date: Sun Aug 23 19:28:04 2026 -0700 Merge tag 'scftorture.2026.08.18a' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux Pull smp_call_function() torture-test updates from Paul McKenney: - Count single_rpc offline failures in statistics output - Make invoker threads actually wait for all threads to start * tag 'scftorture.2026.08.18a' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux: scftorture: Make invoker threads actually wait for all threads to start scftorture: Count single_rpc offline failures in statistics output commit 764587d7d76846716a568dea7ae48be1c50ecc18 Author: Finn Thain Date: Tue Aug 18 11:00:24 2026 +1000 scsi: MAINTAINERS: Leave the cumana_1 and oak drivers to the RISCPC maintainers The NCR5380 entry in MAINTAINERS includes drivers/scsi/arm/cumana_1.c and drivers/scsi/arm/oak.c. However, those two files are also covered by the drivers/scsi/arm/ pathname in the ARM/RISCPC entry. The latter entry is more effective than the former because, AIUI, neither Michael nor I have access to the necessary hardware. IMHO, such access is a pre-requisite for the 'maintainer' role for device drivers. To work on these particular drivers would require an old GCC compiler, having support for -march=armv3m, which is a problem for contributors. Cc: Michael Schmitz Cc: Russell King Cc: Arnd Bergmann Signed-off-by: Finn Thain Acked-by: Michael Schmitz Link: https://patch.msgid.link/935b08c0fb292888c06c2233570331f2ccadcd53.1787014824.git.fthain@linux-m68k.org Signed-off-by: Martin K. Petersen (Oracle) commit 46f861d300e87283f81faf9ee377d1e73682903d Author: Dongdong Hao Date: Fri Aug 14 17:05:26 2026 +0800 scsi: leapraid: Standardize NCQ priority sysfs attributes Replace the earlier LeapRAID ncq_cmd_prio_enable attribute with the standard sas_ncq_prio_supported and sas_ncq_prio_enable names documented in Documentation/ABI/testing/sysfs-block-device, and rename the per-device NCQ priority state to match. The earlier ncq_cmd_prio_enable name has not yet been established as part of a released userspace ABI, so no compatibility alias is needed. For LeapRAID, sas_ncq_prio_enable is backed by the driver's per-device NCQ priority state and controls whether RT-class I/O requests are issued with command priority on supported SATA devices. Update leapraid.rst to describe the standard attribute names and paths, and clean up the surrounding RST text for consistency with kernel documentation style. Also switch the capability check from open-coded VPD page 0x89 parsing to sas_ata_ncq_prio_supported(), use kstrtobool() for the enable path, and expose the NCQ priority attributes only for SATA devices using LeapRAID's target-private SAS device state. Reviewed-by: Damien Le Moal Signed-off-by: Dongdong Hao Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260814090526.395704-1-doubled@leap-io-kernel.com Signed-off-by: Martin K. Petersen (Oracle) commit 00b7c8d4ce441aa9ac704840332ba4738e1c6d51 Author: Linmao Li Date: Fri Aug 14 11:38:45 2026 +0800 scsi: leapraid: Serialize firmware log mmap with teardown leapraid_fw_log_exit() waits for mmap_refcnt to reach zero before it frees the firmware log buffer. leapraid_fw_mmap() checks host_removing, but it does not increment mmap_refcnt until after dma_mmap_coherent() succeeds and the VMA open callback runs. Removal can set host_removing and observe a zero mmap_refcnt between the check and the VMA open. It can then free the coherent buffer while the mmap path is still establishing a userspace mapping of it. Claim a temporary mmap reference while looking up the adapter under leapraid_adapter_lock. Removal deletes the adapter from the same locked list after setting host_removing, so a mapping is either rejected or included in the count that removal waits for. Drop the temporary reference on the common exit path, after a successful VMA open has acquired the reference covering the VMA lifetime. Fixes: 5597088c9e79 ("scsi: leapraid: Add new SCSI driver") Signed-off-by: Linmao Li Reviewed-by: Dongdong Hao Link: https://patch.msgid.link/20260814033845.2971706-3-lilinmao@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) commit 970f69b6bf71562df5afcefb89c77b4e971d68de Author: Linmao Li Date: Fri Aug 14 11:38:44 2026 +0800 scsi: leapraid: Balance host references for firmware log VMAs leapraid_fw_mmap() keeps the Scsi_Host reference obtained while looking up the adapter for the lifetime of the initial VMA. The VMA close callback drops that reference. The open callback is also invoked when a VMA is duplicated or split, but it only increments mmap_refcnt. Since every corresponding close callback drops a host reference, cloning the mapping can release the host while another VMA still refers to the adapter. Take a host device reference for every VMA open and release the lookup reference once the initial mapping has acquired its own reference. Use get_device() because a VMA can be cloned after the host enters SHOST_DEL; an existing VMA still pins the host at that point and open cannot fail. Fixes: 5597088c9e79 ("scsi: leapraid: Add new SCSI driver") Signed-off-by: Linmao Li Reviewed-by: Dongdong Hao Link: https://patch.msgid.link/20260814033845.2971706-2-lilinmao@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) commit 0ec418204f23f0a1dfff79d5f6721080ec006042 Author: Dan Carpenter Date: Thu Aug 13 10:09:32 2026 +0300 scsi: lpfc: Remove unnnecessary NULL check The "evt_dat" variale is non-NULL at this point so there is no need to check. Delete the check and pull the code in a tab. Signed-off-by: Dan Carpenter Reviewed-by: Paul Ely Link: https://patch.msgid.link/an1trOAUeQmYEus_@stanley.mountain Signed-off-by: Martin K. Petersen (Oracle) commit 11e48f5201fd86ffa038809dd9c41144d43ee2e4 Author: Dan Carpenter Date: Thu Aug 13 10:09:53 2026 +0300 scsi: qla2xxx: Fix an loop timeout test This loop timeout with "retries" set to -1, not 0. Fix the test for failure. Fixes: 7ec0effd30bb ("[SCSI] qla2xxx: Add support for ISP8044.") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/an1twcxTYSFkkUTA@stanley.mountain Signed-off-by: Martin K. Petersen (Oracle) commit ff9365a4c9991cca68fd48c7729808f2fdae2036 Author: Dan Carpenter Date: Thu Aug 13 10:08:27 2026 +0300 scsi: qla2xxx: Fix an error code in qla_get_tmf() Negative -EIO was intended instead of positive EIO. The caller, doesn't care so this doesn't affect runtime. It's just a cleanup. Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/an1taxANE_4_vzJT@stanley.mountain Signed-off-by: Martin K. Petersen (Oracle) commit 1ff8d3e3165fd077faa4259fd232bdddcd30249f Merge: e91d58cb2f470f 13087ad7817e6e Author: Dave Airlie Date: Mon Aug 24 11:40:14 2026 +1000 Merge tag 'drm-xe-next-fixes-2026-08-20' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Couple commits cleaning up error messages. Signed-off-by: Dave Airlie From: Rodrigo Vivi Link: https://patch.msgid.link/aocSC19By5UIIbTZ@intel.com commit b79b88b655a84187aed12d773566dabf5ab72ed6 Author: Nathan Chancellor Date: Mon Aug 17 12:04:55 2026 -0700 scsi: ibmvfc: Fix use of uninitialized rport in ibmvfc_do_work() After commit 696d1cc2aaa2 ("scsi: ibmvfc: process NVMe/FC rports in work thread"), clang warns (or errors with CONFIG_WERROR=y / W=e): drivers/scsi/ibmvscsi/ibmvfc-core.c:6154:15: error: variable 'rport' is uninitialized when used here [-Werror,-Wuninitialized] 6154 | } else if (rport && tgt->action == IBMVFC_TGT_ACTION_DEL_AND_LOGOUT_RPORT) { | ^~~~~ The check for rport is unnecessary in this block, it was accidentally included from copying and pasting. Remove it to clear up the warning. Fixes: 696d1cc2aaa2 ("scsi: ibmvfc: process NVMe/FC rports in work thread") Suggested-by: Tyrel Datwyler Link: https://lore.kernel.org/6ccbe8c5-beb6-483f-bfa4-c2d3819ad5f2@linux.ibm.com/ Signed-off-by: Nathan Chancellor Acked-by: Tyrel Datwyler Link: https://patch.msgid.link/20260817-ibmvscsi-rport-wuninitialized-v1-1-0fdfb27a5f01@kernel.org Signed-off-by: Martin K. Petersen (Oracle) commit d34a88f53a7ab0a4d84fbff137c9077701e95b06 Author: Bart Van Assche Date: Fri Aug 14 16:20:08 2026 +0000 scsi: core: Enable context analysis for hosts.o Enable compiler-based context analysis for drivers/scsi/hosts.c by setting CONTEXT_ANALYSIS_hosts.o := y in drivers/scsi/Makefile. The SCSI host management code in hosts.c now has the necessary lock context annotations (such as __must_hold(shost->host_lock) on scsi_host_set_state) and conforms to compile-time lock checking rules. It builds cleanly without triggering any context analysis warnings. Enable context analysis for hosts.o so that lock correctness and context safety invariants for SCSI host operations are verified at compile time when CONFIG_WARN_CONTEXT_ANALYSIS is enabled. Fixes: fb0fc67db962 ("scsi: core: Enable context analysis") Reported-by: John Garry Signed-off-by: Bart Van Assche Reviewed-by: John Garry Link: https://patch.msgid.link/3e1c3c0ca9307e2581cf4b96cf3fcdae35202255.1786724393.git.bvanassche@acm.org Signed-off-by: Martin K. Petersen (Oracle) commit e91d58cb2f470fe15bd4e02a26d44e9aaf771346 Merge: bb11536efd7dbd 140b1347530260 Author: Dave Airlie Date: Mon Aug 24 11:21:11 2026 +1000 Merge tag 'drm-msm-next-2026-08-01' of https://gitlab.freedesktop.org/drm/msm into drm-next Changes for v7.3 Bindings: - Added Shikra support - Document a840, a704, a722 Core: - Use drm_client buffers for fbdev emulation - teardown fixes - ARM32 DMA fixup - Remove objects from evict list when re-validated - Bunch of corner case and error path fixes DPU: - Dropped dev_pm_opp_set_rate(0) preventing burnout - Fixed SSPP offsets of Kaanapali DP: - Dropped dev_pm_opp_set_rate(0) preventing burnout - Cleaned up core code in preparation for MST support - Fixed prepare() to let Pipewire continue in case of the unplugged cable GPU: - Add support for a704 - Add support for a722 HDMI: - Simplifed register access Signed-off-by: Dave Airlie From: Rob Clark Link: https://patch.msgid.link/CACSVV02Kp=J+w_RjEJbBbQnBYRb+SWdwMvVbCaAL70bq9EBagQ@mail.gmail.com commit bb11536efd7dbde13a8a168c66881a9b8131dd81 Merge: 22e48eeaf4851a 271e90eb5f9ff3 Author: Dave Airlie Date: Mon Aug 24 11:19:43 2026 +1000 Merge tag 'drm-misc-next-fixes-2026-08-20' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next One patch to remove a WARN in favour of drm_warn. Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patch.msgid.link/20260820-fabulous-nimble-woodpecker-ffa695@houat commit 83684c4e4d62cb02b2e4d0d18963d1035439278e Merge: 4352b8aee98005 9cc63f8bcd560c Author: Linus Torvalds Date: Sun Aug 23 18:00:22 2026 -0700 Merge tag 'rcu.2026.08.18a' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux Pull RCU updates from Paul McKenney: "Make expedited grace periods expedite normal RCU callbacks Miscellaneous fixes: - Improve diagnostic output with character task states - Mark accesses to inform KCSAN of concurrency design - Move from kmalloc() to kmalloc_obj() - Documentation updates - Improve handling of RCU deferred quiescent states - Clean up unused function arguments and structure fields - Reduce show_rcu_gp_kthreads() stack space Tasks RCU updates: - Clean up after SRCU re-implementation of Tasks Trace RCU - Mark accesses to inform KCSAN of concurrency design - Add ->lazy_timer status to diagnostic output - Remove an unnecessary memory barrier - Fix a data race, courtesy of KCSAN - Documentation updates - Convert cond_resched_tasks_rcu_qs() from macro to static inline function SRCU updates: - Add Rust helpers for SRCU - Avoid losing queued work at cleanup_srcu_struct() time Torture-test updates: - Preparation work for immediate RCU priority deboosting - Test RCU readers from real interrupt handlers (as opposed to softirq) - Simplify code through use of cpumask_next_wrap() - Improve diagnostic output with character task states - Add rcutorture.nwriters parameter to allow lightweight stall testing, and rcutorture.stall_only to make doing so easier - Test an RCU Tasks Trace grace period implying an RCU grace period - Make RCU Tasks Trace torturing track reader batches - Fix a data race, courtesy of KCSAN - Plug a shuffle_tmp_mask memory leak on kthread spawn failure" * tag 'rcu.2026.08.18a' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux: (59 commits) rcu: Add closing parenthesis in comment in rcu_read_unlock_strict() rcutorture: Make {,s}rcu_read_delay() better handle forward-progress testing rcutorture: Announce declining to forward-progress test torture: Don't leak shuffle_tmp_mask when shuffler kthread fails to start rcutorture: Use this_cpu_inc() for rcu_torture_count[] and rcu_torture_batch[] rcutorture: Make RCU Tasks Trace track Reader Batches rcutorture: Test RCU Tasks Trace GP implying RCU GP rcutorture: Add a stall_only module parameter rcutorture: Add nwriters module parameter rcutorture: Use task_state_to_char() for task-state reporting rcutorture: Use cpumask_next_wrap() in rcu_torture_preempt() rcutorture: Test RCU readers from hardware interrupt handlers rcutorture: Check for immediate deboosting at reader end srcu: Queue sdp->work when the delay timer is successfully deleted rcu-tasks: Convert cond_resched_tasks_rcu_qs() to static inline rcu-tasks: Fix some comments for call_rcu_tasks() and call_rcu_tasks_rude() rcu-tasks: Rename tasks_rcu_exit_srcu_stall_timer to tasks_rcu_exit_stall_timer rcu: Mark interrupts-enabled accesses to rdp->cpu_no_qs.s rcu: Reduce stack usage in show_rcu_gp_kthreads() rcu: Mark accesses to ->rcu_urgent_qs and ->rcu_need_heavy_qs ... commit be0cfab740e58b70047ef6e7e3d578f00ed5d258 Author: Michael Kelley Date: Wed Aug 5 13:37:51 2026 -0700 clocksource: hyper-v: Remove support for stimer interrupts in message mode In Hyper-V versions prior to WS2016/Win10, Hyper-V synthetic timers interrupt the guest by delivering a message that is initially handled by the Linux VMBus driver. Starting with WS2016/Win10, Hyper-V can deliver stimer interrupts directly to an assigned interrupt vector without involving the VMBus driver. This is called "Direct Mode". With the overall removal of Linux support for running on Hyper-V hosts earlier than WS2016 and Windows 10, it's no longer necessary to support the legacy message-based delivery. Remove that delivery mechanism and always use Direct Mode. If for some reason, the Hyper-V host does not enumerate Direct Mode, output an error message but continue to run using the LAPIC timer instead of an stimer. With these changes, the VMBus driver no longer calls the stimer interrupt service routine. This removal has a broader benefit in unblocking the disentangling of VMBus code and stimer code, as they should be independent of each other. The final disentangling will come as a follow-on patch set. Signed-off-by: Michael Kelley Signed-off-by: Wei Liu commit 54cf8154186f0267f084a46d21752d5973a25f62 Author: Michael Kelley Date: Wed Aug 5 13:37:50 2026 -0700 scsi: storvsc: Remove support for storvsc protocol of old Hyper-V hosts With the overall removal of Linux support for running on Hyper-V hosts earlier than WS2016 and Windows 10, it's no longer necessary to support older storvsc protocols. Remove the support and associated special case code. However, support for the protocol for Windows Server 2012R2 and Win8.1 (protocol version 6.0) is *not* removed because it is activiely used by HvLite in the paravisor for Azure VMs. Signed-off-by: Michael Kelley Signed-off-by: Wei Liu commit 6b8345035d9de59b46c439bd117a4bec53e66bdc Author: Michael Kelley Date: Wed Aug 5 13:37:48 2026 -0700 hv_netvsc: Remove GPADL teardown special case for old Hyper-V hosts With the overall removal of Linux support for running on Hyper-V hosts earlier than WS2016 and Windows 10, the special case handling of GPADL teardown is no longer necessary. Remove it. Signed-off-by: Michael Kelley Signed-off-by: Wei Liu commit 73da9973b353abf2fed5038d38fa403fc6944339 Author: Michael Kelley Date: Wed Aug 5 13:37:47 2026 -0700 hv_sock: Remove check for old Hyper-V hosts With the overall removal of Linux support for running on Hyper-V hosts earlier than WS2016 and Windows 10, the check for such versions during hv_sock initialization is no longer necessary. Remove the check. Signed-off-by: Michael Kelley Signed-off-by: Wei Liu commit a9a05e801efffe3a2f949fef2a83f855e733d6e1 Author: Michael Kelley Date: Wed Aug 5 13:37:46 2026 -0700 Drivers: hv: Remove support for WS2012/2012R2 & Win8/8.1 version of Hyper-V Linux code for running as a Hyper-V guest includes special cases for running on Hyper-V in WS2012/2012R2 and Windows 8/8.1. These versions were initially released 14 years ago, and official support ended in 2023 (unless a customer has contracted for extended security updates). Given the release of subsequent versions with improved functionality, there's no need to continue to support the latest Linux kernels on these versions of Hyper-V. If someone is running Linux on one of these older Hyper-V versions and doesn't want to upgrade, they can continue to do so as presumably they don't want upgrade the Linux version either. Simplify Linux code by removing special cases for running on these old versions of Hyper-V. Remove the negotiation of the VMBus protocol versions for WS2012/Win8, and remove special case code based on those VMBus protocol versions. Also update the balloon and snapshot drivers to no longer negotiate driver-specific protocol versions for these older Hyper-V versions, and remove any related special cases. Signed-off-by: Michael Kelley Signed-off-by: Wei Liu commit f85e1cc5ecbbbb18ac68639f667c9de49b3ca986 Author: Kameron Carr Date: Tue Aug 11 09:04:47 2026 -0700 hv_netvsc: Allocate send/receive buffers using vmbus_alloc_buffer() On CoCo VMs without confidential VMBus, the netvsc send and receive buffers must be made host-visible by decrypting them. These buffers are vmalloc'ed, but set_memory_decrypted()/encrypted() do not work on vmalloc'ed memory. This use case is (so far) unique to netvsc, so solve it locally rather than changing the set_memory() or allocation APIs. Use vmbus_alloc_buffer() to allocate the send and receive buffers, which will make them host-visible. Store the list of memory chunks in the netvsc_device struct so they can be individually freed later. Use vmbus_establish_gpadl_caller_decrypted() so there is no attempt to decrypt the virtual address. Appropriately free the buffers with vmbus_free_buffer(). Because vunmap() and set_memory_encrypted() must run in process context, replace the rcu_head/call_rcu() pair used to defer free_netvsc_device() with rcu_work/queue_rcu_work(). This also fixes a small race condition where the buffers may be accessed while being re-encrypted by moving the re-encryption after the RCU grace period. Signed-off-by: Kameron Carr Reviewed-by: Michael Kelley Signed-off-by: Wei Liu commit 73fe42af955a24b6cc792b9a4867e809196f05ed Author: Kameron Carr Date: Tue Aug 11 09:04:46 2026 -0700 Drivers: hv: vmbus: Add vmbus_alloc_buffer()/vmbus_free_buffer() for CoCo VMs On CoCo VMs without confidential VMBus, the netvsc send and receive buffers must be made host-visible by decrypting them. These buffers are vmalloc'ed, but set_memory_decrypted()/encrypted() do not work on vmalloc'ed memory. This use case is (so far) unique to netvsc, so solve it locally rather than changing the set_memory() or allocation APIs. Add vmbus_alloc_buffer()/vmbus_free_buffer() to the VMBus core. When the guest's isolation model requires it, allocate the buffer as a list of physically-contiguous chunks via alloc_pages_node(), starting at MAX_PAGE_ORDER and falling back to smaller orders so the allocation still succeeds under memory fragmentation. Each chunk is decrypted in place via set_memory_decrypted() on its direct-map address, and the chunks are then stitched into a single virtually-contiguous range with vmap(). Buffers that do not need decryption keep using vzalloc(). To free the buffer, vmbus_free_buffer() calls vunmap() on the range then re-encrypts and frees each chunk individually; any chunk that fails re-encryption is leaked to prevent accidentally freeing decrypted memory. This approach minimizes scattering of decrypted 4 KiB pages through the kernel direct map and the resulting shattering of large page mappings. Signed-off-by: Kameron Carr Reviewed-by: Michael Kelley Signed-off-by: Wei Liu commit 8f1da3536b8f8420988fe6e6ae15d58afa2ba2d8 Author: Kameron Carr Date: Tue Aug 11 09:04:45 2026 -0700 Drivers: hv: vmbus: add vmbus_establish_gpadl_caller_decrypted() Add a new vmbus_establish_gpadl_caller_decrypted() for callers that want to decrypt their own buffers. Add a new hv_gpadl_type, HV_GPADL_BUFFER_DECRYPTED, to communicate the decryption status of the buffer. No functional change for existing callers. Signed-off-by: Kameron Carr Reviewed-by: Michael Kelley Signed-off-by: Wei Liu commit cee0d90bceae1dee3bcc70f8d6b2ceb5b87deb42 Author: Michael Kelley Date: Wed Aug 12 07:52:23 2026 -0700 Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition The VMBus module initialization function, hv_acpi_init(), currently does nothing when running in the root partition and root is not nested in another VM. But the initialization function reports success, so the VMBus module is indeed loaded. VMBus functionality is not actually needed, but the VMBus module must be loaded so that hv_vmbus_exists() can answer correctly. Furthermore, the mshv_root dependency on the VMBus module is needed as described in the commit message for 840b740a35bf ("mshv: Add conditional VMBus dependency"). Loading the VMBus module without actually initializing it causes failures if the module should later be unloaded. The module unload code tries to clean up things that were never initialized, resulting in memory faults and a panic. Fix this by having VMBus module exit function perform the same check for non-nested root partition, and do nothing in such a case, just like hv_acpi_init(). In the long run, the code that manages the Hyper-V provided SynIC should be refactored to better coordinate the requirements of root partition scenarios and normal VM scenarios, and to hopefully remove the hv_vmbus_exists() dependnecy between mshv_root and VMBus modules. Preventing the current unload failure scenario is an expediency until such a refactoring is done. Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hyperv/20260721154943.A09BD1F00A3D@smtp.kernel.org/ Fixes: 7e279d78664aa ("Drivers: hv: vmbus: skip VMBus initialization if Linux is root") Signed-off-by: Michael Kelley Reviewed-by: Easwar Hariharan Signed-off-by: Wei Liu commit 769bcbee07a45856e0b603ee23243737a2f9ca2a Author: Wei Liu Date: Wed Jul 29 17:50:19 2026 -0700 x86/hyperv: reserve more vectors Microsoft Hypervisor delivers three vectors to the NT HAL running in the root partition and refuses to map a device interrupt to any of them when interrupt remapping is not available in the system. As of writing, the nested MSHV setup has no interrupt remapping capability. The three vectors are: HAL_NT_APC_VECTOR 0x1F HAL_NT_DPC_VECTOR 0x2F HAL_NT_CLOCK_IPI_VECTOR 0xD2 0x1F is below FIRST_EXTERNAL_VECTOR so the vector allocator never hands it out, but 0x2F and 0xD2 are both inside the allocatable range and are handed out once enough vectors are in use. Mapping such an interrupt then fails with HV_STATUS_INVALID_PARAMETER, and the interrupt is never delivered. Reserve all three next to the hypervisor debug vectors that are already kept out of the allocator's hands. Reviewed-by: Michael Kelley Signed-off-by: Wei Liu commit 86bdd16e8f390d51bae9e77a4bc4164ca2f580fe Author: Naman Jain Date: Mon Aug 10 09:07:13 2026 +0000 PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip The Hyper-V vPCI MSI irqchip never installs an irq_retrigger() callback. On CPU hot-unplug fixup_irqs() migrates the interrupts which are affine to the outgoing CPU to a new target. If an interrupt still has its pending bit set in the outgoing CPU's IRR at that point, fixup_irqs() resends it on the new target through the irqchip's irq_retrigger() callback. As the Hyper-V PCI/MSI chip does not provide that callback, the pending interrupt is silently dropped, which can result in lost interrupts, stalls and "No irq handler for vector" messages during CPU hotplug. Install irq_chip_retrigger_hierarchy() as the irq_retrigger() callback for the Hyper-V PCI/MSI irqchip, so that a pending interrupt is resent on its new target CPU via the parent x86 vector domain. Fixes: 4daace0d8ce85 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Cc: stable@vger.kernel.org Suggested-by: Long Li Suggested-by: Thomas Gleixner Reviewed-by: Aditya Garg Reviewed-by: Shradha Gupta Signed-off-by: Naman Jain Reviewed-by: Michael Kelley Signed-off-by: Wei Liu commit e1fc6e70f36e93eede63df85d942011a3f96a764 Author: Hardik Garg Date: Mon Jul 27 21:11:01 2026 +0000 Drivers: hv: Use meaningful errnos for hypercall status codes Commit 3817854ba892 ("hyperv: Log hypercall status codes as strings") converted hv_result_to_errno() from a switch to a table and added status codes used for string logging. Statuses without an existing specific mapping were assigned the generic -EIO fallback even when a more specific errno was available. Map HV_STATUS_ACCESS_DENIED and HV_STATUS_OPERATION_DENIED to -EACCES, HV_STATUS_UNKNOWN_PROPERTY and HV_STATUS_PROPERTY_VALUE_OUT_OF_RANGE to -EINVAL, and HV_STATUS_PROCESSOR_FEATURE_NOT_SUPPORTED to -EOPNOTSUPP. This lets callers distinguish permission, argument, and capability failures from generic I/O errors. The table conversion also added duplicate HV_STATUS_INVALID_LP_INDEX and HV_STATUS_INVALID_REGISTER_VALUE entries. Remove the later -EIO entries, which are unreachable because find_hv_status_info() returns the first match. Signed-off-by: Hardik Garg Reviewed-by: Naman Jain Signed-off-by: Wei Liu commit 22e48eeaf4851a3caf2acb397069283508a7f5f5 Merge: c44e278ce02efd e4c3ab59021e7c Author: Dave Airlie Date: Mon Aug 24 09:07:41 2026 +1000 Merge tag 'amd-drm-next-7.3-2026-08-19' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-7.3-2026-08-19: amdgpu: - eGPU fixes - Runtime PM fix - UserQ fixes - Backlight fix - Discovery sysfs fix - Reset handling fixes - Buffer func handling fix for xgmi - VCN boundary check fix - DC lut handling fixes amdkfd: - Fix return value radeon: - iMac display fix Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patch.msgid.link/20260819183622.2406038-1-alexander.deucher@amd.com commit 14af7a96afa39f4f3c1972705489b9ba15c01857 Author: Swark Yang Date: Mon Aug 17 20:34:08 2026 -0700 mailbox: add Axiado AX3005 mailbox driver Add a mailbox controller driver for the Axiado AX3005 SoC. The controller provides communication channels between the host CPU and the coprocessor. The hardware provides 8 TX channels and 8 RX channels through separate register regions. RX channels use per-channel interrupts, while TX completion is detected by polling the FIFO status. Add the driver path to the existing Axiado mailbox entry in MAINTAINERS. Signed-off-by: Swark Yang Signed-off-by: Jassi Brar commit 289413b8077af26bc8c4fed8311bc9092b9b40fc Author: Swark Yang Date: Mon Aug 17 20:34:07 2026 -0700 dt-bindings: mailbox: add Axiado AX3005 mailbox Add a devicetree binding for the Axiado AX3005 mailbox controller. The controller provides inter-processor communication channels between the host CPU and the coprocessor, with separate TX and RX register regions. Add the corresponding MAINTAINERS entry covering the binding. Signed-off-by: Swark Yang Reviewed-by: Krzysztof Kozlowski Signed-off-by: Jassi Brar commit 4352b8aee98005853aa63f57d6377282de17a33f Merge: 570f7e331f5feb cab40cfc9e116a Author: Linus Torvalds Date: Sun Aug 23 13:28:57 2026 -0700 Merge tag 'i3c/for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux Pull I3C updates from Alexandre Belloni: "A new driver this cycle, for the AMD AXI I3C controller. There are also new features such as IBI wakeup support, SETAASA device discovery and ACPI support for the the DAA methods, meaning we can now communicate with the SPD devices on DDR5 modules. New driver: - AMD AXI I3C master controller Subsystem: - I3C Common Command Code (CCC) handling improvements, especially around GET CCCs - SETAASA device discovery support - ACPI support for all existing DAA methods like SETDASA, SETNEWDA as well as I2C devices on I3C bus - IBI-based wakeup support Drivers: - dw: SETAASA support - mipi-i3c-hci: advertise IBI wakeup capability, AMD_PT I3C controller support, PIO queue management support for HCI v1.2 - renesas: improve suspend to RAM support, add runtime PM support" * tag 'i3c/for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux: (70 commits) i3c: dw: reduce do_daa time if there's no client i3c: mipi-i3c-hci: Add support for AMD_PT I3C controller i3c: mipi-i3c-hci: Add PIO queue management support for HCI v1.2 i3c: mipi-i3c-hci: Fix missing STAT_IBI_STATUS_THLD in PIO mode i3c: dw: rename "pclk" to "apb" to match dt-binding i3c: dw: make struct dw_i3c_cmd smaller i3c: dw: use COMMAND_PORT_TRANSFER_ARG instead of hardcoding i3c: renesas: Don't register devices when ENTDAA times out i3c: master: dw-i3c-master: fix OD timing for first broadcast i3c: mipi-i3c-hci: Advertise IBI wakeup capability i3c: mipi-i3c-hci: Factor out i3c_hci_sysdev() i3c: mipi-i3c-hci-pci: Propagate I3C wakeup requirements to PCI i3c: master: Reject IBI requests from non-IBI-capable devices i3c: master: Add helper to query bus wakeup requirements i3c: master: Report wakeup events for IBIs i3c: master: Support IBI-based wakeup capability i3c: master: Fix potential UAF in i3c_device_match() i3c: master: Fix potential UAF in i3c_device_uevent() i3c: Make dev->desc locking assumptions explicit i3c: master: Fix use-after-free of master->this ... commit 0319b42e1e28b845a3092082fa1e1ff9043f833e Author: Sang-Heon Jeon Date: Mon Aug 24 01:18:15 2026 +0900 coccinelle: zalloc-simple: drop the kmem_alloc rules - kmem_alloc() was removed by commit f078d4ea8276 ("xfs: convert kmem_alloc() to kmalloc()") - kmem_zalloc() was removed by commit 10634530f7ba ("xfs: convert kmem_zalloc() to kzalloc()") So drop the kmem_alloc rules. No functional change. Signed-off-by: Sang-Heon Jeon Signed-off-by: Julia Lawall commit 2bd30b8dc75b823dd7bbef9d7bc68e1fd7ecee5c Author: Sang-Heon Jeon Date: Mon Aug 24 01:18:14 2026 +0900 coccinelle: alloc_cast: drop removed allocators - pci_alloc_consistent() and pci_zalloc_consistent() were removed by commit 7968778914e5 ("PCI: Remove the deprecated "pci-dma-compat.h" API") - kmem_alloc() was removed by commit f078d4ea8276 ("xfs: convert kmem_alloc() to kmalloc()") - kmem_zalloc() was removed by commit 10634530f7ba ("xfs: convert kmem_zalloc() to kzalloc()") - kmem_zone_alloc() and kmem_zone_zalloc() were removed by commit bae633a4a283 ("xfs: remove xfs_zone_{alloc,zalloc} helpers") So drop them from the rules. No functional change. Signed-off-by: Sang-Heon Jeon Signed-off-by: Julia Lawall commit cfeffda899903bfaf5244dab3596f585511af814 Author: Sang-Heon Jeon Date: Mon Aug 24 01:18:13 2026 +0900 coccinelle: remove obsolete pci_free_consistent.cocci pci_alloc_consistent() and pci_free_consistent() were removed by commit 7968778914e5 ("PCI: Remove the deprecated "pci-dma-compat.h" API"). So remove the obsolete script. Signed-off-by: Sang-Heon Jeon Signed-off-by: Julia Lawall commit 8c59f5c467aff29d9d8088e07b6ca34926f6151d Author: Julia Lawall Date: Sun Aug 9 18:43:36 2026 +0200 scripts: coccinelle: devm_free: reduce false positives False positives could be introduced due to allocations using the new _obj functions. Add these to the "safe" rule accordingly. False positives could also be introduced when the same variable name has two possible types. Incorporate type information to avoid reporting this case This does lead to false negatives when no type information is available. Signed-off-by: Julia Lawall Reported-by: Ricardo Ribalda commit 707f8e0ddf3f730c15e5c18b346d4258ddb46868 Author: Sang-Heon Jeon Date: Sun Aug 9 13:53:34 2026 +0900 coccinelle: misc: struct_size: drop unneeded parentheses The outer parentheses and the single-branch disjunction don't matter when just matching and reporting a line. Eliminating them reduces the complexity of the pattern to match and gives a performance improvement in the non-patch cases, like the previous minmax change. Signed-off-by: Sang-Heon Jeon Signed-off-by: Julia Lawall commit a53cbd149844cbde80f6adfc7f4233b8f230f664 Author: Sang-Heon Jeon Date: Mon Jul 27 22:52:44 2026 +0900 coccinelle: mini_lock: improve performance when searching loops The 'looped' rule collects the returns inside a for loop to prevent 'err' from reporting them. It searches every for loop in the file, and on files with large loop bodies the search explodes. For example, kernel/bpf/verifier.c runs for over 200 seconds, almost entirely in 'looped' according to --profile. Since the kernel .cocciconfig sets a 200 second timeout, coccicheck silently skips the file. To avoid this, collect the candidate returns first, so that 'looped' checks only those positions. 'err' then excludes what 'looped' found. Every return that 'err' can report is also a candidate, so the same returns are excluded as before and the output does not change. A report-mode run over every .c file in the tree produces identical output. So verifier.c now finishes well within the timeout, in a few seconds. Signed-off-by: Sang-Heon Jeon Signed-off-by: Julia Lawall commit b64acacd5429ff3fe7c38cb3cf959bbd3a9fb30f Author: Julia Lawall Date: Sun Aug 2 21:20:51 2026 +0200 coccinelle: api: check for macro context A cast on a call to an allocation function that is the body of a macro can be useful, as it ensures tha the macro is used for allocating objects of the right type. Add two new rules to ignore the macro case. Suggested-by: Steven Rostedt Signed-off-by: Julia Lawall commit 5adb3698bbe8f2053afbe046dee8eb184ac78478 Author: 相浦彰 / AIURA，AKIRA Date: Thu Jul 30 02:38:40 2026 +0000 coccinelle: update Coccinelle website URL The old Coccinelle project URL is no longer available. Replace it with the current Coccinelle homepage already referenced by Documentation/dev-tools/coccinelle.rst. Signed-off-by: Akira Aiura Signed-off-by: Julia Lawall commit 4fc2656db0c8026139f1634d557ef66e4b383765 Author: Julia Lawall Date: Sun Jul 26 17:07:54 2026 +0200 coccinelle: misc: minmax: avoid unhelpful isomorphisms Avoid isomorphisms that introduce comparisons with 0 that do not occur in code. Signed-off-by: Julia Lawall commit af8613c863a3160b7fb6fd09cbf5b56e37330d80 Author: Julia Lawall Date: Sun Jul 26 16:08:56 2026 +0200 coccinelle: misc: minmax: check for the presence of if cases As done previously for the ternary command, check that a file contains the min or max if pattern before applying the minif and maxif rules. Signed-off-by: Julia Lawall commit fd0a63f086b3f2f45c49b1378f6c2ac7a542db19 Author: Julia Lawall Date: Sun Jul 26 16:01:38 2026 +0200 coccinelle: misc: minmax: drop unneeded parentheses The outer parentheses don't matter when just matching an returning a line. Eliminating them reduces the complexity of the pattern to match and gives a small performance improvement in the non-patch cases. Signed-off-by: Julia Lawall commit b32cf68d78a1f2a05797ec2a969b80a9472f45a7 Author: Sang-Heon Jeon Date: Sat Jul 25 20:32:41 2026 +0900 coccinelle: misc: minmax: improve performance when no candidate exists The rules that report an opencoded min() or max() search every function body, even when the file contains nothing to find. To avoid this, collect the candidates first and run the search only when one exists. A candidate is any conditional expression whose condition is a comparison. Every opencoded min() or max() is also a candidate, so the same opportunities are reported as before and the output does not change. A report-mode run over every .c file in the tree produces identical output. Signed-off-by: Sang-Heon Jeon Signed-off-by: Julia Lawall commit bf2fe566a8cbd3671b816223eec8fadd18ec8d77 Author: Sang-Heon Jeon Date: Sat Jul 25 20:32:40 2026 +0900 coccinelle: double_lock: improve performance when no double lock exists The 'balanced' rule collects the locks that are taken and released under the same condition, to prevent them from being reported as a double lock. It runs on every file that contains a lock call. To avoid this, collect the double-lock candidates first, so that 'balanced' runs only when one exists. The report then excludes what 'balanced' found. Every double lock that can be reported is also a candidate, so the same reports are made as before and the output does not change. A report-mode run over every .c file in the tree produces identical output. Signed-off-by: Sang-Heon Jeon Signed-off-by: Julia Lawall commit a12eac458814f70ed9b0b2e3293b7478c7032eaa Author: Geert Uytterhoeven Date: Fri Aug 21 12:09:06 2026 +0200 rtc: microcrystal: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. Make sure all members are fully initialized, to avoid such bugs, and to prevent future breakage when converting drivers to a different method for specifying the parents. Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/6e7b5258ff73e93fe23dd83cf56f806ee60fa7a9.1787241693.git.geert+renesas@glider.be Signed-off-by: Alexandre Belloni commit 5ef3d51a3aaae642f8e5515a2c67c17f6b7cb01c Author: Geert Uytterhoeven Date: Fri Aug 21 12:09:05 2026 +0200 rtc: philips: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. Make sure all members are fully initialized, to avoid such bugs, and to prevent future breakage when converting drivers to a different method for specifying the parents. Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/8281eaf605069aac2211d83233e11285b8e8ca84.1787241693.git.geert+renesas@glider.be Signed-off-by: Alexandre Belloni commit 096c7ef4ef6670e64ebfc22f8989cb48f560fe10 Author: Geert Uytterhoeven Date: Fri Aug 21 12:09:04 2026 +0200 rtc: nct3018y: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. Make sure all members are fully initialized, to avoid such bugs, and to prevent future breakage when converting drivers to a different method for specifying the parents. Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/6dba18b645aeea279a67f4625d5ec48037c76f0c.1787241693.git.geert+renesas@glider.be Signed-off-by: Alexandre Belloni commit bdcedfee8b87067dbc907e9e94310c5be4311133 Author: Geert Uytterhoeven Date: Fri Aug 21 12:09:03 2026 +0200 rtc: m41t80: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. Make sure all members are fully initialized, to avoid such bugs, and to prevent future breakage when converting drivers to a different method for specifying the parents. Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/c5290fb9a28b45d6bcec724d5897f8bcbf96ea50.1787241693.git.geert+renesas@glider.be Signed-off-by: Alexandre Belloni commit db005bdaa5ff4ea52095aa213507134dcaff42cc Author: Geert Uytterhoeven Date: Fri Aug 21 12:09:02 2026 +0200 rtc: hym8563: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. Make sure all members are fully initialized, to avoid such bugs, and to prevent future breakage when converting drivers to a different method for specifying the parents. Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/657f2b3a871074087aee0b7a70bf527ab0f48da8.1787241693.git.geert+renesas@glider.be Signed-off-by: Alexandre Belloni commit 570f7e331f5febb30f1384817463c7e42b65ca7d Merge: b6b019a1d9b90a 9324becc398a1f Author: Linus Torvalds Date: Sun Aug 23 12:44:10 2026 -0700 Merge tag 'pci-v7.3-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI updates from Bjorn Helgaas: "Resource management: - Add hotplug reservation only once (not at each level of the hierarchy) so bridge windows don't grow more than necessary (Ilpo Järvinen) Driver binding: - Rework device matching so device ID lifetime only needs to cover the probe path since dynamic IDs can be removed at any time (Gary Guo) Error handling: - Update mappings of AER errors to agent & layer and log them for each individual error when multiple errors detected (Lukas Wunner) - Log Error Source only once, not twice in separate messages (Lukas Wunner) - Emit TLP Log only for unmasked errors (Lukas Wunner) - Support Advisory Non-Fatal Errors (Lukas Wunner) - Allow DPC on all Downstream Ports, not just Root Ports, when OS controls AER (Darshit Shah) ASPM: - Program the same ASPM Control values for every function of multi-function devices, as recommended by the PCIe spec (Krishna Chaitanya Chundru) - Avoid L0s for Realtek RTS525A, where it causes an AER interrupt storm (Max Lee) - Avoid ASPM L0s, L1, and L1 PM Substates based on 'aspm-no-l0s', 'aspm-no-l1' [1], and 'aspm-no-l1ss' DT properties (Krishna Chaitanya Chundru) Power management: - Allow D3 for native hotplug-capable Root Ports on non-x86 platforms (we avoid D3 for these ports on x86 because some old platforms didn't validate it) (Manivannan Sadhasivam) - Allow portdrv to claim Ports even if they don't support services (AER, PME, DPC, hotplug, etc) so it can do power management (Brian Norris) Power control: - Add support for PCIe WAKE# interrupt when described via DT (Krishna Chaitanya Chundru) - For the TC9563 PCIe switch: - Take a reference on the I2C adapter to avoid uninterruptible hang when unloading an I2C module while in-use (Johan Hovold) - Update DT binding and driver to restrict Tx Amplitude, DFE and N_FTS to USP, DSP1 and DSP2 (Manivannan Sadhasivam) - Power off only external-facing ports (DSP1, DSP2), leaving USP and DSP3 (aka VDSP) powered up (Manivannan Sadhasivam) - Move integrated MAC Endpoint out of the list of internal ports and configure it separately (Manivannan Sadhasivam) Virtualization: - Add ACS quirk for Pericom PI7C9X2G608 switches (Tim Harvey) - Fix a long-standing bug in the Intel PCH Root Port MPC ACS quirk that didn't update the intended INTEL_MPC_REG_IRBNCE bit because it used a 16-bit config write when a 32-bit write was intended (Mohamad Raizudeen) Procfs: - Avoid spurious runtime PM wakeup on config space accesses that are outside config space and fail before reaching PCI (Krzysztof Wilczyński) - Warn on user-space writes to kernel-exclusive config space regions, as we already do for sysfs (Krzysztof Wilczyński) - Check credentials of opener, not reader, for config space reads, as we already do for sysfs (Krzysztof Wilczyński) Sysfs: - In pci_write_legacy_io(), avoid out-of-bounds reads from the user buffer and fix incorrect ioport write data (1-byte writes on little-endian powerpc, 2- and 4-byte writes on big-endian powerpc) (Krzysztof Wilczyński) - In pci_read_legacy_io(), fix incorrect ioport read data for 2- and 4-byte reads on big-endian powerpc (Krzysztof Wilczyński) - Fix I/O port accessor argument order in Alpha pci_legacy_write() (Krzysztof Wilczyński) - Avoid spurious runtime PM wakeup on config space accesses that are outside config space and fail before reaching PCI (Krzysztof Wilczyński) - Return -EINVAL, not -ENODEV, for mmap of I/O BAR that fails because the arch doesn't support it, as we do for procfs (Krzysztof Wilczyński) - Check for LOCKDOWN_PCI_ACCESS for legacy_io and legacy_mem, as we do for other config space accessors (Krzysztof Wilczyński) Peer-to-peer DMA: - Add Nvidia Vera Rubin to list of platforms that support P2PDMA (Leon Romanovsky) Endpoint framework: - Check doorbell SUCCESS bit in pci_endpoint_test to avoid treating some failures as successes (Niklas Cassel) - Fail doorbell test when the trigger IRQ is missed (Niklas Cassel) New native PCIe controller drivers: - Add DT binding and driver for NVIDIA Tegra264 (Thierry Reding) Native PCIe controllers: - Use common wait time definitions for PCIe link monitoring instead of defining driver-private duplicates (Thierry Reding) Generic host bridge driver: - Fix NULL pointer dereference that caused enumeration failures on 32-bit CAM systems (Steffen Persvold) Amlogic Meson PCIe controller driver: - Correct the PERST# GPIO state so it remains asserted until power and REFCLK become stable to fix enumeration failure (Ronald Claveau) ASPEED PCIe controller driver: - Switch to irq_domain_create_linear() so we can obsolete irq_domain_add_linear() (Jiri Slaby) Cadence PCIe controller driver: - Add MODULE_DEVICE_TABLE to generate module aliases for OF-based module autoloading (Pengpeng Hou) - Add debugfs 'ltssm_status' file for LGA- and HPA-based Cadence controllers (Hans Zhang) - Support up to x4 (not x2) lanes for J200 (Takuma Fujiwara) - Fix host/endpoint dependencies for cadence-plat driver to fix link error when cadence-plat is built-in but the host or endpoint driver is modular (Aksh Garg) Freescale i.MX6 PCIe controller driver: - Add imx6 intr/aer/pme interrupt lines for i.MX95 (Richard Zhu) - Remove PERST# checking from pci_host_common_parse_port() so callers can decide whether to fall back to legacy DT binding with PERST# in the host bridge (Sherry Sun) - Fix build issues when PCI_PWRCTRL_GENERIC or PCI_HOST_COMMON is a module (Arnd Bergmann) - Create pwrctrl devices only once by doing it from imx_pcie_probe() instead of imx_pcie_host_init(), which is used during both probe and resume (Sherry Sun) - Use 'dw_pcie_rp->skip_pwrctrl_off' to avoid powering off devices during suspend to preserve wakeup capability (Sherry Sun) - Add runtime PM support for i.MX95 to allow dynamic power management when the link is idle (Richard Zhu) Intel VMD host bridge driver: - Support device ID 0x28C1 and assume that BIOS has already enumerated the hierarchy below VMD and stored bus range info for OS to use (Nirmal Patel) - Add support for VMCONFIG BUS_RESTRICT_CFG=3, which makes it possible to enumerate downstream devices on Intel Arrow Lake-HX systems and probably others (Ali Alaei) - Pay attention to _OSC negotiation for VMD hierarchy only when running on bare metal, not when running in a VM (Nirmal Patel) - Add Nova Lake (NVL) and Dunlow (DNL) Device IDs (Szymon Durawa) MediaTek PCIe controller driver: - Add support for PCIe controller in EcoNet EN7528 and EN751221 SoCs (Caleb James DeLisle) MediaTek PCIe Gen3 controller driver: - Add mediatek-gen3 'memory-region' for restricted DMA buffer (Chen-Yu Tsai) NVIDIA Tegra264 PCIe controller driver: - Distinguish Tegra264 C0 PCIe controller for internal GPU from C1-C5 controllers so the unit address matches the first 'reg' entry (Thierry Reding) - Add Tegra264 Root Port stanzas to prepare for generic WAKE# handling (Thierry Reding) Qualcomm PCIe controller driver: - Add IPQ9650 compatible with global interrupt (Kathiravan Thirumoorthy) - Add IPQ5210 compatible with IPQ9574 fallback (Varadarajan Narayanan) - Add DT binding and driver support for Hawi SoC (Matthew Leung) - Skip PERST# GPIOs provided by downstream PCIe devices, which should be handled by drivers of those devices (Manivannan Sadhasivam) - Stop advertising Attention Button Present (no Qcom SoCs support Attention Buttons) so pciehp can use Presence Detect Changed events (Qiang Yu) Renesas R-Car PCIe controller driver: - Add rcar-gen4-pci-host optional 'msi-parent' for GIT ITS (Marek Vasut) - When MSI is enabled but iMSI-RX is not used, configure AXIINTC to allow GIT ITS to handle MSI (Marek Vasut) - Refactor GIC600 implementation to make it easier to add platforms that only support 32-bit addressing (Marek Vasut) - Add Renesas R-Car Gen4 S4/V4H/V4M to the list of GIC600 integrations that only support 32-bit addressing (Marek Vasut) Renesas RZ/G3S PCIe controller driver: - Add DT binding and driver support for RZ/V2H(P) SoC, which contains two PCIe controllers, configured either as a single x4 link or two independent x2 link controllers (Lad Prabhakar) SpacemiT K1 PCIe controller driver: - Add missing MODULE_DEVICE_TABLE() to generate module alias info for OF-based module autoloading (Pengpeng Hou) StarFive PCIe controller driver: - Fix resource leaks on error paths in host_init() (Ali Tariq) - Fix runtime PM handling and teardown ordering to avoid register access while power or clocks are disabled (Ali Tariq) - Check for runtime PM resume failure to avoid register access while power or clocks are disabled (Ali Tariq) Synopsys DesignWare PCIe controller driver: - Add LECARC PMU IDs to the DWC RAS/DES VSEC list so it can take advantage of the existing debugfs support for silicon debug, error injection, and event counters (Brett Zhou) - Factor pcie_valid_speed() and pci_bus_speed2lnkctl2() out of bwctrl so they can be shared by the DWC core (Hans Zhang) - Flush MSI writes from endpoint before unmapping the iATU, as we already do for MSI-X writes (Niklas Cassel) - Unmap MSI iATU window before mapping MSI-X window, to avoid a subsequent MSI write using a disabled aperture and losing the interrupt (Niklas Cassel) - Change endpoint .pre_init() and .init() callbacks to return errors and handle them (Marek Vasut) UltraRISC PCIe controller driver: - Add 'core', 'dbi', and 'aux' clocks to DT binding and manage them in the driver (Jia Wang) - Use module_platform_driver() since this may be built as a module, though not removable because IRQs can't be safely disposed (Jia Wang) MicroSemi Switchtec management driver: - Add Microchip PCI1008 device ID and include it in NTB DMA alias quirk (Logan Gunthorpe) Miscellaneous: - Document how to write PCI Host Controller drivers (Manivannan Sadhasivam) - Fix typos in documentation (D'Orus Tsitera) - Use %pe format specifier to print error pointers so we get symbolic errname when available (Krzysztof Wilczyński)" * tag 'pci-v7.3-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: (124 commits) PCI: vmd: Add Nova Lake (NVL) and Dunlow (DNL) Device IDs PCI: tegra264: Add Tegra264 support dt-bindings: PCI: tegra264: Switch to PCIe Root Port bindings dt-bindings: PCI: tegra264: Strictly distinguish C0 from C1-C5 PCI/AER: Support Advisory Non-Fatal Errors PCI: Fix 32-bit config write in Intel PCH Root Port MPC ACS quirk PCI: dwc: Handle return value from endpoint .pre_init callback PCI: dwc: Handle return value from endpoint .init callback PCI: dwc: Add PCI ID for LECARC PCIe PMU PCI/ASPM: Mask ASPM states based on Devicetree properties PCI/ASPM: Disable/restore ASPM on every function for multi-function devices Documentation: PCI: Document how to write PCI Host Controller drivers PCI/ASPM: Use pcie_capability_clear_and_set_word() for ASPM disable/restore PCI: Add support for PCIe WAKE# interrupt PCI: Allow D3 for native hotplug-capable Root Ports on non-x86 platforms dt-bindings: PCI: Correct white-space style PCI/ASPM: Avoid L0s for Realtek RTS525A PCI: ultrarisc: Use module_platform_driver() PCI: ultrarisc: Get and enable DP1000 PCIe controller clocks dt-bindings: PCI: ultrarisc: Add required DP1000 PCIe clocks ... commit 5febf432df1cfa5b25d99b54c32103fafbdd0eb9 Author: Miguel Ojeda Date: Sun Aug 16 15:32:33 2026 +0200 kbuild: rust: keep Rust objects out of Clang LTO with inline helpers Under `CONFIG_LTO_CLANG` + `CONFIG_RUST_INLINE_HELPERS`, one may hit `objtool` errors such as: vmlinux.o: error: objtool: _R..._3Gsp4boot+0xd6a: can't find jump dest instruction at .text._R..._3Gsp4boot+0x1dfd The reason is that in such builds, the Clang invocation that compiles the combined Rust plus helpers bitcode emits LLVM bitcode (again) -- the final code generation happens in the linker's LTO step, which the `-mllvm` trap options passed to Clang do not reach. This, in turn, means that unreachable traps are missing, and the impossible paths do not merely fallthrough to the next symbol, but past the end of their own section, since LTO builds place each function in its own section. Thus filter `CC_FLAGS_LTO` out of the Clang invocation, so that it always emits machine code directly, with the traps in place. Assisted-by: LLM Cc: Gary Guo Cc: Boqun Feng Cc: Alice Ryhl Cc: Matthew Maurer Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: stable@vger.kernel.org Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust") Acked-by: Gary Guo Link: https://patch.msgid.link/20260816133233.197500-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda commit 0bff7711c19ba05ff3b686554c5a2d503c3e9797 Author: Miguel Ojeda Date: Sun Aug 16 15:32:32 2026 +0200 kbuild: rust: preserve unreachable traps with inline helpers When `CONFIG_RUST_INLINE_HELPERS` is enabled, it is possible to hit `objtool` warnings like: vmlinux.o: warning: objtool: _R..._4cmdq12CommandToGsp4init() falls through to next function _R..._4core5array4iter8IntoIterRShKj3_EEEBa_() `rustc` normally emits traps for unreachable paths. However, under `CONFIG_RUST_INLINE_HELPERS=y`, `rustc` emits LLVM bitcode and Clang performs final code generation after the helper bitcode is linked, but Clang does not trap unreachable IR by default. In turn, this means `objtool` follows compiler-generated impossible Rust `enum` paths through alignment padding into the next function, resulting in fallthrough warnings. Thus pass the LLVM `trap-unreachable` option to the final Clang invocation and suppress traps immediately after `noreturn` calls, which `objtool` already recognizes as dead ends. The combination of both flags makes it match `rustc`'s behavior. Rust 1.85.0 (the minimum supported one) supports LLVM >= 18, and both flags are available in LLVM 18. Assisted-by: LLM Cc: Gary Guo Cc: Boqun Feng Cc: Alice Ryhl Cc: Matthew Maurer Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: stable@vger.kernel.org Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust") Acked-by: Gary Guo Link: https://patch.msgid.link/20260816133233.197500-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda commit 29b03d1de967a177176d12811d970cac7882afcf Author: Gary Guo Date: Thu Aug 20 14:57:32 2026 +0100 rust: cfi: disable function merging if CFI is enabled In Rust doc tests, there is a dummy `__module_firmware_test_init` function generated by the example in `module_firmware!`'s documentation, which just returns zero. Many other documentation examples generate functions that produce zero. LKP test robot reports [1] a `Flags::zeroed` instance; my local reproduction has a `Bounded::new::<0>`. LLVM's MergeFunctionsPass incorrectly merges functions with different KCFI types, causing `__module_firmware_test_init` to be merged into one of the zero-returning functions. As module init is invoked via an indirect function call, KCFI is checked and this produces a KCFI failure. I've reported this bug to upstream LLVM [2]; in the meantime, disable function merging if CFI is enabled. No separate treatment is needed for CONFIG_RUST_INLINE_HELPERS, as Clang does not enable function merging by default. [ LLVM already has a pending PR: https://github.com/llvm/llvm-project/pull/217665 which solves the issue. In addition, I asked upstream Rust if the unstable `-Zmerge-functions=disabled` flag will remain around: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/.60-Zmerge-functions.3Ddisabled.60/ and it does indeed look like that will be the case. - Miguel ] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202608201017.100a4511-lkp@intel.com [1] Link: https://github.com/llvm/llvm-project/issues/217629 [2] Signed-off-by: Gary Guo Cc: stable@vger.kernel.org Fixes: ca627e636551 ("rust: cfi: add support for CFI_CLANG with Rust") Reviewed-by: Sami Tolvanen Link: https://patch.msgid.link/20260820135733.37121-1-gary@kernel.org [ Fixed typos as discussed. Reworded slightly for other typos. - Miguel ] Signed-off-by: Miguel Ojeda commit dea1bf38143f8505747c19b953ef12fb809d5d77 Author: FUJITA Tomonori Date: Sun Aug 9 22:48:58 2026 +0900 rust: jump_label: skip arch-specific asm in `testlib` builds Running `make rusttest` with `ARCH=` set to an architecture other than the host's may fail in the future, e.g. `ARCH=arm64` on an x86_64 host: error: alignment must be a power of 2 --> rust/kernel/jump_label.rs:51:13 | 51 | include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_static_branch_asm.rs")); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: instantiated into assembly here --> :3:10 | 3 | .align 3 | ^ The reason is that `rusttest` builds the kernel crate as a host library: it passes the `CONFIG_*` cfgs of the configured architecture, but not `--target`, so code generation happens for the host. `arch_static_branch!` then selects the arch-specific inline asm arm based on CONFIG_*, and the host assembler rejects it. This does not happen with the current master because `arch_static_branch!` has no user inside the kernel crate itself yet, but fix it now to avoid surprises later. Signed-off-by: FUJITA Tomonori Link: https://patch.msgid.link/20260809134858.1219036-1-tomo@flapping.org [ Reworded slightly to clarify it "may fail in the future". - Miguel ] Signed-off-by: Miguel Ojeda commit 993f235c4af49d0e912cc28abe6d733531600237 Author: Miguel Ojeda Date: Wed Aug 5 16:45:24 2026 +0200 objtool/rust: add one more `noreturn` Rust function When the pointer formatting series [1] is applied and KUnit tests are enabled, `objtool` would report an error with any of our supported Rust versions. For instance, with Rust 1.97.1: rust/kernel.o: error: objtool: _R..._4core3fmt7Pointer3fmtB7_() falls through to next function _R..._4core7convert5AsRefNtB5_4BStrE6as_ref() Or, with Rust 1.85.0: rust/kernel.o: error: objtool: _R..._4core3fmt7Pointer3fmtB7_() falls through to next function _R..._4core3ffi5c_str4CStrENtNtBS_3fmt7Display3fmtB7_() This happens due to calls to the `noreturn` symbol: core::str::slice_error_fail Thus add the mangled one to the list so that `objtool` knows it is actually `noreturn`. See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions") for more details. [ While the series [1] mentioned above was not applied in a way that triggered this, Gary found another case [2]: I am seeing this function causing issue on my 1.85.1 -Os build, although the error message is different this time: rust/kernel.o: warning: objtool: _R..._5range9RangeFromjEE5indexCsldbe0TGTmNx_6kernel+0x1d: stack state mismatch: cfa1=4+8 cfa2=4+16 Disassembly shows that the function call before the warning location is a call to _4core3str16slice_error_fail, and objtool thought it can return (which will end up with a unbalanced stack if it does return). Thus apply it. - Miguel ] Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Josh Poimboeuf Cc: Peter Zijlstra Reported-by: Alice Ryhl Link: https://lore.kernel.org/rust-for-linux/anLxXvCKBcAVf91_@google.com/ Link: https://lore.kernel.org/rust-for-linux/20260706-hashedptr-v13-0-377a07f2f78d@kylinos.cn/ [1] Link: https://lore.kernel.org/rust-for-linux/DKS7U9UHY6XR.2JC0EBIPCI06Z@garyguo.net/ [2] Link: https://patch.msgid.link/20260805144524.233362-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda commit a5c7d35e2fd3e24c411816c91f8f6cc78e652e0c Author: Nikolai Grlica Date: Mon Aug 10 15:03:35 2026 +0000 rust: kernel: list: fix incorrect pop_back example comment The example uses pop_back(), but the accompanying comment says pop_front(). Update the comment to match the example. Signed-off-by: Nikolai Grlica Cc: stable@vger.kernel.org Fixes: bf87a41b85d6 ("rust: list: Add an example for `ListLinksSelfPtr` usage") Link: https://patch.msgid.link/20260810150322.61809-1-nikolai@nikolaigrlica.dev Signed-off-by: Miguel Ojeda commit b418fa370ea69fc5824e70b63d9f4c93249762e7 Author: Lad Prabhakar Date: Fri Aug 21 22:10:32 2026 +0100 rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs Add support for the RTC block found on the Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs. These SoCs integrate a closely related variant of the RZ/N1 RTC IP, but do not implement the RTCA0SUBU register. Use variant-specific match data to disable SUBU support for these SoCs. Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-18-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit 8af6331c6e7aaec3453b8a158bedb44b271314d7 Author: Lad Prabhakar Date: Fri Aug 21 22:10:31 2026 +0100 rtc: rzn1: Drop trailing comma from OF match table sentinel Drop the trailing comma from the final empty entry in the RZN1 RTC OF match table and mark it explicitly as the sentinel. Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-17-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit 38a3a3b09958d9f2d2a2c72b90a0437cbe8618bf Author: Lad Prabhakar Date: Fri Aug 21 22:10:30 2026 +0100 rtc: rzn1: Add OF match data to gate SUBU register access The RZ/N1 RTC driver selects SCMP mode only when an optional xtal clock is provided at a valid rate other than 32768 Hz. Without an xtal clock, or when it runs at 32768 Hz, the driver uses SUBU mode. However, the RTCA0SUBU register used by SUBU mode is not present on all SoCs that integrate a similar variant of the RTC block. Allowing SUBU mode on those variants would expose RTC offset operations that access a non-existent register. Add OF match data to describe whether the RTC supports the SUBU register. Reject probe with -EOPNOTSUPP when SUBU mode would be selected on a variant without SUBU support. Signed-off-by: Lad Prabhakar Suggested-by: Wolfram Sang Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-16-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit 5ae93269d3e51db730ca3ee96f8833e4d3befd95 Author: Lad Prabhakar Date: Fri Aug 21 22:10:29 2026 +0100 rtc: rzn1: use FIELD_PREP/FIELD_GET and GENMASK for register access Replace open-coded shift and mask operations with the bitfield API. Note that the weekday field is changed from an explicit 0x0f mask to an 8-bit field definition, matching the hardware manual. This does not change behaviour, as valid weekday values cannot exceed 7. Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-15-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit 0e1ae8c654f05d813457bee308f864acea7b5cc1 Author: Lad Prabhakar Date: Fri Aug 21 22:10:28 2026 +0100 rtc: rzn1: Consistently use dev_err_probe() Use dev_err_probe() in the IRQ request error path to make error handling consistent with the rest of rzn1_rtc_probe(). Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-14-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit b587001387c16b3a75b8ed9399feee157ad3d3b4 Author: Lad Prabhakar Date: Fri Aug 21 22:10:27 2026 +0100 rtc: rzn1: Use temporary variable for struct device Use a temporary variable for the struct device pointers to avoid dereferencing. Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-13-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit afb8972b9e36cd519bc30fb63081fe9ae96adec2 Author: Lad Prabhakar Date: Fri Aug 21 22:10:26 2026 +0100 rtc: rzn1: Dynamically calculate synchronization delay based on clock rate Replace the hardcoded hardware synchronization delays with a calculated time window derived from the operating sub-clock frequency. The driver currently hardcodes microsecond ranges assuming a fixed sub-clock frequency of 32.768 kHz. Newer SoC variants, such as the RZ/T2H, drive this hardware block using a much faster clock rate (~195.3 kHz). Hardcoding these wait windows forces faster blocks to over-sleep, introducing unnecessary delays during clock initialization and register configuration. Calculate the duration of the required clock cycles in microseconds based on the runtime clock rate, and store this value in the driver private structure to adjust the usleep_range() and readl_poll_timeout() boundaries dynamically. Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-12-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit 6e0d7d480f2df83dba82e2fa8f6cd453e9a8326f Author: Lad Prabhakar Date: Fri Aug 21 22:10:25 2026 +0100 rtc: rzn1: Replace remove callback with devm_add_action_or_reset() Simplify the driver teardown by registering a managed cleanup action with devm_add_action_or_reset(). This eliminates the explicit probe error path and allows the .remove() callback to be dropped. Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-11-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit ea0ef2e7f83be647be114d8cfaf701a5146eaa90 Author: Lad Prabhakar Date: Fri Aug 21 22:10:24 2026 +0100 rtc: rzn1: Use pm_runtime_put_sync() pm_runtime_put() may trigger the idle check after pm_runtime_disable() is run as part of devm_pm_runtime_enable()'s cleanup action, leaving runtime PM active. Use pm_runtime_put_sync() to ensure the idle check runs synchronously. Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-10-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit 960987abe58d175b94869fb7aca72d7b931b584f Author: Lad Prabhakar Date: Fri Aug 21 22:10:23 2026 +0100 rtc: Kconfig: Broaden RTC_DRV_RZN1 dependency to ARCH_RENESAS Replace the ARCH_RZN1 dependency with ARCH_RENESAS for the RTC_DRV_RZN1 config option to make the driver available across both ARM32 and ARM64 Renesas architectures. The newer RZ/T2H and RZ/N2H ARM64 SoCs integrate a closely related variant of the RTC IP block found on the RZ/N1 SoCs. Update the build dependency and expand the Kconfig help text to allow this driver to be selected for these additional platforms. Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-9-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit cd54d8f09d9b61c67e7fc662f4e4e2ffd65a54f2 Author: Lad Prabhakar Date: Fri Aug 21 22:10:22 2026 +0100 rtc: rzn1: Fix malformed MODULE_AUTHOR string Fix a malformed MODULE_AUTHOR macro in the rtc-rzn1 driver where a missing closing angle bracket on the second author entry creates an invalid format. Correct it to the standard "Name " format. Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-8-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit 51458d5b0a1cfb1b6013400abc95aadf16ed2a57 Author: Lad Prabhakar Date: Fri Aug 21 22:10:21 2026 +0100 rtc: rzn1: Disable alarm interrupt before reprogramming alarm registers rzn1_rtc_set_alarm() updates RZN1_RTC_ALM, RZN1_RTC_ALH and RZN1_RTC_ALW using separate MMIO writes without first disabling the alarm interrupt. If a previous alarm is still enabled, the interrupt can fire while the alarm registers contain a mixture of old and newly written values. Fix this by disabling the alarm interrupt before reprogramming ALM, ALH and ALW with a call to rzn1_rtc_alarm_irq_enable(). Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-7-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit c3e735e9f62022354fc63dbf193cb5614188a33b Author: Lad Prabhakar Date: Fri Aug 21 22:10:20 2026 +0100 rtc: rzn1: Fix alarm range check truncation on 32-bit systems alarm and farest were declared as unsigned long, but rtc_tm_to_time64() returns time64_t (s64). On 32-bit systems where unsigned long is 32 bits, the assignment silently truncates the upper 32 bits of the timestamp. Fix by declaring alarm and farest as time64_t and replacing time_after() with a direct signed comparison, which is correct for time64_t values that will never realistically overflow. Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-6-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit 457b5dbce31209e65e1184716ed3af59cb1c0372 Author: Lad Prabhakar Date: Fri Aug 21 22:10:19 2026 +0100 rtc: rzn1: Handle unset alarm weekday in rzn1_rtc_read_alarm RZN1_RTC_ALW is a weekday bitmask where bit N represents weekday N. When no alarm has been configured, the register has its power-on-reset value of zero. rzn1_rtc_read_alarm() uses fls() to convert the weekday bitmask into a weekday number. When RZN1_RTC_ALW is zero, fls(0) returns zero and fls(wday) - 1 evaluates to -1. This invalid weekday is then used to calculate the alarm date and can either leave tm_wday set to -1 or produce a fabricated alarm date. Treat a zero RZN1_RTC_ALW value as an unset alarm weekday and return without calculating the alarm date. Move reading RZN1_RTC_CTL1 before this check so that alrm->enabled is updated for both configured and unconfigured alarms. Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit 022a2839a52006531804a8db55d3228084400b48 Author: Lad Prabhakar Date: Fri Aug 21 22:10:18 2026 +0100 rtc: rzn1: Fix weekday underflow when alarm crosses month boundary rzn1_rtc_set_alarm() calculates the alarm weekday from the difference between the alarm day and the current day of the month. When the alarm crosses a month boundary, this difference can become negative. Since days_ahead is unsigned, it underflows and results in an incorrect weekday being programmed into RZN1_RTC_ALW. The RTC core already provides a fully populated struct rtc_time for the alarm, including the correct tm_wday. Use tm->tm_wday directly instead of recalculating the weekday from the day-of-month. This avoids the underflow and ensures alarms scheduled across a month boundary use the correct weekday. Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Suggested-by: Wolfram Sang Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit 708546aa39560a11cf44c7ba99492c8395a6c2fb Author: Lad Prabhakar Date: Fri Aug 21 22:10:17 2026 +0100 rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt Check for -EPROBE_DEFER from platform_get_irq_byname_optional() and handle the deferred probe request properly. Although the "pps" interrupt is optional, an error code of -EPROBE_DEFER indicates that the interrupt subsystem is not yet ready. Intercept this specific error condition, assign it to the return value, and jump to the dis_runtime_pm label to avoid ignoring a valid probe deferral. Fixes: eea7791e00f33 ("rtc: rzn1: implement one-second accuracy for alarms") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit 1ffb5be3e4be37a8f8d88861d3e1a1a1539b4c97 Author: Lad Prabhakar Date: Fri Aug 21 22:10:16 2026 +0100 dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support Add compatible strings for the RTC block found on the Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs. These SoCs integrate a closely related variant of the RZ/N1 RTC IP. Unlike RZ/N1, they do not implement the RTCA0SUBU register. This is not a limitation for Linux support, as these registers are not used when the RTC operates in "scmp" clock mode, which is required on RZ/T2H and RZ/N2H due to their 195.3 kHz input clock. The RZ/T2H RTC variant also supports a 1Hz output signal on the RTCAT1HZ pin, controlled by the RTCA0CTL1[RTCA01HZE] bit. This bit is marked as reserved in the RZ/N1 hardware manual. Update the binding schema to require the additional clock inputs used by these SoCs. Signed-off-by: Lad Prabhakar Acked-by: Conor Dooley Reviewed-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni commit b6b019a1d9b90ac51174f0ca15b1338b61506bf9 Merge: 66ec24c5d7a047 8b585431a16cfb Author: Linus Torvalds Date: Sun Aug 23 10:30:02 2026 -0700 Merge tag 'parisc-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc architecture updates from Helge Deller: - Drop PER_HPUX personality from UAPI headers - Infinite loop fix when parsing IRQ value in eisa code - Switch to use asm-generic/serial.h - Prevent possible unaligned asm code in head.S * tag 'parisc-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: eisa: Fix infinite loop when parsing invalid IRQ value parisc: Fix alignment of asm statements in head.S parisc: eisa_eeprom: Add missing MODULE_DESCRIPTION() parisc: Use asm-generic/serial.h parisc: sba_iommu: Remove dead DEBUG_DMB_TRAP code UAPI: Drop PER_HPUX personality parisc: superio: Spelling s/Peterson/Petersen/ commit 66ec24c5d7a047f5b06ee1deb1d0a2869b1791bd Merge: 388b607d107c07 101782f8945a12 Author: Linus Torvalds Date: Sun Aug 23 10:26:44 2026 -0700 Merge tag 's390-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 updates from Vasily Gorbik: - Add a cpuidle driver with polling and enabled wait states using the existing CPU idle infrastructure and idle governor to improve latency for frequent sleep/wakeup cycles. Remove the obsolete tick delay heuristic and generic arch_needs_cpu() hook. Add the corresponding driver entry to MAINTAINERS - Add kCFI support using the generic support provided by Clang - Enable Clang CONTEXT_ANALYSIS for various architecture code and for char, PCI, CIO and virtio drivers. Add required lock annotations, exclude unsupported mm helpers and remove conditional PCI locking - Fix secure storage access exception handling and reintroduce DCACHE_WORD_ACCESS previously removed as a workaround - Fix cpum_cf perf crashes when CPUs are brought online while per-task events are active. Allocate and remove per-CPU counter data from CPU hotplug callbacks - Fix a deadlock when an s390dbf debug area is unregistered while one of its debugfs files is being written to - Fix MVIY_PERCPU() with binutils older than 2.39, where an assembler macro silently omitted an instruction needed to repair interrupted operations after CPU migration - Remove/replace cond_resched() calls which are no-ops with the supported s390 preemption models - Fix AP queue depth and maximum message length decoding according to the architecture. Current hardware is not affected, but future hardware could report values which were handled incorrectly - Reflect the configured CPU state in cpu_enabled_mask so deconfigured CPUs are not presented as available for onlining - Restore the vDSO GNU_EH_FRAME program header which was lost when the build switched to direct linker invocation, and mark it read-only - Add SCLP action qualifiers used by Spyre for card initialization, recoverable error and telemetry reporting - Move KMSAN interrupt flag helpers out of line to fix -Wstatic-in-inline build warnings - Use level-specific page table entry accessors for hugetlb entries and ptep_get() when accessing crashed kernel memory in kdump - Make forced AP bus rescans killable so that a user process blocked behind an ongoing scan can still be terminated with SIGKILL - Rework pkey ioctl error paths to remove duplicated cleanup code and avoid freeing error pointers - Allow the protected guest SWIOTLB buffer to be allocated outside the first 2GB. Also enable dynamic SWIOTLB growth and the coherent atomic pool fallback to improve I/O behavior when the initial pool is exhausted - Add program check statistics and spinlock contention tracepoints. Increase the lockdep chain capacity to keep lockdep enabled for complex code paths such as btrfs - Simplify IPL, trap and syscall code and remove the obsolete unistd_32.h generation entry * tag 's390-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (59 commits) s390/percpu: Fix MVIY_PERCPU() with older binutils s390/debug: Fix deadlock during unregister s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks s390: Enable CONTEXT_ANALYSIS for various directories s390/mm: Add __context_unsafe() attribute to gmap helper functions s390/mm: Add __context_unsafe() attribute to do_secure_storage_access() s390/sysinfo: Add context analysis attributes s390/irqflags: Add out-of-line definitions of arch_local_irq_*() for KMSAN s390/virtio: Enable CONTEXT_ANALYSIS s390/cio: Enable CONTEXT_ANALYSIS s390/vfio_ccw: Add __must_hold() attribute to vfio_ccw_sch_quiesce() s390/pci: Enable CONTEXT_ANALYSIS s390/pci: Rework __zpci_event_availability() to remove conditional locking s390/pci: Rework __zpci_event_error() to remove conditional locking s390/char: Enable CONTEXT_ANALYSIS s390/con3215: Add __must_hold() attribute to raw3215_make_room() s390/ap: Fix MAPML computation s390/cio: Remove cond_resched() calls s390: Remove cond_resched() calls KVM: s390: Remove cond_resched() calls ... commit cb732d027aa18e1fcf9d2797f47d20b179ebc59c Author: Sajal Gupta Date: Fri Aug 21 12:46:13 2026 +0530 drm/gud: validate GUD_ROTATION_0 is present in supported rotations The rotation argument to drm_plane_create_rotation_property() is set to DRM_MODE_ROTATE_0, and the device reported rotation bitmask is used as the supported_rotations argument. The driver never validates that GUD_ROTATION_0 is present, so a device that omits it from its GUD_PROPERTY_ROTATION triggers the WARN_ON(rotation & ~supported_rotations) in drm_plane_create_rotation_property() Fix this by skipping the creation of rotation property if the device doesn't have the GUD_ROTATION_0 bit Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Reported-by: syzbot+efe2810681f1b065d3a8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=efe2810681f1b065d3a8 Tested-by: syzbot+efe2810681f1b065d3a8@syzkaller.appspotmail.com Signed-off-by: Sajal Gupta Acked-by: Ruben Wauters Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260821071812.16500-1-sajal2005gupta@gmail.com commit 388b607d107c07aaade04c7f22f344cab6bdccd3 Merge: 91959a31a39900 b2326338dc683e Author: Linus Torvalds Date: Sun Aug 23 09:24:34 2026 -0700 Merge tag 'efi-next-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI updates from Ard Biesheuvel: - Set a timeout for EFI runtime service completions, and declare the firmware wedged if it is exceeded. Note that this requires special handling in case the firmware does return after all - Rate limit the efivarfs statfs() handler as the QueryVariableInfo() runtime service can be costly - Sanity check the size of struct properties_header on Mac/x86 - Tweak the prototype of efi_guid_to_str() * tag 'efi-next-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efivarfs: Rate limit statfs() handler efi: apple-properties: validate setup data header length efi: make efi_guid_to_str() take a const GUID pointer efi/runtime-wrappers: retire the worker if a wedged call ever returns efi/runtime-wrappers: honour EFI_RUNTIME_SERVICES in the non-blocking paths efi/runtime-wrappers: bound the wait for EFI runtime service calls efi/runtime-wrappers: check EFI_RUNTIME_SERVICES before using efi_rts_work efi/runtime-wrappers: handle queue_work() failure with goto exit efi/runtime-wrappers: factor out efi_rts_park_worker() efi: fix stale reference to efi_recover_from_page_fault() commit da1ea35fea67ad841f4ada28dd61b41be65e5437 Author: Tao Yu Date: Wed Aug 19 15:28:35 2026 +0800 drm/gud: validate TV mode names before creating enum property The GUD protocol returns TV mode names as fixed-size GUD_CONNECTOR_TV_MODE_NAME_LEN entries and requires each name to be NUL-terminated. gud_connector_add_tv_mode() currently passes each fixed-size entry directly to drm_mode_create_tv_properties_legacy(), which eventually reaches drm_property_add_enum() and strlen(). If a device returns an entry without a terminating NUL byte, strlen() reads past the end of the slot and can run beyond the allocated buffer, triggering an out-of-bounds read. Validate that each returned TV mode name contains a NUL terminator within its fixed-size slot before passing it to the DRM property code. If a malformed entry is found, reject the device response with -EIO. This fixes the out-of-bounds read without changing the handling of valid devices, and avoids silently truncating malformed protocol data. Reported-by: syzbot+9ae8e7884e451eaed5b4@syzkaller.appspotmail.com Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Signed-off-by: Tao Yu Reviewed-by: Ruben Wauters Cc: Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260819072835.4074130-1-tao1.yu@intel.com commit 91959a31a3990073b55b506af044eda09c359fb4 Merge: df51bdc5e80dae bc0f793c5c4160 Author: Linus Torvalds Date: Sun Aug 23 09:17:38 2026 -0700 Merge tag 'liveupdate-v7.3-rc1-20260823' of git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux Pull more liveupdate updates from Mike Rapoport: "Make boot time huge page allocation work nicely with kexec handover. Today allocation of gigantic pages in HugeTLB cannot work reliably with kexec handover (KHO): - HugeTLB allocates gigantic pages using memblock and autoscaling of KHO scratch accounts for these allocations. When gigantic pages occupy half of the memory of more, KHO fails to allocate its scratch memory. - After kexec handover, memblock allocations exclusively use KHO scratch that is not supposed to contain preserved memory. This essentially blocks preservation of HugeTLB with gigantic pages. Extend early memory pools available for KHO kernel with areas that are guaranteed not to contain preserved memory" * tag 'liveupdate-v7.3-rc1-20260823' of git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux: (21 commits) kho: exclude hugetlb memory from scratch size calculation memblock: add memblock_reserved_hugetlb_size() memblock: make HugeTLB bootmem allocation work with KHO memblock: always include KHO headers kho: extend scratch mm/mm_init: don't rely on memblock to get KHO scratch migratetype kho: initialize preserved memory map radix tree earlier kho: initialize kho_scratch pointer earlier in boot kho: expose kho_scratch_overlap() to kexec_handover.h kho: add kho_radix_init_tree() kho: allow destroying KHO radix tree kho: allow early-boot usage of the KHO radix tree kho: add data argument to radix walk callback kho: add callback for table pages kho: add a struct for radix callbacks kho: move all memory retrieval logic to kho_mem_retrieve() kho: store incoming radix tree in kho_in kho: disallow wide keys in radix tree kho: make radix max key width more obvious kho: generalize radix tree APIs ... commit df51bdc5e80dae43cab81f6cc641e98638303c88 Merge: 61a09cfc121472 9b7e2fe0fe37f7 Author: Linus Torvalds Date: Sun Aug 23 09:11:21 2026 -0700 Merge tag 'mtd/for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull mtd updates from Miquel Raynal: "Raw NAND changes: - Sunxi: Support added for the H616 compatible - Qcom: Support added for the MDM9607 compatible - Support for the Toshiba TC58NVG1S3H part - GPMI: New debugfs entry to expose the chip geometry - PL353: Timing updates and software ECC support have been fixed SPI NAND changes: - fmsh: Support added for FM25G{01,02}B chips - HeYangTek: Support added for HYF1GQ4UDACAE Aside from these main changes, there is a high load of misc fixes and hardening changes, and exceptionally no SPI NOR change" * tag 'mtd/for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (30 commits) mtd: rawnand: sunxi: fix H6/H616 controller timings mtd: rawnand: sunxi: describe tADL and tWHR delays mtd: rawnand: sunxi: group controller delay tables mtd: maps: remove dead select of MTD_CFI_BE_BYTE_SWAP mtd: rawnand: gpmi: add debugfs entry for BCH geometry mtd: rawnand: validate ONFI extended parameter page sections mtd: rawnand: sunxi: add H616 MBUS DMA support mtd: spinand: fmsh: fix FM25G01B/FM25G02B Quad I/O read dummy cycles mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() mtd: mpc5121_nfc: use platform for irq and ioremap mtd: mtdoops: free page bitmap when the backing MTD is removed mtd: mtdswap: Avoid freeing registered blktrans device twice mtd: afs: validate v2 image info bounds mtd: intel-dg: Fix runtime PM error path in probe mtd: nand-omap2: Move omap_nand_ids[] to raw nand driver mtd: rawnand: add Toshiba TC58NVG1S3H mtd: nand: realtek-ecc: add missing MODULE_DEVICE_TABLE() mtd: rawnand: qcom: Add MDM9607 compatible mtd: rawnand: qcom: Make has_onfi_read_op separate from qpic_version2 mtd: rawnand: qcom: Make "aon" clock optional ... commit 61a09cfc121472013f99ae75066676739a5db626 Merge: 0714cf44ac7662 4c6320e0ad400d Author: Linus Torvalds Date: Sun Aug 23 08:41:36 2026 -0700 Merge tag 'ksmbd-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/smb Pull smb server updates from Namjae Jeon: "This contains server updates focused on SMB2 command sequencing, SMB3 request replay and encryption, Apple Time Machine interoperability, protocol-compatibility fixes validated with smbtorture, security hardening, SMB Direct transport support, connection reliability, and other correctness improvements. New features: - Implement the SMB2 command sequence window Enforce the credit-based MessageId range for each connection, rejecting out-of-window, duplicate, and wrapped sequence numbers. This prevents invalid requests and same-channel replays from being processed - Add SMB3 request replay support SMB3 clients may resend requests with SMB2_FLAGS_REPLAY_OPERATION after a channel disconnect when the original response was lost. Track the required channel and open state to safely handle durable CREATE replays and make oplock, lease, and lock replays idempotent, avoiding duplicate state changes and improving multichannel reconnect reliability - Add opt-in Apple Time Machine support Implement the AAPL negotiation and related Finder, stream, COPYCHUNK, sparse-file, CHANGE_NOTIFY, and RPC compatibility required for Time Machine shares, allowing macOS backupd to use ksmbd for backups - Add per-share SMB3 encryption support Allow individual shares to require SMB3 encryption by advertising SMB2_SHAREFLAG_ENCRYPT_DATA in TREE_CONNECT responses and rejecting unencrypted tree connects and plaintext requests for protected shares - Add SMB Direct RDMA encryption support Extend SMB Direct to support SMB3 encrypted payloads over RDMA, with transform negotiation and encryption/decryption for RDMA READ/WRITE Other changes: - Parse and retain AppInstanceVersion contexts, enforce version ordering, close older active handles for newer takeovers, and reject invalid or unversioned opens according to the SMB2 semantics - Accept durable reconnect requests that omit VolatileFileId when the persistent ID and reconnect context identify the handle, while continuing to reject explicit volatile-ID mismatches - Fix SMB2/SMB3 protocol validation and security issues, including request offsets, file and object IDs, IPC responses, output buffer sizes, SMB3.1.1 binding validation, signing-required handling, durable handles, ACLs, maximal access, and security information - Fix heap out-of-bounds accesses, use-after-free bugs, memory leaks, invalid pointer dereferences, and sensitive-data lifetime issues in authentication, Kerberos, preauthentication, sessions, connections, and module teardown - Correct alternate-data-stream and named-stream handling, COPYCHUNK behavior, sparse-file and compression attributes, allocated-range queries, file trimming, duplicate extents, DOS attributes, snapshots, normalized names, and partial information responses - Fix locking, lease, oplock, durable reconnect, async request, and CHANGE_NOTIFY races, including deferred-lock rollback, parent directory lease notifications, and connection teardown lifetime bugs - Fix SMB3 encryption handling for compressed requests, expired encrypted sessions, interim responses, bound multichannel connections, and decryption failures - Fix SMB3 multichannel session lookup and session state transitions so changes are scoped to the correct bound connections and cannot revive connections that are already shutting down - Fix DACL access checks so ACE walks are bounded by the declared DACL size, preventing data beyond the DACL boundary from being interpreted during access validation - Fix session accounting and lifetime issues, including session counter updates during publication and removal, session leaks on registration failure, and procfs creation diagnostics - Improve TCP connection reliability by enabling TCP keepalive for accepted connections and preserving TCP timers for kernel sockets, preventing silent peers from holding connections indefinitely - Fix smbdirect RDMA cleanup ordering for completion queues, QPs, child sockets, and listener locking - Improve async response framing, multi-iovec signing, RPC pipe status handling, and ksmbd procfs monitoring for server, share, connection, session, and open-file state - Remove the obsolete DES crypto header and Kconfig dependency now that NTLMv1 support has been removed - Update the ksmbd repository URL in MAINTAINERS and add an additional KSMBD reviewer" * tag 'ksmbd-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/smb: (142 commits) MAINTAINERS: update ksmbd repository URL MAINTAINERS: add myself as KSMBD reviewer smb: server: remove unused DES crypto header smb: server: Remove obsolete "select CRYPTO_LIB_DES" from Kconfig file ksmbd: keep TCP timers alive for kernel sockets ksmbd: enable TCP keepalive for accepted connections smb/server: fix session counter on session removal smb/server: update session counter under sessions table lock smb/server: fix session leak in ksmbd_session_register() smb/server: warn if ksmbd_proc_create() fails ksmbd: bound smb_check_perm_dacl() ACE walks by DACL size ksmbd: make RDMA encryption diagnostics conditional ksmbd: add SMB Direct RDMA encryption transform ksmbd: handle encrypted compressed requests ksmbd: decrypt requests from expired encrypted sessions ksmbd: disconnect on SMB3 decryption failure ksmbd: encrypt interim responses to encrypted requests ksmbd: scope session state changes to bound connections ksmbd: fix encrypted request lookup on bound channels ksmbd: add per-share SMB3 encryption enforcement ... commit 500cb24cd61bad8a2747ddfc49b7034899c82d94 Author: Deepanshu Kartikey Date: Sun Aug 16 14:22:34 2026 +0530 drm/gud: NUL-terminate TV mode names read from the device gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use. Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Reported-by: syzbot+916c888ba5f1a54c9526@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=916c888ba5f1a54c9526 Tested-by: syzbot+916c888ba5f1a54c9526@syzkaller.appspotmail.com Signed-off-by: Deepanshu Kartikey Acked-by: Ruben Wauters Cc: Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260816085234.22053-1-kartikey406@gmail.com commit 0714cf44ac7662d15308db020ac3d0c4c5f7232b Author: David Sterba Date: Wed Aug 19 12:28:27 2026 +0200 MAINTAINERS: update btrfs git tree entries Add new entry pointing to the development branch so e.g. sashiko can pick it as the baseline. The other entry is for linux-next and slightly behind. Signed-off-by: David Sterba Signed-off-by: Linus Torvalds commit 8552019d09867164a6350bda7d731f140a90d7ac Merge: e5f92606156a6a 5e2d672280d97d Author: Linus Torvalds Date: Sun Aug 23 08:29:33 2026 -0700 Merge tag 'for-next-keys-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd Pull TPM update from Jarkko Sakkinen: "Just a single bug fix" * tag 'for-next-keys-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: KEYS: trusted: Fix TPM teardown ordering commit e5f92606156a6a823992294d214c285b49cd72e9 Merge: 2709dd5ae32f08 eef628bce8e18c Author: Linus Torvalds Date: Sun Aug 23 08:07:11 2026 -0700 Merge tag 'mm-nonmm-stable-2026-08-22-16-57' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull non-MM updates from Andrew Morton: - "ocfs2/dlm: bound peer-controlled lengths in the o2dlm" (Bryam Vargas) Validate and bound all input lengths and count fields in the o2dlm migration and recovery receive handlers to prevent memory corruption and kernel panics from malformed cluster messages - "ocfs2: validate xattr entry bounds" (Cen Zhang) Validate OCFS2 extended attribute entry name and value bounds during metadata reads to prevent out-of-range memory accesses during retrieval or listing operations. - "taskstats: fix cgroupstats invalid fd handling and add selftests" (Yiyang Chen) Return -EBADF when cgroupstats receives an invalid file descriptor to prevent caller hangs and misleading success ACKs. Add a kselftest to validate valid cgroup v1 queries and verify proper error handling across different Netlink flag combinations. - "misc lib/raid/ improvements v2" (Christoph Hellwig) Improve benchmark-based algorithm selection for the XOR and RAID6 libraries, add KUnit benchmark tests, and cleanup minor implementation details. - "ocfs2: cluster: o2hb_region_pin() fixes" (Joseph Qi) Fix sleeping-in-atomic, lock order inversion and error-path cleanup bugs in o2hb_region_pin() by releasing o2hb_live_lock across sleeping configfs_depend_item() calls and using unlocked variants from callback context. Ensure failed pin attempts properly decrement user counts and unpin partially initialized heartbeat regions to prevent memory leaks and unprotected states. - "lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()" (Vincent Mailhol) Fix an off-by-one which could cause an out-of-bounds read. - "ocfs2: harden heartbeat teardown races" (Cen Zhang) Fix two OCFS2 heartbeat/o2net teardown races found by KASAN. - "taskstats: tidy up the cpumask command path" *Bradley Morgan) make two small cleanups in kernel/taskstats.c. - "ocfs2: validate active orphan slots during inode read" (ZhengYuan Huang) Validate active ordinary and append-DIO orphan slots read from OCFS2 dinodes at the metadata boundary to prevent corrupted slot indices from causing out-of-bounds array accesses. - "ocfs2: bound-check both readdir re-validation scans" (Zhan Xusheng) Enforce strict boundary checks on directory entry record lengths and offset calculations during OCFS2 directory re-scans to prevent out-of-bounds memory reads and directory position corruption. * tag 'mm-nonmm-stable-2026-08-22-16-57' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (95 commits) mailmap: fix bouncing address for Taniya Das ocfs2: bound-check dir entries in the inline-data re-validation scan ocfs2: bound-check dir entries in the readdir re-validation scan squashfs: avoid thundering-herd cache wakeups prctl: fix PR_SET_MM_AUXV losing the forced AT_NULL terminator mailmap: update email address for Linfeng Sun lib/interval_tree: fix allocation warning messages checkpatch: add NOKPROBE_SYMBOL to the whitelist of lines that can occur immediately after functions Squashfs: check block offset is not negative signal: factor out the kernel reserved si_code check ocfs2: fix readdir position truncation on 32-bit kernels ocfs2: fix cached cluster count after suballocator reclaim ocfs2: fix circular locking dependency in ocfs2_init_acl() ocfs2: validate DIO orphan slot during inode read ocfs2: validate orphan slot during inode read selftests/prctl: fix non-anonymous VMA mapping in set-anon-vma-name test MAINTAINERS: add IRC and patchwork for LTP include/linux/list.h: mark list_add and __list_add as __always_inline tools/mm: prevent page_owner_sort from truncating input hung_task: update DETECT_HUNG_TASK_BLOCKER Kconfig help ... commit 9b7e2fe0fe37f79e35467929d578c8c9f0f9cfdd Merge: 94d32f1ace8ee3 15a3cbce329941 Author: Miquel Raynal Date: Sun Aug 23 14:30:31 2026 +0200 Merge tag 'nand/for-7.3' into mtd/next * Raw NAND changes - Sunxi: Support added for the H616 compatible - Qcom: Support added for the MDM9607 compatible - Support for the Toshiba TC58NVG1S3H part - GPMI: New debugfs entry to expose the chip geometry - PL353: Timing updates and software ECC support have been fixed * SPI NAND changes - fmsh: Support added for FM25G{01,02}B chips - HeYangTek: Support added for HYF1GQ4UDACAE Aside from these main changes, there is the usual load of misc fixes and hardening changes. commit 17056a36d276a740f09dca723de1bc6aa3eb4ef9 Author: Will Porter Date: Sat Aug 22 20:53:53 2026 -0500 ALSA: usb-audio: Add iD14 MkI to monitor-mix volume quirk Add the iD14 MkI USB ID to the existing audient_id14_map. This names feature unit 12 Monitor Mix Playback Volume. Live meter A/B testing on MkI USB ID 2708:0002 reproduced the same asymmetric attenuation seen on MkII. At ALSA value 104, the right channel was 23.07 dB below the left. At 127, both channels were equal. The misleading Speaker Playback Volume name causes PipeWire to adopt FU12 as the stream master. Reuse the existing map to keep the control available while preventing that selection. Hardware-tested on Bazzite 7.2.0-ogc4.1.fc44.x86_64 with this change backported. ALSA exposed Monitor Mix Playback Volume after module load and USB reconnect. PipeWire volume changes from 100% to 35% and back left all four FU12 values at 127. Channel-isolated left/right playback remained balanced after reconnect. Build-tested with CONFIG_SND_USB_AUDIO=m using the focused sound/usb target. Assisted-by: Codex:gpt-5 Signed-off-by: Will Porter Link: https://patch.msgid.link/20260823015353.686080-1-mrwillporter@gmail.com Signed-off-by: Takashi Iwai commit 3ac761b613c744aa22e269d31801053e38bb4968 Author: Rong Zhang Date: Sun Aug 23 02:52:31 2026 +0800 ALSA: usb-audio: Add quirk flags for Logitech PRO X Wireless The Logitech PRO X Wireless is a wireless headset with a hotpluggable microphone. Its Playback mixer's GET_CUR somehow becomes broken when the microphone is detached, so set QUIRK_FLAG_MIXER_GET_CUR_OK to prevent the mixer behavior from depending on whether the microphone is attached. Meanwhile, the Playback mixer's minimum value doesn't work properly, thus set QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE to prevent userspace audio stack from using the minimum mixer value to tune volume (setting it when muted is OK). Reported-by: Alexander Niemeyer Closes: https://msgid.link/6262cbbd-d1f2-4c9d-a1c7-9c5d12636f4b@gmx.de Closes: https://msgid.link/7984832b-86f6-4934-bfc0-1ed70218973a@gmx.de Signed-off-by: Rong Zhang Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260823-uac-demote-sticky-check-v1-4-a8cbe572edff@rong.moe commit 9e8a6fc3b1a5ee7e3ccbd11ba7d5bfeb7eaf8ebf Author: Rong Zhang Date: Sun Aug 23 02:52:30 2026 +0800 ALSA: usb-audio: Reverse MIXER_GET_CUR_BROKEN as MIXER_GET_CUR_OK The default behavior of sticky check now becomes what QUIRK_FLAG_MIXER_GET_CUR_BROKEN originally does, so the quirk flag is no longer needed. On some devices, whether their GET_CUR being sticky depends on whether hotpluggable components are present. When the hotpluggable components are missing on probe, their GET_CUR behavior is classified as broken. Therefore, reverse QUIRK_FLAG_MIXER_GET_CUR_BROKEN as QUIRK_FLAG_MIXER_GET_CUR_OK, so that it can be set to prevent the heuristics from gating GET_CUR. Note that even if the quirk flag is set, init_cur_mix_raw() should still initialize the mixer value to cval->min, otherwise restoring the bogus saved value on the first channel could lead to unbalanced channels. Signed-off-by: Rong Zhang Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260823-uac-demote-sticky-check-v1-3-a8cbe572edff@rong.moe commit 3c87a903a6820a0789bbab61681dd570d6030260 Author: Rong Zhang Date: Sun Aug 23 02:52:29 2026 +0800 ALSA: usb-audio: Demote the severity of sticky GET_CUR Currently, a mixer is disabled when its GET_CUR is sticky, causing userspace to fall back to soft mixers, unless QUIRK_FLAG_MIXER_GET_CUR_BROKEN is set. This leads to issues on some wireless headphones with broken GET_CUR but effective SET_CUR, which use poorly-performed lossy codecs and are prone to audible distortion at low volume. They have to set the quirk flag to reeanble the mixer. Considering that users can always opt into soft mixers if they need it, i.e., when SET_CUR is stubbed, demote the severity of sticky GET_CUR by marking GET_CUR as broken and only provide mixer values from the cache. The mixer itself is still registered. Signed-off-by: Rong Zhang Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260823-uac-demote-sticky-check-v1-2-a8cbe572edff@rong.moe commit f3d14f0a8dc30eb9755ecd24c853e6eff882fb80 Author: Rong Zhang Date: Sun Aug 23 02:52:28 2026 +0800 ALSA: doc: usb-audio: Add doc for QUIRK_FLAG_ALWAYS_SET_RATE QUIRK_FLAG_ALWAYS_SET_RATE was introduced into usb-audio before without appropriate documentation, so add it. There is an odd colon in its comments, so remove it too. As this is often forgotten, also add a reminder to the end of the enumeration. Fixes: 786f91da8535 ("ALSA: usb-audio: add QUIRK_FLAG_ALWAYS_SET_RATE for Mackie DLZ Creator XS") Signed-off-by: Rong Zhang Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260823-uac-demote-sticky-check-v1-1-a8cbe572edff@rong.moe commit af79b081ce332a3cb0e5c11b7666c6af5d5f4cbc Author: Edward Blair Date: Sat Aug 22 12:41:10 2026 +0100 ALSA: usb-audio: Add quirk flags for SMSL USB DAC The SMSL USB DAC with USB ID 152a:85dd produces an audible pop when snd-usb-audio performs its redundant probe-time interface setup. It also pops when returning from runtime suspend. Skip the probe-time interface setup and disable runtime autosuspend for this device. Both flags have been verified through the quirk_flags module parameter. Keep QUIRK_FLAG_DSD_RAW in the device entry because the exact match takes precedence over the generic 0x152a vendor entry from which the device currently inherits that flag. Signed-off-by: Edward Blair Link: https://patch.msgid.link/20260822114110.1069541-1-edward.blair@gmail.com Signed-off-by: Takashi Iwai commit 1fcccdc20a76b4639b00124cf2a379b837bd2bf7 Author: Csaba Budai Date: Fri Aug 21 12:25:14 2026 +0200 ALSA: hda/realtek: Fix ALC700 audio on Intel Hades Canyon On Intel Hades Canyon systems with an ALC700 codec, analog audio can become unusable after rebooting from Windows into Linux. The affected system uses codec subsystem ID 8086:2073. In the broken state, Realtek coefficient 0x1b has value 0x4a4b. Setting bit 0x0400 changes it to 0x4e4b and immediately restores normal analog playback. The BIOS also sets this bit after disabling and re-enabling onboard audio, while Windows may leave it cleared. Linux currently does not restore it during codec initialization. Add a machine-specific fixup for Intel Hades Canyon which sets only bit 0x0400 of coefficient 0x1b during HDA_FIXUP_ACT_INIT. The fix has been verified across Windows -> Linux reboots on an Intel NUC8i7HNB with an ALC700 codec. Signed-off-by: Csaba Budai Link: https://patch.msgid.link/20260821102514.11194-1-ilyr73@gmail.com Signed-off-by: Takashi Iwai commit 2709dd5ae32f0828f386327c76bba9f39f63a1c6 Merge: 0d78592583949b 23906f3a1686c7 Author: Linus Torvalds Date: Sat Aug 22 16:40:23 2026 -0700 Merge tag 'sched-urgent-2026-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Ingo Molnar: - Add missing cpus_read_lock locking to rebuild_sched_domains() (Sebastian Andrzej Siewior) - Fix division by zero bug in tg_cpus() that can be triggered with empty cpusets (Jake Steinman) * tag 'sched-urgent-2026-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/fair: Floor tg_cpus() at 1 sched/topology: Add a cpus_read_lock to rebuild_sched_domains() commit 0d78592583949b531318b51763ade7ff536ba9bc Merge: d4fd1603f302e6 d8aa5dd97944a7 Author: Linus Torvalds Date: Sat Aug 22 16:29:20 2026 -0700 Merge tag 'locking-urgent-2026-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull futex fixes from Ingo Molnar: - Enforce that the private futex owner shares the mm when attaching (Kyle Zeng, Thomas Gleixner) - Fix race on the initial mm->futex.phash.ref allocation (Hyunwoo Kim) - Fix might_sleep() warning in futex_pivot_pending() (Peter Zijlstra) * tag 'locking-urgent-2026-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: futex: Fix might_sleep() warning in futex_pivot_pending() futex: Fix race on the initial mm->futex.phash.ref allocation futex: Clean up the redundant exit/exec functions futex/pi: Plug private futex exec() race futex: Sanitize and document task_struct::futex::state transitions futex/pi: Reject cross-mm private futex owners commit d4fd1603f302e6d9a35e4475725479b7fde5c5d9 Merge: 81ed8bd71e093f 58b34b72b64bfb Author: Linus Torvalds Date: Sat Aug 22 16:25:25 2026 -0700 Merge tag 'irq-urgent-2026-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irqchip driver fixes from Ingo Molnar: - Fix potential loss of interrupt in the renesas-rzg2l irqchip driver (Biju Das) - Fix a series of mostly corner case & error handling bugs in the gic-v5 irqchip driver (Lorenzo Pieralisi) - Fix hardware probing on the ast2700-intc irqchip driver (Michael Pesa) - Fix endianness bug on the Realtek Interrupt Controller (Rustam Adilov) - Fix incorrect sleeping allocation in critical section in the ast2700-intc irqchip driver (Ryan Chen) - Fix two bugs in the GICv5 irqchip driver: clear IRQ affinity properly on teardown, and fix IRQ serialization bug on disabling the IRQ (Sascha Bischoff) * tag 'irq-urgent-2026-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel() irqchip/gic-v5: Defer default SPI and LPI IAFFID programming irqchip/gic-v5: Use logical cpu 0 irs_data for dynamic IST allocation irqchip/gic-v5: Release IRS iomem region on driver init failure irqchip/gic-v5: Fix gicv5_init_common() error paths irqchip/gic-v5: Disable IRSes on probe failures irqchip/gic-v5: Check for NULL LPI domain on domain teardown irqchip/gic-v5: Check get_logical_index() return value in MADT IAFFID parsing irqchip/gic-v5: Synchronize CPU interface disable irqchip/gic-v5: Clear per-CPU IRS data on teardown irqchip/ast2700-intc: Disable all interrupt merge banks on probe irqchip/ast2700-intc: Avoid allocating in the irq_domain activate() callback irqchip/renesas-rzg2l: Fix loss of interrupt commit 81ed8bd71e093fa2bed806c3b19bbcbaa3a85080 Merge: e13629f4df7e71 c793bbfc4a0a9f e1e3a0ab69c64e Author: Linus Torvalds Date: Sat Aug 22 16:11:56 2026 -0700 Merge tags 'core-urgent-2026-08-22' and 'timers-urgent-2026-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fixes from Ingo Molnar: - Fix timer debugobjects state corruption on CPU offlining (Thomas Gleixner) - Fix ARM get_cycles() regression causing boot hangs on certain ARM configs (Nathan Chancellor) * tag 'core-urgent-2026-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: timer: Keep debugobjects state consistent in migrate_timer_list() * tag 'timers-urgent-2026-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: ARM: Fix get_cycles() after delay_read_timer() conversion commit e13629f4df7e7159d82b11e43149308978103ec9 Merge: 66fb95a521110d a511442085c140 Author: Linus Torvalds Date: Sat Aug 22 15:49:36 2026 -0700 Merge tag 'unicode-for-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/krisman/unicode Pull unicode updates from Gabriel Krisman Bertazi: "Two minor fixes: - Remove the normalization function that we no longer use (David Alan Gilbert)) - Fix a parsing issue in the encoding version argument passed by filesystems (me)" * tag 'unicode-for-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/krisman/unicode: unicode: Properly reject invalid encoding version strings utf8: Remove unused utf8_normalize commit 372f8534244d632ad5118e8a87a11291b01712d3 Author: Deepanshu Kartikey Date: Mon Aug 17 19:36:55 2026 +0530 tracing: Fix use-after-free in trace_pipe read on sub-buffer order change Writing to buffer_subbuf_size_kb calls ring_buffer_subbuf_order_set(), which frees every sub-buffer of the ring buffer, including the reader page, and replaces them with newly allocated ones. Readers of trace_pipe hold pointers into those pages. ring_buffer_peek() looks up an event under cpu_buffer->reader_lock but returns the event pointer after dropping the lock, and peek_next_entry() then calls ring_buffer_event_length() and ring_buffer_event_data() on it. If the sub-buffer order is changed in that window, the reader dereferences freed memory: BUG: KASAN: use-after-free in ring_buffer_peek+0x3e0/0x430 Read of size 1 at addr ffff88802a4cf010 by task syz-executor989/6002 Freed by: free_buffer_page kernel/trace/ring_buffer.c:398 [inline] ring_buffer_subbuf_order_set+0x1325/0x18e0 kernel/trace/ring_buffer.c:7444 buffer_subbuf_size_write+0x182/0x280 kernel/trace/trace.c:8221 Take trace_access_lock(RING_BUFFER_ALL_CPUS) around the order change. This is the lock trace_pipe readers already hold across their entire peek-and-print loop, so the swap can no longer race with a reader that is dereferencing a peeked event. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260817140655.5694-1-kartikey406@gmail.com Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page") Reported-by: syzbot+685955db58555575fdd2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=685955db58555575fdd2 Tested-by: syzbot+685955db58555575fdd2@syzkaller.appspotmail.com Reviewed-by: Bradley Morgan Signed-off-by: Deepanshu Kartikey Signed-off-by: Steven Rostedt commit 649bc7df3e5d7be6f7996a95084037dbf3cad1e5 Author: Hui Su Date: Mon Aug 17 20:06:44 2026 +0800 tracing: Fix crash passing ERR_PTR to kthread_stop() event_test_stuff() calls kthread_run() and unconditionally passes the returned task_struct pointer to kthread_stop(). kthread_run() returns an error pointer such as ERR_PTR(-ENOMEM) when kthread creation fails, for example under memory pressure during the boot-time event self-test. kthread_stop() then dereferences the invalid pointer, crashing the kernel. Check the result of kthread_run() before passing it to kthread_stop(). Use WARN_ON() so that a failure to create the self-test thread does not go unnoticed, matching the ring-buffer self-test fix in commit 91542863abad ("ring-buffer: Fix crash passing ERR_PTR to kthread_stop()"). Cc: stable@vger.kernel.org Fixes: e6187007d6c3 ("tracing/events: add startup tests for events") Link: https://patch.msgid.link/20260817120642.668375-3-sh_def@163.com Signed-off-by: Hui Su Signed-off-by: Steven Rostedt commit a7318172aa332a161fb9618286e64454c827f8fd Author: Hui Su Date: Sun Aug 16 18:04:29 2026 +0800 tracing: Fix use-after-free with same-name named triggers When two hist triggers on different events are registered with the same name=, the second one reuses the first as named_data. Both are added to tr->hist_vars by save_hist_vars() during event_hist_trigger_parse(), because save_hist_vars() is called before event_trigger_register() while the named reuse is only detected later, in hist_register_trigger(). In the named-data branch hist_register_trigger() then frees the second histogram's hist_data via destroy_hist_data(), but never removes its tr->hist_vars list entry, leaving a dangling pointer and leaking the trace_array reference it holds. A later hist trigger that references a variable makes find_var_file() walk tr->hist_vars and dereference the freed hist_data. The bug is reproducible from userspace by writing three hist triggers to tracefs: cd /sys/kernel/tracing echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_switch/trigger echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_process_fork/trigger echo 'hist:keys=common_pid:vals=$x' > events/sched/sched_process_exit/trigger The third write panics the kernel: BUG: KASAN: slab-use-after-free in find_var_file.part.0+0x272/0x290 Read of size 8 at addr ffff888001f8a0e0 by task sh/1 CPU: 1 UID: 0 PID: 1 Comm: sh Tainted: G D N Call Trace: find_var_file.part.0 find_event_var parse_atom parse_expr __create_val_field event_hist_trigger_parse trigger_process_regex event_trigger_write vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe Allocated by task 1: event_hist_trigger_parse Freed by task 1: hist_register_trigger+0x618/0xa30 event_hist_trigger_parse The buggy address belongs to freed 2048-byte region Oops: general protection fault ... RIP: find_var_file.part.0 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Fix by removing the hist_data from tr->hist_vars and releasing the trace_array reference in the named-data branch of hist_register_trigger() before freeing the hist_data. Cc: stable@vger.kernel.org Fixes: 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list") Link: https://patch.msgid.link/20260816100427.33642-3-sh_def@163.com Signed-off-by: Hui Su Signed-off-by: Steven Rostedt commit 7cbfb180945ce529608e4d4e24a6d483699fab1e Author: Giuseppe Piscitelli Date: Thu Aug 20 17:45:03 2026 +0200 net/sched: sch_cake: fix autorate reconfiguration throttling CAKE's autorate-ingress path intends to limit shaper reconfiguration to once per 250 ms, but last_reconfig_time is only checked and never updated. Since the field stays zero, every qualifying capacity-estimate window can call cake_reconfigure(), causing avoidable rate churn and scheduler work under bursty traffic. Store the current timestamp when autorate actually reconfigures the qdisc so the guard enforces the intended interval. Fixes: 7298de9cd725 ("sch_cake: Add ingress mode") Signed-off-by: Giuseppe Piscitelli Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260820154503.892214-1-ooonea@gmail.com Signed-off-by: Jakub Kicinski commit 11efd7963dac9b036a7c9a435ab0e621188910e8 Author: Jian Shen Date: Thu Aug 20 20:43:46 2026 +0800 net: hibmcge: fix page_pool DMA direction mismatch The driver memsets the RX buffer page head to zero before submitting it to hardware, then calls dma_sync_single_for_device() with DMA_TO_DEVICE. This sync direction does not match the pool dma_dir which is DMA_FROM_DEVICE, violating the DMA API contract that the sync direction must match the mapping direction. On swiotlb platforms the mismatch can cause incorrect bounce-buffer behaviour, and CONFIG_DMA_API_DEBUG emits a warning. Switch the page_pool dma_dir to DMA_BIDIRECTIONAL so that the CPU-to-device memset sync becomes legal. Fixes: c30595917585 ("net: hibmcge: add support for pagepool on rx") Signed-off-by: Jian Shen Signed-off-by: Jijie Shao Link: https://patch.msgid.link/20260820124346.4097115-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski commit 137b8ae233cabe7fc77cce86f5ba33bf1b369e26 Author: Eric Dumazet Date: Thu Aug 20 08:06:25 2026 -0400 net_sched: sch_fq: fix pacing delay underflow with pacing offload When pacing offload is enabled (q->offload_horizon > 0), FQ can dequeue packets early (now < f->time_next_packet). In this case, the drift calculation (now - f->time_next_packet) underflows to a large unsigned value. min(len/2, now - f->time_next_packet) then evaluates to len/2, incorrectly halving the pacing delay for the next packet. Fix this by only applying drift compensation if now > f->time_next_packet. This bug was triggered when flow_max_rate was set on the qdisc or for non EDT packets (packets with a zero skb->tstamp). Fixes: f26080d47007 ("net_sched: sch_fq: add the ability to offload pacing") Reported-by: Willem de Bruijn Closes: https://lore.kernel.org/netdev/CANn89iK6O7ujR9zCJzd04MNLQoDi3mA+HWsR-hgQWYzLS3gZfw@mail.gmail.com/ Signed-off-by: Eric Dumazet Signed-off-by: Willem de Bruijn Link: https://patch.msgid.link/20260820120706.1995449-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski commit 039f248a6cc1f4dec895c001de2c600842022e58 Author: Rong Zhang Date: Fri Aug 21 01:41:25 2026 +0800 net: page_pool: Remove zone/policy GFP flags when allocating XArray entries Net drivers request GFP flags according to both the current context and the device constraints, but the XArray entry itself is by no mean used by the device. Passing though device constraints to XArray allocation is a bug and will be warned and fixed up by slab, e.g.: Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0x82820 (GFP_ATOMIC|__GFP_NOWARN|__GFP_NOMEMALLOC). Fix your code! CPU: 2 UID: 0 PID: 1071629 Comm: kworker/u80:1 Not tainted 7.2.0-rc7+ #1 PREEMPT(lazy) Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN27WW 10/20/2025 Workqueue: mt76 mt792x_pm_wake_work [mt792x_lib] Call Trace: dump_stack_lvl+0x6e/0x90 kmalloc_fix_flags+0x4d/0x6a refill_objects+0x10a/0x330 __pcs_replace_empty_main+0x292/0x5c0 kmem_cache_alloc_lru_noprof+0x4c2/0x680 ? __xas_nomem+0x3a/0x120 __xas_nomem+0x3a/0x120 __xa_alloc+0xd4/0x190 page_pool_dma_map+0xef/0x400 __page_pool_alloc_netmems_slow+0xed/0x480 ? lock_release+0x280/0x490 page_pool_alloc_frag_netmem+0xe0/0x3a0 page_pool_alloc_frag+0xe/0x20 mt76_dma_rx_fill_buf+0x1f6/0x580 [mt76] mt76_dma_rx_reset+0x1cf/0x230 [mt76] mt792x_wpdma_reset+0x183/0x1b0 [mt792x_lib] mt792x_wpdma_reinit_cond+0x5e/0xa0 [mt792x_lib] mt792xe_mcu_drv_pmctrl+0x28/0x60 [mt792x_lib] mt792x_mcu_drv_pmctrl+0x3e/0x90 [mt792x_lib] mt792x_pm_wake_work+0x2d/0x1d0 [mt792x_lib] ? process_one_work+0x20e/0x600 process_one_work+0x230/0x600 ? process_one_work+0x256/0x600 worker_thread+0x1ec/0x3c0 ? rescuer_thread+0x610/0x610 kthread+0xf2/0x130 ? kthread_affine_node+0x140/0x140 ret_from_fork+0x2a5/0x380 ? kthread_affine_node+0x140/0x140 ret_from_fork_asm+0x11/0x20 Currently mt76 and stmmac may allocate page pool pages with GFP_DMA32. Fix it by removing zone/policy GFP flags when allocating XArray entries. This is inspired by commit 96d578088085 ("iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()"). Fixes: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool") Signed-off-by: Rong Zhang Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260821-page-pool-xa-drop-dma32-v1-1-6eab295c3478@rong.moe Signed-off-by: Jakub Kicinski commit e16d750a906b05fa5cf475749668a96928aa0cbc Merge: f05516dd7b8656 8d3c1ab82c11d4 Author: Jakub Kicinski Date: Sat Aug 22 13:25:54 2026 -0700 Merge branch 'net-smc-fix-out-of-bounds-and-use-after-free-in-smc-rv2-llc-processing' Yehyeong Lee says: ==================== net/smc: fix out-of-bounds and use-after-free in SMC-Rv2 LLC processing Patch 1 fixes a use-after-free of the LLC queue entry in smc_llc_srv_add_link(), patch 2 bounds the peer's rkey counts, and patch 3 carries the tail of an oversized v2 message in the queue entry so that both readers are bounded by what arrived. All three are tagged for stable: a tree that takes 1 and 2 without 3 still deletes rkeys read from whatever an earlier message left in the shared receive buffer. ==================== Link: https://patch.msgid.link/20260819023306.644849-1-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski commit 8d3c1ab82c11d4fadebf817a825fd221b3e197ea Author: Yehyeong Lee Date: Wed Aug 19 11:33:06 2026 +0900 net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() read the part of a v2 message that does not fit into the 44-byte union smc_llc_msg, and both bound themselves by the size of the buffer it landed in, not by what arrived. On a link with a shared v2 receive buffer a 44-byte DELETE_RKEY_V2 declaring 255 rkeys reaches rkey[9..254] in whatever an earlier message left in lgr->wr_rx_buf_v2, and passes each of them to smc_rtoken_delete(). One of those 255 matched a registered rtoken and deleted it. An ADD_LINK on such a link installs up to 255 rtokens from the same bytes. Copy the tail into the queue entry, so its length is the length of the message that arrived, and declare the rkeys that fit inline as a member of the union instead of reaching them through a cast. The same DELETE_RKEY_V2 now processes the 9 rkeys it carries. The copy is limited to the longest tail the two functions can read, so the peer does not pick the size of the entry. The bound the previous patch placed on links without a shared v2 receive buffer is no longer needed. Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1") Cc: stable@vger.kernel.org Suggested-by: D. Wythe Reviewed-by: Sidraya Jayagond Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260819023306.644849-4-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski commit 2d1e7c5aaa3326e95e2058457f172ca99a9a4577 Author: Yehyeong Lee Date: Wed Aug 19 11:33:05 2026 +0900 net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages On a link whose device has max_recv_sge == 1 there is no shared v2 receive buffer, and smc_llc_save_add_link_rkeys() takes the v2 extension from 44 bytes past the start of the queue entry's inline message: ext = (struct smc_llc_msg_add_link_v2_ext *)(llc_msg + SMC_WR_TX_SIZE); The entry is a 72-byte allocation and the extension starts at offset 68, so ext->num_rkeys at offset 94 is already past it. This happens on every SMC-Rv2 link addition, whatever the peer sends: [ 2.490065] BUG: KASAN: slab-out-of-bounds in smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490431] Read of size 2 at addr ffff8880056406de by task smctest/106 [ 2.490709] [ 2.490792] CPU: 0 UID: 0 PID: 106 Comm: smctest Not tainted 7.2.0-rc5-p1-g77a5d9d9c99f #32 PREEMPT(lazy) [ 2.490795] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.490798] Call Trace: [ 2.490803] [ 2.490805] dump_stack_lvl+0x53/0x70 [ 2.490810] print_report+0xd0/0x630 [ 2.490828] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.490832] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490834] kasan_report+0xce/0x100 [ 2.490836] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490837] smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490839] ? smcr_buf_map_lgr+0x1bf/0x2b0 [ 2.490844] smc_llc_cli_add_link+0xca7/0x1e80 [ 2.490848] ? smc_llc_wait+0x355/0x810 [ 2.490850] ? __pfx_smc_llc_wait+0x10/0x10 [ 2.490851] ? __pfx_smc_llc_cli_add_link+0x10/0x10 [ 2.490853] ? __pfx_autoremove_wake_function+0x10/0x10 [ 2.490863] __smc_connect+0x3f5c/0x4980 [ 2.490873] ? __pfx_kernel_connect+0x10/0x10 [ 2.490888] ? __pfx___smc_connect+0x10/0x10 [ 2.490891] ? release_sock+0x148/0x1d0 [ 2.490894] smc_connect+0x42c/0x580 [ 2.490896] __sys_connect+0xfc/0x130 [ 2.490898] ? __pfx___sys_connect+0x10/0x10 [ 2.490900] ? handle_mm_fault+0x1a1/0x430 [ 2.490908] __x64_sys_connect+0x6d/0xb0 [ 2.490909] ? fpregs_assert_state_consistent+0x56/0xe0 [ 2.490917] do_syscall_64+0xf9/0x540 [ 2.490921] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2.490924] RIP: 0033:0x421bb4 [ 2.490927] Code: ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d ad 34 09 00 00 74 13 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 10 89 55 [ 2.490929] RSP: 002b:00007ffd473b01a8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a [ 2.490935] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000421bb4 [ 2.490936] RDX: 0000000000000010 RSI: 00007ffd473b01d0 RDI: 0000000000000003 [ 2.490937] RBP: 0000000000003930 R08: 0000000000000004 R09: 0000000000000000 [ 2.490938] R10: 00007ffd473b0f98 R11: 0000000000000202 R12: 0000000000000006 [ 2.490939] R13: 00007ffd473b0f87 R14: 0000000000000003 R15: 00007ffd473b0f90 [ 2.490940] [ 2.490941] [ 2.499545] Allocated by task 44: [ 2.499693] kasan_save_stack+0x33/0x60 [ 2.499860] kasan_save_track+0x14/0x30 [ 2.500026] __kasan_kmalloc+0x8f/0xa0 [ 2.500190] __kmalloc_cache_noprof+0x158/0x370 [ 2.500393] smc_llc_enqueue+0x72/0x560 [ 2.500559] smc_wr_rx_tasklet_fn+0x474/0xa80 [ 2.500747] tasklet_action_common+0x20f/0x8a0 [ 2.500945] handle_softirqs+0x18e/0x590 [ 2.501115] do_softirq+0x3b/0x60 [ 2.501266] __local_bh_enable_ip+0x61/0x70 [ 2.501446] __alloc_skb+0x732/0x890 [ 2.501604] rxe_init_packet+0x16b/0x4f0 [ 2.501783] prepare_ack_packet+0xb8/0x830 [ 2.501962] rxe_receiver+0x495/0x96e0 [ 2.502125] do_work+0x144/0x470 [ 2.502269] process_one_work+0x633/0x1030 [ 2.502450] worker_thread+0x45b/0xd10 [ 2.502617] kthread+0x2c6/0x3b0 [ 2.502762] ret_from_fork+0x36e/0x5a0 [ 2.502925] ret_from_fork_asm+0x1a/0x30 [ 2.503103] [ 2.503177] The buggy address belongs to the object at ffff888005640680 [ 2.503177] which belongs to the cache kmalloc-96 of size 96 [ 2.503692] The buggy address is located 22 bytes to the right of [ 2.503692] allocated 72-byte region [ffff888005640680, ffff8880056406c8) [ 2.504227] [ 2.504300] The buggy address belongs to the physical page: [ 2.504535] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5640 [ 2.504865] flags: 0x100000000000000(node=0|zone=1) [ 2.505076] page_type: f5(slab) [ 2.505221] raw: 0100000000000000 ffff888001041280 dead000000000122 0000000000000000 [ 2.505544] raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000 [ 2.505867] page dumped because: kasan: bad access detected [ 2.506102] [ 2.506176] Memory state around the buggy address: [ 2.506380] ffff888005640580: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.506683] ffff888005640600: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.506987] >ffff888005640680: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.507291] ^ [ 2.507548] ffff888005640700: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.507850] ffff888005640780: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc Whatever that read finds then bounds the ext->rt[] loop, so a peer that declares 255 rkeys reads much further. smc_llc_rmt_delete_rkey() has the same shape for llcv2->rkey[]. Bound both loops by the buffer they read from, and skip the extension altogether when there is no shared v2 receive buffer. The extension does arrive on the link, but smc_llc_enqueue() copies only sizeof(union smc_llc_msg) into the queue entry, so what that code read past the 44 inline bytes was heap and not peer data. Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1") Cc: stable@vger.kernel.org Reviewed-by: Sidraya Jayagond Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260819023306.644849-3-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski commit a42a459ef0e54cb0c4b3e43e21cb0e658e664f64 Author: Yehyeong Lee Date: Wed Aug 19 11:33:04 2026 +0900 net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link() smc_llc_srv_add_link() keeps add_llc pointing into the queue entry: add_llc = &qentry->msg.add_link; smc_llc.c:1482 ... smc_llc_save_add_link_info(link_new, add_llc); smc_llc.c:1494 smc_llc_flow_qentry_del(&lgr->llc_flow_lcl); smc_llc.c:1495 ... u8 *llc_msg = smc_link_shared_v2_rxbuf(link) ? (u8 *)lgr->wr_rx_buf_v2 : (u8 *)add_llc; smc_llc.c:1504 smc_llc_save_add_link_rkeys(link, link_new, llc_msg); smc_llc.c:1506 smc_llc_flow_qentry_del() kfree()s the entry, so on a link without a shared v2 receive buffer the pointer handed to smc_llc_save_add_link_rkeys() is already freed. Before the Fixes: commit that branch always used lgr->wr_rx_buf_v2 and add_llc was not used after the free. Reproduced on an unpatched tree over rxe, with KASAN, kasan_multi_shot and a link forced to max_recv_sge == 1: the entry is freed and read by the same call, and the freeing frame is smc_llc_srv_add_link() itself. [ 2.523161] BUG: KASAN: slab-use-after-free in smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523499] Read of size 2 at addr ffff8880052194de by task kworker/0:1/11 [ 2.523789] [ 2.523862] CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0-rc5-p0-g2c9dd296545d #35 PREEMPT(lazy) [ 2.523865] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.523866] Workqueue: smc_hs_wq smc_listen_work [ 2.523869] Call Trace: [ 2.523870] [ 2.523871] dump_stack_lvl+0x53/0x70 [ 2.523872] print_report+0xd0/0x630 [ 2.523874] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.523876] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523878] kasan_report+0xce/0x100 [ 2.523879] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523881] smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523883] ? smcr_buf_reg_lgr+0x2a4/0x660 [ 2.523885] smc_llc_srv_add_link+0xaa2/0x1e50 [ 2.523888] ? _printk+0xba/0xf0 [ 2.523897] ? __pfx_smc_llc_srv_add_link+0x10/0x10 [ 2.523899] ? down_write+0xb0/0x130 [ 2.523903] ? __pfx_down_write+0x10/0x10 [ 2.523905] smc_listen_work+0x489e/0x4d00 [ 2.523907] ? kmem_cache_free+0x1c6/0x3a0 [ 2.523911] ? __pfx_smc_listen_work+0x10/0x10 [ 2.523913] ? release_sock+0x148/0x1d0 [ 2.523915] ? smc_tcp_listen_work+0xb4f/0xfc0 [ 2.523917] ? _raw_spin_lock_irq+0x80/0xe0 [ 2.523918] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 2.523920] process_one_work+0x633/0x1030 [ 2.523922] ? assign_work+0x11d/0x370 [ 2.523924] worker_thread+0x45b/0xd10 [ 2.523926] ? __pfx_worker_thread+0x10/0x10 [ 2.523928] ? __pfx_worker_thread+0x10/0x10 [ 2.523929] kthread+0x2c6/0x3b0 [ 2.523931] ? recalc_sigpending+0x15c/0x1e0 [ 2.523934] ? __pfx_kthread+0x10/0x10 [ 2.523935] ret_from_fork+0x36e/0x5a0 [ 2.523937] ? __pfx_ret_from_fork+0x10/0x10 [ 2.523938] ? __switch_to+0x572/0xdd0 [ 2.523943] ? __pfx_kthread+0x10/0x10 [ 2.523944] ret_from_fork_asm+0x1a/0x30 [ 2.523947] [ 2.523948] [ 2.531253] Allocated by task 48: [ 2.531399] kasan_save_stack+0x33/0x60 [ 2.531570] kasan_save_track+0x14/0x30 [ 2.531737] __kasan_kmalloc+0x8f/0xa0 [ 2.531905] __kmalloc_cache_noprof+0x158/0x370 [ 2.532100] smc_llc_enqueue+0x72/0x560 [ 2.532268] smc_wr_rx_tasklet_fn+0x474/0xa80 [ 2.532491] tasklet_action_common+0x20f/0x8a0 [ 2.532714] handle_softirqs+0x18e/0x590 [ 2.532886] do_softirq+0x3b/0x60 [ 2.533036] __local_bh_enable_ip+0x61/0x70 [ 2.533221] __alloc_skb+0x732/0x890 [ 2.533384] rxe_init_packet+0x16b/0x4f0 [ 2.533567] prepare_ack_packet+0xb8/0x830 [ 2.533760] rxe_receiver+0x495/0x96e0 [ 2.533933] do_work+0x144/0x470 [ 2.534078] process_one_work+0x633/0x1030 [ 2.534257] worker_thread+0x45b/0xd10 [ 2.534424] kthread+0x2c6/0x3b0 [ 2.534569] ret_from_fork+0x36e/0x5a0 [ 2.534737] ret_from_fork_asm+0x1a/0x30 [ 2.534907] [ 2.534980] Freed by task 11: [ 2.535112] kasan_save_stack+0x33/0x60 [ 2.535279] kasan_save_track+0x14/0x30 [ 2.535444] kasan_save_free_info+0x3b/0x60 [ 2.535625] __kasan_slab_free+0x43/0x70 [ 2.535798] kfree+0x121/0x380 [ 2.535935] smc_llc_srv_add_link+0x9a8/0x1e50 [ 2.536128] smc_listen_work+0x489e/0x4d00 [ 2.536305] process_one_work+0x633/0x1030 [ 2.536482] worker_thread+0x45b/0xd10 [ 2.536652] kthread+0x2c6/0x3b0 [ 2.536794] ret_from_fork+0x36e/0x5a0 [ 2.536958] ret_from_fork_asm+0x1a/0x30 [ 2.537133] [ 2.537205] The buggy address belongs to the object at ffff888005219480 [ 2.537205] which belongs to the cache kmalloc-96 of size 96 [ 2.537719] The buggy address is located 94 bytes inside of [ 2.537719] freed 96-byte region [ffff888005219480, ffff8880052194e0) [ 2.538216] [ 2.538289] The buggy address belongs to the physical page: [ 2.538524] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5219 [ 2.538857] flags: 0x100000000000000(node=0|zone=1) [ 2.539066] page_type: f5(slab) [ 2.539210] raw: 0100000000000000 ffff888001041280 dead000000000122 0000000000000000 [ 2.539534] raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000 [ 2.539863] page dumped because: kasan: bad access detected [ 2.540098] [ 2.540170] Memory state around the buggy address: [ 2.540379] ffff888005219380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2.540684] ffff888005219400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2.540988] >ffff888005219480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 2.541291] ^ [ 2.541548] ffff888005219500: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.541857] ffff888005219580: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc The offset is past the 72-byte queue entry because the out-of-bounds read fixed by the next patch is on the same line; what this patch removes is the free at smc_llc_srv_add_link+0x9a8 happening before the read at +0xaa2. Detach the entry instead of freeing it there, and free it at the single exit label. The reject path has to detach as well, otherwise it would be freed twice. This changes only the lifetime of the entry. The same read still runs past its end until the next two patches bound it, so a backport wants all three. Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1") Cc: stable@vger.kernel.org Reviewed-by: Sidraya Jayagond Signed-off-by: Yehyeong Lee Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260819023306.644849-2-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski commit f05516dd7b865666ea7d67e90d0edb588ae9ad18 Author: Jiawen Wu Date: Tue Aug 18 15:47:21 2026 +0800 net: libwx: fix concurrent bitmap overwrite in PTP setup In wx_ptp_set_timestamp_mode(), the driver copies the global `wx->flags` bitmap to a local variable, modifies the PTP-related bits, and then writes the entire bitmap back using memcpy(). This Read-Copy-Update pattern is unsafe and introduces a critical race condition. Other asynchronous contexts (such as Tx timeout routines or GPIO IRQ handlers) update individual bits in `wx->flags` concurrently using atomic bitops like set_bit() or clear_bit(). The memcpy() write-back can silently overwrite and drop these concurrent changes, potentially causing the driver to miss critical module reset or PCIe recovery requests. Fix this by removing the local bitmap copy. Instead, evaluate the intended PTP flag states locally and apply them directly to `wx->flags` using atomic set_bit() and clear_bit() operations only after the hardware is successfully configured. Fixes: 06e75161b9d4 ("net: wangxun: Add support for PTP clock") Signed-off-by: Jiawen Wu Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/6C7EC12D69217315+20260818074721.45536-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski commit 06aa3d26327f24edd039ff249672fdf6f2ba5695 Author: Vaibhav Nagare Date: Tue Aug 18 13:03:09 2026 +0530 qede: Fix NULL pointer dereference in TPA fragment processing Under memory pressure, the qede driver encounters NULL pointer dereferences when processing TPA continuation fragments. Commit 8a8633978b84 ("qede: Add build_skb() support.") accidentally dropped the assignment of tpa_info->buffer.data in qede_tpa_start(). When memory pressure causes an SKB allocation failure in qede_tpa_start(), the driver sets tpa_start_fail = true and attempts to recycle the physical page later in qede_tpa_end() via qede_reuse_page(). However, because buffer.data was left uninitialized (NULL), qede_reuse_page() pushes a "ghost" BD (valid DMA mapping but NULL data pointer) back into the active Rx ring. The next time the hardware uses this ring slot, it passes a NULL page to qede_fill_frag_skb(), causing a kernel panic. Example crash from production system: BUG: unable to handle kernel NULL pointer dereference at 0x8 RIP: qede_fill_frag_skb+0x96/0x430 [qede] Call Trace: qede_rx_int+0xb06/0x1de0 qede_poll+0x2f4/0x6c0 __napi_poll+0x2d/0x130 Fix the root cause by restoring the tpa_info->buffer.data assignment in qede_tpa_start(), ensuring valid pages are correctly tracked and recycled. Additionally, update the stale comment for struct qede_agg_info::buffer to reflect its current usage. Fixes: 8a8633978b84 ("qede: Add build_skb() support.") Cc: stable@vger.kernel.org Signed-off-by: Vaibhav Nagare Link: https://patch.msgid.link/20260818073309.2266072-1-vnagare@redhat.com Signed-off-by: Jakub Kicinski commit 7bf29145d7a9564162c6b18f8d23760e141e2d15 Author: Jiawen Wu Date: Tue Aug 18 10:30:26 2026 +0800 net: txgbe: fix MISC interrupt unmasking in non-MSI-X mode and device shutdown In txgbe_misc_irq_thread_fn(), the driver unmasks the miscellaneous interrupt at the end of the handler using TXGBE_INTR_MISC(wx) (which resolves to BIT(wx->num_q_vectors)). While this is correct for MSI-X mode, it is incorrect for legacy INTx or single MSI modes. Due to hardware behavior, the WX_PX_MISC_IVAR register is completely ignored by the hardware when MSI-X is disabled. In non-MSI-X mode, the hardware forcibly merges all interrupt causes (both Queue and MISC) into a single bit: BIT(0) of the interrupt register. Unconditionally unmasking TXGBE_INTR_MISC(wx) (e.g., BIT(1)) in non-MSI-X mode means the actual MISC interrupt bit (BIT(0)) is not unmasked promptly at the end of the MISC thread. Instead, it remains masked until NAPI completes its polling and unmasks the shared BIT(0). This delays the assertion of subsequent MISC interrupts, preventing timely handling of events like link state changes. Fix this by explicitly checking `pdev->msix_enabled` and falling back to BIT(0) as the interrupt mask for the MISC cause when MSI-X is disabled. Additionally, unconditionally unmasking the interrupt at the end of the thread introduces a race condition during device teardown. Guarding the wx_intr_enable() call with a check for the WX_STATE_DOWN bit, to prevent re-arming the interrupt during device shutdown. Fixes: e37546ad1f9b ("net: wangxun: revert the adjustment of the IRQ vector sequence") Signed-off-by: Jiawen Wu Reviewed-by: Simon Horman Link: https://patch.msgid.link/56A53978B83EEDE9+20260818023026.6631-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski commit dac0c3fa97cb2d554ed17688722020ac68632cbe Merge: 498386b6d40273 b62793a7baeea9 Author: Jakub Kicinski Date: Sat Aug 22 13:21:29 2026 -0700 Merge branch 'net-sparx5-misc-fixes-for-sparx5-and-lan969x' Daniel Machon says: ==================== net: sparx5: misc fixes for sparx5 and lan969x This series fixes various issues in the sparx5 driver, which also serves lan969x. Details are in the individual commit descriptions. ==================== Link: https://patch.msgid.link/20260817-misc-fixes-sparx5-lan969x-v3-0-c7c7fef723a8@microchip.com Signed-off-by: Jakub Kicinski commit b62793a7baeea9cf20209c9fd2e333311aaf3b8d Author: Daniel Machon Date: Mon Aug 17 17:41:59 2026 +0200 net: sparx5: fix sleep in atomic context in MAC table access sparx5_set_rx_mode() runs with netif_addr_lock_bh held and iterates dev->mc via __dev_mc_sync(), which per address calls sparx5_mc_sync() / sparx5_mc_unsync() -> sparx5_mact_learn() / sparx5_mact_forget(). These take sparx5->lock, a mutex, and then poll the MAC access command register with readx_poll_timeout(). A mutex may block, which is not allowed from atomic context. Convert the driver to the new .ndo_set_rx_mode_async callback introduced in commit 3554b4345d85 ("net: introduce ndo_set_rx_mode_async and netdev_rx_mode_work"). The async callback is invoked from process context, so the mutex and sleeping completion poll can remain. Observed with CONFIG_PROVE_LOCKING, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_ATOMIC_SLEEP enabled: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 217, name: ip preempt_count: 201, expected: 0 Call trace: __might_resched+0x144/0x248 __might_sleep+0x48/0x7c __mutex_lock+0x74/0x850 mutex_lock_nested+0x24/0x30 sparx5_mact_learn+0x78/0x100 sparx5_mc_sync+0x40/0x54 __hw_addr_sync_dev+0xc4/0x170 sparx5_set_rx_mode+0x4c/0x58 __dev_set_rx_mode+0x64/0xa4 __dev_open+0x1ec/0x26c Fixes: d6fce5141929 ("net: sparx5: add switching support") Signed-off-by: Daniel Machon Link: https://patch.msgid.link/20260817-misc-fixes-sparx5-lan969x-v3-2-c7c7fef723a8@microchip.com Signed-off-by: Jakub Kicinski commit b7adcc56fd3db4f5ddaf8c01069d26136d61e5c8 Author: Daniel Machon Date: Mon Aug 17 17:41:58 2026 +0200 net: microchip: vcap: use port number instead of netdev name for debugfs sparx5_vcap_init() runs before sparx5_register_netdevs() in probe, and its debugfs setup calls vcap_port_debugfs() for every port using netdev_name(ndev) as the debugfs file name. At that point the netdevs have only been allocated, not registered, so dev->name still holds the "eth%d" template and netdev_name() returns "(unnamed net_device)". Every port tries to create the same file under vcaps/, producing a flood of warnings at boot: debugfs: '(unnamed net_device)' already exists in 'vcaps' debugfs: '(unnamed net_device)' already exists in 'vcaps' ... Add vcap_port_debugfs_portno(), a variant of vcap_port_debugfs() that takes the port's stable hardware port number and uses "p%u" as the debugfs file name instead of netdev_name(ndev). This makes the file name independent of registration order; the file still stores and later dereferences the netdev itself, same as before. sparx5 already reports the same "p%d" string via ndo_get_phys_port_name(), so the debugfs name now matches that. Only sparx5 (and lan969x, which shares this code) is switched to the new function. lan966x keeps calling vcap_port_debugfs() unchanged, so this fix does not rename any of its existing debugfs files. Fixes: b8909aad5b8d ("net: sparx5: move netdev and notifier block registration to probe") Signed-off-by: Daniel Machon Link: https://patch.msgid.link/20260817-misc-fixes-sparx5-lan969x-v3-1-c7c7fef723a8@microchip.com Signed-off-by: Jakub Kicinski commit 498386b6d402737db1e2eeed4c385acbf0ef9e34 Author: Qing Ming Date: Tue Aug 18 23:00:00 2026 +0800 gtp: serialize PDP context updates PDP contexts can be deleted through GTP_CMD_DELPDP or while the GTP network device is being unregistered. The latter is serialized by RTNL, but the generic-netlink delete path only holds RCU. Running both paths concurrently can therefore make both paths delete the same PDP context. The issue was found through static analysis and reproduced on a KASAN-enabled kernel by a simple two-thread program racing GTP_CMD_DELPDP against RTM_DELLINK: Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] RIP: gtp_genl_del_pdp+0x1c1/0x420 [gtp] RBP: dead000000000122 The second deletion dereferenced the poisoned hlist pprev pointer. Serialize gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() with a shared mutex. Keep the mutex held until the final use of a PDP context in the NEWPDP path, and keep the RCU read-side section around the complete PDP context use in the DELPDP path. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Cc: stable@vger.kernel.org Signed-off-by: Qing Ming Link: https://patch.msgid.link/20260818150000.7670-1-a0yami@mailbox.org Signed-off-by: Jakub Kicinski commit 71283aaa6c65b3cec84caf1dc78560985737641f Author: Weiming Shi Date: Tue Aug 18 23:45:15 2026 +0800 xdp: fix zero-copy frame layout xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page. Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result. BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ... Fixes: b0d1beeff2a9 ("xdp: implement convert_to_xdp_frame for MEM_TYPE_ZERO_COPY") Cc: stable@vger.kernel.org Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260818154516.793517-1-bestswngs@gmail.com Signed-off-by: Jakub Kicinski commit 7c3a1a34810d9570d65701200f23d6a9e7e6c874 Merge: 870a9e42ecc6fe 31ded341c375bb Author: Jakub Kicinski Date: Sat Aug 22 13:06:10 2026 -0700 Merge branch 'net-ntb_netdev-fix-rx-statistics-accounting' Koichiro Den says: ==================== net: ntb_netdev: Fix RX statistics accounting This series addresses Jakub's comment on ntb_netdev RX statistics accounting: https://lore.kernel.org/r/20260818092938.4121c220@kernel.org/ It fixes the double counting and also the related packet/byte accounting on RX refill failure. ==================== Link: https://patch.msgid.link/20260819172539.1450821-1-den@valinux.co.jp Signed-off-by: Jakub Kicinski commit 31ded341c375bb2faac1d77ab0012a732ba3e2a6 Author: Koichiro Den Date: Thu Aug 20 02:25:39 2026 +0900 net: ntb_netdev: Count packets dropped on RX refill failure When replacement skb allocation fails, ntb_netdev drops a packet that was received successfully and requeues the original buffer. The drop is counted, but rx_packets and rx_bytes are not. Count every good packet before allocating its replacement. Fixes: d2121faf133a ("NTB: ntb_netdev: Preserve RX queue depth on allocation failure") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260819172539.1450821-3-den@valinux.co.jp Signed-off-by: Jakub Kicinski commit 82e15be2d8b9efa6fb1750528d9b6f40e6a8eea7 Author: Koichiro Den Date: Thu Aug 20 02:25:38 2026 +0900 net: ntb_netdev: Avoid double-accounting netif_rx() drops netif_rx() already accounts packets it drops in the core rx_dropped counter. ntb_netdev counts them again as both errors and drops. Leave netif_rx() drops to the core. Count the packet and bytes unconditionally since it was received successfully by the driver. Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device") Cc: stable@vger.kernel.org Suggested-by: Jakub Kicinski Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260819172539.1450821-2-den@valinux.co.jp Signed-off-by: Jakub Kicinski commit 870a9e42ecc6fe1b8c25d87af043cb0d9c178fe1 Author: Yong Wang Date: Wed Aug 19 23:22:04 2026 +0800 tcp: clamp route advmss to TCP_MIN_MSS tcp_select_initial_window() assumes that callers never pass an MSS smaller than 1, but route-derived advmss values can violate that assumption. A too-small explicit RTAX_ADVMSS is one way to get there, but it is not the only one. The same divide-by-zero can also be reached through the "default advmss" path when RTAX_ADVMSS is left at 0 and the effective advmss is later driven down by route MTU and min_adv_mss. Introduce a tcp_dst_advmss() helper that clamps route advmss to TCP_MIN_MSS before TCP consumes it, and use it in the TCP paths that derive advmss from dst metrics. This keeps the effective MSS from dropping to zero before tcp_select_initial_window() rounds the receive window. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Yong Wang Signed-off-by: Ren Wei Link: https://patch.msgid.link/251eaf8277fa7c66364c9815c5da01662d269181.1787074852.git.edragain@163.com Signed-off-by: Jakub Kicinski commit 6776efe4a52f289a3fc18f8adf19b035a7d8e1bb Author: Anton Danilov Date: Wed Aug 19 13:43:39 2026 +0300 ipip: fix skb leak in collect_md mode when metadata_dst allocation fails In collect_md mode ipip_tunnel_rcv() returns 0 without freeing the skb when ip_tun_rx_dst() fails to allocate the metadata_dst. ipip_rcv() and mplsip_rcv() are registered as xfrm_tunnel handlers, so tunnel4_rcv() and tunnelmpls4_rcv() read the zero return as "the packet has been consumed" and do not free it either. The skb is leaked. The other tunnel drivers all dispose of the packet at this point: ip6_tunnel.c jumps to its drop label, ip_gre.c and ip6_gre.c return PACKET_REJECT, which makes gre_rcv() free the skb. Only ipip returns 0. Jump to the existing drop label instead. It frees the skb and still returns 0, so the packet keeps being reported as consumed, which is what we want here: the outer header has already been pulled, and neither the remaining handlers nor an ICMP unreachable have any use for it. Triggering this needs an ipip or mplsip tunnel in collect_md mode and an atomic allocation failure, which is why it has gone unnoticed. Fixes: cfc7381b3002 ("ip_tunnel: add collect_md mode to IPIP tunnel") Cc: stable@vger.kernel.org Signed-off-by: Anton Danilov Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260819104338.432631-2-littlesmilingcloud@gmail.com Signed-off-by: Jakub Kicinski commit 1beb81947eb486716af80db7a584f9e9fef7e003 Author: Jamal Hadi Salim Date: Wed Aug 19 10:37:33 2026 -0400 net/sched: account classifier filter allocations to memcg 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 commit e755276c9f3b8fc589c50efb9ca33d21918e19be Merge: 777dbc9914b2f0 8d128c932bced7 Author: Jakub Kicinski Date: Sat Aug 22 12:42:57 2026 -0700 Merge tag 'batadv-net-pullrequest-20260821' of https://git.open-mesh.org/batadv Simon Wunderlich says: ==================== Here are a few batman-adv bugfixes: - fix stale receive device on merged fragments, by Zhiling Zou the others are written by Sven Eckelmann: - bla: fix potential CRC corruption issues (2 patches) - dat: avoid unaligned fault in IP extraction - dat: atomically update mac addresses - mcast: fix TX priority extraction for BATADV_FORW_MCAST - mcast: fix skb sharing and linearization (2 patches) - bla: fix freeing of claims on meshif deletion * tag 'batadv-net-pullrequest-20260821' of https://git.open-mesh.org/batadv: batman-adv: bla: fix freeing of claims on meshif deletion batman-adv: mcast: linearize skbuff for packet generation batman-adv: mcast: ensure unshared skb for multicast packets batman-adv: fix TX priority extraction for BATADV_FORW_MCAST batman-adv: dat: atomically update mac addresses batman-adv: dat: avoid unaligned fault in IP extraction batman-adv: bla: prevent CRC corruptions after claim flush batman-adv: bla: avoid CRC corruption due to parallel claim add batman-adv: fix stale receive device on merged fragments ==================== Link: https://patch.msgid.link/20260821094813.201800-1-sw@simonwunderlich.de Signed-off-by: Jakub Kicinski commit 777dbc9914b2f003f1d44af80c7a4a395c5961b2 Author: Wei Fang Date: Fri Aug 21 11:24:49 2026 +0800 ptp: netc: fix period truncation and potential divide-by-zero in PEROUT The max_period bound in net_timer_enable_perout() was computed as: max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period; which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002 for the default 333333333 Hz clock). A period_ns that passes this check but exceeds U32_MAX is then silently truncated when stored into the u32 struct netc_pp::period field. A truncated value of zero can reach netc_timer_set_perout_alarm(), where the local u32 period variable would also be 0, causing a divide-by-zero in roundup_u64(delta, period) whenever the stime < min_time branch is taken (which always happens for a start time of {0, 0}). Additionally, netc_timer_enable_periodic_pulse() and netc_timer_enable_fiper() both compute: fiper = pp->period - integral_period; A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD, mis-programming the FIPER hardware register. Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER (0xFFFFFFFF). This ensures that any period_ns passing the range check fits in a u32 without truncation, so the stored value is always valid and non-zero. The accepted range is reduced by integral_period ns (typically only a few nanoseconds), which is negligible in practice. Fixes: 671e266835b8 ("ptp: netc: add periodic pulse output support") Signed-off-by: Wei Fang Reviewed-by: Abel Vesa Link: https://patch.msgid.link/20260821032449.1235065-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski commit a70859cf31214e546cb73da7142f190138dae9ab Author: Thomas Walsh Date: Thu Aug 20 18:05:44 2026 -0400 bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check In bnxt_request_irq(), pcie_enable_tph() is called unconditionally to enable PCIe TPH when setting up interrupts. If the NIC hardware or firmware capabilities do not support queue ops, attempting to enable TPH during bnxt_request_irq() is unnecessary. As a result a flood of "RX queue restart failed: err=-95" messages is seen upon boot. Older NICs (pre-Thor / BCM57414) do not support TPH or queue management. TPH requires queue management to restart the queue. NICs that support queue management (with updated FW) all support TPH. Gate the call to pcie_enable_tph() and setting of bp->tph_mode behind BNXT_SUPPORTS_QUEUE_API(bp) to ensure TPH is only initialized on devices capable of supporting queue ops. This prevents a guaranteed -EOPNOTSUPP error from occurring due to NULL operations. Fixes: c214410c47d6 ("bnxt_en: Add TPH support in BNXT driver") Suggested-by: Michal Schmidt Signed-off-by: Thomas Walsh Reviewed-by: Michael Chan Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/20260820220544.1240879-1-thwalsh@redhat.com Signed-off-by: Jakub Kicinski commit 622d698df4239fef3e0eb51fe59f4198f957f28a Author: Guenter Roeck Date: Thu Aug 20 21:45:12 2026 -0700 bnxt_en: Fix call to hardware monitoring event handler The first parameter of hwmon_notify_event() is supposed to be the hardware monitoring device. The bnxt driver calls it with the platform device as first parameter instead. This API break results in undefined behavior and may result in a crash. Pass the hardware monitoring device as parameter instead to fix the problem. Fixes: a19b4801457b0 ("bnxt_en: Event handler for Thermal event") Signed-off-by: Guenter Roeck Reviewed-by: Kalesh AP Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260821044512.663941-1-linux@roeck-us.net Signed-off-by: Jakub Kicinski commit cca061dccf563907061766191b2ce3f66b7c285a Author: Tejun Heo Date: Fri Aug 21 09:05:52 2026 -1000 sched_ext: Fix spurious aborts in scx_bpf_dsq_move() on ownership change races scx_dsq_move() verifies that the task belongs to the calling scheduler before taking any locks and aborts the scheduler on mismatch. The task can lose the sched association at any point: It can run and fully exit, which clears the association, or get rehomed to a different sub-sched. Both are benign races, but the early ownership check escalates them into scheduler aborts. Move the ownership check below the cursor-lost check. Every ownership change dequeues the task first, so a task that is still on the iterated DSQ under the lock while owned elsewhere indicates a genuine violation and should abort. Also fix two stale comments still referencing sched_ext_free(), which has been renamed to sched_ext_dead(). Fixes: bb4d9fd55158 ("sched_ext: scx_dsq_move() should validate the task belongs to the right scheduler") Signed-off-by: Tejun Heo commit 66fb95a521110da673090294561844c9f76ebe64 Merge: 728785f8fb07ae 9b0ee13b80798f Author: Linus Torvalds Date: Sat Aug 22 09:11:40 2026 -0700 Merge tag 'caps-pr-20260820' of git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux Pull capabilities update from Serge Hallyn: "Just one trivial patch which corrects two comments to avoid kernel-doc warnings" * tag 'caps-pr-20260820' of git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux: capability: remove non-kernel-doc comments commit 728785f8fb07ae9c295b1be6d7d672b9ebfc3c05 Merge: 473f6c8f437b04 490529f668016c Author: Linus Torvalds Date: Sat Aug 22 08:57:28 2026 -0700 Merge tag 'exfat-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat Pull exfat updates from Namjae Jeon: "A set of exfat fixes covering shared writable mappings, entry error handling, allocation cleanup, FITRIM bounds, and locking: - Fix valid_size extension over shared writable mappings by lazily zeroing page-cache gaps and ensuring racing stores cannot be overwritten or extend beyond valid_size - Clean up partially written directory entries on add-entry failure and safely free new directory clusters - Free a newly allocated directory cluster when zeroing it fails - Write the destination entry before removing the source entry during rename, preserving the source if the destination write fails - Keep FITRIM within the requested range, even when the free-space search wraps around the allocation bitmap - Fix truncated FS_IOC_GETFSLABEL results by passing the destination buffer size in bytes to the UTF-16-to-NLS conversion - Fix overflow in the cluster-to-dentry calculation, which could cause readdir to stop early on large volumes - Replace the per-inode truncate_lock with inode_lock, using shared locking in bmap to serialize against concurrent truncation - Update the exfat mailing list address in MAINTAINERS" * tag 'exfat-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat: exfat: replace truncate_lock with inode_lock exfat: keep FITRIM within the requested range exfat: fix truncated volume labels returned by FS_IOC_GETFSLABEL exfat: fix overflow in cluster-to-dentry conversion exfat: clean up new entry on add entry failure exfat: free new directory cluster if zeroing fails exfat: write moved entry before removing source MAINTAINERS: update mailing list address for exfat exfat: fix valid_size extension over a shared writable mapping commit 473f6c8f437b049f8ec015d57cd59bb983b1d85c Merge: 47f05f71ad988c 9453bc6a69ef43 Author: Linus Torvalds Date: Sat Aug 22 08:47:50 2026 -0700 Merge tag 'perf-tools-for-v7.3-2026-08-21' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools Pull perf tools updates from Namhyung Kim: "perf c2c: - Add 'function view' in perf c2c report TUI (switched by pressing 'TAB' in the cacheline view) to organize samples around functions rather than cachelines in 3-level hierarchy: Level 1: Read-side function (sorted by estimated Cycles %) Level 2: Contending writer functions (sorted by Store count) Level 3: Shared cacheline addresses Users can navigate the entries and fold/unfold using 'e' key. An example output would look like below: Shared Data Functions Table (19 entries, sorted on Cycles %) Cycles Store % count Function / Contending function / Cacheline ---------------------------------------------------------------------- + 35.67% 876 + [k] cpupri_set + 24.31% 424 + [k] pull_rt_task - 16.53% 555 - [k] dequeue_pushable_task 145 - [k] pull_rt_task 145 0xff2d0082809da080 139 - [k] enqueue_pushable_task 70 0xff2d00a2071f9640 69 0xff2d0082809da000 python module support: - Extend "perf" python module so that it can be fully functional. The goal is to run scripts directly, not by 'perf script' command. This would give better performance as well as more control to build standalone programs with UI. - Add LiveSession helper (perf_live.py) to enable live event collection directly from Python using perf.evlist and perf.parse_events. perf stat: - Add --hide-zero-events option to suppress zero-count events - Reject conflicting --field-separator and --json-output options - Fix duplicate event output with --for-each-cgroup perf sched latency: - Add -H/--histogram and --hist-mode (log|linear) options to show scheduler wait latency histograms - Add --time option to filter analysis by time span in 'perf sched latency' ARM CoreSight: - Synthesize callchains for instruction samples from CoreSight trace using thread stack ('--itrace=g...') - Support call indentation ('perf script -F +callindent') to display call depth hierarchy on branch samples - Decode ETE (Embedded Trace Extension) exception packets Build system: - Add 'make install-build-deps' target to install required packages - Parallelize JSON and metric pre-computation in jevents.py for faster builds Vendor event/metric updates: - Add Intel Nova Lake events and update tables for existing models - Update AMD Zen 5 and Zen 6 core events - Update Arm64 Tegra410 metrics and PowerPC hcalls Internal changes and fixes: - Harden trace-event and synthetic event parsing against corrupted data - Fix unwinding of multi-threaded processes in libdw unwinder - Fix memory leaks in various commands and python bindings - Speed up 'perf test' shell tests" * tag 'perf-tools-for-v7.3-2026-08-21' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: (232 commits) perf vendor events arm64: Fix Tegra410 Olympus event 0x0197 perf vendor events arm64: fix swapped MetricGroup for Tegra410 L1 prefetcher metrics perf evlist: Warn when 'sleep' workload is used without system-wide (-a) option perf c2c: document function view in perf-c2c man page perf c2c: add function view browser UI and cacheline detail perf c2c: build and finalize the function view hierarchy perf c2c: add function view hierarchy entry creation perf c2c: add function view stats merge and memory management perf c2c: add HPP list parsing for function view columns perf c2c: add column rendering for function view perf c2c: add function view model skeleton perf c2c: extract shared data structures into util/c2c.h perf test sample-parsing: Validate PERF_FORMAT_GROUP values without LOST perf dso: Replace assert with runtime check in dso__read_symbol() perf dso: Guard against cache underflow on short reads in dso_cache__memcpy() perf dso: Use stored fd error instead of stale errno in file_read() and file_size() perf dso: Guard close() against invalid fd in dso__decompress_kmodule_path() perf dso: Guard against errno==0 when dso__get_filename() returns NULL perf build: install-build-deps: add RHEL family devel package mapping perf build: Remove leftover feature tests for removed cxx and clang support ... commit 47f05f71ad988c3180bdba807151e6e86ed75aa3 Merge: 26260251022fbc 05bfb1327dc5fb Author: Linus Torvalds Date: Sat Aug 22 08:41:28 2026 -0700 Merge tag 'firewire-updates-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire updates from Takashi Sakamoto: "Error handling, a potential bug fix, and KUnit tests: - Handle failures when generating the contents of the configuration ROM with parameters supplied by in-kernel implementations such as unit drivers (Sreeraj S Kurup) - Fix potential memory leak when an invalid self-ID sequence causes an error while building the internal node tree (Abdun Nihaal) KUnit tests have been added to trigger this case" * tag 'firewire-updates-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: core: fix memory leak in error path of build_tree() firewire: core: validate parent port count before allocating nodes in build_tree() firewire: core: consolidate port counting in build_tree() firewire: core: add KUnit tests for failure of tree building firewire: core: add KUnit tests for successful tree building firewire: core: add KUnit test skeleton for node tree firewire: core: validate sub-block lengths in fw_core_add_descriptor() firewire: core: validate overall descriptor length in fw_core_add_descriptor() commit a9a01be2834a529cbd490ccbab02643f0c1735f2 Author: Vincent Donnefort Date: Fri Aug 7 09:54:23 2026 +0100 tracing: Fix logged instance name on creation failure When boot instance creation fails, the kernel incorrectly logs "(null)" as the instance name because strsep() consumes curr_str entirely during parsing. Print the properly parsed name variable instead. And while at it log the error code. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260807085423.4175161-1-vdonnefort@google.com Fixes: cb1f98c5e574 ("tracing: Add creation of instances at boot command line") Acked-by: Masami Hiramatsu (Google) Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt commit d576a9561a1c80ae593539fb0ce0743d66825ac2 Merge: 7a79b02dd1b09c b5fa55ad007059 Author: Andi Shyti Date: Sat Aug 22 14:19:12 2026 +0200 Merge tag 'rust-i2c-for-7.3' into i2c/i2c i2c: rust: mark I2cAdapter methods as inline A single cleanup for the Rust I2C abstractions, targeting 7.3. `I2cAdapter::get`, `inc_ref`, and `dec_ref` are trivial wrappers around `i2c_get_adapter`/`i2c_put_adapter` and were showing up as their own symbols in the build. Mark them `#[inline]` so they get folded into their callers instead. Signed-off-by: Igor Korotin * tag 'rust-i2c-for-7.3': i2c: rust: mark I2cAdapter methods as inline commit b5fa55ad007059547c9139d4c4872e158ae255f2 Author: Nicolás Antinori Date: Thu May 21 16:08:50 2026 -0300 i2c: rust: mark I2cAdapter methods as inline When building the kernel using llvm-19.1.7-rust-1.85.0-x86_64, the following symbols are generated: $ nm vmlinux | grep ' _R'.*I2cAdapter | rustfilt ffffffff817ff380 T ::get ffffffff817ff400 T ::dec_ref ffffffff817ff3e0 T ::inc_ref However, these Rust symbols are trivial wrappers around the `i2c_get_adapter` and `i2c_put_adapter` functions. It doesn't make sense to go through a trivial wrapper for these functions. Link: https://github.com/Rust-for-Linux/linux/issues/1145 Suggested-by: Alice Ryhl Signed-off-by: Nicolás Antinori Reviewed-by: Onur Özkan Reviewed-by: Igor Korotin Signed-off-by: Igor Korotin commit 3c0ebc4c07ff1147724d8f370203e62390ae7ee7 Author: Helge Deller Date: Fri Aug 21 10:01:22 2026 +0200 vt: hide cursor prior to font changes to avoid out-of-bound reads KASAN reports slab-out-of-bounds errors: BUG: KASAN: slab-out-of-bounds in soft_cursor+0x3eb/0xb70 drivers/video/fbdev/core/softcursor.c:70 When changing the size of a sceen font, the amount of columns and rows on a screen may change and thus the current position of the cursor and the selection may suddenly lay outside of the current screen limits. Clear the selection and hide the cursor before any font changes to avoid such possible out of bounds accesses. Reported-by: Jaeyoung Chung Signed-off-by: Helge Deller Link: https://lore.kernel.org/all/20260819163440.3702924-1-jjy600901@snu.ac.kr/ commit 9e8581a090c02ffa35e8439b90b024956a735de9 Author: Tejun Heo Date: Tue Aug 18 09:48:40 2026 -1000 sched_ext: Sync common and compat headers from the scx repo Sync common.bpf.h, compat.bpf.h and compat.h with the scx repo, which accumulated the following: - __COMPAT_read_enum() can now recover 64-bit scx enum values from kernel BTF generated without BTF_KIND_ENUM64 support (pahole < 1.24 or --skip_encoding_btf_enum64, e.g. COS/GKE kernels), substituting values from the build-time vmlinux.h cross-checked against the low 32 bits the kernel does provide. - is_migration_disabled() no longer assumes the BPF prolog always disables migration. Since 8e4f0b1ebcf2 ("bpf: use rcu_read_lock_dont_migrate() for trampoline.c") the prolog only does so under CONFIG_PREEMPT_RCU, so the old current-task test under-reported on v6.18+ !PREEMPT_RCU kernels. A runtime probe on bpf_scx_reg() handles older kernels with backported trampoline behavior. - __COMPAT_scx_bpf_dsq_peek() is gated behind kernel v7.1 where 2f2ea7709266 ("sched_ext: Use dsq->first_task instead of list_empty() in dispatch_enqueue() FIFO-tail") fixed the kfunc spuriously returning NULL on non-empty FIFO DSQs, and the new scx_bpf_reenqueue_local_from_anywhere() provides a callable-from-anywhere reenqueue which prefers the generic scx_bpf_dsq_reenq(). Both were first posted by Gavin Guo and Changwoo Min and are picked up here with the review feedback folded in. - __COMPAT_scx_bpf_cpu_curr() and the scx_bpf_cpu_rq() declaration are restored. Schedulers built from these headers still run on pre-v6.18 kernels where scx_bpf_cpu_curr() does not resolve and the scx_bpf_cpu_rq() fallback still exists. - scx_clock_task() and scx_clock_pelt() document their stale-read behavior for remote idle CPUs under NO_HZ_IDLE. Link: https://lore.kernel.org/all/20260817143126.562923-1-changwoo@igalia.com Signed-off-by: Tejun Heo commit e10b8b4931e10dbcce5b369583461d81c69187e8 Author: Tejun Heo Date: Tue Aug 18 09:48:40 2026 -1000 sched_ext: Sync tools autogen enum headers from the scx repo Regenerate enum_defs.autogen.h against the current tree, picking up the dispatch verdict enums and dropping the marker for the removed SCX_RQ_IN_BALANCE. Add enums_abi.autogen.h, a table of 64-bit scx enumerator values generated from vmlinux.h, used as the substitution source when the running kernel's BTF truncates 64-bit enum values to 32 bits. Signed-off-by: Tejun Heo commit dafb84f092a6387748b2df4c8f647d46873bc1a0 Author: Chao Yu Date: Wed Aug 12 12:20:43 2026 +0000 f2fs: fix to propagate error from f2fs_sync_fs() So that caller can detect any failure from f2fs_sync_fs(). Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim commit a2c73a7a677afdaa8b16d775188f9ef5cfbfd8b2 Author: Wenjie Qi Date: Mon Aug 10 21:38:32 2026 +0800 f2fs: return symlink writeback errors F2FS writes long symlink data with page_symlink() and then flushes the symlink mapping to reduce the chance of exposing a broken symlink. That flush result is currently ignored. If the writeback fails, symlink() still returns success even though the symlink is not durable and the same operation can already surface -EIO through syncfs(). Return the writeback error to userspace and skip the dirsync flush once the symlink data flush has failed. Fixes: d0cae97cb600 ("f2fs: flush symlink path to avoid broken symlink after POR") Cc: stable@kernel.org Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim commit 11d56d7a8e60d7ee4969b56403da700745aea1af Author: Daeho Jeong Date: Fri Aug 21 07:17:42 2026 -0700 f2fs: fix error handling on device alias check in rename and unlink In f2fs_rename() and f2fs_unlink(), directly returning -EPERM when encountering a device aliasing file bypasses the cleanup path. Fix this by setting err to -EPERM and jumping to the proper cleanup labels (out_dir and out) instead of returning immediately. Reported-by: Christophe JAILLET Signed-off-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim commit 2b8704b6a8b2896ccad1f5941d9a3e2c5031a470 Author: Chao Yu Date: Mon Aug 17 02:39:27 2026 +0000 f2fs: fix to reset all pinned status during fggc 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 commit 46d4246d8dcde75aff707976cddc546f22184cac Author: Chao Yu Date: Mon Aug 17 11:19:16 2026 +0000 f2fs: use f2fs_{down, up}_(read, write}_trace() for nat_tree_lock Under heavy workloads or during background GC/fallocate operations, nat_tree_lock can experience high lock contention between background readers (e.g. f2fs_get_node_info() in gc_data_segment) and writers (e.g. flush_nat_entries, set_node_addr, shrinker). [375067.327986][T13777] schedule+0x4c/0x114 [375067.327997][T13777] f2fs_get_node_info+0x438/0x5c4 [375067.328002][T13777] f2fs_get_inode_page+0x1e0/0x3f0 [375067.328013][T13777] f2fs_iget+0x88/0x1180 [375067.328024][T13777] f2fs_lookup+0x168/0x3a8 [375067.328035][T13777] path_openat+0xa28/0x1b04 [375067.328046][T13777] do_filp_open+0xac/0x130 [375067.328056][T13777] do_sys_openat2+0x140/0x21c [375067.328066][T13777] __arm64_sys_openat+0x70/0x9c [375067.330299][T13777] schedule+0x4c/0x114 [375067.330310][T13777] schedule_preempt_disabled+0x24/0x40 [375067.330321][T13777] rwsem_down_write_slowpath+0x3b4/0x9d0 [375067.330332][T13777] down_write+0x98/0x170 [375067.330343][T13777] set_node_addr+0x74/0x4b4 [375067.330354][T13777] f2fs_new_node_page+0xb0/0x280 [375067.330444][T13777] f2fs_new_inode_page+0x3c/0x64 [375067.330455][T13777] f2fs_init_inode_metadata+0x4c/0x47c [375067.330461][T13777] f2fs_add_regular_entry+0x258/0x5b8 [375067.330471][T13777] f2fs_add_dentry+0x100/0x158 [375067.330476][T13777] f2fs_do_add_link+0x84/0x140 [375067.330487][T13777] f2fs_create+0xec/0x250 [375067.331759][T13777] schedule+0x4c/0x114 [375067.331770][T13777] f2fs_down_read+0x9c/0xc4 [375067.331781][T13777] f2fs_need_inode_block_update+0x20/0x10c [375067.331792][T13777] f2fs_do_sync_file+0x478/0x830 [375067.331802][T13777] f2fs_sync_file+0x2c/0x40 This patch converts nat_tree_lock to use the f2fs_{down,up}_{read,write}_trace infrastructure. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim commit 660ee6792edfe498e35ec17b1b34bb6704e74f4f Author: Fenglin Wu Date: Thu Aug 6 23:21:40 2026 -0700 dt-bindings: input: Add Qualcomm SPMI PMIC haptics Add binding document for the haptics module inside Qualcomm PMIC PMIH0108. Assisted-by: Claude:claude-4-8-opus Reviewed-by: Krzysztof Kozlowski Signed-off-by: Fenglin Wu Link: https://patch.msgid.link/20260806-qcom-spmi-haptics-v6-1-19fcecd5204f@oss.qualcomm.com [robh: Drop example] Signed-off-by: Rob Herring (Arm) commit 72cc574aa3791aa4f05d247b4e884cdbd135819a Author: Julian Braha Date: Fri Aug 21 18:54:10 2026 +0100 ASoC: fix unmet dependencies on PPC_BESTCOMM and SND_SOC_AC97_BUS SND_MPC52xx_SOC_PCM030 and SND_MPC52xx_SOC_EFIKA both select SND_SOC_MPC5200_AC97 without ensuring its dependency on PPC_BESTCOMM is met. This causes unmet dependencies such as: WARNING: unmet direct dependencies detected for SND_SOC_MPC5200_AC97 Depends on [n]: SOUND [=m] && SND [=m] && SND_SOC [=m] && SND_POWERPC_SOC [=m] && PPC_BESTCOMM [=n] Selected by [m]: - SND_MPC52xx_SOC_PCM030 [=m] && SOUND [=m] && SND [=m] && SND_SOC [=m] && SND_POWERPC_SOC [=m] && PPC_MPC5200_SIMPLE [=y] In v1, Rosen pointed out that the import of "mpc5200_dma.h" is actually unnecessary, and Arnd suggested that the 'select' of SND_SOC_MPC5200_AC97 be changed to 'depends on'. This resolves all 3 unmet dependencies. These unmet dependency bugs were detected by kconfirm, a static analysis tool for Kconfig. Fixes: a9262c4fd404 ("ASoC: Support for AC97 on Phytec pmc030 base board.") Fixes: 6ffee43ecf8b ("ASoC: Fabric bindings for STAC9766 on the Efika") Suggested-by: Arnd Bergmann Suggested-by: Rosen Penev Signed-off-by: Julian Braha Link: https://patch.msgid.link/20260821175410.179631-1-julianbraha@gmail.com Signed-off-by: Mark Brown commit cf82dd2183cb0c224816f7d23d32a7a05be4858b Author: Niranjan H Y Date: Thu Aug 20 17:21:14 2026 +0530 ASoC: tac5xx2-sdw: update default regmap registers * At boot time, when the registers are accessed by asoc layer while trying to enable a DAPM path, while the device is still being attached, -EBUSY error will be thown by regmap_read and regmap_udpate_bits. Because the regmap will be in cache only mode. Add default values for these registers so that, the cached values are returned instead of error. * Also remove writing default values once again for first attach. Signed-off-by: Niranjan H Y Link: https://patch.msgid.link/20260820115114.1203-3-niranjan.hy@ti.com Signed-off-by: Mark Brown commit 04145998fa20f321fd7090089c7f86dba3d36a13 Author: Niranjan H Y Date: Thu Aug 20 17:21:13 2026 +0530 ASoC: tac5xx2-sdw: Rename gain and volume macros Rename gain and volume macros to match the hardware intent. Currently, both TAC_SDCA_CHANNEL_GAIN and TAC_SDCA_CHANNEL_VOLUME are defined as 0x02. Keep only TAC_SDCA_CHANNEL_VOLUME and reposition TAC_SDCA_CHANNEL_GAIN to 0x0B. Remove the now-redundant TAC_SDCA_MASTER_GAIN alias (also 0x0B), replacing its single use with TAC_SDCA_CHANNEL_GAIN. Signed-off-by: Niranjan H Y Link: https://patch.msgid.link/20260820115114.1203-2-niranjan.hy@ti.com Signed-off-by: Mark Brown commit 9d4843ac81d15be27e0b03392a99a8bd88a2d86a Author: Niranjan H Y Date: Thu Aug 20 17:21:12 2026 +0530 ASoC: sdw_utils: Set component_name for tac5xx2 codec family * With component_name set in the codec_info_list DAI entries, "amixer -D hw: info" includes the 'spk' identifier for each tac5xx2 speaker component. This allows userspace to identify the speaker codec at runtime and enables UCM card matching for the tac5xx2 family. * Set component_name for the speaker, mic, and UAJ DAI entries for all tac5xx2 family variants. Signed-off-by: Niranjan H Y Link: https://patch.msgid.link/20260820115114.1203-1-niranjan.hy@ti.com Signed-off-by: Mark Brown commit 9324becc398a1f9e67c91a3d652a7c56e5afc7f4 Merge: 70cbec6fec2c5b ce3294cef61c85 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:48 2026 -0500 Merge branch 'pci/misc' - Fix typos in documentation (D'Orus Tsitera) - Use %pe format specifier to print error pointers so we get symbolic errname when available (Krzysztof Wilczyński) * pci/misc: PCI: Use %pe format specifier to print error pointers Documentation: PCI: Fix sysfs-bus-pci typo commit 70cbec6fec2c5b7e73d7edbeb6810e57fad66138 Merge: 25a22c9078d262 6d99b198629dde Author: Bjorn Helgaas Date: Fri Aug 21 16:40:47 2026 -0500 Merge branch 'pci/controller/misc' - Use common wait time definitions for PCIe link monitoring instead of defining driver-private duplicates (Thierry Reding) - Add LECARC PMU IDs to the DWC RAS/DES VSEC list so it can take advantage of the existing debugfs support for silicon debug, error injection, and event counters (Brett Zhou) * pci/controller/misc: PCI: dwc: Add PCI ID for LECARC PCIe PMU PCI: Use standard wait times for PCIe link monitoring commit 25a22c9078d2626fa833969c0c04c5927adf673f Merge: e0aba454f87aeb 4869db344e76c9 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:47 2026 -0500 Merge branch 'pci/controller/xgene' - Drop unnecessary OF node reference (Yuho Choi) * pci/controller/xgene: PCI: xgene: Drop unnecessary OF node reference commit e0aba454f87aeb3d2c86fcc401daa7db03061bdb Merge: b130a2caf5d3f6 55aa45154fe48b Author: Bjorn Helgaas Date: Fri Aug 21 16:40:47 2026 -0500 Merge branch 'pci/controller/vmd' - Support device ID 0x28C1 and assume that BIOS has already enumerated the hierarchy below VMD and stored bus range info for OS to use (Nirmal Patel) - Add support for VMCONFIG BUS_RESTRICT_CFG=3, which makes it possible to enumerate downstream devices on Intel Arrow Lake-HX systems and probably others (Ali Alaei) - Observe _OSC negotiation for VMD hierarchy only when running on bare metal, not when running in a VM (Nirmal Patel) - Add Nova Lake (NVL) and Dunlow (DNL) Device IDs (Szymon Durawa) * pci/controller/vmd: PCI: vmd: Add Nova Lake (NVL) and Dunlow (DNL) Device IDs PCI: vmd: Only copy root bridge _OSC control flags in bare metal OS PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX PCI: vmd: Add feature to scan BIOS-enumerated devices commit b130a2caf5d3f65c14e9524c65bcf0d64be298d9 Merge: 003bb33da95b04 01c3c27a0ef6a7 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:46 2026 -0500 Merge branch 'pci/controller/tegra264' - Distinguish Tegra264 C0 PCIe controller for internal GPU from C1-C5 controllers so the unit address matches the first 'reg' entry (Thierry Reding) - Add Tegra264 Root Port stanzas to prepare for generic WAKE# handling (Thierry Reding) - Add NVIDIA Tegra264 driver (Thierry Reding) * pci/controller/tegra264: PCI: tegra264: Add Tegra264 support dt-bindings: PCI: tegra264: Switch to PCIe Root Port bindings dt-bindings: PCI: tegra264: Strictly distinguish C0 from C1-C5 commit 003bb33da95b0465ea524b32c94c3534bc8e01cc Merge: 707ba6063c4712 007c7304d80f14 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:46 2026 -0500 Merge branch 'pci/controller/rzg3s-host' - Add DT binding and driver support for RZ/V2H(P) SoC, which contains two PCIe controllers, configured either as a single x4 link or two independent x2 link controllers (Lad Prabhakar) * pci/controller/rzg3s-host: PCI: rzg3s-host: Add support for RZ/V2H(P) SoC PCI: rzg3s-host: Prepare System Controller handling for multiple controllers PCI: rzg3s-host: Use shared reset controls for power domain resets dt-bindings: PCI: renesas,r9a08g045-pcie: Add RZ/V2H(P) support commit 707ba6063c47125dedb712fb075e6a7e5239218d Merge: 2d022e66d5d962 2077ccb9baa2cb Author: Bjorn Helgaas Date: Fri Aug 21 16:40:45 2026 -0500 Merge branch 'pci/controller/mediatek' - Add support for PCIe controller in EcoNet EN7528 and EN751221 SoCs (Caleb James DeLisle) * pci/controller/mediatek: PCI: mediatek: Add support for EcoNet EN7528 SoC commit 2d022e66d5d962fe1323ea8f5f5f858168b06a58 Merge: e6859eee417d32 aaae917990623a Author: Bjorn Helgaas Date: Fri Aug 21 16:40:45 2026 -0500 Merge branch 'pci/controller/plda-starfive' - Fix resource leaks on error paths in host_init() (Ali Tariq) - Fix runtime PM handling and teardown ordering to avoid register access while power or clocks are disabled (Ali Tariq) - Check for runtime PM resume failure to avoid register access while power or clocks are disabled (Ali Tariq) * pci/controller/plda-starfive: PCI: starfive: Fix unchecked pm_runtime_get_sync() in probe PCI: starfive: Fix Runtime PM handling and teardown ordering PCI: starfive: Fix resource leaks on error paths in host_init() commit e6859eee417d32ef838131c1dc98dfdf01146978 Merge: 3d3fce9435088b 19a30bbb6477bf Author: Bjorn Helgaas Date: Fri Aug 21 16:40:44 2026 -0500 Merge branch 'pci/controller/plda-host' - Fix event IRQ user-after-free issues (Ali Tariq) - Fix IRQ domain leaks in error paths (Ali Tariq) * pci/controller/plda-host: PCI: plda: Fix IRQ domain leaks in the error paths of plda_init_interrupts() PCI: plda: Fix use-after-free of event IRQs during teardown commit 3d3fce9435088be669e4473425877259e1cabac3 Merge: 2a66fae91e356a 22a415e623e9eb Author: Bjorn Helgaas Date: Fri Aug 21 16:40:44 2026 -0500 Merge branch 'pci/controller/dwc-ultrarisc' - Add 'core', 'dbi', and 'aux' clocks to DT binding and manage them in the driver (Jia Wang) - Use module_platform_driver() since this may be built as a module, though not removable because IRQs can't be safely disposed (Jia Wang) * pci/controller/dwc-ultrarisc: PCI: ultrarisc: Use module_platform_driver() PCI: ultrarisc: Get and enable DP1000 PCIe controller clocks dt-bindings: PCI: ultrarisc: Add required DP1000 PCIe clocks commit 2a66fae91e356ae0713f7e7fd3caddd089ac2c46 Merge: 45b3d1baf4d606 e145af8c14474d Author: Bjorn Helgaas Date: Fri Aug 21 16:40:44 2026 -0500 Merge branch 'pci/controller/dwc-spacemit-k1' - Add missing MODULE_DEVICE_TABLE() to generate module alias info for OF-based module autoloading (Pengpeng Hou) * pci/controller/dwc-spacemit-k1: PCI: spacemit: Add missing MODULE_DEVICE_TABLE() commit 45b3d1baf4d6062ea61c23b0c60eb6e4720e4936 Merge: 1579362594999e a8818827486cd3 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:43 2026 -0500 Merge branch 'pci/controller/dwc-rcar-gen4' - When MSI is enabled but iMSI-RX is not used, configure AXIINTC to allow GIT ITS to handle MSI (Marek Vasut) - Refactor GIC600 implementation to make it easier to add platforms that only support 32-bit addressing (Marek Vasut) - Add Renesas R-Car Gen4 S4/V4H/V4M to the list of GIC600 integrations that only support 32-bit addressing (Marek Vasut) * pci/controller/dwc-rcar-gen4: irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling PCI: rcar-gen4: Configure AXIINTC if iMSI-RX is not used PCI: dwc: Move iMSI-RX check before calling 'pp->ops->init()' commit 1579362594999e8357ac671ecc45775740714da9 Merge: 9bb52aa1972d89 65ccb2203ef891 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:43 2026 -0500 Merge branch 'pci/controller/dwc-qcom' - Add DT binding and driver support for Hawi SoC (Matthew Leung) - Skip PERST# GPIOs provided by downstream PCIe devices, which should be handled by drivers of those devices (Manivannan Sadhasivam) - Stop advertising Attention Button Present (no Qcom SoCs support Attention Buttons) so pciehp can use Presence Detect Changed events (Qiang Yu) * pci/controller/dwc-qcom: PCI: qcom: Clear Attention Button Present in Slot Capabilities PCI: qcom: Rename qcom_pcie_set_slot_nccs() to qcom_pcie_set_slot_cap() PCI: qcom: Skip PERST# GPIOs provided by downstream PCIe devices PCI: qcom: Add support for Hawi dt-bindings: PCI: qcom: Document Hawi and Maili PCIe Controllers commit 9bb52aa1972d895b1bbd31aed5813c39ddc33a18 Merge: ab345fad8f7f9c 40fb390cbcc117 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:42 2026 -0500 Merge branch 'pci/controller/dwc-meson' - Correct the PERST# GPIO state so it remains asserted until power and REFCLK become stable to fix enumeration failure (Ronald Claveau) * pci/controller/dwc-meson: PCI: meson: Fix GPIO state while requesting PERST# commit ab345fad8f7f9c21e36e008fe42dc23e9a8b6a90 Merge: 3e01ebb61957d1 3260336defeb29 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:42 2026 -0500 Merge branch 'pci/controller/dwc-keystone' - Fix OF node reference leak in init (Yuho Choi) * pci/controller/dwc-keystone: PCI: keystone: Fix OF node reference leak in init commit 3e01ebb61957d1c61ce950c635b17431a07544c1 Merge: 71aabbe6d49ba1 c2b9620359b759 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:42 2026 -0500 Merge branch 'pci/controller/dwc-imx6' - Remove PERST# checking from pci_host_common_parse_port() so callers can decide whether to fall back to legacy DT binding with PERST# in the host bridge (Sherry Sun) - Fix build issues when PCI_PWRCTRL_GENERIC or PCI_HOST_COMMON is a module (Arnd Bergmann) - Create pwrctrl devices only once by doing it from imx_pcie_probe() instead of imx_pcie_host_init(), which is used during both probe and resume (Sherry Sun) - Use 'dw_pcie_rp->skip_pwrctrl_off' to avoid powering off devices during suspend to preserve wakeup capability (Sherry Sun) - Add runtime PM support for i.MX95 to allow dynamic power management when the link is idle (Richard Zhu) * pci/controller/dwc-imx6: PCI: imx6: Add runtime PM support for i.MX95 PCI: imx6: Add 'skip_pwrctrl_off' flag support PCI: imx6: Move pci_pwrctrl_create_devices() to imx_pcie_probe() PCI: imx6: Fix building against PCI_PWRCTRL_GENERIC PCI: imx6: Fix building against PCI_HOST_COMMON PCI: host-generic: Move legacy DT binding fallback decision to caller of pci_host_common_parse_ports() commit 71aabbe6d49ba17f84a5178252dfc6ec75796ac5 Merge: 4bba1f93069eea c1366b72ad4e87 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:41 2026 -0500 Merge branch 'pci/controller/dwc' - Factor pcie_valid_speed() and pci_bus_speed2lnkctl2() out of bwctrl so they can be shared by the DWC core (Hans Zhang) - Flush MSI writes from endpoint before unmapping the iATU, as we already do for MSI-X writes (Niklas Cassel) - Unmap MSI iATU window before mapping MSI-X window, to avoid a subsequent MSI write using a disabled aperture and losing the interrupt (Niklas Cassel) - Change endpoint .pre_init() and .init() callbacks to return errors and handle them (Marek Vasut) * pci/controller/dwc: PCI: dwc: Handle return value from endpoint .pre_init callback PCI: dwc: Handle return value from endpoint .init callback PCI: dwc: ep: Fix unmap potentially unmapping the wrong iATU PCI: dwc: ep: Flush cached MSI write before unmapping the iATU PCI: dwc: Use common speed conversion function PCI: Move pci_bus_speed2lnkctl2() to public header PCI: Add public pcie_valid_speed() for shared validation commit 4bba1f93069eea16be0e9d8cd78f9e115cb1254e Merge: 1ef0f8a7f0847e 79752653c13649 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:41 2026 -0500 Merge branch 'pci/controller/cadence' - Add missing MODULE_DEVICE_TABLE to generate module aliases for OF-based module autoloading (Pengpeng Hou) - Add debugfs 'ltssm_status' file for LGA- and HPA-based Cadence controllers (Hans Zhang) - Support up to x4 (not x2) lanes for J200 (Takuma Fujiwara) - Fix host/endpoint dependencies for cadence-plat driver to fix link error when cadence-plat is built-in but the host or endpoint driver is modular (Aksh Garg) * pci/controller/cadence: PCI: cadence: Fix host/endpoint dependencies for cadence-plat driver PCI: j721e: Fix incorrect max_lanes for J7200 PCI: cadence: Add LGA IP debugfs for LTSSM status PCI: cadence: Add HPA IP debugfs for LTSSM status PCI: cadence: Add HPA architecture flag PCI: cadence: Add missing MODULE_DEVICE_TABLE() commit 1ef0f8a7f0847e988c594eed441bd2962ceabe1e Merge: c4afb0b2d3341e f944349dcbaeaa Author: Bjorn Helgaas Date: Fri Aug 21 16:40:40 2026 -0500 Merge branch 'pci/controller/aspeed' - Switch to irq_domain_create_linear() so we can obsolete irq_domain_add_linear() (Jiri Slaby) * pci/controller/aspeed: PCI: aspeed: Switch to irq_domain_create_linear() commit c4afb0b2d3341ed0bd746705ff8fa174976afae6 Merge: 4fe60541de1176 008cb88edb41f3 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:40 2026 -0500 Merge branch 'pci/controller/host-generic' - Fix NULL pointer dereference that caused enumeration failures on 32-bit CAM systems (Steffen Persvold) * pci/controller/host-generic: PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems commit 4fe60541de1176c55028aedf755a8968bfab1b97 Merge: e3a6268803d528 29e179cb7f636d Author: Bjorn Helgaas Date: Fri Aug 21 16:40:40 2026 -0500 Merge branch 'pci/controller/root-port-reset' * pci/controller/root-port-reset: misc: pci_endpoint_test: Add AER error handlers PCI: dw-rockchip: Implement .reset_root_port() and use for link down PCI: qcom: Implement .reset_root_port() and use for link down PCI: host-common: Add link down handling for Root Ports PCI/ERR: Add support for resetting the Root Ports in a platform-specific way PCI: dwc: ep: Clear MSI iATU mapping in dw_pcie_ep_cleanup() commit e3a6268803d5283f9f8cf26a4c070ee7396c9b67 Merge: 625ae0ff41e513 0a6f72eda328c7 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:39 2026 -0500 Merge branch 'pci/endpoint' - Check doorbell SUCCESS bit in pci_endpoint_test to avoid treating some failures as successes (Niklas Cassel) - Fail doorbell test when the trigger IRQ is missed (Niklas Cassel) * pci/endpoint: misc: pci_endpoint_test: Fail doorbell test when the trigger IRQ is missed misc: pci_endpoint_test: Check SUCCESS bit for doorbell status commit 625ae0ff41e5138303992547e59f665f7dcb9585 Merge: b4b07fb82b9e91 f7b2ceb411479b Author: Bjorn Helgaas Date: Fri Aug 21 16:40:39 2026 -0500 Merge branch 'pci/dt-binding' - Add qcom IPQ9650 compatible with global interrupt (Kathiravan Thirumoorthy) - Add qcom IPQ5210 compatible with IPQ9574 fallback (Varadarajan Narayanan) - Add imx6 intr/aer/pme interrupt lines for i.MX95 (Richard Zhu) - Add mediatek-gen3 'memory-region' for restricted DMA buffer (Chen-Yu Tsai) - Add rcar-gen4-pci-host optional 'msi-parent' for GIT ITS (Marek Vasut) - Correct some white-space issues (Krzysztof Kozlowski) * pci/dt-binding: dt-bindings: PCI: Correct white-space style dt-bindings: PCI: rcar-gen4-pci-host: Document optional msi-parent dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer dt-bindings: PCI: mediatek-gen3: Add support for MT8189 SoC dt-bindings: PCI: imx6q-pcie: Add i.MX95 optional intr/aer/pme interrupts dt-bindings: PCI: qcom,pcie-ipq9574: Add IPQ5210 compatible dt-bindings: PCI: qcom,pcie-ipq9574: Add IPQ9650 compatible commit b4b07fb82b9e91958cf37e35be08d2309fa16fbe Merge: 97ab14ecc75537 071e245ab749c5 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:38 2026 -0500 Merge branch 'pci/wake' - Add support for PCIe WAKE# interrupt when described via DT (Krishna Chaitanya Chundru) * pci/wake: PCI: Add support for PCIe WAKE# interrupt commit 97ab14ecc7553717695b12dbf28c3f538a4b4901 Merge: c1a7b1aad517bf 23d7eed5974989 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:38 2026 -0500 Merge branch 'pci/virtualization' - Add ACS quirk for Pericom PI7C9X2G608 switches (Tim Harvey) - Fix a long-standing bug in the Intel PCH Root Port MPC ACS quirk that didn't update the intended INTEL_MPC_REG_IRBNCE bit because it used a 16-bit config write when a 32-bit write was intended (Mohamad Raizudeen) * pci/virtualization: PCI: Fix 32-bit config write in Intel PCH Root Port MPC ACS quirk PCI: Add ACS quirk for Pericom PI7C9X2G608 switches [12d8:2608] commit c1a7b1aad517bfea7a29570bc21c22115aa41e1a Merge: 5572ea216f891f 1b7c9855bb686f Author: Bjorn Helgaas Date: Fri Aug 21 16:40:38 2026 -0500 Merge branch 'pci/sysfs' - In pci_write_legacy_io(), avoid out-of-bounds reads from the user buffer and fix incorrect ioport write data (1-byte writes on little-endian powerpc, 2- and 4-byte writes on big-endian powerpc) (Krzysztof Wilczyński) - In pci_read_legacy_io(), fix incorrect ioport read data for 2- and 4-byte reads on big-endian powerpc (Krzysztof Wilczyński) - Fix I/O port accessor argument order in Alpha pci_legacy_write() (Krzysztof Wilczyński) - Avoid spurious runtime PM wakeup on config space accesses that are outside config space and fail before reaching PCI (Krzysztof Wilczyński) - Return -EINVAL, not -ENODEV, for mmap of I/O BAR that fails because the arch doesn't support it, as we do for procfs (Krzysztof Wilczyński) - Check for LOCKDOWN_PCI_ACCESS for legacy_io and legacy_mem, as we do for other config space accessors (Krzysztof Wilczyński) - Tidy static resource attribute names and macros that build them (Krzysztof Wilczyński) * pci/sysfs: PCI/sysfs: Add legacy I/O and memory attribute macros alpha/PCI: Make the suffix the first __pci_dev_resource_attr() parameter PCI/sysfs: Add pci_ prefix to static PCI resource attribute names PCI/sysfs: Add lockdown checks to legacy I/O and memory handlers PCI/sysfs: Return -EINVAL for unsupported I/O BAR mmap PCI/sysfs: Avoid spurious runtime PM wakeup on config space accesses alpha/PCI: Fix I/O port accessor argument order in pci_legacy_write() PCI/sysfs: Fix read byte order in pci_read_legacy_io() PCI/sysfs: Fix out-of-bounds read in pci_write_legacy_io() commit 5572ea216f891f64fb314c588d0309770ea27ff0 Merge: adea2f75b7a3c2 00a479ba1d0124 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:37 2026 -0500 Merge branch 'pci/switchtec' - Add Microchip PCI1008 device ID and include it in NTB DMA alias quirk (Logan Gunthorpe) * pci/switchtec: PCI: switchtec: Add Microchip PCI1008 to NTB DMA alias quirk PCI: switchtec: Add Microchip PCI1008 device ID dmaengine: switchtec-dma: Add PCI1008 device ID commit adea2f75b7a3c2eca7d22b1c6c90c6eed92dc2cc Merge: f1093b32f8f0df 5012a69532081d Author: Bjorn Helgaas Date: Fri Aug 21 16:40:37 2026 -0500 Merge branch 'pci/resource' - Add hotplug reservation only once (not at each level of the hierarchy) so bridge windows don't grow more than necessary (Ilpo Järvinen) * pci/resource: PCI: Do not add hotplug reservation multiple times commit f1093b32f8f0df06446c8c9c71a9ad9314b37240 Merge: 9f91b2b716a086 b9851611bad7cb Author: Bjorn Helgaas Date: Fri Aug 21 16:40:36 2026 -0500 Merge branch 'pci/pwrctrl' - Take a reference on the I2C adapter in tc9563 to avoid uninterruptible hang when unloading an I2C module while in-use (Johan Hovold) - Restrict tc9563 Tx Amplitude, DFE and N_FTS to USP, DSP1 and DSP2 in DT binding (Manivannan Sadhasivam) - Fix parsing tc9563 integrated Ethernet MAC Endpoint node (Manivannan Sadhasivam) - Power off only tc9563 external-facing ports (DSP1, DSP2), leaving USP and DSP3 powered up (Manivannan Sadhasivam) - Skip tc9563 Tx amplitude and DFE tuning for DSP3, which don't support them (Manivannan Sadhasivam) - Move integrated MAC Endpoint out of the list of internal ports and configure it separately (Manivannan Sadhasivam) * pci/pwrctrl: PCI/pwrctrl: tc9563: Move Integrated MAC Endpoint out of 'tc9563_pwrctrl_ports' enum PCI/pwrctrl: tc9563: Rename DSP3 to VDSP PCI/pwrctrl: tc9563: Skip Tx amplitude and DFE tuning for DSP3 PCI/pwrctrl: tc9563: Power off only the external ports in tc9563_pwrctrl_disable_port() PCI/pwrctrl: tc9563: Fix parsing the integrated Ethernet MAC Endpoint node dt-bindings: PCI: toshiba,tc9563: Restrict Tx Amplitude, DFE and N_FTS to USP, DSP1 and DSP2 PCI/pwrctrl: tc9563: Take i2c adapter module reference commit 9f91b2b716a08634473c0f37fae57eebae3d5cbb Merge: 56948ac2a27528 f82f53e75eff38 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:36 2026 -0500 Merge branch 'pci/procfs' - Avoid spurious runtime PM wakeup on config space accesses that are outside config space and fail before reaching PCI (Krzysztof Wilczyński) - Warn on user-space writes to kernel-exclusive config space regions, as we already do for sysfs (Krzysztof Wilczyński) - Check credentials of opener, not reader, for config space reads, as we already to for sysfs (Krzysztof Wilczyński) * pci/procfs: PCI/proc: Use file_ns_capable() when checking config space read access PCI/proc: Warn on writes to kernel-exclusive config space regions PCI/proc: Avoid spurious runtime PM wakeup on config space accesses commit 56948ac2a27528d19d2707b9a8b88b15a7327a66 Merge: 057b93af1d1c5a 834171efeefffb Author: Bjorn Helgaas Date: Fri Aug 21 16:40:36 2026 -0500 Merge branch 'pci/portdrv' - Allow probing even without child services so it can do power management (Brian Norris) * pci/portdrv: PCI/portdrv: Allow probing even without child services commit 057b93af1d1c5ae529de799367ffcd380f1ef14a Merge: c9bb08a01e6eb6 d4c79b63d82d40 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:35 2026 -0500 Merge branch 'pci/pm' - Allow D3 for native hotplug-capable Root Ports on non-x86 platforms (we avoid D3 for these ports on x86 because some old platforms didn't validate it) (Manivannan Sadhasivam) * pci/pm: PCI: Allow D3 for native hotplug-capable Root Ports on non-x86 platforms commit c9bb08a01e6eb66b614f1662f3d6f439e46b32f3 Merge: 908ccdf5e378e9 894a78088fc3dd Author: Bjorn Helgaas Date: Fri Aug 21 16:40:35 2026 -0500 Merge branch 'pci/p2pdma' - Add Nvidia Vera Rubin to list of platforms that support P2PDMA (Leon Romanovsky) * pci/p2pdma: PCI/P2PDMA: Add Nvidia Vera Rubin to whitelist commit 908ccdf5e378e926ce92459082435138f7915a56 Merge: cc6fa623ca8d33 985fb7419fe27b Author: Bjorn Helgaas Date: Fri Aug 21 16:40:35 2026 -0500 Merge branch 'pci/hotplug' - Pass empty string, not an uninitialized device_class string, to acpi_bus_generate_netlink_event(), so we can remove device_class completely in the future (Rafael J. Wysocki) * pci/hotplug: PCI: acpiphp_ibm: Do not use uninitialized device_class commit cc6fa623ca8d33e2ce561ad294ac4bb478a3acd9 Merge: ea55835bc53825 3ffc4c9690c33e Author: Bjorn Helgaas Date: Fri Aug 21 16:40:34 2026 -0500 Merge branch 'pci/enumeration' - Don't store pci_device_id in agp amd-k7 and via, ata, scsi nsp32, ipack tpci200, mlxsw since the dynamic ID feature means the ID is only guaranteed to live during probe (Gary Guo) - Add pci_match_one_id() to match an ID directly so dynamic ID insertion doesn't need to make a temporary device for matching (Gary Guo) - Check for existing ID inside the dynamic ID addition critical section to avoid a time-of-check vs time-of-use race (Gary Guo) - Copy device ID to avoid use-after-free when match races with sysfs dynamic ID removal (Gary Guo) * pci/enumeration: PCI: Fix UAF when probe runs concurrent to dyn ID removal PCI: Fix dyn_id add TOCTOU PCI: Make pci_match_one_device() match on ID instead of device agp/amd-k7: Don't rely on address of pci_device_id agp/via: Don't rely on address of pci_device_id mlxsw: pci: Don't store pci_device_id ipack: tpci200: Don't store pci_device_id scsi: nsp32: Don't store pci_device_id ata: ata_generic: Don't store pci_device_id commit ea55835bc53825bd3486a2eaa59af4b326baa4cd Merge: 749fa6a99e73e6 97ca178c899d00 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:34 2026 -0500 Merge branch 'pci/dpc' - Allow DPC on all Downstream Ports, not just Root Ports, when OS controls AER (Darshit Shah) * pci/dpc: PCI/DPC: Allow DPC on all Downstream Ports when OS controls AER commit 749fa6a99e73e66b96225868bbf15b66751c06fc Merge: 606866edbcd7ea 1af156149d9a7d Author: Bjorn Helgaas Date: Fri Aug 21 16:40:33 2026 -0500 Merge branch 'pci/doc' - Document how to write PCI Host Controller drivers (Manivannan Sadhasivam) * pci/doc: Documentation: PCI: Document how to write PCI Host Controller drivers commit 606866edbcd7eacbccbdfdd8cf5daf298b2eae73 Merge: d358e9ad15c20c eacf92a29af970 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:33 2026 -0500 Merge branch 'pci/aspm' - Avoid L0s for Realtek RTS525A, where it causes an AER interrupt storm (Max Lee) - Program the same ASPM Control values for every function of multi-function devices, as recommended by the PCIe spec (Krishna Chaitanya Chundru) - Avoid ASPM L0s, L1, and L1 PM Substates based on 'aspm-no-l0s', 'aspm-no-l1' [1], and 'aspm-no-l1ss' DT properties (Krishna Chaitanya Chundru) * pci/aspm: PCI/ASPM: Mask ASPM states based on Devicetree properties PCI/ASPM: Disable/restore ASPM on every function for multi-function devices PCI/ASPM: Use pcie_capability_clear_and_set_word() for ASPM disable/restore PCI/ASPM: Avoid L0s for Realtek RTS525A commit d358e9ad15c20cc1f5fb5015f81f66dea6d47de9 Merge: dc59e4fea9d83f eddba19b8b5f76 Author: Bjorn Helgaas Date: Fri Aug 21 16:40:33 2026 -0500 Merge branch 'pci/aer' - Update mappings of errors to agent & layer (Lukas Wunner) - Log agent & layer of each individual error when multiple errors detected (Lukas Wunner) - Log Error Source only once, not twice in separate messages (Lukas Wunner) - Emit TLP Log only for unmasked errors (Lukas Wunner) - Support Advisory Non-Fatal Errors (Lukas Wunner) * pci/aer: PCI/AER: Support Advisory Non-Fatal Errors PCI/AER: Move retrieval of FEP and TLP Log into helper PCI/AER: Emit TLP Log only for unmasked errors PCI/AER: Deduplicate logging of Error Source Identification PCI/AER: Log agent & layer for each individual error PCI/AER: Fix mapping of errors to agent & layer commit 26260251022fbc2f248a3d747a9b2b961b18d2d8 Merge: 2f0f6b0773be0a e77f165d26f72c Author: Linus Torvalds Date: Fri Aug 21 13:11:56 2026 -0700 Merge tag 'livepatching-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching Pull livepatching updates from Petr Mladek: - Move consistency checks to catch missing func->old_name before the first access - Allow to run livepatching selftests from top-level directory * tag 'livepatching-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching: kbuild: unset sub_make_done before calling kselftest build system livepatch: Fix NULL pointer dereference in klp_find_func() commit 2f0f6b0773be0a1ec475097ae54848eea42adc7d Merge: 27a59c0251e5d1 3dfaae04243cde Author: Linus Torvalds Date: Fri Aug 21 12:47:25 2026 -0700 Merge tag 'modules-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux Pull module updates from Petr Pavlu: - Remove unnecessary module::args. Nowadays, no parameter-handling code points into the module::args buffer. The last user of module::args in xtensa/simdisk is updated and the data is then removed - Add Rust support for boolean parameters. This will initially be used by the Rust null block driver - Fix clearing the current charp parameter value when setting a new one fails due to an allocation failure - Improve the debugging code for kmod (request_module()) duplicates. Fix a potential use-after-free when waiting on a duplicate request and make several general improvements to the code - Fix the symbol size returned when looking up a data symbol through kallsyms - Smaller fixes and cleanups * tag 'modules-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux: params: fix charp corruption on allocation failure module: validate string table section types module/dups: Clean up includes module/dups: Use strcmp() to compare module names module/dups: Use scope-based cleanup helpers module/dups: Avoid unnecessary kmod_dup_req allocations module/dups: Fix use-after-free in kmod_dup_req lifetime handling module/dups: Inform duplicate requests about the result directly rust: module_param: support bool parameters rust: module_param: return value by copy from `value` module: Remove unnecessary module::args xtensa/simdisk: Avoid referring to module::args module: Remove unused DISCARD_EH_FRAME definition from module.lds.S module: procfs: use matching type for accumulator in module_total_size() module: use strscpy() to copy module names in stats and dup tracking params: fix path of /sys/module/XYZ/parameters/ in comment module/kallsyms: fix nextval for data symbol lookup commit 27a59c0251e5d1f41a3a6fbae7c4dc478c34d919 Merge: af33c5a2a9fd52 3b7711be026128 Author: Linus Torvalds Date: Fri Aug 21 12:39:49 2026 -0700 Merge tag 'mips_7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux Pull MIPS updates from Thomas Bogendoerfer: - switch gpio code to use swnodes - rework of TXX9 gpio code - enable multi-vpe for econet - cleanups and fixes * tag 'mips_7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: mips: dts: econet: Describe dual-VPE 34Kc processor mips: econet: add multi-vpe capability to EN751221 MIPS: ptrace: Fix syscall skipping via PTRACE_SYSCALL mips: remove dead select MIPS: BCM47XX: Convert buttons to software nodes ssb: gpio: Add and register software node for GPIO controller bcma: gpio: Add and register software node for GPIO controller MIPS: ip22-gio: Drop #include of MIPS: TXX9: Clean up txx9_iocled_init() MIPS: TXX9: Convert gpio_txx9 to dynamic GPIO base allocation MIPS: TXX9: Drop GPIOLIB_LEGACY select MIPS: TXX9: Use GPIO lookup table for iocled LEDs MIPS: TXX9: Reduce TXX9_IOCLED_MAXLEDS to 3 MIPS: TXX9: rbtx4927: Use GPIO lookup table for TXx9 LEDs MIPS: TXX9: rbtx4927: Use GPIO lookup table for SIO DTR MIPS: TXX9: Remove txx9_7segled_*() forward declarations MIPS: TXX9: Remove tx4938_spi_init() and txx9_spi_init() MIPS: kernel: proc: Use two seq_putc() calls in show_cpuinfo() commit 415125669c2ddc773c579a60df108f75712dfa83 Author: Robin Everaars Date: Mon Aug 17 14:14:17 2026 +0000 ACPI: button: Add DMI quirk for Razer Blade Pro 17 early 2020 lid switch The lid switch reports "close" but can miss the matching "open", leaving _LID closed after resume. systemd-logind then suspends the system again roughly every 35 seconds. Reading the embedded controller's PSTA byte while _LID is stale shows that bit 0x04 is set, which the DSDT treats as open. The DSDT returns the cached LIDS byte from _LID. Its wake path aborts in RTEC on an unhandled SystemCMOS region before copying PSTA to LIDS. Initialize the lid state to open on resume, matching the existing quirk for the Razer Blade Stealth 13 late 2019. With button.lid_init_state=open, a physical close suspended once and resume reported open without another suspend. Signed-off-by: Robin Everaars Link: https://patch.msgid.link/20260817141414.213075-1-robineveraars@pm.me Signed-off-by: Rafael J. Wysocki commit af33c5a2a9fd52f07ffb428255b7f060da1de49d Merge: 7199989f3f3194 f81cb44f9a4b88 Author: Linus Torvalds Date: Fri Aug 21 12:32:01 2026 -0700 Merge tag 'ecryptfs-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs Pull eCryptfs updates from Tyler Hicks: - Hardening and fixes for maliciously crafted eCryptfs metadata in the lower encrypted file - Hardening and fixes for maliciously crafted userspace <-> kernel miscdev communications - Locking fixes for userspace <-> kernel miscdev communications - Fix to display encrypted filename related mount options - Clean up address_space_operations and reduce build dependencies by moving to filemap_dirty_folio() - Get rid of an unnecessary memory allocation in the inode update path - Kernel-doc formatting corrections * tag 'ecryptfs-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs: ecryptfs: ecryptfs_kernel.h: clean up kernel-doc comments ecryptfs: use filemap_dirty_folio for address space operations ecryptfs: avoid heap allocation for inode size write ecryptfs: show filename encryption options eCryptfs: bound the packet-length peek to the user buffer ecryptfs: reject too-small tag 70 packets ecryptfs: fix tag 11 packet exact-fit size check ecryptfs: pass packet set buffer size to parser ecryptfs: hold msg ctx list lock when cleaning daemon queue ecryptfs: release message context on send failure ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet commit 7199989f3f3194d653b024ce8e79cea6b15e38b9 Merge: 614b9fb585f143 172b6a6d846356 Author: Linus Torvalds Date: Fri Aug 21 12:28:35 2026 -0700 Merge tag 'landlock-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux Pull Landlock update from Mickaël Salaün: "This improves observability with Landlock tracepoints support, which required some refactoring for dedicated domain types and common helpers shared with audit code. A LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS flag is also added to improve process-wide domain enforcement consistency. Whiteout files are now correctly handled and tested, and a few other fixes" * tag 'landlock-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux: (34 commits) landlock: Document tracepoints selftests/landlock: Add landlock_enforce_domain trace tests selftests/landlock: Add scope and ptrace tracepoint tests selftests/landlock: Add network tracepoint tests selftests/landlock: Add filesystem tracepoint tests selftests/landlock: Add trace event test infrastructure and tests landlock: Add tracepoints for ptrace and scope denials landlock: Add landlock_deny_access_fs and landlock_deny_access_net landlock: Add tracepoints for rule checking landlock: Add landlock_enforce_domain tracepoint landlock: Add create_domain and free_domain tracepoints landlock: Add landlock_add_rule_fs and landlock_add_rule_net tracepoints landlock: Add create_ruleset and free_ruleset tracepoints landlock: Consolidate access-right and scope names in a shared header landlock: Decouple the per-denial logging decision from CONFIG_AUDIT landlock: Split denial logging from audit into common framework landlock: Split struct landlock_domain from struct landlock_ruleset landlock: Move domain query functions to domain.c landlock: Prepare ruleset and domain type split samples/landlock: Add LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS to sampler ... commit 614b9fb585f143d65162f17f1a4b4ec4cbdf5794 Merge: 2be02a7c996aa7 934753d26f1ed7 Author: Linus Torvalds Date: Fri Aug 21 12:16:31 2026 -0700 Merge tag 'cifs-maintainer-switch-7.3-rc1' of https://git.manguebit.org/linux Pull cifs maintainer update from Paulo Alcantara. * tag 'cifs-maintainer-switch-7.3-rc1' of https://git.manguebit.org/linux: MAINTAINERS: Replace Steve French as CIFS maintainer commit 2be02a7c996aa733bb36e29e07715621b0de9736 Merge: 283955dfacfe9e 2da28b059e0ddc Author: Linus Torvalds Date: Fri Aug 21 12:05:10 2026 -0700 Merge tag 'for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply and reset updates from Sebastian Reichel: "Power-supply core: - Add PbAc, NiZn, RAM, and ZnAr battery chemistry types - Create LED triggers based on properties instead of device type - Provide power_supply_get_system_batteries() for usage with USB-C - Add registration init callback for race-free device setup Power-supply drivers: - new TI BQ25630 charger driver - new SG Micro sgm41542 charger driver - bq257xx: Add support for BQ25792 - max8903: add DC and USB input current-limit controls - max17042_battery: Initialize MAX17055 from battery info - sbs-battery: map newly introduced battery chemistries - drop extra error messages for IRQ request failures - lot's of driver removal race condition fixes - misc small cleanups and fixes Reset drivers: - add MCF5441x RCM power-on reason driver - misc small cleanups and fixes" * tag 'for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (115 commits) power: supply: bq27xxx: bq27z561: fix invalid AverageEnergy address power: supply: bq27xxx: bq28z610: fix invalid AverageEnergy address power: supply: bq27xxx: bq27520g4: fix REG_TTES address power: supply: max17040: synchronize work cancellation on suspend power: supply: lp8727: fix use-after-free in lp8727_release_irq() power: supply: bq256xx: drain usb_work before freeing the charger power: supply: qcom_battmgr: fix battery chemistry strncmp length power: supply: bd99954: Drop bad register fields power: supply: bd71828: Do not hide errors power: supply: bd71828: Drop duplicate power-supply property power: supply: bd71828: Fix current direction power: supply: bd71815: Fix temperature reading power: supply: add stubs for notifier registration helpers power: supply: ucs1002: fix use-after-free on remove power: supply: lp8788-charger: fix use-after-free on remove power: supply: ab8500_fg: fix use-after-free on remove power: supply: bq24257: fix use-after-free on remove power: supply: qcom_battmgr: fix use-after-free power: supply: max17040: drop incorrect I2C functionality check power: supply: charger-manager: register regulators before exposing sysfs ... commit 283955dfacfe9e4716b13aa7cd360544717f00cb Merge: f96718fc1f6142 e81250ec6b6924 Author: Linus Torvalds Date: Fri Aug 21 12:01:23 2026 -0700 Merge tag 'hsi-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi Pull HSI updates from Sebastian Reichel: - omap_ssi_core: fix missing DMA mask - misc small cleanups * tag 'hsi-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi: hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device HSI: omap_ssi: Remove redundant dev_err() HSI: nokia-modem: Remove redundant dev_err() hsi: omap_ssi: remove debugfs on port creation failure commit f96718fc1f6142038a3f836b83b12e5062576a2f Merge: 21bd0802cd3f58 35e689fb79dcba Author: Linus Torvalds Date: Fri Aug 21 11:58:08 2026 -0700 Merge tag 'mmc-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC updates from Ulf Hansson: "MMC core: - Reject invalid perdev_minors for the block device before division - Document DT fixed-layout NVMEM provider support for eMMC cards MMC host: - Convert a couple of plain text DT bindings to the yaml format - bcm2835: DMA mapping improvements - cqhci: Fix sparse warnings for endian conversions - dw_mmc: Stop and complete DMA also in busy state - dw_mmc-rockchip: Add support for the RV1106 variant - litex_mmc: Add dynamic bus width support - moxart: Propagate error for DMA completion timeout - pxamci: Remove PXA remnants for the PXA93x support - rtsx_usb_sdmmc: Avoid USB I/O in runtime autosuspend - rtsx_usb_sdmmc: Suppress false CD after init timeout - sdhci_am654: Add Judith Mendez as maintainer - sdhci-esdhc-mcf: Do not use readl()/writel() on ColdFire - sdhci-msm: Extend the DT bindings for ICE - sdhci-tegra: Add support for Tegra264/Tegra238 variants - sunxi: Add support for the Allwinner A733 variant - via-sdmmc: Clean up card detect work at remove and in probe error path" * tag 'mmc-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (35 commits) ARM: PXA: Fix build error for PXA93x dt-bindings: mmc: sunxi: add compatible string for Allwinner A733 MMC0/1/2 dt-bindings: mmc: Document fixed-layout NVMEM provider support mmc: sdhci-tegra: Add Tegra264 SoC data dt-bindings: mmc: tegra: Document Tegra264 SDHCI mmc: sdhci-tegra: Add Tegra238 SoC data dt-bindings: mmc: tegra: Document Tegra238 SDHCI mmc: omap_hsmmc: use platform_get_irq_optional for wake IRQ mmc: via-sdmmc: cancel card-detect work on remove mmc: via-sdmmc: stop card-detect handling on probe failure mmc: moxart: use platform helpers for resource and IRQ mmc: host: Remove redundant dev_err()/dev_err_probe() mmc: bcm2835: DMA mapping improvements mmc: dw_mmc: move declaration of dw_mci_pmops dt-bindings: mmc: rockchip-dw-mshc: Add RV1106 compatible mmc: rtsx_usb_sdmmc: suppress false CD after init timeout misc: rtsx_usb: avoid USB I/O in runtime autosuspend mmc: sdhci-of-dwcmshc: Log eMMC reset calls mmc: block: reject invalid perdev_minors before division mmc: sdhci-of-ma35d1: add missing MODULE_DEVICE_TABLE() ... commit 21bd0802cd3f58b656065f1be236694c40588c3a Merge: 35748ddd3b2c91 8049741ac93acd Author: Linus Torvalds Date: Fri Aug 21 11:48:54 2026 -0700 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma Pull RDMA updates from Jason Gunthorpe: "About the normal size, still a lot of AI bug fixes and so on, but some interesting new functionality too: - Assorted locking, bounds-checking, cleanup, and error-path fixes across UCMA/CMA, bng_re, bnxt_re, cxgb4, EFA, ERDMA, HFI1, HNS, ionic, iRDMA, mlx4/mlx5, RXE, SIW, SRP/SRPT, and iSER target. - netlink report for max # of supported resources - get_zeroed_page()/etc removal - Robust udata for ionic - Allow unique RDMA device names per network namespace - Completion counters and v2 admit queue support for EFA - UC QP support for MANA - Completion timestamps for ionic - Harden uverbs data validation and resource lifetime handling, fixing several core use-after-free conditions. - bnxt_re toggle-page ownership and lifetime bug fixes - dmabuf SRQ support for mlx5" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: (160 commits) RDMA/ucma: Allow path records to exactly fit the output buffer RDMA/uverbs: Guard legacy bundles without method_elm RDMA/efa: Add support for 128B admin v2 SQ entry RDMA/efa: Generalize the admin SQ RDMA/efa: Decouple admin command payload from admin header RDMA/rxe: Fix OOB in free_rd_atomic_resources() RDMA/cma: Fix WARNING in res_to_rt RDMA/cxgb4: Free debugfs on registration failure RDMA/cxgb4: Cancel reg_work before freeing device on remove RDMA/ucma: Lock the handler in ucma_set_ib_path() RDMA/ucma: Lock the handler in ucma_write_cm_event() RDMA/erdma: restrict the driver to little-endian systems RDMA/ionic: Embed counter driver data in rdma_counter allocation RDMA/ionic: Cap eq_count to the eth driver's interrupt vector budget RDMA/siw: Fix use-after-free in siw_accept() IB/isert: post the full-feature receive buffers after session registration IB/isert: delay the final Login Response until the session is registered RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ RDMA/erdma: Hold QP references for AE and CM processing RDMA/erdma: Hold CQ references when processing EQ events ... commit 35748ddd3b2c91555bd86b8cf88edc90e7317e57 Merge: 531ed942bb0df0 376a3960e5efe8 Author: Linus Torvalds Date: Fri Aug 21 11:23:20 2026 -0700 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI updates from James Bottomley: "One new driver: leapraid (similar to mpi3mr but OK'd by Broadcom). The usual suspects for driver updates (ufs, qla2xxx, smartpqi, zfcp, fnic, ibmvfc) plus a few small core updates: a fix for an uninitialized sg list pad bytes plus the removal of the dma mask check for max sectors. The big update in the sd driver is mostly code refactoring for obscure error leg handling" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (195 commits) scsi: fnic: Fix built-in NVMe/FC build scsi: fnic: Fix invalid comparison for error scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables() scsi: zfcp: Enable CONTEXT_ANALYSIS scsi: zfcp: Add __must_hold() attribute to zfcp_qdio_sbal_get() scsi: fnic: Use GFP_ATOMIC for VLAN alloc under spinlock scsi: storvsc: Support manual scans for all Hyper-V targets scsi: sd: Fix sd_done() sense handling condition scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails scsi: sd: Fix error handling in sd_probe() after large pool creation failure scsi: leapraid: Add driver documentation scsi: leapraid: Add new SCSI driver scsi: ufs: Add support for the aggregated read query opcode scsi: ufs: Use unsigned types for the BSG query scsi: ibmvfc: Fix spelling mistake "Deleteing" -> "Deleting" scsi: qla2xxx: Update version to 12.00.00.2607b2 scsi: qla2xxx: Bound i2c->length in I2C bsg handlers scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers scsi: qla2xxx: Validate BSG request_len before reading vendor_cmd[] scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak ... commit 4e15e89faac9f308baeb01f46c13a051814d2449 Author: Joe Damato Date: Wed Aug 19 16:32:11 2026 -0700 net: bnxt: ring the doorbell when SW USO exits early When a burst of packets is handed down to the driver, the driver defers the doorbell to the end by setting txr->kick_pending = 1. The normal TX path handles this, but the SW USO path can miss it if it returns early. If bnxt_sw_udp_gso_xmit runs but returns early with NETDEV_TX_BUSY and txr->kick_pending was previously set to 1, then the TX queue can stall because the driver wrote some BDs but never wrote the doorbell. The device won't know to do the TX which would generate the completion that would wake the queue back up. Simplify bnxt_sw_udp_gso_xmit to set txr->kick_pending in its success case and check the flag on return. The added check after bnxt_sw_udp_gso_xmit returns ensures that any pending doorbells are written handling both successful USO and any early returns, which prevents the TX queue stall mentioned above. This TX queue stall was observed on a production system with a netdev TX watchdog informing about the queue stall. Fixes: cc5d90667db8 ("net: bnxt: Implement software USO") Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Reviewed-by: Michael Chan Link: https://patch.msgid.link/20260819233213.3673149-1-joe@dama.to Signed-off-by: Jakub Kicinski commit 75b0a6db4300e4c2c9e97a0848deaa7acfb42fb7 Author: Hui Su Date: Thu Aug 13 23:51:33 2026 +0800 bpf: Fix percpu map update indexing with sparse CPU IDs Per-CPU array, hash, and cgroup storage map updates without BPF_F_CPU or BPF_F_ALL_CPUS use a value buffer whose per-CPU slots are packed in possible-CPU order. The buffer is sized as: round_up(value_size, 8) * num_possible_cpus() The update paths iterate over possible CPUs, but use the logical CPU ID to calculate the source offset: value + size * cpu This only works when possible CPU IDs are contiguous starting at zero. For example, with a possible CPU mask of 0,2-3, the buffer contains three slots corresponding to CPUs 0, 2, and 3. CPU2 is therefore expected to use slot 1 and CPU3 slot 2. Instead, the current code uses slots 2 and 3 respectively, causing incorrect per-CPU values and an out-of-bounds read from the update buffer for CPU3. The corresponding lookup paths already use a dense offset while iterating over possible CPUs. Do the same for the array, hash, and cgroup storage update paths, advancing the source offset once for each possible CPU. BPF_F_ALL_CPUS continues to use the same value for every CPU. Fixes: 8eb76cb03f0f ("bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu_array maps") Fixes: c6936161fd55 ("bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu_hash and lru_percpu_hash maps") Fixes: 47c79f05aa0d ("bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu_cgroup_storage maps") Signed-off-by: Hui Su Signed-off-by: Andrii Nakryiko Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260813155131.1022745-3-sh_def@163.com commit ed54bf564ac52699cf4def3d0c2125d493e756f9 Author: Hui Su Date: Fri Aug 14 00:09:00 2026 +0800 bpf: Fix BPF_F_CPU validation for sparse CPU IDs BPF_F_CPU stores the target CPU ID in the upper 32 bits of the map operation flags. bpf_map_check_op_flags() currently compares that ID with num_possible_cpus(), which is the number of possible CPUs rather than a bound on CPU IDs. On an arm64 QEMU guest with a CPU device-tree hole, the possible CPU mask was 0,2-3. A userspace program using raw bpf() syscalls creates a BPF_MAP_TYPE_PERCPU_ARRAY and performs update and lookup operations for each CPU by setting BPF_F_CPU and the CPU ID in the flags. With the old check, CPU 1 is incorrectly accepted while valid CPU 3 is rejected with -ERANGE. The CPU 1 update then reaches the per-CPU map access path and triggers: Unable to handle kernel paging request at virtual address ... pc : __pi_memcpy_generic+0x5c/0x22c lr : bpf_percpu_array_update+0x2dc/0x2e8 Call trace: __pi_memcpy_generic bpf_map_update_value map_update_elem __sys_bpf Check the CPU ID against nr_cpu_ids and cpu_possible() instead. This rejects CPU IDs outside the valid range and CPUs absent from the possible mask, while allowing valid sparse CPU IDs. Fixes: 2b421662c788 ("bpf: Introduce BPF_F_CPU and BPF_F_ALL_CPUS flags") Signed-off-by: Hui Su Signed-off-by: Andrii Nakryiko Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260813160858.1042834-3-sh_def@163.com commit 0fd298233f545f3f284068127c21f0a6e9912aff Merge: dfb8bc1d286fd9 abb5bed6f48d54 Author: Mark Brown Date: Fri Aug 21 18:08:40 2026 +0100 ASoC: tegra: Fixes for issues exposed in Linux v7.2 Jon Hunter says: Commit 4b05ccb17f92 ("regcache: Sort the local copy of an unsorted reg_defaults array") exposed an issue in the Tegra I2S and MIXER drivers and after this commit was added, this underlying issue now causes audio tests that exercise the I2S and MIXER drivers to fail. This series fixes the issue in the I2S and MIXER drivers and also fixes warning observed with the ADMAIF and MBDRC drivers that have unsorted reg_defaults. Link: https://patch.msgid.link/20260821153734.158426-1-jonathanh@nvidia.com commit abb5bed6f48d54d3b82724a430fd462579ecd876 Author: Jon Hunter Date: Fri Aug 21 16:37:34 2026 +0100 ASoC: tegra: Sort MBDRC register defaults Commit 4b05ccb17f92 ("regcache: Sort the local copy of an unsorted reg_defaults array") exposed an issue with the Tegra MBDRC driver and now the following warning is observed: tegra210-ope 2908000.processing-engine: Driver needs fixing: Unsorted reg_defaults, sorting the copy This warning occurs because register defaults in the structure tegra210_mbdrc_reg_defaults are not specified in ascending order which is required by regmap. Fix this by sorting the register defaults according to their address. Note that in order to do this it is necessary to replace the macro MBDRC_FILTER_REG_DEFAULTS with a per register macro MBDRC_FILTER_PARAM_REG_DEFAULTS. Fixes: 7358a803c778 ("ASoC: tegra: Add Tegra210 based OPE driver") Cc: stable@vger.kernel.org Signed-off-by: Jon Hunter Link: https://patch.msgid.link/20260821153734.158426-5-jonathanh@nvidia.com Signed-off-by: Mark Brown commit 18d48bfd1bc178da7cfc7a1be3eaa1c8cb10f05c Author: Jon Hunter Date: Fri Aug 21 16:37:33 2026 +0100 ASoC: tegra: Sort ADMAIF register defaults Commit 4b05ccb17f92 ("regcache: Sort the local copy of an unsorted reg_defaults array") exposed an issue in the Tegra ADMAIF driver and now the following warning is observed: tegra210-admaif 290f000.admaif: Driver needs fixing: Unsorted reg_defaults, sorting the copy This warning occurs because register defaults in the structures tegra186_admaif_reg_defaults and tegra264_admaif_reg_defaults are not specified in ascending order which is required by regmap. Fix this by sorting the register defaults according to their address. Note that in order to do this it is necessary to split the macro ADMAIF_REG_DEFAULTS into separate RX and TX macros to the RX and TX registers. Fixes: f74028e159bb ("ASoC: tegra: Add Tegra210 based ADMAIF driver") Cc: stable@vger.kernel.org Signed-off-by: Jon Hunter Link: https://patch.msgid.link/20260821153734.158426-4-jonathanh@nvidia.com Signed-off-by: Mark Brown commit 5442b8093a2f94ecd4696b3875194be09e2676c5 Author: Jon Hunter Date: Fri Aug 21 16:37:32 2026 +0100 ASoC: tegra: Fix the MIXER enable default value Commit 4b05ccb17f92 ("regcache: Sort the local copy of an unsorted reg_defaults array") exposed an issue in the Tegra MIXER driver where the register default for the TEGRA210_MIXER_ENABLE is specified as 1, but the hardware default is actually 0. After this commit was added the MIXER driver is no longer working and so fix this by correcting the default value for this register and explicitly configuring the MIXER_ENABLE register when runtime resuming the MIXER device. Fixes: 05bb3d5ec64a ("ASoC: tegra: Add Tegra210 based Mixer driver") Cc: stable@vger.kernel.org Signed-off-by: Jon Hunter Link: https://patch.msgid.link/20260821153734.158426-3-jonathanh@nvidia.com Signed-off-by: Mark Brown commit 53dd1c1de851280c71385f49a24715e5615c926c Author: Jon Hunter Date: Fri Aug 21 16:37:31 2026 +0100 ASoC: tegra: Fix the I2S enable default value Commit 4b05ccb17f92 ("regcache: Sort the local copy of an unsorted reg_defaults array") exposed an issue in the Tegra I2S driver where the register default for the TEGRA210_I2S_ENABLE is specified as 1, but the hardware default is actually 0. After this commit was added the I2S driver is no longer working and so fix this by correcting the default value for this register and explicitly configuring the I2S_ENABLE register when runtime resuming the I2S device. The I2S_ENABLE register offset is different on Tegra264 devices than other Tegra devices and so add a 'enable_reg' variable to the SoC data structure to specify the offset for different SoC devices. Fixes: c0bfa98349d1 ("ASoC: tegra: Add Tegra210 based I2S driver") Cc: stable@vger.kernel.org Signed-off-by: Jon Hunter Link: https://patch.msgid.link/20260821153734.158426-2-jonathanh@nvidia.com Signed-off-by: Mark Brown commit 531ed942bb0df04f6747983fecdedce76a22d07f Merge: 4e69c1856bfd9f d463633d63e6aa Author: Linus Torvalds Date: Fri Aug 21 09:49:54 2026 -0700 Merge tag 'fbdev-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev Pull fbdev updates from Helge Deller: "The usual bunch of many small fixes in various fbdev drivers, but more interestingly the Vodoo3/4/5 cards will now be initialized even without PC BIOS support and vintage Atari computers gain more color depths and console acceleration on SuperVidel's SuperBlitter chips. New features: - Allow Vodoo3/4/5 card to be initialized without PC-BIOS (Daniel Palmer) - Add support for SuperVidel's SuperBlitter (Miro Kropacek) - Add further video bit depths (Miro Kropacek) - Detect default graphics card for console output on sticon/parisc (Helge Deller) Fixes: - kyro: Validate overlay viewport coordinates (Danila Chernetsov) - platinumfb: add error checking for ioremap calls (BingKun Yue) - ssd1307fb: damage callback fixes (Hui Su) - maxine: fix 64-bit build error and code cleanups (Randy Dunlap) - omapfb: panel-dsi-cm: initialize lock before registering display (Runyu Xiao) - core: Clamp total_size to smem_len in read/write functions (Mingyu Wang) - uvesafb, tdxfb: failure path cleanups (Myeonghun Pak) - udlfb: validate DisplayLink vendor descriptor items before usage (Pengpeng Hou) Cleanups: - Convert multiple drivers to managed PCI and ioremap API (Shixiong Ou) - Remove redundant dev_err() from multiple drivers (Pan Chuang) - omap2: do not copy isr table (Andreas Kemnade) - pvr2fb: correct user pointer annotation and sentinel initializer (Florian Fuchs) - mb862xxfb: silence possibly unused functions (Helge Deller) - au1100fb: drop unneeded semicolon (Julia Lawall) - clps711x-fb: remove unreachable code (Karl Mehltretter) - viafb: refactor strcpy call (Ajith P V) - sstfb: add missing MODULE_DEVICE_TABLE() (Pengpeng Hou) - mb862xx: replace dead Kconfig select with dependency (Julian Braha) Documentation fixes: - fonts: fixup font.h kernel-doc warnings (Randy Dunlap)" * tag 'fbdev-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev: (43 commits) fbdev: atafb: Add support for SuperVidel's SuperBlitter fbdev: atafb: Add support for further video bit depths on atafb:external fbdev: atafb: Give atafb proper parent fbdev: omapfb: panel-dsi-cm: initialize lock before registering display fbdev: viafb: refactor strcpy and viafb_name fbdev: platinumfb: add error checking for ioremap calls fbdev: maxine: use MODULE_LICENSE() unconditionally fbdev: maxine: fix maxinefb_init() return value fbdev: maxine: fix 64-bit build error fbdev: maxine: elide an unused function fbdev: maxine: make functions static fbdev: atyfb: Convert to managed PCI and ioremap API fbdev: matrox: Convert to managed PCI and ioremap API fbdev: savage: Convert to managed PCI and ioremap API fbdev: nvidia: Convert to managed PCI and ioremap API fbdev: aty128fb: Convert to managed PCI and ioremap API fbdev: clps711x-fb: Remove unreachable unregister_framebuffer() call fbdev: mb862xxfb: Silence possibly unused functions sticon/parisc: Detect default STI graphics card for console output fbdev: ssd1307fb: defer I2C transfers from damage callbacks ... commit 4e69c1856bfd9ffb7e9d335a25842fa211628929 Merge: 818bebeb63dd6b c44e278ce02efd Author: Linus Torvalds Date: Fri Aug 21 08:41:00 2026 -0700 Merge tag 'drm-next-2026-08-20' of https://gitlab.freedesktop.org/drm/kernel Pull drm updates from Dave Airlie: "Highlights: - dmemcg eviction support is good for low VRAM things like Steam Machine - AMD adds gfx6-8 modifier support for older GPUs that enables a bunch of wayland stuff - i915/xe has some new hw support but also a lot of display refactoring Everything: perf: - export perf_allow_ APIs for xe udmabuf: - remove default size limit of 64MB rust: - i/o rework (signed tag from driver-core tree) - add registration guard and registration data - fix unbounded lifetimes in ioctl handler args - fix a drm_dev_register race - gem_shmem: add DmaResvGuard helper - gpuvm: require send/sync for driver data - implement send/sync for GpuVaAlloc and GpuVmBo - add SmContext lifetime - rename dma_handle to dma_address - change pci_sriov_get_totalvfs return to unsigned int core: - create drm_of_get_panel_orientation - send per-connector hotplug events - add thunderbolt UBHR tunneling support connector: - add color format property dmem: - introduce a peak file - accept one region per limit - add dmemcg support for eviction gpusvm: - reorg code to give drivers more flexibility atomic: - add create_state callback and helper - add documentation on atomic commit lifetime buddy: - add per-order free - add used block scoreboard - fix UAF - test buffer clearance on resume - add phys_addr->block helper gem: - drop DRIVER_GEM_GPUVA flag ttm: - be more aggressive allocating below protection limit sched: - add test suite for concurrent job submissions hdmi: - hook the color format property in helpers mipi-dsi: - add MIPI_DSI_MODE_DSC_ALL_SLICES_IN_PKT bridge: - add atomic create callbacks - drop atomic reset - display-connector: don't autoenable HPD IRQ - trigger initial HPD for DP - ti-sn65dsi83: remove NO_HFP and NO_HBP mode flags - analogix_dp: switch to DP link training helpers dp: - add support for DSC max delta BPP edid: - parse panel type from DisplayID 2.x Display Parameters sysfb: - improve panel, stride, framebuffer size validation panel: - implement ref counting for struct drm_panel - himax-hx83121a: add backlight regulator support - novatek-nt36672a: Inline panel init sequences - visionox-vtdr6130: enable DSC - novatek-nt37801: Use mipi_dsi_*_multi() functions - samsung-s6d16d0: Fix prepare error handling - support Novatek NT36536 plus DT bindings - sofef00: fix backlight updates - osd101t2587: use mipi_dsi_*_multi interface - panel-edp: adjust timing for AUO displays - panel-lvds: support Opto Logic SCX1001511GGC49 - panel-simple: support Kyocera tcg070wvlq - panel-edp: quirks - AUO B116XAT04.3, CMN N116BCP-EA2, CSW MNB601LS1-8 - BOE NV116WH2-M30, BOE NT116WHM-N21, BOE NV116FH1-M31 - BOE NV116FH1-M30, NV140FHM-N5B, TM156VDXP25 - BOE NE160QDM-NY1, MB116AS01 - new: - Samsung ATNA40HQ08-0, Anbernic TD4310 - Chipone ICNA35XX, Ilitek ILI9488 - Ilitek ILI7807S, Renesas R63419 - MNE001BS6-2, MNF601BS4-1, Sharp LQ120P1JX51 virtio: - add support for save/restore virtio_gpu_objects - abort vq wait on device removal amdgpu: - add color format DRM property - initial compute pipe reset support - add GFX 6-8 modifier support - initial DCN 6.0.0 support - dmemcg eviction support - improved boundary checking for bios parsing - RAS updates and rework - VCN secure submission fixes - 8K panel fix - Display KUNIT tests - parse panel type from DisplayID - Align IP discovery to pci device lifetime - SOC15 register macro cleanups - UVD memory placement fixes - GFX9 mode2 reset fixes - drop unnecessary BUG/BUG_ON - GFX8 soft reset rework - enable soft reset on GFX8 - PSP/SMU 15.0.9 update - VI ASPM fix - userq fixes - amdgpu_vm_get_task_info_pasid lifetime fix - DC CACP support - change system_unbound_wq with system_dfl_wq - Loosen VFCT bios parsing to deal with pci=realloc - SI/SMU7 AC/DC switch fix - VM fence handling fix - GEM close optimisation - Apple Studio Display fixes - DC FRL fixes amdkfd: - initial compute pipe reset support - allow applications to opt out of sigbus on fatal errors - improve CRIU boundary checks - MQD handling rework - move TBA/TMA from system to device memory - avoid topology-lock in kfd_mmap - SVM eviction fixes radeon: - fix unset CONFIG_ACPI build i915: - Novalake (NVL display version 35) timing generator enabling - NVL DC3CO enabling - enable UBHR link rates on thunderbolt tunnels - Reduce Xe3+ PM demand peak bandwidth - enable pipe DMC error interrupts for display 30+ - add kunit tests for DP link config selection - refactor and document DP link recovery - i915/xe driver display probe/remove/suspend/resume/shutdown cleanup and unification - i915/xe display runtime PM unified - Break i915 and xe panic dependency on struct intel_framebuffer - Streamline Pre/Post-CSC LUT loops - drop TGL DC3DO support - CDCLK santization - fix HDMI scrambling enable - fix phys bo pread/pwrite with offset - add missing nospec on parallel submit slot - fix some NULL derefs xe: - drop force_execlist module param - gate observation streams with perf_allow_cpu - skip FORCE_WC and vm_bound check for external dma-bufs - dmemcg eviction support - remove unused NVL-S GuC - TLB invalidation improvements - NVL-S updated PCI-IDs and w/a - madvise: optimise invalidation path - fix infinite gt-reset loop in timeout recovery - update TTM device benefical_order - wait on external BO kernel fences in exec ioctl - add/use more KLV helpers - sriov: disable display in admin only PF mode - add RAS GPU health indicator - optimise TTM populate for DONTNEED BO - drop force_probe for NVL-s - add debugfs for pcode info amdxdna: - disable device buffer export nova: - build nova-core/nova-drm from drivers/gpu - export nova-core rust symbols (workaround) - GSP boot process consolidation - Boot GSP with vGPU enabled - TLV firmware image format support - Hopper/Blackwell fixes and cleanups - I/O projection adoption tyr: - firmware loading and MCU boot - add generic slot manager + MMU - GPU VM support ARM64 LPAE page tables - add kernel buffer object for internal allocations - add parser for Mali CSF - add MCU booting nouveau: - race fixes - check instmem iomapping at first use - add dmemcg support - expose NVDEC channels - add scanline position/head state support for GSP qxl: - convert simple encoder to regular ethosu: - add perf counter support etnaviv: - force flush on power register ops msm: - support DSC configuration with slice_per_pkt > 1 mxsfb: - fix disable sequence panthor: - support sparse mappings rockchip: - switch away from simple helpers - support YUV background color - fix layer config timeout - add edp support for rk3576 - add batch command submission function rocket: - error handling and NULL ptr deref fixes sun4i: - switch away from simple helpers imagination: - mark BXM-4-64 MC1 as support host1x: - support tegra264 tegra: - add DSI for tegra 20/30 v3d: - reduce PM runtime autosuspend delay - scheduler fixes and refactoring - deprecate v3d 3.3 and 4.1 - validate CPU job query boundaries hibmc: - improve plane format handling - switch to gem shmem mediatek: - cec: correct compat for mt7623-8167? exynos: - remove simple dependency - add error handling to encoder paths - take i2c adapter module reference" * tag 'drm-next-2026-08-20' of https://gitlab.freedesktop.org/drm/kernel: (2074 commits) drm/xe/mcr: Take vcs1/vecs1 into account for first media slice drm/xe: Fix a bug in pc_adjust_freq_bounds() drm/xe: Fix xe_device_probe() failure drm/xe/drm_ras: Move has_drm_ras check to drm_ras layer drm/xe/ras: Fix boot-time ras error processing drm/amd/display: make DC_RUN_WITH_PREEMPTION_ENABLED misuse a build error drm/amd/pm: silence uninitialized variable warnings drm/amdgpu: skip BOs being torn down during GTT recovery drm/amdgpu: Reject UVD message with invalid number of h265 refs drm/amdgpu: keep PRT mappings off the vm_bo state lists drm/amdgpu: fix nbif 6.3.1 l1 low power not functional drm/amd/display: fix BT.2020 YCbCr output CSC matrices for DCE drm/amd/display: fix BT.2020 YCbCr limited output CSC matrix drm/amdgpu: Implement insert_end for VCE 3 drm/amdgpu: Fix UVD min buffer sizes drm/amdgpu: Fix UVD decode image min size calculation drm/amdgpu: Fix UVD dpb min size calculation for H264 drm/amdgpu: Reject UVD message with dimensions above 4096 drm/amdgpu: check ASPM on the dGPU host link drm/radeon: fix autosuspend cleanup during teardown ... commit 7617cc05df28dcae967cca109de74084321eaa62 Author: Rafael J. Wysocki Date: Thu Aug 20 21:11:14 2026 +0200 ACPI: scan: Do not combine resources that overlap completely Commit f234fdaae1ca ("ACPI: scan: Avoid registering platform devices with resource overlaps") attempted to avoid platform device registration errors due to overlaps of resources of the same type returned by the same _CRS object in the ACPI tables. It did that by combining two or more overlapping resources into one, but it went too far and also caused resources that overlap completely to be combined which broke the arm-cmn driver that expects two MMIO resources to be present for each device it binds to and it expects those two resources to overlap completely. Address this issue by adding checks for completely overlapping resources to acpi_platform_adjust_resources() and add a comment explaining what is done there. Fixes: f234fdaae1ca ("ACPI: scan: Avoid registering platform devices with resource overlaps") Reported-by: Nathan Chancellor Tested-by: Nathan Chancellor Closes: https://lore.kernel.org/linux-acpi/20260819003752.GA3063251@ax162/ Signed-off-by: Rafael J. Wysocki Reviewed-by: Jarkko Sakkinen Link: https://patch.msgid.link/12955564.O9o76ZdvQC@rafael.j.wysocki commit d0ad81b2b5feea2e8b08a529c0e0d1fbaca98333 Author: Jiri Kosina Date: Fri Aug 21 15:39:15 2026 +0200 HID: hyperv: make pointer arithmetics understandable for FORTIFY_SOURCE Commit 83df7b5fa6735b5084ecd2 ("HID: hyperv: add KUnit coverage for device info bounds") introduced this piece of code report = ((u8 *)&info->hid_descriptor) + info->hid_descriptor.bLength; memset(report, 0x42, 4); to populate the report, making use of the fact that the report &info->hid_descriptor points to a struct hid_descriptor (which is a fixed-size struct). GCC's FORTIFY_SOURCE infer the object size from that specific struct field rather than the outer dynamically allocated info buffer. As a result, writing past sizeof(struct hid_descriptor) triggers the __write_overflow_field warning. Calculate the pointer offset using info directly, so the compiler evaluates the memory bounds against the allocated flexible layout of struct synthhid_device_info instead of the nested struct. Fixes: 83df7b5fa6735b5084ecd2 ("HID: hyperv: add KUnit coverage for device info bounds") Reported-by: Jürgen Groß Tested-by: Jürgen Groß Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina commit 78acddfde75177a27000f076e3e828743e38877e Author: Cosmo Chou Date: Sat Jul 18 03:37:05 2026 +0800 rtc: pcf85363: Add error checking to regmap calls in probe() The probe() function ignores errors returned by regmap operations. If an I2C transport error occurs (e.g., -ENXIO), the driver continues probing and may register a non-functional RTC device. Propagate errors from all unchecked regmap calls in probe() using dev_err_probe(). Fixes: fd9a6a13949a ("rtc: pcf85363: add support for the quartz-load-femtofarads property") Signed-off-by: Cosmo Chou Link: https://lore.kernel.org/linux-rtc/20260716125142.1801599-1-chou.cosmo@gmail.com/ Link: https://patch.msgid.link/20260717193705.2003175-1-chou.cosmo@gmail.com Signed-off-by: Alexandre Belloni commit 445fcd33c501be4be41806715f5b7ec80200f9f7 Author: Jiri Kosina Date: Fri Aug 21 11:29:51 2026 +0200 HID: hyperv: fix build breakage with certain configs If CONFIG_HID_HYPERV is built-in (=y) while CONFIG_KUNIT is built as a module (=m), the linker fails to resolve kunit_mem_assert_format when creating vmlinux. Fix the dependencies in Kconfig. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202608190536.d9qCkWWc-lkp@intel.com/ Fixes: 83df7b5fa6735b5084ecd2 ("HID: hyperv: add KUnit coverage for device info bounds") Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina commit 82e9343260dfc6dda6349f285d9a5eac3e0738d7 Author: Jérémy Jean Date: Fri Aug 14 10:20:05 2026 +0000 nsfs: keep namespace tree fields stable until after RCU grace period struct ns_common overlays struct ns_tree with the rcu_head used by kfree_rcu(). That lets the deferred-free machinery overwrite ns_id and __ns_ref_active as soon as a namespace is queued for freeing, even though nsfs tree walkers may still read those fields under RCU after ns_tree_remove(). KASAN reports slab UAF. Keep the tree state and deferred-free callback storage separate. Namespace tree readers can then continue to validate and take references until the grace period has elapsed. Signed-off-by: Jérémy Jean Link: https://patch.msgid.link/20260814102005.1939777-1-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Christian Brauner (Amutable) commit 0ecd56573c1f272c72298154a3854380876dbb7c Author: Jan Kara Date: Tue Aug 4 12:41:13 2026 +0200 ext4: Avoid entering writeback paths during fastcommit replay Fastcommit replay effectively happens in nojournal mode. This results in ext4_mark_iloc_dirty() setting I_METADATA_WRITEBACK flag and as a result we end up entering filesystem writeback functions. However during fastcommit replay s_writepages_rwsem isn't initialized yet and hence we crash. Fix the problem by avoiding setting I_METADATA_WRITEBACK during fastcommit replay. Journal replay flushes the whole block device after replay anyway so all metadata is properly persisted and replay is faster this way as a bonus. Fixes: c26339e1df33 ("ext4: Fix data integrity writeout issues in nojournal mode") Reported-by: Venkat Rao Bagalkote Reported-by: Ojaswin Mujoo Signed-off-by: Jan Kara Link: https://patch.msgid.link/20260804104112.93202-2-jack@suse.cz Tested-by: Venkat Rao Bagalkote Reviewed-by: Ojaswin Mujoo Signed-off-by: Christian Brauner (Amutable) commit a7b842f182d126a07838d81be8201d8d953c67c0 Author: Hyunchul Lee Date: Fri Aug 21 14:00:59 2026 +0900 ntfs: support resident WOF decompression Extend WOF decompression to support files where the reparse named data attribute or the compressed chunks themselves are resident. Retrieve resident metadata using ntfs_attr_lookup() and copy compressed chunks directly from the resident attribute payload. Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 2bef615ebf2884f33036123ada4dc00c0f54904d Author: Hyunchul Lee Date: Fri Aug 21 14:00:58 2026 +0900 ntfs: add non-resident WOF decompression Introduce non-resident Windows System Compression (WOF) decompression support. Add wof.c containing parse_wof_chunk_table() and ntfs_read_wof_compressed_block(), and routing them via transparent codec ops table with dynamic scratch memory allocation. Hook up ntfs_readpage/read_folio paths in aops.c to delegate to the WOF block reader when NInoWofCompressed is set. Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 7ddb3fef353231adcaba2c6c891463226e9c199f Author: Hyunchul Lee Date: Fri Aug 21 14:00:57 2026 +0900 ntfs: implement codec ops for LZX and XPRESS Implement the transparent compression codec ops for XPRESS (4K, 8K, 16K) and LZX (32K) algorithms. The xpress_scratch_size, lzx_scratch_size, xpress_decompress_chunk, and lzx_decompress_chunk wrappers provide unified interfaces and use per-call dynamic scratch state allocation (avoiding global mutexed singletons). Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit f39cd3f7fcafe2681f7d1fe916748f3e42be0c4c Author: Hyunchul Lee Date: Fri Aug 21 14:00:56 2026 +0900 ntfs: port lzx/xpress decompressors from ntfs-3g-system-compression Port the LZX and XPRESS decompressors from the userspace ntfs-3g-system-compression plugin (Eric Biggers, https://github.com/ebiggers/ntfs-3g-system-compression) into the in-tree NTFS driver under lib/, and adapt them to the kernel environment. The upstream plugin implements WOF ("Windows Overlay Filesystem", a.k.a. system compression / "Compact OS") decompression for the NTFS-3G FUSE driver, and itself borrows the LZX/XPRESS decompressors that the same author wrote for wimlib (https://wimlib.net/). The XPRESS and LZX formats used here are identical to those used in WIM archives. This commit is the kernel-side port that lets fs/ntfs/wof.c read system-compressed files. The library keeps the upstream subtable-based Huffman decoder (root table + contiguous subtables decoded with MAKE_DECODE_TABLE_ENTRY()), so long codewords only need one extra lookup instead of bit-by-bit tree traversal. The ntfs_codec_ops interface exported to fs/ntfs/wof.c (ntfs_lzx32k_codec_ops and ntfs_xpress{4k,8k,16k}_codec_ops) matches what the WOF layer expects. Modifications made while porting from the upstream plugin: - Replace the variable LZX window order (2^15..2^21) with a fixed 32768-byte window, which is the only size WOF uses - Simplify the bitstream helper: - bitstream_ensure_bits() now guarantees 16 valid bits instead of the carried-over 17-bit refill path from wimlib. Neither LZX (max codeword length 16) nor XPRESS (max 15) needs more than 16 bits. - Refactor codes to satisfy checkpatch. Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit d7aa04984f1280efc476dbe25d6cad1c000dcfaf Author: Hyunchul Lee Date: Fri Aug 21 14:00:55 2026 +0900 ntfs: return errors from inode initialization ntfs_iget() previously converted only -ENOMEM from ntfs_read_locked_inode() into an ERR_PTR(). Other initialization errors left the inode on the normal return path after it had been unlocked. Return every non-zero initialization error after releasing the inode reference. Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 760c9d271d40beae9c7f41769b89cb963173e36d Author: Hyunchul Lee Date: Fri Aug 21 14:00:54 2026 +0900 ntfs: parse REPARSE_TAG_WOF Introduce parsing support for REPARSE_TAG_WOF reparse points. Rename ntfs_make_symlink() to ntfs_parse_reparse() since it now handles both symlinks and WOF reparse tags. Introduce NI_WofCompressed flag to indicate files compressed via Windows System Compression (WOF), and configure compressed block size accordingly (12 to 15 bits based on the format). Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 56cc42a7b3878ad1450d04713beabeb3e7447b14 Author: Hyunchul Lee Date: Fri Aug 21 14:00:53 2026 +0900 ntfs: return errors from ntfs_attr_readall ntfs_attr_readall() currently loses the failure reason for attribute lookup, allocation, and read failures by returning NULL. Return ERR_PTR() with the original error instead. The reparse parser can then propagate allocation and I/O errors without treating them as filesystem corruption. Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit d38ce59d16d53194cf184baa822d5f2ad528b92e Author: Hyunchul Lee Date: Fri Aug 21 14:00:52 2026 +0900 ntfs: add WOF compression config option Add CONFIG_NTFS_FS_WOF_COMPRESSION for Windows system compression. Build XPRESS and LZX decoding code only when requested. Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit c34e33a60fc7c410f15d265d80959b546088c10f Author: Hyunchul Lee Date: Fri Aug 21 14:00:51 2026 +0900 ntfs: define LZNT1 codec ops under transparent codec interface Define the ntfs_lznt1_codec_ops structure containing decompress_pages and compress_subblock callbacks in compress.c, and export it in ntfs_codec.h. This structure binds existing LZNT1 decompress and compress helper functions under the unified transparent compression interface. Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit f2240a2ff4db3a63c8740a9074ad98cb13d9b83b Author: Hyunchul Lee Date: Fri Aug 21 14:00:50 2026 +0900 ntfs: introduce transparent compression codec interface Introduce struct ntfs_codec_ops and enum ntfs_codec_id to provide a unified interface for compression and decompression algorithms. This interface supports WOF and LZNT1 decompression. Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 412f89fb3988a344175899776c8bc7073524ad84 Author: Carlos Maiolino Date: Tue Aug 4 11:45:55 2026 +0200 capability: unexport has_capability_noaudit This has been originally exported to be used in xfs. Giving we are not using it anymore, unexport for consistency. Signed-off-by: Carlos Maiolino Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Serge Hallyn Signed-off-by: Carlos Maiolino commit be9c45bdb19461889b16c91c185a284d665ea72d Author: Carlos Maiolino Date: Tue Aug 4 11:45:54 2026 +0200 xfs: replace ns_capable_noaudit Now that capable_noaudit() is available, we don't need to keep using ns_capable_noaudit() and specifying the usernamespace every single time. Signed-off-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 4642259374fc9eb99af4cf8b2d54d54ccb0de08e Author: Carlos Maiolino Date: Tue Aug 4 11:45:53 2026 +0200 quota: Don't issue audit messages on quota enforcing Calling capable() to determine if we can bypass quota enforcement or not can trigger spurious audit messages. We don't really require it here so just use the capable_noaudit() version. Signed-off-by: Carlos Maiolino Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Acked-by: Jan Kara Signed-off-by: Carlos Maiolino commit 1b91724d0bdc470ed8f353d1cc8d3e4123b51ed5 Author: Carlos Maiolino Date: Tue Aug 4 11:45:52 2026 +0200 capability: Add new capable_noaudit In some situations (quota enforcement bypass in this case) we'd like to check for a specific capability without triggering spurious audit messages from security modules like selinux. Add a new helper so we don't need to use ns_capable_noaudit() directly. Signed-off-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Reviewed-by: Serge Hallyn Signed-off-by: Carlos Maiolino commit e2f62a9744ebad3bcb6347a648e615026e9efeff Author: Carlos Maiolino Date: Tue Aug 4 11:45:51 2026 +0200 xfs: fix capability check in xfs An user reported a bug where he managed to evade group's quota by changing a file's gid to a different group id the same user belonged to, even though quotas were enforced on both gids and the file's size was big enough to exceed the quota's hardlimit. Commit eba0549bc7d1 replaced a capable() call by a has_capability_noaudit() to prevent unnecessary selinux audit messages. Turns out that both calls have slightly different semantics even though their documentation seems similar. Where in a nutshell: capable() - Tests the task's effective credentials has_ns_capability_noaudit() - Tests the task's real credentials This most of the time has no practical difference but in some cases like changing attrs (specifically group id in this case) through a NFS client this will allow the quota code to use XFS_QMOPT_FORCE_RES, effectively bypassing quota accounting checks. Using instead ns_capable_noaudit() should fix this issue and prevent selinux audit messages. This also fix the remaining calls to has_capability_noaudit() Fixes: eba0549bc7d1 ("xfs: don't generate selinux audit messages for capability testing") Cc: stable@vger.kernel.org # v5.18 Reported-by: Dr. Thomas Orgis Signed-off-by: Carlos Maiolino Reviewed-by: Darrick J. Wong Reviewed-by: Serge Hallyn Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 885435535bb1d07746916d4c8832f95767bf2d7e Author: Christoph Hellwig Date: Thu Aug 13 16:56:12 2026 +0200 xfs: restore bi_bdev in xfs_zone_gc_write_chunk xfs_zone_gc_write_chunk relies on bi_bdev to still be valid, which is not true when XFS is used on top of a stacked block device. This can lead to misdirected GC writes, writing of plain text when using dm-crypt, or miscalculated I/O limits in xfs_zone_gc_split_write. Fix this by reassigning bi_bdev. Fixes: 080d01c41d44 ("xfs: implement zoned garbage collection") Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino commit 6b855256eb9e652caf8b14eb1f69b6eb00a9d9d1 Author: Christoph Hellwig Date: Tue Aug 11 10:48:41 2026 -0600 xfs: split ioend handling into a separate source file The ioend handling used to be only for buffered writeback, but has been extended to direct I/O and reads. Split it into a new source file. Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Reviewed-by: Hans Holmberg Reviewed-by: Damien Le Moal Signed-off-by: Carlos Maiolino commit 0510346e8e308d2e2cb057ea7b408758b5d6f6cd Author: Christoph Hellwig Date: Tue Aug 11 10:48:40 2026 -0600 xfs: factor out a xfs_iomap_set_anon_write helper De-duplicate the iomap setup for zoned writes. Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Reviewed-by: Hans Holmberg Reviewed-by: Damien Le Moal Signed-off-by: Carlos Maiolino commit 4bc67fc800edcaae8a657e4d2fba12e64e856b9f Author: Christoph Hellwig Date: Tue Aug 11 10:48:39 2026 -0600 xfs: fix zoned write iomap flags assignments Don't overwrite IOMAP_F_DIRTY with IOMAP_F_ANON_WRITE, but ensure both flags are set instead. Note that in practice this is harmless as all zoned writes force a metadata transaction anyway, but incorrectly assigned flags are still a landmine that will cause problems at some point. Fixes: 058dd70c65ab ("xfs: implement buffered writes to zoned RT devices") Fixes: 2e2383405824 ("xfs: implement direct writes to zoned RT devices") Cc: stable@vger.kernel.org # v6.15 Signed-off-by: Christoph Hellwig Reviewed-by: Andrey Albershteyn Reviewed-by: Darrick J. Wong Reviewed-by: Hans Holmberg Reviewed-by: Damien Le Moal Signed-off-by: Carlos Maiolino commit 2d829cc76777a5335269768d7caa750e102f74d2 Author: Christoph Hellwig Date: Tue Aug 11 10:48:38 2026 -0600 xfs: fix racy open zone caching When testing on very fast storage devices, I've observed writers using io_uring creating many open zones with just a few kiB written to it, which then don't get used. I tracked this down to multiple io_uring helper threads finding a full zone in i_private, and then going on to select a one, with the final one winning the race and leaving it in i_private. Fix this by dropping full zones from i_private as soon we find them, checking cached for a cached zoned when a single writes needs a new zone, and by keeping an existing cached zone in xfs_set_cached_zone when it still has space available, dropping the newly found/allocated one instead. This uses i_flags_lock as a low-level spinlock for short hold times to avoid interactions with the ilock, which is used for completions. Signed-off-by: Christoph Hellwig Reviewed-by: Hans Holmberg Reviewed-by: Darrick J. Wong Reviewed-by: Damien Le Moal Signed-off-by: Carlos Maiolino commit ae285611891f8d1a691771d14ecb5c9de3319abf Author: Christoph Hellwig Date: Tue Aug 11 10:48:37 2026 -0600 xfs: handle NULL open_zone for merged ioends in xfs_ioend_put_open_zones In theory we could fail multiple ioends before an open zone was assigned to them, and the iomap code could merge them. Check for NULL not only for the main ioend but also all merged ones on ->io_list to handle this case. Fixes: 058dd70c65ab ("xfs: implement buffered writes to zoned RT devices") Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Reviewed-by: Hans Holmberg Reviewed-by: Damien Le Moal Signed-off-by: Carlos Maiolino commit 4e07cd78e159a8c6b028e5dc5f4e5bf06067d969 Author: Christoph Hellwig Date: Mon Aug 10 08:38:38 2026 -0700 xfs: use inode_init_always_gfp with __GFP_NOFAIL in xfs_inode_alloc Just like the inode allocation itself, allocation of the security data inside of inode_init_always(_gfp) must not fail here as we can be inside an already dirty transaction context. Note that we do not have to pass GFP_NOFS explicitly as we are already in a nofs context when in a transaction, as seen by the call to alloc_inode_sb. Also update the comment about this a bit to be more clear. Fixes: bf904248a2ad ("[XFS] Combine the XFS and Linux inodes") Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino commit 750a361bfc8a8c8178872f2aecb7507a6fbf41a4 Author: Tal Zussman Date: Fri Aug 7 06:58:51 2026 -0400 xfs: remove kmem_to_page() kmem_to_page() has been unused since commit 5ced480d4886 ("xfs: simplify building the bio in xlog_write_iclog"), so remove it. This also removes the last instance of 'struct page' in fs/xfs/. Signed-off-by: Tal Zussman Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 7fc296b379edc0fef83890097af3c9537fbf4364 Author: Christoph Hellwig Date: Mon Jul 20 16:09:21 2026 +0200 xfs: don't flush and invalidate internal RT device twice in xfs_shutdown_devices Check for an internal RT device to remove a bit of extra work. Fixes: bdc03eb5f98f ("xfs: allow internal RT devices for zoned mode") Signed-off-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit b9b541e70d465a8c9cadf697eec7cb15b6653e7d Author: Christoph Hellwig Date: Mon Jul 20 11:36:12 2026 +0200 xfs: split an assert in xfs_trans_log_buf Split the "irst <= last && last < BBTOB(bp->b_length)" assert into two to make it clear which condition fired. Signed-off-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino commit 41a28c865d1d5843f8cb9e0af17a8f4d9e2961ff Author: Yun Zhou Date: Fri Jul 31 11:10:10 2026 +0800 xfs: don't hold buffer locks across sync transaction commit in xfs_sync_sb_buf xfs_sync_sb_buf() holds sb/rtsb buffer locks across a synchronous xfs_trans_commit(), which flushes the CIL push workqueue internally. If shutdown occurs during the CIL push, xfs_buf_item_unpin() needs to lock these buffers to fail them, causing a deadlock: setlabel: holds buf lock -> flush_workqueue(xfs-cil) CIL push worker: xfs_buf_item_unpin -> xfs_buf_lock(same buf) Remove the xfs_trans_bhold() calls so that commit releases the buffer locks normally. After the sync commit, re-acquire the buffers via mp->m_sb_bp / mp->m_rtsb_bp for the on-disk writeback. Fixes: f7664b31975b ("xfs: implement online get/set fs label") Reported-by: syzbot+837bcd54843dd6262f2f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=837bcd54843dd6262f2f Cc: stable@vger.kernel.org Signed-off-by: Yun Zhou Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino commit 818bebeb63dd6bf5f4e07e145f6cdbace520a34c Author: Linus Torvalds Date: Thu Aug 20 20:12:39 2026 -0700 drm/xe: Don't hand out the flat CCS storage as usable VRAM get_flat_ccs_offset() reads the base of the flat CCS storage from the hardware, scales it by the number of enabled L3 nodes, and rounds the result up to 128K. Everything below that offset is then handed to the VRAM allocator as usable memory. Rounding a limit that means "usable memory ends here" upwards publishes whatever lies between the real base and the rounded one as free memory, and that memory belongs to the compression hardware. The scaled value has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it is not: flat CCS base: raw 0x3fafff800, rounded 0x3fb000000 so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator's pool. Whatever is allocated there gets that tail overwritten by the compression hardware, which needs no page-table entry, no buffer object and no GPU submission to do it, and does it before userspace exists. On this machine a Mesa VM's level-3 page table landed on that page on every cold boot. It lost the entry covering the compositor's batch-buffer heap, so the compositor's first submission faulted fetching its batch and gdm restarted it forever: a black screen on an otherwise working machine. Restarting gdm cleared it because the next VM's page tables were allocated somewhere else. Round down instead, to the page size the allocator works in. On this machine that excludes exactly one page. Reading the reserved page afterwards shows what had been writing it: [369] 0xcccc000000000000 [371] 0xcc77000000000000 [373] 0xcccc000000000000 [375] 0xcc77000000000000 compression metadata, two bytes per sixteen, sitting where the driver used to hand out memory. The assertion that should have caught this compares the offset against GSMBASE - ccs_size for equality. That value is 128K aligned, so it agrees with the rounded-up offset precisely when the base is not aligned - the check cannot fail in the case it exists to catch, and is compiled out unless CONFIG_DRM_XE_DEBUG is set. Replace it with one that can fail: CCS storage must not run into GSM. [ And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work. I'd like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it. I suspect those things have been trained by people who may not be quite as stubborn as I am. But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above. This is basically a one-liner fixing a bogus "round_up()" to a "round_down()", but there were 24 patches adding more and more debug information to this, and 18 kernel boot to finally narrow it down to this. - Linus ] Fixes: 37173392741c ("drm/xe/vram: fix ccs offset calculation") Cc: stable@kernel.org Signed-off-by: Linus Torvalds commit 8dbbc7e188949b6e1f6be4e82a44dd1d8b1d6c8b Merge: ed3b875bea55a3 aedf2efd18977e Author: Linus Torvalds Date: Thu Aug 20 20:05:59 2026 -0700 Merge tag 'mm-hotfixes-stable-2026-08-19-21-33' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull hotfixes from Andrew Morton: "8 hotfixes. 5 are cc:stable. 5 are for MM. All are singletons, please see their changelogs for details" * tag 'mm-hotfixes-stable-2026-08-19-21-33' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/pagewalk: fix stale walk->action escaping walk_pmd_range() mm, swap: don't free a hibernation slot that is in the swap cache mm: memcg-v1: fix memsw and TCP failcnt accounting mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() mailmap: add entries for Guodong Xu MAINTAINERS, mailmap: update email address for JP Kobryn MAINTAINERS: remove git URL for Squashfs memcg: keep folio's objcg same as its node commit 5e2d672280d97d83de43031d93761b12dadd7b8a Author: Chengfeng Ye Date: Tue Aug 11 02:56:03 2026 +0300 KEYS: trusted: Fix TPM teardown ordering trusted_tpm_exit() drops the TPM chip reference and frees the digest array before unregistering the trusted key type. key_type_lookup() holds key_types_sem for reading until the key operation finishes, while unregister_key_type() takes it for writing. It therefore provides the synchronization point that must precede backend teardown. The current order permits this interleaving: CPU 0 CPU 1 trusted_tpm_exit() key_type_lookup("trusted") put_device(&chip->dev) trusted_tpm_seal() kfree(digests) pcrlock() unregister_key_type() tpm_pcr_extend(..., digests) CPU 1 can consequently dereference the freed digest array. The chip can also be released before callbacks stop using it. KASAN reported: BUG: KASAN: slab-use-after-free in tpm_pcr_extend+0x1f0/0x200 Read of size 2 at addr ffff88810872d000 by task poc/89 Call Trace: tpm_pcr_extend+0x1f0/0x200 pcrlock+0x42/0x70 [trusted] trusted_tpm_seal+0x1b6/0x570 [trusted] trusted_instantiate+0x293/0x340 [trusted] __key_instantiate_and_link+0xb2/0x2b0 __key_create_or_update+0x61e/0xb50 __do_sys_add_key+0x1b8/0x310 Allocated by task 88: __kmalloc_noprof+0x1a7/0x490 do_one_initcall+0xa1/0x390 do_init_module+0x2df/0x840 Freed by task 90: kfree+0x131/0x3c0 trusted_tpm_exit+0x59/0xa0 [trusted] __do_sys_delete_module+0x346/0x510 Move unregister_key_type() before releasing either resource. This stops new lookups and waits for in-flight key operations to finish before the backend state is destroyed. Fixes: 0b6cf6b97b7e ("tpm: pass an array of tpm_extend_digest structures to tpm_pcr_extend()") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Link: https://lore.kernel.org/r/20260731140925.2973492-1-nicoyip.dev@gmail.com Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen commit ed3b875bea55a3ec4837113356df2ead11115af9 Merge: 7f063b2f17eaba 08745c62350126 Author: Linus Torvalds Date: Thu Aug 20 18:17:08 2026 -0700 Merge tag 'mm-stable-2026-08-18-18-39' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull MM updates from Andrew Morton: - "mm: drop "sub" prefix from various places" (Dev Jain) page->folio conversion and a naming cleanup - "mm/kasan: remove redundant initialization for kasan_flag_write_only" (Igor Putko) KASAN cleanup work - "mm/filemap: reduce unnecessary xarray lookups" (Chi Zhiling) Small speedup in the pagecaache read code - "mm/percpu: Fix possible NOFS/NOIO reclaim recursion" (Kaitao Cheng) Improve the vmalloc code - mainly the avoidance of GFP_KERNEL allocations when the caller asked for GFP_NOFS or GFP_NOIO - "mm/kmemleak: avoid soft lockup when scanning task stacks" (Breno Leitao) Avoid a soft lockup watchdog trigger from the kmemleak scanning code in extreme situations - "mm/page_owner: misc cleanups" (Ye Liu) Cleanups to the page_owner code. For some reason lots of people have been working on the page_owner code this cycle. - "mm: convert to walk_page_range_vma() to eliminate find_vma()" (Kefeng Wang) Simplify and accelerate the page walking library function - "mm/migrate: preparatory cleanups for batch copy and offload" (Shivank Garg) Cleanups in the migration code - "mm/page_owner: add per-fd filter infrastructure for print_mode and NUMA filtering" (Zhen Ni) Per-fd filtering to page_owner in order to reduce the sometimes vast amount of output it can produce - "mm: Refactor bootmem gigantic hugepage allocation" (Muchun Song) Fixes and preparatory cleanups around bootmem HugeTLB handling, sparse initialization ordering, and related vmemmap setup - "mm/zsmalloc: reduce lock contention in zs_free()" (Wenchao Hao) Reduce lock contention in zs_free(), which dominates the unmap path under memory pressure on Android (LMK kills) and on x86 servers running zswap-heavy workloads. Up to 1.83x improvement in microbenchmarking. - "move alloc_tag.c file under mm/" (Suren Baghdasaryan) - "samples/damon: handle damon_{start,stop}() failures" (SJ Park) Fix improper handling of damon_start(), damon_stop(), and damon_call() failures across DAMON sample modules to prevent potential memory leaks, operation disruptions and use-after-free bugs - "mm/damon/sysfs: kobject_del() directories that users can create/remove" (SJ Park) Fix delayed sysfs directory removal under DEBUG_KOBJECT_RELEASE causeing creation failures due to duplicate directory names by adding missing kobject_del() calls before creating new directories - "mm: cleanup clear_not_present_full_ptes()" (David Hildenbrand) Clean up the core pte handling code - "selftests/damon: misc fixes for test bugs" (Kunwu Chan) Fix several bugs in the DAMON selftests - "selftests/damon: fix memcg_path staging handling" (Cheng Nie) Fix a bug in _damon_sysfs.py for damos_filter memcg_path setup, and add a test case for it in sysfs.py. - "selftests/damon: test kdamond refresh_ms" (Ruslan Valiyev) Selftest coverage for DAMON's refresh_ms sysfs feature by updating the test control module and verifying that scheme stats update automatically without manual intervention - "mm/damon: five misc fixups" (Akinobu Mita) Miscellaneous DAMON fixups. - "mm/damon/core: detect internal variation above max_nr_regions/2" (Jiayuan Chen) Fix DAMON's region splitting behavior when region counts exceed half the maximum budget by dynamically scaling down the split fraction as the limit approaches, preventing large regions from staying un-split, and add corresponding KUnit test coverage - "mm: preparatory patches for PMD level swap entries" (Usama Arif) Refactor and clean up PMD softleaf helpers, call sites, and architecture flags to lay the groundwork for a follow-up series that introduces PMD page table swap entries - "mm/damon: update, optimize, and clean up doc, tests, and code" (SJ Park) Update DAMON design and ABI documentation, expands unit and selftest coverage, optimize damon_commit_target_regions(), and clean up recently added sysfs interface code for better readability - "mm/vmpressure: reduce CPU, memory and code overhead on cgroup v2" (Usama Arif) Optimize vmpressure() by skipping unnecessary work on cgroup v2 for userspace event notifications and refactor v1-only eventfd handling into mm/memcontrol-v1.c to reduce memory overhead and code complexity - "selftests/mm: refactor pkey helpers and fix mmap error handling" (Hongfu Li) Refactor pkeys shared tracing and assertion helpers into a common file, unify protection key selftests to use consistent diagnostic logging and assertions, and enforce standardized MAP_FAILED return checks for mmap() calls across the tests - "mm/damon: optimize out nr_accesses_bp" (SJ Park) Replace the error-prone, continuously updated nr_accesses_bp field in damon_region with an on-demand moving sum function, reducing structure memory overhead and avoiding state corruption bugs - "Open HugeTLB allocation routine for more generic use" (Ackerley Tng) Decouple HugeTLB folio allocation from VMA dependencies by introducing hugetlb_alloc_folio(), enabling subsystems like guest_memfd to allocate HugeTLB folios without standard VMA reservations or pseudo-VMAs - "mm/damon: provide pseudo moving sum probe_hits" (SJ Park) Integrate DAMON's probe_hits attribute counter into the pseudo moving sum infrastructure, enabling real-time, online monitoring without waiting for full aggregation intervals - "mm: Some cleanups for page allocator APIs" (Brendan Jackman) Simplify and refactor the page allocator entry points and flags by unifying allocation paths, adding internal alloc_flags arguments, and eliminating redundant __ prefixed alloc_pages variants. - "Fix incorrect access of hugetlb pte entries" (Dev Jain) Enforce the consistent use of huge_ptep_get() instead of ptep_get() for HugeTLB entries and fixes an unaligned address issue in arm64's huge_ptep_get() implementation - "mm/damon: validate all parameters in the core" (SJ Park) Consolidate parameter validation into the DAMON core specifically within damon_start() and damon_commit_ctx() to centralize error checking, eliminate caller-side redundant checks and to improve maintenance efficiency - "tools/mm/page_owner_sort: fix filtering and cleanup issues" (Yichong Chen) Rename is_need() to filter_record() for clearer return semantics, fix per-record allocation memory leaks and bound output copies in search_pattern() to address an existing buffer issue - "memcg: bail out reclaim when memcg is dying" (Jiayuan Chen) Mitigate a system-wide stall which occurs when a cgroup is removed while one of its memory control files is doing synchronous reclaim - "mm/memory-failure: add panic option for unrecoverable pages" (Breno Leitao) Introduce an opt-in vm.panic_on_unrecoverable_memory_failure sysctl that immediately panics the kernel on unrecoverable memory errors in kernel-owned pages to preserve error context and prevent delayed, silent data corruption - "mm/damon: refactor damon_{start,stop,commit}() for simple error handling" (SJ Park) Refactor the DAMON core API functions to guarantee that all contexts are fully stopped when damon_start(), damon_stop(), or damon_commit() fail, eliminating the need for complex and error-prone caller-side cleanup code - "Keep tail page private zero at free and folio split" (Zi Yan) Add checks to ensure tail_page->private is zero when freeing compound or high-order pages and when promoting tail pages during large folio splits. By validating these fields at free and split time, it allows the removal of redundant private field clearing inside prep_compound_tail() - "mm: drop redundant lru_add_drain in anon folio reuse paths" (Barry Song) Eliminate redundant lru_add_drain() calls in wp_can_reuse_anon_folio() and do_swap_page() to reduce LRU lock contention and system overhead By validating folio refcounts against the LRU cache before draining and removing unnecessary drains in the swap path, it achieves up to a 30.5% reduction in drain calls during heavy swap workloads - "mm: clean up folio LRU and swap declarations" (Jianyue Wu) Reorganize folio LRU and swap code by relocating page-cluster state to mm/swap_state.c, renaming mm/swap.c to mm/folio.c, and moving MM-internal reclaim declarations into mm/internal.h. - "userfaultfd: working set tracking for VM guest memory" (Kiryl Shutsemau) Add userfaultfd support for tracking the working set of VM guest memory, so a VMM can identify hot pages and reclaim cold ones to tiered or remote storage - "mm: remove CONFIG_HAVE_BOOTMEM_INFO_NODE (Part 2)" (David Hildenbrand) Remove the remaining pieces of CONFIG_HAVE_BOOTMEM_INFO_NODE, performing some smaller cleanups around freeing of reserved vmemmap pages on the way. - "mm/damon: update probe hits for runtime parameter commits" (SJ Park) Ensure that DAMON's probe_hits attribute counter is properly updated when monitoring intervals are changed at runtime, matching the behavior of nr_accesses. To achieve this, it refactors and renames existing helper functions for shared use, applies the updates to probe_hits, and handles edge cases in damon_probe_hits_mvsum() to maintain measurement accuracy. - "KSM: performance optimizations for rmap_walk_ksm" (xu xin) Resolve a severe KSM reverse-mapping performance bottleneck where thousands of split VMAs sharing a single anon_vma cause extended lock contention. By adding an interval-filtering check during the rmap walk, it reduces worst-case anon_vma lock hold times from over 500ms down to under 2ms, preventing application freezes and latency spikes under memory pressure. - "mm: split a couple of headers from internal.h" (Mike Rapoport) Split declarations related to mm_init, memblock, vmalloc and sparse into new headers - "KSM: use linear_page_index in collect_procs_ksm()" (xu xin) Apply the interval tree optimization from rmap_walk_ksm() to collect_procs_ksm() to avoid iterating over non-matching VMAs during KSM memory error handling. It hoists loop-invariant address initialization and restricts the anon_vma_interval_tree_foreach walk to a targeted page offset range, reducing redundant checks and improving lookup efficiency. - "selftests/mm: avoid false failures in hugetlb and KSM tests" (Sayali Patil) Fix issues in the hugetlb and KSM MM selftest categories that can report failures when the prerequisites for the tests are not satisfied - "mm/damon: introduce data attributes only monitoring" (SJ Park) Introduce attribute-weighted region management in DAMON, allowing users to prioritize specific data attributes (such as page sizes or cgroups) over or instead of access monitoring. By assigning weights to attribute probes, DAMON can completely disable access tracking and adjust monitoring regions based on weighted probe-hit counters to optimize monitoring quality for attribute-focused workloads. - "mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings" (Stanislav Kinsburskii) Extend hmm_range_fault() to support userfaultfd-backed regions by allowing the mmap lock to be dropped during fault handling via a new hmm_range_fault_locked() helper. By accepting a locked pointer and signaling retry status when lock release occurs, it enables page fault resolution in userfaultfd regions while preserving backward compatibility for existing callers. - "mm: make VMA page offset handling more consistent" (Lorenzo Stoakes) Clean up and standardize how vma->vm_pgoff is accessed and manipulated across file-backed and anonymous mappings in the kernel It introduces dedicated helper functions such as vma_start_pgoff(), vma_end_pgoff(), vma_set_pgoff() and linear_page_delta() while renaming rmap interval tree helpers to better reflect their functionality. These changes establish a cleaner foundation for future work that will unify virtual page offset indexing for all anonymous and CoW'd folios. - "mm: handle device-private PMDs in walk callbacks" (Usama Arif) Address kernel panics and state corruption caused by MM walk callbacks reaching non-present device-private PMD swap entries created during HMM migrations It ensures that functions which acquire pmd_trans_huge_lock() properly recognize device-private PMDs instead of assuming a present THP or a standard migration entry. - "mm/rmap: Refactor try_to_unmap_one" (Dev Jain) Refactor try_to_unmap_one by modularizing Hugetlb, anonymous-lazyfree, and anonymous-swapbacked logic into dedicated functions, laying the structural groundwork for batched anonymous large folio unmapping. - "Docs/ABI/damon: sysfs ABI document fixes and additions" (Song Hu) Fix typos and fills in missing entries in the DAMON sysfs ABI document - "dax/kmem: atomic whole-device hotplug via sysfs" (Gregory Price) Introduce an atomic sysfs state attribute and supporting DAX/MM infrastructure to prevent userland races when offlining and removing entire memory regions By adding an unplugged state alongside standard online modes, it enables whole-device atomic hotplug control while preserving backward compatibility. - "mm: convert more vm_flags_t users to vma_flags_t" (Lorenzo Stoakes) Continue transitioning the kernel from the deprecated vm_flags_t type to vma_flags_t across core memory management infrastructure. It replaces legacy type usage in core functions such as do_mmap(), unmapped area allocation, mm->def_vma_flags, and VMA operations like mlock, mprotect, and mremap. - "Two small patches to clean up mm/mm_slot.h" (xu xin) Refactor mm_slot.h by introducing mm_slot_remove() to unify duplicate slot deletion sequences in khugepaged and KSM. It also adds code documentation explaining why mm_slot_lookup and mm_slot_insert must remain as preprocessor macros rather than static inline functions. - "mm/damon/core: hide core-private struct fields" (SJ Park) Clean up DAMON core structures by consistently marking internal-only fields with private: comment tags to prevent improper direct access from outer layers. It enforces encapsulation across core structures including damon_region, damon_target, and damon_ctx and updates DAMON_SYSFS to interact through approved access APIs instead of exposing raw struct members. - "mm/damon: unurgent fixes for infinite loop, NULL de-ref and races" (SJ Park) Address potential infinite loops, NULL dereferences, and race conditions identified in DAMON It fixes an infinite loop triggered by extreme user configurations, a NULL pointer dereference within unit tests and minor monitoring accuracy degradation caused by subtle runtime races. - "mm/page_alloc: fixes for free_pages_nolock() on RT/UP" (Brendan Jackman) Fix an NMI safety flaw in __free_frozen_pages() where freeing pages on non-SMP or PREEMPT_RT kernels can bypass can_spin_trylock() checks via non-PCP or isolated migration paths. It also resolves potential kernel crashes and privilege escalation risks triggered when BPF tracing runs in NMI context alongside memory hotplug or large allocation frees. - "mm/page_alloc: couple of followups for recent cleanups" (Brendan Jackman) Clean up and update page allocator nomenclature, documentation, and debug assertions. It aligns internal FPI_ flags with the public "nolock" naming convention, removes outdated internal implementation details from high-level page allocator comments, and eliminates obsolete VM_BUG_ON() assertions in allocation paths. - "mm/mseal: further cleanups" (Lorenzo Stoakes) Refactor and simplify the mseal implementation by clarifying API boundaries and removing unnecessary code complexity. It replaces generic do_mseal() usage outside the syscall with a dedicated mseal_mmap_page_zero() helper for MMAP_PAGE_ZERO, eliminates mm_struct parameters to enforce that sealing applies only to current->mm, and streamlines overall logic and comments with no functional changes intended. - "mm/vmscan: fix swappiness=max and clean up per-node proactive reclaim" (Ridong Chen) Resolve reclaim behavior bugs and clean up function parameters across memory reclaim paths It fixes swappiness=max in both standard reclaim and MGLRU so unswappable anonymous memory no longer falls back to evicting page cache, ensures reclaim_store() returns accurate error codes instead of collapsing all failures into -EAGAIN, and removes the obsolete gfp_mask parameter from __node_reclaim(). - "mm: mincore: misc cleanups" (Kefeng Wang) Clean up and simplifies the mincore code. Most importantly, it removes the historical special behavior that always reports VM_PFNMAP pages as non-resident. - "mm/huge_memory: drop dead split helper variants" (Kiryl Shutsemau) Two trivial cleanups in the folio split API - "mm/damon: fix uninitialized DAMOS field and kunit exec expectation bugs" (SJ Park) Resolve minor operational and testing bugs in DAMON identified by Sashiko. It initializes the damos->last_applied field to prevent occasional efficiency degradation and fixes invalid memory accesses in DAMON KUnit tests during test failure handling. - "cleanup for stable_page_flags()" (Jinjiang Tu) Clean up and refactor stable_page_flags() used by /proc/kpageflags without altering functionality. It uses BIT_ULL() to prevent shift-overflow warnings on 64-bit flag bits, converts folio-specific flag checks to standard folio_test_*() helpers, and removes redundant CONFIG_PAGE_IDLE_FLAG handling. - "Batch unmap of uffd-wp file folios" (Dev Jain) Extend batched folio unmapping support to file folios within userfaultfd write-protect (uffd-wp) VMAs by adding batching capabilities to pte_install_uffd_wp_if_needed(). This removes special-case restrictions on uffd-wp VMAs in try_to_unmap_one(), significantly simplifying the function's control flow and complexity. - "mm/early_ioremap: clarify and clean up early_ioremap_reset()" (Sang-Heon Jeon) Clarify and clean up the architecture-specific usage of __late_set_fixmap() and __late_clear_fixmap() after early_ioremap_reset() It adds explicit documentation regarding when early_ioremap_reset() must be called and removes redundant macro definitions and reset calls in the RISC-V and ARM64 architectures. - "mm: fix reclaim storms in defrag_mode" (Johannes Weiner) Address severe performance regressions, swap storms, and spurious OOMs caused by vm.defrag_mode=1 under high memory pressure in Meta production It updates the page allocator slowpath so non-movable allocation requests actively trigger direct reclaim and direct compaction at pageblock_order scale, allowing them to claim whole pageblocks rather than spinning unproductively. - "zram: lockmap tweaks" (Sebastian Siewior) Optimize and fix lockdep tracking for zram devices by consolidating per-entry lockmaps and isolate lock classes across multiple instances This reduces memory overhead by replacing per-entry lockdep_map instances with a single map per struct zram, and assigns a dynamic lock_class_key to each instance to prevent false deadlock reports when different zram devices are backed by distinct filesystems. * tag 'mm-stable-2026-08-18-18-39' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (501 commits) selftests/mm: thuge-gen: fix test_shmget() for PAGE_SIZE check selftests/mm: unpoison pages in memory-failure teardown mm/shmem: downgrade final i_blocks check in shmem_evict_inode() to pr_warn() mm/khugepaged: replace mutex_lock/mutex_unlock usage with guard macro mm/zsmalloc: fix release order of locks in zs_page_migrate() Documentation: zram: remove sections numbering ksm: stop iterating VMAs when ksm_test_exit returns true mm: fold userfaultfd_rwp() to false without CONFIG_ARCH_HAS_PTE_PROTNONE mm/migrate: report RCU-tasks quiescent states in migrate_pages_batch() zram: use a custom key for each zram object zram: move lockmap to be per-zram instead per table selftests/mm: fix gup_longterm EINVAL error message mm: page_alloc: fix non-movable reclaim storm in defrag_mode mm: page_alloc: move capture_control to the page allocator mm: compaction: support non-movable compaction for pageblock requests mm: page_alloc: __GFP_FS lockdep annotation for direct compaction hugetlb: evaluate subpool free state while locked mm/damon: remove trailing semicolons after function definitions mm/damon/ops-common: prevent migration fallback to non-target nodes mm/damon: update outdated comment about DAMOS filter handling ... commit 9a9ee7408a1f8271bd1978baff2dd09457054ef4 Author: Chao Yu Date: Wed Aug 19 09:31:07 2026 +0800 f2fs: reduce memory footprint of ino management Currently, ino entries for APPEND_INO, UPDATE_INO, TRANS_DIR_INO, and XATTR_DIR_INO allocate a 'struct ino_entry' slab object and attach it to both a list and a radix tree solely for existence checks via f2fs_exist_written_data(). Since these ino types only track binary existence status, we can embed the information directly into radix tree value entries as a bitmap: - The Linux radix tree/XArray supports in-place value entries via xa_mk_value() / xa_to_value(), which tag the least significant bit to store an unallocated integer value of BITS_PER_XA_VALUE bits (BITS_PER_LONG - 1) directly in the slot pointer. - For each inode, (ino / BITS_PER_XA_VALUE) serves as the radix tree slot index, and (ino % BITS_PER_XA_VALUE) is used as the bit offset within the slot's bitmap. For example, when tracking ino = 7: - Before: Allocate a 'struct ino_entry' ({ .ino = 7 }), insert its pointer into the radix tree at index = 7, and link it to im->ino_list. - After: Compute slot_index = 7 / BITS_PER_XA_VALUE (index 0) and bit_offset = 7 % BITS_PER_XA_VALUE (bit 7), then set bit 7 in the value entry via xa_mk_value(bitmap) at index 0, without allocating a slab object or linking to a list. Additionally: - In-place slot updates are performed via radix_tree_replace_slot(), and slots are deleted with radix_tree_delete() once the bitmap is zeroed. - Reorder the ino list enum so ORPHAN_INO and FLUSH_INO (which still require struct ino_entry and list traversal) remain separated, while bitmap-based trees are torn down using xa_destroy(). This eliminates 'struct ino_entry' slab allocations and linked-list tracking for these ino types, significantly reducing memory consumption. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim commit 0f448bb3767ef6119f5cdeabcae3f10d6e75aed6 Author: Zhan Xusheng Date: Tue Aug 18 22:55:35 2026 +0800 f2fs: fix i_size when pinned fallocate partially fails From: Zhan Xusheng Commit 4275b59673eb ("f2fs: fix to round down start offset of fallocate for pin file") moved the allocation loop's start down to a section boundary, but the error path still converts @expanded against @pg_start, which holds the unrounded start. @pg_start exists for that conversion: commit 88f2cfc5fa90 ("f2fs: fix to update last i_size if fallocate partially succeeds") added it as an immutable base because map.m_lblk moves every round. Each round now maps exactly sec_blks blocks starting from rounddown(pg_start, sec_blks), so pg_start + expanded overshoots the last allocated block by pg_start % sec_blks, and a partial failure leaves i_size covering a tail that was never allocated. Nothing corrects that afterwards either, since file_dont_truncate() has already cleared FADVISE_TRUNC_BIT. It needs a start offset that is not section aligned plus a fallocate that hits ENOSPC partway, so the error path runs with expanded > 0. On an 80 MiB image with 2 MiB sections: truncate -s 80M img mkfs.f2fs -s 1 -f img mount -o loop img /mnt touch /mnt/pinned f2fs_io pinfile set /mnt/pinned # 2093056 = block 511, so pg_start % sec_blks = 511 f2fs_io fallocate 0 2093056 536870912 /mnt/pinned stat -c %s /mnt/pinned filefrag -v /mnt/pinned The last extent ends at block 10737 either way. Before, i_size is 46075904, block 11249, so 511 blocks of it were never allocated, and filefrag does not mark the last extent eof. After, i_size is 43982848, block 10738, and eof is back. A kernel from before that commit also shows no overshoot. Keep @pg_start pointing at where allocation actually begins. Fixes: 4275b59673eb ("f2fs: fix to round down start offset of fallocate for pin file") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim commit 8ec06f50ddd8d201bd7e55b896ae28ed9d4cb7d1 Author: Daeho Jeong Date: Wed Aug 19 11:06:35 2026 -0700 f2fs: fix to migrate all curseg types during free_segment_range In free_segment_range(), the curseg evacuation loop only iterates up to NR_CURSEG_PERSIST_TYPE (0..5), missing non-persistent in-memory curseg types such as CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC. Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range. Fix this by expanding the curseg evacuation loop upper bound to NR_CURSEG_TYPE to ensure all active curseg types are safely migrated out of the target range. Fixes: d0b9e42ab615 ("f2fs: introduce inmem curseg") Cc: stable@vger.kernel.org Signed-off-by: Daeho Jeong Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim commit 258c95150c26a30db1896eacd3bdef26314f2ca1 Author: Daeho Jeong Date: Thu Aug 20 09:43:40 2026 -0700 f2fs: avoid setting SBI_NEED_FSCK on transient resize failure When free_segment_range() fails in f2fs_resize_fs(), no on-disk superblock or filesystem metadata has been modified yet, and free_segment_range() safely restores all in-memory counters before returning. However, the current error recovery path unconditionally sets the SBI_NEED_FSCK flag and prints a scary error message on any error, forcing an unnecessary and time-consuming fsck.f2fs repair on the subsequent mount/reboot. Fix this by separating the error recovery path with a dedicated recover_user_blocks label to bypass setting SBI_NEED_FSCK on free_segment_range() failures. Signed-off-by: Daeho Jeong Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim commit 934753d26f1ed7fadeedf1b9e7df6fe75de303e8 Author: Paulo Alcantara Date: Tue Aug 18 11:07:38 2026 -0300 MAINTAINERS: Replace Steve French as CIFS maintainer Unfortunately, due to health reasons, Steve French can no longer continue as CIFS maintainer; therefore, I am taking over the role with Namjae Jeon as secondary maintainer. Acked-by: Namjae Jeon Reviewed-by: David Howells Signed-off-by: Namjae Jeon Cc: Steve French Cc: Steve French Cc: Greg Kroah-Hartman Cc: Al Viro Cc: Christian Brauner Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: samba-technical@lists.samba.org Cc: linux-cifs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Tom Talpey Signed-off-by: Paulo Alcantara commit 7f063b2f17eaba2a35e251aa53627f2a70d536e2 Merge: a625b2a387628d b282418bc36619 Author: Linus Torvalds Date: Thu Aug 20 17:07:50 2026 -0700 Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost Pull vhost,vdpa,virtio updates from Michael Tsirkin: - transport v3 support in virtio-mmio - suspend support in vduse - fixes, cleanups all over the place * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (54 commits) vduse: Add suspend vduse: do not take rwsem at reset work flush vduse: add F_QUEUE_READY feature vduse: add VDUSE_SET_FEATURES ioctl vduse: add VDUSE_GET_FEATURES ioctl vduse: store control device pointer tools/virtio: Fix control typo in trace agent comment tools/virtio: Fix userspace typo in vringh test comment vhost: reject zero-size IOTLB INVALIDATE vdpa: Remove redundant dev_err() virtio_ring: fix infinite loop in virtnet_poll_cleantx when device is broken vdpa/mlx5: roll back MR update after VQ setup failure MAINTAINERS: remove Gabriel from LiteX and fw-cfg drivers virtio_mem: fix typo in comment vdpa/solidrun: fix typos in snet_ctrl comments virtio: fix article before virtio in dma-buf comment vhost: fix inaccurate kdoc in iotlb helpers virtio: rtc: time out alarm requests vdpa/mlx5: fix wrong MLX5_ADDR_OF struct type in alloc_inout() vdpa: octeon_ep: add missing MODULE_DEVICE_TABLE() ... commit a625b2a387628df94e385faf5c81bf252f304ed9 Merge: 77ae27fd98f3b5 4e3c1fc8abcb8e Author: Linus Torvalds Date: Thu Aug 20 16:57:59 2026 -0700 Merge tag 'vfio-v7.3-rc1' of https://github.com/awilliam/linux-vfio Pull VFIO updates from Alex Williamson: - Add nv_falcon vfio selftest driver. The Falcon is a general-purpose microcontroller embedded within NVIDIA GPUs, presenting a relatively simple DMA programming interface. This adds another selftest target for vfio-pci with real DMA transfers (Rubin Du, Alex Williamson) - Add allocation assertion helpers to vfio selftests and use them to avoid variable length arrays and the compiler errors they generate (Alex Mastro) - Fix use-after-free hazard where an init path error in MSI support leaves a stray pointer that can later be reused or double-freed (Xiang Mei) - Fix previous refactor of PCI BAR mappings to honor non_mappable_bars flag, which otherwise generates a warning when trying to pci_iomap() a 256TiB BAR on ISM devices on s390 (Farhan Ali) - Add igb vfio selftest driver. Like nv_falcon, this provides another target for DMA testing with vfio selftests, but importantly this driver supports both physical 82576 NICs and the emulation model in QEMU. This therefore enables a vfio selftest vector with no physical hardware requirements (Josh Hilke, Alex Williamson) - Mark selftest fixture objects __maybe_unused to accommodate builds with clang -Wunused-but-set-global (David Matlack) - Add error recovery for vfio-pci devices on s390x. This expands devices which expose the existing error eventfd and introduces a device feature for reporting firmware defined error state information to the user, allowing recovery through hypervisor channels (Farhan Ali) * tag 'vfio-v7.3-rc1' of https://github.com/awilliam/linux-vfio: vfio/pci: Remove the pcie check for VFIO_PCI_ERR_IRQ_INDEX vfio-pci/zdev: Add a device feature for error information s390/pci: Store PCI error information for passthrough devices PCI/MSI: Enable memory decoding before restoring MSI-X messages PCI: Fail FLR when config space is inaccessible PCI: Avoid saving config space state if inaccessible PCI: Allow per function PCI slots to fix slot reset on s390 PCI: Introduce PCI_SLOT_PLACEHOLDER constant for slot_nr placeholder value selftests: harness: Mark test fixture objects __maybe_unused vfio: selftests: Retry on EAGAIN during device reset vfio: selftests: igb: Add driver for Intel 82576 device vfio: selftests: Add helpers to re-enable interrupts vfio/pci: Avoid mapping BARs for devices with non-mappable BARs vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio: selftests: Avoid VLAs vfio: selftests: Add allocation assert helpers vfio: selftests: Add NVIDIA Falcon driver for DMA testing vfio: selftests: Allow drivers without send_msi() support vfio: selftests: Add generic PCI command register helpers vfio: selftests: Add memcpy chunking to vfio_pci_driver_memcpy() commit dd8eb789f18c4c600f28e61176a02bcf3b790117 Merge: 5d650f824df6c0 fbfa013eeac299 fb96dea9cfd68f Author: Stephen Boyd Date: Thu Aug 20 16:51:47 2026 -0700 Merge branches 'clk-pile' and 'clk-microchip' into clk-next * clk-pile: (111 commits) clk: microchip: mpfs: fix regmap_update_bits() mask/val order clk: visconti: Make sure clk_init_data is fully initialized clk: ti: Make sure clk_init_data is fully initialized MAINTAINERS: Add Brian Masney and Jerome Brunet as co-maintainers for clk subsystem Drop Michael Turquette's clk maintainer entry clk: ti: composite: resolve parent clocks by DT index, not by name clk: ti: mux: resolve parent clocks by DT index, not by name clk: devres: fix cleanup in devm_clk_get_optional_enabled_with_rate() dt-bindings: clock: ti,keystone-gate: Convert to DT schema dt-bindings: clock: ti: Convert APLL clock to DT schema clk: zynq: pll: Fix kernel-doc after determine_rate() conversion dt-bindings: clock: ti,clockdomain: Convert to DT schema dt-bindings: clock: Correct white-space style clk: tegra: set up proper EMC clock implementation for Tegra114 clk: clocking-wizard: remove 20kHz restriction clk: clocking-wizard: optimize clock search clk: clocking-wizard: fix clock difference detection clk: mediatek: mt8135: Fix inverted gate control for devapc_ck clk: clocking-wizard: Program PLL CP/RES and lock parameters on reconfig clk: tegra: support 48MHz clock for pll_p_out1 ... * clk-microchip: clk: at91: Read "reg" with helper commit 5d650f824df6c0db181164c36a73c0ab2286a24d Merge: a1476addb4631c 9af2b738227fef 1353d95e637b57 53cb675d72064f 79b64c7476da30 d8a8d206a7ea9e Author: Stephen Boyd Date: Thu Aug 20 16:51:33 2026 -0700 Merge branches 'clk-imx', 'clk-rockchip', 'clk-samsung', 'clk-qcom' and 'clk-allwinner' into clk-next * clk-imx: clk: imx95-blk-ctl: Fix REFCLK rise-fall mismatch on i.MX95 clk: imx95-blk-ctl: Add func_out_en clock for i.MX9x PCIe clk: imx: imx8qxp: add missing MODULE_DEVICE_TABLE() clk: imx: imx8qxp-lpcg: add missing MODULE_DEVICE_TABLE() clk: imx: Add audio PLL debugfs for K-divider control * clk-rockchip: clk: rockchip: rk3576: fix source muxes for SPI0..SPI4 clk: rockchip: Add clock controller for the RV1106 dt-bindings: clock: rockchip: Add RV1106 CRU support clk: rockchip: Fractional PLL coefficient on RK3588/RK3576 is two's complement clk: rockchip: Fix the fractional part denominator on RK3588/RK3576 PLLs clk: rockchip: rk3588: Allow VP2 the same sourcing options as other VPs clk: rockchip: rk3588: Don't change PLL rates when setting dclk_vop2_src * clk-samsung: clk: samsung: Don't include clk: samsung: pll: use kzalloc_flex clk: samsung: cpu: use kzalloc_flex clk: samsung: use kzalloc_flex clk: samsung: exynos990: Fix PERIS gate clock parents clk: samsung: exynos990: Add PERIS TMU_SUB_PCLK gate dt-bindings: clock: exynos990: Add CLK_GOUT_PERIS_TMU_SUB_PCLK * clk-qcom: (94 commits) clk: qcom: Add support for Qualcomm GPU Clock Controller on Shikra clk: qcom: Return expected ENOMEM error on dynamic allocation failure clk: qcom: apss-ipq-pll: Add IPQ5210 support dt-bindings: clock: qcom,a53pll: Add IPQ5210 compatible clk: qcom: Add support for videocc driver on Qualcomm Maili SoC dt-bindings: clock: qcom: Add Qualcomm Maili video clock controller dt-bindings: clock: qcom: Add Qualcomm Shikra GPU clock controller dt-bindings: clock: qcom: Add Qualcomm Shikra Display clock controller clk: qcom: gpucc-qcm2290: Park RCG's clk source at XO during disable clk: qcom: gpucc-qcm2290: Keep the critical clocks always-on from probe clk: qcom: gpucc-qcm2290: Move to the latest common qcom_cc_probe() model clk: qcom: gpucc-qcm2290: Drop pm_clk handling clk: qcom: qcm2290: Update DISPCC and GPUCC GDSC *wait_val values clk: qcom: qcm2290: Add RETAIN_FF_ENABLE flag for DISPCC and GPUCC GDSCs clk: qcom: qcm2290: Set POLL_CFG_GDSCR flag for DISPCC and GPUCC GDSCs clk: qcom: dispcc-qcm2290: Enable runtime PM support clk: qcom: dispcc-qcm2290: Move to the latest common qcom_cc_probe() model clk: qcom: gcc-qcm2290: Keep the critical clocks always-on from probe dt-bindings: clock: qcom,qcm2290-dispcc: Add missing power-domains property clk: qcom: Add Audio Core clock controller support on Qualcomm Shikra SoC ... * clk-allwinner: clk: sunxi-ng: sun6i-rtc: add a733 support clk: sunxi-ng: sun6i-rtc: split main oscillator div and gate clk: sunxi-ng: div: add read-only operation support clk: sunxi-ng: mux: fix determine helper rate propagation clk: sunxi-ng: mux: remove unneeded export clk: sunxi-ng: sun6i-rtc: Add feature bit for IOSC calibration clk: sunxi-ng: sun6i-rtc: clean up DT usage clk: sunxi-ng: fix ccu probe clock unregister on error dt-bindings: rtc: sun6i: add sun60i-a733 support dt-bindings: rtc: sun6i: no clock-output-names on h616/r329 commit a1476addb4631cc7d393adc057a20129b264520f Merge: 9ff218b1b07d13 aa7ebeb0358cf6 cd72dbb2a783bb 3990334628de81 166455473d1f60 Author: Stephen Boyd Date: Thu Aug 20 16:51:21 2026 -0700 Merge branches 'clk-renesas', 'clk-thead', 'clk-mobileye', 'clk-amlogic' and 'clk-spacemit' into clk-next * clk-renesas: clk: renesas: Add R-Car X5H CPG driver dt-bindings: clock: Document Renesas R-Car X5H Clock Pulse Generator clk: r9a08g045: Add clocks and resets for CAN-FD dt-bindings: clock: renesas,versaclock7: Update maintainer clk: renesas: r9a09g047: Add LVDS clocks and resets clk: renesas: r9a09g077: Add LCDC and PLL3 clock support for RZ/T2H display pipeline clk: renesas: rzv2h-cpg: Extract PLL calculation helpers into shared library clk: renesas: rzv2h-cpg: Use per-SoC PLL reference frequency for calculations clk: renesas: r9a08g046: Add USB2.0 clock and reset entries clk: renesas: r9a09g077: Add RTC clocks clk: renesas: cpg-mssr: Implement dedicated MSTP delay logic for RZ/T2H LCDC and RTC clk: renesas: r9a08g046: Add clock and reset entries for GE3D clk: renesas: r9a08g046: Add clock and reset entries for SDHI clk: renesas: r9a09g047: Add audio clock and reset support dt-bindings: clock: renesas: Add audio clock inputs for RZ/V2H family dt-bindings: clock: renesas,r9a09g077/87: Add PCLKRTC clock ID dt-bindings: clock: renesas,r9a09g077/87: Add LCDC_CLKD clock ID * clk-thead: clk: thead: allow COMPILE_TEST builds * clk-mobileye: clk: eyeq: Add EyeQ7H compatibles clk: eyeq: Drop PLL, dividers, and fixed factors structs clk: eyeq: Convert clocks declaration to eqc_clock clk: eyeq: Introduce a generic clock type clk: eyeq: Prefix the PLL registers with the PLL type clk: fixed-factor: Export __clk_hw_register_fixed_factor() clk: fixed-factor: Rework initialization with parent clocks reset: eyeq: Add EyeQ7H compatibles dt-bindings: soc: mobileye: Add EyeQ7H OLB * clk-amlogic: clk: amlogic: Add A9 peripherals clock controller driver dt-bindings: clock: Add Amlogic A9 peripherals clock controller clk: amlogic: Add A9 AO clock controller driver dt-bindings: clock: Add Amlogic A9 AO clock controller clk: meson: align gxbb_32k_clk_sel number of parents with actual count * clk-spacemit: clk: spacemit: k3: fix missing /2 factor in i2s sysclk dividers clk: spacemit: k3: fix i2s clock topology dt-bindings: soc: spacemit: k3: add i2s_sysclk, i2s_bclk_factor and i2s1_sysclk_src IDs clk: spacemit: k3: Add UFS refclk clock dt-bindings: soc: spacemit: k3: Add clock ID for UFS refclk clk: spacemit: k3: fix parent clock of UFS aclk commit 77ae27fd98f3b548797c9f22c10ab5cf1c4ada53 Merge: 6439079365dcb3 3783364ce6f883 Author: Linus Torvalds Date: Thu Aug 20 15:34:31 2026 -0700 Merge tag 'printk-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux Pull printk updates from Petr Mladek: - Prevent a possible out-of-bound access and a use-after-free in rather theoretical situations - Make no_hash_pointers take effect early - Some fixes and clean up of the ratelimit KUnit test * tag 'printk-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux: printk: Handle pre-enabled consoles in the top-level register_console() printk: Fix possible console use-after-free lib/tests: test_ratelimit: fix stress test thread lifecycle and leak lib/vsprintf: Make no_hash_pointers take effect early commit ee5a386cfe60f3f8286de16a9db8e1a08f0bc124 Author: Junrui Luo Date: Sun Aug 16 16:01:29 2026 +0800 NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget path When the server returns a new layout stateid while a valid one is still held, pnfs_layout_process() calls pnfs_mark_matching_lsegs_return() on the on-stack free_me list and jumps to out_forget. Segments whose reference count drops to zero are unlinked from lo->plh_segs and moved to free_me by mark_lseg_invalid(); for an idle cached segment the layout header holds the only reference, so this happens on the first decrement. out_forget never drains free_me -- only the success path calls pnfs_free_lseg_list(). Commit 814b84971388 ("pNFS/NFSv4: Fix a layout segment leak in pnfs_layout_process()") added the drain; commit 08bd8dbe8882 ("pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process()") removed it while switching the destination to lo->plh_return_segs, which is drained elsewhere. Commit fb700ef02676 ("NFSv4.1: Simplify layout return in pnfs_layout_process()") switched the destination back to free_me without restoring the drain. Restore the pnfs_free_lseg_list() call. Fixes: fb700ef02676 ("NFSv4.1: Simplify layout return in pnfs_layout_process()") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Signed-off-by: Trond Myklebust commit 13c23c5cb977f66390795437fd3837887ce1fd75 Author: Junrui Luo Date: Sun Aug 16 16:01:28 2026 +0800 NFSv4/pnfs: key the data server cache on the NFS version nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time. Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Trond Myklebust commit c75ef2137e749f2673f0617cfdaae53b2bb7195a Author: Junrui Luo Date: Sun Aug 16 16:01:27 2026 +0800 NFSv4.2: fix LAYOUTSTATS send buffer exhaustion encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation. Fixes: 27c430644369 ("pnfs/flexfiles: encode LAYOUTSTATS flexfiles specific data") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Trond Myklebust commit 20358201777496fd0bb7b4336fcb4d3fc13cad28 Author: Tim Menninger Date: Wed Aug 19 12:41:21 2026 +0000 pNFS: Fix EBUSY check in pnfs_layout_need_return Commit 41d0a8ead9720 ("NFSv4/pnfs: Add support for the PNFS_LAYOUT_FILE_BULK_RETURN flag") replaced pnfs_layout_segments_returnable() in pnfs_layout_need_return() with a direct call to pnfs_mark_layout_stateid_return(). The old helper checked the return value against -EBUSY, but the replacement compares against EBUSY. Since pnfs_mark_layout_stateid_return() returns negative errno values, the -EBUSY case is never detected. Fix the comparison in pnfs_layout_need_return() to check against -EBUSY. Fixes: 41d0a8ead9720 ("NFSv4/pnfs: Add support for the PNFS_LAYOUT_FILE_BULK_RETURN flag") Cc: stable@vger.kernel.org Signed-off-by: Tim Menninger Signed-off-by: Trond Myklebust commit 6439079365dcb33c6701f5f0e480ac2c17312b6b Merge: 920f27122cbacf 29a86c5e6361ca Author: Linus Torvalds Date: Thu Aug 20 15:11:52 2026 -0700 Merge tag 'probes-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull probes updates from Masami Hiramatsu: "BTF typecasting and variable fetch enhancements: - Typecast support across probe events: Extended BTF typecasting syntax (e.g., (STRUCT)PARAM->MEMBER) to kprobes, uprobes, and fprobes on function entry and return - Nested typecasts: Added support for chaining and nesting typecasts up to 3 levels, including casting registers and stack variables - Field specifier option: Added (STRUCT,FIELD) syntax to emulate container_of(), allowing retrieval of parent structures from member pointers - $current variable support: Introduced $current special variable to access the running task_struct via BTF dereferencing - Per-CPU variable access: Added this_cpu_read() and this_cpu_ptr() fetcharg methods to trace CPU-local data safely - Fetcharg bytecode dumper: Added CONFIG_PROBE_EVENTS_DUMP_FETCHARG to dump the compiled fetcharg bytecode instructions as comments in dynamic_events - Extended symbol name handling: Removed the MAX_COMMON_HEAD_LEN limit and extended MAX_ARGSTR_LEN to 256 bytes, enabling probing of long symbols, mangled Rust symbols and complex BTF expressions - eprobe variable syntax: Allowed eprobes to reference event fields directly without requiring a '$' prefix - Cleanup unused parameters, redundant codes, duplicate macros and pointer arithmetic - Use a ternary operator for simplifying fetch_type_from_btf_type() Expanded boot time dynamic probe support: - Add boot-time tracing configuration support for event probes (eprobes), function probes (fprobes), and tracepoint probes (tprobes) - Allow comment lines ('#') in dynamic_events file Optimization, robustness, and cleanups: - Simplify fprobe_remove_ips() by reusing graph and ftrace helpers - Remove __packed attribute from struct __fprobe_header to avoid unaligned memory access penalties on RISC architectures - Remove redundant memset() calls in perf event probe handlers - Replace legacy __ASSEMBLY__ with __ASSEMBLER__ in header files Selftests & refactoring: - Refactor parse_probe_arg() and parse_probe_vars(), and eliminate recursion in probe argument parsing to protect kernel stack depth - Add selftests for BTF typecasts and module probing without module prefixes - Force LC_ALL=C in ftracetest to prevent test failures on localized systems - Refactor btf_type_skip_modifiers() to remove ignored id parameter - Sort ERRORS list in trace_probe.h alphabetically - Fix typo in fprobe docs, and trace_fprobe function name - Rename FETCH_OP_DATA to FETCH_OP_IMMSTR - Make file offset error message probe-agnostic" * tag 'probes-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: (37 commits) fprobe: Simplify fprobe_remove_ips() by reusing existing helpers tracing/boot: Add support for eprobe, fprobe, and tprobe events selftests/ftrace: Force C locale in ftracetest tracing/probes: Treating longer symbol name on event comparation docs: trace: fprobe: fix 'thos' spelling tracing/probes: Fix extra whitespace in trace_probe_kernel.h tracing/kprobe: Remove redundant memset in kprobe_perf_func() tracing/fprobe: Remove redundant memset in fentry_perf_func() tracing/fprobe: Remove redundant snprintf in trace_fprobe_match_command_head() tracing/probes: Simplify BTF_KIND_PTR case in fetch_type_from_btf_type() tracing/probes: Cleanup pointer arithmetic in store_trace_entry_data() tracing/probes: Remove unused parameter from parse_probe_var_retval() tracing/probes: Remove redundant bounds check in trace_probe_compare_arg_type() tracing/probes: Remove redundant boolean conversion in trace_probe_has_single_file() tracing/probes: Remove duplicate MAX_ARRAY_LEN macro definition selftests/ftrace: Add test case for a symbol in a module without module name tracing/probes: Eliminate recursion in parse_probe_arg() tracing/probes: Extend max length of argument string tracing/probes: Sort ERRORS list in trace_probe.h alphabetically tracing/probes: Refactor parse_probe_arg() ... commit d463633d63e6aa10384683bf39971a4b00780c56 Author: Miro Kropacek Date: Thu Aug 20 10:28:37 2026 +1200 fbdev: atafb: Add support for SuperVidel's SuperBlitter The SuperVidel graphics FPGA includes a hardware blitter (bit block transfer engine) operating within the SuperVidel DDR2 video RAM. Two versions of this blitter exist. Later versions (>= 9) of the SuperVidel firmware support an asynchronous command FIFO, older versions must be polled for command completion. Add hardware-accelerated copyarea, fillrect and imageblit fb operations (falling back to the non-accelerated versions for anything that exceeds blitter capabilities). Signed-off-by: Miro Kropacek Reviewed-by: Michael Schmitz Signed-off-by: Michael Schmitz Link: https://lists.debian.org/debian-68k/2026/08/msg00000.html Signed-off-by: Helge Deller commit 51df976c3268b96a926d8f389fd9e91c0b5392e1 Author: Miro Kropacek Date: Thu Aug 20 10:28:36 2026 +1200 fbdev: atafb: Add support for further video bit depths on atafb:external Supervidel offers additional video bit depths: 8-bit chunky, 16-bit RGB565 (also on the original Videl) and ARGB888. Add code to support these bit depths. Signed-off-by: Miro Kropacek Reviewed-by: Michael Schmitz Signed-off-by: Michael Schmitz Link: https://lists.debian.org/debian-68k/2026/08/msg00000.html Signed-off-by: Helge Deller commit d7dda89ad05173f9bbb795cd3cfc38262381f7f4 Author: Miro Kropacek Date: Thu Aug 20 10:28:35 2026 +1200 fbdev: atafb: Give atafb proper parent The atafb fb device registers no parent, causing a missing symlink (/sys/class/graphics/fb0/device). Xorg fbdevhw driver looks for that symlink when scanning for devices, so add a parent node for atafb. The proper way to do that is use of framebuffer_alloc(), which requries refactoring atafb to move from static fb_info to allocation of fb_info by framebuffer_alloc(). About the only location where a fb_info pointer cannot be passed is monspec setup in atafb_setup(). Store static monspecs there and copy into place after framebuffer_alloc(). Pass fb_info everywhere it's needed (detect, decode_var and do_fb_set_var functions), and remove the static fb_info struct. Signed-off-by: Miro Kropacek Reviewed-by: Michael Schmitz Signed-off-by: Michael Schmitz Link: https://lists.debian.org/debian-68k/2026/08/msg00000.html Signed-off-by: Helge Deller commit 920f27122cbacfd3b540a3f2f67b0145203d5581 Merge: 073e62fd33fe9c 7098e9cd98a05c Author: Linus Torvalds Date: Thu Aug 20 15:02:09 2026 -0700 Merge tag 'cxl-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl Pull CXL updates from Dave Jiang: "This includes the remaining patches to complete the basic support for CXL type2 (accelerators) drivers by the CXL core. A set of unit testing support to catch regressions for the CXL core type2 exported functions has also been added. The actual CXL type 2 driver support for the AMD Solarflare NIC driver has been picked up by net-dev. A set of preparatory patches has been picked up from the CXL port error handling series in order to reduce the number of patches in that series for review. The rest of that series is getting close to be merged but was not ready for the 7.3 merge window. There are also a number of misc patches and a large number of bug fixes against pre-existing issues flagged by sashiko reviews as contributors post new patches on the mailing list. We will continue to work through the sashiko raised issues as they show up." * tag 'cxl-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl: (35 commits) cxl/Documentation: Spell out globbed sysfs attribute names cxl: Rename find_cxl_port() to find_cxl_port_by_dport() cxl: Tighten CPER kfifo registration API and symbol visibility acpi/apei/ghes: Use raw_spinlock_t for CXL CPER work locks cxl/ras: Fix cxl_rch_get_aer_severity() wrong severity register cxl/ras: Fix cxl_rch_get_aer_info() out-of-bounds AER register read cxl/test: Assign one mock memdev a full-width serial number cxl/core: Format the memdev serial number as unsigned in TP_printk cxl/pmem: Format the nvdimm serial number as unsigned decimal cxl: Use %pe to print error pointers cxl/region: Use __free(put_device) in find_pos_and_ways() cxl/region: Fix use-after-free in find_pos_and_ways() error path cxl: Deny Features commands on the RAW mailbox path cxl/features: Clamp Get Feature output size to the remaining buffer cxl/features: Reject Set Features output buffer smaller than the header cxl/features: Reject Get Feature count larger than the output buffer cxl/port: Restart port enumeration when a sibling adds the dport first cxl/features: Serialize multi-part Get/Set Feature transfers cxl/pci: Honor -EPROBE_DEFER from component register setup cxl/mbox: Break poison list loop on an empty payload ... commit 073e62fd33fe9cec754cb89e60c0ebbab781a50a Merge: 73cc4da3857bb2 8da45c93dfa98f Author: Linus Torvalds Date: Thu Aug 20 14:53:54 2026 -0700 Merge tag 'riscv-for-linus-7.3-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V updates from Paul Walmsley - Add initial definitions and discovery for the Smcsrind, Sscsrind, Smcntrpmf, Ssccfg, Smcdeleg, Zicclsm, Ziccamoa, Ziccif, Ziccrse, Za64rs, and Ssqosid RISC-V ISA extensions - Improve the RISC-V update_mmu_cache_range() implementation by using flush-by-ASID, enabling performance improvements on microarchitectures that support related optimizations; and by taking advantage of the Svinval RISC-V ISA extension on microarchitectures that support it - Shrink CFI shadow stack allocation further (to 512MB) to save virtual address space (and physical memory on systems with strict overcommit policies) - Add initial CPU context switch support for QoS tagging (Ssqosid) - Change our vector misaligned access speed test code to be synchronous, avoiding a bunch of bugs related to unnecessary asynchronicity - Enable ARCH_HAS_ACPI_TABLE_UPGRADE for RISC-V to help with ACPI table debugging (similar to ARM64 and x86) - Extract vDSO section offsets at build time, rather than run time, to avoid the boot time overhead - Use assembler directives to control the use of instructions from the RISC-V ISA extensions Zacas and Zabha, rather than compiler -march flags that could affect the whole kernel (similar to ARM64) - Add a kselftest for kprobes support for the c.jal instruction on RISC-V - When UEFI runtime services are available, use them to restart and power off - Fix ARCH_HAS_ACPI_TABLE_UPGRADE for RISC-V by adding a missing include file to the ACPI code - Move contiguous DMA memory reservation later in the boot, to ensure that the correct global and per-node pools are allocated when CONFIG_CMA_SIZE_PERNUMA is enabled - Disallow probes on breakpoint handlers to avoid recursing indefinitely into do_trap_break() - Patch the compat vDSO during runtime alternatives processing, not only the standard vDSO - Remove some leftover XIP support elements missed by commit 9b3a2be84803 ("riscv: Remove support for XIP kernel") - Fix broadcast timer switching in ACPI LPI power states by implementing a RISC-V version of arch_get_idle_state_flags() - Miscellaneous fixes, including: vDSO makefile simplification; marking our default_power_off() as __noreturn; error path fixes in the PMU SBI perf driver; RISC-V extension capitalization consistency; the use of BIT() macros in one of our include files; and some documentation fixes * tag 'riscv-for-linus-7.3-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: (39 commits) RISC-V: hwprobe: Use BIT macro to avoid warnings riscv: alternative: Also patch the compat vDSO riscv: alternative: Use the statically extracted vDSO section offsets riscv: vdso: Add symbols for the alternative section boundaries riscv: Add Ziccamoa, Ziccif, Ziccrse, and Za64rs to cpufeature and hwprobe riscv: Add Zicclsm to cpufeature and hwprobe riscv: cpufeature: Clarify ISA spec version for canonical order riscv: Standardize extension capitalization riscv: kprobes: Prevent probes in breakpoint handlers riscv: cmpxchg: Use .option arch for Zacas and Zabha riscv: acpi: Handle LPI architectural context loss flags riscv: further remove XIP riscv: Add support for srmcfg CSR from Ssqosid extension riscv: Detect the Ssqosid extension dt-bindings: riscv: Add Ssqosid extension description dt-bindings: riscv: add Counter delegation ISA extensions description RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing RISC-V: Add Ssccfg extension CSR definition dt-bindings: riscv: add Smcntrpmf ISA extension description RISC-V: Add Smcntrpmf extension parsing ... commit 8fa4804fe62ca4155a2d8fc2789d630376cbf2fc Author: Jérémy Jean Date: Thu Aug 20 20:53:29 2026 +0000 NFSv4.1: zero referring call lists before decoding 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 commit 73cc4da3857bb2970b3e349ed9608ca37861a84e Merge: caf325ab81be0b 2f8e3cad53b5c3 Author: Linus Torvalds Date: Thu Aug 20 14:49:34 2026 -0700 Merge tag 'm68k-for-v7.3-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k Pull m68k updates from Geert Uytterhoeven: - Fix backtraces for non-running tasks - Fix deadlock in show_cons_active() - defconfig updates * tag 'm68k-for-v7.3-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: m68k: nfcon: Do not call console_is_registered() in nfcon_device() m68k: Fix backtraces for non-running tasks m68k: defconfig: Update defconfigs for v7.2-rc1 m68k: amiga: Remove redundant amiga_reset() prototype commit 746fc0787f616da418ffc04a110296fe95d53491 Author: Mehrdad Afshari Date: Sat Aug 15 21:04:26 2026 -0700 net: usb: cdc_ncm: add Apple MacBook Pro USB product ID 0x1902 The cdc_devs[] quirk table special-cases the Mac CDC-NCM private interface personality only for USB product ID 0x1905. Some MacBook Pro models (e.g. M1 Max) connected over a USB4/Thunderbolt 3/4 cable to a host whose Thunderbolt controller lacks PCIe tunneling support (no NHI function, USB4-only mode) present themselves with product ID 0x1902 instead, using the same descriptor layout as 0x1905: a Communications control interface with zero endpoints (no interrupt/status endpoint) paired with a CDC Data interface, at interface numbers 0 and 2. Because 0x1902 is unmatched, these devices fall through to the generic cdc_ncm_info driver_info, which sets FLAG_LINK_INTR and therefore requires an interrupt endpoint on the control interface. Apple's private NCM interface never provides one, so cdc_ncm_bind() fails outright: cdc_ncm 2-1:1.0: bind() failure cdc_ncm 2-1:1.2: bind() failure and no network device is created, breaking Ethernet-over-USB4 between the Mac and any USB4 host lacking Thunderbolt PCIe tunneling. Add matching entries for 0x1902 alongside the existing 0x1905 ones, reusing apple_private_interface_info as with the other Mac ID. Signed-off-by: Mehrdad Afshari Signed-off-by: Jakub Kicinski commit caf325ab81be0bc22adf75248ecd22f52f01ad21 Merge: 55ab7e14222e5f 6afb0359965361 Author: Linus Torvalds Date: Thu Aug 20 14:46:50 2026 -0700 Merge tag 'loongarch-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch updates from Huacai Chen: - Add DIRECT_MAP_PHYSMEM_END definition - Expand module virtual address space to 2GB - Use current_stack_pointer in current_pt_regs() - BPF JIT enhancements such as kptr_xchg and timed may_goto - Some bug fixes and other small changes * tag 'loongarch-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: selftests/bpf: Enable kptr_xchg_inline test on LoongArch LoongArch: BPF: Add arch_bpf_stack_walk() implementation LoongArch: BPF: Add timed may_goto implementation LoongArch: BPF: Resolve per-CPU addrs for internal-only MOV LoongArch: BPF: Advertise JIT support for kptr xchg inline LoongArch: BPF: Align value-returning atomics with LKMM LoongArch: BPF: Split unconditional branch JA paths statically LoongArch: BPF: Remove dead move_imm() call in BPF_NEG path LoongArch: BPF: Remove redundant zext jumping in move_imm() LoongArch: BPF: Implement branchless conditional move for TCC LoongArch: BPF: Refactor jump offset calculation in tail call LoongArch: BPF: Move arena register slot below TCC context LoongArch: BPF: Optimize redundant TCC loads in epilogue LoongArch: Use current_stack_pointer in current_pt_regs() LoongArch: Use generic cmp_int() instead of custom cmp_3way() LoongArch: Expand module virtual address space to 2GB LoongArch: Add DIRECT_MAP_PHYSMEM_END definition LoongArch: Fix acpi_package_ids[] array overflow commit f8e43fe0f22b7137ce456e6fe3581d3098174f74 Author: Runyu Xiao Date: Tue Aug 18 21:53:18 2026 +0800 fbdev: omapfb: panel-dsi-cm: initialize lock before registering display dsicm_probe() registers the display before initializing ddata->lock. Once omapdss_register_display() publishes the display, another consumer can reach a dsicm callback that takes this mutex while it is still uninitialized. Initialize the mutex before registering the display so the published callbacks always see a valid lock. Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Signed-off-by: Helge Deller commit f74cf70e5e78a43bd316e5c8e371caea0a49c207 Author: Ajith P V Date: Tue Aug 18 11:17:22 2026 +0000 fbdev: viafb: refactor strcpy and viafb_name Eliminate the single-use file-scope variable `viafb_name` and pass the "Via" string literal directly to strcpy(). Since "Via" is a literal constant, the compiler safely executes compile-time bounds checking during fortify verification. This satisfies the security initiative requirements while minimizing code complexity. Signed-off-by: Ajith P V Signed-off-by: Helge Deller commit ba13226fc966004713aed47931db8922b84d1960 Author: BingKun Yue Date: Mon Aug 17 14:39:42 2026 +0800 fbdev: platinumfb: add error checking for ioremap calls The ioremap() and ioremap_wt() calls in platinumfb_probe() were not checked for failure. If any of these mappings fail, the driver would dereference NULL pointers, leading to a kernel panic. Add proper error checking and use goto-based cleanup to avoid code duplication across the error paths. Signed-off-by: BingKun Yue Signed-off-by: Helge Deller commit 772bd1a84288e07d2621108473c96602c3d6b6bb Author: Randy Dunlap Date: Fri Aug 14 11:42:34 2026 -0700 fbdev: maxine: use MODULE_LICENSE() unconditionally This driver cannot be built as a loadable module so testing for "#ifdef MODULE" is not appropriate here. Also, MODULE_LICENSE() is always available. Signed-off-by: Randy Dunlap Acked-by: Maciej W. Rozycki Signed-off-by: Helge Deller commit c761c0400fb7785672a5df5b21518f1dfd8fc81a Author: Randy Dunlap Date: Thu Aug 13 19:56:40 2026 -0700 fbdev: maxine: fix maxinefb_init() return value A driver should return a negative error code on failure of its module_init() function so that the system recognizes the failure. Change the "return 1" to "return -ENODEV". Suggested-by: sashiko-bot@kernel.org Link: https://sashiko.dev/#/patchset/20260809234810.982500-1-rdunlap@infradead.org?part=1 Signed-off-by: Randy Dunlap Acked-by: Maciej W. Rozycki Signed-off-by: Helge Deller commit 3adec5c640dc09dca5605043e138412fd5a0629d Author: Randy Dunlap Date: Thu Aug 13 16:29:34 2026 -0700 fbdev: maxine: fix 64-bit build error The KSEG1ADDR() macro is only defined for non-64BIT builds. Use the CKSEG1ADDR() macro instead. In file included from ../drivers/video/fbdev/maxinefb.c:34: ../drivers/video/fbdev/maxinefb.c: In function 'maxinefb_ims332_write_register': ../include/video/maxinefb.h:16:41: error: implicit declaration of function 'KSEG1ADDR'; did you mean 'CKSEG1ADDR'? [-Wimplicit-function-declaration] 16 | #define MAXINEFB_IMS332_ADDRESS KSEG1ADDR(0x1c140000) ../drivers/video/fbdev/maxinefb.c:66:49: note: in expansion of macro 'MAXINEFB_IMS332_ADDRESS' 66 | register unsigned char *regs = (char *) MAXINEFB_IMS332_ADDRESS; ../drivers/video/fbdev/maxinefb.c:66:40: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 66 | register unsigned char *regs = (char *) MAXINEFB_IMS332_ADDRESS; Signed-off-by: Randy Dunlap Acked-by: Maciej W. Rozycki Signed-off-by: Helge Deller commit 47eb05e731fbef11dc36e9a9a9a05e61d43480ae Author: Randy Dunlap Date: Thu Aug 13 16:29:33 2026 -0700 fbdev: maxine: elide an unused function maxinefb_ims332_read_register() is not used, but since it describes a hardware interface, leave it in the source file as documentation and surround it inside an #if 0/#endif block. ../drivers/video/fbdev/maxinefb.c:74:21: warning: 'maxinefb_ims332_read_register' defined but not used [-Wunused-function] 74 | static unsigned int maxinefb_ims332_read_register(int regno) Signed-off-by: Randy Dunlap Acked-by: Maciej W. Rozycki Signed-off-by: Helge Deller commit 311f2c770d6786a1b835d544196c345b0f9d7767 Author: Randy Dunlap Date: Thu Aug 13 16:29:32 2026 -0700 fbdev: maxine: make functions static Make 3 functions static so that they don't need to be declared in a header file. ../drivers/video/fbdev/maxinefb.c:64:6: warning: no previous prototype for 'maxinefb_ims332_write_register' [-Wmissing-prototypes] 64 | void maxinefb_ims332_write_register(int regno, register unsigned int val) ../drivers/video/fbdev/maxinefb.c:74:14: warning: no previous prototype for 'maxinefb_ims332_read_register' [-Wmissing-prototypes] 74 | unsigned int maxinefb_ims332_read_register(int regno) ../drivers/video/fbdev/maxinefb.c:114:12: warning: no previous prototype for 'maxinefb_init' [-Wmissing-prototypes] 114 | int __init maxinefb_init(void) Signed-off-by: Randy Dunlap Acked-by: Maciej W. Rozycki Signed-off-by: Helge Deller commit 511585987d27d8cb668acebd399fc4deda23404c Author: Marek Czernohous Date: Thu Aug 13 01:13:27 2026 +0200 drm/nouveau: unsubscribe the channel-kill event before the fence context nouveau_channel_del() tears the fence context down first and only drops the channel-kill subscription later, in the middle of the nvif object teardown: if (chan->fence) nouveau_fence(chan->cli->drm)->context_del(chan); ... nvif_object_dtor(&chan->vram); nvif_event_dtor(&chan->kill); The subscribed handler is nouveau_channel_killed(), which calls nouveau_channel_kill() and from there nouveau_fence_context_kill() on chan->fence. A kill event delivered in that window takes fctx->lock and walks fctx->pending on a fence context that context_del() has already freed. Nothing reaches this below Fermi today, because the subscription is gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On Fermi and newer the window is real but narrow, since a kill has to land exactly while the channel is being destroyed. That is reason enough on its own, which is why this carries a Fixes: tag. The last patch in this series subscribes Tesla channels as well; nothing kills those today, so it does not widen the exposure now, but it is the groundwork for a recovery path that would, and the ordering is better fixed before that lands than alongside it. Drop the subscription before anything it depends on is torn down. Fixes: ea13e5abf807 ("drm/nouveau: signal pending fences when channel has been killed") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Marek Czernohous Fixes: ea13e5abf807 ("drm/nouveau: signal pending fences when channel has been killed") Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260812231330.705425-2-mczernohous@gmail.com commit e264c048709469096f3927fcd35a2c45f9e38eb8 Merge: 5ee0ceddc7785c b824059a673b22 Author: Jakub Kicinski Date: Thu Aug 20 14:23:07 2026 -0700 Merge branch 'bridge-vxlan-fix-reading-neigh-ha-without-synchronization' Nikolay Aleksandrov says: ==================== bridge/vxlan: fix reading neigh ha without synchronization Neigh ha address must be read using the seqlock to get a stable snapshot. Both the bridge and vxlan read it directly and can see partial updates. I reproduced both issues with running neigh updates and exercising these paths in parallel and saw partial addresses, e.g. updating between neigh A: 02:00:00:00:00:00 neigh B: fe:ff:ff:ff:ff:ff was able to observe 02:00:ff:ff:ff:ff and fe:ff:00:00:00:00 in packets. Noticed this initially in the bridge, then checked vxlan and its arp/neigh_reduce functions have the same bug, route_shortcircuit is doing the right thing already. ==================== Link: https://patch.msgid.link/20260818150756.890025-1-razor@blackwall.org Signed-off-by: Jakub Kicinski commit b824059a673b2283e78c7aae2c7d257aad7f0e1d Author: Nikolay Aleksandrov Date: Tue Aug 18 18:07:56 2026 +0300 vxlan: fix reading neigh ha 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 commit 57549ab9079122991dfa0f8248ca00e101e8e69b Author: Nikolay Aleksandrov Date: Tue Aug 18 18:07:55 2026 +0300 net: bridge: arp/nd proxy: fix reading neigh ha 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 commit cb258d651d747a7f7063d40f145418bee562ceaf Author: Shibo Zhu <3499129952@qq.com> Date: Wed Aug 19 00:18:39 2026 +0800 PM: sleep: Unblock runtime PM when device prepare fails device_prepare() blocks runtime PM for a device with runtime PM disabled before invoking its system-sleep ->prepare() callback. For a device that has never enabled runtime PM, this changes dev->power.last_status from RPM_INVALID to RPM_BLOCKED. If the callback returns an error, dpm_prepare() does not move the device to dpm_prepared_list. Consequently, the recovery path through dpm_complete() never calls device_complete() for the failing device. The error path drops the runtime PM usage reference, but does not clear RPM_BLOCKED. A later legitimate pm_runtime_enable() then reports: Attempt to enable runtime PM when it is blocked before clearing the stale state. Call pm_runtime_unblock() on the prepare error path before dropping the runtime PM reference, matching the cleanup performed by device_complete(). The issue was reproduced with a platform test device whose ->prepare() callback returns -EIO while runtime PM has never been enabled. Before the fix, last_status remained RPM_BLOCKED after the failed suspend and the first pm_runtime_enable() produced the warning above. With the fix, last_status is restored to RPM_INVALID and the warning is absent. Fixes: 3e5eee147b7b ("PM: Block enabling of runtime PM during system suspend") Cc: All applicable Signed-off-by: Shibo Zhu <3499129952@qq.com> Link: https://patch.msgid.link/tencent_C5AC0A02FC01F700E764F8C2E3ECE4F41009@qq.com Signed-off-by: Rafael J. Wysocki commit 5ee0ceddc7785c6dcf4a8107fef01f0414a354f4 Author: Mahanta Jambigi Date: Tue Aug 18 09:39:43 2026 +0200 net/smc: free pending qentry in smc_llc_flow_stop() before memset smc_llc_flow_stop() resets a flow struct with a blind memset: spin_lock_bh(&lgr->llc_flow_lock); memset(flow, 0, sizeof(*flow)); flow->type = SMC_LLC_FLOW_NONE; spin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op. Fixes: 555da9af827d ("net/smc: add event-based llc_flow framework") Reviewed-by: Hidayath Khan Signed-off-by: Mahanta Jambigi Link: https://patch.msgid.link/20260818073943.1108383-1-mjambigi@linux.ibm.com Signed-off-by: Jakub Kicinski commit 036322025d6e440cb75fc6fecbba9a16b271a2ae Author: Mahanta Jambigi Date: Tue Aug 18 09:31:07 2026 +0200 net/smc: free stashed qentry before overwrite in REQ_ADD_LINK to ADD_LINK transition When smc_llc_event_handler() transitions the local LLC flow from SMC_LLC_FLOW_REQ_ADD_LINK to SMC_LLC_FLOW_ADD_LINK on arrival of an ADD_LINK request, it calls smc_llc_flow_qentry_set() unconditionally: if (lgr->llc_flow_lcl.type == SMC_LLC_FLOW_REQ_ADD_LINK) { lgr->llc_flow_lcl.type = SMC_LLC_FLOW_ADD_LINK; smc_llc_flow_qentry_set(&lgr->llc_flow_lcl, qentry); ... } A CONFIRM_LINK or ADD_LINK_CONT arriving while flow->type is SMC_LLC_FLOW_REQ_ADD_LINK is stashed into flow->qentry via the SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT handler (which stores into flow->qentry for any non-NONE flow type). When the subsequent ADD_LINK arrives, the REQ_ADD_LINK branch overwrites flow->qentry with the new pointer without first freeing the stashed allocation, leaking one kmalloc object. The stashed entry has no consumer: smc_llc_wait() is only called from llc_add_link_work, which is not yet scheduled while the flow type remains REQ_ADD_LINK. No waiter is sleeping on llc_msg_waiter at this point. It is safe to unconditionally free any stashed qentry before the overwrite. Call smc_llc_flow_qentry_del() before smc_llc_flow_qentry_set() in the REQ_ADD_LINK branch. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal path where no entry is stashed is a no-op. Fixes: b4ba4652b3f8 ("net/smc: extend LLC layer for SMC-Rv2") Reviewed-by: Hidayath Khan Signed-off-by: Mahanta Jambigi Link: https://patch.msgid.link/20260818073107.466506-1-mjambigi@linux.ibm.com Signed-off-by: Jakub Kicinski commit a8b842366f8ff469fe0fc700ba53770ded847ea9 Author: Li, Yifan Date: Fri Aug 14 11:10:08 2026 +0800 powercap: intel_rapl: Sign-extend the PMU delta on counter wraparound The RAPL PMU misreports energy when the hardware energy counter overflows and wraps back to zero. perf event counts are defined to increase monotonically, but a single wraparound makes the PMU event count jump backwards by nearly the full counter range, and consumers that take the difference of two reads in unsigned arithmetic then underflow and report an absurd value. On a Panther Lake system (energy unit 61.035 uJ, counter range 262144 J) the package counter wraps every ~2.9 hours at 25 W, and turbostat prints one bogus sample per wraparound, per domain: PkgTmp PkgWatt CorWatt GFXWatt RAMWatt SysWatt 44 24.97 16.30 3.90 1.87 2145386370.35 43 2145240612.10 16.13 4.02 1.91 40.46 The RAPL energy counters are 32-bit wide on every register interface: MSR, MMIO and TPMI all describe ENERGY_COUNTER with a GENMASK(31, 0) mask. rapl_read_data_raw() applies that mask, so event_read_counter() returns the counter zero-extended in a u64. rapl_event_update() then computes delta = new_raw_count - prev_raw_count; without reducing the result modulo 2^32. While the counter does not wrap this is correct, but once the hardware counter wraps, new_raw_count < prev_raw_count and delta becomes (true_delta - 2^32), a large negative value. Declaring delta as s64 only makes that value representable; it does not correct it. That bogus delta is scaled and added to event->count, which is where the backwards jump comes from. Fix it the way arch/x86/events/rapl.c has done since the RAPL PMU was first introduced: shift both values up so that the 64-bit subtraction reduces modulo 2^32, then shift the difference back down with an arithmetic shift to sign-extend it. This is correct as long as at most one wraparound happens between two updates, which the existing overflow hrtimer already guarantees: its period is half of the counter range at the 200 W reference used in rapl_package_add_pmu_locked(). The problem has been present since the powercap RAPL PMU was added, but only affected TPMI RAPL until commit 748d6ba43afd ("powercap: intel_rapl: Enable MSR-based RAPL PMU support") routed MSR RAPL through the same PMU, which exposed it on client platforms such as Panther Lake. Fixes: 575024a8aa7c ("powercap: intel_rapl: Introduce APIs for PMU support") Reported-by: Jyoti, Anand B Signed-off-by: Li, Yifan Signed-off-by: Gao Jianfeng Tested-by: Jyoti, Anand B Acked-by: Srinivas Pandruvada Reviewed-by: Kuppuswamy Sathyanarayanan Link: https://patch.msgid.link/20260814031008.750911-1-yifan2.li@intel.com Signed-off-by: Rafael J. Wysocki commit f2849b1fd059ec9b3281b771e6ac5aad9feee851 Author: Christian Marangi Date: Mon Aug 17 23:30:03 2026 +0200 net: phylink: correctly validate returned PCS in phylink_inband_caps In phylink_inband_caps(), the PCS returned by mac_select_pcs is only checked if NULL but mac_select_pcs can also return an error pointer. This can cause a kernel panic as phylink_pcs_inband_caps() only checks if passed PCS is not NULL and directly dereference ops from the phylink_pcs struct. Use the IS_ERR_OR_NULL macro to address both case where the returned PCS can be NULL or an error pointer and prevent a kernel panic. Cc: stable@vger.kernel.org Fixes: df874f9e52c3 ("net: phylink: add pcs_inband_caps() method") Signed-off-by: Christian Marangi Link: https://patch.msgid.link/20260817213009.13924-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski commit 55ab7e14222e5f0b0fd9f7711ca391d2924b35e3 Merge: f5437ff7299e47 326d49039c10b6 Author: Linus Torvalds Date: Thu Aug 20 13:55:16 2026 -0700 Merge tag 'for-7.3/block-20260819' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull block updates from Jens Axboe: - NVMe updates via Keith: - Enable Clang context analysis for the nvme host driver, adding context annotations across core, fabrics, rdma, tcp and pci - nvmet reservation state exposed through a new namespace-level debugfs directory, plus ABI documentation for the host sysfs and target configfs interfaces - nvme-tcp host memory disclosure fixes on the read path: reject a read that transferred too few bytes, don't accept C2HData based on blk_rq_payload_bytes() alone, and fix the R2T case for a read command - Parallelize nvme-rdma I/O queue allocation and startup (Surabhi) - Apple nvme fixes and quirks: page aligned admin queue buffers, destroy the admin queue on removal, and various DMA/NVMMU correctness fixes - A large pile of nvmet and host fixes for out-of-bounds reads, refcount/resource leaks, and NULL derefs across auth, zns, passthru, pci-epf, rdma and configfs - Various other fixes and cleanups - MD updates via Yu Kuai: - llbitmap reshape support, the large series wiring exact bitmap mapping and reshape lifecycle through raid5 and raid10, growing the page cache in place, and remapping checkpointed bits as reshape progresses - raid5 fixes for lockless max_nr_stripes and recovery_offset accesses, a reshape deadlock with more failed devices than max degraded, and bitmap batch counter consistency - Atomic write handling for raid1/raid10, and removal of the REQ_NOWAIT support from raid1/10/456 - raid5-ppl use-after-free fix in ppl_do_flush() - A batch of smaller fixes across md core and the bitmap code - s390/dasd ESE full-track write support and the surrounding infrastructure, plus enabling CONTEXT_ANALYSIS for s390/block - RWF_DONTCACHE support for block devices, built on new task-context bio completion infrastructure, and wiring it up for the iomap and buffer dropbehind writeback paths - Async io_uring zone reset all, plus zone management command cleanups allowing REQ_NOWAIT and tightening conventional zone rejection - Block integrity refactoring: lift BIP_CHECK_FLAGS to the shared header, handle nogenerate/noverify properly in fs-integrity, and drop the blk-integrity.h include from bdev.c - Split out a new blk_plug.h header - ublk improvements: add UBLK_F_IO_DESC_SIZE, split request validation from io_desc init, reject non-power-of-2 zone sizes in SET_PARAMS, and a series of hardening fixes around map/unmap and auto buf reg - null_blk cleanups and configfs serialization fixes - nbd queue freeze removal on the setup paths, and a new pre_defined_connections module parameter for pre-created devices - blk-cgroup fixes for the race between policy activation and blkg destruction, and accounting per-cpu stats over possible CPUs across blk-stat, iolatency, iocost and kyber - Various dio fixes: leak on metadata mapping error, validate user space vectors during extraction, and set dma_alignment from the backing file for loop and zloop direct I/O - bio cleanups - Various other fixes and cleanups all over * tag 'for-7.3/block-20260819' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: (241 commits) nbd: add pre_defined_connections module parameter for pre-created devices nbd: remove queue freeze for newly created nbd from netlink path nbd: factor out a nbd_genl_foreach_sock nbd: skip queue freeze when setting size at device startup nbd: remove queue freeze in nbd_add_socket nbd: clear queue limits on disconnect nbd: disallow NBD_SET_SOCK on an active device nbd: simplify find_fallback() by removing redundant logic blk-mq: add missing call to srcu_barrier() in blk_mq_free_tag_set() block: mtip32xx: synchronize ioctls with device removal ublk: avoid teardown retry loop on xarray allocation failure null_blk: fix UBSAN shift-out-of-bounds when zone_size is 0 or overflows block: don't include blk-integrity.h in bdev.c xfs: avoid double deferrals for RWF_DONTCACHE writes loop: Fix recently introduced lock inversion block: set QUEUE_FLAG_DYING unconditionally in blk_mark_disk_dead() swim3: Add missing MODULE_DESCRIPTION selftests: ublk: add SET_PARAMS validation test selftests: ublk: add helper for SET_PARAMS ublk: reject non-power-of-2 zone sizes in SET_PARAMS ... commit f5437ff7299e47e76e52d37a2937a4b0f04e399f Merge: c84d3e3130dfe1 881dc9dd66d236 Author: Linus Torvalds Date: Thu Aug 20 13:47:56 2026 -0700 Merge tag 'for-7.3/io_uring-20260819' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull io_uring update from Jens Axboe: "On top of the usual cleanups and fixes, the bigger items in here are: - zcrx work, most of it centered around adding dynamic area provisioning, plus a bunch of prep and cleanups leading up to it: scale refilling with large pages, coalesce same-niov RQEs on refill, separate the RQ head/tail cache lines and cache the RQ tail, and rework the area creation locking. - Fix the futex inflight accounting so that only private futex waits are marked inflight, and don't mark wake requests as inflight at all. - Drop the custom iov copy in the buffer select prep and msg header copy paths, using the generic helpers instead. - Fix a folio size overflow in io_vec_fill_bvec(), and account the pages a compound region really uses in the memmap path. - Fix an iovec leak in uring_cmd when the async cmd isn't recycled, skip the blocking task work for io_uring_cmd_issue_blocking(), and don't skip completion for a synchronous multishot cmd - Defer eventfd signaling when queued from a wakeup handler - Fix io-wq worker accounting when canceling creation callbacks - Annotate remote tasks for kcoverage" * tag 'for-7.3/io_uring-20260819' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: (30 commits) io_uring: Add missing include for ITER_SOURCE and ITER_DEST io_uring/uring_cmd: don't skip completion for a synchronous multishot cmd io_uring/memmap: account the pages a compound region really uses io_uring/zcrx: add dynamic area provisioning io_uring/zcrx: lock area creation with pp_lock io_uring/zcrx: keep array of areas io_uring/zcrx: move freelist lock to struct zcrx io_uring/zcrx: unmap under netdev lock io_uring/zcrx: split dmabuf unmap and release io_uring/zcrx: don't pass ifq_reg to area creation io_uring/zcrx: add helper for deriving area token io_uring/zcrx: don't reload skb_shinfo io_urint/zcrx: narrow var scope in io_zcrx_recv_skb() io_uring/zcrx: constify area_reg on import io_uring/zcrx: coalesce same-niov RQEs on refill io_uring/zcrx: cache RQ tail io_uring/zcrx: add RQ iterator io_uring/zcrx: move RQ head/tail to separate cache lines io_uring/zcrx: scale refilling with large pages io_uring/io-wq: fix worker accounting when canceling creation callbacks ... commit 52ffb39e710db4b08cb0434741b96a9baf1a1934 Merge: 8197c180052fe5 a4f2387db6f1cc Author: Jakub Kicinski Date: Thu Aug 20 13:43:26 2026 -0700 Merge branch 'net-ntb_netdev-fix-tx-completion-and-error-handling' Koichiro Den says: ==================== net: ntb_netdev: Fix TX completion and error handling This small series fixes several TX buffer ownership and queue handling bugs in ntb_netdev and ntb_transport. Patch 4 first appeared in my "NTB: Add direct TX/RX using PCI endpoint DMA" series. Sashiko later reported the same pre-existing leak while reviewing another series, so I moved the fix here. See: https://lore.kernel.org/r/20260815032932.151F11F000E9@smtp.kernel.org/ The ntb_transport fixes affect buffer ownership and queue handling in ntb_netdev, the only in-tree ntb_transport_client implementation, so the patches need to go in together. I am targeting the net tree for the series. ==================== Link: https://patch.msgid.link/20260817053519.4135287-1-den@valinux.co.jp Signed-off-by: Jakub Kicinski commit a4f2387db6f1cc2f03abba7f3a6807ad61e26ff7 Author: Koichiro Den Date: Mon Aug 17 14:35:19 2026 +0900 NTB: ntb_transport: Reject oversized TX buffers ntb_process_tx() handles an oversized buffer by calling tx_handler() with a NULL data pointer and returning success. ntb_netdev therefore neither frees the skb in its completion callback nor takes its enqueue error path, leaking it. Reject oversized buffers in ntb_transport_tx_enqueue() before acquiring a queue entry and return -EMSGSIZE. The caller retains ownership of the buffer, and the preceding netdev patch frees the skb when enqueue returns this permanent error. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260817053519.4135287-5-den@valinux.co.jp Signed-off-by: Jakub Kicinski commit 873ce713fef5dde0939220f04f3484ec86a16fba Author: Koichiro Den Date: Mon Aug 17 14:35:18 2026 +0900 NTB: ntb_transport: Fail TX enqueue when the QP link is down Commit f195a1a6fe41 ("ntb: Drop packets when qp link is down") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller. With the preceding patch, ntb_netdev frees the skb on non-retryable enqueue failures and returns NETDEV_TX_OK, so a packet racing with link-down is dropped without leaking or entering a busy retry loop. Fixes: f195a1a6fe41 ("ntb: Drop packets when qp link is down") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260817053519.4135287-4-den@valinux.co.jp Signed-off-by: Jakub Kicinski commit 8aaa47351db0f93a5c5297fbafdfa8bc75e8ae49 Author: Koichiro Den Date: Mon Aug 17 14:35:17 2026 +0900 net: ntb_netdev: Fix TX busy and drop handling Currently, ntb_netdev returns NETDEV_TX_BUSY for every enqueue error. It also increments the drop and error counters while leaving the skb owned by the qdisc, and may return BUSY with the subqueue still awake. Retrying a permanent error cannot succeed either. The unconditional BUSY return and premature accounting date back to the initial driver. The error-path queue stop was later removed without changing that return value. The current flow-control code includes a resource check, but ntb_netdev does not honor its result before enqueue. Honor the resource check before enqueue. For -EAGAIN and -EBUSY, stop the subqueue, arm the existing reaper timer, and return BUSY without touching the skb. For other errors, free the skb, increment tx_dropped, and return NETDEV_TX_OK. Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device") Fixes: d723485cb4ca ("ntb_netdev: remove tx timeout") Fixes: e74bfeedad08 ("NTB: Add flow control to the ntb_netdev") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260817053519.4135287-3-den@valinux.co.jp Signed-off-by: Jakub Kicinski commit 256496397287334a19ed80ec7be92bffcae76b9d Author: Koichiro Den Date: Mon Aug 17 14:35:16 2026 +0900 NTB: ntb_transport: Recycle TX entries before client callbacks ntb_tx_copy_callback() invokes the client callback before returning the entry to tx_free_q. The callback may wake a stopped client queue, only for the next enqueue to find no local entry and return -EBUSY. The window is narrow, but the retry is unnecessary. Save the callback data and length, then return the entry to tx_free_q before invoking the client. A completion callback then means both the client buffer and transport entry are ready for reuse. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260817053519.4135287-2-den@valinux.co.jp Signed-off-by: Jakub Kicinski commit 8197c180052fe5ee644e91b31d98328bea8a31ed Author: Stefan Wahren Date: Tue Aug 18 15:59:58 2026 +0200 docs: oa-tc6-framework: Fix link to specification Current link for 10BASE-T1x MAC-PHY Serial Interface Specification doesn't work - it returns 404. Update the link to the working one. Signed-off-by: Stefan Wahren Acked-by: Randy Dunlap Link: https://patch.msgid.link/20260818135958.17311-1-wahrenst@gmx.net Signed-off-by: Jakub Kicinski commit 03a9d10ecf71f54b2af8020935f2033d4a132be5 Author: Hyunwoo Kim Date: Wed Aug 19 10:38:37 2026 +0900 sctp: drop a chunk if its transport was removed sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed. An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock(). The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state. Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Acked-by: Xin Long Link: https://patch.msgid.link/aoUJHQmxL0LFIMCw@v4bel Signed-off-by: Jakub Kicinski commit 25b863cd6d12ec196115ff7a5422c69995443466 Author: Triet Hoang Date: Tue Aug 18 13:27:39 2026 +0000 tools: ynl: handle calloc failure in ynl_ntf_parse Check the return value of calloc() before dereferencing the allocated response structure in ynl_ntf_parse(). Signed-off-by: Triet Hoang Link: https://patch.msgid.link/20260818132739.469624-1-triet.hoang.dev@gmail.com Signed-off-by: Jakub Kicinski commit 4c660ee8c809637909f4f7eb1017f7b9401c75c4 Author: Jamal Hadi Salim Date: Tue Aug 18 05:59:27 2026 -0400 net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue gred_enqueue(), bfifo_enqueue() and plug_enqueue() admit a packet when the current backlog plus the packet length fits within the queue limit: sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (gred default VQ) gred_backlog+qdisc_pkt_len(skb) <= q->limit (gred configured VQ) sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo) sch->qstats.backlog + skb->len <= q->limit (plug) sch->qstats.backlog and q->backlog are u32, and qdisc_pkt_len()/skb->len are unsigned int, so all sums are computed in 32 bits and wrap at 2^32. Once the true backlog exceeds 4 GiB the wrapped sum becomes small and admission keeps succeeding, so the queue grows without bound and the kernel can be driven to OOM. Promote the sums to u64 so admission stops once the true backlog exceeds the limit. The limit is u32, so the bounded queue stays below 2^32 and the stored u32 backlog never wraps. The bug can only be reproduced as root (albeit with ridiculous setup): attach a gred (or bfifo/plug) qdisc with a limit near 4 GiB, leaving the default VQ unconfigured (for gred), and drive >4 GiB of queued traffic (e.g. via a size table / stab to inflate qdisc_pkt_len, or sustained high-rate traffic). The u32 backlog+len sum wraps at 2^32, admission keeps succeeding, and the queue grows unboundedly to OOM. Fixes: a3eb95f891d6 ("net_sched: gred: add TCA_GRED_LIMIT attribute") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260818095927.15901-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski commit d9c56501c72fdac937e8b770f31655c46832f1a5 Author: Mina Almasry Date: Fri Aug 14 19:13:31 2026 +0000 net: tcp: block mixing readable and unreadable frags Protect tcp_sendmsg_locked() from mistakenly mixing readable and unreadable page fragments in the same SKB. Check that the devmem binding matches the existing SKB's readability. If a mismatch is detected, avoid collapsing and create a new segment. Fixes: bd61848900bff ("net: devmem: Implement TX path") Suggested-by: Eric Dumazet Cc: Pavel Begunkov Cc: Stanislav Fomichev Cc: Bobby Eshleman Signed-off-by: Mina Almasry Link: https://patch.msgid.link/20260814191336.187243-2-almasrymina@google.com Signed-off-by: Jakub Kicinski commit 68d8c6532659168430e489bb659c0d41de7d75fe Author: Mina Almasry Date: Fri Aug 14 19:13:30 2026 +0000 net: core: propagate unreadable flag in skb_zerocopy skb_zerocopy() fails to propagate the unreadable flag when copying unreadable fragments, causing target skbs to appear as readable memory. This patch fixes the flag propagation. Additionally, it returns -EFAULT if readable fragments are mixed with unreadable fragments during extraction, and returns -EFAULT in openvswitch queue_userspace_packet(). Fixes: 65249feb6b3d ("net: add support for skbs with unreadable frags") Cc: Stanislav Fomichev Cc: Bobby Eshleman Cc: Florian Westphal Cc: Aaron Conole Cc: Eelco Chaudron Cc: Willem de Bruijn Signed-off-by: Mina Almasry Reviewed-by: Pavel Begunkov Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/20260814191336.187243-1-almasrymina@google.com Signed-off-by: Jakub Kicinski commit 992cc9f94ca924089a506ba9b327caa9af797529 Author: Kyle Zeng Date: Sun Aug 16 16:56:46 2026 -0700 net/packet: defer vmalloc TX_RING free until skbs finish AF_PACKET TX_RING skbs keep a raw pointer to their ring frame. The skb page references preserve page-backed ring blocks after pg_vec is freed, but they do not preserve a vmalloc mapping. tpacket_destruct_skb() currently drops the pending reference before writing the timestamp and TP_STATUS_AVAILABLE to the frame. Move the decrement after those stores. The smp_wmb() in __packet_set_status() orders the frame stores before the decrement. Also recheck pending TX frames under pg_vec_lock before non-closing ring replacement, so a racing send cannot add a pending skb between the initial check and the ring swap. Ring allocation can produce a mixture of page-backed and vmalloc-backed blocks. Allocate deferred-work storage during TX ring setup when the first vmalloc-backed block is encountered, and keep its pointer in the pg_vec allocation header. If allocation fails, return -ENOMEM from ring setup. On socket close, a non-NULL pointer identifies a vmalloc-backed vector without a scan. If TX skbs remain, defer the whole vector to system_long_wq. After pg_vec is detached, a late destructor can skip the pending decrement. Use socket write-memory accounting as the deferred lifetime gate instead: an skb remains charged through its final sock_wfree(), after all ring-frame accesses. The delayed work retains a socket reference and reschedules itself until no TX skbs remain. Move pending_refcnt release to packet_sock_destruct() so late skb destructors and deferred cleanup can safely use it after packet_release(). Page-backed teardown remains synchronous, and no lock is added to the TX completion hot path. Fixes: b013840810c2 ("packet: use percpu mmap tx frame pending refcount") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netdev/20260721015824.45829-1-kylebot@openai.com/ Suggested-by: Eric Dumazet Suggested-by: Willem de Bruijn Reviewed-by: Willem de Bruijn Signed-off-by: Kyle Zeng Link: https://patch.msgid.link/20260816235646.76500-1-kylebot@openai.com Signed-off-by: Jakub Kicinski commit c84d3e3130dfe1058cb27dc78e7ad8bd36f0545a Merge: 50c44fea13ec33 9091c97be34083 Author: Linus Torvalds Date: Thu Aug 20 13:17:11 2026 -0700 Merge tag 'ext4_for_linus-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 Pull ext4 updates from Ted Ts'o: - Improve performance by allowing parallel DIO writes when we were previously being overly conservative when checking whether it was safe to avoid requiring an exclusive lock - Improve the performance of ext4_mb_prefetch() used by fallocate() by avoiding work when it is not needed - Remove the unnecessary custom end_io function ext4_end_buffer_io_sync() - Improve performance when performing an overwrite to an already uptodate folio - Clean up how we handle deallocating EA inodes to avoid a potential lock ordering issue when there is a failed mount while an EA inode is still being evicted - Use str_plural() instead of a custom macro - Avoid soft lockups or RCU stalls if there are many busy buffers (caused by heavy I/O) while checkpointing - Use scoped NOFS when starting a handle in nojournal mode - Align fields in handle structure to optimize setting and getting the h_type and h_line_no fields - Fix documentation of the meta_bg block group layout - Bug fixes: - Fix a potential out-of-bounds read in ext4_read_inline_dir() - Fix a potential deadlock when concurrent xattr operations are racing with each other when some of the xattrs are using the ea_inode feature - Fix a spurious warning with data=journal that can be triggered when writeback races with remounting the file system read-only - Fix a potential deadlock when EXT4_IOC_MIGRATE races with a file system freeze operation - Make sure all in-flight direct I/O operations are complete before falling back to buffered I/O - Handle IOCB_NOWAIT properly when performing a extending DAX write - Prevent potentially sleeping on a block allocation when IOCB_NOWAIT is set - Fix potential races when racing an inline data write with a page fault - Propagate errors when adding or removing extent ranges during a fast commit replay - Avoid trying to expand an inode's extra size when it is being evicted to avoid a number of corner case or deadlocks - Avoid spurious error when retrying inode extra size expansion - Fix corner cases where we underestimate the number of journal credits needed - Avoid hangs/crashes/WARNINGS caused by maliciously corrupted file systems - Don't issue spurious orphan clean message on RO file systems - Avoid leaving the file system in an inconsistent state after a crash when a WRITE_ZEROS in progress converting an unwritten extent to a written extent - Handle WRITE_ZEROS correctly when there are some partially dirtied regions in the page cache - Pass errors during zero-rage, truncate, or punch hole to the caller if ext4_get_block() fails - Wait for writeback to finish when triggered by zero-range or zero-range for those devices that require stable writes - If the reserved gid superblock field is set, set the reserved gid instead of the reserved uid * tag 'ext4_for_linus-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: (56 commits) ext4: fix estimate extent index blocks in ext4_ext_index_trans_blocks() ext4: fix transaction overflow during writeback ext4: teach ext4_meta_trans_blocks() about number of allocated extents ext4: guard against NULL s_group_info in ext4_get_group_info ext4: fix spurious message about orphan cleanup on RO fs ext4: stop retrying saturated xattr cache entries ext4: don't enable DAX on new encrypted files ext4: protect WRITE_ZEROES written extents with orphan list ext4: export converted block count from ext4_convert_unwritten_extents() ext4: fix incorrect function call when initializing s_resgid ext4: validate EA inode i_nlink in ext4_xattr_inode_iget jbd2: align h_type and h_line_no in the handle structure on byte boundaries ext4: enable scoped NOFS when starting a handle in nojournal mode ext4: write back partial-zeroed edges in WRITE_ZEROES ext4: zero out whole block for clean edges in WRITE_ZEROES ext4: track partial-zero outcome per edge in ext4_zero_partial_blocks() ext4: clarify return semantics of ext4_load_tail_bh() ext4: move partial block zeroing earlier in ext4_zero_range() ext4: check return value of ext4_get_block() in ext4_load_tail_bh() ext4: skip tail block zeroing for inline data files ... commit 51a26bb843251a7f003898d08a50138351658ebb Merge: 447cbe95ebb953 bb23acfd05f039 Author: Jakub Kicinski Date: Thu Aug 20 13:07:00 2026 -0700 Merge branch 'ionic_rcq_shared' of https://github.com/abhijitG-xlnx/linux Abhijit Gangurde says: ==================== Extend the net/ionic firmware identity structure to expose the rcq_sign_bit field from the RDMA LIF identity. * 'ionic_rcq_shared' of https://github.com/abhijitG-xlnx/linux: net: ionic: Fetch RCQ sign bit from firmware ==================== Link: https://patch.msgid.link/ Signed-off-by: Jakub Kicinski commit 447cbe95ebb95392b5d8f6a01c0556826919ce23 Author: Eric Dumazet Date: Tue Aug 11 08:52:46 2026 +0000 vlan: fix skb_under_panic and races when toggling HW VLAN offload Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(), which dynamically changed vlandev->hard_header_len. This causes two issues: 1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2) read dev->hard_header_len without holding RTNL lock. Mutating hard_header_len dynamically under RTNL creates a data race where upper layers reserve insufficient headroom based on a stale hard_header_len, resulting in skb_under_panic when vlan_dev_hard_header() is called. 2. In addition, vlan_transfer_features() updated hard_header_len without updating header_ops, causing a mismatch between allocated headroom and header creation. Always setting dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally ensures: - dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len, eliminating all dynamic runtime updates and data races on hard_header_len. - Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len + real_dev->needed_headroom + VLAN_HLEN). - vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV requirements are honored. - AF_PACKET SOCK_RAW network header offsets remain correctly aligned at real_dev->hard_header_len. - vlan_header_ops is used unconditionally. Note to stable teams: Make sure to backport these commits: e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") cef51860becd ("macvlan: inherit needed_headroom and needed_tailroom from lowerdev") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Tangxin Xie Closes: https://lore.kernel.org/netdev/99d678ae-c7b2-4b44-b534-b8320679deb3@h-partners.com/ Cc: # 3.19: e16e960d55a4: ipvlan: inherit needed_headroom and needed_tailroom from phy_dev Cc: # 3.19: cef51860becd: macvlan: inherit needed_headroom and needed_tailroom from lowerdev Cc: # 3.19 Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260811085246.2267779-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit d302d7109fb9c553bcd96adad7fa2918316c4cc2 Author: Zhan Xusheng Date: Tue Aug 18 10:37:04 2026 +0800 ethtool: remove unused __ETHTOOL_LINK_MODE_MASK_NWORDS From: Zhan Xusheng Added by commit f625aa9be8c1 ("ethtool: provide link mode information with LINKMODES_GET request") and never used. The same count is computed as __ETHTOOL_LINK_MODE_MASK_NU32 in net/ethtool/ioctl.c. Signed-off-by: Zhan Xusheng Link: https://patch.msgid.link/20260818023704.125721-1-zhanxusheng@xiaomi.com Signed-off-by: Jakub Kicinski commit 50c44fea13ec339d0d457079b254e8c8420d6511 Merge: 9328b3b03bdce0 4096e2a06f43fa Author: Linus Torvalds Date: Thu Aug 20 13:00:40 2026 -0700 Merge tag 'for-7.3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs updates from David Sterba: "This is the summer edition of btrfs changes, smaller than usual. Yet, there are performance improvements in various areas or for specific workloads and some notable changes like removing space cache v1 code or mount option reduction. User visible changes: - free space v1 disabled by default; the v2 (free space tree) is mkfs default since 5.15, filesystems with v1 still work but could be slightly slower due to lack of block group caching - mount option 'rescue=usebackuproot' requires read-only mount, it's too risky to allow writable mount - remove standalone mount option 'usebackuproot', deprecated in 5.9 - preserve constraints of NODATASUM and NODATACOW when chattr and mount options may change the attributes - remove arbitrary limitation of 4KiB for page size when allowing block sizes smaller than page - print messages when pinned block groups affect swap activation Performance improvements: - use iomap bounce buffer for direct io instead of a fall back to buffered io; past correctness vs speed trade-offs dropped performance to ~50% of theoretical maximum, now it's ~95%, effectively doubled - replace xarray with local LRU list for tracking inhibited extent buffers, restored performance to pre-inhibition state (relatively ~3x) - remove unnecessary 1 jiffy delay in "non-SSD" mode with multiple logging tasks, decrease latency, throughput increased ~5x on sample workload - skip hole detection during full fsync for files without holes and lots of extents, reduce run time ~5x on sample workload (microsecond ranges) - reduce locking around extent readahead so it does not slow down other tasks using an overlapping range - enhance extent buffer allocation modes to allow NOWAIT semantics in some cases Notable fixes: - write-protect folios during writeback, prevent concurrent mmap and compress/checksumming/etc undesired interactions - in zoned mode, handle transient overcommit full instead of going read-only - fix possible deadlock between defragmentation and delayed allocation reservations - handle remaining iputs at umount time - fix lockdep warning between device scan locking and log mutex - add workaround for degenerate RAID56 device count modes (2 and 3) not supported by the parity calculation library - restore check that subvolume is not read-only when changing ACLs - retry reading verity data colliding with up-to-date status changes Core: - simplify raid56 stripe handling by using contiguous virtual allocations - in zoned mode, fix various metadata write issues in writeback or unmount - space reservation fixes - remove unused data structure members - more auto-freeing conversions - error pointer values are printed using %pe format" * tag 'for-7.3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: (72 commits) btrfs: skip hole detection during full fsync for files without holes btrfs: add extra ASSERT()s to make sure the folio size is correct btrfs: use GFP_NOWAIT for tree block readahead btrfs: enable unlocked NOFAIL retry for eb allocations btrfs: add struct btrfs_eb_prealloc btrfs: factor init_extent_buffer from __alloc_extent_buffer btrfs: qgroup: fix a wrong length calculation in qgroup_free_reserved_data() btrfs: add validation for extent states btrfs: use aligned range for locking in reflink btrfs: use aligned range for locking in extent_fiemap() btrfs: zoned: don't clobber the extent buffer when zeroing it out btrfs: zoned: drop stranded dirty metadata buffers at unmount btrfs: zoned: drop stranded dirty metadata on transaction abort btrfs: zoned: flush active metadata block group at btree_writepages() start btrfs: convert reflink.c to use btrfs_inode as parameters btrfs: use simple booleans for log_commit field in struct btrfs_root btrfs: check for exit condition after waking in wait_log_commit() btrfs: move condition for log commit wait into wait_log_commit() btrfs: remove log batch counter use for fsync btrfs: stop sleeping for one jiffy in non-ssd mounts during log commit ... commit f12c2de4f542e3220e17e0606f492110064f04cb Author: Kyle Zeng Date: Mon Aug 17 08:49:54 2026 +0000 batman-adv: reject unrepresentable multicast TVLV offsets The network and transport header fields in struct sk_buff are 16-bit offsets from skb->head, and U16_MAX is reserved as the unset transport header value. batadv_tvlv_call_handler() sets both fields from a received multicast TVLV without checking whether the TVLV end is representable. If the end offset exceeds the field's range, skb_set_transport_header() truncates it so that the transport header precedes the network header. The negative difference is then returned by skb_network_header_len() as a large u32. batadv_mcast_forw_packet() consequently accepts an oversized multicast tracker and accesses memory beyond the skb data. Add skb_set_transport_header_careful(), an offset-aware counterpart to skb_reset_transport_header_careful(), which validates the final head-relative offset before assigning it. Use the new helper in batadv_tvlv_call_handler() and reject unrepresentable TVLVs before setting the network header. Fixes: 07afe1ba288c ("batman-adv: mcast: implement multicast packet reception and forwarding") Cc: stable@vger.kernel.org Signed-off-by: Kyle Zeng Co-developed-by: David Lee Signed-off-by: David Lee Acked-by: Sven Eckelmann Link: https://patch.msgid.link/20260817084955.944189-1-david.lee@trailofbits.com Signed-off-by: Jakub Kicinski commit 44930446dde45a7a90fe1446fa38eb0e2c561646 Author: Kyle Zeng Date: Mon Aug 17 08:58:38 2026 +0000 ipv6: seg6: clear IPv4 control block on IPIP decapsulation End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress. Fixes: 891ef8dd2a8d ("ipv6: sr: implement additional seg6local actions") Cc: stable@vger.kernel.org Suggested-by: Andrea Mayer Signed-off-by: Kyle Zeng Co-developed-by: David Lee Signed-off-by: David Lee Reviewed-by: Andrea Mayer Link: https://patch.msgid.link/20260817085839.946321-1-david.lee@trailofbits.com Signed-off-by: Jakub Kicinski commit 2ee66e9487172fcd189bc52a767c30dad7141c09 Author: Eric Dumazet Date: Tue Aug 18 15:12:13 2026 +0000 inetpeer: randomize RB-tree node comparison using SipHash The inetpeer rate limiting system stores peer entries in a Red-Black tree keyed deterministically on the remote IP address. Because tree lookups walk the RB-tree using standard lexicographical comparisons (inetpeer_addr_cmp), an off-path adversary can predict the exact topology of the tree and the sequence of nodes traversed during lookups (the gc_stack candidate list). By combining deterministic tree traversal with aggressive garbage collection (triggered when tree size exceeds inet_peer_threshold), an attacker can selectively force the eviction of targeted inet_peer nodes. When an evicted node is subsequently re-created upon receiving a new packet, its rate-limiting token bucket (rate_tokens, rate_last) is reset to full capacity. This creates a side-channel primitive allowing off-path attackers to bypass IP-keyed ICMP rate limits and infer open UDP ports (similar to SAD DNS style attacks). Mitigate this by randomizing the RB-tree node comparison logic using SipHash with a secret key (inetpeer_hash_key) initialized via net_get_random_once(). Nodes are ordered in the tree by SipHash(addr, key) rather than raw IP addresses. Because the secret key is unknown to external entities, the tree layout and lookup traversal paths are unpredictable to off-path adversaries, breaking the deterministic eviction gadget. Cache the computed 64-bit SipHash (hash) in struct inet_peer and compute the target hash (dhash) once at the beginning of inet_getpeer() to avoid recomputing SipHash at every step of the RB-tree walk. Fixes: b145425f269a ("inetpeer: remove AVL implementation in favor of RB tree") Reported-by: Michael Blunt Suggested-by: Michael Blunt Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260818151213.3953963-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit 235b42b5860189eb8c27c36435ad932cae65a734 Author: Eric Dumazet Date: Tue Aug 18 17:27:55 2026 +0000 ip6mr: do not clone dst in ip6mr_cache_report() 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 commit b878dfdd12d7a5b8722a78d35e313506140ca3d9 Author: Harshit Varu Date: Sat Aug 15 17:22:05 2026 +0530 mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields. Fixes: 9466a1ccebbe ("mptcp: enable JOIN requests even if cookies are in use") Cc: stable@vger.kernel.org Signed-off-by: Harshit Varu Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260815115205.197151-1-harshitvaru666@gmail.com Signed-off-by: Jakub Kicinski commit 9328b3b03bdce05f660dbf33a4183716a64e304f Merge: 81e51378b78a11 62333e480d12ab Author: Linus Torvalds Date: Thu Aug 20 12:52:35 2026 -0700 Merge tag 'fs_for_v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs Pull ext2, udf, isofs, and quota updates from Jan Kara: - Remove deprecated quota code printing warnings about exceeded quota directly to console - Various udf & isofs hardening for handling of corrupted filesystems - Fix a possible data loss in udf when converting files from inline to out-of-line format - Simplify EIO error handling in ext2 xattr code * tag 'fs_for_v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: udf: Fix data loss when converting inline inodes to out of line udf: Move udf_map_block() up ext2: Simplify error handling of IO error when adding xattr isofs: Drop support of directory entries straddling blocks isofs: validate directory records consistently quota: remove CONFIG_PRINT_QUOTA_WARNING code udf: Fix i_lenExtents truncation on 32-bit kernels isofs: release zisofs block pointer buffer head udf: Fix bh leak for unallocated space entries udf: bound lengthAllocDescs from unallocated space entry UDF symlink pathComponent header OOB read isofs: fix out-of-bounds page array access on empty zisofs block udf: reject VAT indexes equal to the entry count udf: Mark LVID buffer as uptodate before marking it dirty udf: avoid recursive s_alloc_mutex deadlock when freeing AED blocks udf: validate extent partition references in udf_current_aext() commit 5e8076e4e4124dae75a3e080ddc20404700d7585 Author: Pengpeng Hou Date: Sun Aug 16 13:21:09 2026 +0800 net: qlcnic: validate unified ROM sections before loading The unified ROM parser reads directory, product, and data-descriptor fields from the firmware file. Existing validation forms table and data ends with unchecked additions and multiplications. Malformed values can wrap before they are compared with the firmware size. The parser also dereferences typed pointers at firmware-controlled offsets. Valid descriptor extents alone are insufficient for the consumers. The loader reads a fixed-size bootloader regardless of its declared size, the version parser assumes a 17-byte tail, and a partial final firmware word is read as a full u64. A truncated image can therefore make the driver read beyond the firmware allocation during validation or loading. Replace the pointer-returning parser with bounded range helpers. Validate table entry sizes, descriptor indices, section ranges, the fixed bootloader load length, and the version tail before exposing any section. Read all file fields with unaligned little-endian accessors and assemble a partial final word from only the bytes that remain. Apply the same range checks to the legacy image before reading its fixed fields. Fixes: af19b49152bd ("qlcnic: Qlogic ethernet driver for CNA devices") Signed-off-by: Pengpeng Hou Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816052109.4607-1-pengpeng@iscas.ac.cn Signed-off-by: Jakub Kicinski commit 81e51378b78a11b168ffec08d80ff4b47e5b0227 Merge: d141ec2825b4d3 e422777fdd4746 Author: Linus Torvalds Date: Thu Aug 20 12:47:41 2026 -0700 Merge tag 'fsnotify_for_v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs Pull fsnotify updates from Jan Kara: "A couple of assorted fixes (mostly stuff spotted by Sashiko) for fsnotify subsystem. I'm also removing Matt as a reviewer because he was not active in fsnotify in last years and after he stopped working for Google I don't have a working contact to him" * tag 'fsnotify_for_v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: fsnotify: Fix stale object mask after concurrent mark updates fanotify: report full event length for FIONREAD fanotify: fix use-after-free of file range info fanotify: stop permission watchdog when timeout is zero fsnotify: Remove Matt Bobrowski as a reviewer fanotify: initialize permission event watchdog state commit f85dc137aabf357bf3d9fe4c9712121039d83798 Author: Tetsuo Handa Date: Mon Aug 17 23:08:15 2026 +0900 net: add missing ref_tracker_dir_exit() to net_passive_dec() I found that trying to read /sys/kernel/debug/ref_tracker/* causes NULL pointer dereference crash when alloc_netdev_mqs() via unshare() returned NULL, for commit 9ba74e6c9e9d ("net: add networking namespace refcount tracker") added ref_tracker_dir_exit(&net->refcnt_tracker) to only __put_net() path whereas commit 65b584f53611 ("ref_tracker: automatically register a file in debugfs for a ref_tracker_dir") added ref_tracker_dir_debugfs() to ref_tracker_dir_init() path. Since preinit_net() calls ref_tracker_dir_init(&net->refcnt_tracker) and ref_tracker_dir_init(&net->notrefcnt_tracker), we need to make sure that both ref_tracker_dir_exit(&net->refcnt_tracker) and ref_tracker_dir_exit(&net->notrefcnt_tracker) are called before net_passive_dec() schedules for kmem_cache_free() via net_complete_free(). ref_tracker_dir_exit(&net->refcnt_tracker) is called via put_net() when ns_ref_put() returned true. But put_net() is not called when copy_net_ns() fails. Therefore, call ref_tracker_dir_exit() from net_passive_dec() if put_net() is not yet called. Link: https://sashiko.dev/#/patchset/b06ce35d-e7bc-47a5-8e0a-e82be7e4dd08%40I-love.SAKURA.ne.jp Fixes: 9ba74e6c9e9d ("net: add networking namespace refcount tracker") Reviewed-by: Eric Dumazet Signed-off-by: Tetsuo Handa Link: https://patch.msgid.link/64254d80-9248-466c-8108-95f43bd71117@I-love.SAKURA.ne.jp Signed-off-by: Jakub Kicinski commit a6fa4d6e38d6d57986957de990d1feab663ea3c7 Author: Rafael J. Wysocki Date: Wed Aug 19 22:14:10 2026 +0200 ACPI: Update upstream ACPICA repository URL in documentation Update the URL of the upstream ACPICA repository after recent changes in the upstream ACPICA project. Signed-off-by: Rafael J. Wysocki Reviewed-by: Armin Wolf Link: https://patch.msgid.link/1867400.VLH7GnMWUR@rafael.j.wysocki commit 500919d75d5bbc0b45cc486615181ee502a49c31 Author: Rafael J. Wysocki Date: Wed Aug 19 22:13:13 2026 +0200 ACPI: Update MAINTAINERS entry for ACPICA Update the MAINTAINERS entry for ACPICA after recent changes in the upstream ACPICA project. Signed-off-by: Rafael J. Wysocki Reviewed-by: Armin Wolf Link: https://patch.msgid.link/3356863.5fSG56mABF@rafael.j.wysocki commit 45ccfec7caab044e0954fae6a296710d21aa466f Author: Rafael J. Wysocki Date: Wed Aug 19 22:12:34 2026 +0200 ACPI: Add Bob Moore to CREDITS To me, Bob is a silent hero. He had been driving the development and maintenance of the ACPI Component Architecture (ACPICA) project for over 2 decades and while he was not vocal or otherwise visible too much, he was focused on improving the code delivered by him to a community reaching far beyond the Linux kernel. Bob retired from Intel earlier this year after over 40 years of continuous service and departed from software development as far as I know, and he is missed already. The kernel depends on Bob's contributions quite a bit, so he deserves a CREDITS entry. Signed-off-by: Rafael J. Wysocki Reviewed-by: Armin Wolf Link: https://patch.msgid.link/3711645.iIbC2pHGDl@rafael.j.wysocki commit d141ec2825b4d3ec52f27c43bdd864090159273a Merge: ada9ccfb81eca6 46db3c8a1be96a Author: Linus Torvalds Date: Thu Aug 20 12:39:56 2026 -0700 Merge tag 'nfsd-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux Pull nfsd updates from Chuck Lever: - CB_NOTIFY support for NFSD's NFSv4.1 directory delegations The server used to recall a delegation as soon as the directory changed. NFSD now watches delegated directories through fsnotify and reports adds, removes, renames, and directory attribute changes, carrying the filehandle and attributes of the affected entry, so clients can keep their caches. Some of the NOTIFY4 flags come from RFC 8881bis (Jeff Layton) - Continued netlink work A new server-stats-get operation reports what /proc/net/rpc/nfsd publishes, plus NFSv4 callback counts, and SUNRPC now keeps its per-procedure call counts per network namespace, so a container sees its own numbers. nfsstat reads all of this over netlink, with a procfs fallback for older kernels (Jeff Layton) - Remove SUNRPC service thread pool mode selection Per node is the right choice on any host we run today, so the auto, global, and percpu modes have been removed. A single-node host still gets one pool. A multi-NUMA host now gets a pool per node. sunrpc.pool_mode accepts the old names but no longer selects anything. - Bug fixes, clean-ups, and small optimizations: - async COPY offload rework (Jeff Layton) - more use-after-free fixes in the NFSv4 state revocation paths - percpu counter contention removed from the reply cache and IO accounting - a long list of hardening fixes (Chris Mason) Sincere thanks to all contributors, reviewers, testers, and bug reporters who participated in the v7.3 NFSD development cycle. * tag 'nfsd-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux: (182 commits) nfsd: export NFSv4 callback op stats via netlink nfsd: count NFSv4 callback operations per netns sunrpc: remove unused svc_version vs_count field nfsd: implement server-stats-get netlink handler sunrpc: use per-net counts in svc_seq_show() sunrpc: add per-netns per-procedure call counts to svc_stat NFSD: Document reply_cache_stats ABI NFSD: Eliminate percpu counter contention in IO byte accounting NFSD: Eliminate percpu counter contention in reply cache statistics NFSD: Eliminate percpu counter contention in DRC memory accounting NFSD: Fix off-by-one in DRC bucket pruning limit NFSD: Relocate NFSv4 "supported attributes" to new header NFSD: Relocate nfsd4_set_netaddr() NFSD: Relocate nfsd_user_namespace() NFSD: Move struct readdir_cd NFSD: Move the export.h include from nfsd.h to auth.c NFSD: Remove '#include "nfsd.h"' from fs/nfsd/cache.h NFSD: include "netns.h" NFSD: Explicitly include "stats.h" NFSD: Make "stats.h" self-contained ... commit d2796ffe38cb4155afe0eab23636295b096c27a5 Author: Jiangshan Yi Date: Sat Aug 15 20:21:49 2026 +0800 bnx2x: fix double free in bnx2x_init_firmware() error path bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-op. Fixes: 94a78b79cb5f ("bnx2x: Separated FW from the source.") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260815122149.951215-1-yijiangshan@kylinos.cn Signed-off-by: Jakub Kicinski commit d2c26c2911dd1a363c488add4fb63eb5f0f28f87 Author: Cen Zhang (Microsoft) Date: Sun Aug 16 21:32:37 2026 -0400 ipv6: avoid divide by zero in rt6_multipath_rebalance rt6_multipath_rebalance() calculates the total eligible nexthop weight in one pass and programs upper bounds in a second pass. Since RTM_NEWROUTE is RTNL-free, a concurrent ignore_routes_with_linkdown update can make the first pass return zero while the second sees an eligible nexthop, causing rt6_upper_bound_set() to divide by zero. UBSAN: division-overflow in net/ipv6/route.c:4845:17 Oops: divide error: 0000 [#1] SMP KASAN NOPTI rt6_upper_bound_set() net/ipv6/route.c:4845 rt6_multipath_rebalance() fib6_add_rt2node() ip6_route_multipath_add() inet6_rtm_newroute() Skip upper-bound calculation when the first pass reports a zero total. This respects the lock-free performance considerations here and solves insecure scenarios. Fixes: bd11ff421d36 ("ipv6: Get rid of RTNL for SIOCDELRT and RTM_DELROUTE.") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Xiang Mei (Microsoft) Reported-by: Cen Zhang (Microsoft) Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260817013237.2797-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski commit ada9ccfb81eca6943c3cd42d23b9ddd446e75342 Merge: dc83d18cdd9048 d410cd5303ec59 Author: Linus Torvalds Date: Thu Aug 20 12:36:26 2026 -0700 Merge tag 'for-linus-7.3-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux Pull orangefs updates from Mike Marshall: "Fixes: - fix double-free of trailer_buf - skip leading spaces before parsing client debug masks Cleanup: - Remove commented out code New: - use folio_pos() and folio_size() in orangefs_page_mkwrite()" * tag 'for-linus-7.3-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux: orangefs: skip leading spaces before parsing client debug masks orangefs: Remove commented out code in find_cached_xattr orangefs: use folio_pos() and folio_size() in orangefs_page_mkwrite() orangefs: fix double-free of trailer_buf on readdir copy failure commit 07e98a4d5e9c292eae97c9cc5ab0937384e48492 Author: Eric Dumazet Date: Mon Aug 17 08:25:11 2026 +0000 netdevsim: update queue NAPI association on queue reset In netdevsim, receive queues (struct nsim_rq) embed their own struct napi_struct. When queue reset is performed (e.g. via queue_reset debugfs), nsim_queue_start() swaps in a newly allocated struct nsim_rq, and nsim_queue_mem_free() later deletes and frees the old one. However, nsim_queue_start() failed to update the queue-to-NAPI mapping via netif_queue_set_napi(). As a result, dev->_rx[idx].napi continued to point to the old NAPI struct. After the old queue was freed, a subsequent queue dump via Netlink (NETDEV_CMD_QUEUE_GET) triggered a KASAN slab-use-after-free read in nla_put_napi_id() when accessing rxq->napi->napi_id. Fix this by calling netif_queue_set_napi() in nsim_queue_start() to associate the new NAPI with the RX queue, and clear the association with netif_queue_set_napi(..., NULL) in nsim_del_napi() during teardown. Fixes: 5bc8e8dbef27 ("netdevsim: add queue management API support") Reported-by: syzbot+483a6efbc4882c1201ee@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a82c3d4.f7a79266.2f965f.0024.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260817082511.2300402-1-edumazet@google.com Signed-off-by: Jakub Kicinski commit ced45be0073a8a31b30b4a7f68cd3a15734515de Author: Anirudh Prasad Date: Sat Aug 15 01:36:23 2026 +0530 ACPI: pfr_update: fix stack buffer overflow in query_capability() query_capability() copies four ACPI buffer objects returned by the firmware _DSM into fixed-size u8[16] fields in struct pfru_update_cap_info using memcpy with the firmware-supplied length: memcpy(&cap_hdr->code_type, elements[CAP_CODE_TYPE_IDX].buffer.pointer, elements[CAP_CODE_TYPE_IDX].buffer.length); The same pattern repeats for drv_type, platform_id, and oem_id. If the firmware returns buffer.length > 16 for any of these fields, memcpy writes past the destination array. struct pfru_update_cap_info is stack-allocated in pfru_ioctl(). Confirmed with KASAN on 7.2-rc6: three stack-out-of-bounds reports are generated when a DSM returns 64-byte buffers, with writes reaching 44 bytes past the end of cap_hdr's [64, 156) frame window into adjacent stack redzones. Introduce a helper pointer to out_obj->package.elements and use it to validate each buffer length against its destination field size before copying, returning -EINVAL if the firmware supplies an oversized buffer. Fixes: 0db89fa243e5 ("ACPI: Introduce Platform Firmware Runtime Update device driver") Cc: All applicable Signed-off-by: Anirudh Prasad Link: https://patch.msgid.link/1a001e1fee9.637da6dc3533246.238498880682901704@a0rg.com Signed-off-by: Rafael J. Wysocki commit 408da1df18116c971c3392e21e50586688cd3fbf Author: Aldo Ariel Panzardo Date: Wed Aug 12 23:21:02 2026 -0300 net: mctp: hold a reference to the route device in mctp_route_lookup() mctp_route_lookup() uses rt->dev without holding a reference on it. mctp_route_lookup_single() returns the route under RCU only, so the route's device can be torn down concurrently: mctp_dev_put() drops the last reference and synchronously kfree()s mdev->addrs. mctp_dev_saddr() then reads rt->dev->addrs[0], giving a use-after-free reachable by an unprivileged local AF_MCTP user on the receive/forwarding path (no CAP_NET_RAW required): BUG: KASAN: slab-use-after-free in mctp_route_lookup Read of size 1 at addr ... by task mctp_uaf/... mctp_route_lookup mctp_pkttype_receive Freed by task ...: kfree mctp_dev_put mctp_dev_notify In the same window mctp_dst_from_route() -> mctp_dev_hold() also increments a refcount that has already reached zero ("refcount_t: addition on 0 ... mctp_dev_hold"). This reintroduces the use-after-free class of CVE-2023-3439: the source address lookup was moved ahead of the point where the destination takes its device reference. Take a reference with refcount_inc_not_zero() before touching rt->dev, skip a device that is already dead, and drop the reference once the destination has taken its own. Fixes: 22cb45afd221 ("net: mctp: perform source address lookups when we populate our dst") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Link: https://patch.msgid.link/20260813022102.2792032-1-qwe.aldo@gmail.com Signed-off-by: Jakub Kicinski commit dc83d18cdd90482c70fa4320160bba70ec5c9ef8 Merge: 8f421dfec2347c c22f91d82cb9a2 Author: Linus Torvalds Date: Thu Aug 20 12:27:02 2026 -0700 Merge tag 'ntfs3_for_7.3' of https://github.com/Paragon-Software-Group/linux-ntfs3 Pull ntfs3 updates from Konstantin Komarov: "Added: load ATTR_BITMAP run extents from $MFT extension records initialize err in attr_wof_frame_info reserve NUL byte when converting UTF-16 names reject restart table growth beyond U16_MAX entries validate dirty page table on log replay basic support for alternative data streams validate ef->size covers the record's name and value Fixed: slab-out-of-bounds write in ni_create_attr_list() out-of-bounds read of INDEX_ROOT in reparse/objid init boundary check in ntfs_dir_count() info-leak in ntfs_rename() lseek EINVAL on sparse/compressed files with 64-bit clusters info-leak on partial LZNT decompress in ni_read_frame() bound page_lcns[] index by the log record memory leak in indx_find_sort() integer overflow in MFT cluster validation reject out-of-range evcn in mi_enum_attr() out-of-bounds read in read_log_rec_buf() Changed; widen inode/record number storage to u64 cosmetic fixes and improvements rename 'err' to 'ret' in read paths" * tag 'ntfs3_for_7.3' of https://github.com/Paragon-Software-Group/linux-ntfs3: (21 commits) fs/ntfs3: validate ef->size covers the record's name and value fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() fs/ntfs3: reject out-of-range evcn in mi_enum_attr() fs/ntfs3: fix integer overflow in MFT cluster validation fs/ntfs3: Add basic support for alternative data streams fs/ntfs3: Rename 'err' to 'ret' in read paths fs/ntfs3: Fix memory leak in indx_find_sort() fs/ntfs3: bound page_lcns[] index by the log record fs/ntfs3: validate dirty page table on log replay fs/ntfs3: reject restart table growth beyond U16_MAX entries fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame() fs/ntfs3: reserve NUL byte when converting UTF-16 names ntfs3: initialize err in attr_wof_frame_info fs/ntfs3: fix lseek EINVAL on sparse/compressed files with 64-bit clusters fs/ntfs3: load ATTR_BITMAP run extents from $MFT extension records ntfs3: fix info-leak in ntfs_rename() ntfs3: fix boundary check in ntfs_dir_count() fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list() fs/ntfs3: cosmetic fixes and improvements ... commit 6b9eaa61ff2df63c6eb35d5cd025e2cef0861d76 Author: Ruoyu Wang Date: Sat Aug 15 23:17:37 2026 +0800 net: ipa: balance runtime PM reference on remove error ipa_remove() takes a runtime PM reference before accessing IPA hardware during teardown. If a concurrent modem start or stop keeps ipa_modem_stop() busy across both attempts, the callback intentionally returns without releasing the remaining resources because proceeding with teardown could crash. That return also skips the matching pm_runtime_put_noidle(), leaving the callback's usage-count reference held. Drop only this runtime PM reference before returning. pm_runtime_put_noidle() does not request an idle transition, so the hardware and resources retained on this exceptional path remain untouched while the usage count stays balanced. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 923a6b698447 ("net: ipa: get clock in ipa_probe()") Signed-off-by: Ruoyu Wang Reviewed-by: Alex Elder Link: https://patch.msgid.link/20260815151737.3758320-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski commit a4d7fc32559568e6e01e2896a0d220750e55c2ef Merge: ac9d95c71a2810 cfa9178ce2e5b4 Author: Jakub Kicinski Date: Thu Aug 20 12:24:46 2026 -0700 Merge branch 'forcedeth-two-register-window-bounds-fixes' Marek Czernohous says: ==================== forcedeth: two register-window bounds fixes Two bounds fixes in forcedeth, both in the same shape: a loop that walks the register window one step too far. They are independent of each other and touch different functions. 1/2 nv_suspend() and nv_resume() save and restore the non-PCI config space with i <= register_size/sizeof(u32). On a VER3 device that is exactly the length of saved_config_space[], so the last iteration reads and writes one element past the array, and on resume it writel()s that element one dword past the length the driver mapped. UBSAN catches it. 2/2 nv_tx_timeout() dumps the window in rows of eight dwords but only bounds the row's starting offset, so the final row reads between 12 and 28 bytes past register_size, on every one of the three supported window sizes. Neither is a regression. Both are long standing, and 1/2 in particular is not new to the list: - The identical off-by-one in nv_get_regs() was fixed by commit ba9aa134287f ("forcedeth: fix buffer overflow") in 2012. The two loops in this patch were missed at the time. - The suspend and resume side was then reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix. Sergei Shtylyov replied asking for the patch inline rather than attached, and the thread ended there. So this is not a new discovery. It is the same bug at the two sites the 2012 fix did not reach, finally sent in the form the list asks for. How bad is it, stated plainly 1/2 writes one u32 past the end of a declared array, on a suspend path, on every suspend of a VER3 device. That is an out-of-bounds store, it is what UBSAN reports, and with CONFIG_UBSAN_TRAP=y it is a trap that aborts the running kernel code. That is the stable case, and I think it stands on its own: memory safety, reproduced on hardware, one character to fix, no behavioural change for anyone else. What I will not claim is drama beyond that. The element it lands in is np->name_rx, a scratch string that nv_request_irq() rewrites with sprintf() before it is ever used, so on a kernel without UBSAN_TRAP nothing observable is corrupted. The patch says which member and why, so you can judge the severity yourself instead of taking my word. The MMIO side of both patches is milder still. ioremap() rounds the requested length up to page granularity, so these accesses stay inside the page the CPU has mapped and no fault is expected on any architecture with PAGE_SIZE >= 4K. What they leave is the window the driver asked for. 2/2 is only that, and carries no stable tag. Behaviour change in 2/2, so it is not buried in the patch The partial trailing row of the debug dump is no longer printed: 16 bytes for VER1, 20 for VER2, 4 for VER3. That is a deliberate trade against open-coding a second, narrower dump in a debug-only path. If you would rather keep those registers, a short remainder loop on top is the obvious follow-up. Testing Reference hardware: Apple Macmini3,1 (MCP79 chipset), forcedeth driving the onboard NIC. 1/2 is reproduced and fixed on that machine. One point of method first: UBSAN reports each source location only once per module load, so a quiet second suspend proves nothing. Both runs below are the first S3 cycle after a fresh load of the module in question. stock module, first S3 after load: 2 splats, one per loop patched module, first S3 after load: none The patched module was built, stripped, installed and reloaded, with the md5 of the running module checked against the installed one. The link came back, the DHCP lease was restored and ping showed no loss. That measurement was taken on 2026-08-04 on a 7.1.6 based kernel. The stock half has since been reproduced again on 7.1.8, most recently on 2026-08-13, reporting line 6225 from pci_pm_suspend and line 6240 from pci_pm_resume. I have not repeated the patched half on net/main itself. The runtime measurements come from a distro kernel on the reference hardware, which is the only machine I have with this NIC; the series itself is based on and built against net/main. 2/2 has no runtime test. Its path sits behind the debug_tx_timeout module parameter and needs a genuine TX timeout, which I cannot force safely on this machine. It rests on the arithmetic in the patch and on the build below. Build: allmodconfig with W=1 on x86_64, whole tree, zero compiler warnings and zero errors; forcedeth.c specifically produces none. That took about 30 hours on the two cores I have, which is why I say it plainly rather than in passing. I have not run allyesconfig. If you want that too, say so and I will queue it before reposting rather than claim a build I did not do. Two checkpatch notes on 1/2, both deliberate "Prefer a maximum 75 chars per line" fires on a line that is quoted UBSAN output. The splat is trimmed, and 1/2 says what was cut, but I did not rewrap the lines that remain: reflowing diagnostic output to satisfy a heuristic makes it harder to match against a real log. Two "spaces preferred around that '/'" CHECKs fire on register_size/sizeof(u32). That spacing is what the file already uses, including in nv_get_regs(), which is otherwise the same loop. Adding spaces would leave the two lines I touch inconsistent with their neighbourhood, so I kept the change to the one character that is wrong. Happy to do it the other way round if you prefer. AI assistance Per Documentation/process/coding-assistants.rst: this work is AI assisted. I use Claude (claude-opus-5) as a coding and analysis assistant. Both patches carry an Assisted-by trailer accordingly, and no Signed-off-by is added by the tool. Nature of the assistance: the assistant did the code archaeology and most of the drafting. I described the symptom, asked for the mechanism to be traced in the source rather than guessed, and asked for each claim to be backed by a file and a line. The UBSAN output and the S3 measurements are from the machine, not model output. It is also what found the 2012 fix and the 2013 report above, on a second pass over an earlier draft of this posting that claimed the bug had never been reported. That claim was wrong and would have wasted your time, so it seems worth saying that the checking pass is part of the process here and not a flourish. I reviewed the result, I understand the code, and I take responsibility for it. ==================== Link: https://patch.msgid.link/178682367884.3748309.5288746298966501007@gmail.com Signed-off-by: Jakub Kicinski commit 8f421dfec2347c67f5f8c261fbfdee407ac5e20f Merge: 62abb6cffd6bab 988c3c186c7305 Author: Linus Torvalds Date: Thu Aug 20 12:24:48 2026 -0700 Merge tag 'erofs-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs Pull erofs updates from Gao Xiang: "The most notable enhancement is to allow passing source fds via fsconfig() for composefs. The others are all various fixes: - Allow source fds via fsconfig(), in addition to source paths - Use dedicated metadata inodes for file-backed mounts - Disallow invalid interlaced ztailpacking pclusters - Validate on-disk compression algorithm IDs against supported ones - Fix unused pcluster pools on higher page-size platforms" * tag 'erofs-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs: erofs: fix unused pcluster_pools for higher page sizes erofs: guard on-disk algorithm IDs against Z_EROFS_COMPRESSION_MAX erofs: fix interlaced ztailpacking pclusters erofs: use dedicated meta inodes for file-backed mounts erofs: accept source file descriptor via fsconfig erofs: fix typo in error messages commit cfa9178ce2e5b4f2e2a9e8b577a6cff841665aa0 Author: Marek Czernohous Date: Sat Aug 15 21:54:38 2026 +0200 forcedeth: stop the tx_timeout register dump past the requested window nv_tx_timeout() dumps the register window in rows of eight dwords: for (i = 0; i <= np->register_size; i += 32) { netdev_info(dev, "%3x: %08x ... %08x\n", i, readl(base + i + 0), ..., readl(base + i + 28)); The loop bound only checks the row's starting offset, so the final row reads a full 32 bytes from a position that is below the end of the window but too close to it. base is mapped with exactly that length: np->base = ioremap(addr, np->register_size); so the tail of that row is read from beyond the length the driver asked for. Per variant, the last iteration reads past register_size by: NV_PCI_REGSZ_VER1 (0x270): row 0x260 reads to 0x27f, 16 bytes over NV_PCI_REGSZ_VER2 (0x2d4): row 0x2c0 reads to 0x2df, 12 bytes over NV_PCI_REGSZ_VER3 (0x604): row 0x600 reads to 0x61f, 28 bytes over This happens on every supported device, not just one of them. Note that it is not a consequence of the sizes being odd: with i <= register_size the offending row is reached whatever the size, and a size that were a multiple of 32 would overrun by a full row rather than by a remainder. To be precise about the severity: the reads stay inside the BAR. Memory BAR sizes are powers of two, the driver only accepts a region with pci_resource_len() >= register_size (forcedeth.c:5757-5762), and the next power of two at or above each register_size already covers the offending row: 0x400 for 0x270 and 0x2d4, 0x800 for 0x604. ioremap() also rounds the mapped length up to page granularity, so the reads land inside the mapping the CPU has as well. What they leave is the window the driver asked for, not the BAR and not the mapping. That is still a driver reading registers it did not ask for, and it is trivial to avoid, but nobody should expect a fault from it. Changing <= to < is not enough: register_size is a length and every size above is larger than its last row start, so i still reaches the offending row. Check that the whole row fits instead. The trade-off is that a partial trailing row is no longer dumped: 16 bytes for VER1, 20 for VER2, 4 for VER3. That seemed preferable to reading outside the requested window, and to open-coding a second, narrower dump for the remainder in what is a debug-only path. Extending the dump to cover the tail can be done on top if anyone misses those registers. Only reachable with the debug_tx_timeout module parameter, which defaults to false. It has not been observed at runtime: forcing a genuine TX timeout on the reference machine is not something I can do safely, so this rests on the arithmetic above and on a build test, not on a reproduction. UBSAN does not catch it either, since these are MMIO reads rather than an array access. It was found by reading the function while fixing the saved_config_space off-by-one in nv_suspend() and nv_resume(). The dump was introduced with a fixed 0x400 bound while ioremap() mapped only NV_PCI_REGSZ (0x270), so it read about 0x190 bytes too far from the start. Commit 86a0f04387bf ("[PATCH] forcedeth: fix initialization") later replaced 0x400 with np->register_size, which shrank the overrun to the remainder but did not remove it. Fixes: c2dba06dae7d ("[PATCH] forcedeth: rewritten tx irq handling") Signed-off-by: Marek Czernohous Reviewed-by: Simon Horman Reviewed-by: Zhu Yanjun Link: https://patch.msgid.link/178682367886.3748309.6978554332066826294@gmail.com Signed-off-by: Jakub Kicinski commit 9393f1d656a79693e0c123ff7bc7c5c0f708046d Author: Marek Czernohous Date: Sat Aug 15 21:54:38 2026 +0200 forcedeth: fix off-by-one when saving/restoring non-PCI config space nv_suspend() and nv_resume() walk the non-PCI configuration space with for (i = 0; i <= np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as u32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=y turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: np->base = ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the "?" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f ("forcedeth: fix buffer overflow") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=, which saves and restores exactly register_size bytes. Fixes: 1a1ca86158ee ("[netdrvr] forcedeth: save/restore device configuration space") Cc: stable@vger.kernel.org Signed-off-by: Marek Czernohous Reviewed-by: Simon Horman Reviewed-by: Zhu Yanjun Link: https://patch.msgid.link/178682367885.3748309.10595890901761762683@gmail.com Signed-off-by: Jakub Kicinski commit ac9d95c71a2810da878659856753b1fa2025af4f Merge: c5ae83ee02c044 ad0ae7aefa7a6e Author: Jakub Kicinski Date: Thu Aug 20 12:22:44 2026 -0700 Merge branch 'net-mlx5-preserve-speed-and-state-across-vport-modify-commands' Tariq Toukan says: ==================== net/mlx5: Preserve speed and state across vport modify commands The firmware vport modify command bundles both admin state and max tx speed in a single operation, which requires each side to preserve the other field when it only intends to change one. When modifying max tx speed, the driver already queries the current admin state and passes it back to avoid overwriting it. However, this query and the subsequent modify were not atomic, a state change between the two could cause the modify to overwrite the new state with a stale value. The fix holds esw->state_lock across the query-modify sequence. When support for setting max tx speed via the vport modify command was introduced, the existing admin state modify path was not updated to preserve the current speed. As a result, the firmware interprets the zero speed field as an intentional reset. The fix adds a speed query before the state modify and passes the result back in the command. To support that, mlx5_query_vport_max_tx_speed() had to be fixed first: it was returning zero whenever the vport was DOWN, which was correct for the query_port_speed verb but would defeat the purpose of querying before a state modify. The DOWN-to-zero logic is moved to the verb-layer caller so the function returns the raw firmware value. Patch #1 holds esw->state_lock across the state query and modify in the speed modify path Patch #2 moves the vport DOWN zero mapping to the verb-layer caller so the query returns the raw firmware value Patch #3 queries current max tx speed before modifying vport state to preserve it ==================== Link: https://patch.msgid.link/20260816065015.3280733-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit ad0ae7aefa7a6ede28a549d8dac87456d87ef6d4 Author: Or Har-Toov Date: Sun Aug 16 09:50:15 2026 +0300 net/mlx5: E-Switch, preserve max tx speed on vport state modification When modifying vport state, the firmware interprets a zero in the max tx speed field as an intentional reset, which can overwrite previously set values. This patch attempts to fix this by querying the current max tx speed from firmware before modifying the vport state and passing it back in the modification command. If the query fails, fall back to the cached agg_max_tx_speed value to avoid inadvertently resetting the speed. Fixes: 50f1d188c580 ("net/mlx5: Propagate LAG effective max_tx_speed to vports") Signed-off-by: Or Har-Toov Reviewed-by: Mark Bloch Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816065015.3280733-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit 20f11b5cfa429ba3a2b8ef463d47e820687b4d2e Author: Or Har-Toov Date: Sun Aug 16 09:50:14 2026 +0300 net/mlx5: Move vport DOWN state check out of mlx5_query_vport_max_tx_speed() mlx5_query_vport_max_tx_speed() was introduced to serve the query_port_speed path, which uses max_tx_speed == 0 when port is down. This is incorrect for callers that need the actual configured speed regardless of vport state, such as modify-vport-state helpers that must preserve the speed across state transitions. Move this logic to the caller function in the verb flow and let mlx5_query_vport_max_tx_speed() return the raw firmware value unconditionally. Fixes: aaecff5e13cd ("RDMA/mlx5: Implement query_port_speed callback") Signed-off-by: Or Har-Toov Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816065015.3280733-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit ff0f9b7aa1c756e24a8023eaf684e93774c64194 Author: Mark Bloch Date: Sun Aug 16 09:50:13 2026 +0300 net/mlx5: E-Switch, use state lock for vport state changes Protect vport admin state modifications and vport iteration with the eswitch state_lock mutex to ensure proper serialization of concurrent vport state changes. Currently, calls to mlx5_modify_vport_admin_state() and loops iterating over eswitch vports can race with each other, potentially leading to inconsistent vport state. Fix this by acquiring esw->state_lock Fixes: 7d0314b11cdd ("net/mlx5e: Modify uplink state on interface up/down") Signed-off-by: Mark Bloch Reviewed-by: Shay Drori Reviewed-by: Or Har-Toov Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816065015.3280733-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski commit c5ae83ee02c04487b1be1d143b791ec2caca888e Author: Fan Ye Date: Sat Aug 15 10:21:52 2026 +0000 net: thunderbolt: Count delivered packets in rx_packets and rx_bytes tbnet_poll() increments rx_packets once per received frame because that is the NAPI work unit, and then adds the same number to stats.rx_packets. An skb is handed to the stack only when the last frame of a packet arrives, so once the MTU exceeds TBNET_MAX_PAYLOAD_SIZE the statistic reports frames. tx_packets is bumped once per skb, so the two ends of a link disagree: at MTU 65330 the receiver reports 16 times the packets its sender sent. rx_bytes has the matching problem: frames of a packet that is later dropped mid-assembly are already accounted, so it does not correspond to rx_packets as documented. Account for both where the packet is completed, and leave the NAPI work counter alone. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Signed-off-by: Fan Ye Reviewed-by: Simon Horman Acked-by: Mika Westerberg Link: https://patch.msgid.link/20260815-tbnet-rx-stats-v1-1-8da375c2cd09@gmail.com Signed-off-by: Jakub Kicinski commit f826df95332c07380206dbd54178b6eefb311aba Author: Andrea Mayer Date: Mon Aug 17 15:26:44 2026 +0200 ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv() ipv6_rpl_srh_rcv() dereferences idev from __in6_dev_get() without a NULL check when reading idev->cnf.rpl_seg_enabled. When the device's MTU drops below IPV6_MIN_MTU, addrconf_ifdown() clears dev->ip6_ptr through RCU_INIT_POINTER(). A packet that passed the idev check in ip6_rcv_core() can then reach ipv6_rpl_srh_rcv() with dev->ip6_ptr already NULL. Reproduced by flooding the receiving interface with ping6 traffic while flapping its MTU between 1500 and 1200: BUG: KASAN: null-ptr-deref in ipv6_rpl_srh_rcv+0xb3/0x1070 Read of size 4 at addr 00000000000006b4 by task ping6/394 CPU: 2 UID: 0 PID: 394 Comm: ping6 Not tainted 7.2.0-rc7-micro-vm-dev-00095-g24ef02f934ee #240 PREEMPT(full) Call Trace: kasan_report+0xc6/0x100 ipv6_rpl_srh_rcv+0xb3/0x1070 ip6_protocol_deliver_rcu+0x759/0x9a0 ip6_input_finish+0xa8/0x1b0 ip6_input+0xe1/0x490 ipv6_rcv+0x33d/0x460 __netif_receive_skb_one_core+0xd6/0x130 process_backlog+0x2cc/0xa00 __napi_poll.constprop.0+0x56/0x270 net_rx_action+0x327/0x730 handle_softirqs+0x11e/0x630 do_softirq+0xb3/0xf0 Both ipv6_rpl_srh_rcv() and ipv6_srh_rcv() are called only from ipv6_rthdr_rcv(), which already has an idev lookup. Fix the NULL dereference on the RPL path by checking idev in ipv6_rthdr_rcv(), before it calls either function. The callees take idev as an argument and no longer call __in6_dev_get(), so the packet is now dropped in one place, with SKB_DROP_REASON_IPV6DISABLED on both paths. Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr") Cc: stable@vger.kernel.org Signed-off-by: Andrea Mayer Tested-by: Xiang Mei Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260817132644.2223-1-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski commit da4471557f279d0f56605158a625bb6e49ef7d41 Author: Hyunwoo Kim Date: Mon Aug 17 06:28:42 2026 +0900 net/tcp-ao: fix use-after-free of current_key on reconnect to another peer tcp_inbound_ao_hash() is called before bh_lock_sock_nested() is taken, with only rcu_read_lock() held. On the fast path for established sockets, if the rnext_keyid sent by the peer differs from current_key->sndid, the key the peer asked for is looked up and stored in current_key. The lookup is inside the RCU read side, but current_key outlives it. When the socket is disconnected and connect() is called again for another peer, tcp_ao_connect_init() unlinks every key that does not match the new peer and frees it with call_rcu(). If current_key points at such a key, it is cleared to NULL. The fast path reads sk_state only once on entry, so a softirq that got into it while the socket was still established can update current_key after that loop has already run. The update is inside the RCU read side, so it comes before the call_rcu() callback, and once the callback frees the key, current_key is left pointing at freed memory. The next transmission picks that pointer up in tcp_get_current_key(). tcp_ao_transmit_skb() then reads the traffic key from the freed object, which is the use-after-free. Wait for one grace period before unlinking, and only if a key is going to be removed. By the time tcp_connect() runs the socket is already in TCP_SYN_SENT, and TCP_AO_ESTABLISHED does not contain TCPF_SYN_SENT, so a softirq entering after the wait cannot reach the fast path, and the ones already in it have finished. The existing NULL handling in the loop is then enough. Fixes: 0a3a809089eb ("net/tcp: Verify inbound TCP-AO signed segments") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Reviewed-by: Simon Horman Acked-by: Paolo Abeni Link: https://patch.msgid.link/aoIriv3pHDgII2YR@v4bel Signed-off-by: Jakub Kicinski commit 62abb6cffd6bab44d430627043778ec157c32cce Merge: cf62c7084acfa9 e99cb3ecd8334c Author: Linus Torvalds Date: Thu Aug 20 12:17:36 2026 -0700 Merge tag 'libnvdimm-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull NVDIMM and DAX updates from Alison Schofield: "Most are DAX preparatory patches for FAMFS support, along with a few NVDIMM fixes and documentation cleanups. - Documentation cleanup, removing kernel-doc warnings - preparing DAX for FAMFS - misc NVDIMM fixups with cleanups for issues reported by Coccinelle" * tag 'libnvdimm-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: nvdimm-btt: clean up kernel-doc warnings libnvdimm: nd.h: clean up kernel-doc warnings dax: fsdev.c minor formatting cleanup dax: fix holder_ops race in fs_put_dax() dax: read holder_ops once in dax_holder_notify_failure() dax/fsdev: fail probe on invalid pgmap offset dax/fsdev: use __va(phys) for kaddr in direct_access dax/fsdev: clear pgmap ops and owner on unbind dax/fsdev: don't leave a dangling dev_dax->pgmap on probe failure dax/fsdev: clear vmemmap_shift when binding static pgmap dax/fsdev: fix multi-range offset in memory_failure handler dax: fix misleading comment about share/index union in dax_folio_reset_order() nvdimm/btt: reject an arena whose nfree is below the lane count libnvdimm/labels: Bound the on-media label size before the shift libnvdimm/labels: Prevent integer overflow in __nd_label_validate() nvdimm: ndtest: remove redundant NULL check before vfree() nvdimm: nfit: remove redundant NULL check before vfree() commit 8e2efb3f45a5c6f7c8f68685c1c4709040aa2fa0 Author: Victor Nogueira Date: Sun Aug 16 17:13:27 2026 -0300 net/sched: add get_fill_size callbacks for actions missing them Several tc actions - act_police, act_bpf, act_pedit, act_ife, act_sample, act_ct, act_ctinfo and act_tunnel_key among them - provide no get_fill_size() callback, so tcf_action_fill_size() falls back to tcf_action_shared_attrs_size() which does not account for the action-specific netlink attributes emitted inside TCA_ACT_OPTIONS by their dump functions. When an RTM_NEWACTION request with NLM_F_ECHO (or an RTNLGRP_TC listener) creates several actions, tcf_add_notify_msg() allocates the echo skb from this underestimated size. When this happens, the act_api code fails to add all of the fields to the netlink message and, thus, fails to send it. Issue is that, when that happens, this failure doesn't stop the action instances from being added. So any user watching these events will be under the false impression that no actions were created at all. For example, act_pedit overruns with 32 actions of four munge keys each, act_police with 32 policers once the optional rate/peakrate/result/avrate attributes are present. To fix this, add the missing get_fill_size callbacks returning the worst-case size of each action's dump attributes, following the pattern used by act_gact/act_skbedit/act_vlan. Also widen the TCA_GACT_TM accounting in tcf_action_shared_attrs_size() to nla_total_size_64bit(), since actions dump their tcf_t with nla_put_64bit(), which may be preceded by an NLA_PAD attribute. Note: We only provided fixes for the actions we reproduced this bug with as of today. We can send a separate hardening patch for the remaining actions to net-next later. The other pre-existing issues, pointed out by Clashiko [1], will be fixed in upcoming patches. [1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810164357.1653956-1-victor%40mojatatu.com Fixes: 4e76e75d6aba ("net sched actions: calculate add/delete event message size") Reported-by: Vega Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816201327.2435335-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski commit e5c8e301b497930e25cc4085fbc7ea2223b37030 Author: Eric Dumazet Date: Sat Aug 15 15:15:08 2026 +0800 selftests: net: packetdrill: add tests for advertised MSS with PMTU exceptions Add packetdrill tests for IPv4 and IPv6 to verify that the advertised MSS in SYN-ACK is derived from the configured interface/route MTU, and is not shrunk by learned Path MTU exceptions from previous outbound connections. Signed-off-by: Eric Dumazet Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260815071532.301908-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski commit 2640e64195948a601430d230c9864f5426574cde Author: Jiayuan Chen Date: Sat Aug 15 15:03:36 2026 +0800 net: advertise TCP MSS from the configured MTU, not the learned PMTU The MSS a host puts in its SYN tells the peer how big a segment it may send us. Right now we can shrink it with a PMTU we learned on our own send path, which is the wrong direction entirely. On asymmetric paths this bites - think DSR load balancers, where the request side goes through a smaller-MTU overlay. We learn a small PMTU going out, then advertise a small MSS, and the peer stays capped for the whole connection even though its path back to us is wide. MSS only shows up in the SYN and never grows back. On symmetric paths we lose nothing by dropping it either: the peer runs its own PMTU discovery and usually already knows the real path MTU. So work out the advertised MSS from the configured route or device MTU and ignore the learned PMTU. Our send side is unchanged, still clamped by tcp_current_mss(). Add ip_dst_mtu_configured()/ip6_dst_mtu_configured() and use them from the two default_advmss() paths. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 164a5e7ad531 ("ipv4: ipv4_default_advmss() should use route mtu") Cc: stable@vger.kernel.org Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260815070413.294559-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski commit ec518a7c4ba13ea0b94a50cc79584e6d578e4791 Author: Théo Lebrun Date: Thu Aug 20 19:08:20 2026 +0200 net: macb: drop CONFIG_OF #if block Fix -Wimplicit-function-declaration error on CONFIG_OF=n builds: drivers/net/ethernet/cadence/macb_main.c: In function ‘macb_probe’: drivers/net/ethernet/cadence/macb_main.c:5951:15: error: implicit declaration of function ‘macb_alloc_tieoff’ [...] 5951 | err = macb_alloc_tieoff(bp); | ^~~~~~~~~~~~~~~~~ drivers/net/ethernet/cadence/macb_main.c:5973:9: error: implicit declaration of function ‘macb_free_tieoff’ [...] 5973 | macb_free_tieoff(bp); | ^~~~~~~~~~~~~~~~ Error got introduced because functions are mistakenly declared in a `#if defined(CONFIG_OF)` block. Instead of moving functions around, avoid any future mistake and drop the block entirely. Change the module content slightly on CONFIG_OF=n. Previously match tables were ignored. Now they appear in the resulting build. This is considered trivial in size by most and is the common case: ⟩ 18 out of 254 OF net drivers reference CONFIG_OF ⟩ rg -lF 'MODULE_DEVICE_TABLE(of,' drivers/net/ | tee /tmp/a | wc -l 254 ⟩ xargs -a /tmp/a rg -l CONFIG_OF | wc -l 18 Tangent: no, of_match_ptr() does not imply that the compiler can optimize out match tables, because MODULE_DEVICE_TABLE(of, ...) unconditionally puts the match tables in the binary. It is only meant to avoid undefined declaration issues when match tables are hidden behind a #ifdef, as was done before. We therefore drop the macro call. Fixes: 5262eab9462a ("net: macb: allocate tieoff descriptor once across device lifetime") Reported-by: Nathan Chancellor Signed-off-by: Théo Lebrun Reviewed-by: Nicolai Buchwitz Acked-by: Conor Dooley Link: https://patch.msgid.link/20260820-macb-fix-x86-v1-1-b2e7c902104e@bootlin.com Signed-off-by: Jakub Kicinski commit cf62c7084acfa9f1ef98ce81b38c934c7ea10f93 Merge: ae814200e8393f ab11176bd3a760 Author: Linus Torvalds Date: Thu Aug 20 12:03:45 2026 -0700 Merge tag 'execve-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull execve update from Kees Cook: - x86/elf: Correct comment for STACK_RND_MASK() (Lorenzo Stoakes) * tag 'execve-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: x86/elf: Correct comment for STACK_RND_MASK() commit efebf6496685c93150df5bb0794363ae70c5f58a Author: Hui Su Date: Fri Aug 7 01:56:00 2026 +0800 bpf: Fix infinite loop in pcpu_freelist push with one possible CPU __pcpu_freelist_push() can loop forever when only one CPU is possible and an NMI re-enters pcpu_freelist_push() while the interrupted context holds that CPU's freelist lock. After the current-CPU fast path fails, the fallback loop walks cpu_possible_mask while skipping the current CPU. With CONFIG_SMP=n, or when an SMP kernel is limited to one possible CPU with nr_cpus=1 or possible_cpus=1, there are no other possible CPUs to examine. The loop therefore makes no lock acquisition attempt and can never make progress. The following stack was observed on a UP system: NMI context: pcpu_freelist_push free_htab_elem htab_map_delete_elem [perf-event BPF program] __perf_event_overflow perf_event_nmi_handler exc_nmi Interrupted context: __pcpu_freelist_push pcpu_freelist_push free_htab_elem htab_map_delete_elem [raw_tp/sys_enter BPF program] __bpf_trace_sys_enter do_syscall_64 raw_res_spin_lock() detects the same-CPU recursive acquisition and returns -EDEADLK, but the subsequent fallback loop has no candidate head on a system with one possible CPU. Restore the extra fallback head that existed before the rqspinlock conversion. Keep the current-CPU fast path, then try the other possible CPUs and finally the extra head. The additional head lets a push, which cannot fail without losing a preallocated element, make progress when the only per-CPU head is held by the interrupted context. Also check the extra head from the pop path so that nodes placed there can be reused. Fixes: f2ac0e5d1c4d ("bpf: Convert percpu_freelist.c to rqspinlock") Signed-off-by: Hui Su Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260806175600.1993595-1-sh_def@163.com Signed-off-by: Kumar Kartikeya Dwivedi commit 7ee2f20bf20ed59fb269a260c4c4aff1e67f1b7c Author: Jiayuan Chen Date: Wed Aug 19 20:58:30 2026 +0800 selftests/bpf: Add reg-invariants test for speculative pointer arithmetic An unprivileged socket filter does variable pointer arithmetic on a PTR_TO_MAP_VALUE whose offset collapses to a constant. The Spectre-v1 speculative path used to snapshot the pointer with a const offset and an unbounded r32, which tripped reg_bounds_sanity_check() on the following register move. Mark the test __success_unpriv (the speculative path only runs unprivileged) and flag it BPF_F_TEST_REG_INVARIANTS so the invariant violation becomes a hard load failure. The unprivileged run fails without the verifier fix and passes with it: verifier_bounds/spec_ptr_alu_const_offset @unpriv:FAIL # without fix verifier_bounds/spec_ptr_alu_const_offset @unpriv:OK # with fix Signed-off-by: Jiayuan Chen Tested-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260819125840.286434-2-jiayuan.chen@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi commit 150aeba624e8b7cac51c39440d7e8e1fd11de9a0 Author: Jiayuan Chen Date: Wed Aug 19 20:58:29 2026 +0800 bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic Take the following unprivileged program as an example: r0 = bpf_map_lookup_elem(...) /* PTR_TO_MAP_VALUE, offset 0 */ ... 14: r0 += r1 /* r1 is a bounded scalar */ 15: r9 = r0 Loading it triggers a verifier warning from reg_bounds_sanity_check(): verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out of sync with range bounds r64={.base=0x0, .size=0x0} r32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0) What happens: 1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new offset is computed into dst_reg's var_off and 32/64-bit ranges. 2. Because pointer registers do not track 32-bit subregister bounds, __mark_reg32_unbounded() first sets r32 to the full range; r32 is re-derived from the offset at the end of the function by reg_bounds_sync(). 3. On the unprivileged path, sanitize_ptr_alu() is called and, via sanitize_speculative_path() -> push_stack(), snapshots the current register state and schedules the next instruction (insn 15) to be verified directly as a speculative path. 4. That snapshot is taken between step 2 and the final reg_bounds_sync(): at this point dst_reg's var_off still holds the (const) original offset while r32 has just been blanked to the full range, i.e. the two are out of sync. When the speculative path later verifies insn 15 (r9 = r0), the inconsistent state reaches reg_bounds_sanity_check() and trips the warning. var_off and the 32-bit range must always be consistent. There are two ways to keep the snapshot consistent: 1. sync var_off and r32 before the snapshot so they match, or 2. leave r32 at its original (already consistent) value and blank it only after the snapshot. The whole point of sanitize_ptr_alu() is to insert a harmless masking sequence that keeps the access in bounds under speculation, so the state it snapshots should faithfully represent that. Take approach 2: move __mark_reg32_unbounded() to after sanitize_ptr_alu(), so the speculative snapshot keeps the pointer's original, consistent r32. The non-speculative path is unchanged: r32 is still blanked before the offset is applied and re-derived by reg_bounds_sync(). Fixes: 5f99f312bd3b ("bpf: add register bounds sanity checks and sanitization") Reported-by: Hiker Cl Closes: https://lore.kernel.org/bpf/CAGM=xGB1fJ9kT8XTitVo74B0WGqgjkoUHdLwzytwV0AyqeVApw@mail.gmail.com/ Signed-off-by: Jiayuan Chen Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260819125840.286434-1-jiayuan.chen@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi commit dc948f8b384a516ac5c471eb9382959f838e02f4 Author: Peixin Xie Date: Thu Aug 20 13:56:27 2026 +0800 ACPI: scan: Defer device power initialization acpi_bus_get_power_flags() initializes the device power state while the ACPI device object is being created, before checking whether the device is ready for enumeration. If enumeration is deferred, acpi_bus_attach() clears the initialized and power_manageable flags. When the dependency is later satisfied, acpi_bus_init_power() is called again and takes additional references to the power resources used by the device. These references prevent the resources from being turned off when the device enters D3. This issue was reproduced on a SpacemiT K3 RISC-V Pico-ITX. The affected device uses a power resource through _PR0 and has an automatically derived dependency on its interrupt controller. The initial power initialization acquires a power resource reference. The device is then deferred, but that reference is not dropped. When the dependency becomes available, power initialization acquires another reference. Consequently, entering D3 only drops the reference count from 2 to 1 and _OFF is not evaluated: [ 0.314611] ACPI Debug: "I2P2 _STA" [ 0.318260] ACPI: \_SB_.I2P2: ACPI: PM: Power resource is on [ 0.323998] ACPI: \_SB_.I2P2: New power resource [ 0.382108] ACPI Debug: "I2P2 _STA" [ 0.478964] ACPI Debug: "I2P2 _ON" [ 0.482498] ACPI: \_SB_.I2P2: ACPI: PM: Power resource turned on [ 0.488597] ACPI Debug: "I2C2, PS0" [ 0.863170] ACPI: \_SB_.I2P2: ACPI: PM: Power resource already on [ 0.873686] ACPI Debug: "I2C2, PS0" [ 2.416055] ACPI Debug: "I2C2, PS3" [ 2.423397] ACPI: \_SB_.I2P2: ACPI: PM: Power resource still in use To address this, remove the early acpi_bus_init_power() call and leave regular ACPI device objects uninitialized until acpi_bus_attach() runs after the device is ready for enumeration. Power resource objects are initialized through acpi_add_power_resource() and do not require the generic initialization in acpi_bus_attach(), so mark them as initialized there. After the change, device power state initialization is deferred until its dependency is met. Since no reference is acquired before then, the power resource left on by firmware is turned off as unused after the namespace scan. Once the dependency is met, the resource is turned on once for the device and is turned off normally when the device later enters D3: [ 0.314628] ACPI Debug: "I2P2 _STA" [ 0.318277] ACPI: \_SB_.I2P2: ACPI: PM: Power resource is on [ 0.324016] ACPI: \_SB_.I2P2: New power resource [ 0.382118] ACPI Debug: "I2P2 _STA" [ 0.496116] ACPI: \_SB_.I2P2: ACPI: PM: Turning OFF [ 0.501081] ACPI Debug: "I2P2 _OFF" [ 0.504705] ACPI: \_SB_.I2P2: ACPI: PM: Power resource turned off [ 1.415899] ACPI Debug: "I2P2 _ON" [ 1.418866] ACPI: \_SB_.I2P2: ACPI: PM: Power resource turned on [ 1.424947] ACPI Debug: "I2C2, PS0" [ 2.647655] ACPI Debug: "I2C2, PS3" [ 2.654856] ACPI Debug: "I2P2 _OFF" [ 2.654866] ACPI: \_SB_.I2P2: ACPI: PM: Power resource turned off This also avoids powering up devices before their dependencies are available. Signed-off-by: Peixin Xie [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260820-acpi-power-resource-ref-fix-v2-1-29818173ea13@linux.spacemit.com Signed-off-by: Rafael J. Wysocki commit ae814200e8393fa504dd246e98fcba8f5493de28 Merge: 216b3f432a3654 f4806cc63cc65b Author: Linus Torvalds Date: Thu Aug 20 11:41:46 2026 -0700 Merge tag 'bitmap-for-7.3' of https://github.com/norov/linux Pull bitmap updates from Yury Norov: "The usual set of fixes, cleanups and performance improvements together with a couple of new tests: - bitmap_find_next_zero_area_off() optimization (Sunyi) - bitmap_find_next_zero_area_off(): return size when no zero area is found (Yury) - bitmap vs IDA vs Maple Tree performance test (Yury) - get rid of cpumap_print_to_pagebuf() (Yury) - use nr_node_ids in __nodemask_pr_numnodes() (Li RongQing) - bitops: make the *_bit_le functions use unsigned long (Benjamin) - bitmap scatter & gather test fix (Christophe) - use __ASSEMBLER__ in bitmap header files (Thomas)" * tag 'bitmap-for-7.3' of https://github.com/norov/linux: (25 commits) lib: test bitmap vs IDA vs Maple Tree performance for region allocations bitmap: Return size when no zero area is found media: s5p-mfc: Treat bitmap size as allocation failure crypto: ccp: Treat bitmap size as allocation failure powerpc/msi: Treat bitmap size as allocation failure ARM: dma-mapping: Treat bitmap size as allocation failure bitmap: drop bitmap_next_set_region() nodemask: reduce bitmap width to nr_node_ids in __nodemask_pr_numnodes() bitmap: Properly initialise destination bitmap for scatter & gather test lib/bitmap-str: get rid of cpumap_print_to_pagebuf() perf: Use sysfs_emit() for cpumask show callbacks PCI/sysfs: Use sysfs_emit() for cpumask show callbacks RDMA/hfi1: Use sysfs_emit() for cpumask show helper hwtracing: hisi_ptt: Use sysfs_emit() for cpumask show fpga: dfl-fme-perf: Use sysfs_emit() for cpumask show devfreq: Use sysfs_emit() for cpumask show callbacks cpu: Use sysfs_emit() for cpumask show callback x86/events: Use sysfs_emit() for cpumask show callbacks powerpc: Use sysfs_emit() for cpumask show callbacks arm: Use sysfs_emit() for cpumask show callbacks ... commit 50720728b18e3c4ce660bf31ca13b7eaaefc1538 Merge: 066ae87fe95e6a 4e9442ce551ebd Author: Jakub Kicinski Date: Thu Aug 20 11:38:13 2026 -0700 Merge tag 'ipsec-2026-08-18' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2026-08-18 1) xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full Tighten the secpath-depth check so a full chain can't write past xvec[]. 2) Add and revert "esp: do not unref managed frag pages in esp_ssg_unref()" The patch does not fully fully resolve the issue, a corrected version will follow. 3) xfrm: espintcp: fix UAF during close Synchronize espintcp close with the xfrm_trans_reinject work queue so the freed socket message isn't dereferenced again. 4) xfrm: drop ESP-in-TCP packets with no ingress device Drop queued ESP-in-TCP records whose saved ingress device has gone away, avoiding a NULL device deref in the XFRM input path. 5) xfrm: avoid lock inversion in nat keepalive work Split the NAT keepalive walk into a reference-collection phase and a per-state lock phase to break the AB-BA with state removal. This patch has some issues that are fixed with a followup patch. 6) xfrm: Fix skb double-free in xfrm_dev_direct_output() Stop freeing the skb unconditionally in xfrm_dev_direct_output(), letting local_out()'s result indicate when ownership has moved on. 7) xfrm: ah6: validate routing header segments_left Validate the segments_left/hdrlen invariant before rearranging the routing-header addresses, avoiding an OOB memmove on malformed HDRINCL packets. 8) xfrm: fix xfrm_state_construct() auth-trunc leak Detect an already-attached auth-trunc allocation by the pointer rather than inferring it from the algorithm id, so a prior attach isn't overwritten and lost. 9) xfrm: bound nat keepalive state collection Replace the per-state allocation in the NAT keepalive walk with a fixed-size batch that drains under BH-disabled locking and resumes from the cursor, bounding the worker's memory. * tag 'ipsec-2026-08-18' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec: xfrm: bound nat keepalive state collection Revert "esp: do not unref managed frag pages in esp_ssg_unref()" xfrm: fix xfrm_state_construct() auth-trunc leak xfrm: ah6: validate routing header segments_left xfrm: Fix skb double-free in xfrm_dev_direct_output() xfrm: avoid lock inversion in nat keepalive work xfrm: drop ESP-in-TCP packets with no ingress device xfrm: espintcp: fix UAF during close esp: do not unref managed frag pages in esp_ssg_unref() xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full ==================== Link: https://patch.msgid.link/20260818092920.653034-1-steffen.klassert@secunet.com Signed-off-by: Jakub Kicinski commit 066ae87fe95e6a6421daf1c11eac0c8d2df7436f Merge: 47cdab0d51aaa9 e625a9477d12ba Author: Jakub Kicinski Date: Thu Aug 20 11:36:56 2026 -0700 Merge tag 'nf-next-26-08-18' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next Pablo Neira Ayuso says: ==================== Netfilter/IPVS fixes for net-next This contains fixes for nf_tables, revisit issues with expectation infra updates reported by sashiko, an ipset fix for deletions in the hash:net type and tne fix for the IPVS FTP helper. 1) Validate layer 4 header mangling done via nfnetlink_queue and nft_payload, this is a follow up to recent similar validation at layer 3. From Zhiling Zou. 2) Do not allocate memory on delete operations in ipset hash:net type, delete operation must always succeed. From Florian Westphal. 3) Deliver nft_obj overquota packet path notification directly via nfnetlink, do not use the control plane batch logic. From Fourie Zhang. 4) Follow up to controlidate check for reinserted dead expectations, to cover the nf_conntrack_expect_related_pair() function too. 5) Do not expose expectation dead flag to userspace via ctnetlink. 6) Make commit set_update_list per-netns to prepare to publish set clone earlier. 7) Publish the set clone earlier from commit path to address set lookup failures during table re-creation, this is targetting the rbtree and pipapo set backends. 8) Fix an integer overflow in the IPVS FTP helper. A similar fix was already proposed for the conntrack FTP helper months ago. From Joas Antonio dos Santos. * tag 'nf-next-26-08-18' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next: ipvs: fix integer overflow in ftp helper port/address parsing netfilter: nf_tables: call set ops .commit when building new ruleset blob netfilter: nf_tables: move set_update_list to nftables per-netns netfilter: ctnetlink: do not expose expectation DEAD flag netfilter: nf_conntrack_expect: consolidate check for insertion of dead expectation netfilter: nf_tables: don't queue packet path object notifications netfilter: ipset: remove need to allocate memory on delete operations netfilter: validate L4 headers after userspace packet writes ==================== Link: https://patch.msgid.link/20260817232957.1281637-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski commit 47cdab0d51aaa9bd85f8e4904585bd5bd4df4488 Author: Yuyang Huang Date: Sat Aug 15 17:46:51 2026 +0900 ipv6: use RCU iterator to dump route exceptions rt6_nh_dump_exceptions() uses hlist_for_each_entry() to iterate over RCU-protected exception lists. The caller holds rcu_read_lock(), but does not hold rt6_exception_lock, so rt6_insert_exception() can concurrently add an entry with hlist_add_head_rcu(). KCSAN reports this race (irrelevant details omitted): ================================================================== BUG: KCSAN: data-race in rt6_insert_exception / rt6_nh_dump_exceptions write (marked) to 0xffff8a7c44c59620 of 8 bytes by interrupt on cpu 5: rt6_insert_exception+0x3bb/0x760 __ip6_rt_update_pmtu+0x4fe/0x750 ip6_sk_update_pmtu+0x19a/0x3b0 udpv6_err+0x3ff/0x800 icmpv6_notify+0x1e1/0x440 icmpv6_rcv+0x8c0/0xab0 ip6_protocol_deliver_rcu+0x616/0x840 ip6_input_finish+0xb9/0x160 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff8a7c44c59620 of 8 bytes by task 549 on cpu 14: rt6_nh_dump_exceptions+0xb3/0x260 rt6_dump_route+0x53e/0x5f0 fib6_dump_node+0x6d/0xf0 fib6_walk_continue+0x290/0x2d0 fib6_dump_table+0x28d/0x360 inet6_dump_fib+0x37d/0x620 rtnl_dumpit+0x7b/0xd0 netlink_dump+0x3ae/0x7e0 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f 4 locks held by dumper/549: ... #1: (rcu_read_lock){....}-{1:3}, at: inet6_dump_fib+0x88/0x620 #2: (&tb->tb6_lock){+.-.}-{3:3}, at: fib6_dump_table+0x1e9/0x360 #3: (rcu_read_lock){....}-{1:3}, at: rt6_dump_route+0x483/0x5f0 value changed: 0xffff8a7c44e05700 -> 0xffff8a7c45d60100 Reported by Kernel Concurrency Sanitizer on: CPU: 14 UID: 0 PID: 549 Comm: dumper Not tainted 7.2.0-rc7-virtme #38 PREEMPT(lazy) ... Use hlist_for_each_entry_rcu() to safely iterate over the exception list. Fixes: 1e47b4837f3b ("ipv6: Dump route exceptions if requested") Cc: stable@vger.kernel.org Signed-off-by: Yuyang Huang Reviewed-by: Stefano Brivio Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260815084651.69477-1-sigefriedhyy@gmail.com Signed-off-by: David S. Miller Signed-off-by: Jakub Kicinski commit 3cbfd627ee720f3d2460d2cbe2fe9e4130240db6 Author: Jorijn van der Graaf Date: Sat Aug 15 06:03:02 2026 +0200 net: ipa: fix stalled modem TX queue after runtime resume ipa_start_xmit() unconditionally stops the TX queue before calling pm_runtime_get(), relying on the wake scheduled by runtime resume (ipa_modem_wake_queue_work()) to restart it once power is ACTIVE. But that work is queued from within the runtime resume callback, before the device's power state reaches RPM_ACTIVE, so it can run while the device is still RPM_RESUMING. The wake is then consumed too early: the transmit it restarts stops the queue again, pm_runtime_get() returns -EINPROGRESS without arranging any future wake (deferred_resume exists only for RPM_SUSPENDING), and after the resume completes nothing is left to wake the queue. Transmit stalls permanently: packets pile up in the qdisc behind the stopped queue, the device runtime-suspends, and since the netdev registers no ndo_tx_timeout the watchdog never fires. Observed on SM7635 (Fairphone 6) as the cellular data path going permanently deaf within hours, RX included, since nothing resumes the suspended endpoints. Close the window by making the wake work wait for the resume to complete (pm_runtime_get_sync()) before waking the queue. Every queue stop is then guaranteed a later wake that happens while power is ACTIVE; a transmit racing a new suspend/resume cycle re-schedules the work. If the device could not be resumed, wake the queue anyway so pending packets are dropped by the transmit path rather than stranded. The STARTED power flag used to narrow this window: a wake running before the transmit path's stop suppressed that stop, but only once, as the flag was cleared by the first stop it absorbed. Removing the flag made a single transmit during an in-flight resume sufficient to strand the queue, which is the form observed. With an accelerated reproducer (autosuspend delay shortened to 5 ms, ~20 packets/s of TX), an unpatched kernel stalled three times in 230 s / 4380 packets; with this patch the same test ran 3601 s / 70298 packets without a stall. Fixes: 688de12f080f ("net: ipa: kill the STARTED IPA power flag") Cc: stable@vger.kernel.org Signed-off-by: Jorijn van der Graaf Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260815040302.653650-1-jorijnvdgraaf@catcrafts.net Signed-off-by: David S. Miller Signed-off-by: Jakub Kicinski commit b74a072d8fb71d3c9ffba4a17d5943e63266fb38 Author: Ruoyu Wang Date: Fri Aug 14 21:40:53 2026 +0800 net: bridge: Reject descending VLAN tunnel ranges A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 94339443686b ("net: bridge: notify on vlan tunnel changes done via the old api") Signed-off-by: Ruoyu Wang Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260814134053.1387275-1-ruoyuw560@gmail.com Signed-off-by: David S. Miller Signed-off-by: Jakub Kicinski commit 216b3f432a36549767ca750e64badd71340b8c0f Merge: 11260c335ec607 a8488ecbd7ba44 Author: Linus Torvalds Date: Thu Aug 20 11:32:27 2026 -0700 Merge tag 'kcsan-20260817-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/melver/linux Pull Kernel Concurrency Sanitizer (KCSAN) update from Marco Elver: - Avoid unintended access checking in NMIs * tag 'kcsan-20260817-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/melver/linux: kcsan: avoid unintended access checking in NMIs commit e37b2abca80473e106176e41712a369fd2f72117 Author: Cen Zhang (Microsoft) Date: Thu Aug 13 17:53:28 2026 -0400 xsk: fix NULL pointer dereference in __xsk_rcv() In the __xsk_rcv() multi-buffer path, xsk_buff_alloc() is called in a loop without checking its return value. xsk_buff_can_alloc() only counts fill queue entries without validating their addresses, so it can succeed while xsk_buff_alloc() rejects all remaining entries and returns NULL. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:__xsk_rcv+0x426/0xc20 (net/xdp/xsk.c:350) Call Trace: xsk_generic_rcv+0x26d/0x5f0 xdp_do_generic_redirect+0x3c5/0xcf0 do_xdp_generic+0x92f/0xe70 __netif_receive_skb_core.constprop.0+0xf7e/0x2b30 Fix this with a two-stage transaction. First allocate and stage all buffers required for the packet, recycling all staged buffers with xsk_buff_free() if any allocation fails. Only after this stage succeeds, copy the data, reserve the RX descriptors, and release the buffers in an error-free loop. Fixes: 804627751b42 ("xsk: add support for AF_XDP multi-buffer on Rx path") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: Simon Horman Reviewed-by: Jason Xing Link: https://patch.msgid.link/20260813215328.99311-1-blbllhy@gmail.com Signed-off-by: David S. Miller Signed-off-by: Jakub Kicinski commit 11260c335ec6071af5543aef73000b28f041c124 Merge: 40d8c81577db09 fab183d6326283 Author: Linus Torvalds Date: Thu Aug 20 11:01:37 2026 -0700 Merge tag 'sched_ext-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext Pull sched_ext updates from Tejun Heo: "Most of this cycle completes the enqueue-path support for hierarchical sub-scheduling, which makes sub-scheduler support feature complete: a root BPF scheduler can now hand a cgroup subtree over to a nested sub-scheduler together with revocable CPU grants, and the sub-scheduler owns all scheduling decisions for its tasks on those CPUs. Development volume was high and a number of changes plugging holes in the new support landed late in the cycle. Also included are core scheduling fixes that were completed too late for the v7.2 release and are routed through this pull request. Sub-scheduler CPU delegation: - Parent schedulers now grant and revoke per-CPU capabilities (enqueueing, preemption, CPU frequency control) on their children, enforced on every path a scheduler can reach a CPU through. Previously only dispatching could be delegated; this lets sub-schedulers fully schedule their CPUs. - Rescue execution: a task whose scheduler doesn't have access to the CPUs the task needs to run on starved until the watchdog ejected the whole scheduler. The kernel now runs such tasks directly on a small bandwidth budget, turning a scheduler-killing failure into bounded degradation. - Cgroup integration: tasks migrating across a sub-scheduler boundary weren't re-homed to the new owner, causing wrong-scheduler scheduling and a use-after-free. Sub-schedulers now take over their cgroup subtree and receive its cgroup callbacks. - Arena objects now cross the kernel/BPF boundary as typed pointer arguments, translated transparently by the BPF tree's new arena argument support, replacing untyped arguments with manual translation. - scx_qmap now demonstrates full hierarchical sub-scheduling. Other fixes and updates: - Robustness improvements: the abort path is now NMI-safe, fixing deadlocks when errors are raised from NMI context and making hardlockup recovery direct. Reenqueue loops that could monopolize a CPU ahead of the watchdog now eject the offending scheduler, and stalls are blamed on the scheduler actually responsible. - Hardening: BPF-writable arena memory is validated before kernel use, and task slice and vtime writes got explicit synchronization rules, closing corruption vectors open to buggy or malicious schedulers. - Core scheduling: sched_ext dispatching can drop the rq lock inside the core-wide pick, which let interleaving selections corrupt each other's state and hard-hang the machine. The selection now restarts when the lock was released. The task ordering callback was also invoked with its arguments swapped, and the default ordering is updated to work across sub-scheduler boundaries. The fixes are marked for stable. - Other fixes headed for stable: a task init leak on fork failure during enable, tooling compat macros that silently failed to detect newer kernels, and a crash on reenqueueing against a destroyed dispatch queue. - Tooling: scx_pair moves off deprecated callbacks, and the deprecated scx_bpf_cpu_rq() kfunc is removed" * tag 'sched_ext-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: (144 commits) sched_ext: Drop the dead SCX_DEQ_CORE_SCHED_EXEC test in dequeue_task_scx() sched_ext: Make core-sched task ordering hierarchy-aware sched_ext: Use runnable_at for the default core-sched task ordering sched_ext: Fix inverted ops.core_sched_before() invocation sched_ext: Move the config-off sub-cap kfunc stubs into sub.c sched_ext: Rename balance-era identifiers to dispatch terms sched_ext: Drop the stale keep_prev fixup in dispatch_pick() sched_ext: Keep kick_sync waiting on the rq's own CPU sched_ext: Make SCHED_CLASS_EXT select GENERIC_ALLOCATOR sched_ext/scx_flatcg: Fix cvtime true-up on slice expiry sched_ext: Don't BUG_ON a destroyed DSQ in process_deferred_reenq_users sched_ext: Fix scx_bpf_dsq_move_to_local___v2 compat detection sched_ext: Make scx_bpf_events() read the calling scheduler's counters sched_ext: Drop unlocked scx_rq_clock_invalidate() from scx_root_disable() selftests/sched_ext: Fix flaky ddsp failure tests on busy systems selftests/sched_ext: Make numa idle validation race-free sched_ext: Fix scx_bpf_dsq_reenq___compat kfunc extern prototype sched_ext/scx_flatcg: expire cached hweights on weight changes sched_ext: Fix exit_task leak on fork failure during enable sched_ext: fix stale references in doc comments ... commit a8c6daab4b0e276508b7ffdd66c60fd3020a9178 Author: Hongfu Li Date: Thu Aug 20 15:09:44 2026 +0800 selftests/cgroup: Fix cg_run_in_subcgroups ignoring arg parameter cg_run_in_subcgroups() discards its arg and always passes NULL to cg_run(), turning the (void *)100 from test_kmem_dead_cgroups() into NULL so no allocation occurs. This makes test_kmem_dead_cgroups() falsely pass without exercising the "dying cgroup with charged slab" scenario it intends to test. Pass the arg through to cg_run() to fix this. Fixes: 933dc80ec262 ("kselftests: cgroup: add kernel memory accounting tests") Signed-off-by: Hongfu Li Reviewed-by: Michal Koutný Signed-off-by: Tejun Heo commit 72c5ae18ebe6588101f2c1e96be61618ce06f182 Author: Liang Luo Date: Thu Aug 20 10:37:44 2026 +0800 Docs/admin-guide/cgroup-v2: document BPF scheduler callbacks for cpu.max and cpu.idle The cpu.weight and cpu.weight.nice entries already state that the files also affect a BPF scheduler through the cgroup_set_weight callback. However, cpu.max, cpu.max.burst and cpu.idle only mention the fair-class scheduler, even though sched_ext implements the cgroup_set_bandwidth (notified with the period/quota from cpu.max and the burst from cpu.max.burst) and cgroup_set_idle callbacks from these interfaces. Mirror the cpu.weight wording for the three entries and generalize the category preamble to refer to the corresponding cgroup_set_* callback so it keeps covering the entries below. Suggested-by: Tejun Heo Signed-off-by: Liang Luo Signed-off-by: Tejun Heo commit 40d8c81577db09b71ee5402ba336b642d32d6a82 Merge: 39e34e88ec0dc7 2d19207f3fc8e0 Author: Linus Torvalds Date: Thu Aug 20 10:37:42 2026 -0700 Merge tag 'cgroup-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup updates from Tejun Heo: - Attach path bug fixes: migrations spanning multiple source or destination cpusets were mishandled, most visibly leaving thread affinities stale when the controller is disabled in a threaded subtree. Configuration writes could also race an in-flight attach and apply stale state, and the deadline task count could get corrupted by concurrent updates, skewing SCHED_DEADLINE admission decisions. - Memory binding bug fixes: which node masks get applied differed between the binding update paths, and tasks cloned with CLONE_INTO_CGROUP skipped rebinding entirely. Rebinding also now runs once per process instead of repeating for every thread sharing the mm. - Overhead removals with no behavior change: CPU hotplug iterated tasks of cpusets that just inherit the parent's effective masks, and the slab-spreading task flag was still being maintained although the SLAB allocator that consumed it is long gone. - Data-race annotations for benign races so that KCSAN reports stay meaningful, selftest coverage for the fixes above along with flakiness and portability fixes, and documentation corrections. * tag 'cgroup-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: (34 commits) selftests/cgroup: Remove redundant chown in test_cgcore_lesser_ns_open selftests/cgroup: Preserve CPU hotplug write errors cgroup/cpuset: Add test for partition root invalidation returning wrong CPUs cgroup/cpuset: Remove obsolete PFA_SPREAD_SLAB task flag docs: cgroup-v2: fix stale "io" controller introduction selftests/cgroup: Avoid awk -e in cpuset tests cgroup/cpuset: Use WRITE_ONCE() for shared prs_err updates selftests/cgroup: add user_usec sanity check in test_cpucg_nice cgroup: drop unneeded semicolon docs: cgroup-v2: mark memory.pressure and io.pressure as read-write selftests/cgroup: Fix minor defects in test_cpuset Docs/admin-guide/cgroup-v2: fix delay_nsec unit in io.latency doc selftests/cgroup: Remove redundant cg_enter_current() call in test_core selftests/cgroup: Add test for cpuset affinity on controller disable cgroup/cpuset: Handle the special case of non-moving tasks in cpuset_can_attach() cgroup/cpuset: Support multiple destination cpusets for cpuset_*attach() selftests/cgroup: fix missing TAP output in test_hugetlb_memcg cgroup/cpuset: Support multiple source cpusets for cpuset_*attach() cgroup/cpuset: Move mpol_rebind_mm/cpuset_migrate_mm() calls inside cpuset_attach_task() cgroup/cpuset: Make attach_ctx.old_cs track task group leader ... commit 39e34e88ec0dc7dbe3668dd54a0a9346a8323a8f Merge: 72fdff1416e280 20a80e7f6b71bd Author: Linus Torvalds Date: Thu Aug 20 10:34:25 2026 -0700 Merge tag 'wq-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq Pull workqueue updates from Tejun Heo: - Worker wakeups moved out of pool->lock on the hot paths, shortening lock hold times. The wakeup can be expensive on arm64 due to the idle wakeup IPI, and the change improves the workqueue microbenchmark there by up to 10% - Stall diagnostics now report pools stuck with no running worker, with a backtrace of what the CPU is executing and the likely culprit worker, instead of dumping every in-flight worker - Preparation for turning per-cpu workqueues into an affinity scope of unbound workqueues instead of a separate backend - Race annotations for KCSAN and sparse warnings, and doc and monitoring script fixes * tag 'wq-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: (23 commits) workqueue: annotate racy p->wake_cpu accesses in kick_pool_pick() workqueue: BUG_ON() instead of returning NULL in wq_node_nr_active() workqueue: use RCU accessors when populating wq->cpu_pwq workqueue: use rcu_dereference_sched() in workqueue_congested() workqueue: skip the node_nr_active update for non-unbound workqueues workqueue: rename alloc_unbound_pwq() to alloc_pwq() workqueue: allocate attrs for all workqueues workqueue: rename wq->unbound_attrs to wq->attrs workqueue: test WQ_UNBOUND explicitly in the hotplug loops workqueue: account nr_active by the backing pool workqueue: release pwq pools by pool type workqueue: factor out alloc_and_link_percpu_pwqs() workqueue: factor out get_percpu_pool() docs: workqueue: Fix bracket workqueue: annotate racy sum_exec_runtime reads for CPU-intensive detection workqueue: annotate racy PWQ_STAT_CPU_TIME update in wq_worker_tick() workqueue: dump the last woken worker for stalled pools workqueue: trigger a single-CPU backtrace for stalled pools workqueue: only show running workers in stall diagnostics workqueue: defer the worker wakeup outside pool->lock in process_one_work() ... commit 72fdff1416e280e2baaa3cca69574defb998437e Merge: 9d2ed026f031f7 791e420360669d Author: Linus Torvalds Date: Thu Aug 20 10:31:50 2026 -0700 Merge tag 'docs-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux Pull documentation updates from Jonathan Corbet: "It has been a not-too-busy cycle for docs; here's the highlights: - A (hopefully) consensus change to our LLM-attribution requirements, removing the specific model name from the Assisted-by tag - A couple of new realtime documents - Various docs-build-system fixes - Ongoing work with the Chinese, Portuguese, and Japanese translations ...and lots of typo fixes, grammar tweaks, etc" * tag 'docs-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux: (85 commits) Doc: admin-guide: pm: Remove unnecessary backticks and fix a spell Documentation: Extend the real-time hardware bits with some firmware bits docs: pt_BR: Reorganize process/index.rst to follow english structure docs: conf.py: fix the 'utf-8' typo doc tools: fix 'path' typos Documentation: real-time: Add kernel configuration guide docs: python: abi_regex: convert adjacent index placeholders docs: python: abi_regex: catch the right exception for a bad regex docs: sphinx-build-wrapper: include localversion in kernel version string Documentation: html: adjust sidebar section titles styling Documentation: html: show sections in the sidebar checkpatch.pl: adapt to new Assisted-by: format MAINTAINERS: update Traditional Chinese documentation maintainers docs: pt_BR: process: Translate CVE documentation docs: pt_BR: translate the management-style.rst to Brazilian Portuguese docs: xforms_lists: support DEFINE_IDTENTRY_IRQ() coding-assistants: simplify attribution docs: translations: pt_BR: translate email-clients.rst docs: pt_BR: process: Translate the security-bugs.rst doc:it_IT: align doc-guide translation ... commit 175a58668e2d5e96c571177fc7a0d8997bfbb205 Author: Kumar Kartikeya Dwivedi Date: Thu Aug 20 04:20:19 2026 +0200 selftests/bpf: Test invalid DW LDSX diagnostics An invalid BPF_MEMSX | BPF_DW instruction can reach Program Structure diagnostics before opcode validation when placed at the end of a subprogram. Exercise this path and require the disassembler fallback so table bounds regressions are caught. Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260820022020.3450479-3-memxor@gmail.com commit 37e5c4f4d2856290b1c56e573ced91dcd88db8ec Author: Kumar Kartikeya Dwivedi Date: Thu Aug 20 04:20:18 2026 +0200 bpf: Reject invalid LDSX instruction in disassembly The signed-load mnemonic table has entries for byte, half-word, and word loads because BPF_MEMSX does not support double-word loads. A BPF_MEMSX | BPF_DW instruction nevertheless selects index 3, past the end of this table. Program Structure diagnostics can disassemble a malformed instruction before check_and_resolve_insns() rejects its opcode. Placing the invalid signed double-word load at the end of a program therefore triggers an out-of-bounds access while reporting subprogram fallthrough. Treat signed double-word loads as invalid in the disassembler and use the existing BUG_ldx fallback instead. Fixes: a8f427835394 ("bpf: Report Program Structure CFG errors") Reported-by: syzbot+3544d9b2a9206be8ba37@syzkaller.appspotmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Daniel Borkmann Reviewed-by: Jiayuan Chen Link: https://lore.kernel.org/bpf/20260820022020.3450479-2-memxor@gmail.com commit 58b34b72b64bfbfc5f8ad4d8f229942aff76597e Author: Rustam Adilov Date: Thu Aug 20 21:20:17 2026 +0500 irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel() When CONFIG_SWAP_IO_SPACE is enabled, readl() performs a swap from little endian device to big endian CPU and vice versa for writel(). This is incorrect for Realtek Interrupt controller as that is a big endian device and so the LE to BE conversions are unwanted. Fix this by converting the MMIO accesses to readl_be() and writel_be(). Fixes: 9f3a0f34b84a ("irqchip: Add support for Realtek RTL838x/RTL839x interrupt controller") Signed-off-by: Rustam Adilov Signed-off-by: Thomas Gleixner Tested-by: Carlo Szelinsky Link: https://patch.msgid.link/20260820162017.28507-1-adilov@disroot.org commit d8aa5dd97944a72d4a9e3cc79bb80fcac7d6e829 Author: Peter Zijlstra Date: Thu Aug 20 09:49:27 2026 +0200 futex: Fix might_sleep() warning in futex_pivot_pending() A younger me put a WARN in might_sleep() to warn about nested sleep loops. This younger me also build a wait-loop variant that can deal with it. This wait-loop variant doesn't have all the fancy wrappers, since it isn't used much. It also lacks wait-bit support. Add the wait-bit support and use it to fix the nested wait issue. Fixes: 8e7ff730dd96 ("futex: Fix race in futex_pivot_pending() during private hash resize") Reported-by: syzbot+350a93852ac854927f45@syzkaller.appspotmail.com Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260820074927.GH1246887@noisy.programming.kicks-ass.net Closes: https://syzkaller.appspot.com/bug?extid=350a93852ac854927f45 commit c7a2a3618290594867b4829900b434704ab31dbc Author: Mike Rapoport (Microsoft) Date: Tue Aug 18 16:05:10 2026 +0300 x86/bpf: Make arch_bpf_trampoline_size allocate from EXECMEM_MODULE_DATA Jiri Olsa reports slowdown of tracing_multi benchmark that allocates huge number of trampolines [1]. The slowdown caused by extra protection changes in execmem_alloc_rw() and execmem_free(). With ROX caches enabled, all execmem allocations except EXECMEM_MODULE_DATA are ROX after the allocation. execmem_alloc_rw() temporarily sets them to W+NX and execmem_free() resets them back to ROX. The only user of bpf_jit_alloc_exec_rw() is x86::arch_bpf_trampoline_size() that only needs a temporary writable buffer in the modules address space. On x86 executable memory and module data are constrained to the same address range, so x86::arch_bpf_trampoline_size() can directly use execmem_alloc(EXECMEM_MODULE_DATA) Replace the call to bpf_jit_alloc_exec_rw() with a call to execmem_alloc(EXECMEM_MODULE_DATA) in x86::arch_bpf_trampoline_size() and drop bpf_jit_alloc_exec_rw() helper. Fixes: 5bf02dbf39fa ("bpf, x86: Make sure allocation in arch_bpf_trampoline_size() is writable") Reported-by: Jiri Olsa Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Daniel Borkmann Tested-by: Jiri Olsa Link: https://lore.kernel.org/all/an8r7EODLIL-bZM3@krava Link: https://lore.kernel.org/bpf/20260818130510.3110054-1-rppt@kernel.org commit 9d2ed026f031f764e9450ac9aada2f46bc977397 Merge: 91ec2035134982 8d75c338f0bcec Author: Linus Torvalds Date: Thu Aug 20 08:46:41 2026 -0700 Merge tag 'sysctl-7.03-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl Pull sysctl updates from Joel Granados: - Fix kernel-doc warnings by adjusting in file documentation - Consolidate do_proc_* function into do_proc_vec Consolidate three slightly different implementations of applying a converter on all elements of a vector. Fixes to this function now propagate to the three types. - Replace CONFIG_PROC_SYSCTL with CONFIG_SYSCTL (they were the same) and restrict cad_pid modifications to global root (GLOBAL_ROOT_UID) * tag 'sysctl-7.03-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl: sysctl: remove CONFIG_PROC_SYSCTL, it just mirrors CONFIG_SYSCTL sysctl: move the "cad_pid" entry from pid_table[] to kern_reboot_table[] sysctl: repair some kernel-doc comments sysctl: add Returns: kernel-doc for all functions sysctl: Update API function documentation sysctl: Rename proc_doulongvec_minmax_conv to proc_doulongvec_conv sysctl: Group proc_handler declarations and document sysctl: Replace do_proc_do{int,ulong,uint}vec with do_proc_vec sysctl: Add negp parameter to douintvec converter functions sysctl: Move default converter assignment out of do_proc_dointvec commit 91ec2035134982b98fab0609a9fd8480e8217dc1 Merge: 5a8cd539ac19f7 61eb236c41c2a4 Author: Linus Torvalds Date: Thu Aug 20 08:16:04 2026 -0700 Merge tag 'net-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next Pull networking updates from Jakub Kicinski: "One of the 'small improvements all over the place' releases for us. It's hard to draw any direct comparisons because summer vacations disrupted our patch processing (and presumably - generation) quite a bit. Quick and dirty count suggests we (Paolo and I) merged a very similar number of net (632) and net-next (648) patches. This is not telling the full story either because 1/3 to 1/2 of the net-next patches also *seem* like AI-driven low priority fixes, cleanups and clarifications. We are completely overwhelmed, of course. The glimmer of hope is that we secured sufficient LLM budget and access (thank you Meta!) to run reviews with multiple frontier models on each patch. This eliminates some hallucinations. That said, in terms of review, the LLMs can only do so much. The sad truth is that our APIs (especially for rare events like PCIe errors, timeouts etc) have always been racy, and now LLMs don't let us ignore that. I expect our direction for the next release will be to tweak the reviews a little bit more, but start shifting focus to letting the LLMs take care of the busy work - managing patchwork, automating common process complaints, editing commit messages, and maybe applying patches which already got "reviewed-by" tags from people we trust... Core & protocols: - A few steps lowering rtnl_lock dependence: - per-netns netdev unregistration for select SW drivers (e.g. veth, ipvlan, tunnels) - rtnl_lock-less FIB rule changes (RTM_NEWRULE and RTM_DELRULE) - prepare software drivers and TC qdiscs for rtnl_lock-less GET - Support BIG TCP (>64kB TSO) in UDP tunnels (vxlan, geneve) - Support buffers larger than PAGE_SIZE in devmem zero-copy API - Improve MPTCP handling of extreme memory pressure handling, when out-of-order queue had to be pruned - Report the per-group user count via RTM_GETMULTICAST - Expose the route deletion reason in RTM_DELROUTE - Add a SO_RIGHTS_NOTRUNC option to UNIX sockets to enable more useful handling of LSM denials when receiving SCM_RIGHTS messages: instead of truncating the message at the first blocked fd, keep every fd slot and store the LSM errno in the blocked slot - IPv6 Segment Routing - support looking up the post-encap SID (address) in a different/specified routing table - Support PRP RedBox (interlink) creation - Support per-nexthop UDP dst port in VXLAN - Continue converting getsockopt callbacks in a number of protocols to iov_iter Ethernet: - Merge initial CXL support for AMD/Solarflare NICs (shared branch with the CXL tree) - New drivers: - ADIN1140 10BASE-T1S MACPHY - Initial skeleton of Intel iXD and ZTE Dinghai drivers - High-speed NICs: - AMD/Pensando: - support firmware flashing - Cisco (enic): - SR-IOV V2 admin channel and MBOX protocol - Huawei (hns3): - support for ethtool pfc_prevention_tout - nVidia/Mellanox: - support sharing bandwidth control across interfaces of the same device - Marvell (octeontx2-pf): - link RQ page pools to netdev for Netlink stats - Google vNIC: - XDP metadata support for DQ RDA - Microsoft vNIC: - support forcing full-page RX buffers - Other NICs: - Synopsys IP: - eic7700: support for eth1 - Microchip (lan743x): - support for RMII interface - Wangxun: - support for ethtool -G and -C for VFs - add Tx timeout and PCIe error handling - Intel (igb/igc): - RSS key get/set support - support for forcing link speed without auto-negotiation - Switches: - NXP (dpaa2): - support bonding/LAG offload - Mediatek: - mt7530: EN7528 support - initial support for MT7628 - Micrel (ksz8/9): - refactoring work to move towards library model - PTP support for KSZ8463 - nVidia/Mellanox: - support rtnl-lock-less ethtool callbacks - Realtek: - rtl8366rb: use generic RTL83xx code - support SGMII and HSGMII for RTL8367S - PHYs: - Airoha: - EcoNet EN7528 PHY support - DAPU Telecom - DAPU Telecom DAP8211R(I) Gigabit PHY support - Realtek: - support RTL8261C_CG - support RTL8261D Wireless: - nl80211: per-link statistics support for multi-link operation - mac80211: AQL/airtime-fairness support for multicast - Merge Peripheral Authentication Service (PAS) / TEE support for ath12k (shared branch with the firmware/qcom tree) - New drivers: - mm81x for Morse Micro Long-Range S1G devices - nxpwifi for NXP devices (mostly forked off from mwifiex) - Driver changes: - Broadcom (brcmfmac): - DPP support, some Cypress part update - MediaTek (mt76): - mt7928 support - mt7925 NAN support - mt7996 AP powersave improvements - Qualcomm (ath12k): - much kernel infrastructure integration work - AHB platform MultiPD support - Realtek (rt89): - LED support - RTL8922DE support - dual-BT coex for RTL8922D - Intel: - new FW version support Bluetooth: - HCI: add support for Shorter Connection Interval (SCI) feature - af_bluetooth: add minimal context analysis annotations - Driver changes: - Intel: - add Bluetooth SAR revision 2 support - add vendor_reset PCI sysfs for PLDR - Mediatek: - add USB IDs for MT7902 and MT7922 devices - Realtek: - add USB IDs for 8761CU and 8852BE devices - NXP: - add M.2 Bluetooth device support using pwrseq Misc: - DPLL support for manual/numerical oscillator control (NCO) (implement in zl3073x) - MCTP support for MCTP over USB v1.1 (DMTF DSP0283) - Power-over-Ethernet: support Realtek PSE controllers - Remove the IBM EHEA driver - Remove tulip/xircom_cb driver" * tag 'net-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1433 commits) net/mlx5e: do not HW-GRO coalesce small frames net: openvswitch: fix nf_connlabels leak in ovs_ct_init net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs() net: openvswitch: fix flow mask use-after-free on flow deletion sctp: stop processing a packet once its association is deleted dpll: zl3073x: add PTP clock support dpll: zl3073x: add channel ToD, phase step and TIE operations dpll: zl3073x: scale poll interval proportionally to timeout ptp: vmclock: prevent read-only mappings from becoming writable ipv4: reject undersized MTUs in ip_do_fragment() bonding: initialize err for empty target lists net: dsa: initial support for MT7628 embedded switch net: dsa: initial MT7628 tagging driver net: phy: mediatek: add phy driver for MT7628 built-in Fast Ethernet PHYs dt-bindings: net: dsa: add MT7628 ESW net: pse-pd: realtek-pse-mcu: add UART transport net: pse-pd: realtek-pse-mcu: add I2C transport net: pse-pd: add Realtek PSE MCU core dt-bindings: net: pse-pd: add bindings for Realtek PSE MCU vsock: use sock_error() to consume sk_err after a failed connect ... commit 5a8cd539ac19f7a68e68e1d25ef9ca2ff55b8500 Merge: a4ff2be345d0ab f79066c784022f Author: Linus Torvalds Date: Thu Aug 20 07:36:20 2026 -0700 Merge tag 'bpf-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Pull bpf updates from Daniel Borkmann: "Major changes: - Redesign the verifier error reporting: failures now carry source and instruction annotations along with the causal event history that led to them, making program rejections far easier to debug and repair (Kumar Kartikeya Dwivedi) - Add arena argument support to kfuncs and struct_ops through the new __arena and __arena__nullable suffixes (Tejun Heo, Puranjay Mohan, Kumar Kartikeya Dwivedi, Ihor Solodrai) - Signed BPF program loader rework to accommodate both BPF and security community needs where the kernel runs the signature verification at BPF_PROG_LOAD time before the LSM admission hook (Daniel Borkmann) - Add a set of ksock kfuncs which let BPF LSM and syscall programs create, connect and send on UDP sockets in order to emit telemetry data (Mahe Tardy) - Unify helper and kfunc call argument verification and classify kfunc arguments purely from BTF into a generated bpf_func_proto which is computed once at add-call time (Amery Hung) Other features and fixes: - Enable EXECMEM_ROX_CACHE for BPF allocations on x86 (Mike Rapoport) - Add bidirectional VLAN support to bpf_fib_lookup() through the new BPF_FIB_LOOKUP_VLAN and BPF_FIB_LOOKUP_VLAN_INPUT flags (Avinash Duduskar) - Infer zext_dst from static register liveness analysis to fix 32-bit zero-extension semantics, and remove the artificial limitations on pointer types eligible for spilling (Eduard Zingerman) - Inline the numeric open-coded iterator kfuncs so that bpf_for() loops no longer pay a kfunc call on every iteration (Puranjay Mohan) - Add an arena-based bitmap data structure to libarena along with serial and parallel selftests (Emil Tsalapatis) - Teach resolve_btfids to discover kfuncs from the kernel's BTF ID sets and to emit kfunc BTF decl tags, reducing the kernel build's dependency on pahole features (Ihor Solodrai) - Add BPF_F_ADJ_ROOM_DECAP_* flags to bpf_skb_adjust_room() so that tunnel decapsulation can update the GSO and encapsulation state of the skb (Nick Hudson) - Fix the ring buffer pending_pos walk and the available-data accounting on 32-bit position wrap (Israel Téllez García) - Add memory usage accounting for arena maps and fix an mmap_lock deadlock on arena lock failure (Jiayuan Chen) - Add tracing_multi link info support to the kernel UAPI and bpftool, and refactor the stack map code to run with preemption disabled (Jiri Olsa) - Support BPF_F_EGRESS in bpf_redirect_peer() to emit the skb in the egress direction of the target's peer device (Jordan Rife) - Add a KF_SPINLOCK_SAFE kfunc flag so that providers, in particular modules, can declare kfuncs safe to call under bpf_spin_lock instead of relying on the verifier's hard-coded allowlist (Kaitao Cheng) - Introduce global percpu data for BPF programs with libbpf probing and bpftool skeleton support, and stop exposing uninitialized kernel heap memory when copying per-CPU map values (Leon Hwang) - Add s390 JIT support for load-acquire and store-release instructions (Maxim Khmelevskii) - Fix a CFI mismatch in the task work callback and an arm64 KASAN false positive after bpf_throw() (Mykyta Yatsenko) - Reject writes through untrusted BTF pointers and bound the rdonly/rdwr_buf_size kfunc arguments (Nicholas Dudar) - Invalidate RCU pointers only after the final spin unlock and account for preempt and IRQ disabled regions as overlapping RCU protection (Ning Ding) - Support mixing bpf2bpf calls and tail calls on RV64, add signed operations and 32-bit atomics to the RV32 JIT, and add timed may_goto support (Pu Lehui, Kuan-Wei Chiu, Feng Jiang) - Fix a use-after-free on mm_struct in bpf_find_vma() for foreign tasks and an mmap_lock leak in the irq_work path (Sanghyun Park) - Populate mmap-able BPF array map memory lazily which makes mmap() O(1) instead of proportional to the map size (Song Liu) - Introduce a jit_required flag and reject programs with inlined helpers when no JIT is available, where the interpreter would otherwise jump into an invalid address (Tiezhu Yang) - Fix the x86 JIT per-CPU address resolution into an extended register where the REX prefix dropped the high destination register bit (Vineet Gupta) - Reject MEM_ALLOC BTF accesses past object bounds, arena frees below the arena base, and mixed arena and ordinary atomic paths (Yiyang Chen) - Fix the trampoline handling of 128-bit arguments and of return values larger than 8 bytes (Yonghong Song) - Ensure that any fault prone load is rewritten with exception table handling, and fix the arena load-acquire and atomic fetch handling in the x86, arm64, riscv and s390 JITs (Daniel Borkmann) - Many more fixes and cleanups across the verifier, arena, trampolines, sockmap, cgroup, ring buffer, x86/arm64/riscv/s390 JITs, libbpf, bpftool, resolve_btfids and selftests" * tag 'bpf-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (373 commits) selftests/bpf: Add tests for a store on a fault prone qdisc pointer selftests/bpf: Add tests for fault prone loads out of RCU pointers selftests/bpf: Add tests for pointer type merge at a shared load selftests/bpf: Remove duplicate copies of the arena spinlock qnodes selftests/bpf: Retry stat generation in cgroup_iter_memcg selftests/bpf: Test pseudo-function policy diagnostics bpf: Distinguish function references in policy diagnostics bpf: Preserve source attribution without source text selftests/bpf: Test kfunc argument diagnostics bpf: Correct kfunc argument diagnostics bpf: Use canonical stack argument names in diagnostics bpf: Preserve R0 lineage across helper calls selftests/bpf: Exercise negative optlen in cgroup getsockopt hook bpf: Reject negative optlen in cgroup getsockopt hook selftests/bpf: tc_tunnel - validate decap GSO and encapsulation state bpf: Clear decap state on skb_adjust_room shrink path bpf: Allow new DECAP flags and add guard rails bpf: Add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation bpf: Refactor masks for ADJ_ROOM flags and encap validation bpf: Name the enum for BPF_FUNC_skb_adjust_room flags ... commit 4c6320e0ad400d4ee41cfde614c05a0d87f54e1b Author: Namjae Jeon Date: Thu Aug 20 22:40:22 2026 +0900 MAINTAINERS: update ksmbd repository URL Update the ksmbd repository URL to the kernel.org ksmbd-for-next branch. Signed-off-by: Namjae Jeon commit 13b1d8a99687122faa13f246cbd6fa9abe2ac562 Author: ChenXiaoSong Date: Wed Aug 19 07:12:24 2026 +0000 MAINTAINERS: add myself as KSMBD reviewer I and my team have been working on KSMBD development, and I am also interested in helping maintain this code. Signed-off-by: ChenXiaoSong Signed-off-by: Namjae Jeon commit c5e640fe346177372ff4a51a45b01fcd48c29207 Author: Namjae Jeon Date: Thu Aug 20 16:43:15 2026 +0900 smb: server: remove unused DES crypto header The DES crypto header is no longer used after the removal of NTLMv1 authentication. Remove it now that the server no longer selects CRYPTO_LIB_DES. Fixes: ce812992f239 ("ksmbd: remove NTLMv1 authentication") Signed-off-by: Namjae Jeon commit ed91d80242358ffdf127a34e3b7c9fc445c9e5d1 Author: Thomas Huth Date: Thu Aug 20 08:58:15 2026 +0200 smb: server: Remove obsolete "select CRYPTO_LIB_DES" from Kconfig file The DES encryption in the smb server code has been removed in 2021 with the removal of the insecure NTLMv1 authentication code. Thus we don't need this "select" statement here anymore. Fixes: ce812992f239f ("ksmbd: remove NTLMv1 authentication") Signed-off-by: Thomas Huth Signed-off-by: Namjae Jeon commit 80b6367ec37faf61fbd11aae6fae64c51faa5bba Author: Namjae Jeon Date: Thu Aug 20 08:26:03 2026 +0900 ksmbd: keep TCP timers alive for kernel sockets ksmbd creates its listening socket with sock_create_kern(). Kernel sockets do not hold a network namespace reference by default. Accepted sockets inherit this state. When an accepted socket is released, tcp_close() clears its pending TCP timers for a kernel socket after the socket enters an orphaned state. If the peer is unreachable while ksmbd sends a FIN, this can leave a FIN-WAIT-1 orphan without a retransmission timer. Upgrade the listening socket's network namespace reference before kernel_listen(). Accepted sockets inherit the reference, so the TCP stack can keep the retransmission timer active and apply its normal orphan retry policy. Preserve the existing graceful shutdown behavior. Link: https://github.com/openwrt/openwrt/issues/24744 Signed-off-by: Namjae Jeon commit 56549c18a4f75309161ca780feaa4d17904e3ee9 Author: Namjae Jeon Date: Wed Aug 19 10:01:11 2026 +0900 ksmbd: enable TCP keepalive for accepted connections A client that disappears without sending a FIN or RST can leave its ksmbd connection in ESTABLISHED indefinitely. ksmbd sets a socket receive timeout, but the connection receive loop retries timeout errors without a limit, so the connection remains in conn_list and consumes the per-IP connection quota. Enable SO_KEEPALIVE on accepted TCP sockets so the TCP stack can detect a silent peer failure. The keepalive idle time, interval, and probe count remain controlled by the existing TCP sysctl settings. Signed-off-by: Namjae Jeon commit 7e77c09e23dae1ff8bd8598c3c96f9db6862eddd Author: Zhang Heng Date: Thu Aug 20 21:06:44 2026 +0800 ALSA: hda/realtek: Reorder quirk entries for Lenovo Legion Pro 7 16ARX8H Reorder the HDA_CODEC_QUIRK entries for 0x17aa:0x38a7 and 0x17aa:0x38a8 so that the AMD variant (TAS2781) is matched before the Intel variant's PCI SSID (0x386f) which uses a different amplifier. This ensures the correct fixup (ALC287_FIXUP_TAS2781_I2C) is applied to the AMD model, restoring internal speaker functionality. Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260820130644.76093-2-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai commit 41d60cbfde10b9f01ae6e2d3195463fbad6e54a8 Author: Zhang Heng Date: Thu Aug 20 21:06:43 2026 +0800 ALSA: hda/realtek: Fix bass speaker DAC routing for Lenovo Yoga Pro 9 16IAH10 The Lenovo Yoga Pro 9 16IAH10 (PCI SSID 17aa:3846, codec SSID 17aa:3920) uses a TAS2781 smart amplifier driven via the ALC287 codec. On this machine the bass speaker pin (NID 0x17) is by default routed to DAC 0x03, which has no volume amplifier capability, resulting in the right-side woofer being barely audible while only the tweeter plays. The Windows driver configures NID 0x17 to DAC 0x02, which is shared with the main speaker and carries proper amp control. Currently this machine has no PCI SSID quirk, so it falls through to the codec SSID fallback and matches the existing 0x17aa:0x3920 entry intended for the Yoga S990-16, applying only the TAS2781 I2C init without the DAC routing fix. Add a dedicated quirk for PCI SSID 17aa:3846 that forces NID 0x17 to DAC 0x02 via alc285_fixup_speaker2_to_dac1() and chains to ALC287_FIXUP_TXNW2781_I2C so the TAS2781 amplifier initialization is preserved. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220540 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260820130644.76093-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai commit c73cb5b7c159246dd572277c668851a56e516019 Author: Runyu Xiao Date: Thu Aug 20 19:27:49 2026 +0800 ALSA: mtpav: shut down output timer before card teardown snd_mtpav_output_timer() rearms chip->timer while holding chip->spinlock and accesses the card-private mtpav state. snd_mtpav_free() currently takes the same lock and calls timer_delete() when the timer is active. This only removes a pending timer; it does not wait for a callback that is already running and does not prevent the callback from rearming the timer. A callback running on another CPU can therefore continue after snd_mtpav_free() releases the lock and access the card-private state while the card is being torn down. It can also rearm the timer after timer_delete() has returned. Call timer_shutdown_sync() without holding chip->spinlock. This waits for any running callback to finish and prevents further rearming before the card-private mtpav state is released. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260820112749.9195-1-runyu.xiao@seu.edu.cn Signed-off-by: Takashi Iwai commit 13087ad7817e6e5f210064518bfc4d6d58a9c2f3 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 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 commit dfb8bc1d286fd97b7cf47e3af5df84cfb068d214 Author: Jack Yu Date: Thu Aug 20 17:24:15 2026 +0800 ASoC: rt712-sdca: Pull high JD2 to prevent from entering TV mode Add a patch setting to prevent ALC712 from entering TV mode which may cause unexpected issues. Signed-off-by: Jack Yu Link: https://patch.msgid.link/20260820092415.2979641-1-jack.yu@realtek.com Signed-off-by: Mark Brown commit a9c2f0d401fd1e11ce59e4243946a59bd818e8c5 Author: Li Jun Date: Thu Aug 20 17:23:51 2026 +0800 spi: loongson: pm: add .freeze .poweroff .thaw .restore after execute s4, the spi error, [ 1104.754246][ 4] [ T1] tpm_tis_spi spi-SMO0768:00: SPI transfer failed: -110 [ 1104.761503][ 4] [ T1] spi_master spi1: failed to transfer one message from queue [ 1104.769201][ 4] [ T1] spi_master spi1: noqueue transfer failed [ 1104.776344][ 4] [ T1] tpm_tis_spi spi-SMO0768:00: SPI transfer failed: -110 [ 1104.783609][ 4] [ T1] spi_master spi1: failed to transfer one message from queue [ 1104.791308][ 4] [ T1] spi_master spi1: noqueue transfer failed [ 1104.797446][ 4] [ T1] gttadd tpm_chip_start1 ret = -110 and in s4 the loongson_spi_resume&suspend are not called at all. use DEFINE_SIMPLE_DEV_PM_OPS() add .freeze .poweroff .thaw .restore, after s4 the spi communication is normal. Signed-off-by: Li Jun Link: https://patch.msgid.link/20260820092351.101605-1-lijun01@kylinos.cn Signed-off-by: Mark Brown commit b2702908ee23ef31bfcf241a2e07ace0eb76bd71 Author: Geert Uytterhoeven Date: Wed Aug 19 21:05:19 2026 +0200 spi: amlogic-spisg: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. aml_spisg_clk_init() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: cef9991e04aed330 ("spi: Add Amlogic SPISG driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Reviewed-by: Xianwei Zhao Link: https://patch.msgid.link/9fb35ae0aedb7a6db0db6c78a8193c7602dd9d44.1787165329.git.geert+renesas@glider.be Signed-off-by: Mark Brown commit b2326338dc683e8c1067c0cbf7a47986c4190902 Author: Ard Biesheuvel Date: Sat Aug 1 17:28:04 2026 +0300 efivarfs: Rate limit statfs() handler Ravi reports that statfs() may be called by unprivileged users on the efivarfs mount point, which may result in a flood of calls to the QueryVariableInfo() runtime service. These calls are disproportionately costly on x86 systems where the variable store is backed by SMM, as each SMM entry requires a rendez-vous of all the CPUs. So rate limit the calls to QueryVariableInfo() at twice per second, and return the most recently obtained value for calls that are elided. Cc: Reported-by: Ravi Bangoria Fixes: d86ff3333cb1 ("efivarfs: expose used and total size") Reviewed-by: Anisse Astier Signed-off-by: Ard Biesheuvel commit eb01ffabeb52251f821c18438af8a65391f7ac79 Author: Pengpeng Hou Date: Mon Jul 6 17:18:13 2026 +0800 efi: apple-properties: validate setup data header length map_properties() remaps the Apple properties setup_data payload and then reads the properties header fields. Reject a truncated payload before checking the header version and length fields. Signed-off-by: Pengpeng Hou Reviewed-by: Lukas Wunner Signed-off-by: Ard Biesheuvel commit 01787ed2fde4ac42bc35339dae799a5abb094ed0 Author: Vincent Mailhol Date: Wed Jul 22 23:22:25 2026 +0200 efi: make efi_guid_to_str() take a const GUID pointer efi_guid_to_str() only formats the GUID through the byte array passed to the UUID printf formatter. It does not modify the GUID contents. Make the input pointer const so callers can stringify GUIDs from const data without a cast. Signed-off-by: Vincent Mailhol Signed-off-by: Ard Biesheuvel commit 8049741ac93acd3a590dac070e12571fddf0e294 Author: Serhat Kumral Date: Thu Aug 6 23:13:58 2026 +0300 RDMA/ucma: Allow path records to exactly fit the output buffer ucma_query_path() emits a path record only when the remaining output buffer is strictly larger than struct ib_path_rec_data. A buffer sized exactly for the response header and N complete records therefore gets only N - 1 records, while resp->num_paths still advertises N. A caller sizing its buffer for a single record gets a header claiming one path and no path data at all. ucma_query_ib_service() in the same file computes the record count with a plain division and so accepts an exact fit; make ucma_query_path() behave the same way. Current librdmacm is unaffected because it always sizes the response for six records while the kernel currently reports at most two paths. Other users of the UAPI that provide an exactly sized buffer can observe the truncated response. Fixes: ac53b264b2f3 ("RDMA/ucma: Support querying when IB paths are not reversible") Signed-off-by: Serhat Kumral Link: https://patch.msgid.link/20260806201358.147478-1-serhatkumral1@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe commit 4b2c033b5bc971a6a1e3c5cd2fa44421eb2ff84e Author: Breno Leitao Date: Tue Jun 16 05:09:40 2026 -0700 efi/runtime-wrappers: retire the worker if a wedged call ever returns When __efi_queue_work() times out it disables runtime services and returns, but the kworker is still blocked inside firmware. If the firmware eventually unblocks, efi_call_rts() would run its tail on an efi_rts_work that the timed-out caller has long abandoned: signalling a stale completion and clearing efi_runtime_lock_owner that may by then belong to another caller. If runtime services have been disabled by the time the call returns, park the worker with efi_rts_park_worker() instead, so it never touches efi_rts_work again or returns to the workqueue. Suggested-by: Ard Biesheuvel Signed-off-by: Breno Leitao Signed-off-by: Ard Biesheuvel commit bb50e70f4ffe12ad1710883603ba8109bb5d6dfd Author: Breno Leitao Date: Tue Jun 16 05:09:39 2026 -0700 efi/runtime-wrappers: honour EFI_RUNTIME_SERVICES in the non-blocking paths Three wrappers call firmware directly instead of going through __efi_queue_work(), and none of them check whether runtime services are still enabled: virt_efi_set_variable_nb(), virt_efi_query_variable_info_nb() and virt_efi_reset_system(). Once a hang has cleared EFI_RUNTIME_SERVICES - or efi_recover_from_page_fault() has cleared it on a firmware page fault - these paths still enter the (possibly wedged) firmware, e.g. an EFI pstore write through the non-blocking SetVariable() variant, in violation of UEFI's non-reentrancy rules. reset_system() is reachable too: efi_reboot() only gates it on the static efi_rt_services_supported() mask, which does not track the runtime disable. Check efi_enabled(EFI_RUNTIME_SERVICES) in each before calling into firmware. Test it after taking efi_runtime_lock rather than before: the bit is only ever cleared at runtime while that lock is held, so checking it under the lock avoids racing with a concurrent timeout that clears the bit and drops the lock. Suggested-by: Ard Biesheuvel Signed-off-by: Breno Leitao Signed-off-by: Ard Biesheuvel commit 60618389de92444b3b11a6385c306109fc89c46a Author: Breno Leitao Date: Tue Jun 16 05:09:38 2026 -0700 efi/runtime-wrappers: bound the wait for EFI runtime service calls When an EFI runtime service hangs in firmware, the efi_rts_wq worker is stuck inside the call and cannot be cancelled. __efi_queue_work() then waits on the completion forever while holding efi_runtime_lock, so every later EFI caller is wedged until reboot; the only symptom is a "workqueue lockup" and tasks piling up on the semaphore. Replace wait_for_completion() with wait_for_completion_timeout() bounded by EFI_RTS_TIMEOUT (120 seconds). On timeout, clear EFI_RUNTIME_SERVICES and return EFI_ABORTED so later callers fail fast at the entry check instead of each paying another 120 seconds. The wedged worker is intentionally leaked and keeps ownership of efi_rts_work. A worker that only starts running after the timeout would otherwise dereference efi_rts_work.args, now pointing into the caller's freed stack frame, and hand stale pointers to firmware. Park it with efi_rts_park_worker() at the entry of efi_call_rts() when runtime services are already disabled, before it touches args or enters firmware. Known limitation: a worker already inside firmware when the timeout fires still holds efi_rts_args pointing into the caller's stack frame; if firmware unblocks afterwards and writes the output buffers, they land in reused memory. Firmware hung this long rarely recovers; a follow-up could bounce the buffers through kmalloc. Signed-off-by: Breno Leitao Signed-off-by: Ard Biesheuvel commit 7f64cb373f3dcc20d0e27e273dae10975a94d7e8 Author: Breno Leitao Date: Tue Jun 16 05:09:37 2026 -0700 efi/runtime-wrappers: check EFI_RUNTIME_SERVICES before using efi_rts_work Move the EFI_RUNTIME_SERVICES check to the top of __efi_queue_work() and return directly, so a caller that finds runtime services disabled returns without touching the shared efi_rts_work. No functional change. This prepares for bounding the wait, where a timeout will clear EFI_RUNTIME_SERVICES while the leaked worker still owns efi_rts_work; a later caller must then bail out before reinitialising it. Signed-off-by: Breno Leitao Signed-off-by: Ard Biesheuvel commit c554d4e534bbfc9d88ffdbfeea754b4111843608 Author: Breno Leitao Date: Tue Jun 16 05:09:36 2026 -0700 efi/runtime-wrappers: handle queue_work() failure with goto exit Convert the queue_work() failure path in __efi_queue_work() to a goto exit instead of falling through to the wait and the WARN_ON_ONCE(status == EFI_ABORTED) below it. A failed queue_work() leaves the status at its initial EFI_ABORTED, so that warning would fire even though no call ran; it is meant for a completed call that returned EFI_ABORTED. No change for the common (successful enqueue) path. This also prepares __efi_queue_work() for the timeout handling added later. Signed-off-by: Breno Leitao Signed-off-by: Ard Biesheuvel commit ecbccdbdab5d31e1e465e3f789d57bb34e5452cd Author: Breno Leitao Date: Tue Jun 16 05:09:35 2026 -0700 efi/runtime-wrappers: factor out efi_rts_park_worker() x86's efi_crash_gracefully_on_page_fault() ends in an infinite schedule() loop so the kworker that faulted in firmware never runs efi_rts_wq again. A later change needs the same "park this worker forever" primitive on the runtime service timeout path, so factor the loop into a shared efi_rts_park_worker() and call it from the x86 page-fault handler. No functional change. Signed-off-by: Breno Leitao Signed-off-by: Ard Biesheuvel commit 766062a82e1ce4087c7dc077224144dfd34b3661 Author: Hyunchul Lee Date: Thu Aug 20 11:18:51 2026 +0900 ntfs: reject invalid empty mapping pairs Reject an attribute with empty mapping pairs if it has inconsistent highest VCN and size. Fixes: 11ccc9107dc4 ("ntfs: update runlist handling and cluster allocator") Reported-by: Robert Morris Closes: https://lore.kernel.org/all/9519.1786907182@localhost/ Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 9969d58a9b0417393d033b24c670d57b686cabbf Author: Hongling Zeng Date: Thu Aug 20 16:14:10 2026 +0800 ntfs: fix resource leak in ntfs_new_attr_flags When handling resident attributes that don't need sparse/compressed changes, ntfs_new_attr_flags() returns 0 directly at line 678 without calling unmap_mft_record() or ntfs_attr_put_search_ctx(). This leaks the MFT record mapping and attribute search context. An unprivileged user can cause a denial of service by repeatedly calling setxattr(2) with system.ntfs_attrib on files with resident attributes, eventually exhausting kernel memory. Fix by replacing the direct return with goto err_out to ensure proper cleanup of resources via the existing cleanup code. Fixes: e791930240a5 ("ntfs: fix resident conversion in ntfs_new_attr_flags") Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Signed-off-by: Namjae Jeon commit 81684340963da2e898eabb8c1e274433d9375bc6 Author: Dennis Tighe Date: Thu Aug 20 19:28:39 2026 +0900 ntfs: validate usa_ofs before preserving the update sequence number When ntfs_mft_record_alloc() reuses a free mft record it reads the old update sequence number straight from the on-disk record: usn = *(__le16 *)((u8 *)m + le16_to_cpu(m->usa_ofs)); Here m points into the raw $MFT page-cache folio, which still holds unvalidated, MST-protected bytes: the folio is read by a plain iomap_read_folio() and neither post_read_mst_fixup() nor ntfs_mft_record_check() has run on it (both work on private copies). m->usa_ofs is therefore an untrusted u16, and a corrupted record can put it past the end of the record so the two-byte read lands outside the folio. Reading such a record while creating a file gives, under KASAN: BUG: KASAN: use-after-free in ntfs_mft_record_alloc+... Read of size 2 at addr ... ntfs_mft_record_alloc -> __ntfs_create -> ntfs_create -> path_openat Only preserve the old update sequence number when usa_ofs is even and in range, mirroring the check ntfs_mft_record_check() already applies; otherwise leave usn zero, which the existing restore below skips. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dennis Tighe Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit 98716c9fce21f6c8a9d71e08cf53e7504fa562f4 Author: Dennis Tighe Date: Wed Aug 19 23:32:58 2026 -0700 ntfs: fix off-by-one page overflow in ntfs_decompress() The per-token range check in ntfs_decompress() uses if (cb >= cb_sb_end || dp_addr > dp_sb_end) break; so dp_addr == dp_sb_end falls through to the symbol copy `*dp_addr++ = *cb++`, writing one byte past the destination page. Since NTFS_SB_SIZE == PAGE_SIZE the destination is a single page, so the byte lands in the adjacent page, and *dest_ofs is left one past the sub-block end (the later `*dest_ofs &= ~PAGE_MASK` then yields 1, not 0, so the page is never finalized and later sub-blocks keep writing further past it). A corrupted compressed $DATA attribute thus produces a bounded run of out-of-bounds writes when the file is read. Break as soon as dp_addr reaches dp_sb_end; a full sub-block still completes, as its final copy advances dp_addr to exactly dp_sb_end. Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dennis Tighe Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon commit e1e3a0ab69c64eedaf53dce9306f8a090bf038f0 Author: Nathan Chancellor Date: Wed Aug 19 14:43:21 2026 -0700 ARM: Fix get_cycles() after delay_read_timer() conversion After commit dfc256dac54c ("calibrate: Rework delay timer calibration"), certain ARM configurations (such as multi_v5_defconfig) hang during boot. The use of read_current_timer() in arch/arm's get_cycles() was improperly converted to delay_read_timer(), resulting in get_cycles() returning 0 even when the timer has been read or an uninitialized stack value when delay_read_timer() returns false. Flip the branches of the ternary condition to fix get_cycles(). Fixes: dfc256dac54c ("calibrate: Rework delay timer calibration") Signed-off-by: Nathan Chancellor Signed-off-by: Thomas Gleixner Reviewed-by: Jinjie Ruan Cc: Thomas Gleixner Cc: linux-arm-kernel@lists.infradead.org Link: https://patch.msgid.link/20260819-fix-arm-get_cycles-v1-1-208bf07ac540@kernel.org commit 23906f3a1686c737bf356fdd21183b40722b2437 Author: Jake Steinman Date: Wed Aug 19 09:20:59 2026 -0400 sched/fair: Floor tg_cpus() at 1 tg_cpus() returns cpuset_num_cpus() unfloored, while its sibling tg_tasks() already floors its result at 1. calc_concur_shares() feeds nr = min(tg_tasks(tg), tg_cpus(tg)) into __calc_smp_shares() as shares_max, so an nr of 0 makes shares_max 0. __calc_smp_shares() ends with return clamp_t(long, shares, MIN_SHARES, shares_max); and clamp() yields hi when hi < lo, so a zero shares_max silently defeats the MIN_SHARES floor and returns 0 -- the exact case the comment above that line says must return MIN_SHARES instead of 0. That leaves a group sched_entity with load.weight == 0, and __calc_prop_weight() then divides by cfs_rq->load.weight: weight *= se->load.weight; if (parent_entity(se)) weight /= cfs_rq->load.weight; which takes a #DE inside enqueue_task_fair(): Oops: divide error: 0000 [#1] SMP NOPTI RIP: 0010:enqueue_task_fair+0x422/0x950 Call Trace: enqueue_task+0x8e/0x250 wake_up_new_task+0x148/0x2e0 kernel_clone+0x1c6/0x390 __x64_sys_clone+0xcc/0x100 do_syscall_64+0x147/0x3c0 This is not survivable in practice: with panic_on_oops=0 the kernel took the first #DE and continued for 476 ms, then faulted at the same RIP with identical register state and an identical RSP, because the oops recovery path (kill task -> schedule()) re-enters the same enqueue while the rq lock is held mid-enqueue. The second fault escalates to a panic. Flooring tg_cpus() at 1 makes it symmetric with tg_tasks() and keeps shares_max >= tg_shares, so the MIN_SHARES floor in __calc_smp_shares() can no longer be bypassed. Note this only removes the division hazard. Whether cpuset_num_cpus() can legitimately return 0 -- via the cpu hotplug/suspend path where a v2 cpuset may transiently become empty, or via an RCU race -- is a separate question still open on the report thread. Fixes: 90ac22ffef48 ("sched/fair: Add cgroup_mode: max") Signed-off-by: Jake Steinman Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/20260818231333.1441757-1-j@metarealtyinc.ca/ Link: https://patch.msgid.link/20260819132104.2148918-1-j@metarealtyinc.ca commit 666a32836c8f9daf9b0067c49b04d5201fb8f3ba Author: Sebastian Andrzej Siewior Date: Thu Aug 13 09:38:55 2026 +0200 sched/topology: Add a cpus_read_lock to rebuild_sched_domains() A read from /proc/sys/kernel/sched_rt_runtime_us leads to backtrace due to missing cpu_hotplug_lock with CONFIG_CPUSETS=n. The callchain is sched_rt_handler() -> partition_sched_domains() -> sched_cache_set() -> static_key_enable_cpuslocked(&sched_cache_present). sched_cache_set() itself is also invoked from sched_init_domains() which is early during the boot, holding just the sched_domains_mutex_lock(). Here is no warning because it happens before user space is running (and hotplug operations are not possible). There is also sched_cache_active_set() which acquires the hotplug lock before invoking any of the _cpuslocked() functions. This is only a problem with CONFIG_CPUSETS=n because in the =y case the other implementation of rebuild_sched_domains acquires the CPU-hotplug lock. Acquire CPU hotplug lock before in rebuild_sched_domains(), before partition_sched_domains() is invoked for the CONFIG_CPUSETS=n case. Fixes: a7660ce1590fc ("sched/cache: Fix has_multi_llcs iff at least one partition has multiple LLCs") Signed-off-by: Sebastian Andrzej Siewior Reivewed-by: Ridong Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Chen Yu Reviewed-by: Tim Chen Reviewed-by: Waiman Long Reviewed-by: Valentin Schneider Reviewed-by: Shrikanth Hegde Reviewed-by: Aaron Tomlin Tested-by: Dietmar Eggemann Link: https://patch.msgid.link/20260813073855.ji2UrtVh@linutronix.de commit 2b366b833f52a37f70be845892c1f5fe1d993051 Author: Zhang Heng Date: Thu Aug 20 15:37:44 2026 +0800 ALSA: hda/conexant: Simplify headset plugin type handling Both the CTIA and OMTP branches of cx_process_headset_plugin() write the same value to the headset-mic pin, differing only in the debug message. Merge the two branches into a single one, leaving the codec write unchanged. No functional change. Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260820073744.521680-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai commit e711ebfadc9a9b7ee9fcb6b5c8c6b1bfc0cc4a87 Author: Habil Eren Türker Date: Wed Aug 19 20:08:59 2026 +0300 ALSA: hda/realtek: Add quirk for HP Laptop 15-fd0039nt This patch adds a quirk for the HP Laptop 15-fd0039nt (SSID 103c:8bb6) to fix the micmute LED functionality. The micmute LED is controlled via GPIO 0 with active-low polarity. Tested-by: Habil Eren Türker Signed-off-by: Habil Eren Türker Link: https://patch.msgid.link/20260819170919.3172-1-habilerenturker@hotmail.com Signed-off-by: Takashi Iwai commit d736eba9c453fedce664fdf592c8b71ecff1932b Author: Haotian Zhang Date: Thu Aug 20 09:41:17 2026 +0800 ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup snd_ice1712_probe() performs multiple initialization steps after snd_card_new(), but directly returns on failures from later steps without releasing the ALSA card, causing resource leaks when probing fails. Use snd_devm_card_new() together with scope-based cleanup via __free(snd_card_unref), and clear the card pointer after successful registration to keep it alive. Fixes: ca642da4b33d ("ALSA: ice1712: Allocate resources with device-managed APIs") Suggested-by: Takashi Iwai Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20260820014117.14044-1-vulab@iscas.ac.cn Signed-off-by: Takashi Iwai commit a1ee1a1ca75b674f503c74eb8b3ca77612ba3c0c Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:35 2026 +0200 irqchip/gic-v5: Defer default SPI and LPI IAFFID programming SPI and LPI interrupts do not have an architected default value for their IAFFID (interrupt affinity ID) - the property that determines an IRQ affinity. Current code awkwardly tries to set a default IAFFID value corresponding to the logical cpu executing the gicv5_hwirq_init() function at SPI/LPI allocation time. There are two issues with this approach: - gicv5_hwirq_init() is called in preemptible context and current code uses smp_processor_id() to check the logical cpu executing the function. Whilst that's harmless, it can spit a splat on DEBUG_PREEMPT kernels - Setting the default SPI/LPI IAFFID to the one belonging to the cpu executing the IRQ allocation is a completely arbitrary choice It is saner to remove the SPI/LPI IAFFID set-up in the SPI/LPI domain IRQ allocation code and flag SPI/LPI irqchips as IRQCHIP_AFFINITY_PRE_STARTUP so that the SPI/LPI affinity is initialized by IRQ core to a sane value before an IRQ is started up using the respective irq_chip irq_set_affinity() callback. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-7-3743e82c69a4@kernel.org commit 9dfcc2187282816d42b9f8aa2b689c732ebbcc01 Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:34 2026 +0200 irqchip/gic-v5: Use logical cpu 0 irs_data for dynamic IST allocation In set-ups with a 2-level IST, L1 table entries are created dynamically when LPIs are allocated. The L1 allocation and mapping, implemented in gicv5_irs_iste_alloc() is carried out in preemtible context and can be carried out on any IRS in the system. Current code indexes the per_cpu_irs_data per cpu array using smp_processor_id() to retrieve the IRS that is local to the core executing gicv5_irs_iste_alloc(). Since that's preemptible context, the core executing that function can change on preemption. Given that every IRS in the system is equivalent to each core, this is not really an issue in that even if the thread is preempted and resumed on a different cpu, the table allocation and mapping to an IRS would work seamlessly regardless. On the other hand, smp_processor_id() spits a legitimate splat on DEBUG_PREEMPT kernels when used in preemtible context and this should be fixed. Given that all IRSes are equivalent from a core perspective in terms of IST initialization, always choose as a policy the IRS local to logical cpu 0, preventing the smp_processor_id() splat. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-6-3743e82c69a4@kernel.org commit dc2eae1620bdb4562aa43f1c34c8427308ab4436 Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:33 2026 +0200 irqchip/gic-v5: Release IRS iomem region on driver init failure In gicv5_irs_of_init(), an IRS is set-up using of_io_request_and_map() to request its memory region (corresponding to the configuration frame) and map the IRS configuration frame. On gicv5_irs_of_init() failure, the driver unmaps the IRS iomem region but does not release the requested memory region leaving it allocated in the iomem resource tree. Fix it by releasing the iomem region on gicv5_irs_of_init() probe failure. Likewise, on both OF and ACPI driver init failure, IRS iomem regions are requested but never released in gicv5_irs_remove(). Stash a copy of the IRS iomem region in a struct resource in struct gicv5_irs_chip_data and use it to release the requested region in gicv5_irs_remove() if the driver probe fails. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-5-3743e82c69a4@kernel.org commit 183750b276c229c5253b3b11581f6cd8877b753e Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:32 2026 +0200 irqchip/gic-v5: Fix gicv5_init_common() error paths Current code fails to disable interrupts on gicv5_starting_cpu() failure and to set the handle_arch_irq pointer to NULL if gicv5_irs_enable() fails. Update the respective error paths to fix them. Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-4-3743e82c69a4@kernel.org commit 79b115c2a29204cb7e836b0df0b8c466be4b2250 Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:31 2026 +0200 irqchip/gic-v5: Disable IRSes on probe failures GICv5 driver probe failures cause IRSes initialized by the kernel to be unmapped and their data structures to be destroyed but the current driver leaves the probed IRSes enabled, whereas they should be disabled. Disable IRSes on driver probe failures so that the IRSes are brought back to their quiescent HW state. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-3-3743e82c69a4@kernel.org commit aa079dbf4c2598c2613a0e464efcb2c232753c51 Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:30 2026 +0200 irqchip/gic-v5: Check for NULL LPI domain on domain teardown In gicv5_free_lpi_domain() the LPI domain being freed can be NULL. Check it and return before trying to free it if it is. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-2-3743e82c69a4@kernel.org commit 328affc639ce9873a7a0a3fd6b8339f19767529b Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:29 2026 +0200 irqchip/gic-v5: Check get_logical_index() return value in MADT IAFFID parsing In gic_acpi_parse_iaffid() a given MADT GICC entry might not correspond to a logical cpu recognized by the kernel, resulting in the cpu variable initialization to an error value. Currently, the get_logical_index() return value is not checked for failure, which might result in out-of-bounds memory corruption while trying to index a per_cpu variable array. Add a check to evaluate get_logical_index() return value. Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-1-3743e82c69a4@kernel.org commit ac6db0e0bee18cd4385418c752a007e1aba4ec14 Author: Sascha Bischoff Date: Tue Aug 11 15:27:31 2026 +0000 irqchip/gic-v5: Synchronize CPU interface disable The write disabling the GICv5 CPU interface is only guaranteed to take effect after a context synchronization event. Without one, execution can return from gicv5_cpu_disable_interrupts() while an interrupt is still able to be taken. Add an ISB after the ICC_CR0_EL1 write to ensure interrupts are disabled before the function returns. No corresponding ISB is added when enabling the interface, as interrupt delivery is asynchronous and there is no obvious benefit to waiting for it. Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support") 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=6 Link: https://patch.msgid.link/20260811152630.942023-3-sascha.bischoff@arm.com commit 3dfc0ab5fefd052c6028c4632b1fad8bdaf7967e Author: Sascha Bischoff Date: Tue Aug 11 15:27:00 2026 +0000 irqchip/gic-v5: Clear per-CPU IRS data on teardown 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 commit 34b7e953d19a39515f8fc6c0820ebf243ea6b026 Author: Michael Pesa Date: Tue Jul 21 22:02:43 2026 -0700 irqchip/ast2700-intc: Disable all interrupt merge banks on probe The INTC0 interrupt-merge (INTM) space has 50 sources at 10 per bank, i.e. INTC0_INTM_NUM / INTM_IRQS_PER_BANK = 5 banks. This is reflected everywhere the banks are indexed: the aspeed_intc0_intm_routes[] table has 5 valid entries, and the mask/unmask/eoi paths compute the bank as (hwirq - INTM_BASE) / INTM_IRQS_PER_BANK, spanning banks 0-4. However, INTC0_INTM_BANK_NUM is hardcoded to 3, so aspeed_intc0_disable_intm() only clears IER for banks 0-2 at probe. Banks 3 and 4 are left in whatever state the firmware configured them , which can leave interrupts enabled before a handler is installed. Derive the bank count from the source count so the probe-time disable covers every bank. Fixes: 07825e41519a ("irqchip/ast2700-intc: Add AST2700-A2 support") Signed-off-by: Michael Pesa Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260722050243.298355-1-michael.pesa@icloud.com commit fbfa013eeac299ecc015cb14fa40e382a23fb489 Author: Pedro Kopper Date: Fri Aug 14 10:22:13 2026 +0100 clk: microchip: mpfs: fix regmap_update_bits() mask/val order mpfs_cfg_clk_set_rate() passes the mask and value arguments to regmap_update_bits() in the wrong order. The resulting write becomes reg = orig_reg | val, causing bits to not be cleared if the clock divider changes. Pass the arguments in the correct order so the divider field is updated as intended. Fixes: c6f2dddfa7f9 ("clk: microchip: mpfs: use regmap for clocks") Signed-off-by: Pedro Kopper Reviewed-by: Conor Dooley Cc: stable@vger.kernel.org Signed-off-by: Stephen Boyd commit 39c0e6c844a14945040cca4ccf6997792ab764c4 Author: Geert Uytterhoeven Date: Wed Aug 19 21:05:16 2026 +0200 clk: visconti: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. visconti_clk_register_gate() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: b4cbe606dc3674b2 ("clk: visconti: Add support common clock driver and reset driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Reviewed-by: Nobuhiro Iwamatsu Signed-off-by: Stephen Boyd commit 3ae1674975d48fb6d343d03ff7961abd6904af1a Author: Geert Uytterhoeven Date: Wed Aug 19 21:05:15 2026 +0200 clk: ti: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. _register_mux() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter is uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: 667f420c09f1417c ("clk: ti: mux: resolve parent clocks by DT index, not by name") Closes: https://lore.kernel.org/CAMuHMdU3yVqoyHC4eNF2NuYo8wy+6ODLoYat4R71X99Mxc_=kw@mail.gmail.com Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Reviewed-by: Mathieu Dubois-Briand Signed-off-by: Stephen Boyd commit eef628bce8e18ce1eb8531c396bf55e36f86c62c Author: Konrad Dybcio Date: Mon Aug 17 15:33:46 2026 +0200 mailmap: fix bouncing address for Taniya Das The quic_username@quicinc.com emails have been deprecated inside Qualcomm for a while now in favor of firstname.lastname@oss.qualcomm.com Re-route the emails to Taniya's current OSS email address to avoid Outlook bounces ("recipient's inbox is full"). Link: https://lore.kernel.org/20260817-topic-taniya_email_bounce-v1-1-d7af1f113d64@oss.qualcomm.com Signed-off-by: Konrad Dybcio Cc: Taniya Das Signed-off-by: Andrew Morton commit 763c097f71bc6106e1b1e28a96e9e4e5ced6228c Author: Zhan Xusheng Date: Tue Aug 11 10:43:37 2026 +0800 ocfs2: bound-check dir entries in the inline-data re-validation scan ocfs2_dir_foreach_blk_id() re-scans the inline data area the same way ocfs2_dir_foreach_blk_el() re-scans a directory block, and is missing the same two bounds: for (i = 0; i < i_size_read(inode) && i < offset; ) { de = (struct ocfs2_dir_entry *)(data->id_data + i); if (le16_to_cpu(de->rec_len) < OCFS2_DIR_REC_LEN(1)) break; i += le16_to_cpu(de->rec_len); } ocfs2_validate_inode_block() keeps i_size inside the inline area: if (le16_to_cpu(data->id_count) > ocfs2_max_inline_data_with_xattr(sb, di)) if (le64_to_cpu(di->i_size) > le16_to_cpu(data->id_count)) and that area runs to the end of the inode block, so for a full inline directory data->id_data + i_size is the end of di_bh->b_data. A bogus rec_len leaves i in the last OCFS2_DIR_REC_LEN(1) - 1 bytes of it, and de->rec_len, at byte offset 8 within the entry, is then read past the block. The emit loop below hands i_size_read(inode) to ocfs2_check_dir_entry(), which refuses both an entry that close to the end and one whose rec_len runs past it. Apply the same two bounds to the re-validation scan, reading i_size once into a local as ocfs2_check_dir_entry() takes it as @size. Unlike the extent case there is no mask to corrupt here: an unbounded i only sets ctx->pos past i_size, which ends the readdir early rather than moving it to the wrong place. Link: https://lore.kernel.org/20260811024337.3972976-3-zhanxusheng@xiaomi.com Signed-off-by: Zhan Xusheng 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 commit bec0eed29b41a4e1b922d9ce40a748216496ed6e Author: Zhan Xusheng Date: Tue Aug 11 10:43:36 2026 +0800 ocfs2: bound-check dir entries in the readdir re-validation scan Patch series "ocfs2: bound-check both readdir re-validation scans", v2. This patch (of 2): When the inode version changed since the last readdir(), ocfs2_dir_foreach_blk_el() re-scans the directory block from its start to relocate the current position: for (i = 0; i < sb->s_blocksize && i < offset; ) { de = (struct ocfs2_dir_entry *)(bh->b_data + i); if (le16_to_cpu(de->rec_len) < OCFS2_DIR_REC_LEN(1)) break; i += le16_to_cpu(de->rec_len); } i walks the block on rec_len values taken from the block itself and the only thing tested is that rec_len is not too small, so a single bogus rec_len leaves i anywhere in the block, including its last OCFS2_DIR_REC_LEN(1) - 1 bytes. @offset comes from ctx->pos, which userspace moves with lseek() on the directory fd, and decides how far the walk gets. Two bounds are missing, both of which ocfs2_check_dir_entry() applies for the emit loop below. de->rec_len sits at byte offset 8 within the entry, so dereferencing de in that tail reads past the s_blocksize buffer. ocfs2_check_dir_entry() declines to look at an entry that close to the end: size - buf_offset < OCFS2_DIR_REC_LEN(1) Nothing bounds i += rec_len either, so i can end up past the block. The emit loop that follows is guarded by offset < sb->s_blocksize and does not run, but offset = i; ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; runs first and ORs a value with bits above the block mask into ctx->pos, corrupting the block number readdir() resumes from. ocfs2_check_dir_entry() rejects that as "directory entry overrun": next_offset = buf_offset + rlen; ... next_offset > size Apply both bounds. For a consistent directory this changes nothing: entries are at least OCFS2_DIR_REC_LEN(1) bytes and do not cross the end of the block, so no valid entry is skipped. Found by the sashiko review tool; fix approach suggested by Joseph Qi. Link: https://lore.kernel.org/20260811024337.3972976-1-zhanxusheng@xiaomi.com Link: https://sashiko.dev/#/patchset/20260806022044.167962-1-zhanxusheng@xiaomi.com Link: https://lore.kernel.org/20260811024337.3972976-2-zhanxusheng@xiaomi.com Signed-off-by: Zhan Xusheng Suggested-by: Joseph Qi 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 commit f6f47a9ca82b3943c136494143f41366f83a2584 Author: Usama Arif Date: Fri Aug 7 10:24:21 2026 -0700 squashfs: avoid thundering-herd cache wakeups squashfs_cache_get() puts a task to sleep when its block is not cached and every cache entry is busy. Those sleeps are non-exclusive, so the nr_exclusive == 1 budget squashfs_cache_put() has always passed to wake_up() is inert and one release makes every waiter runnable. A wakee only returns to squashfs_cache_get() if it observes cache->unused before the entry is reclaimed; later wakees see zero and re-queue inside wait_event() without rescanning. One freed entry satisfies exactly one capacity waiter, so waking the rest is waste. On a Meta production host serving a Python web application from a packaged squashfs image, a 30-second trace caught 1,045,132 cache-release wake calls and 19,511,556 wakeups: 18.7 per release, although each release added only one reusable cache entry. This was causing significant spikes in CPU usage. Make the waits exclusive, enqueueing while still holding cache->lock so that a concurrent lookup either sees the waiter queued or the waiter sees the block that lookup publishes. Two things follow. A wakee cannot be assumed to consume the entry it was woken for: it may find its own block published meanwhile, share that entry, and leave the freed one unclaimed. So a wakee which shares hands its wakeup on to the next waiter, as commit 0ddad21d3e99 ("pipe: use exclusive waits when reading or writing") does with wake_next_reader. And a waiter can now sleep through a publication of the very block it wants, which the old broadcast gave it repeated chances to notice. So waiters are keyed by block: publishing wakes every waiter for that block (nr_exclusive == 0), freeing an entry wakes one. That needs a custom wake callback, like wake_page_function() in mm/filemap.c, which also records which wakeup arrived so the handoff only fires for a capacity wakee. Broadcast is kept where more than one task can proceed - every waiter for a published block, and the wake_up_all() on entry->wait_queue - at the cost of walking the queue under wait_queue.lock to test the key. Waiters are now served FIFO with a scheduling round trip per handoff hop, so per-waiter latency changes; the filebench run below is 4x oversubscribed, where that should hurt most. Measured on a 32-CPU VM against a read-only squashfs (gzip, DECOMP_MULTI_PERCPU, FILE_DIRECT, default 8 metadata / 3 fragment cache entries) staged in tmpfs, page cache dropped each iteration to force cold decompression: elbencho, 64 threads metadata stat 700 -> 1320 files/s 1.9x small-file read 40 -> 60 MiB/s 1.5x filebench, 128 threads, open+read+stat+close (mean of 3x 30s) throughput 11,314 -> 25,186 ops/s 2.2x sched:sched_wakeup 27.0 -> 4.55 per op 5.9x fewer context switches 37.2 -> 7.64 per op 4.9x fewer Wakeups and context switches are per operation, since the two runs did 2.2x different amounts of work. Workloads which never queue for a cache entry gain no wakeups. Link: https://lore.kernel.org/20260807172421.3875982-1-usama.arif@linux.dev Signed-off-by: Usama Arif Reviewed-by: Phillip Lougher Cc: Boris Burkov Cc: Christian Brauner Cc: Jeff Layton Cc: Johannes Weiner Cc: Rik van Riel Cc: Shakeel Butt Signed-off-by: Andrew Morton commit 5146e0688d86f0654263e4b0e4ff1719b4072f16 Author: Bradley Morgan Date: Sun Aug 9 00:29:01 2026 +0000 prctl: fix PR_SET_MM_AUXV losing the forced AT_NULL terminator prctl_set_auxv() copies the user vector into a stack buffer, forces AT_NULL on the last two entries there, and then copies only len bytes into mm->saved_auxv. Which is fine until the vector is shorter than the buffer, because then the forced terminator sits past the end of the copy and never lands in saved_auxv at all. The code even says /* Make sure the last entry is always AT_NULL */ and it does, just not in the part that gets copied. So mm->saved_auxv keeps the stale tail from exec. Reproducing it is easy: from a process with CAP_SYS_RESOURCE (just run it as root), call prctl(PR_SET_MM, PR_SET_MM_AUXV, ...) with a vector that has a couple of entries and no AT_NULL inside len (32 bytes on arm64), and then hexdump /proc/self/auxv, or gcore the process and look at the AUXV note with readelf -n. This is arm64, the new vector was just { AT_UID, 0x1111, AT_GID, 0x2222 }: idx before (from exec) after the prctl [0] AT_SYSINFO_EHDR 0x7ed1d6e000 AT_UID 0x1111 <- new [1] AT_MINSIGSTKSZ 0x1270 AT_GID 0x2222 <- new [2] AT_HWCAP 0x119fff AT_HWCAP 0x119fff <- stale [3] AT_PAGESZ 0x1000 AT_PAGESZ 0x1000 <- stale ... 16 more entries ... <- stale [20] AT_NULL 0x0 AT_NULL 0x0 21 entries before the prctl, still 21 after: the two new ones plus all 19 left over from exec. Every consumer walks the vector until AT_NULL, so what they get now is a vector that never existed at exec, the head from the prctl glued onto the tail of the old binary. gdb and crash pull the AUXV note out of coredumps to find AT_PHDR, AT_ENTRY, AT_SYSINFO_EHDR and friends, and a mixed vector points them at the wrong layout. /proc//auxv and PR_GET_AUXV hand the same mess out to live processes too. Nothing crashes, everything just quietly reads a frankenstein auxv. And callers that terminate their own vector hide the whole thing, which is likely why nobody noticed since PR_SET_MM_AUXV landed in 2012. Nothing exciting security wise either, I mean it needs CAP_SYS_RESOURCE to begin with. prctl_set_mm_map() right above already copies the whole buffer for exactly this reason, so just do the same here. user_auxv is zero initialized and only partially filled from userspace, so the rest is zeros and nothing leaks. Link: https://lore.kernel.org/20260809002901.32591-1-include@grrlz.net Fixes: fe8c7f5cbf91 ("c/r: prctl: extend PR_SET_MM to set up more mm_struct entries") Signed-off-by: Bradley Morgan Cc: Alexey Dobriyan Cc: Cyrill Gorcuno Signed-off-by: Andrew Morton commit dfe88f832fe80f11077cb9d3de39e78f04a158a4 Author: Linfeng Sun Date: Mon Aug 10 15:32:35 2026 +0800 mailmap: update email address for Linfeng Sun 1. Update my university email to my personal Gmail, as the former will expire after graduation. 2. Fix a typo in my Gmail domain. Link: https://lore.kernel.org/20260810073235.22980-1-linfeng.sun.dev@gmail.com Signed-off-by: Linfeng Sun Signed-off-by: Andrew Morton commit d9c0fd5533fb23bc445bd581feb140e966195936 Author: Karl Mehltretter Date: Sat Aug 8 14:36:08 2026 +0200 lib/interval_tree: fix allocation warning messages WARN_ON_ONCE() takes a condition, not a message. The string literals are always true, so the warnings still trigger but the messages are never printed. Use WARN_ONCE(1, ...) instead to print the messages and keep the once-only behavior. Found with a Coccinelle script. Clang's -Wstring-conversion also flags such calls but is not enabled in kernel builds. Link: https://lore.kernel.org/20260808123608.73613-1-kmehltretter@gmail.com Fixes: 82114e45131f ("lib/interval_tree: add test case for interval_tree_iter_xxx() helpers") Assisted-by: Claude:claude-fable-5 coccinelle Signed-off-by: Karl Mehltretter Reviewed-by: Andrew Morton Reviewed-by: Wei Yang Signed-off-by: Andrew Morton commit c44e278ce02efd0c4be79a8eda1ea6885c1ce5ec Merge: 65b92bc671db7c 8d3ae59288f1e7 Author: Dave Airlie Date: Thu Aug 20 10:58:44 2026 +1000 BackMerge tag 'v7.2' into drm-next Linux 7.2 There was a lot of conflicts this round between fixes and next, and I'd like to get the merge resolutions that we have in drm-tip. Signed-off-by: Dave Airlie commit a4ff2be345d0abc943da8dd8da98151843b750dc Merge: a51ec5e8e5dae8 7537036a2e6fe9 Author: Linus Torvalds Date: Wed Aug 19 17:25:42 2026 -0700 Merge tag 'v7.3-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto update from Herbert Xu: "API: - Add af_alg_restrict sysctl and white list - Fix potential suspend/resume races in hwrng Algorithms: - Optimize vli additive operations using compiler builtins in ecc Drivers: - Remove unsafe/deprecated algorithms from qce - Mark qce as BROKEN - Add runtime PM and interconnect bandwidth scaling support to qce - Remove crypto_rng from qcom, sun8i and caam - Fix SG list issues in iaa - Fix SEV init path bugs in ccp" * tag 'v7.3-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (122 commits) crypto: lskcipher - propagate errors from unaligned crypt crypto: keembay - use crypto_memneq() to compare CCM AEAD tags crypto: keembay - use crypto_memneq() to compare GCM AEAD tags crypto: sa2ul - use crypto_memneq() to compare AEAD tag hwrng: drivers - use named initializers for acpi_device_id crypto: qce - fix CCM AAD buffer underallocation crypto: iaa - unmap dst before software fallback on decompress crypto: iaa - use bounce buffer for multi-sg decompress input crypto: iaa - avoid counting fallback decompression bytes crypto: iaa - fall back to software for multi-entry scatterlists hwrng: core - Stop/start hwrng_fillfn() kthread before/after suspend-resume crypto: hisilicon/sec2 - fix CCM algorithm long packet failure crypto: eip93 - use struct_size() and flexible array for ring allocation crypto: krb5 - use kfree_sensitive() for derived key buffers crypto: af_alg - Stop after finding name in allowlist crypto: af_alg - Replace 'bool privileged' with flags crypto: af_alg - Make cbc(paes) privileged-only hwrng: imx-rngc - Disable clock on registration failure crypto: qat - remove dead ADF_HEX code crypto: qce - simplify qce_handle_request ... commit a51ec5e8e5dae80824239f0344210060cb92a4b0 Merge: cbad8981fa3b1f f1e10b10874051 Author: Linus Torvalds Date: Wed Aug 19 17:17:17 2026 -0700 Merge tag 'integrity-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity Pull integrity updates from Mimi Zohar: - TPM initialization is sometimes delayed until deferred_probe_initcall Since ordering is not guaranteed within the same initcall level, IMA may initialize before the TPM and fall back to TPM-bypass mode. A new config option, CONFIG_IMA_INIT_LATE_SYNC, allows those building the kernel to defer IMA initialization to late_initcall_sync, accepting the integrity risk of missing early measurements in exchange for avoiding TPM-bypass mode. - The raw policy rules are now measured, as well as the complete policy, closing a gap in integrity measurement coverage * tag 'integrity-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: ima: measure userspace policy writes before parsing ima: add critical data measurement for loaded policy security: ima: rename boot_aggregate when ima is initialised at late_sync security: ima: introduce IMA_INIT_LATE_SYNC option security: lsm: allow LSMs to register for late_initcall_sync init commit cbad8981fa3b1fc726e6e5652e92fd76c01e543c Merge: 09005a63988521 fedc88e38ce979 Author: Linus Torvalds Date: Wed Aug 19 16:51:39 2026 -0700 Merge tag 'Smack-for-7.3' of https://github.com/cschaufler/smack-next Pull smack updates from Casey Schaufler: - Spelling fix - Code optimization in smackfs - Fix credential mis-uses - Place limits on two of the smackfs interfaces * tag 'Smack-for-7.3' of https://github.com/cschaufler/smack-next: smack: fix cred UAF in smack_file_send_sigiotask() smack: restrict smackfs/{direct,mapped} values to 0-255 smack: deduplicate smackfs/{direct,mapped} file_operations smack: show msgrcv() subject task in audit smack: fix incorrect task context in smack_msg_queue_msgrcv security: smack: fix spelling mistake smack: simplify write handlers of sysfs entries Smack: Fix error in capability bypass commit 09005a63988521f74111fae344aecb3f63306168 Merge: 4253eb09d25bcf 0cee720cfd5140 Author: Linus Torvalds Date: Wed Aug 19 16:28:23 2026 -0700 Merge tag 'lsm-pr-20260814' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm Pull LSM updates from Paul Moore: - Remove task_euid() The task_euid(), and Rust counterpart, was never widely used, for good reason, and now that the only user is gone we're removing it to rid ourselves of both dead and funky code. - Documentation improvements Correct some of the kdoc comments for security_task_prctl() and clarify the rust comments on task UID accessors. - Fix a memory leak in the LSM syscall selftests * tag 'lsm-pr-20260814' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm: selftests/lsm: Fix memory leak in attr_lsm_count cred: delete task_euid() rust: task: clarify comments on task UID accessors lsm: clarify security_task_prctl() hook documentation commit 4253eb09d25bcfe44f6987b6f67c09f09d80a966 Merge: 83453b6f5131a8 fd6e2388a3ea55 Author: Linus Torvalds Date: Wed Aug 19 16:24:46 2026 -0700 Merge tag 'selinux-pr-20260814' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux Pull selinux updates from Paul Moore: - Convert a __get_free_page() call into a kmalloc() call We had some very old code that called out to __get_free_page() for allocating a pathname. There is no reason this couldn't be done with a call to kmalloc() so we've done the conversion and now there is one less __get_free_page() caller in the kernel. - Limit the number of retired/unknown DCCP netlink messages While DCCP is gone from the kernel, there are still userspace tools which try to talk to the kernel about DCCP sockets which were generating SELinux related log noise (unrecognized netlink message). This pull request both limits the log messages to just the first instance and also explains to the user that DCCP support has been removed. - Convert the SELinux strlcat() calls to seq_buf_XXX() calls As part of the effort to drop the strlcat() API from the kernel, the SELinux/IMA code was converted over to using seq_buf_XXX() calls. - Only calculate the SELinux IMA configuration string length once Previously each call to generate a SELinux configuration string for IMA would have to calculate the length of the string. While the contents of the string will likely change over the lifetime of the system, the length of the string will not. Calculate the string length once at boot and reuse the length value throughout the lifetime of the system. - Further validation of the SELinux policy at policy load time Perform additional sanity checks on the policy constraints and types. - Proper cleanup and error handling for selinuxfs init failures We were not properly cleaning up some state in the case where selinuxfs fails to initialize properly. It's somewhat of an academic exercise as a failure to initialize selinuxfs will cause the system to fail on boot, but it's arguably better to make sure we do things the proper way. - Various code cleanups Convert integer flags to boolean types and drop an uncessary goto from the SELinux code. * tag 'selinux-pr-20260814' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux: selinux: validate constraint expression attr and op at load time selinux: compute the IMA configuration settings string length once at boot selinux: replace strlcat() with seq_buf in selinux_ima_collect_state() selinux: suppress warning flood for retired DCCP netlink messages selinux: tighten type validation during policy load selinux: drop unnecessary goto and label from avc_alloc_node() selinux: convert int flags to bool flags in ss/services.c selinux: clean up selinuxfs resources on init failure selinux: hooks: use kmalloc() to allocate path buffer commit 83453b6f5131a83af7b2a4df28bc776353ac56c5 Merge: cb8a75eec08778 783f0f0974c156 Author: Linus Torvalds Date: Wed Aug 19 16:21:32 2026 -0700 Merge tag 'audit-pr-20260814' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit Pull audit updates from Paul Moore: - Drop BUG_ON() assertions from two functions While I don't recall any bug reports from either of these assertions in recent memory, neither of these checks warrant the kernel panic that could result from BUG_ON(). One of the BUG_ON() calls is converted to a WARN_ON_ONCE() and the other to a lockdep assertion. - Fix an audit tree reference counting problem Fix a corner case where audit could end up unintentionally dropping the last reference to an audit tree while the tree was still in use. We should probably revisit the audit tree handling code in full, but this patch works, and should be easy to backport to stable trees and downstream kernels. - Update the audit syscall classification tables Add some missing syscalls to the PERM class * tag 'audit-pr-20260814' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit: audit: avoid dropping live tree ref on fsnotify rule autoremove audit: drop BUG_ON() from audit_signal_info_syscall() audit: drop BUG_ON() from audit_add_to_parent() audit: add missing syscalls to PERM class tables commit ca45cfa74370644d371b552bef57938c19e3c80c Author: Linkai Gong Date: Fri Jul 31 16:04:58 2026 +0800 rtc: gamecube: check return value of devm_rtc_register_device() gamecube_rtc_probe() ignored the return value of devm_rtc_register_device() and always returned success. Propagate the error so probe fails when RTC registration fails. Fixes: 86559400b3ef ("rtc: gamecube: Add a RTC driver for the GameCube, Wii and Wii U") Signed-off-by: Linkai Gong Link: https://patch.msgid.link/20260731080458.417532-1-gonglinkai@kylinos.cn Signed-off-by: Alexandre Belloni commit 878d93aaa596a861dbc8d71f7c38e62a2e805f01 Author: Robert Leussler Date: Tue Jul 21 08:19:07 2026 +0000 rtc: ds1307: fix RX8130 wakeup alarm WADA bit for day-of-month mode The RX8130 wakeup alarm never fired when set via /sys/class/rtc/rtc0/wakealarm. The root cause is that the WADA bit (bit 3) in the Extension register (0x1c) was never set before programming the alarm registers. Per the RX8130 datasheet: WADA=0 - Week alarm: register 0x19 is compared against day-of-week WADA=1 - Day alarm: register 0x19 is compared against day-of-month rx8130_set_alarm() always writes a BCD day-of-month value to alarm register 0x19, so WADA must be 1. With WADA=0 the hardware matched the day-of-month value (e.g. 15) as a day-of-week index, which is always out of range (valid weekdays are 0-6), so the alarm interrupt was never asserted. Fix by setting the WADA bit in rx8130_set_alarm() before writing the Extension register back to the device. This is consistent with rx8130_read_alarm(), which decodes the same register under the same assumption (24-hour and day-of-month mode). Signed-off-by: Robert Leussler Link: https://patch.msgid.link/20260721081907.3518648-1-robert.leussler@leica-geosystems.com Signed-off-by: Alexandre Belloni commit b1407862fb57c6455a04fa5d0d02b58496a38cc9 Author: Sang-Heon Jeon Date: Fri Jul 24 03:45:31 2026 +0900 rtc: pcf2127: remove conditional return with no effect Both branches of the check return the same value, so the check has no effect. Remove it and return the value directly. This is the result of running the Coccinelle script from scripts/coccinelle/misc/cond_return_no_effect.cocci. Signed-off-by: Sang-Heon Jeon Reviewed-by: Bruno Thomsen Link: https://patch.msgid.link/20260723184538.3888637-30-ekffu200098@gmail.com Signed-off-by: Alexandre Belloni commit 4d31434fea516f10ccff35db4a21773780f08cee Author: Eduard Bostina Date: Sun Jul 19 14:10:07 2026 +0000 dt-bindings: rtc: Convert TI Palmas RTC to DT schema Convert the Texas Instruments Palmas RTC controller bindings to DT schema. As part of the conversion, declare 'wakeup-source: true'. This documents the Palmas PMIC's capability to wake the system. Signed-off-by: Eduard Bostina Reviewed-by: Rob Herring (Arm) Link: https://patch.msgid.link/20260719141008.3562347-2-egbostina@gmail.com Signed-off-by: Alexandre Belloni commit 745ca1b959d9f08cbfd15891aa74ef4e3e847952 Author: Teja Sai Charan Bellamkonda Date: Fri Jul 10 03:49:44 2026 +0530 dt-bindings: rtc: Convert rtc-cmos binding to YAML Convert the rtc-cmos devicetree bindings to dt schema. The original text binding documents only the motorola,mc146818 compatible. Existing in-tree Devicetree sources also use the intel,ce4100-rtc compatible together with the motorola,mc146818 fallback, but this was not documented. Document the Intel variant in the schema so that these existing configurations are accepted during schema validation. Signed-off-by: Teja Sai Charan Bellamkonda Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260709221944.159244-1-tejaasaye@gmail.com Signed-off-by: Alexandre Belloni commit 1190db8edcd91309e64d8212c1ca8b90a4ed732d Author: Udaya Kiran Challa Date: Fri Jul 3 16:34:42 2026 +0530 dt-bindings: rtc: microchip,pic32mzda-rtc: Convert to DT schema Convert Microchip PIC32 Real Time Clock and Calendar devicetree binding from legacy text format to DT schema. Signed-off-by: Udaya Kiran Challa Acked-by: Conor Dooley Link: https://patch.msgid.link/20260703110442.205026-1-challauday369@gmail.com Signed-off-by: Alexandre Belloni commit cb8a75eec0877810b50aa1c5a833f929525cd2ee Merge: 1484625c5968ca 8b502bf6eb3da1 Author: Linus Torvalds Date: Wed Aug 19 14:22:07 2026 -0700 Merge tag 'trace-ringbuffer-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull ring-buffer updates from Steven Rostedt: - Remove unneeded semicolon A macro ended with a semicolon that wasn't needed. - Fix freeing cpu_buffer extra subbuffer with order greater than zero When the cpu_buffer was being freed, its "free" page, was using free_page() to free it when it could be more than one page. - Hold the cpu_buffer lock when resizing the subbuffer The freeing of the "free" page of the cpu_buffer was done without locking. The order of the data was being saved and then the "free" page was set to NULL. But there is a race that the "free" page could have been updated between those two operations. Add locking around it to prevent the race. - Save the order of the data along with the data in the free page The cpu_buffer would store just the data portion of the subbuffer page in its descriptor. But it did not store the order of the data pages. The order was being saved in the global buffer descriptor. But this leads to races. Have the cpu_buffer save the subbuf data along with its metadata (which includes the order of the page) to make sure when it frees it, it frees the correct order along with it. - Remove the subbuf_size and use the order directly when needed Having a size field for the size of the subbufer along with its order allowed for races to have them get out of sync. Remove the subbuf_size and use the order from the subbuf meta data directly under locks. Use the subbuf_order for other calculations in the ring buffer. - Remove the useless "cpus" field of trace_buffer The code has been restructured and the "cpus" field is no longer used. Remove it. - Remove the "mapped" field of the ring buffer and use a helper function instead. The "mapped" field has become a bit overused and made the code come complex in using a counter for what is denoted as being mapped or not. There are other fields that are set when the ring buffer is considered mapped. Add a helper function to check those fields and use that instead of keeping track of a counter. * tag 'trace-ringbuffer-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: ring-buffer: Remove ring_buffer_per_cpu::mapped ring-buffer: Remove trace_buffer::cpus ring-buffer: Dynamically calculate max_data_size ring-buffer: Fix subbuf resize race with ring_buffer_alloc_read_page() ring-buffer: Fix subbuf resize race with ring buffer readers ring-buffer: Make cpu_buffer::free_page a buffer_data_read_page ring-buffer: Hold cpu_buffer::lock when resizing a subbuf ring-buffer: Free cpu_buffer::free_page with subbuf_order ring-buffer: drop unneeded semicolon commit 315d11a89147724528d867268382812913bd2ead Author: Bhargav Joshi Date: Tue Aug 4 22:35:08 2026 +0530 dt-bindings: rtc: ti,omap-rtc: Convert to DT schema Convert the Texas Instruments OMAP Real Time Clock (RTC) binding from the legacy text format to the DT schema. Mark 'ti,hwmods' as deprecated as it is no longer used, it is kept to support legacy boards. Signed-off-by: Bhargav Joshi Reviewed-by: Rob Herring (Arm) Link: https://patch.msgid.link/20260804-ti-omap-rtc-v3-4-ba3bbd8af570@gmail.com Signed-off-by: Alexandre Belloni commit 1484625c5968cad5e26b653d13b4b7a18c07834d Merge: 081e5bf2a9d941 43a17abc83c640 Author: Linus Torvalds Date: Wed Aug 19 14:18:45 2026 -0700 Merge tag 'tracefs-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracefs updates from Steven Rostedt: - Define event fields before directory creation Move the event_define_fields() call in event_create_dir() before the eventfs directory creation. Previously, a failure after directory creation wouldn't clean up eventfs_inode because the error path didn't call eventfs_remove_dir(). This eliminates the need to clean up the eventfs directories if event_define_fields() fails. - Add warning for out of bounds pos in __eventfs_iterate() Sashiko complains about the ctx->pos causing issues if it is less than 2 or greater than MAX_INT in __eventfs_iterate(). The thing is, the logic prevents that from happening. But to make Sashiko happy, add a WARN_ON() and exit safely if the function ever does get input that is out of the range the function expects. * tag 'tracefs-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: eventfs: Add warning for out of bounds pos in __eventfs_iterate() eventfs: Define event fields before directory creation commit aa8e5dc6a7a2a1141ab40706a51010adcd0e57d2 Merge: 2791de535400bc 302f94dc3f8c21 Author: Oliver Upton Date: Wed Aug 19 14:08:24 2026 -0700 Merge branch 'kvm-arm64/misc-7.3' into next * kvm-arm64/misc-7.3: : Miscellaneous fixes for KVM/arm64, 7.3 : : - Fixes for saving invalid table entries as part of saving the ITS : tables (Fuad Tabba) : : - Don't reallocate the SPI array for re-attempted vgic_init(), avoiding : a memory leak (Fuad Tabba) : : - Hold a reference on an LPI when saving the pending state (Qihang) : : - Don't WARN for out-of-range, guest-supplied INTID (Karl) : : - Avoid corrupting GPRs for 32-bit CP64 reads (Karl) : : - Reset 'in kernel' VGIC state when private IRQ allocation fails (Fuad) : : - Avoid kallsyms lookup in nVHE panic unless the host stage-2 is also : disabled (Vincent) : : - Disregard Pending+Active state when computing maintenance IRQ for : ICH_MISR_EL2.NP (Kajetan) : : - Various Sashiko-identified issues dealing with GICv5 (Sascha) : : - Fix CPU onlining in pKVM due to mismatched accesses when the MMU is : disabled (Will) KVM: arm64: Validate GICv5 timer PPIs before claiming ownership KVM: arm64: vgic: Reject out-of-range GICv5 PPI IDs KVM: arm64: vgic: Prevent speculative SPI array underflow KVM: arm64: vgic: Free gic_kvm_info on initialization failure KVM: arm64: Avoid mismatched accesses to 'struct kvm_nvhe_init_params' KVM: arm64: vgic: Fix detection of MI on no pending LR KVM: arm64: Drop %pB on nVHE panic when stage-2 is active KVM: arm64: vgic: Reset in_kernel on private IRQ allocation failure KVM: arm64: GICv2: Don't WARN on out-of-range GICV_DIR INTID KVM: arm64: Preserve GPRs for AArch32 CP64 reads generating an UNDEF KVM: arm64: vgic-v3: take an LPI reference in vgic_v3_save_pending_tables KVM: arm64: vgic-its: Point saved ITEs at the next valid entry KVM: arm64: vgic-its: Don't save collections the table cannot hold KVM: arm64: vgic: Don't leak the SPI array when init is retried KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save Signed-off-by: Oliver Upton commit 081e5bf2a9d941da60cd70c97c5a704b29e47f7f Merge: 00d66b29a66ce1 ae70b04ab9c7f6 Author: Linus Torvalds Date: Wed Aug 19 14:06:14 2026 -0700 Merge tag 'trace-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing updates from Steven Rostedt: - Expose btf_ids to trace events In order to allow BPF programs to attach to system call trace events (which are actually pseudo trace events built on top of raw_syscall events), expose the BTF ID of the events. This will allow BPF programs better precision in attaching to events. - Use "u64" to assign to hist_field->type Instead of using kstrdup("u64", GFP_KERNEL) to assign the hist_field->type, just point it to "u64" instead. The hist_field->type is freed via kfree_const(). - Replace kmalloc()/strcpy() with kstrdup() for trace_printk Instead of having two calls to copy the module format string, just use kstrdup(). - Use __free() in trace event histograms and triggres where possible - Use seq_buf in trace event code instead of strcat() Instead of calculating the size of the buffer to use and filling it with strcat(), use the seq_buf infrastructure that takes care of making sure not to overflow the string size. - Reject invalid preemptirq_delay_test CPU affinity The preempt_delay_test module can take an invalid CPU affinity mask and create confusing output. Simply have the module reject invalid affinity masks. - Prevent division by zero in ftrace_ops sample module code If the ftrace_ops sample module code receives the module parameter nr_function_calls set to zero, it can cause a division by zero error. - Warn when an event dereferences a parameter in TP_printk() On boot up and module load, the trace event TP_printk() is scanned for possible bugs. As the TP_printk() code is executed when the user reads the "trace" file and processes the data written when the trace_event executed, the data it reads can be literally days old. The scan currently checks for dereferencing printk formats like "%pI6". But it does not check if the parameters themselves have a dereference like: TP_printk("offset %08x: value %08x", (u32)(__entry->addr - __entry->edma->membase), __entry->value) __entry represents the pointer to the event on the ring buffer. The __entry->edma->membase is dereferencing a pointer on the ring buffer to find membase, but the __entry->edma may no longer be a valid pointer. Warn on this case too. - Replace some strcpy() with strscpy() - Clean up mmiotrace events to use assign_type() macro The assign_type() macro makes sure the event type is indeed the type that is being parsed. The mmiotrace trace was written before that macro was created so it just simply typecasted the pointer. Replace the typecasting with the macro. - Have the ENUM processing to numbers only process what is added The code that converts ENUMs to their numbers in the trace events scanned all events to do the processing. This was true when a module was loaded too. That is, instead of processing just the events for the module, it processed *all* events. Even the builtin ones that were processed at boot up. Add a check for the event->module matching mod if it is a module before processing it. * tag 'trace-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: (21 commits) tracing: Have trace_event_update_all() only handle module that is loading tracing: Cleanup event_enable_trigger_parse() by using __free() tracing: Report every TP_printk double dereference tracing/mmiotrace: Use trace_assign_type() in mmio_print_mark() tracing: Make per-template BTF id lists file-local tracing: Use seq_buf for string concatenation tracing: Use strscpy() instead of strcpy() in trace_sched_switch tracing: Warn when an event dereferences a pointer in TP_printk() samples/ftrace: Prevent division by zero when nr_function_calls is zero tracing: Reject invalid preemptirq_delay_test CPU affinity fgraph: Use trace_seq_putc() in print_graph_return() tracing/user_events: Replace a seq_printf() call by seq_puts() in user_seq_show() tracing/user_events: Use seq_putc() in two functions tracing: Bound histogram expression strings with seq_buf tracing: Return ERR_PTR() from expr_str() tracing: Use __free() for expr_str() buffer kernel/trace/trace_printk: Use kstrdup() instead of kmalloc() and strcpy() tracing: Point constant hist field type to string literal selftests/bpf: Add test for tracepoint btf_ids tracefs file tracing: Expose tracepoint BTF ids via tracefs ... commit 2791de535400bc40fd837baa756117434df7895d Merge: c75d616c082e19 36d32222fcab09 Author: Oliver Upton Date: Wed Aug 19 14:05:49 2026 -0700 Merge branch 'kvm-arm64/vtr-patch' into next * kvm-arm64/vtr-patch: : Inline patching of ICH_VTR_EL2 constant, courtesy of Marc Zyngier : : Unify readers of ICH_VTR_EL2 on an instruction-patched constant value, : avoiding system register accesses known to trap under nested : virtualization and sharing the implementation between pKVM and 'regular' : KVM. KVM: arm64: vgic-v3: Kill kvm_vgic_global_state.ich_vtr_el2 KVM: arm64: vgic-v3: Simplify initial GICv3 configuration sampling KVM: arm64: Convert most ICH_VTR_EL2 accesses to inlined literal value KVM: arm64: Add a helper providing an inlined literal value for ICH_VTR_EL2 KVM: arm64: Move GICv3 broken SEIS implementation detection to a CPU errrata KVM: arm64: vgic-v3: Make vtr_to_* helpers use architectural field symbols Signed-off-by: Oliver Upton commit 00d66b29a66ce18e417a8436076c629d03186a27 Merge: 3793b558ff3b1c 88b3e7fedc07d9 Author: Linus Torvalds Date: Wed Aug 19 14:01:58 2026 -0700 Merge tag 'ftrace-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull ftrace updates from Steven Rostedt: - Deprecrate ftrace_enabled in disabling ftrace The file /proc/sys/kernel/ftrace_enabled was created when ftrace was first introduced back in 2008. It was to be a "kill switch" if something was to go wrong. It was also used as a way to turn off function tracing for the latency tracers that would have it on by default. But in 2013 (Linux 3.10) the option "function-trace" was introduced to disable function tracing for the latency tracers as the "ftrace_enabled" file was considered too big of a hammer and caused too many side effects. When live kernel patching came along, disabling ftrace via the ftrace_enabled file would put the system into an unstable state if a live kernel patch was installed. This created the need to mark some function hooks as "PERMANENT". Now there's a need for BPF usage marked as PERMANENT for the same reasons. The file "ftrace_enabled" usage is no longer viable. It doesn't do what it says it does and there is no reason to use it. Make writing '0' to it a nop and print a message saying its usage is deprecated. The return value of writing '0' is -EOPNOTSUPP so that user space will error on that write (hopefully to inform any developer that it no longer works). Eventually the file should be removed completely, but for now just making it not do anything is the path forward to that. - Update the livepatch tests to handle ftrace_enabled being disabled Because in the past, livepatch was broken by ftrace_enabled being turned off, there's a test case that checks to make sure it still doesn't break. But having the write of '0' return an error caused that test to break. Updated the test to handle the new change. * tag 'ftrace-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: selftests/livepatch: update test-ftrace.sh for deprecated ftrace_enabled ftrace: deprecate disabling via ftrace_enabled sysctl commit 3793b558ff3b1cae64a3eddb497ab9e5636bf022 Merge: 55ee4b931a7ffe 0ad45018ace734 Author: Linus Torvalds Date: Wed Aug 19 14:00:15 2026 -0700 Merge tag 'trace-tools-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull RTLA updates from Steven Rostedt: - Extend support for unsetting CLI options libsubcmd auto-generates "--no-