commit 79a907609d53d5cd645b42c11550d295d43abf99 Author: Greg Kroah-Hartman Date: Fri Oct 30 13:09:52 2026 +0100 Linux 7.3.1 Link: https://lore.kernel.org/r/20261028165940.394092994@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Brett A C Sheffield Tested-by: Takeshi Ogasawara Tested-by: Peter Schneider Tested-by: Salvatore Bonaccorso Tested-by: Barry K. Nathan Tested-by: Miguel Ojeda Tested-by: Ron Economos Tested-by: SJ Park Tested-by: Shuah Khan Tested-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit a2795d9c65bd9d8b863a04dfbf6a05c2e99381d0 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 Signed-off-by: Greg Kroah-Hartman commit f46cd8241d9b83f2279cc0db3e9d3e181b548a59 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 2f22342b9f4c9fa88edede522881f4cc3beeed0f Author: Christian Brauner Date: Mon Aug 24 14:08:17 2026 +0200 coredump: prevent TIF_NOTIFY_SIGNAL from interrupting coredumps commit a58d647acfdc62561f3570d114025b3bf38ae41b 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 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. However, both the usermodehelper pipe and the coredump socket will bail early on TIF_NOTIFY_SIGNAL. This affects the following codepaths: - coredump_sock_recv() -> unix_stream_read_generic() The request/ack handshake is abandoned before any coredump data is sent. - anon_pipe_write() returning -ERESTARTSYS Once the pipe is full this truncates the coredump. - unix_stream_sendmsg() returning -ERESTARTSYS Once the send buffer is full this truncates the coredump. - coredump_sock_wait() -> __kernel_read() This reports a failure that didn't happen. - wait_for_dump_helpers() -> wait_event_interruptible() This stops waiting for the coredump helpers. Such truncation is entirely invisible to userspace and all uapi bits still indicate that a successful coredump happened. A crashing process with a bunch of file backed mappings and io_uring thrown in loses most of the coredump data. If the NT_FILE note goes past PAGE_SIZE mappings it's gonzo. TIF_NOTIFY_SIGNAL is sent by io_uring for the common case. And it uses poll without sleeping so a completion callback runs task_work_add() from interrupt context against the task that submitted the request. This is the task that is running the coredump. Since that task hasn't set work_exited (it hasn't exited yet after all) TIF_NOTIFY_SIGNAL keeps reappearing. A coredumping task doesn't return to userspace. The task work is run at exit. So interrupting it doesn't buy anything and just loses the coredump which is quite valuable. Note that this isn't specific to io_uring. There's also klp_send_signals(), bpf_task_work_schedule_signal(), landlock's tsync and then technically, kthread_stop() and the printk kunit test set the bit raw. Link: https://patch.msgid.link/20260824-work-tif_notify_signal-v2-2-6609e42b3157@kernel.org Fixes: 12db8b690010 ("entry: Add support for TIF_NOTIFY_SIGNAL") Reviewed-by: Oleg Nesterov Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit f750c60b24ee77b4f4f5204782524b015e31faf6 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 f307e69545f022149d9ede8e4b091a7b7949baac 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 afa8eb069694bd9f845e5e44eac6e81cbc06780e 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 1fb3e7276a1f80aa04037a1bb0099967fcac7a13 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 31fc780b75b278d37700373d54a99fdb4117fdd6 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 6d8f10ccd3f4308a66d720ff95655f3315e43e13 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 10e2681cecfeddf583a1138890e4746efd1d41be 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 b0eca0edddf4c1dbaf6d1f6a8636b4235f5bc573 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 d97dba9ff13987d1fc415408557a54adde980311 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 57e54b6939c6539d90a81c7e57531901d5991651 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 ed697a5f667435bbb1cedbe5bd9f300de645047d 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 fc2850c39b738380fd81524cfa4c3205a4892408 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 23a9163cc40b4996ba1e20533b1210a1a0bee416 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 e2a2deda08d91644f5e30c17d267b1cdc5f124b2 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 a113eba06bd1183c614d7994864d6e7054140cb9 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 0461bc8f91116aae4a020e15f4e1c1fd535ab35e 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 49f4e768540d25d8852ef750313afda6a4774871 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 40b12b93ae4ab9e22c3d571e9b09fd08afad53f6 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 e01014ea788fef3df8c136eba70a81821c0f0253 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/ 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 22fb4a4518e305164c7f203608287564de292f34 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 e8f229e48f03115329aea2d848944fcdc4364682 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 70ecde6bbdbb5c7ace18ecb4da3b8bcea6f162b6 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. 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 521e8a65e9b45532295ba1082ef12be6e80c173b 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 041d1a568a11a7ed7415ef1408d0c65041c1ad69 Author: Haoran Wang Date: Fri Oct 16 11:33:13 2026 +0800 tracing/syscalls: Use copy_from_user for the faultable syscall buffer commit 097fd0050089df17b032f2b852b9b65e548e342a upstream. syscall_copy_user_array() copies the buffer argument of faultable syscalls (write, pwrite64, ...) with __copy_from_user(), which skips access_ok(). Use copy_from_user() instead so a non-user address is rejected and the entry is recorded as faulted. It could be a security concern for machines that trust perf a bit too much. Cc: stable@vger.kernel.org Fixes: baa031b7bd2ce ("tracing: Allow syscall trace events to read more than one user parameter") Link: https://patch.msgid.link/6ad19afd.a938ce27.16851e.3440@mx.google.com Signed-off-by: Haoran Wang Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit cf4e31d5da80fae4c9cdbe7af55b7c3ad213f0e4 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 9d8297ec7f0c9ab6398df004e941d9ddbb113f18 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 b8b68fb3978de1c3bb3fb1410568ec4904ebda7a Author: Donggeun Yoo Date: Mon Sep 14 14:34:41 2026 +0900 tracing: Add the bucket size to expr_field_str() commit c027ed03bc03a0e82fc368eaad657584a4480c7a upstream. expr_field_str() renders a HIST_FIELD_FL_BUCKET field as "pid.buckets", dropping the count, and parse_field() rejects that spelling. get_hist_field_flags() returns the bare string "buckets" and keeps the count in hist_field->buckets. hist_field_print() appends it, expr_field_str() never did. Nothing reaches it today, since .buckets is refused on a value and no expression can carry one, but the next patch renders histogram keys with expr_field_str(), where a .buckets key is legal. Append the count, as hist_field_print() does. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914053443.981201-3-donggeunyoo.kernel@gmail.com Fixes: de9a48a360b7 ("tracing: Add linear buckets to histogram logic") Signed-off-by: Donggeun Yoo Assisted-by: Claude:claude-fable-5 Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit d0090baf02dd08f6e909f36f0ad54a4e80f5e79b 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 7cafc82e6153f05a221be678cd649d02e06ba909 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 5bcdf3c18c3471122ee9652b0e2f5cdb718d9a46 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 1f06cfe0b60a878619d1d8efe1cd0f515b7dc2aa 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 244c442f54601a24c86ad90572bf36fc3df41c5e 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 3bdc8765af493be7ee8d3c4a4e18a448fc004a94 Author: Sasha Levin Date: Sun Oct 11 18:33:31 2026 -0400 tools/dma: fix building with O= commit 9441e7eca18c8004d1afe57b2f9b27717549562a upstream. With O= set, "all" depends on $(OUTPUT)dma_map_benchmark, but the only rule builds dma_map_benchmark in the source directory, and built-in rules are disabled: make: *** No rule to make target '/dma_map_benchmark', needed by 'all'. Stop. Build $(OUTPUT)dma_map_benchmark. Fixes: f74ee32963f1b ("tools/dma: move dma_map_benchmark from selftests to tools/dma") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Sasha Levin Acked-by: Qinxin Xia Link: https://lore.kernel.org/r/20261011223358.2327625-3-sashal@kernel.org Signed-off-by: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman commit d3afd7803f9bc2a8c4270199497b60158b2fc647 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 156aeda4d74e9007b56492ed1f3b5838822632be Author: SJ Park Date: Mon Oct 26 06:33:16 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. [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 6184eaadca4a1826dc56ba639976e5709903dbb3 Author: Haris Okanovic Date: Fri Sep 11 13:31:59 2026 -0500 genirq/proc: Fix missing CPU header in /proc/interrupts commit e74798f2f8e1562f2bbd2fed8d81929eeef39ffc upstream. irq_seq_show() must be idempotent since it may be called multiple times to render the same record, e.g. when seq_file's buffer is exceeded. It emits the CPU header behind the one-shot print_header flag, which the first pass clears, so the header is lost with the discarded buffer. This can be seen on large systems, such as 8g.48xl (192 CPUs) and 8i.96xl (384 CPUs) AWS instance types: $ head -1 /proc/interrupts 9: 0 0 ... 0 GICv3 25 Level vgic Replace print_header with the position of the first record and include the header whenever that record is emitted. Fixes: 171cc0d9eed1 ("genirq/proc: Speed up /proc/interrupts iteration") Signed-off-by: Haris Okanovic Signed-off-by: Thomas Gleixner Tested-by: Michael Kelley Reviewed-by: Radu Rendec Link: https://patch.msgid.link/20260911-dev-harisokn-proc-interrupts-fix-b4-v1-1-f9ff208efcfa@amazon.com Signed-off-by: Greg Kroah-Hartman