commit f45ed76d6791cf72ff1265ee93511175bbbc2f18 Author: Greg Kroah-Hartman Date: Fri Oct 30 13:06:41 2026 +0100 Linux 6.18.60 Link: https://lore.kernel.org/r/20261028165942.357251485@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Pavel Machek (CIP) Tested-by: Miguel Ojeda Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Wentao Guan Tested-by: Barry K. Nathan Signed-off-by: Greg Kroah-Hartman commit 057cd46db83f79d9e10974a2c5884c0a5343aa63 Author: Rafael J. Wysocki Date: Mon Dec 15 14:59:00 2025 +0100 ACPI: tiny-power-button: Convert the driver to a platform one [ Upstream commit f4203ec64e1155c07c5d95bddc62201af8598c67 ] While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI tiny-power-button driver to a platform one. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Signed-off-by: Rafael J. Wysocki [ rjw: White space fixup ] Link: https://patch.msgid.link/5629403.Sb9uPGUboI@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 05a4e200b129293d9aafa2f5addc74d656dbadd8 Author: Rafael J. Wysocki Date: Thu Aug 20 21:11:14 2026 +0200 ACPI: scan: Do not combine resources that overlap completely [ Upstream commit 7617cc05df28dcae967cca109de74084321eaa62 ] 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 Signed-off-by: Sasha Levin commit 67073dd6a642acd8890cc7d0190a94fb8576594d Author: Ilpo Järvinen Date: Tue Mar 24 18:56:24 2026 +0200 resource: Add __resource_contains_unbound() for internal contains checks [ Upstream commit edfaa81d5da5fbfe3c73fece3ca0417a04cc4ba2 ] __find_resource_space() currently uses resource_contains() but for tentative resources that are not yet crafted into the resource tree. As resource_contains() checks that IORESOURCE_UNSET is not set for either of the resources, the caller has to hack around this problem by clearing the IORESOURCE_UNSET flag (essentially lying to resource_contains()). Instead of the hack, introduce __resource_contains_unbound() for cases like this. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Xifer Link: https://patch.msgid.link/20260324165633.4583-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit 112182caff410c860d2df3e1a68d2d278a0b8095 Author: Rafael J. Wysocki Date: Fri Aug 7 12:22:37 2026 +0200 ACPI: scan: Avoid registering platform devices with resource overlaps commit f234fdaae1cad8c39265e7ca0a14633076ec7154 upstream. If acpi_dev_get_resources() returns overlapping I/O or memory resources, the subsequent registration of a platform device will fail with -EBUSY due to a resource conflict. This is reported to happen on Acer Aspire ES1-572 [1]. Avoid that by adjusting resources returned by acpi_dev_get_resources() to eliminate partial overlaps between them. This has not been regarded as necessary before because putting overlapping resources into the _CRS of one device is really pointless, but now that the issue has been reported to actually happen in the field, it needs to be done. Fixes: ab06eb920401 ("ACPI: scan: Register platform devices for fixed event buttons") Fixes: 48fe2cddc85c ("tpm_crb: Convert ACPI driver to a platform one") Reported-by: Julien Tested-by: Julien Reviewed-by: Paul Menzel Reviewed-by: Andy Shevchenko Closes: https://lore.kernel.org/linux-integrity/CAJOGg3z6LJPDsdPNBxajgy8_wQxfhYBRxe4EiurZf3kPU5A5Bw@mail.gmail.com/ [1] Cc: All applicable Signed-off-by: Rafael J. Wysocki [ rjw: Tweaked the new message ] Link: https://patch.msgid.link/12955541.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 70178691c467c8f9f722765299fd8524c3121a35 Author: Christian Brauner Date: Mon Aug 24 14:08:20 2026 +0200 pid_namespace: prevent TIF_NOTIFY_SIGNAL from interrupting the reaper commit 5c0985dd3c32fc2bbd0e8beaf13cf52cd97376a2 upstream. Since commit 7fea700e04bd ("zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING") zap_pid_ns_processes() clears TIF_NOTIFY_SIGNAL before every kernel_wait4() call. Otherwise kernel_wait4() doesn't sleep and returns -ERESTARTSYS if signal_pending() is true and the reaper busy-waits. But clearing TIF_NOTIFY_SIGNAL doesn't fix it. It can get raised again. For example, klp_send_signals() sets it raw against any task that hasn't transitioned yet. And it keeps sending it until the livepatch finishes. The sleep loop waiting for pid_allocated to drop has the same problem and it doesn't even clear anything. So a schedule() in TASK_INTERRUPTIBLE returns immediately. Use a no_notify_signal guard. signal_pending() will ignore TIF_NOTIFY_SIGNAL and the pid namespace reaper sleeps until a child exits or free_pid() wakes it. Link: https://patch.msgid.link/20260824-work-tif_notify_signal-v2-5-6609e42b3157@kernel.org Fixes: 7fea700e04bd ("zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING") Reviewed-by: Oleg Nesterov Cc: stable@vger.kernel.org Suggested-by: Oleg Nesterov Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 2decf30c2427c29b7ec2ed460f199e93f25c0cf6 Author: Christian Brauner Date: Mon Aug 24 14:08:16 2026 +0200 signal: allow taks to temporarily block TIF_NOTIFY_SIGNAL commit 22b7f491be8f93ff72de0a3fe02b8ee9e64d3f21 upstream. TIF_NOTIFY_SIGNAL is used to kick a task in uninterruptible sleep to return to userspace and run task work and then go back to sleep. This mechanism works well but breaks e.g., coredumps. dump_interrupted() only allows fatal signals to interrupt a coredump and the whole regular write path going to actual filesystems is impervious to TIF_NOTIFY_SIGNAL as well. Add PF_NO_NOTIFY_SIGNAL and helpers to raise and restore it. This is the same approach as memalloc_nofs_save(). signal_pending() will not report a fake pending signal via TIF_NOTIFY_SIGNAL if inside a PF_NO_NOTIFY_SIGNAL section. No functional changes. Link: https://patch.msgid.link/20260824-work-tif_notify_signal-v2-1-6609e42b3157@kernel.org Reviewed-by: Oleg Nesterov Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 7df22750f30db46372a46bceafbf4c1913f23a87 Author: Christian Brauner Date: Mon Sep 21 15:44:57 2026 +0200 exit: hang up the tty before closing the files commit ad016f0131ebfec250a3360ea75d35128b3f4aa8 upstream. do_exit() closes the task's files in exit_files() and hangs up the controlling tty of a session leader in disassociate_ctty(1) after that. Since commit d99d38540bf0 ("fs: make close_files() synchronous") the final __fput() of every file runs inside exit_files(). So when the session leader holds the last open of its tty the tty is released before disassociate_ctty() runs. tty_release() clears signal->tty for the whole session in session_clear_tty() once the count drops to zero and sends no signal doing so. disassociate_ctty(1) then finds neither a tty nor a tty_old_pgrp and does nothing. The foreground process group loses its SIGHUP: do_exit() exit_files() close_files() tty_release() tty->count == 0 session_clear_tty() signal->tty = NULL, no signal disassociate_ctty(1) get_current_tty() NULL signal->tty_old_pgrp NULL, nothing sent That only affects real ttys. For a pty the master's open keeps the slave's count above zero. And it only affects a foreground job that holds no descriptor to the tty anymore while its session leader exits. Everything else is unchanged. The DTR drop on the last close happens in tty_port_shutdown() regardless, stopped jobs get their SIGHUP from kill_orphaned_pgrp() and signal->tty is cleared either way. Before that commit the final __fput() ran from exit_task_work() which comes after disassociate_ctty(). That order isn't old. Until v3.14 exit_task_work() came right after exit_files() and before v3.6 fput() was synchronous, so the tty was always released first. Commit c39df5fa37b0 ("exit: call disassociate_ctty() before exit_task_namespaces()") moved disassociate_ctty() up to fix a pppd crash and in front of exit_task_work() as a side effect. The hangup in this case has worked since then and that's eleven years of userspace being able to rely on it. Hang the tty up before closing the files. This is the ordinary hangup with the file still open: __tty_hangup() swaps in hung_up_tty_fops and tty_release() runs from the close afterwards as it does when a modem drops the line. disassociate_ctty() stays in front of exit_task_namespaces() which the pppd fix needs. Reported-by: Chris Mason Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-8-8e4adb1619e6@kernel.org Acked-by: Oleg Nesterov Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit f7ac8500d58e7684d37403553b1dea90ee2b27b1 Author: Christian Brauner Date: Mon Sep 21 15:44:56 2026 +0200 fork: release the files of a failed fork after sched_cancel_fork() commit 296a98c1fa50778c3b31eebed1a3f903f9684349 upstream. Reorder copy_process() cleanup so sched_fork() taking scx_fork_rwsem scx_pre_fork() is safe and isn't held around exiting files. Right now, a fork that fails while another thread closed the bpf link fd will deadlock against its own read side. It also blocks every fork on the system: copy_process() holds scx_fork_rwsem for read exit_files() close_files() filp_close_sync() bpf_scx_unreg() kthread_flush_work() waits for the disable work scx_root_disable() percpu_down_write(&scx_fork_rwsem) Simply release the child's files after sched_cancel_fork() dropped the lock. The task starts out as a copy of its parent so p->files points to the parent's table until copy_files() replaces it. exit_files() must not run for a fork that failed before that. Clear p->files up front so exit_files() is a no-op for those and make copy_files() set it explicitly for CLONE_FILES. Reported-by: Chris Mason Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-7-8e4adb1619e6@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 85b3ef7b9648a3b309195526f5d4f7dba89eb01c Author: Christian Brauner Date: Mon Sep 21 15:44:58 2026 +0200 ptrace: refuse to change the signal mask of a user worker commit cabc249e6560bee7bdfee9fbcb7ce4e951dcfd41 upstream. A user worker is created with every signal other than SIGKILL and SIGSTOP blocked. It never runs user code and that mask is what keeps get_signal() from dequeuing anything else for it. complete_signal() never picks a thread that blocks the signal, tkill() queues on the worker but nothing dequeues it. ptrace_signal() requeues an injected signal that the tracee blocks. PTRACE_SETSIGMASK is the only way to change that mask from the outside. A tracer that clears it makes the worker eligible for every signal. Whatever the worker then dequeues it can only act on by leaving. Refuse PTRACE_SETSIGMASK for a user worker with -EPERM, the way ptrace_attach() refuses a kernel thread. A worker is guaranteed to only ever dequeue SIGKILL or SIGSTOP and an injected signal stays pending on it, which is what already happens when the mask isn't touched. Taking the request and quietly leaving the mask alone was the other option, the way set_current_blocked() keeps SIGKILL and SIGSTOP unblocked whatever userspace asks for. But then a tracer gets success back with nothing changed and no way to tell that apart from a mask that took effect. Fixes: e8b33b8cfafc ("Revert "kernel: treat PF_IO_WORKER like PF_KTHREAD for ptrace/signals"") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-9-8e4adb1619e6@kernel.org Acked-by: Oleg Nesterov Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 19c3fbf86c2a970f74db24dedb615b1bc4e67691 Author: Christian Brauner Date: Tue Sep 22 15:26:16 2026 +0200 signal: only SIGKILL and the freezers interrupt a coredumping task commit 563d606b93d7a1d23512832fc252d32c68860d87 upstream. For quite a while now coredump has allowed either SIGKILL or freezing to interrupt an ongoing coredump. Since we seem to like it complicated "freezing" can mean a lot of things: (1) Power Management induced freezing (2) cgroup v1 freezer controller induced freezing (3) cgroup v2 freezer controller induced freezing So (1) and (2) are handled by checking freezing() but (3) isn't. (3) uses cgroup_freeze_task() which sets JOBCTL_TRAP_FREEZE and calls signal_wake_up() on every task in the cgroup. The trap isn't handled by the coredump code. Which means the current logic is inconsistent. Power and cgroup v1 freeze and abort the coredump. With cgroup v2 it depends on where the core goes. A dump to a file completes and the cgroup v2 freeze has to wait for it to finish. When dumping to a pipe or socket the dump is interrupted at the next write because of trap's TIF_SIGPENDING. Which is it? Let's be consistent and align (1)-(3): freezing interrupts an ongoing coredump and doesn't make it wait until the dump is done. All three freezers go through signal_wake_up() and so set TIF_SIGPENDING on the dumper. And once zap_threads() has set core_state that flag can't mean anything else anymore. prepare_signal() drops every signal but SIGKILL for the group, the dying threads don't retarget shared signals to the dumper, and zap_process() cleared the pending job control traps. So the flag is the thing to check. Let dump_interrupted() test task_sigpending() and nothing else. That is also what the pipe and socket writes already fail on. TIF_NOTIFY_SIGNAL is left out on purpose, task work must not cut a dump short. A seized tracee that gets PTRACE_INTERRUPT during the dump is cut short the same way. It already was for pipes and sockets. The one freeze that check can miss is one requested before the dump started. zap_threads() clears TIF_SIGPENDING and the cgroup v2 freezer only wakes a task once while its JOBCTL_TRAP_FREEZE isn't part of JOBCTL_PENDING_MASK and survives zap_process(). So refuse to start the dump when freezing() is true or the trap is pending. The task then exits without dumping, which is what happens today when the freeze interrupts the dump at the first write. Fixes: 403bad72b67d ("coredump: only SIGKILL should interrupt the coredumping task") Fixes: 76f969e8948d ("cgroup: cgroup v2 freezer") Cc: stable@vger.kernel.org Suggested-by: Oleg Nesterov Link: https://lore.kernel.org/r/arJ6zZuI59BJnXpl@redhat.com Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-2-8e4adb1619e6@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit c91e2a1f058dbe41e19fada4cbd57cc15555e3c4 Author: Christian Brauner Date: Mon Sep 21 15:44:54 2026 +0200 signal: don't retarget shared signals in a dying thread group commit c0e659511d4f49087da095a95799edb5b775a705 upstream. If the calling thread has blocked a signal then retarget_shared_pending() slingshots a shared pending signal to a sibling thread. Today it only skips PF_EXITING threads but not a coredumping thread. But if SIGNAL_GROUP_EXIT is set no thread in the thread-group can dequeue such signals anymore as get_signal() sends SIGKILL to every thread and prepare_signal() drops any other signal. exit_signals() also returns early on SIGNAL_GROUP_EXIT. But neither sigprocmask() nor the mask restore in sigtimedwait() do. Say a thread sleeps in sigtimedwait() and a sibling thread crashes. The sleeping thread gets woken by the zap call. It restores its mask on the way out and retargets a signal that was queued for the coredumping process. That means TIF_SIGPENDING is set on the coredumping task which zap_threads() had cleared. So a blocking write sees TIF_SIGPENDING and truncates the dump. Stop retargeting signals when SIGNAL_GROUP_EXIT is set and avoid needlessly truncating coredumps. Fixes: e6fa16ab9c1e ("signal: sigprocmask() should do retarget_shared_pending()") Cc: stable@vger.kernel.org Acked-by: Oleg Nesterov Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-5-8e4adb1619e6@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 16e94ed90b1b02398e044d41fd1db34828daa08e Author: Christian Brauner Date: Mon Sep 21 15:44:50 2026 +0200 coredump: hold RCU while releasing parked threads commit 61d58591aa0188bf2463e263962256316ff8b576 upstream. coredump_finish() releases the parked threads by clearing ->task in their core_thread entry and calling wake_up_process() on each of them. It does that without holding a reference on the task and without being inside rcu. But calling wake_up_process(task) without rcu here isn't safe. A parked thread doesn't need that wakeup to leave. A spurious wakeup or a preemption after the store is enough for the task to go away. So if the coredump client is preempted between the store and wake_up_process() the thread can exit and be freed in the meantime and try_to_wake_up() takes pi_lock in freed memory. Hold rcu across the loop. Fixes: a94e2d408eae ("coredump: kill mm->core_done") Cc: stable@vger.kernel.org Acked-by: Oleg Nesterov Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-1-8e4adb1619e6@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 8932e5a4df110a25578728526bb5a3dbc849d8a2 Author: Aaron Ahmed Date: Fri Oct 16 23:04:03 2026 +0000 ftrace: Initialize modname and offset in print_rec() commit e1f339ff3b83857b93baf8b88186275a413d445e upstream. print_rec() leaves 'modname' and 'offset' uninitialized and kallsyms_lookup() only sets them on success. When the lookup fails like when a module is being loaded or unloaded, 'modname' holds a garbage value, passes the 'if (modname)' check, and is dereferenced by seq_printf(). Oops: general protection fault RIP: 0010:string+0x48/0xe0 Call Trace: vsnprintf+0x1f5/0x650 seq_printf+0x8e/0xb0 print_rec+0x6c/0xc0 t_show+0x4c/0x440 seq_read_iter+0x119/0x480 This can be triggered by reading available_filter_functions while a module is being loaded or unloaded. Initialize both variables so a failed lookup skips the module name. Cc: stable@vger.kernel.org Fixes: b39181f7c690 ("ftrace: Add FTRACE_MCOUNT_MAX_OFFSET to avoid adding weak function") Link: https://patch.msgid.link/20261016230403.4916-1-aarnahmd@amazon.com Tested-by: Gavin Inglis Signed-off-by: Aaron Ahmed Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 1aa0c7aa4c2554a5b6d74ae1924508ca4718234b Author: Weiming Shi Date: Sun Sep 6 19:01:53 2026 +0800 asymmetric_keys: reject trust keys without IDs commit 9695df3b1db4ac4534274d38ee16e3b9b0bf910e upstream. The PKCS#8 parser deliberately leaves the asym_key_ids payload slot empty. key_or_keyring_common() unconditionally dereferences that slot when a PKCS#8 key is supplied to a key_or_keyring restriction. Both the plain and :chain forms reach this branch, allowing an unprivileged caller to trigger a NULL pointer dereference through KEYCTL_RESTRICT_KEYRING followed by add_key(). Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:key_or_keyring_common (crypto/asymmetric_keys/restrict.c:205 crypto/asymmetric_keys/restrict.c:279) Call Trace: __key_create_or_update (security/keys/key.c:884) key_create_or_update (security/keys/key.c:1021) __do_sys_add_key (security/keys/keyctl.c:134) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exception Reject an asymmetric restriction key without key IDs. A PKCS#8 private key cannot identify the signer of a candidate certificate and is not a valid trust anchor. Fixes: 3c58b2362ba8 ("KEYS: Implement PKCS#8 RSA Private Key parser [ver #2]") Cc: stable@vger.kernel.org Reported-by: Xiang Mei Link: https://lore.kernel.org/r/20260429181629.110802-2-bestswngs@gmail.com Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e55d48f21f591a9fe80d26b5fbd1912ea725d9e6 Author: Srish Srinivasan Date: Sat Sep 12 11:59:49 2026 +0530 keys/trusted_keys: return immediately after TPM unseal failure commit f92d0ccb05bf9089072cb067dda0dffd5394c4ef upstream. trusted_tpm_unseal() proceeds to pcrlock() when the TPM unseal operation fails. If pcrlock() succeeds, its return value overwrites the unseal error, causing key instantiation to succeed. Return immediately when unseal fails to preserve the original error. Cc: stable@vger.kernel.org # v5.15+ Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Signed-off-by: Srish Srinivasan Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260912062950.279104-2-ssrish@linux.ibm.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 0dac848d4e81454643e363db4f48472a04a13c52 Author: Stefano Garzarella Date: Wed Sep 23 19:35:06 2026 +0200 KEYS: trusted: Fix blob allocation size in tpm2_key_decode() commit 11077cbcc2695f71c944a84a5f08c6672ab759f1 upstream. tpm2_key_decode() allocates 4 bytes more than needed. The ASN.1 callbacks tpm2_key_priv() and tpm2_key_pub() provide the lengths of TPM2B_PRIVATE and TPM2B_PUBLIC, so ctx.priv_len and ctx.pub_len already account for the 2-byte `size` field each of those structures starts with. I noticed this while reviewing commit 114f00d738f1 ("KEYS: trusted: Fix tpm2_load_cmd() boundary check"), which correctly reports ctx.priv_len + ctx.pub_len as the decoded blob size [1]. Let's allocate exactly that amount, matching the data copied into the blob. [1] https://lore.kernel.org/linux-integrity/apfoKo-BdwaLXtkT@sgarzare-redhat/ Cc: stable@vger.kernel.org # v5.13+ Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Signed-off-by: Stefano Garzarella Link: https://lore.kernel.org/r/20260923173506.41519-1-sgarzare@redhat.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 01835d3a3709be508ae5209f806640336c48e395 Author: Adrian Martinez Date: Sat Oct 10 23:40:00 2026 +0300 KEYS: Fix key_reject_and_link() race with keyring restriction commit 0b157166e612b70f98a332b6c7be7eac6f8e9593 upstream. The restrict_link check in key_reject_and_link() is done before taking the keyring semaphore, racing with a concurrent keyring_restrict() that installs the restriction while holding the semaphore in write mode. Move the check to after __key_link_lock(), so it is done under the semaphore, matching the pattern used in __key_create_or_update(). Cc: stable@vger.kernel.org Fixes: 5ac7eace2d00 ("KEYS: Add a facility to restrict new links into a keyring") Reviewed-by: Jarkko Sakkinen Signed-off-by: Adrian Martinez Link: https://lore.kernel.org/r/CACO1+RT+m==BY+ZPkE+fo536D0qu3wog4xE1dfuXQ56g+=Qv=A@mail.gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 3edc064069d07e7d37359fcb4d03d3bab15ee3ab Author: Cen Zhang Date: Mon Oct 19 22:57:21 2026 +0800 keys: Protect the read method check against type removal commit 925c84e3cc21caf09de92d9bcafab0147790debf upstream. keyctl_read_key() checks key->type->read without holding key->sem. A reference keeps the key alive, but does not pin the module containing its type. A surviving RxRPC key can therefore be read while AF_RXRPC is being unloaded: KEYCTL_READ task Module unload and key GC ---------------- ------------------------ lookup_user_key() permission / possession checks load key->type af_rxrpc_exit() unregister_key_type() GC: down_write(key->sem) GC: retype to key_type_dead GC: up_write(key->sem) unregister_key_type() returns free_module() read saved type's read member The final access can read freed module storage. The read invocation in __keyctl_read_key() is already protected by key->sem, but the earlier method check is outside that critical section. Move the method check into __keyctl_read_key(), after key_validate() and under its existing read hold on key->sem. The check and invocation then use the same protected type for length queries and every read retry. The GC cannot retype the key until the semaphore is released, and type unregistration waits for that GC pass before the module can be freed. Return -EOPNOTSUPP when validation succeeds and the type has no read method. A temporary buffer may now be allocated before this result; allocation and copying to userspace remain outside the semaphore. Assisted-by: LLM Cc: stable@vger.kernel.org # v5.10+ Fixes: d3ec10aa9581 ("KEYS: Don't write out to userspace while holding key semaphore") Suggested-by: Jarkko Sakkinen Signed-off-by: Cen Zhang Reviewed-by: Jarkko Sakkinen Reviewed-by: David Howells Link: https://lore.kernel.org/r/pm-key-management-objects-candidate-0010-v7-fc85721ff5cfb9e33ac6@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 61ac0585d9f4344d3dfb84b5edff1fee7d532897 Author: Kyle Zeng Date: Tue Oct 13 16:12:51 2026 -0700 keys: make keyring indexes independent of kernel addresses commit de891c73c1cf41ac8de12c07fa2c84d6a912ad0c upstream. KEYCTL_READ returns the serial numbers in a keyring in associative-array traversal order. The first word of the index is a public, deterministic hash of the type pointer, domain pointer and description. An unprivileged user can therefore insert keys with known descriptions, predict their order for each possible KASLR slide, and recover the kernel image address. On an x86-64 build with 16 MiB alignment, 45 user keys suffice to distinguish the candidate slides. Remove the addresses from the whole index, not just its first hash word. Assign each key type and domain a nonzero 64-bit ID and hash those IDs and the description with a once-initialized SipHash key. Use the full IDs in the later index chunks as well. Truncating or hashing the IDs there would lose the guarantee that distinct type/domain/description tuples have a differing index bit. Allocate IDs lazily since private key types need not be registered. Cache them in the index key so tree walks and copies of an existing index do not need to dereference a type descriptor that may have been unregistered. Keep the 32-bit chunk layout and diff_objects() bit offsets consistent, and retain the separate root slot for keyrings used by recursive search. The key comparison, permissions and userspace data format are unchanged; only the address-dependent in-memory ordering is replaced. Cc: stable@vger.kernel.org Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring") Assisted-by: Codex:gpt-6-astra Signed-off-by: Kyle Zeng Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20261013231251.56170-1-kylebot@openai.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 6b613747f7ea309ada5b8d05b55398c338f7a968 Author: Cen Zhang Date: Fri Oct 9 13:11:03 2026 +0800 keys: Protect the type name while describing a key commit fced7238b7e80cf8aa688d5af976e4aa6e33c329 upstream. keyctl_describe_key() must keep the key type's name alive until kasprintf() has consumed it. The retained key reference keeps the key and its description alive, but does not pin the module providing its type. The name is passed to kasprintf() without holding key->sem. kvasprintf() uses the saved name pointer in two formatting passes, with a GFP_KERNEL allocation between them. With AF_RXRPC=m, a task that passes View permission before type retirement can overlap a privileged module unload in this order: 1. KEYCTL_DESCRIBE looks up the key, saves key->type->name in the kasprintf() arguments and completes the first formatting pass. 2. While the formatter is delayed before its second pass, af_rxrpc_exit() calls unregister_key_type(), which removes the type from the registry and waits for key_gc_keytype(). 3. The collector takes key->sem for writing, retypes the retained key to key_type_dead and completes retirement. Unregistration and module exit return, allowing free_module() to release the type and name. 4. The formatter resumes its second pass and reads the saved name from released module storage, which can fault in string(). Hold key->sem for reading across kasprintf(). The collector then cannot retype the key or complete retirement until both formatting passes have finished. If retirement wins the lock first, formatting uses the core key_type_dead name instead. Release the semaphore immediately after kasprintf(), including on allocation failure, before copying to userspace. Oops report as below: BUG: unable to handle page fault for address: fffffbfff8054794 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page RIP: 0010:string+0x23f/0x470 Call Trace: vsnprintf+0x330/0x1110 Cc: stable@vger.kernel.org Fixes: aa9d4437893f ("KEYS: Fix the size of the key description passed to/from userspace") Assisted-by: LLM Signed-off-by: Cen Zhang Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/pm-key-management-objects-candidate-0009-v4-6b537c5732fd957c33fa@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit b86db7993051d05810601654e886a1e78e1fa495 Author: Cen Zhang Date: Fri Oct 9 13:52:16 2026 +0800 keys: Check the authorization payload in process keyring searches commit 0a0ec45bf577a9b4d4960567f20d3877ef480de9 upstream. An authorization payload and its saved credentials must remain valid while search_process_keyrings_rcu() searches the requestor's keyrings. The function validates the authorization key, then separately loads payload.data[0] and unconditionally reads rka->cred. Validation does not prevent request_key_auth_revoke() from clearing the payload. A request-key helper can assume authority and fork a descendant that inherits the authorization key. If the descendant misses in its own keyrings, it falls back to the saved requestor credentials. Successful target instantiation invalidates the authorization key without clearing the payload. After the helper exits, UMH_WAIT_PROC returns to the requester, which calls complete_request_key() and revokes that key. With the descendant paused after validation, the paths can interleave as follows: 1. The descendant enters search_process_keyrings_rcu() under RCU and key_validate() succeeds. 2. The helper instantiates the target, invalidates the authorization key, and exits. 3. The requester resumes from UMH_WAIT_PROC, calls complete_request_key(), and revokes the authorization key. request_key_auth_revoke() sets its payload pointer to NULL. 4. The descendant loads NULL and dereferences rka->cred. This NULL dereference can oops the kernel. RCU delays payload disposal but does not prevent the pointer from being cleared. Load the payload with dereference_key_rcu() and require a non-NULL result before validating the authorization key and searching its saved credentials. A non-NULL payload and its credentials remain alive for the caller's RCU read-side section; a cleared payload skips the fallback search and follows the existing error selection. KASAN report as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:search_process_keyrings_rcu+0x32b/0x790 Cc: stable@vger.kernel.org Fixes: e59428f721ee ("keys: Move the RCU locks outwards from the keyring search functions") Assisted-by: LLM Signed-off-by: Cen Zhang Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/pm-key-management-objects-candidate-0004-v3-598361863b76bc25d58d@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit b0830a26e2c3008a6e21863126b4a0e68b2761cd Author: Cen Zhang Date: Fri Oct 9 13:11:59 2026 +0800 keys: Avoid the owner account dereference in named keyring lookup commit 51409aaa01f8602552c336009fd22b226b0cdf1d upstream. Named keyring lookup must keep the storage containing the owner UID alive through the namespace mapping check. find_keyring_by_name() reads keyring->user->uid under keyring_name_lock, but that lock protects the keyring's name entry and allocation, not its separate key_user. A named session-keyring join can overlap a privileged KEYCTL_CHOWN on another CPU. If the keyring holds the last reference to its old dynamic key_user and the ownership transfer succeeds, the following ordering is possible: Named join Chown find_keyring_by_name() keyctl_chown_key() read_lock(keyring_name_lock) down_write(key->sem) load old keyring->user replace key->user and key->uid up_write(key->sem) key_put(key) key_user_put(old user): free read old user->uid read_unlock(keyring_name_lock) Chown neither takes keyring_name_lock nor key_session_mutex, so it can free the old account between the pointer load and the UID read. The lookup then reads freed memory even though the keyring itself is alive. Use keyring->uid for the mapping check. key_alloc() initializes this inline owner UID and keyctl_chown_key() updates it on chown. The existing name lock keeps its containing keyring allocated throughout the check, so lookup no longer depends on the account's lifetime. This also matches the owner UID used by the permission check. KASAN report as below: BUG: KASAN: slab-use-after-free in find_keyring_by_name+0x577/0x5d0 Read of size 4 at addr ffff8881128ae2ec by task keycase/500 Cc: stable@vger.kernel.org Fixes: 2ea190d0a006 ("keys: skip keys from another user namespace") Assisted-by: LLM Signed-off-by: Cen Zhang Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/pm-key-management-objects-candidate-0002-v3-2baa8cad2bb554364e10@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit d3a32432e6be86437686d3de9b32400b62a308c1 Author: Jens Axboe Date: Tue Oct 27 12:02:04 2026 -0600 io_uring: keep the drain active when a deferred drain request is started Commit 2295613cd3713beffc8665e956135a5d48dfc208 upstream. ecb6817b769f ends the drain when the dispatched drain request has posted its CQE and nothing else is deferred. But the deferred list is processed in between, and if the request it starts is itself a drain request, the drain is over before that one has even run. A request submitted after that point then runs ahead of it: 1. P0 in flight, D1 and D2 (both IOSQE_IO_DRAIN) deferred behind it 2. P0 completes, D1 is started 3. D1 completes, drain_done is set, D2 is started, the list is empty 4. IO_RING_F_DRAIN_ACTIVE is cleared with D2 still in flight Anything submitted now bypasses the drain. The same happens with D2 as the head of a link, as those aren't tracked in ->drain_req at all. Have io_queue_deferred() report whether it started a drain request, and don't end the drain if it did. Starting non-drain requests and ending it is still fine, they were only waiting on the drain request that just completed. [ 6.18: ->drain_active is a bool here ] Fixes: ecb6817b769f ("io_uring: end the drain when the drain request completes") Reported-by: Karl Mehltretter Link: https://lore.kernel.org/io-uring/20261027043323.98916-1-kmehltretter@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 708031a0f3d81029fe1744908fb246513eb218b0 Author: Jens Axboe Date: Mon Oct 19 13:30:51 2026 -0600 io_uring: end the drain when the drain request completes Commit ecb6817b769fd7d71af2c9f446188649020b2e53 upstream. Since requests are drained based on allocated requests, the drain stays active after the drain request has posted its CQE, until it is freed and a new request finds the defer list empty. A drain request run by io-wq is freed only after the worker drops its reference, so a request submitted after the drain completed can still be deferred behind it, and get issued much later than the application expects. A drain request dispatched from the defer list runs alone. Track it, and end the drain when its CQE is flushed and nothing else is deferred. Have io-wq complete drain requests through task_work, so that this happens under ->uring_lock before the CQE is visible. Linked drain requests keep waiting until the link is freed. Reported-by: Wei Gao Link: https://lore.kernel.org/io-uring/20261018070154.16944-1-wegao@suse.com/ [ 6.18: ->drain_active and ->lockless_cq are bools here ] Fixes: 8fb7aee05591 ("io_uring: drain based on allocates reqs") Cc: stable@vger.kernel.org Tested-by: Wei Gao Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5bfeee1774791602a0d53eb717f00f172127a017 Author: Junyeong Lee Date: Tue Oct 20 00:21:00 2026 +0900 io_uring/waitid: prevent cancel reference wrap Commit 98787d3fa4e99564d2b2bc21255b21f670c450d0 upstream. io_waitid packs the cancellation state into bit 31 of ->refs and uses bits 30:0 as a 31-bit reference counter: #define IO_WAITID_CANCEL_FLAG BIT(31) #define IO_WAITID_REF_MASK GENMASK(30, 0) __io_waitid_cancel() marks a request canceled, then increments the low bits of ->refs to claim completion ownership. When another path owns the request, the increment remains even though cancellation returns false. The request remains discoverable by cancellation, so repeated failed attempts can wrap the 31-bit reference field to zero. A later cancellation can claim ownership and complete the request a second time. Use atomic_fetch_or() when setting the cancel flag and inspect the old flag value. The first cancel attempt continues to the existing ownership increment, preserving its wake and issuer handoff semantics. Later attempts see the cancel flag and return without incrementing the reference field. This makes repeated failed cancellation attempts idempotent while leaving the first-cancel state transitions unchanged. Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Junyeong Lee Link: https://patch.msgid.link/20261019152100.63565-1-jylee5498@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 29257ada73c41bf60399b76ad7dc6bc95a6163e7 Author: Austin Schuh Date: Sat Oct 17 10:17:26 2026 -0700 io_uring/wait: wake real-time waiters from hard interrupt context Commit 5b01d5955ac206e38097f777eff6ab2a8b948c41 upstream. Since commit cebf123c634a ("io_uring: implement our own schedule timeout handling"), a CQ wait with a timeout sleeps on io_uring's own hrtimer instead of an hrtimer sleeper. On PREEMPT_RT, an hrtimer that isn't marked for hard interrupt expiry expires in the per-CPU ktimers thread, which runs at SCHED_FIFO 1. A real-time task waiting in io_uring_enter() is therefore not woken at its deadline while any other real-time task is runnable on its CPU: the wakeup waits until every one of them has blocked. hrtimer sleepers, which schedule_hrtimeout_range_clock() used to give io_uring, don't have this problem: __hrtimer_setup_sleeper() marks the timer hard when the sleeping task is in a real-time or deadline class. Both of io_uring's callbacks are fine in hard interrupt context: io_cqring_timer_wakeup() sets a flag and calls wake_up_process(), and io_cqring_min_timer_wakeup() only reads ring state, under RCU, before doing the same or re-arming the timer. Apply the sleeper rule to them. Measured on a Jetson Orin Nano running 6.18.39-rt with this change backported: a SCHED_FIFO 40 task waits in io_uring_enter() for 40,000 deadlines 500us apart, while a SCHED_FIFO 20 task runs bursts of up to 1ms on the same CPU. Before, 6,647 wakeups were more than 100us late, the latest by 1,040us, and 2,758 deadlines passed without a wakeup at all. After, none were more than 100us late and the latest was 18us. This mirrors epoll: epoll_pwait2() waits on an hrtimer sleeper, so its timeout is already hard for real-time tasks, and on the same setup it was never more than 17us late. [ 6.18: the wait code is still in io_uring.c ] Fixes: cebf123c634a ("io_uring: implement our own schedule timeout handling") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Austin Schuh Link: https://patch.msgid.link/20261017171726.601443-1-austin.linux@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 68c3969f8682e7d4d4555620790c0e1a0a36fc85 Author: Tamaki Yanagawa Date: Sun Oct 18 04:22:32 2026 +0000 io_uring/net: keep recv buffer select length within MAX_RW_COUNT Commit 96262cfab554cf11412de7a6247f0e82c94e130f upstream. Since commit dcbd1c054848 ("io_uring/net: let io_recv_buf_select return the length of the buffer region"), io_recv_buf_select() returns the selected length as an int. For a non-bundle recv with sqe->len == 0 the length comes from the ring provided buffer, which can be up to 4G, so a buffer of 2G or more makes io_recv() fail the request with a bogus negative result (e.g. -2147483648) instead of receiving into it. Clamp the length to MAX_RW_COUNT, which import_ubuf() limits the transfer to anyway. Fixes: dcbd1c054848 ("io_uring/net: let io_recv_buf_select return the length of the buffer region") Cc: stable@vger.kernel.org Signed-off-by: Tamaki Yanagawa Assisted-by: Claude:claude-opus-5-5 Link: https://patch.msgid.link/20261018042227.1105-1-ty@000ty.net Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9249f350e9b292871913f14a6ffcad8f35cd3529 Author: Jens Axboe Date: Fri Oct 16 09:15:13 2026 -0600 io_uring/poll: don't loop on HUP with multiple references Commit 67bb1ad9a517bedf1e1599fe5448620b9f38bf2a upstream. io_poll_check_events() drops down to one reference when a multishot request sees HUP with more than one, so that the loop goes around once more. It did so by subtracting one less than it had. With the cmpxchg that only takes the local count down: the exchange fails, the next pass reads the unchanged count, and goes through the same motions again. The loop then only ends once io_poll_issue() stops the request. Drop the extra references from the counter instead, and loop once more without trying the exchange. The next pass sees one reference, like it did before, and ends unless a wake up came in. Fixes: 937d38dcacd6 ("io_uring/poll: avoid retry wakeup loss when dropping ownership") Signed-off-by: Jens Axboe Co-Authored-By: Claude Fable 5.1 Signed-off-by: Greg Kroah-Hartman commit f10ab47077e63d6eee35b242c257c3947bb49e64 Author: Jens Axboe Date: Thu Oct 15 16:38:45 2026 -0600 io_uring/timeout: don't lose a cancel as io-wq arms a timeout Commit 89f193dc3ef462059387e9691bf6af4b1808379a upstream. An IORING_OP_TIMEOUT run by io-wq, because of IOSQE_ASYNC, has the same problem as poll, futex and waitid. io_wq_submit_work() looks at IO_WQ_WORK_CANCEL once, before it issues the request. A cancel in between flags the work, gets -EALREADY, and searches ->timeout_list in vain, while the worker then adds the request and starts the timer: io-wq worker io_try_cancel() io_wq_submit_work() IO_WQ_WORK_CANCEL isn't set io_async_cancel_one() sets IO_WQ_WORK_CANCEL = -EALREADY io_timeout_cancel() = -ENOENT io_timeout() adds the request to ->timeout_list hrtimer_start() = IOU_ISSUE_SKIP_COMPLETE Nobody looks at the flag again, and the timeout runs its course. At ring exit, io_uring_try_cancel_requests() cancels io-wq work and then kills the timeouts the same way, so an exiting task can get stuck for the full duration of such a timeout. Look at the flag under ->timeout_lock, which the search takes as well, and fail the request if it is set. If the search came first, the flag is visible. If it comes later, it finds the request on the list. Fixes: ce35a47a3a02 ("io_uring: add IOSQE_ASYNC") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 045dfbbbc7236bc820ec70f495c5e5959223f932 Author: Jens Axboe Date: Thu Oct 15 14:25:00 2026 -0600 io_uring/timeout: don't flush with the sequence behind the last flush Commit 85f85d573ffa7772e1ad4504d0cec5113a5c5cf1 upstream. io_flush_timeouts() measures the events since the last flush as the distance of the current sequence from ->cq_last_tm_flush. A fired timeout bumps ->cq_timeouts before its CQE is posted, so until it is the sequence can be behind the last flush, and the distance wraps: last flush: seq 100, cq_last_tm_flush = 100 Y: IORING_OP_TIMEOUT, off 50, target_seq 150 pure timeout A fires, cq_timeouts = 1 task_work posts A's CQE, cached_cq_tail = 101 pure timeout B fires before the flush, cq_timeouts = 2 io_flush_timeouts(): seq = 99, events_got = 0xffffffff Y, and every sequence timeout behind it, is ended with -ETIME although no event happened. Two timeouts expiring close together is all it takes, a completion with IOSQE_CQE_SKIP_SUCCESS after a single one does it too. Nothing but those in flight CQEs separates the two, so count from the last flush when the sequence is behind it, as io_timeout() does. Fixes: f010505b78a4 ("io_uring: flush timeouts that should already have expired") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c7bb2c49581e89bcda53405d37a4bf7123f23769 Author: Jens Axboe Date: Thu Oct 15 14:18:22 2026 -0600 io_uring/timeout: don't put a sequence target behind the last flush Commit fdfce905a58edea053ee7b68b5bd4348dd1b36e0 upstream. io_timeout_fn() and io_kill_timeout() bump ->cq_timeouts when a timeout fires, but its CQE is only posted later from task_work. Until then the sequence io_timeout() computes is one below the last flush per fired timeout. Now that ->cq_last_tm_flush is kept while sequence timeouts are pending, a timeout armed in that window with a small offset gets a target behind the base. Its distance from the base wraps, and it's never completed by events, only by its timer. With DEFER_TASKRUN that window is as wide as the application makes it, as submission runs before the local task_work. Nothing but those in flight CQEs separates the two, so use the last flush as the base for the target when the sequence is behind it. Fixes: c6c0b3eba88c ("io_uring/timeout: don't skip over reached sequences") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit afa407c02f3aa0fd872f86c9bf1b34502e0fa8f0 Author: Juanlu Herrero Date: Tue Oct 13 15:37:20 2026 -0700 io_uring/poll: avoid retry wakeup loss when dropping ownership Commit 937d38dcacd675dc0572d6c9b6743960df3128ed upstream. If a wakeup sets IO_POLL_RETRY_FLAG between the owning task consuming the existing instance of IO_POLL_RETRY_FLAG and the loop check of io_poll_check_events(), then we stall on processing the request until an unrelated wakeup comes along. Using atomic_cmpxchg instead of atomic_sub_return to guarantee both the count v and poll_refs are 0 and no wake-ups are missed. Cc: stable@vger.kernel.org Fixes: a26a35e9019f ("io_uring: make poll refs more robust") Signed-off-by: Juanlu Herrero Assisted-by: LLM Suggested-by: Anand Natarajan Link: https://patch.msgid.link/20261013-pu-cmpxchg-v1-1-4ddc10fd8a03@fastmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8e3ac8ada6b500e5ac1da1fa40409da2b4b36c88 Author: Josef Bacik Date: Thu Oct 15 19:31:07 2026 +0000 io_uring: look up the file before queueing to io-wq Commit 98bc044d5a5374f8d3605fe55a8e2df6d6fc3f82 upstream. io_prep_async_work() decides by the file of a request what kind of work it is for io-wq. I/O on regular files and block devices is bounded work, limited to min(SQ entries, 4 * CPUs) workers, for anything else that may block indefinitely the limit is RLIMIT_NPROC. Writes to a regular file are hashed by the inode, so that they are run one after the other instead of having a bunch of workers fight for the inode lock. Since the file is only assigned when a request is issued, a request that is queued without an attempt to issue it, REQ_F_FORCE_ASYNC, doesn't have one at that point. io_prep_async_work() takes that for "not a regular file or block device": - Reads and writes end up as unbound work. 32 reads with IOSQE_ASYNC from a slow block device on a ring with 4 SQ entries get 32 workers, not 4. - Writes aren't hashed. Four buffered writes to one file get four workers, three of which do nothing but wait for the lock. The late assignment is for the benefit of links, where a request may use a fixed file that one of its predecessors installs. By the time a request gets to io_queue_iowq() these are done, it is as good as issued. Assign the file there. io_assign_file() moves up and is forced inline. With a third caller the compiler may stop inlining it, and every request that is issued would pay for a call. IORING_OP_SPLICE is left as it is, unbound and not hashed. The file of the request is where it writes to, which says nothing about how long it takes: a splice from an empty pipe or a socket into a regular file waits for its input. As bounded work, four of these on a ring with 4 SQ entries keep all other bounded work of the task from running, and as hashed work one of them blocks all writes to that file. REQ_F_FORCE_ASYNC is not only set for IOSQE_ASYNC. What changes, and brings back what was the case before the file assignment was deferred: - Requests with IOSQE_ASYNC or IOSQE_IO_DRAIN, and all requests that are submitted while a drain is active: reads and writes on regular files and block devices count against the limit for bounded workers, including the one set with IORING_REGISTER_IOWQ_MAX_WORKERS, so fewer of them run at the same time. - Of these, writes to one regular file are run one at a time, unless they are O_DIRECT and the filesystem has FOP_DIO_PARALLEL_WRITE. - IORING_OP_FALLOCATE and IORING_OP_FTRUNCATE, which always go to io-wq, are run one at a time per file, and in turn with these writes. - The descriptor or the fixed file slot is looked up when the request is queued, not when a worker gets around to it, so closing or replacing it in between no longer has an effect on the request. Fixes: 6bf9c47a3989 ("io_uring: defer file assignment") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-43-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 379b1382befbaab00a3f5c02d465048d75070629 Author: Josef Bacik Date: Thu Oct 15 19:31:06 2026 +0000 io_uring/timeout: don't end a linked timeout with 1 Commit c74193430febdd120e35936dda3e5aeec3a54405 upstream. A linked timeout that fires cancels the request it is linked to, and completes with -ETIME if that worked out: ret = io_try_cancel(req->tctx, &cd, 0); ... io_req_set_res(req, ret ?: -ETIME, 0); io_try_cancel() returns 0 or an error, except for requests that are parked on ->futex_list or ->waitid_list. io_futex_cancel() and io_waitid_cancel() return the number of requests that they have cancelled, and io_try_cancel() hands it on. So the linked timeout of an IORING_OP_FUTEX_WAIT, IORING_OP_FUTEX_WAITV or IORING_OP_WAITID that it has cancelled completes with 1, each time. The waitid test of liburing checks for that 1, and has to be changed to expect -ETIME, which is what the linked timeout of any other request completes with. Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Fixes: 194bb58c6090 ("io_uring: add support for futex wake and wait") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-42-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d25c2deb5dd4cfccd40249d08571350f4b0a0777 Author: Josef Bacik Date: Thu Oct 15 19:31:05 2026 +0000 io_uring/timeout: no ABS update of multishot timeouts Commit b088ae34d4da730dc647261b893a6eb622fe5e1f upstream. IORING_TIMEOUT_MULTISHOT can't be combined with IORING_TIMEOUT_ABS, prep rejects that, as the request is armed again with the same value each time it fires. IORING_TIMEOUT_UPDATE doesn't check and takes an absolute time for a multishot timeout. The first expiry is as asked for, but io_timeout_complete() then arms the timer with ->mode of the original request, i.e. it uses the absolute time as the interval. With CLOCK_MONOTONIC the next expiry is an uptime away, with CLOCK_REALTIME more than fifty years. Fail such an update with -EINVAL, and do so before the timeout is touched. Fixes: ea97f6c8558e ("io_uring: add support for multishot timeouts") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-41-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit fc8506eea4498ecba26ef8bf6dbbd74af3dc891d Author: Josef Bacik Date: Thu Oct 15 19:31:04 2026 +0000 io_uring/net: don't retry recv on uncommitted buffers Commit 8444de681a179e41a4eb92d5bbe770a0677074a6 upstream. Commit 41b70df5b38b ("io_uring/net: commit partial buffers on retry") commits ring provided buffers when a receive is going to be retried after a partial transfer, so that another request using the same buffer group can't be handed the memory the first one keeps receiving into. It commits the number of bytes received so far. That does the job for a single buffer which is consumed as a whole, but the request hangs on to all it has mapped: - For a buffer ring with IOU_PBUF_RING_INC only these bytes are consumed. The rest of the buffer stays at the head of the ring. - For a bundle only the buffers which hold these bytes are consumed, the others that were peeked stay in the ring. In both cases the next receive with that buffer group gets memory that the retried request is still going to write to, and whoever comes last overwrites the data of the other. What the retry fills isn't committed at all, as the buffer list isn't known any more at that point. So the kernel hands it out again later on, while the CQE tells the application that it was used, and for an incremental buffer that it is done with. The remainder can't be committed in advance: if the request ends up receiving less, there is no way to tell the application that more was consumed than the CQE accounts for. Complete the request with what it has got instead of retrying it. MSG_WAITALL is no longer honoured for receives into incremental buffers or multi buffer bundles, they can return a short count, with the request marked as failed like for other short MSG_WAITALL transfers. Fixes: 41b70df5b38b ("io_uring/net: commit partial buffers on retry") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-40-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e9b540d004ca6d9102a12fba867a0c3a14c8c48a Author: Josef Bacik Date: Thu Oct 15 19:31:03 2026 +0000 io_uring: don't pass restart error codes to userspace Commit e1a64bc64897f4c2fe460922c345f2ed8f889b5f upstream. -ERESTARTSYS and friends are instructions for the system call exit code, which either restarts the call or turns them into -EINTR. They are not supposed to be seen by applications. A request isn't a system call, nobody looks at what it returns before that is put into a CQE. The read/write and the networking opcodes convert these codes to -EINTR by hand. The others don't. An io-wq worker that is blocked in the open of a FIFO, a tty or some other device, or in a splice from an empty pipe, and that gets interrupted because the request is cancelled, completes it with -512: IORING_OP_OPENAT, IOSQE_ASYNC // FIFO without a writer IORING_OP_ASYNC_CANCEL // -EALREADY, worker is signalled CQE of the open: res == -512 There are more candidates, like whatever a file system or driver returns from ->flush(), ->fsync(), ->fallocate() or ->uring_cmd(), or breaking a lease or delegation. Take care of it in io_issue_sqe(), which all of them go through. The helper is moved from rw.c as is. The cost is a compare and a branch that is not taken per request. Fixes: 15b71abe7b52 ("io_uring: add support for IORING_OP_OPENAT") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-39-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b4b7b2d19dab611f3cf3d052aa19278e7e4c4683 Author: Josef Bacik Date: Thu Oct 15 19:31:02 2026 +0000 io_uring/openclose: keep the lock in io_pipe_fixed() Commit a3d7ee11289f657aa9af826d8f0844221292a27a upstream. io_pipe_fixed() installs both ends of the pipe in the fixed file table, drops ->uring_lock, and copies the slot numbers to the application. If that faults, it takes the lock again and removes whatever is in these slots. If the request is run by io-wq the lock really is dropped in between, and the slots are visible to everybody else. By the time the error path gets to them, they may have been closed and reused, by IORING_OP_CLOSE and a direct open or accept, or by IORING_REGISTER_FILES_UPDATE. Then a file is removed from the table that has nothing to do with the failed request. Do the copy with the lock held. Faulting in user memory under ->uring_lock is fine, the registration paths do it all the time. Fixes: 53db8a71ecb4 ("io_uring: add support for IORING_OP_PIPE") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-38-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 64fca102086d5615cc5488c794942f1540b886c8 Author: Josef Bacik Date: Thu Oct 15 19:31:01 2026 +0000 io_uring/sqpoll: let the thread sleep on disabled rings Commit d492dcbb3b81c1c2d0aabef41fa1307093f3a556 upstream. __io_sq_thread() doesn't submit anything as long as the ring has IORING_SETUP_R_DISABLED set. The check that keeps the SQPOLL thread from going to sleep while the SQ ring holds entries doesn't know about that. If an application fills in SQEs first and enables the ring later, the thread finds that there is work each time it is about to sleep, goes around, doesn't submit it, and so on. It uses up a CPU until the ring gets enabled. Entries in the SQ ring of a disabled ring are no reason to stay awake. io_register_enable_rings() clears the flag and then wakes the thread, and the flag is looked at after prepare_to_wait(), so the thread can't miss that. Fixes: 0298ef969a11 ("io_uring: clean R_DISABLED startup mess") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-37-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 857de5de2f576d98246be72f6e1a7636fd9c9006 Author: Josef Bacik Date: Thu Oct 15 19:31:00 2026 +0000 io_uring/kbuf: handle index wrap in last buffer check Commit 6e773b5161506a4d0e739eb3aa4667d28f20219c upstream. io_ring_buffer_select() flags the request with REQ_F_BL_EMPTY if it takes the last buffer of the ring. Head and tail are 16-bit counters, but "head + 1" is computed as an int. If head is 65535 and tail has wrapped to 0, that compares 65536 to 0 and the flag isn't set. A bundle receive relies on the flag to tell that there is no point in trying to get more data. Without it, it goes for another round, finds no buffer, and the request, which has received data, is marked as failed on account of the -ENOBUFS. That severs a link, and ends a multishot. Fixes: c3f9109dbc9e ("io_uring/kbuf: flag request if buffer pool is empty after buffer pick") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-36-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9bfb315e2d0907fbcaf5d0453dd6d873c9aa8d5b Author: Josef Bacik Date: Thu Oct 15 19:30:59 2026 +0000 io_uring/zcrx: fix buffer offsets in areas above 4GB Commit ab4536bf2e5617b04f2d9396f06393c7bbfb071d upstream. io_zcrx_queue_cqe() computes the offset of the buffer in its area from net_iov_idx(), which is an unsigned int, so the shift is done in 32 bits and only the result is widened to the u64 that goes into the CQE. An area can be up to 1TB in size. For every niov beyond the first 4GB the CQE points the application at a buffer 4GB, or a multiple of that, below the one which has the data. It reads the wrong data, and then returns a buffer it doesn't own via the refill queue while the real one is never given back. Fixes: 11ed914bbf94 ("io_uring/zcrx: add io_recvzc request") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-35-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1731af12abdd910e01bd46a2fba8e3c878c4599c Author: Josef Bacik Date: Thu Oct 15 19:30:58 2026 +0000 io_uring/napi: don't busy poll past an expired timeout Commit 21ed976c12f6b77d7ea028a4fe9a08e69a56179f upstream. __io_napi_busy_loop() caps the busy poll time to what is left until the timeout of the wait. The difference is negative if the timeout has passed already, which is what an application gets if it uses IORING_ENTER_ABS_TIMER with a time that isn't in the future any more. The min_t(u64, ...) turns that into a huge value, so the cap has no effect and the wait, which should return right away, spins for the full busy poll time first. Fixes: d5cce407e4f5 ("io_uring/napi: postpone napi timeout adjustment") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-34-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 18c373f446068972788158c8c7de6e849b04ed98 Author: Josef Bacik Date: Thu Oct 15 19:30:57 2026 +0000 io_uring/napi: make stale entries time out after 60s Commit 9c151648780d89e5446e5f89f3fa2e416c3bb911 upstream. With dynamic tracking a NAPI id that hasn't been seen for a minute is meant to be dropped from the list the ring busy polls. The timeout is added to jiffies, but it is defined as 60 * SEC_CONVERSION, and SEC_CONVERSION isn't the number of jiffies in a second. It is the internal factor of __timespec64_to_jiffies(), HZ scaled up by SEC_JIFFIE_SC bits. For HZ=1000 that is 1000 << 22, which puts the timeout at about eight years. On 32-bit the multiplication overflows. So entries are never removed, and every id that a socket of the ring ever had keeps being polled on each wait. Fixes: 8d0c12a80cde ("io-uring: add napi busy poll support") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-33-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d978f1fafc53d4399a49f5ba22e72578dffeabcd Author: Josef Bacik Date: Thu Oct 15 19:30:56 2026 +0000 io_uring/wait: no early -ETIME if min_wait finds work Commit 83cce67298ab1f4d2e9205a49f56975475cdb154 upstream. When the min wait time is over and there is work to run, which for DEFER_TASKRUN includes task_work that was queued lazily and didn't wake the waiter, io_cqring_min_timer_wakeup() ends the wait via io_cqring_timer_wakeup(). That flags it as timed out. io_cqring_wait() runs the work, leaves the loop, and returns 0 if the CQ ring holds something. Running task_work doesn't have to result in a CQE, though. A poll wake up can turn out to be spurious, for instance if somebody else has read the data by the time the request is retried. The application then gets -ETIME once the min wait time has passed, no matter how far away the timeout it asked for is. Wake the task without declaring a timeout. From now on a single CQE satisfies the wait, like in the case where the timer is switched over to the normal timeout. If running the work doesn't post one, the loop in io_cqring_wait() goes back to sleep with the normal timeout. [ 6.18: io_cqring_min_timer_wakeup() lives in io_uring.c, there is no wait.c yet ] Fixes: 1100c4a2656d ("io_uring: add support for batch wait timeout") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-32-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Co-Authored-By: Claude Fable 5.1 Signed-off-by: Greg Kroah-Hartman commit 515e06072da30530887dc94b598a16b67415346c Author: Josef Bacik Date: Thu Oct 15 19:30:54 2026 +0000 io_uring/timeout: keep repeat count on multishot update Commit 3dc2a32cd356ee382aa4a8c7d844c53b2c0ad83b upstream. IORING_TIMEOUT_UPDATE clears ->off of the timeout it updates, to turn a timeout that waits for a number of completions into a pure one. For a multishot timeout ->off isn't a sequence though, it tells whether the number of repeats is limited: io_timeout_finish() only looks at ->repeats if ->off is set. A multishot timeout that was set up to fire N times hence fires forever once its interval has been updated. Leave ->off alone for those, they are never treated as sequence timeouts anyway. Fixes: ea97f6c8558e ("io_uring: add support for multishot timeouts") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-30-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ec99bc7fae9f9bc92c5b048d7bb2c32b8263e93d Author: Josef Bacik Date: Thu Oct 15 19:30:53 2026 +0000 io_uring/timeout: don't skip over reached sequences Commit c6c0b3eba88c3b13ca11ea112404982e86d58f7a upstream. io_flush_timeouts() copes with the wrap of the CQ sequence by looking at the distance from ->cq_last_tm_flush. That relies on the target of each pending timeout being at or ahead of the last flush. io_timeout() breaks that. It sets ->cq_last_tm_flush to the current sequence, on the assumption that nothing has been posted since the last flush. That isn't true. A multishot request posts its CQEs right when it is issued or retried, but they are committed, and the timeouts flushed, at the end of the submission or task_work run: X: IORING_OP_TIMEOUT, off == 1 target_seq == N + 1 io_submit_sqes() multishot recv, posts two CQEs sequence == N + 2 Y: IORING_OP_TIMEOUT, off == 100 ->cq_last_tm_flush = N + 2 io_flush_timeouts() X: events_needed = N + 1 - (N + 2) // 0xffffffff events_got = 0 // not yet X isn't completed although the completions it was waiting for have happened, only its timer can end it now. And as the list is sorted and the walk ends at the first timeout that isn't due, it gets in the way of the ones behind it. The insertion sort has the same problem, it measures the distance of the pending targets from the current sequence. ->cq_last_tm_flush only needs to be brought up to date if no timeout is waiting for a sequence, as io_flush_timeouts() isn't called before the first one is set up. Otherwise it is current enough. Timeouts with a sequence come first in the list, so looking at the first entry will do. Use the last flush as the base for the insertion sort as well. Fixes: f010505b78a4 ("io_uring: flush timeouts that should already have expired") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-29-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c5a92562cddf13bff2b139b926f2d549a3e55a97 Author: Josef Bacik Date: Thu Oct 15 19:30:52 2026 +0000 io_uring/fdinfo: fix CQE dump of CQE32 rings Commit e4507a62c247081fffe299622c04c6f7c3d98e92 upstream. Since the CQ ring dump was changed to deal with IORING_SETUP_CQE_MIXED, a 32b CQE is taken to occupy two entries of the ring. That is how it works for mixed rings. With IORING_SETUP_CQE32 each entry has twice the size: head and tail count 32b CQEs, and entry n is found at cqes[n << 1]. For such rings the dump reads cqes[n], and skips every other entry. It shows half of the pending CQEs at best, and what it shows is taken from the wrong place unless the head happens to be at the start of the ring. The extra data of the last entry isn't shown at all, as the check that keeps the dump of a mixed ring from reading beyond the array is applied to these rings as well. [ 6.18: without the last-slot check of f26f49600c9a, which is not in 6.18 ] Fixes: 82ceb7fcc5ff ("io_uring/fdinfo: handle mixed sized CQEs") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-28-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Co-Authored-By: Claude Fable 5.1 Signed-off-by: Greg Kroah-Hartman commit 24ea0d2fc921f17167f8e6b3a309e2700efc7161 Author: Josef Bacik Date: Thu Oct 15 19:30:50 2026 +0000 io_uring/register: handle index wrap when resizing Commit e8dee8d5498c710a22a84076d8ecb661627032b4 upstream. The ring heads and tails are free running 32-bit counters. io_register_resize_rings() takes that into account when it checks whether the pending entries fit into the new rings, but then copies them with for (i = old_head; i < tail; i++) If the tail has wrapped and the head hasn't, that copies nothing. The new rings get the old head and tail, so the application finds whatever is in the freshly allocated memory, zeroes, in place of the CQEs it hasn't reaped yet, or the kernel in place of the SQEs that have not been submitted yet. A ring that completes a million requests per second gets there after little more than an hour. Loop until the tail is reached, the number of iterations has been bounded by the size of the new ring at that point. Fixes: 79cfe9e59c2a ("io_uring/register: add IORING_REGISTER_RESIZE_RINGS") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-26-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 82274bbae24fe4b7a7bfe3dae0e7439df9b8deed Author: Josef Bacik Date: Thu Oct 15 19:30:49 2026 +0000 io_uring/register: don't wrap 32b CQEs when resizing Commit 0edf1930b8ed3c398d3cbdbafd8f72dbd1a3d9e4 upstream. On an IORING_SETUP_CQE_MIXED ring, a 32b CQE uses two contiguous CQ entries and is never allowed to wrap the end of the ring. When posting, io_cqe_cache_refill() inserts a dummy IORING_CQE_F_SKIP entry if only one entry is left before the ring wraps, and the application relies on that to read a 32b CQE as one contiguous 32 byte slot. io_register_resize_rings() copies pending CQEs to the new ring one 16b entry at a time, placing entry i at i & (new_entries - 1). When the CQ ring is shrunk, a pending 32b CQE that was contiguous in the old ring can land with its first half on the last entry of the new ring and its second half on entry 0. For example, with 8 old entries, 4 new entries and a 32b CQE at index 3, the halves end up at entries 3 and 0. The application then reads the extra data of that CQE from past the end of the CQ array, and the CQE content it sees is wrong. This was found by code inspection and has not been reproduced. Fix by failing the resize with -EOVERFLOW if a pending 32b CQE would wrap the new ring, the same way the resize fails when the pending CQEs don't fit. Fixes: e26dca67fde1 ("io_uring: add support for IORING_SETUP_CQE_MIXED") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-25-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3a9c90b5be6fe6108604e9f849626f5c50642428 Author: Josef Bacik Date: Thu Oct 15 19:30:47 2026 +0000 io_uring: drop the CQE cache if a refill fails Commit 78f9c9cffef02a290b6e97672aaa9c75df0d21da upstream. ->cqe_cached and ->cqe_sentinel delimit the CQ entries which can be handed out without looking at the ring. io_get_cqe_overflow() only calls io_cqe_cache_refill() if that range is too small. Without IORING_SETUP_CQE_MIXED too small means empty. With it, a 32b CQE needs two entries, and one may be left. If the refill then fails, the entry stays in the cache, and the next 16b CQE gets it without any checks. That CQE overtakes the 32b one, which went to the overflow list. The test for IO_CHECK_CQ_OVERFLOW_BIT, which is there to prevent that, is part of the refill: CQ ring with 4 entries, head == 0 16b CQE, 32b CQE tail == 3, one entry cached 32b CQE no room, the CQE overflows 16b CQE written to entry 3, ahead of the 32b CQE Forget about the rest of the cache when it is refilled. Fixes: e26dca67fde1 ("io_uring: add support for IORING_SETUP_CQE_MIXED") Reported-by: Leonid Ovchinnikov Closes: https://lore.kernel.org/io-uring/CAECZYD5OMD9vMTzjteFMMP40Dn+SWKj9SFj=43U6uO3XMnxJbw@mail.gmail.com/ Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-23-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3330d7c73fa95febaeb7bd22baceab84f1a534a8 Author: Josef Bacik Date: Thu Oct 15 19:30:46 2026 +0000 io_uring/futex: allocate private hash before waiting Commit 3eff68bce25584cded3fb6ec033ff9a1c9913d04 upstream. The futex code relies on there being no private futex waiters by the time the first private hash of a mm is installed: __futex_pivot_hash() moves the waiters from the previous private hash to the new one, but it does not look for them in the global hash which is used as long as there is no private hash. That is why every clone(CLONE_VM) allocates it up front: a task which is alone in its mm cannot block in futex_wait() and create a thread or invoke prctl(PR_FUTEX_HASH) at the same time. IORING_OP_FUTEX_WAIT and IORING_OP_FUTEX_WAITV do not block the submitter though: io_uring_enter() io_futex_wait() futex_wait_setup() // no private hash: queued in the global hash pthread_create() futex_hash_allocate_default() __futex_pivot_hash() // first private hash, nothing is moved futex(FUTEX_WAKE_PRIVATE) futex_hash() // private hash: no waiter The wakeup is lost and the request only completes when it is cancelled. prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS, n) instead of pthread_create() has the same effect. Allocate the default private hash when a wait request on a private futex is prepared, which happens in the context of the submitter. This is a RCU protected pointer check once the hash exists. A failure to allocate it fails the request with -ENOMEM. [ 6.18: the futex vector is a local, not ifd->futexv, so free that on error ] Fixes: 80367ad01d93 ("futex: Add basic infrastructure for local task local hash") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-22-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Co-Authored-By: Claude Fable 5.1 Signed-off-by: Greg Kroah-Hartman commit 1924a7e963089c7a97cd5e76d55cec64a5c7a164 Author: Josef Bacik Date: Thu Oct 15 19:30:45 2026 +0000 io_uring/poll: drop stale double poll entry on rearm Commit f2dbe87968a3aef74a11c025776d293b80964d3f upstream. A file that uses two wait queues for poll, e.g. a tty, gets a second io_poll entry, which IORING_OP_POLL_ADD keeps in ->async_data until the request is freed. io_poll_add() can run more than once for a request though: IORING_OP_POLL_REMOVE with one of the update flags disarms and rearms it, and io_poll_task_func() reissues it if a wake up turns out to be spurious. The second poll_wait() of the new round then finds *poll_ptr set, with ->head cleared by the disarm, and __io_queue_proc() fails what it takes for a third wait queue with -EINVAL. For an update that means that the poll request is completed with -ECANCELED, while the update itself reports success. For a spurious wake up, e.g. tcsetattr() on the polled tty, the poll request fails with -EINVAL. Free the old entry and clear the poll flags before arming, which is what io_arm_apoll() does for internal polling. All entries have been removed from their wait queues at that point. Fixes: b69de288e913 ("io_uring: allow events and user_data update of running poll requests") Fixes: 6e5aedb9324a ("io_uring/poll: attempt request issue after racy poll wakeup") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-21-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit feb9c75c4d24d4a000af0d6d1d3caf76613c54e8 Author: Josef Bacik Date: Thu Oct 15 19:30:44 2026 +0000 io_uring/wait: look at all CQ waiters on wake up Commit 356f92f2412686f822383b784fa102924407457a upstream. io_wake_function() returns -1 if the waiter it is called for doesn't have enough events yet, which makes __wake_up_common() stop walking the wait queue. That assumes that the waiters behind it can't be satisfied either. Each waiter has its own target though, computed from the min_complete it passed in: thread A: io_uring_enter(GETEVENTS, min_complete = 10) // queued first thread B: io_uring_enter(GETEVENTS, min_complete = 1) one CQE is posted: A isn't woken, and B isn't even considered B keeps sleeping with the event it asked for sitting in the CQ ring, until A's demand is met or a timeout or signal ends the wait. Return 0 to carry on with the next waiter. Only waiters whose condition is met are woken, like before. [ 6.18: io_wake_function() lives in io_uring.c, there is no wait.c yet ] Fixes: bda521624e75 ("io_uring: make CQ ring wakeups be more efficient") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-20-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Co-Authored-By: Claude Fable 5.1 Signed-off-by: Greg Kroah-Hartman commit 2c88d978f1dfd03edf67924ea8fd25cc45499eef Author: Josef Bacik Date: Thu Oct 15 19:30:43 2026 +0000 io_uring: wake ring pollers for local task_work Commit b88902d8745a701d24275d012f0830e3628e2a22 upstream. With IORING_SETUP_DEFER_TASKRUN completions are queued as local work, and only become CQEs when the submitter enters the kernel to wait for events. For an application that finds out via poll() or epoll on the ring fd when it is time to do that, io_uring_poll() reports EPOLLIN if local work is pending. That only helps if the work is there at the time of the call. When DEFER_TASKRUN was added, io_req_local_work_add() did io_cqring_wake(), which took care of tasks sleeping in poll() as well. Then polling got a wait queue of its own, ->poll_wq, and the wake up in io_req_local_work_add() was replaced by waking the submitter directly. Since then ->poll_wq is only woken when CQEs are committed, which for such a ring is done by the very task that is waiting to be told to: submitter completion poll(ring_fd) io_uring_poll() // nothing yet schedule() io_req_local_work_add() // ->cq_wait_nr: nobody waits // sleeps on Wake ->poll_wq when the first entry is put on the work list. Like for the eventfd, that must not be done right away if the work is queued from a wake up handler, as the chain of wake ups could get back to the wait queue whose lock is held. Use an RCU callback in that case, with a reference to the ring. [ 6.18: io_req_local_work_add() lives in io_uring.c, and ->poll_activated is a bitfield rather than an int_flags bit ] Fixes: 130bd686d9be ("io_uring: waitqueue-less cq waiting") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-19-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Co-Authored-By: Claude Fable 5.1 Signed-off-by: Greg Kroah-Hartman commit 1827b011dd85d28afba0b290a0e3ef4192d9d372 Author: Josef Bacik Date: Thu Oct 15 19:30:42 2026 +0000 io_uring/cancel: let CANCEL_ALL find parked requests Commit fe6ca13c98b1223f6005f32913ebd32e4df64b77 upstream. A cancellation with IORING_ASYNC_CANCEL_ALL or _ANY goes on until it finds nothing more. A request may stay where it was found for a while after it has been cancelled, so each one that matches is stamped with the sequence number of the cancellation, and is skipped from then on. io_cancel_cb() does so for io-wq work as well. There is no need to: pending work is taken off the list, and the workers are looked at once per call. And it does harm. A request that is run by io-wq may be parked while it still is the current work of the worker: poll gets armed for it, or it is put on ->futex_list or ->waitid_list. io-wq worker io_try_cancel() io_wq_submit_work() io_arm_poll_handler() io_poll_add_hash() io_async_cancel_one() io_cancel_cb() stamps the request sets IO_WQ_WORK_CANCEL = -EALREADY io_poll_cancel() skips the request = -ENOENT io_assign_current_work(NULL) The flag comes too late for the worker to see it, and the search that would have found the request takes it for done. The cancellation returns, and the request stays. With a multishot poll, IOSQE_ASYNC, and IORING_OP_ASYNC_CANCEL with IORING_ASYNC_CANCEL_ALL up to 63us later, that happens to 4 of 1,000 requests (4 CPUs, KVM). Take the stamp off again if the work matches. If the request is found on one of the lists it gets a new one, and io_cancel_cb() doesn't match it a second time. __io_async_cancel() tries the io-wq of the caller twice. So far the stamp has kept it from counting work that is running there the second time. Skip it instead, so that the number that is returned stays the same. Fixes: 8e29da69fead ("io_uring: add support for IORING_ASYNC_CANCEL_ALL") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-18-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 49dbeedbcc39f94d216a3bbac394c6002e40d7e3 Author: Josef Bacik Date: Thu Oct 15 19:30:41 2026 +0000 io_uring/cancel: recognize "no timeout" on 32-bit Commit 3774e4d4c8533da2caae95556c4d635c7c4f45b8 upstream. IORING_REGISTER_SYNC_CANCEL waits without a limit if both fields of io_uring_sync_cancel_reg::timeout are -1. io_sync_cancel() compares them with -1UL. They are of type long long. With a long of 32 bits -1UL is 4294967295, which is what it stays when it is converted for the comparison, and the fields are never equal to it. So { -1, -1 } is taken for a timeout. ktime_set() takes the nanoseconds as an unsigned long, so what becomes of it is -1s + 4294967295ns = 3.29s. If the request is being run by io-wq and can't be interrupted, the call returns -ETIME after that time, rather than waiting for the request to be gone. On i386, with a buffered read from a null_blk device that takes 4s to complete a request, IOSQE_ASYNC, that is what each call does. Fixes: 78a861b94959 ("io_uring: add sync cancelation API through io_uring_register()") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-17-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 83fb8fe2210d6184a8b774ef77bc79cf26cf0a3c Author: Josef Bacik Date: Thu Oct 15 19:30:40 2026 +0000 io_uring/cancel: don't forget that the work was running Commit 8aa0e5db4845fb5ac11abe40d7b1cac0656c3ee3 upstream. If the request to be cancelled is being run by io-wq, io_async_cancel_one() flags the work, signals the worker and returns -EALREADY. Since commit ccbf726171b7 ("io_uring: perform poll removal even if async work removal is successful") io_try_cancel() goes on regardless, as poll may be armed for the request. If it isn't, and nothing else turns up, the result is the -ENOENT of the last search. __io_async_cancel() makes up for that. On -ENOENT it tries the io-wq of every task that uses the ring, and that of the caller is one of them. So the work is found a second time, and the result is -EALREADY after all. Unless the worker is done with it by then. If the work is flagged before io_wq_submit_work() looks at IO_WQ_WORK_CANCEL, all the worker does is to queue the request to be failed by task work. Then it isn't anywhere to be found until the task work has run, and - IORING_REGISTER_SYNC_CANCEL returns -ENOENT, - IORING_OP_ASYNC_CANCEL completes with -ENOENT, for a request that they have just cancelled, and that completes with -ECANCELED. With a read of an empty pipe, IOSQE_ASYNC, and a sync cancel right behind it, 1 to 3 of 1,000,000 calls return -ENOENT, and 50 to 110 with IORING_SETUP_DEFER_TASKRUN (4 CPUs, KVM). Nothing is written to the pipe, and all of these reads end with -ECANCELED. Remember that the work was found. IORING_OP_ASYNC_CANCEL completes with -EALREADY, as it does if the worker is a bit slower. For IORING_REGISTER_SYNC_CANCEL it means to try again, which ends with 0. The result of a linked timeout, which calls io_try_cancel() by itself, and the number that is returned for IORING_ASYNC_CANCEL_ALL and _ANY don't change. Fixes: ccbf726171b7 ("io_uring: perform poll removal even if async work removal is successful") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-16-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4a9748a48f238fbbcc6d899bbe8471def40f9db8 Author: Josef Bacik Date: Thu Oct 15 19:30:39 2026 +0000 io_uring: don't lose a cancel as io-wq parks a request Commit 5cb049d2203d7a81a1c1a737c8df4575e71078e3 upstream. IORING_OP_FUTEX_WAIT, IORING_OP_FUTEX_WAITV and IORING_OP_WAITID don't block. They put the request on a list of the ring, where a wake up or a cancellation finds it, and return IOU_ISSUE_SKIP_COMPLETE. They do so as well if they are run by io-wq, e.g. because of IOSQE_ASYNC. io_wq_submit_work() looks at IO_WQ_WORK_CANCEL once, before it issues the request. Somebody who wants to cancel the request after that, and before it is on the list, finds it running: io-wq worker io_try_cancel() io_wq_submit_work() IO_WQ_WORK_CANCEL isn't set io_async_cancel_one() sets IO_WQ_WORK_CANCEL signals the worker = -EALREADY ... io_futex_cancel() = -ENOENT ... io_futex_wait() adds the request to ->futex_list = IOU_ISSUE_SKIP_COMPLETE Nobody looks at the flag again. IORING_OP_ASYNC_CANCEL returns -EALREADY and the request stays. It is the problem that "io_uring/poll: don't lose a cancel as io-wq arms poll" deals with for poll. Look at the flag once the request is on the list, and cancel it if it is set. The lists are searched and the requests are added with ->uring_lock held, and the flag is set before the search. So either the search finds the request, or it came first and the flag is seen. What the canceller is told doesn't change, see the other patch, also for IORING_ASYNC_CANCEL_ALL and _ANY. Fixes: 194bb58c6090 ("io_uring: add support for futex wake and wait") Fixes: 8f350194d5cf ("io_uring: add support for vectored futex waits") Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-15-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 272f545ab9314781ff4f9910222d3614c39ed9dd Author: Josef Bacik Date: Thu Oct 15 19:30:38 2026 +0000 io_uring/poll: don't lose a cancel as io-wq arms poll Commit 6d2d4c2530e95ff6ddeb98195d49d99dbca14369 upstream. A request on a pollable file that was forced to io-wq is issued without blocking there. If that ends in -EAGAIN, io_wq_submit_work() arms poll for it and returns. It looks at IO_WQ_WORK_CANCEL once, before it issues the request. Somebody who wants to cancel the request in between finds it running: io-wq worker io_try_cancel() io_wq_submit_work() IO_WQ_WORK_CANCEL isn't set io_issue_sqe() = -EAGAIN io_async_cancel_one() sets IO_WQ_WORK_CANCEL signals the worker = -EALREADY io_poll_cancel() = -ENOENT ... = -ENOENT io_arm_poll_handler() = IO_APOLL_OK return Nobody looks at the flag again, and the signal doesn't matter to a worker that doesn't sleep. The request is armed as if nothing had happened: - a linked timeout completes with -ENOENT, and the request it was meant to limit waits for as long as it takes. - IORING_OP_ASYNC_CANCEL returns -EALREADY, and the request stays. - IORING_REGISTER_SYNC_CANCEL waits for the request to complete if it gets -EALREADY. Since commit 5623eb1ed035 ("io_uring/tctx: add separate lock for list of tctx's in ctx") it doesn't sleep but spins, so its next attempt finds the armed poll. The same goes for a multishot poll, recv or accept that is armed from io-wq. With a read of an empty pipe, IOSQE_ASYNC, and a linked timeout of 5ms or a cancel in the same submission, in a guest that is slow enough (TCG, KASAN), the request is lost in 21 of 24 rounds of 40 or 100 attempts. While it arms poll from io-wq, __io_arm_poll_handler() owns the request. Look at the flag once the request is in the hash table. The table is searched and the request is added with ->uring_lock held, and the flag is set before the search. So either the search finds the request, or it came first and the flag is seen. With the request marked as cancelled, the task work that is queued, right away or because ownership can't be released, fails it with -ECANCELED. What the canceller is told doesn't change. In this window a linked timeout still completes with -ENOENT rather than -ETIME, a cancel request with -EALREADY, and one with IORING_ASYNC_CANCEL_ALL or _ANY with a count that doesn't include the request. But the request is cancelled, so what is new is a request that completes with -ECANCELED after such a result. This doesn't help in two cases: - IORING_ASYNC_CANCEL_ALL and _ANY, if the work is flagged after the test added here, while io-wq still has it as the current work of the worker. io_cancel_cb() stamps it with the sequence of the cancel, so the search of the hash table on behalf of the same cancel takes it for done and skips it. - requests that are parked elsewhere by io-wq, like IORING_OP_FUTEX_WAIT and IORING_OP_WAITID. They have the same problem. Fixes: 90fa02883f06 ("io_uring: implement async hybrid mode for pollable requests") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-14-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a08c16cf403231f10c97090ecabf87b81afab250 Author: Josef Bacik Date: Thu Oct 15 19:30:37 2026 +0000 io_uring/io-wq: let cancel find picked up hashed work Commit e9efeb4fc97b0879512a3c3b995ed448f2487e12 upstream. io_get_next_work() takes all the work items that share a hash off the work list in one go, and the worker runs them one after the other. Only the one it is working on is visible as ->cur_work. The others are neither on the list nor current, so io_wq_cancel_cb() can't find them. IORING_OP_ASYNC_CANCEL and IORING_REGISTER_SYNC_CANCEL return -ENOENT for a request that has not even been started, e.g. a buffered write queued behind another write to the same file that is blocked, and the request is carried out. The cancellation done for a task or ring that goes away gets there in the end, as it keeps trying, but it has to wait for each item to become current. Keep a pointer to the remainder of the chain next to ->cur_work, and have io_wq_worker_cancel() look at it. The items on it belong to the worker, which needs ->lock to move on to the next one. Matching work is flagged with IO_WQ_WORK_CANCEL and fails with -ECANCELED when its turn comes. The worker isn't signalled for it, that would interrupt the unrelated work it is busy with. As the request isn't gone yet, it is reported like running work, with -EALREADY. Fixes: 86f3cd1b589a ("io-wq: handle hashed writes in chains") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-13-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5d8092339f3238e18af611013ad834cb59d3853f Author: Josef Bacik Date: Thu Oct 15 19:30:36 2026 +0000 io_uring/io-wq: don't exit with a creation pending Commit e231d2e8f80d3649ecd3851b7f2abdfbe606c04b upstream. A worker that is the last one to go to sleep while work is pending asks for another worker. io_wq_dec_running() bumps ->nr_running on behalf of the new worker and queues create_worker_cb() as task_work for the owner of the io-wq. Until that has run, everybody else takes it that a worker is running which is going to look after the work list: io_wq_enqueue() doesn't create one, and other workers that go to sleep don't find themselves to be the last. If the worker that made the request exits, io_worker_exit() cancels the task_work, and io_worker_cancel_cb() drops ->nr_running without a look at the work list: worker A worker B io_wq_enqueue() blocks, work is pending nr_running++ queues create_worker_cb() wakes, handles the work idle timeout, decides to exit picks up work 1 queues work 2 B is on the free list still: wakes B work 1 blocks nr_running 2 -> 1 io_worker_exit() io_worker_cancel_cb() nr_running 1 -> 0 Work 2 has to wait for work 1, although there is room for more workers. It takes an owner that doesn't get around to run its task_work for the time of the idle timeout, less if the worker exits because its affinity was changed or the io-wq is marked exit-on-idle. Let the worker stay around until its request has been dealt with. Only the worker itself sets ->create_state, so it can't be set behind its back once it has decided to leave. Fixes: 1d5f5ea7cb7d ("io-wq: remove worker to owner tw dependency") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-12-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 661bfc5b5cecb04f2b13d9f98d767f7d5ac0feb7 Author: Josef Bacik Date: Thu Oct 15 19:30:35 2026 +0000 io_uring/io-wq: don't strand work when a worker exits Commit ad41f325be1271b22d99353819c90f0d5e45acc8 upstream. A worker exits if its idle timeout fired and it isn't the last one, if its affinity was changed, or if the wq is marked exit-on-idle. It decides so after it found the work list empty, and until io_worker_exit() is through it stays on the free list and in ->nr_running: worker io_wq_enqueue() io_acct_run_queue() == false queues work io_acct_activate_free_worker() wake_up_process(worker) // found one, nothing to create acct->nr_workers-- break io_worker_exit() Nobody is going to look at the work. If other workers exist, it has to wait until one of them finishes what it is blocked on or hits its idle timeout. If not, which is possible for the affinity and the exit-on-idle case, it sits there until something else is queued. For exit-on-idle it takes a task that closes its last ring and sets up a new one while the workers are on their way out. Make the worker take itself off the free list when it gives up its ->nr_workers slot, then leave ->nr_running, and only then take the final look at the work list. That look and queueing work are both done under acct->lock, so either the worker sees the work and stays, or the enqueue side sees that the worker is gone and wakes or creates another one. If it wants to stay and finds that its slot has been taken, a worker has been created in its place, which is going to look at the work list, and it can leave after all. Fixes: 38aa434ab933 ("io_uring/io-wq: add exit-on-idle state") Fixes: 05c5f4ee4da7 ("io-wq: get rid of FIXED worker flag") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-11-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 20558701dbeb1bfe03440fc1df47d9afa89ef294 Author: Josef Bacik Date: Thu Oct 15 19:30:34 2026 +0000 io_uring/io-wq: don't go to sleep on pending work Commit f19c38feb96802ee53a99649d740d2bf630bcce7 upstream. io_wq_enqueue() wakes a worker off the free list. If there is none it creates one, unless ->nr_running says that a worker is running. That relies on whoever takes ->nr_running to zero to check for pending work, which io_wq_dec_running() no longer does for a worker without ->cur_work, on the grounds that an idle worker is either woken right away or someone else has created a worker. Neither has to be the case: worker A (idle) worker B (idle) io_wq_enqueue() woken for work 1 woken (e.g. timeout) takes work 1 work list is empty queues work 2 B is first on the free list: wake_up_process(B) leaves the free list work 1 blocks nr_running 2 -> 1 schedule_timeout() nr_running 1 -> 0 ->cur_work == NULL Work 2 isn't looked at until work 1 is done or A's idle timeout fires, five seconds later. ->cur_work is also NULL while a worker blocks on ->uring_lock in io_wq_put_work(), with the same result if it was the only one running. Let the idle worker leave ->nr_running by itself before it takes its last look at the work list. Both that and queueing work are done under acct->lock, so either the worker sees the work, or the enqueue side sees that it can't count on this worker. This doesn't bring back the request for a new worker which the check was meant to avoid, and as idle workers don't get to io_wq_dec_running() any more, the check can go. Fixes: 8343cae362e1 ("io_uring/io-wq: ignore non-busy worker going to sleep") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-10-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 14f56e9c0b8fdc2e178acdbec9781e90ef46f7e9 Author: Josef Bacik Date: Thu Oct 15 19:30:30 2026 +0000 io_uring: don't flood a cancelling task with task_work Commit 22e643e61b9b6299b42ff7d88bab48bccada8a5d upstream. io_ring_exit_work() asks each task which has used the ring to remove its tctx node, by task_work, and repeats that until the list is empty. io_tctx_exit_cb() doesn't touch the node while the task is in io_uring_cancel_generic(), which removes all the nodes at its end. So the work item queues the callback again as soon as it has completed, for nothing. That is more than a waste of time. task_work_run() only returns when it finds the list empty. If the rings are released from inside the cancellation, because requests of other rings held the last references to their files, up to 64 work items keep sending callbacks to the one task which is running them. It never finds the list empty, never gets back to the cancellation, the nodes stay, and so it goes on: a task with 60 pairs of rings which poll each other ran 280000 callbacks in 5 seconds, 20 seconds after exit_group(). It ends when all the senders happen to be late at the same time. Until then the task keeps a CPU and the work items busy. An exiting task can't be killed meanwhile. execve() cancels the requests in the same way, so a live task can get stuck there as well, for minutes. If it takes more than five, the work items run into the WARN_ON_ONCE(time_after(jiffies, timeout)) of io_ring_exit_work(). No privilege is needed for any of this. If the callback has met a task in cancellation, wait a little before it is sent again. Nobody has to wake the work item up for that: either the node is gone by then, or it is the turn of the next round. Fixes: d56d938b4bef ("io_uring: do ctx initiated file note removal") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-6-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3e02b8df0e9fa1423ac2a4e03409a9329c30ac49 Author: Josef Bacik Date: Thu Oct 15 19:30:29 2026 +0000 io_uring/io-wq: don't hide a link from cancellations Commit 436d48a2ed13112d2d27085325838e5bce6b4507 upstream. A task that exits cancels its tracked requests and waits until they are gone. io_uring_cancel_generic() looks everywhere a request can be, and goes to sleep if it found nothing to cancel. It is woken up each time one of the requests of the task is completed by task work or freed. When io-wq is done with a request that has a link, there is a time in which the next request of the link can't be found: io_worker_handle_work() io_assign_current_work(worker, NULL) io_wq_free_work(work) io_req_find_next() // takes the link off the request io_free_req() // task work for the task io_assign_current_work(worker, linked) io_run_task_work() cond_resched() worker->cur_work = linked It is not pending, it is not the current work of a worker, and it is not yet on the list that it is about to be parked on. If the pass that the exiting task makes because of io_free_req() falls into that time, it finds nothing and the task goes to sleep. The worker then runs the link, which IO_WQ_BIT_EXIT doesn't prevent for bounded work. If that parks the request nothing is completed or freed, and nobody wakes up the task. If it is the process that exits it can't be killed any more either. NOP, IOSQE_ASYNC | IOSQE_IO_LINK FUTEX_WAIT, FUTEX2_PRIVATE exit of the thread, or of the process, up to 63us later With four of these per round 5 to 8 of 10,000 rounds hang (4 CPUs, KVM): io_uring_cancel_generic do_exit Commit f8b632e89a10 ("io_uring: tighten task exit cancellations") is about the same gap, and makes the task look again for whatever happens before io_free_req(). Free the request once the link is the current work of the worker, or pending. Whoever is woken up by that can find the link, until it is parked where cancellations look as well. To do so split io_wq_free_work() in two. [ 6.18: io_wq_free_work() has no REQ_F_CQE_SKIP link check yet (5530a5102e3c), kept its link logic in the split ] Fixes: 768134d4f481 ("io_uring: don't do flush cancel under inflight_lock") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-5-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Co-Authored-By: Claude Fable 5.1 Signed-off-by: Greg Kroah-Hartman commit 7309fea05a3d66af9746843c43fef14c10b8141e Author: Josef Bacik Date: Thu Oct 15 19:30:28 2026 +0000 io_uring/io-wq: don't lose the signal that ends work Commit 63c103279a95e82280092f2f4232e91e8117a252 upstream. When a thread exits, only its tracked requests are cancelled. Then its io-wq is torn down. io_wq_exit_workers() signals every worker, to get it out of an interruptible sleep, and waits for all of them to exit. Before they do, they go through the work that is left. Unbounded work is cancelled. Bounded work is run, as it is expected to end by itself. Not all of it does. An open has no file yet, so it counts as bounded, and the open of a FIFO waits for the other end. That is what the signal is for. But the workers are signalled once, and a worker that hasn't started the work by then loses the signal: io_wq_exit_workers() io_worker_handle_work() io_wq_worker_wake() set TIF_NOTIFY_SIGNAL io_assign_current_work() io_run_task_work() clear TIF_NOTIFY_SIGNAL io_wq_submit_work() fifo_open() wait_for_partner() wait_for_completion_timeout() The thread never gets out of do_exit(): IORING_OP_OPENAT of a FIFO without a writer, IOSQE_ASYNC exit of the thread that has submitted it hangs in more than 9 of 10 attempts (4 CPUs, KVM), until the process is killed. Set TIF_NOTIFY_SIGNAL for bounded work that is started with IO_WQ_BIT_EXIT set. The bit is set before the workers are signalled, and it is tested after the flag has been cleared, with clear_notify_signal() providing the barrier. So either the flag stays, or the bit is seen. Work that is started while the io-wq exits is treated like work that is being run at that time: it isn't interrupted unless it waits interruptibly. Fixes: afcc4015d1bf ("io-wq: provide an io_wq_put_and_exit() helper") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-4-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4a89352edd8b3e20d1e1fb33f0fc297dd137149f Author: Josef Bacik Date: Thu Oct 15 19:30:27 2026 +0000 io_uring/wait: don't spin on a stuck overflow list Commit 34f5a664c34d3cb62f6bec7f4156754594a7d25b upstream. As long as IO_CHECK_CQ_OVERFLOW_BIT is set, io_cqring_wait_schedule() returns right away, before it gets to look at signals or arms the timeout, for io_cqring_wait() to flush the overflow list. If that doesn't empty the list, and the CQ ring doesn't hold the number of events the caller wants, the loop starts over, with the same result. The task spins in the kernel, and can't be killed. The assumption is that this can't happen: if CQEs can't be flushed, the ring is full, and min_events is capped to the size of the ring. But: - With IORING_SETUP_CQE_MIXED a 32b CQE needs two contiguous entries. It is stuck on the list if a single one is free, and then the ring holds less than cq_entries events. A single threaded application that asks for as many events as the ring has entries never gets out of io_uring_enter(). - Whether the ring is full is up to the CQ head, which the application can write to. While one thread waits for events on an empty ring, another one can move the head back so that the ring looks full and have a CQE overflow. The waiter can't be stopped any more, not even by SIGKILL. Only the application can make room in the CQ ring. Return to it if the list could not be flushed. [ 6.18: io_cqring_wait() lives in io_uring.c, there is no wait.c yet ] Fixes: 3fcf19d592d5 ("io_uring: parse check_cq out of wq waiting") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-3-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Co-Authored-By: Claude Fable 5.1 Signed-off-by: Greg Kroah-Hartman commit 2d5af21422060c088f6e4fb0f1e7dcf5bcdd6707 Author: Josef Bacik Date: Thu Oct 15 19:30:26 2026 +0000 io_uring/cmd: don't leave list poison in ->hash_node Commit 4c83e39f4d1944d7146fd06094f2c8053238d55c upstream. io_uring_cmd_del_cancelable() uses hlist_del() to take a command off ->cancelable_uring_cmd, which leaves LIST_POISON1/2 behind in ->hash_node. Requests are recycled through the request cache without being reinitialised, and not every user of ->hash_node sets it up before it is used: If a vectored futex wait is woken while futex_wait_multiple_setup() is still queueing the futexes, io_futexv_wait() doesn't add the request to ->futex_list, and leaves the completion to the task_work queued by the wake up. io_futexv_complete() ends in __io_futex_complete(), whose hlist_del_init() is fine for a request that is unhashed, which is how all other users of the node leave it. If the request was a cancelable uring_cmd in its previous life, e.g. a ublk FETCH_REQ, it writes through LIST_POISON2: Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-...] RIP: 0010:io_futexv_complete+0x219/0x420 Call Trace: tctx_task_work_run+0x804/0x950 tctx_task_work+0x71/0xa0 task_work_run+0x118/0x200 Leave the node unhashed. Fixes: 93b8cc60c37b ("io_uring: cancelable uring_cmd") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-2-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8381a912c65b8de16e8a848225c7c5a56b6ea834 Author: Josef Bacik Date: Thu Oct 15 19:30:25 2026 +0000 io_uring/waitid: own the request before clearing ->head Commit c254eec4364b9f4b4cbdce43be3fb4df5a651a70 upstream. io_waitid_remove_wq() only takes the wait queue lock if ->head is set. io_waitid_wait() clears ->head first thing, before it tries to become the owner of the request by bumping ->refs. If somebody else owns the request at that point, nothing keeps it from completing the request while the wake up handler is still going to touch it: CPU0 (io_waitid_wait) CPU1 (io_waitid, holds a ref) list_del_init(&wait->entry) smp_store_release(&iw->head, NULL) __do_wait() finds another child io_waitid_remove_wq() // ->head == NULL, no locking io_waitid_finish(), IOU_COMPLETE // request freed and reused atomic_fetch_inc(&iw->refs) The same goes for __io_waitid_cancel() if it claims the request in that window. ->refs is part of the per opcode data of the request, so this increments whatever the next user of the request keeps there. If that happens to be zero, the handler concludes that it owns the request, and queues io_waitid_cb() for it. With the window held open by a delay, and the request reused for a receive that is waiting for data: BUG: KASAN: slab-use-after-free in __wake_up_common+0x1ca/0x1f0 __wake_up_sync_key+0x36/0x50 sock_def_readable+0xf1/0x420 unix_stream_sendmsg+0x60b/0x1110 Allocated by task 87: io_arm_apoll+0x1ed/0x940 Freed by task 87: __io_submit_flush_completions+0x118d/0x1a10 tctx_task_work_run+0x327/0x950 Only clear ->head once the handler owns the request. If it doesn't, the owner finds ->head set and has to wait for the lock, which is held by the caller of the handler. Deleting the already deleted entry again is harmless. Fixes: ab673c1bcaf2 ("io_uring/waitid: use io_waitid_remove_wq() consistently") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-1-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0d81cdd433b0a96c5275c01b8172e0b1f71dd595 Author: Christian Brauner Date: Mon Sep 21 15:44:53 2026 +0200 io-wq: order the exit bit against worker creation task work Commit 0e5663856b69219ef2f02e04bac9f5c5be19718a upstream. io_wq_exit_workers() cancels task work for queued worker creation with task_work_cancel_match(). That has a plain load of task->task_works. io_queue_worker_create() adds the new entry and tests IO_WQ_BIT_EXIT to cancel it if the workqueue is already on its way out. That must be ordered. task_work_add() has a full barrier via cmpxchg(). But io_wq_exit_start() sets the bit with set_bit() which doesn't have any memory ordering. So afaict, on weakly ordered architectures the exiting task may load task_works before the store of the bit is visible. The other side tests the bit before the store is visible as well. So the entry remains queued with worker_refs and the exiting task waits on worker_done indefinitely. If the task still has rings then io_uring_del_tctx_node() provides the barrier via test_and_set_bit() in io_wq_set_exit_on_idle(). When it has closed all rings though that barrier is gone. Add the barrier after the set_bit(). Fixes: 71a85387546e ("io-wq: check for wq exit after adding new worker task_work") Cc: stable@vger.kernel.org Reviewed-by: Jens Axboe Acked-by: Oleg Nesterov Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-4-8e4adb1619e6@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 388604279da3d0698a151efa4fb6d852efa0de4a Author: Zihan Xi Date: Thu Sep 24 05:15:21 2026 +0000 net: gso: limit recursive IP-in-IP segmentation commit 006c8b834aed8b02bd8fb9fb05e9e7ead37d1763 upstream. 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 [ Ting-Han: ipv6_gso_segment() still calls ipv6_hopopt_jumbo_remove() right after skb_reset_network_header() in this version; keep the new recursion check directly after skb_reset_network_header() as upstream does, before the jumbo removal ] Signed-off-by: Ting-Han Hou Signed-off-by: Greg Kroah-Hartman commit 06e816bed499fe47f39f12044382cc5d064485fb Author: Lee Jones Date: Mon Oct 19 12:07:29 2026 +0000 tracing/histograms: Verify event_call identity when updating synth_event refcount commit 3403d9bb27ebc3572bd048620746b4414e073bf9 upstream. In event_hist_trigger_parse() and hist_unreg_all(), the histogram registration and unregistration paths look up find_synth_event() using trace_event_name(file->event_call) and adjust se->ref if a match is found. Because find_synth_event() only compares the event basename, registering or removing a histogram on a non-synthetic trace event whose basename matches a synthetic event erroneously modifies the synthetic event's reference count. If a histogram is registered on the non-synthetic event before the synthetic event is created and removed afterwards, se->ref is decremented without a matching increment, allowing the synthetic event to be freed while an active histogram action still holds a pointer to it. Introduce find_synth_event_call() to verify that &se->call matches file->event_call before adjusting se->ref. Fixes: 4b147936fa50 ("tracing: Add support for 'synthetic' events") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261019120730.2342739-1-lee@kernel.org Signed-off-by: Lee Jones Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit a9c51d3b5311d4b880f903d71d13e69e64914cf0 Author: Donggeun Yoo Date: Thu Sep 17 10:55:32 2026 +0900 tracing: Fix 64-bit and signed histogram fields on 32-bit kernels commit 443d23176812803d0fa182b8d05ef066a7b8271f upstream. DEFINE_HIST_FIELD_FN() reads a trace event field and widens it to the u64 the histogram uses as a key or a value: type *addr = (type *)(event + hist_field->field->offset); return (u64)(unsigned long)*addr; unsigned long is 32 bits on a 32-bit kernel, so the intermediate cast discards the upper half of a 64-bit field, and widens a signed field by zero extension from 32 bits rather than sign extension from its own width. Five of the eight instantiations are wrong there: s64, u64, s32, s16 and s8. The cast came in with commit 79e577cbce4c ("tracing: Support string type key properly"), which also added hist_field_dynstring() and hist_field_pstring(). Those convert a char * to u64 and do warn without an unsigned long in between on 32-bit. DEFINE_HIST_FIELD_FN() converts an integer and never a pointer, so it gains nothing from the cast and only loses information. Drop the intermediate cast and let the usual arithmetic conversions widen *addr according to its own type. unsigned long is 64 bits on LP64, so the two forms are identical there and 64-bit kernels are unaffected. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260917015532.103081-1-donggeunyoo.kernel@gmail.com Fixes: 79e577cbce4c ("tracing: Support string type key properly") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260914054614.82A9B1F000FF@smtp.kernel.org/ Signed-off-by: Donggeun Yoo Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 431959fc76456cbba539279fe8967aa9391e6f23 Author: Donggeun Yoo Date: Mon Sep 14 19:40:36 2026 +0900 tracing: Unregister field variable histograms when the command fails commit 91c14d6c13096091c56304120aaa26e479130b8b upstream. An action that names a field on another event needs that field as a variable, so create_field_var_hist() registers a second hist trigger on that event to provide it, and records it in target_hist_data->field_var_hists[]. If a later part of the same command fails, create_actions() returns an error and event_hist_trigger_parse() jumps to out_free. The write fails with -EINVAL and sched_switch gets no trigger, but: # echo 'hist:keys=pid:ts0=common_timestamp.usecs' >> \ events/sched/sched_waking/trigger # echo 'my_synth u64 lat; int a; int b' >> synthetic_events # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0:\ onmatch(sched.sched_waking).my_synth($wakeup_lat,prio,nosuchfld)'\ >> events/sched/sched_switch/trigger # cat events/sched/sched_waking/trigger hist:keys=pid:vals=hitcount:ts0=common_timestamp.usecs:sort=hitcount:size=2048:clock=global [active] hist:keys=pid:vals=hitcount:synthetic_prio=prio:sort=hitcount:size=2048 [active] The second histogram is the one created for 'prio'. It is still active and still counting. out_free reaches destroy_field_var_hists(), which frees the field_var_hists[] entries, but never unregister_field_var_hists(), which is what removes the triggers and runs only from event_hist_trigger_free(). The entry is freed and the trigger is left with nothing tracking it. Unregister the field variable histograms in out_free as well, and record each one as soon as its trigger is registered rather than after the lookup that follows it, so no exit can leave a registered trigger untracked. The entry then belongs to field_var_hists[] and is released by destroy_field_var_hists(), so freeing it on that exit would be a double free. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914104036.1768529-1-donggeunyoo.kernel@gmail.com Fixes: 02205a6752f2 ("tracing: Add support for 'field variables'") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260913204302.DB2551F000FF@smtp.kernel.org/ Signed-off-by: Donggeun Yoo Assisted-by: Claude:claude-fable-5 Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 3609ada3c12cecfb0ae5ee82ef4f86c5f18a2dea Author: Donggeun Yoo Date: Tue Sep 15 08:47:54 2026 +0900 tracing: Save the event file instead of the compatible histogram commit d5c42664fc094899af9aae5300b27fe8fdb658ef upstream. create_field_var_hist() creates a histogram on the matched event to supply a field variable, and records it on the target so it can be torn down later: hist_data = find_compatible_hist(target_hist_data, file); ... /* Save the compatible histogram information */ var_hist->hist_data = hist_data; hist_data is not the histogram it creates. It is one that was already there, whose keys the new one copies. The saved pointer has a single user, unregister_field_var_hists(), which runs when the target is removed: file = hist_data->field_var_hists[i]->hist_data->event_file; find_compatible_hist() matches on keys alone, so it can pick one with no variables of its own. check_var_refs() then returns false and the user can remove it while the target still points at it: BUG: KASAN: slab-use-after-free in event_hist_trigger_free+0x2b2/0x320 Read of size 8 at addr ffff8880093b90e0 by task init/1 Freed by task 1: kfree+0x154/0x420 event_hist_trigger_free+0x1d5/0x320 event_hist_trigger_parse+0x35f3/0x69e0 trigger_process_regex+0x1a6/0x250 Save the event file instead. It is all the dereference ever wanted, and it does not go away when the user removes a trigger. Cc: stable@vger.kernel.org Reported-by: Sashiko Link: https://lore.kernel.org/all/20260914110753.221E61F000FF@smtp.kernel.org/ Link: https://patch.msgid.link/20260914234754.3676905-1-donggeunyoo.kernel@gmail.com Fixes: 02205a6752f2 ("tracing: Add support for 'field variables'") Signed-off-by: Donggeun Yoo Assisted-by: Claude:claude-fable-5 Acked-by: Tom Zanussi Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 1008e9e0b8280d47f1ab5e9c113f666a023a9697 Author: Kyle Zeng Date: Fri Oct 23 10:46:20 2026 -0700 tracing: Reject incomplete event filter expressions commit 1fdc4164e488916402badddbb1f51e9380dabb91 upstream. A non-empty expression normally finishes in predicate_parse()'s inner loop, which resolves the pending logical operators before jumping to finalization. If the input ends after an operator, possibly followed by unary '!' tokens, the outer loop instead falls through with unresolved operator state. For example, "common_pid == 1 || common_pid == 2 &&" leaves prog[0].target equal to -1. The second pass then reads prog[-1] before the forward-jump check can reject it. Depending on adjacent slab contents, it can also copy an out-of-bounds word into a branch target that passes the forward-only check. A self-targeted perf tracepoint counting event can reach this path through PERF_EVENT_IOC_SET_FILTER. Reject the outer-loop fallthrough when a predicate has already been parsed. This ensures that non-empty expressions only reach finalization after the inner loop has resolved their operators. Keep the existing no-filter error for input that has no predicates. Add a regression test for trailing logical operators and unary negations. Fixes: 80765597bc587 ("tracing: Rewrite filter logic to be simpler and faster") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261023174620.91969-1-kylebot@openai.com Assisted-by: Codex:gpt-6-astra Acked-by: Masami Hiramatsu (Google) Tested-by: JongHyuk Kim(MalHyuk) Signed-off-by: Kyle Zeng Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 92b69f6db640dadc0851762ee2e12db99f083cad Author: David Carlier Date: Fri Oct 16 07:16:35 2026 +0100 tracing: Hold trace_types_lock when resetting last boot data from readers commit 5a6bd62f09147b49b31fd19d4eba122cb5f941a1 upstream. update_last_data_if_empty() is called from tracing_open() with O_TRUNC, tracing_read_pipe() and tracing_buffers_read() without trace_types_lock. Two readers can both pass the LAST_BOOT test and free module_delta twice, and a module notifier can update module_delta while it is being freed. Take trace_types_lock in those paths and keep the callers that already hold it on an unlocked variant. Cc: stable@vger.kernel.org Fixes: 32dc0042528d ("tracing: Reset last-boot buffers when reading out all cpu buffers") Link: https://patch.msgid.link/20261016061638.214847-2-devnexen@gmail.com Signed-off-by: David Carlier Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 57408eac99b0d8a005796346d317d31f0ca4e07a Author: David Carlier Date: Fri Oct 16 07:16:34 2026 +0100 tracing: Hold trace_types_lock when updating modules in persistent instances commit 66877a312ae3c2c3d849e82e882f642ffd4ec3e2 upstream. trace_module_record() walks ftrace_trace_arrays from the module notifier without trace_types_lock. A concurrent rmdir of an instance removes it from the list and frees it under that lock, so a module load or unload can walk into a freed trace_array. Cc: stable@vger.kernel.org Fixes: 5f3719f697c3 ("tracing: Update modules to persistent instances when loaded") Link: https://patch.msgid.link/20261016061638.214847-1-devnexen@gmail.com Signed-off-by: David Carlier Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 10c705dd706aa93164ba41f2566f15206d6c178e Author: Pauli Virtanen Date: Wed Sep 2 00:04:36 2026 +0300 Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn [ Upstream commit 86b55991d3cd690e73c5ef8d20b75ae4905b357a ] l2cap_chan may be linked to l2cap_conn at most once. This is assumed in several places, eg l2cap_chan_del cleanup. There is a TOCTOU race where the invariant is violated: [Task 1] [Task 2] l2cap_chan_connect l2cap_sock_bind l2cap_chan_lock lock_sock l2cap_state_change if (sk->sk_state != BT_OPEN) chan->state = BT_CONNECT l2cap_sock_state_change_cb chan->state = BT_BOUND sk->sk_state = BT_BOUND lock_sock <------------------ release_sock sk->sk_state = BT_CONNECT l2cap_sock_connect() does not check sk->sk_state, so since chan->state is now BT_BOUND, subsequent connect() ends up with second __l2cap_chan_add. Explicitly document and check the invariant in __l2cap_chan_add with WARN_ON_ONCE. The only callsite where it could be hit is l2cap_chan_connect, so add pre-check there to avoid relying on chan->state. chan->state read/write is not properly guarded currently so there can be other TOCTOUC problems. Add l2cap_lock_chan in l2cap_sock_bind() to guard chan->state write. Fixes: b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") Assisted-by: deepseek-4-flash # finding the race condition Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 216a047d17b5cfdc00e6135a89c83af964344573 Author: Jonas Köppeler Date: Mon Mar 23 18:49:20 2026 +0100 net_sched: codel: fix stale state for empty flows in fq_codel [ Upstream commit 815980fe6dbb01ad4007e8b260a45617f598b76d ] When codel_dequeue() finds an empty queue, it resets vars->dropping but does not reset vars->first_above_time. The reference CoDel algorithm (Nichols & Jacobson, ACM Queue 2012) resets both: dodeque_result codel_queue_t::dodeque(time_t now) { ... if (r.p == NULL) { first_above_time = 0; // <-- Linux omits this } ... } Note that codel_should_drop() does reset first_above_time when called with a NULL skb, but codel_dequeue() returns early before ever calling codel_should_drop() in the empty-queue case. The post-drop code paths do reach codel_should_drop(NULL) and correctly reset the timer, so a dropped packet breaks the cycle -- but the next delivered packet re-arms first_above_time and the cycle repeats. For sparse flows such as ICMP ping (one packet every 200ms-1s), the first packet arms first_above_time, the flow goes empty, and the second packet arrives after the interval has elapsed and gets dropped. The pattern repeats, producing sustained loss on flows that are not actually congested. Test: veth pair, fq_codel, BQL disabled, 30000 iptables rules in the consumer namespace (NAPI-64 cycle ~14ms, well above fq_codel's 5ms target), ping at 5 pps under UDP flood: Before fix: 26% ping packet loss After fix: 0% ping packet loss Fix by resetting first_above_time to zero in the empty-queue path of codel_dequeue(), matching the reference algorithm. Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Fixes: d068ca2ae2e6 ("codel: split into multiple files") Co-developed-by: Jesper Dangaard Brouer Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Jonas Köppeler Reported-by: Chris Arges Tested-by: Jonas Köppeler Reviewed-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/all/20260318134826.1281205-7-hawk@kernel.org/ Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260323174920.253526-1-hawk@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d5482be6243b816730689099c017109eb8730dd5 Author: SJ Park Date: Mon Oct 26 06:47:39 2026 -0700 mm/damon/core: error damos_commit_quota_goal() for zero target_value [ Upstream commit 610c4438fb66e06d9e693c0ad3b2c1be54c0d61f ] Patch series "mm/damon: move zero damos quota target_value handling to the core layer". Having zero DAMOS quota target value can cause division by zero. DAMON API callers are checking the target value parameters to avoid that. It is easy to make mistakes in some of the multiple API callers. Move that to the core layer. Patch 1 adds the corner case handling into the core layer DAMON parameters validation logic. Patches 2 and 3 remove no more needed DAMON API callers side handling of the corner case in DAMON_LRU_SORT and DMON_SAMPLIE_MTIER, respectively. This patch (of 3): If a DAMOS scheme has a damos_quota_goal of zero target_value, damos_quota_goal() could trigger division-by-zero error. Hence each DAMON API callers should do the zero target_value validation. It is easy to make mistakes. Actually such bugs in DAMON_LRU_SORT and DAMON_SAMPLE_MTIER were found and fixed [1]. It is better to handle the corner case only once in the core layer, instead of multiple places in all DAMON API callers. One straightforward option is using an alternative denominator for the corner case in the damos_quota_goal(). However, the zero target_value is meaningless. In this case, the quota goal is always evaluated as achieved or over-achieved. The quota will only keep being reduced. Simply avoid using zero target_value by adding a check in the core layer DAMOS quota goal parameters validation/commit path, damos_commit_quota_goal(). Update it to return an error in the case. Also update its caller to propagate the error. Notes for stable kernel porting. The upstream commit doesn't have Fixes: and therefore not ported to stable kernels. It turned out it fixes commit 8b549a4fd3c5 ("mm/damon/sysfs-schemes: commit damos quota goals user input to DAMOS") which was merged into v6.8. The user impact is a race condition that can result in divide-by-zero. Hence backport. Reproducing the issue requires sysfs write permission, certain DAMON ABI usages that are supposed to be uncommon, and a rare race timing, though. The issue was discovered [2] by Sashiko as a part [3] of its bug report. Also, the upstream commit on this stable kernel can fix the issue for parameters commit paths but DAMON start path. That's because DAMON start path does not invoke damon_commit_quota_goals(). To fix the path with minimum change, add a new small validation of quota goal target value before damon_start() call. [2] https://sashiko.dev/#/bug/linux-7f814c9a-986f-4103-a55a-ef9537dcf62b [3] https://lore.kernel.org/20261021005234.94107-1-sj@kernel.org Link: https://lore.kernel.org/20260903010722.94244-1-sj@kernel.org Link: https://lore.kernel.org/20260903010722.94244-2-sj@kernel.org Link: https://lore.kernel.org/20260803134034.15217-1-sj@kernel.org [1] Signed-off-by: SJ Park Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Sasha Levin commit ce68b7a19a23c2c20b39452d4a35521744cdd023 Author: Damien Le Moal Date: Sun Oct 25 14:09:14 2026 +0800 block: avoid potential deadlock on zone revalidation failure commit 3dd63dba8f9cb6990a40af7ed66ee0159f475819 upstream. If revalidating the zones of a zoned block device with blk_revalidate_disk_zones() fails during a SCSI disk rescan, the following lockdep splat is thrown: [ 347.251859] [ T11230] sda: failed to revalidate zones [ 347.261380] [ T11230] ====================================================== [ 347.263882] [ T11230] WARNING: possible circular locking dependency detected [ 347.266353] [ T11230] 7.1.0+ #1194 Not tainted [ 347.268052] [ T11230] ------------------------------------------------------ [ 347.270537] [ T11230] tcsh/11230 is trying to acquire lock: [ 347.272555] [ T11230] ffffffff8f91d400 (wq_pool_mutex){+.+.}-{4:4}, at: destroy_workqueue+0x15d/0x8d0 [ 347.275914] [ T11230] but task is already holding lock: [ 347.278646] [ T11230] ffff88812fa1bcc0 (&q->q_usage_counter(io)#5){++++}-{0:0}, at: blk_mq_freeze_queue_nomemsave+0x16/0x30 [ 347.282503] [ T11230] which lock already depends on the new lock. [ 347.286239] [ T11230] the existing dependency chain (in reverse order) is: [ 347.289408] [ T11230] -> #2 (&q->q_usage_counter(io)#5){++++}-{0:0}: [ 347.292437] [ T11230] blk_alloc_queue+0x5ca/0x750 [ 347.294379] [ T11230] blk_mq_alloc_queue+0x14c/0x240 [ 347.296375] [ T11230] scsi_alloc_sdev+0x871/0xd10 [scsi_mod] [ 347.298619] [ T11230] scsi_probe_and_add_lun+0x600/0xc50 [scsi_mod] [ 347.301056] [ T11230] __scsi_scan_target+0x187/0x3b0 [scsi_mod] [ 347.303385] [ T11230] scsi_scan_channel+0xf2/0x180 [scsi_mod] [ 347.305651] [ T11230] scsi_scan_host_selected+0x20b/0x2d0 [scsi_mod] [ 347.308119] [ T11230] do_scan_async+0x42/0x420 [scsi_mod] [ 347.310276] [ T11230] async_run_entry_fn+0x94/0x5a0 [ 347.312284] [ T11230] process_one_work+0x8da/0x1690 [ 347.314287] [ T11230] worker_thread+0x5fe/0x1010 [ 347.316216] [ T11230] kthread+0x358/0x450 [ 347.317675] [ T11230] ret_from_fork+0x5b9/0x8e0 [ 347.319181] [ T11230] ret_from_fork_asm+0x11/0x20 [ 347.320778] [ T11230] -> #1 (fs_reclaim){+.+.}-{0:0}: [ 347.322890] [ T11230] fs_reclaim_acquire+0xd5/0x120 [ 347.324464] [ T11230] __kmalloc_cache_node_noprof+0x39/0x620 [ 347.326223] [ T11230] init_rescuer+0x19b/0x560 [ 347.327697] [ T11230] workqueue_init+0x33b/0x6a0 [ 347.329224] [ T11230] kernel_init_freeable+0x2eb/0x600 [ 347.330881] [ T11230] kernel_init+0x1c/0x140 [ 347.332334] [ T11230] ret_from_fork+0x5b9/0x8e0 [ 347.333847] [ T11230] ret_from_fork_asm+0x11/0x20 [ 347.335360] [ T11230] -> #0 (wq_pool_mutex){+.+.}-{4:4}: [ 347.337510] [ T11230] __lock_acquire+0xdea/0x2260 [ 347.339030] [ T11230] lock_acquire+0x187/0x2f0 [ 347.340495] [ T11230] __mutex_lock+0x1ab/0x2600 [ 347.341464] [ T11230] destroy_workqueue+0x15d/0x8d0 [ 347.342485] [ T11230] disk_free_zone_resources+0xd5/0x560 [ 347.343577] [ T11230] blk_revalidate_disk_zones+0x620/0xac7 [ 347.344723] [ T11230] sd_zbc_revalidate_zones+0x1dd/0x790 [sd_mod] [ 347.345938] [ T11230] sd_revalidate_disk+0xc66/0x8e60 [sd_mod] [ 347.347112] [ T11230] scsi_rescan_device+0x1f9/0x310 [scsi_mod] [ 347.348318] [ T11230] store_rescan_field+0x19/0x20 [scsi_mod] [ 347.349507] [ T11230] kernfs_fop_write_iter+0x3d2/0x5e0 [ 347.350565] [ T11230] vfs_write+0x469/0x1000 [ 347.351484] [ T11230] ksys_write+0x116/0x250 [ 347.352403] [ T11230] do_syscall_64+0xf0/0x6e0 [ 347.353361] [ T11230] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 347.354533] [ T11230] other info that might help us debug this: [ 347.356432] [ T11230] Chain exists of: wq_pool_mutex --> fs_reclaim --> &q->q_usage_counter(io)#5 [ 347.358919] [ T11230] Possible unsafe locking scenario: [ 347.360307] [ T11230] CPU0 CPU1 [ 347.361327] [ T11230] ---- ---- [ 347.362340] [ T11230] lock(&q->q_usage_counter(io)#5); [ 347.363344] [ T11230] lock(fs_reclaim); [ 347.364526] [ T11230] lock(&q->q_usage_counter(io)#5); [ 347.365968] [ T11230] lock(wq_pool_mutex); [ 347.366811] [ T11230] *** DEADLOCK *** This happens because SCSI disk rescan is executed from a work context and a failure of blk_revalidate_disk_zones() causes a call to disk_free_zone_resources() which will free the disk zone write plug workqueue. Avoid this by delaying the destruction of the disk zone write plug workqueue to disk_release(). Do this by introducing the function disk_release_zone_resources() and using this new function from disk_release(). This new function destroys the zone write plugs workqueue and calls disk_free_zone_resources(), thus allowing to remove the call to destroy_workqueue() from disk_free_zone_resources(). disk_alloc_zone_resources() is modified to not create the disk zone write plug work queue if it already exists. Fixes: a8f59e5a5dea ("block: use a per disk workqueue for zone write plugging") Cc: stable@vger.kernek.org Signed-off-by: Damien Le Moal Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260701082155.1369996-1-dlemoal@kernel.org Signed-off-by: Jens Axboe [ stanleyjhu: 6.18.y has no zone write plug kthread worker and does not use WQ_PERCPU, so only the workqueue part applies: disk_alloc_zone_resources() reuses an existing workqueue, disk_free_zone_resources() drains it instead of destroying it, and the new disk_release_zone_resources() destroys it from disk_release(). ] Signed-off-by: Stanley Jhu Signed-off-by: Sasha Levin commit 50a4c00511cf6bae2fd90c173065348b0a535c34 Author: Bernard Pidoux Date: Fri Oct 2 14:37:30 2026 +0200 ax25: don't free an incoming SABM skb left on the listener's queue When a SABM comes in for a listening socket, ax25_rcv() creates the new socket, puts the skb on the listener's receive queue and only then allocates the digipeater path. If that allocation fails, the skb is freed with kfree_skb() while it is still linked on the queue, and the accept backlog count taken by sk_acceptq_added() is never given back. The next accept() or the close of the listener then walks a queue that contains a freed skb. Allocate the path before the skb is queued, so that the error path only has to free an skb nobody else knows about and to destroy the new socket. The later allocation remains for a connection that has no listening socket. Only reachable when the atomic allocation fails for a call that comes through digipeaters. Regression tested in QEMU (6.12.94 with lockdep and KASAN): 14 incoming connections to a listening socket, each accepted, served and closed, before and after; no report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux (cherry picked from commit 2d67e8e9f3d627327114fb946c3a28ef72becb2d) Signed-off-by: Sasha Levin commit 422548da8d1a566b7c13176088cfcb95bb8282c3 Author: Bernard Pidoux Date: Sat Oct 10 12:57:44 2026 +0200 rose: bring up the link of the preferred route passed over by a connect request For a connect request rose_get_neigh() walks the routes that match the address, from the most specific to the least specific, and takes the first neighbour whose link is restarted. A neighbour whose link is down is only used when no matching route at all has a restarted neighbour. A node that has both an exact route to a neighbouring node and a wide route through a relay therefore never uses the exact route once its link is down: the relay is restarted, it is always found first, and since no frame is ever sent over the direct link nothing brings it up again. The calls keep going through the relay, which may have no route other than back to the calling node and then clears them. Seen on a node whose White Pages daemon calls an adjacent node: every call goes to the relay and comes back as CLEAR REQUEST "not obtainable", for as long as the node runs. Keep sending the call to the restarted neighbour, so that a call never waits for a link that may not answer, but when a neighbour of a more specific route, or an earlier neighbour of the same route, was passed over because its link is down, start the restart procedure on that link. If the other end answers, the next call finds the link restarted and uses it. A link that has just failed is left alone for link_fail_timeout, and nothing is done while a restart is under way. Frames in transit are handled as before. Tested in QEMU with a lockdep and KASAN kernel, three nodes A - B - C where B has an exact route to C over their direct link and a wide route through A, and the link B - A is restarted while B - C is not. Before, every call from B to C goes to A and is cleared there, and the direct link stays down. After, the first call still goes to A, the direct link is restarted within 20 ms and the following calls go through it. With C switched off no call waits: they all go to A at once, the restart is attempted once, and after the AX.25 connection gives up the link is left alone for link_fail_timeout. A call from A to C in transit through B gets the same answer before and after. No lockdep, KASAN or refcount report. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Bernard Pidoux (cherry picked from commit cdf5a2eba2bc4f79dabb013a3a935f54aedb85e9) Signed-off-by: Sasha Levin commit e1765e170a0889e5944315f515b391504a7eb552 Author: Bernard Pidoux Date: Thu Oct 8 15:09:05 2026 +0200 ax25: send unacknowledged I frames again when a link is re-established When a connection goes back through state 1 from state 3 or 4 (invalid N(R), FRMR, illegal frame), the UA that re-establishes it resets V(S), V(A) and V(R) but leaves the I frames that were waiting for their acknowledgment in the ack queue. From then on every acknowledgment frees the frame at the head of the queue, an old one, instead of the one it is for, so the queue keeps that many frames too many for ever: - they stay charged to the socket that sent them, whose send memory is never given back; - they are sent again by the next go-back-N, long after the event, and the peer gets duplicates; - they were not sent again when the link came back, so the layer above lost them. Seen on a live ROSE node: an AX.25 connection in state 3 with V(S) == V(A), empty write queue and 18 frames in its ack queue, and the ROSE sockets using it showing a send queue that never drains. Requeue those frames when the UA is received, as is already done when the peer resets the link with a SABM in state 3 or 4. Same change in the DAMA slave state machine. Like that existing path, this can send again a frame that the peer had received just before the reset: AX.25 has no way to know. The layer above sees a duplicate instead of a silent loss. ROSE drops an exact duplicate, but resets the circuit when the replayed frame carries an N(R) that is no longer valid. On the nodes below those resets came with link re-establishments caused by a late N(R), which "ax25: send a private copy of each I frame" removes: with both patches the node that is instrumented saw no re-establishment and no reset in 49 hours, against five resets in the 47 hours before. Tested in QEMU (6.12.94 with lockdep and KASAN), two nodes over a mkiss serial link, one ROSE circuit, 40 messages 150 ms apart, the link forced through state 1 three times by an injected FRMR. Before: 6 runs of 6 deliver 40/40 and leave one frame in the ack queue, the ROSE socket keeps 960 bytes of send memory. After: 6 of 6 deliver 40/40 and the send memory goes back to zero. No lockdep, KASAN or refcount report. On four production nodes since 3 October 2026, six since 6 October. A relay node that had 18 to 20 such frames on one link is sampled every hour: 124 samples and 1301 link states in five days, none with a frame left in an ack queue. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 7b22827cb729de19ccba284ebaff3eeee21d4f11) Signed-off-by: Sasha Levin commit 26c0952ba226726b5fca4a33c91bc675e352284c Author: Bernard Pidoux Date: Wed Oct 7 15:26:50 2026 +0200 rose: clear the circuits of a neighbour that restarts the link A Restart Request is the X.25 way to say that every virtual circuit of a link is gone. rose_link_rx_restart() only marks the neighbour as restarted and answers with a Restart Confirmation: the sockets and the through routes that used the link are left as they were. That is harmless on a link coming up, nothing is established yet. It is not when the other end restarts its AX.25 and ROSE stack while we keep the link: the first thing it sends is a SABM, which resets our AX.25 connection without bringing it down, then a Restart Request. Its circuits are gone, ours stay in state 3 forever: - a frame for a logical channel that the other end does not know is dropped silently by rose_route_frame(), so no Clear Request ever comes back; - no timer watches the acknowledgement of data in state 3, and the idle timer is off by default; - the through routes stay in /proc/net/rose_routes and the remote ends of those calls are never told. The stale entries are not just a leak. The restarted end allocates its logical channel numbers afresh, so a new circuit can get the number of a stale through route on the same link, and whatever still arrives on the stale half is then relayed into the new circuit. Seen on a live network: a node that restarts its stack from cron left, on each of three neighbours, a data circuit with five unacknowledged frames that never moved again, and five through routes on the node that relays for the others. Clear them when a Restart Request arrives on a link that is already up: send a Clear Request to the other half of each through route and drop the route, and disconnect the local sockets, as rose_link_failed() does when the link goes down. The loop of rose_del_route_by_neigh() is moved to a helper for that, since the caller here already holds rose_route_list_lock. Nothing is sent to the restarting neighbour: it has no circuit left, and a Clear Request could hit a call it has just placed on a reused channel number. A link that is not up yet is left alone: nothing can be established over it, and the sockets found there are calls waiting in neigh->queue for the restart to complete. Tested with three QEMU guests in a line, A - B - C, on a kernel with lockdep and KASAN. A calls C through B and B calls C, both circuits stay open, then C destroys and recreates its AX.25 interface, reloads its routes and calls B. Before: both circuits are still open a minute later, B keeps the through route, nobody is told. After: A and B get the circuit cleared (cause 0x09) within a second of the Restart Request, B has no through route left, and the new call from C goes through at the first attempt. Four runs, no lockdep, KASAN or refcount report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 34de1b990c7c690c19594a49ee5b9a74883baf2b) Signed-off-by: Sasha Levin commit d5189ba8534316dc16136f2d12a9fcaa9ed29e7b Author: Bernard Pidoux Date: Tue Oct 6 13:20:51 2026 +0200 ax25: send a private copy of each I frame ax25_kick() keeps every I frame on the ack queue until it is acknowledged and hands a clone of it to the device. After a REJ or a T1 timeout the frame goes back to the write queue and ax25_kick() clones it again. A clone shares its data with the original, so ax25_send_iframe() and ax25_transmit_buffer() write the control field and the address header of the new clone in the very bytes used by the previous one. If the previous clone is still waiting in the device queue, its control field is rewritten there: it leaves with the N(R) current at the time of the retransmission, not the one it was sent with. Frames queued behind it, an RR for instance, were built in between with a lower N(R). The peer then receives an N(R) lower than one it has already been given. ax25_validate_nr() rejects it and ax25_std_nr_error_recovery() resets the link with a SABM, in the middle of a transfer. The layers above pay for it: on a ROSE circuit, the frames replayed after the reset carry stale sequence numbers and the circuit is reset as well, with loss of data. Hand a private copy to the device instead. The frames are small (256 bytes of data by default) and the link is slow, the extra copy is not measurable. Found on a test bench: two virtual machines with four CPUs each, a 6.12.94 kernel with KASAN and lockdep, one ROSE circuit over an AX.25 link on a serial line (mkiss), 192 messages each way in bursts of 24, and three REJ frames injected by one side. Instrumentation showed that frames reached the driver in the order they were given to dev_queue_xmit(), that V(R) never went backwards on the sender, and that the driver nevertheless saw frames whose N(R) was lower than the one before. Counting, on the receiver, the frames whose N(R) is lower than the previous one: - this code plus the two pending AX.25 fixes used on the bench (REJ guard, requeue on re-establishment): 4 runs, 13 such frames, 4 link resets; with this patch: 6 runs, none, no link reset; - the same with the transmit serialisation patches for AX.25 and ROSE on top: link resets in most runs before; with this patch: 6 runs, none, no link reset, no ROSE reset, 192/192 messages both ways in every run. Signed-off-by: Bernard Pidoux Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 1b464137f3173fadf81a7a1bf4a9584ebaf72c7b) Signed-off-by: Sasha Levin commit f44808ff191c26e7e6c208c2832645de5e2268d5 Author: Bernard Pidoux Date: Tue Oct 6 01:28:14 2026 +0200 ax25: don't accept frames on a device that is going down ax25_rcv() creates a connection on an incoming SABM, for a listening socket or for a callsign registered by ROSE or NET/ROM. Like the ones made by ax25_send_frame(), it holds no reference on the ax25_dev and relies on ax25_kill_by_device() to detach it before the ax25_dev is freed. If it is added to ax25_list after ax25_kill_by_device() has walked the list, it is left pointing to a freed ax25_dev. ax25_rcv() is called from the packet type handler, under rcu_read_lock(), and ax25_kill_by_device() now clears device_up and waits for the RCU readers before its walk. Drop the frame when device_up is clear: a frame that gets past the test is fully processed before the walk starts, and none is processed behind it. The window is much smaller than for ax25_send_frame(): the core already drops what is received on a device that is no longer running, so only a frame that was queued before the device was stopped and is processed late can hit it. I could not exercise it. The change was checked for regressions only: incoming connections still work in the ROSE tests of the previous patch, where every AX.25 link is opened by an incoming SABM on one side. Signed-off-by: Bernard Pidoux Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 748551f72b27325043eafe969311b15ae1eb0c7c) Signed-off-by: Sasha Levin commit d046414d590092d38ecc1292261ca1f922600a0c Author: Bernard Pidoux Date: Tue Oct 6 01:28:14 2026 +0200 ax25: wait for ax25_send_frame() before detaching the connections of a device A connection created by ax25_send_frame(), for ROSE, NET/ROM or IP over AX.25, points to the ax25_dev of its device without holding a reference on it. It relies on ax25_kill_by_device() to detach it when the device goes down, before ax25_dev_device_down() frees the ax25_dev. On NETDEV_DOWN the two run one after the other. In between, the ax25_dev is still on ax25_dev_list, so ax25_send_frame() still finds it, creates a connection and adds it to ax25_list after ax25_kill_by_device() has finished walking that list. The connection is left with a pointer to an ax25_dev that is freed a moment later, which ax25_find_cb() and the AX.25 timers then dereference: BUG: KASAN: slab-use-after-free in ax25_find_cb+0x2ed/0x330 [ax25] Read of size 8 at addr ffff8880031e8c10 by task repro/3287 ax25_find_cb+0x2ed/0x330 [ax25] rose_transmit_link+0xea/0x560 [rose] rose_write_internal+0x3ab/0x15b0 [rose] rose_release+0x2b2/0x4b0 [rose] Allocated by: ax25_dev_device_up, ax25_device_event Freed by: kfree_rcu_monitor, queued from ax25_device_event The buggy address is located 16 bytes inside of freed 256-byte region, cache kmalloc-256 This is the trace of the syzbot report below. An earlier commit, "rose: use timer_shutdown_sync() for t0timer teardown", attributed that report to the ROSE t0 timer; the freed object in the report is the ax25_dev, as it is here. A connection that is on the list in time is not safe either while it is still being set up: ax25_kill_by_device() can detach it, clearing its ax25_dev pointer, between the moment ax25_send_frame() adds it and the moment it starts the link and queues the frame, which then dereference NULL. Make the two exclude each other with RCU. ax25_send_frame() now runs entirely under rcu_read_lock() and gives up when the device is no longer marked up. ax25_kill_by_device() clears device_up and calls synchronize_rcu() before it walks the list: once that returns, every connection ax25_send_frame() was working on is complete and on the list, and no new one can appear behind the walk. This adds one RCU grace period to taking an AX.25 interface down. Tested on 6.12.94 with KASAN and lockdep, with the modules of this tree and the rest of this series: - with a 100 ms delay inserted between ax25_kill_by_device() and ax25_dev_device_down(), a single "ifconfig bpq0 down" during eight ROSE call requests left connections on the list and ended in a use-after-free in ax25_heartbeat_expiry(); with the series the list is empty after the down and there is no report; - the syzbot C reproducer, with the interface brought up again in a loop, caused 217 KASAN reports and a panic after 41 seconds; with the series it ran for 600 seconds without any report; - 60 plain "ifconfig bpq0 down" / "up" under 20 ROSE call requests per second, and a ROSE call through a three node chain over mkiss, behave as before; - eight ROSE calls started at the same instant still end up on a single AX.25 connection. Reported-by: syzbot+caa052a0958a9146870d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=caa052a0958a9146870d Signed-off-by: Bernard Pidoux Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 45071a40f7d5db10350dbd177decd3f68fdaaa01) Signed-off-by: Sasha Levin commit 08690ab94ca8874f2ff088b247f01b512ecdaae8 Author: Bernard Pidoux Date: Tue Oct 6 01:28:14 2026 +0200 ax25: read the connection's ax25_dev only once when walking ax25_list ax25_kill_by_device() detaches a connection from a device that goes down by setting s->ax25_dev to NULL. It does so after it has dropped ax25_list_lock, while the connection is still on ax25_list. __ax25_find_cb() and ax25_find_listener() walk that list and test s->ax25_dev against NULL before they dereference it, but they load the pointer a second time for the dereference. ax25_send_to_raw() dereferences it without any test. If ax25_kill_by_device() clears the pointer in between, the walker dereferences NULL: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:ax25_find_cb+0x121/0x330 [ax25] ax25_send_frame+0xdc/0x980 [ax25] rose_send_frame+0xce/0x270 [rose] rose_transmit_restart_request+0x1b3/0x260 [rose] rose_transmit_link+0x31d/0x560 [rose] rose_write_internal+0x3ab/0x15b0 [rose] rose_release+0x2b2/0x4b0 [rose] Load the pointer once in the three walkers and use that value, and add the missing NULL test to ax25_send_to_raw(). The ax25_dev itself cannot go away under the walker: ax25_kill_by_device() has to take ax25_list_lock again, in ax25_cb_del(), before the device teardown gets as far as freeing it. The oops above was obtained on 6.12.94 with KASAN, after 382 seconds of the syzbot C reproducer of the ax25_find_cb() use-after-free report, with the interface brought up again in a loop, while testing an earlier version of the next patch. With this series the same test runs for 600 seconds without an oops. Signed-off-by: Bernard Pidoux Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 3696f3cf8690e335a2cc7e8103f018bc205de738) Signed-off-by: Sasha Levin commit 56165cd0710cde822253365ca8c6ef4ddfa68345 Author: Bernard Pidoux Date: Fri Oct 2 15:04:48 2026 +0200 ax25: don't create two connections for the same link in ax25_send_frame() ax25_send_frame() looks for an existing connection with ax25_find_cb() and, when there is none, creates one and adds it to the list. The lookup and the insertion are not done under the same lock, so two callers sending to a neighbour at the same time both find nothing and both create a control block: the same link ends up with several connections, each sending its own SABM, and the frames queued on the ones that lose are never delivered. ROSE and NET/ROM call ax25_send_frame() for every frame they send to a neighbour, from process context and from softirq context, so this happens as soon as several circuits start together on a link that is not established yet. Add ax25_cb_add_unique(), which searches the list and inserts the new control block under ax25_list_lock, and returns the existing connection when another sender got there first; ax25_send_frame() then drops its own control block and queues the frame on that connection. The SABM is only sent once the control block is known to be the one in the list. Tested in QEMU, two 4-CPU nodes with lockdep and KASAN over a KISS serial link, eight ROSE calls started at the same instant with no AX.25 connection up: before, /proc/net/ax25 shows four connections for the same pair of callsigns on three runs out of three; after, one. No lockdep, KASAN or refcount report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux (cherry picked from commit 2649f91b6dd2c48348975d03e8f94d8e6a09cf71) Signed-off-by: Sasha Levin commit 515efcc5aacca0c8a5be83bf6bf9412d843d7651 Author: Bernard Pidoux Date: Thu Oct 1 14:07:23 2026 +0200 rose: process received frames and send with the socket locked rose_kick() takes frames off the write queue, numbers them from V(S) and moves them to the ack queue. It runs from rose_sendmsg() in process context and from rose_process_rx_frame() in softirq context, and neither holds the socket lock. When a frame for the socket is received on one CPU while a process is sending on another, both read the same V(S) and two different frames go out under the same N(S), or the queues and V(S)/V(A) are updated by one while the other walks them. The peer drops the frames it sees as out of sequence, and since ROSE has no REJ and no retransmission in state 3 the data is lost for good: messages go missing from the stream, or the window fills and the circuit freezes. The timers already take the socket lock and retry when a process owns it. Do the same for the two remaining paths: rose_sendmsg() calls rose_kick() under lock_sock(), and received frames go through rose_rcv_frame(), which takes bh_lock_sock() and queues the frame on the socket backlog when a process owns the socket, as NET/ROM and X.25 do. Tested in QEMU, two 4-CPU nodes with lockdep and KASAN over a KISS serial link, four ROSE circuits each sending 400 numbered messages at the same time (together with the AX.25 fix "ax25: serialise the transmission of I frames on a connection", without which the same happens one layer down): before, 60 to 90 of the 1600 messages are missing from the streams; after, 1600/1600 delivered in order on six runs out of six. No lockdep, KASAN or refcount report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux (cherry picked from commit 831b23b977e1fdf14e51dd9652fd27f30965ecb0) Signed-off-by: Sasha Levin commit ccf05d51014e85f90c00e859a28d6e1eed5358aa Author: Bernard Pidoux Date: Thu Oct 1 14:07:43 2026 +0200 ax25: serialise the transmission of I frames on a connection ax25_kick() takes frames off the write queue, numbers them from V(S) and moves them to the ack queue, with no lock. It is called from process context by the senders (ax25_output()) and from softirq context by the receive path and the timers. A connection used by ROSE or NET/ROM carries several circuits, so ax25_output() can run for the same connection on two CPUs at once, and against the receive path. Both then read the same V(S) and two different I frames are sent under the same N(S). The peer keeps the first and rejects the second; the go-back-N that follows resends whatever the ack queue holds for that number, and one of the two frames is never sent again while the AX.25 counters look consistent on both sides. The layer above sees a hole: a ROSE circuit receives its frames out of sequence, ignores them, and stays frozen with its window full. Seen on a live ROSE node relaying several circuits over one AX.25 link: fm F6BVP-9 to F6BVP-13 ctl I55^ pid=1(X.25) len 254 LCI 030 DATA S2 fm F6BVP-9 to F6BVP-13 ctl I55^ pid=1(X.25) len 254 LCI 02E DATA S2 fm F6BVP-13 to F6BVP-9 ctl REJ6v Add a lock to the ax25_cb covering V(S), V(A) and the write and ack queues, taken in ax25_kick(), ax25_frames_acked() and ax25_requeue_frames(). The frames are not sent with the lock held, since ax25_transmit_buffer() may end up in ax25_disconnect(): ax25_kick() puts the numbered frames on a transmit queue which is emptied, in order, by one context at a time once the lock is dropped. Tested in QEMU, two 4-CPU nodes with lockdep and KASAN over a KISS serial link, four ROSE circuits each sending 400 numbered messages at the same time: before, every circuit freezes and 300 to 600 of the 1600 messages get through; after, no sender is blocked and more than 1500 get through (the ROSE side needs "rose: process received frames and send with the socket locked" for the rest: 1600/1600 in order on six runs out of six with both). No lockdep, KASAN or refcount report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") [F6BVP: v2: in ax25_frames_acked(), loop on what skb_dequeue() returns instead of on skb_peek(): ax25_clear_queues() purges the ack queue without ax25->lock, so skb_dequeue() could return NULL and __skb_queue_tail() dereference it in softirq context (reported by Sasha Levin). Same fix submitted to mod-orphan.] Signed-off-by: Bernard Pidoux (cherry picked from commit 3f42b974059565c9e60229a9ff1ca21d10334671) Signed-off-by: Sasha Levin commit d43478056d6f2433803f0eebc6bdbe3138cf5737 Author: Bernard Pidoux Date: Thu Oct 1 12:00:15 2026 +0200 rose: restart the link of a neighbour created over a live AX.25 connection A new neighbour starts with restarted == 0 and waits for the first frame sent to it to start the restart procedure. But when a neighbour is removed from the routing tables and added back (SIOCDELRT then SIOCADDRT, or SIOCRSCLRRT followed by a reload of the routes), the AX.25 connection to it outlives the old entry. The other end has seen nothing: it still regards the link as restarted and will not restart it. On this end rose_get_neigh() only hands out restarted neighbours to through calls, so no frame is ever sent to the new neighbour and nothing starts the restart either. Every call relayed through that neighbour is then refused until one of the two ends happens to originate a call of its own over the link, or the AX.25 connection drops. This happens on a relay node each time its routing daemon restarts: FPAC clears and reloads the routes, the neighbours come back as "restart no" while /proc/net/ax25 still shows their connections established. When rose_add_node() creates a neighbour and an AX.25 connection to it already exists, send the RESTART REQUEST right away and start T0, as rose_transmit_link() does for the first frame. Nothing changes when there is no connection yet: the link is still brought up on demand. Tested in QEMU with a lockdep and KASAN kernel, three nodes A - B - C with A calling C through B, then B removing and re-adding its route to C (or clearing and reloading all its routes): before, the neighbour stays "restart no" on B and A's calls to C are refused for as long as the test runs; after, the neighbour is restarted within three seconds and the first call goes through. No lockdep, KASAN or refcount report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux (cherry picked from commit 411b950c8862277a53f4afc6c6c5b3ab00b814be) Signed-off-by: Sasha Levin commit 1e3cba409644246d91e2b90d67b154b606a5ff3e Author: Bernard Pidoux Date: Wed Sep 30 16:59:45 2026 +0200 rose: clear through routes when a neighbour is removed from the tables When the last route using a neighbour is deleted (SIOCDELRT) or all routes are cleared (SIOCRSCLRRT), rose_del_node() and rose_clear_routes() take the neighbour out of rose_neigh_list, but the through routes in rose_route_list that still use it are left alone. No frame can reach them any more, so they stay in the table for ever, holding their neighbour references, and neither end of the relayed connection is told: the caller and the called station keep a circuit that goes nowhere. rose_clear_routes() even says it keeps neighbours with active connections, which it does not. This shows up on every node that relays traffic when its routing daemon restarts: FPAC clears and reloads the routes, the neighbours are recreated under new numbers, and the old through routes remain listed with neighbours that no longer exist. Clear them when the neighbour is removed, as rose_link_failed() does when a link fails, but send the CLEAR to both halves since the removed neighbour's link may still be up, and cut the local connections using it. rose_route_list_lock is taken under rose_node_list_lock and rose_neigh_list_lock, the order rose_route_frame() and rose_link_failed() already use. Tested in QEMU with a lockdep and KASAN kernel, three nodes A - B - C with A calling C through B: before, the through route stays on B after SIOCDELRT or SIOCRSCLRRT and A is never told; after, the entry is gone and both A and C get a CLEAR (cause 0x09) within a second. No lockdep, KASAN or refcount report. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux (cherry picked from commit 065ae03f519c147d5ee7b87acb2d21fe93ae0007) Signed-off-by: Sasha Levin commit d834cb9b9ce7eb67db126206e156090de7cd3fe4 Author: Bernard Pidoux Date: Sat Sep 26 11:56:18 2026 +0200 netrom: fix nr_node leak when nr_del_node() removes the last route nr_del_node() takes a reference on the node with its lookup. When the route it deletes is not the last one, it drops that reference before returning. When it is the last one, it only unlinks the node with nr_remove_node_locked(), which drops the list's reference, and returns still holding its own: the unlinked node is never freed. Seen with kmemleak on a live node after adding and then deleting a route to a dummy node with nrparms (SIOCADDRT then SIOCDELRT): the 96-byte nr_node allocated by nr_add_node(), callsign and mnemonic of the dummy node in its hex dump, is reported as unreferenced. Drop the lookup reference in both cases. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux (cherry picked from commit a4b96115783fdefae9599f9a84a39e24fb288d6b) Signed-off-by: Sasha Levin commit f026224d03017f49ce797c83e49f794cf6dce045 Author: Bernard Pidoux Date: Sat Sep 26 11:34:02 2026 +0200 netrom: clear nr_neigh->ax25 under the routing lock in nr_link_failed() nr_route_frame() swaps nr_neigh->ax25 for the ax25_cb returned by ax25_send_frame() and puts the old one while holding nr_route_lock. nr_link_failed(), called by AX.25 when that link fails, looks the neighbour up under the lock but then clears nr_neigh->ax25, puts the ax25_cb and bumps nr_neigh->failed after dropping it. If a frame is routed to the same neighbour at that moment, both paths can see the same ax25_cb and put it twice. Do the whole of nr_link_failed() in one critical section. The neighbour no longer needs a temporary reference, since it cannot be unlinked while the lock is held. This depends on "netrom: use a single lock for the node and neighbour lists". Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux (cherry picked from commit 6e6f80bff5c901f317c3750cdf375766800ecc1a) Signed-off-by: Sasha Levin commit 9e08bc699bde7230e8ad5291c3382a6d6c5a11ba Author: Junjie Cao Date: Sat Sep 26 11:33:35 2026 +0200 netrom: fix reference count leak in nr_rt_device_down When a device goes down, nr_rt_device_down() clears the routes that use this device. However, it fails to drop the per-route reference to the neighbour (nr_neigh): neither nr_neigh->count nor its refcount is decremented when the route is removed. Mirror the behaviour of nr_dec_obs() / nr_del_node() by decrementing nr_neigh->count and calling nr_neigh_put(), so that the neighbour reference is properly released when a device goes down. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Junjie Cao [F6BVP: rebased on the single nr_route_lock; the list reference is still dropped last by nr_remove_neigh_locked(), so the neighbour stays valid while its routes are removed.] Signed-off-by: Bernard Pidoux (cherry picked from commit b0f6830b24b75618e299c8e5451367e8742272da) Signed-off-by: Sasha Levin commit ece0d8fc6a459be4125f3eae32a6d69e7354e06f Author: Bernard Pidoux Date: Sat Sep 26 11:33:13 2026 +0200 netrom: look up and update routes in one critical section nr_add_node(), nr_del_node(), nr_add_neigh() and nr_del_neigh() look up a node or neighbour with nr_node_get()/nr_neigh_get_dev(), which take and drop the routing lock, and only then take the lock again to change the routes. In between, another task can unlink the object they found. nr_add_node() can then store a neighbour that is no longer on nr_neigh_list in a node's routes; that route's reference becomes the last one, and the next time the route is dropped the neighbour is freed and read again straight away: nr_neigh->count--; nr_neigh_put(nr_neigh); /* frees it */ if (nr_neigh->count == 0 && ...) /* use after free */ This is what syzbot reports in nr_add_node() (evicting the worst of three routes) and in nr_dec_obs() through nr_rt_ioctl(). Lizhi Xu analysed the first race; the fix posted then filtered neighbours by refcount and was not taken. Now that one lock covers both lists and the routes, do the lookup and the update in a single critical section in all four functions, using new __nr_node_get()/__nr_neigh_get_dev() variants that expect the lock to be held. A node or neighbour found there stays linked while it is used, so a route can no longer outlive its neighbour's list entry. Concurrent additions of the same node or neighbour no longer create duplicate entries either. Also factor the "drop one route's use of a neighbour" sequence into nr_neigh_route_put_locked(), which reads count and locked before dropping the reference, and use it in nr_add_node(), nr_del_node() and nr_dec_obs(). nr_add_node() is also called from nr_route_frame() in softirq context, where the kmemdup(GFP_KERNEL) of the digipeater list could sleep; the neighbour creation shared with nr_add_neigh() now allocates with GFP_ATOMIC, like the rest of nr_add_node() already did. This depends on "netrom: use a single lock for the node and neighbour lists". Reported-by: syzbot+2860e75836a08b172755@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2860e75836a08b172755 Reported-by: syzbot+df52f4216bf7b4d768e7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=df52f4216bf7b4d768e7 Link: https://patchwork.kernel.org/project/netdevbpf/patch/20251023135032.3759443-1-lizhi.xu@windriver.com/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux (cherry picked from commit 1292cb18feed7503f861695134206c99347cc7bb) Signed-off-by: Sasha Levin commit a007f3036b593e63e1a31a1c564dc76317136f82 Author: Bernard Pidoux Date: Fri Sep 25 14:51:52 2026 +0200 netrom: use a single lock for the node and neighbour lists NET/ROM routing uses three kinds of locks: nr_node_list_lock, nr_neigh_list_lock and a lock in every nr_node. They are taken in opposite orders on different paths: - nr_del_node() and nr_dec_obs() take the node list lock, then a node lock, then the neighbour list lock (through nr_remove_neigh()); - nr_add_node(), called for every frame received from a neighbour, holds a node lock and takes the neighbour list lock; - nr_rt_device_down() takes the neighbour list lock, then the node list lock, then each node lock. Taking an interface down while routes are being changed or frames are coming in can therefore deadlock, which is what the open syzbot reports against nr_del_node(), nr_remove_neigh() and nr_rt_device_down() show. Fixing the order case by case was tried several times and never covered every combination. As suggested by Jakub, replace all three with one nr_route_lock that covers both lists and the routes of every node. The per-node lock goes away: with the lists and routes[] under the same lock it no longer protects anything, and routing tables are small and change rarely. nr_remove_neigh() gets a variant for callers that already hold the lock. Node refcounting is unchanged apart from the hold/put pair that nr_node_lock()/nr_node_unlock() used to add around each critical section. nr_route_frame() still calls ax25_send_frame() with the lock held, as it did under the node lock, so the lock is documented as never to be taken with an AX.25 list lock held; nr_link_failed() is called from AX.25 with only linkfail_lock held. No change in behaviour otherwise; the other issues found on the way (unlocked updates of nr_neigh->ax25 and failed, duplicate entries from concurrent nr_add_node(), a reference leak in nr_rt_device_down()) are left for separate patches. Link: https://patchwork.kernel.org/project/netdevbpf/patch/20260406114904.89088-1-mashiro.chen@mailbox.org/ Suggested-by: Jakub Kicinski Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux (cherry picked from commit 602c964d5e3d006cbd6e514aa971c5ab7257d66a) Signed-off-by: Sasha Levin commit 23c0aedefd907d8fb3fd1513213ade76851d140c Author: Mashiro Chen Date: Tue Apr 14 04:49:21 2026 +0800 net: ax25: fix integer overflow in ax25_rx_fragment() ax25_rx_fragment() accumulates fragment lengths into ax25_cb->fraglen, which is an unsigned short. When the total exceeds 65535, fraglen wraps around to a small value. The subsequent alloc_skb(fraglen) allocates a too-small buffer, and skb_put() in the copy loop triggers skb_over_panic(). Add pskb_may_pull(skb, 1) at function entry to ensure the segmentation header byte is in the linear data area before dereferencing skb->data. This also rejects zero-length skbs, which the original code did not check for. Two issues in the overflow error path are also fixed: First, the current skb, after skb_pull(skb, 1), is neither enqueued nor freed before returning 1, leaking it. Add kfree_skb(skb) before the return. Second, ax25->fraglen is not reset after skb_queue_purge(). Add ax25->fraglen = 0 to restore a consistent state. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Mashiro Chen [F6BVP: v4 as posted on netdev; it was set aside only because the subsystem was being removed from the kernel. Applied unchanged.] Signed-off-by: Bernard Pidoux (cherry picked from commit 0674e0f082be20adb8e7eb03718d85e71d8b05de) Signed-off-by: Sasha Levin commit d3db0d9b568bbd7adfdfdb51e52ff71bca7b8710 Author: Bernard Pidoux Date: Fri Sep 25 14:10:34 2026 +0200 ax25: check frame length in ax25_decode() and ax25_rx_iframe() Two more reads on the receive path assume bytes that a short frame does not have: - On a connection set up with SABME (modulo 128), ax25_decode() reads a two-byte control field for I and S frames (frame[1]) without checking that the second byte is there. - ax25_rx_iframe() reads the PID byte of an I frame without checking that anything is left after the control field, so an I frame made of its control field alone is dispatched on a byte past its end. The same function also receives reassembled segments. Return AX25_ILLEGAL from ax25_decode() when the control field is incomplete, which the state machines already handle as a malformed frame, and drop an I frame that has no PID byte. The first check in ax25_decode() also covers an empty frame on its own, independently of the length check proposed for ax25_rcv(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux (cherry picked from commit 5b010290c0e627fd09b92eb8d690f0726d7cfe7c) Signed-off-by: Sasha Levin commit 0fb17d4257e8b29bb992a5242cd90e54baff577a Author: Ashutosh Desai Date: Tue Apr 21 05:48:58 2026 +0000 ax25: fix OOB read after address header strip in ax25_rcv() A crafted AX.25 frame with a valid address header but no control byte causes skb->len to reach zero after skb_pull() strips the header. The subsequent reads of skb->data[0] (control) and skb->data[1] (PID) are then out of bounds. Linearize the skb after confirming the device is an AX.25 interface. Guard with skb->len < 1 after the pull - one byte suffices for LAPB control frames which have no PID byte. Add a separate skb->len < 2 check inside the UI branch before accessing the PID byte. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Ashutosh Desai [F6BVP: v5 as posted on netdev; the author withdrew it only because the subsystem was being removed from the kernel that day. Applied unchanged.] Signed-off-by: Bernard Pidoux (cherry picked from commit e653f27001ca2a31a445ee20d9f90be65b85d7e3) Signed-off-by: Sasha Levin commit 9a92a7f8bd979026260016ef238c3ae08deaa3f2 Author: Bernard Pidoux Date: Fri Sep 25 13:38:55 2026 +0200 netrom: bound fragment reassembly in nr_queue_rx_frame() nr_sock.fraglen is an unsigned short, but nr_sendmsg() accepts messages of up to 65536 bytes, which nr_output() then splits into NR_INFO frames with the MORE flag. Reassembling such a message on the receiving side makes fraglen wrap to 0, so alloc_skb() returns a buffer far smaller than the data copied into it just after. The same happens with any stream of MORE fragments that adds up to more than 65535 bytes. Mashiro Chen proposed rejecting fragments once the total would exceed USHRT_MAX by returning 1 to the caller. Review pointed out that this return value makes nr_state3_machine() put the frame back on the resequencing queue after nr_queue_rx_frame() has already pulled its headers, and that the limit would reject a legitimate 65536-byte message. Instead: - make fraglen an unsigned int, so a full 64 KiB message fits; - when a message would grow beyond 65536 bytes, drop what has been gathered so far, consume the frame and return 0, so the caller does not retry it; - discard the remaining fragments of that message up to its last fragment, using a new NR_COND_FRAG_DISCARD condition bit, rather than delivering its tail as a separate message. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Mashiro Chen Closes: https://patchwork.kernel.org/project/netdevbpf/patch/20260407171600.102988-2-mashiro.chen@mailbox.org/ Signed-off-by: Bernard Pidoux (cherry picked from commit 6ad8be739b22495d6edc3f6d7b916098ceb3fdf0) Signed-off-by: Sasha Levin commit 775505307e971674345a253b9f26bbe6e71ba5fb Author: Mashiro Chen Date: Wed Apr 8 01:15:59 2026 +0800 net: netrom: validate source address in nr_find_socket() nr_find_socket() dispatches incoming NR_INFO frames into a connected socket by matching the frame's circuit index/id pair (bytes[15-16]) against the socket's my_index/my_id. It performs no validation of the frame's source callsign against the socket's dest_addr. This means any node on the network can craft an NR_INFO frame with a guessed or brute-forced circuit index/id pair and have it accepted into an arbitrary STATE_3 connection as if it came from the legitimate peer. Circuit IDs are assigned sequentially starting at (1,1), making them predictable in practice. Combined with other receive path bugs, this lets a third party feed frames into a circuit it does not own. nr_find_peer() already checks the source address for CONNREQ; do the same for the other frame types. Fix by adding a source address parameter to nr_find_socket() and requiring it to match the socket's recorded dest_addr for all frame-dispatch lookups. The internal nr_find_next_circuit() caller, which only checks for circuit ID availability, passes NULL to skip the source check. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Mashiro Chen [F6BVP: rebased on mod-orphan; dropped the reference to an unassigned CVE from the changelog. Checked that every caller other than nr_find_next_circuit() is in nr_rx_frame() for non-CONNREQ frames, whose network source is the remote node recorded in dest_addr.] Signed-off-by: Bernard Pidoux (cherry picked from commit 70bf32b0eda85781a416cb929b7c6b4761abd2a8) Signed-off-by: Sasha Levin commit 2cf088d42435774883443682a3d878617f86021d Author: Greg Kroah-Hartman Date: Fri Sep 25 13:37:31 2026 +0200 netrom: require full NET/ROM headers in nr_route_frame() nr_route_frame() only checked that an incoming frame was long enough for the two network layer addresses and the time-to-live byte, and did so against skb->len without making sure the bytes were in the linear part of the skb. A valid NET/ROM network frame always carries the 5-byte transport header as well, so anything shorter than NR_NETWORK_LEN + NR_TRANSPORT_LEN (20 bytes) is malformed, whether it is for this node or in transit. Use pskb_may_pull() for that length, as suggested in review, so the header fields are also guaranteed to be linear before they are read here or later in nr_rx_frame(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Greg Kroah-Hartman [F6BVP: taken from the nr_route.c part of Greg's "netrom: do some basic forms of validation on incoming frames"; the nr_rx_frame() part is handled separately. Switched from a skb->len test to pskb_may_pull() following Simon Horman's review.] Signed-off-by: Bernard Pidoux (cherry picked from commit dc06212ff6bb781fad2b5082e3ecb7cc93336da0) Signed-off-by: Sasha Levin commit c8082ee771a0311421c6a620be2a2f6c9e4942e8 Author: Stanislav Fort Date: Fri Sep 25 12:23:50 2026 +0200 netrom: linearize and validate lengths in nr_rx_frame() Linearize skb and add targeted length checks in nr_rx_frame() to prevent out-of-bounds reads when processing malformed NET/ROM frames. - Require skb to be linear and at least NR_NETWORK_LEN + NR_TRANSPORT_LEN (20 bytes) before reading network/transport fields. - For the existing sockets path, ensure NR_CONNACK includes the window byte (>= 21 bytes), which nr_state1_machine() reads. - For CONNREQ handling, ensure window (byte 20) and user address (bytes 21-27) are present (>= 28 bytes), and do so before nr_find_listener() so no listener reference can leak. - Preserve existing BPQ extension handling: - NR_CONNACK len == 22 -> 1 extra byte (TTL) - NR_CONNREQ len == 37 -> 2 extra bytes (timeout) nr_route_frame() only guarantees 15 bytes before handing a frame addressed to a local node to nr_rx_frame(), so a short frame received from any AX.25 neighbour is enough to trigger the over-read. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Eric Dumazet Reviewed-by: Eric Dumazet Signed-off-by: Stanislav Fort [F6BVP: v4 never reached mainline (whitespace-damaged posting, subsystem removed in 7.1); rebased onto mod-orphan, added comments. Tested on a two-VM QEMU bench (6.12.94, mkiss link): an AX.25 peer sends CONNREQ frames truncated to 20 and 27 bytes; without this patch both are accepted as connections, the user callsign being read past the end of the frame; with it only the complete 35-byte CONNREQ is accepted. v2: apply the CONNACK length check to a plain CONNACK only, so that 20-byte CONNACK|CHOKE refusals and resets are no longer dropped (reported by Sasha Levin). Same fix submitted to mod-orphan.] Signed-off-by: Bernard Pidoux (cherry picked from commit db51201afd46992c9206fa79878badb2236bb7d3) Signed-off-by: Sasha Levin commit e885a256982c40f3e9c13c687618aa1398970c52 Author: Bernard Pidoux Date: Fri Sep 25 11:10:23 2026 +0200 rose: clear stale N(R)/N(S) before (re)transmitting a data frame rose_kick() transmits a skb_clone() of each data frame and keeps the original on ack_queue. The clone shares its data buffer with the original, so the sequence numbers that rose_send_iframe() ORs into byte 2 of the header are also left in the queued original. After a RESET, rose_requeue_frames() puts those originals back on the write queue and rose_kick() sends them again with vs/vr restarted at zero. rose_send_iframe() only ORs the new values into byte 2, so the retransmitted frame carries the bitwise OR of the old and new N(R) and N(S). The peer rejects the invalid N(R) with a new RESET REQUEST, the frames are requeued again, and the two nodes reset each other forever. This was observed on a live FPAC network: a White Pages circuit between two nodes looping on RESET REQUEST / RESET CONFIRMATION / DATA at about 2000 frames per second, with DATA frames resent as "R3 S7" right after a reset instead of "R0 S0", until the application was restarted. Clear everything but the M bit before setting the sequence numbers, as x25_send_iframe() does for modulo 8 circuits. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux (cherry picked from commit b16b091aeb78faac22cf2b850246826d23f4a335) Signed-off-by: Sasha Levin commit 2a2927e95cf1b8efb15bcb741bbd06c9bb0537b7 Author: Larysa Zaremba Date: Thu Mar 5 12:12:45 2026 +0100 ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz [ Upstream commit e142dc4ef0f451b7ef99d09aaa84e9389af629d7 ] The only user of frag_size field in XDP RxQ info is bpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead of DMA write size. Different assumptions in ice driver configuration lead to negative tailroom. This allows to trigger kernel panic, when using XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to 6912 and the requested offset to a huge value, e.g. XSK_UMEM__MAX_FRAME_SIZE * 100. Due to other quirks of the ZC configuration in ice, panic is not observed in ZC mode, but tailroom growing still fails when it should not. Use fill queue buffer truesize instead of DMA write size in XDP RxQ info. Fix ZC mode too by using the new helper. Fixes: 2fba7dc5157b ("ice: Add support for XDP multi-buffer on Rx side") Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Link: https://patch.msgid.link/20260305111253.2317394-5-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eae1bd12387e1e2e3a27cb4ec4d2687aa3abf6c0 Author: Larysa Zaremba Date: Thu Mar 5 12:12:44 2026 +0100 ice: fix rxq info registering in mbuf packets [ Upstream commit 02852b47c706772af795d3e28fca99fc9b923b2c ] XDP RxQ info contains frag_size, which depends on the MTU. This makes the old way of registering RxQ info before calculating new buffer sizes invalid. Currently, it leads to frag_size being outdated, making it sometimes impossible to grow tailroom in a mbuf packet. E.g. fragments are actually 3K+, but frag size is still as if MTU was 1500. Always register new XDP RxQ info after reconfiguring memory pools. Fixes: 2fba7dc5157b ("ice: Add support for XDP multi-buffer on Rx side") Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Link: https://patch.msgid.link/20260305111253.2317394-4-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 54136991299a68c03356db3ef8540fa493d5940e Author: Rafael J. Wysocki Date: Sat Oct 24 18:57:08 2026 +0800 ACPI: scan: Register platform devices for fixed event buttons [ Upstream commit ab06eb9204010c61e754bf4e71ee6f554584714d ] On platforms using ACPI, power and sleep buttons may be so called "fixed event devices" in which case they are hooked up directly to the Fixed Events register in the platform via dedicated lines and there are no corresponding device objects in the ACPI namespace. Nevertheless, in Linux they get corresponding struct acpi_device objects with special device IDs, either LNXPWRBN or LNXSLPBN, which are then used for driver binding in a ususal way. However, the function creating those struct acpi_device objects for "fixed event device" buttons, acpi_bus_scan_fixed(), does not register platform devices for them, unlike the generic code handling device enumeration based on the ACPI namespace. Consequently, if an ACPI power or sleep button is represented by a device object in the ACPI namespace, it will get a corresponding platform device, but if it is a "fixed event device", it will not get one, which is inconsistent and prevents the ACPI power button driver from being converted into a platform driver. For the sake of consistency and to allow the ACPI power button driver to become a platform one going forward, modify acpi_bus_scan_fixed() to register platform devices for "fixed event device" buttons and update ACPI platform device registration code to work with non-device ACPI object types, so it can handle the buttons in question. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3731144.R56niFO833@rafael.j.wysocki [ Ting-Han: 52d864019636 ("ACPI: button: Convert the driver to a platform one") was backported to 6.18.57 as a dependency of fe80251152fe ("ACPI: button: Fix ACPI GPE handler leak during removal") without this prerequisite, so fixed event power buttons (LNXPWRBN, e.g. on QEMU q35) have no platform device and are no longer bound to any driver. ] Signed-off-by: Ting-Han Hou Signed-off-by: Sasha Levin commit 600d95eb39ad34959969ce144848ae6a70eb95e4 Author: Joseph Qi Date: Thu Oct 22 14:40:46 2026 +0800 eventfs: fix SRCU read lock leak in eventfs_iterate() Commit 2b80707b9e27 ("eventfs: Use children field for rcu head and add memory barriers") added an early bail out to the ei->children loop: smp_rmb(); if (ei->is_freed) return -EINVAL; Upstream wraps eventfs_iterate() in guard(srcu)(&eventfs_srcu), so that return still drops the read lock. The 6.18.y backport instead brackets the function with srcu_read_lock() and a shared "out" label that calls srcu_read_unlock(), so this path returns while still holding eventfs_srcu for reading. The unbalanced reader prevents the grace period from ever completing, so the call_srcu() callback queued by free_ei() never runs and the eventfs_inode is leaked. Every readdir that races with removal adds another reader. Set ret and jump to "out" like the other bail out paths in this function do. Fixes: 2b80707b9e27 ("eventfs: Use children field for rcu head and add memory barriers") Signed-off-by: Joseph Qi Signed-off-by: Sasha Levin