From nobody Sat Feb 7 11:31:46 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 451A723645D; Sat, 24 Jan 2026 16:47:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769273224; cv=none; b=Rqeu5XcERW3tvqozPc4ihcA0AqeEP24IxFFOd2sI2Ktzm3yO4skzuriosrQtpHUzi2gaeUTVJaLbyC90Bn/NFrej9ON3t97lWLesCJuXKjDnzATZvh9zUBtKN0dXbS3lsgWVvMLg86iqyRx+qI/UrKjomuYOgGRcp0M3C4IZWyI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769273224; c=relaxed/simple; bh=koVTBk7QDr/VkxFedRNFGbEg98lzmoTKW7R68p1v3qI=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=kZqJ+9stpd+V/BOGzbHC+huSTAklC7yQwdvzCeYBb1+bD01Q+sNUnHl/zONpgUU/ggvf1jwIWytv0k0XDcJdIoDQrWMFyZaeJnU59xzyH4RfhS2uwsvDsLOawriSeuLrtzmPX/5pz+MjpiVeMI5MxMXMb7ZRh9Qlt34f5dD0FOo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bTSUehkH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bTSUehkH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C575CC16AAE; Sat, 24 Jan 2026 16:47:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769273223; bh=koVTBk7QDr/VkxFedRNFGbEg98lzmoTKW7R68p1v3qI=; h=Date:From:To:Cc:Subject:References:From; b=bTSUehkHz5gaFDL6QbDsA55ZotHlD7VXFXO+i0gM7RGd4+6GAVzX21Z2ncf/8oLdX EeLqT0d8sIiO8SJLFlWgD3lCFGxTEhz+aowWOflVPc40XRzVAQ2HcriLIMafVsV3iB tB4mWqmLEG5AzQaesgIE6uH8EB1XDu5Me4tt+OT5/E5UDL0fG4bARxMecKgN6HY+4B 9cj3V1wtKeVKPL9VRbFmO4kw4WbgEBSThkjroOQYEmy/chs0xzqn3zhFglB7ZfP5L+ 3zRAMZynrSoGUPBq22UutAgiOvDA3+IEaZJe4Db7CeFgWhioxy1R757t7/LYCNGxhC tcboPntwxUCkA== Received: from rostedt by gandalf with local (Exim 4.99.1) (envelope-from ) id 1vjgnO-00000003Cmt-3TLm; Sat, 24 Jan 2026 11:47:34 -0500 Message-ID: <20260124164734.690561052@kernel.org> User-Agent: quilt/0.68 Date: Sat, 24 Jan 2026 11:29:44 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, Tom Zanussi Subject: [for-linus][PATCH 1/4] tracing: Fix crash on synthetic stacktrace field usage References: <20260124162943.928691049@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Steven Rostedt When creating a synthetic event based on an existing synthetic event that had a stacktrace field and the new synthetic event used that field a kernel crash occurred: ~# cd /sys/kernel/tracing ~# echo 's:stack unsigned long stack[];' > dynamic_events ~# echo 'hist:keys=3Dprev_pid:s0=3Dcommon_stacktrace if prev_state & 3' >>= events/sched/sched_switch/trigger ~# echo 'hist:keys=3Dnext_pid:s1=3D$s0:onmatch(sched.sched_switch).trace(s= tack,$s1)' >> events/sched/sched_switch/trigger The above creates a synthetic event that takes a stacktrace when a task schedules out in a non-running state and passes that stacktrace to the sched_switch event when that task schedules back in. It triggers the "stack" synthetic event that has a stacktrace as its field (called "stack"). ~# echo 's:syscall_stack s64 id; unsigned long stack[];' >> dynamic_events ~# echo 'hist:keys=3Dcommon_pid:s2=3Dstack' >> events/synthetic/stack/trig= ger ~# echo 'hist:keys=3Dcommon_pid:s3=3D$s2,i0=3Did:onmatch(synthetic.stack).= trace(syscall_stack,$i0,$s3)' >> events/raw_syscalls/sys_exit/trigger The above makes another synthetic event called "syscall_stack" that attaches the first synthetic event (stack) to the sys_exit trace event and records the stacktrace from the stack event with the id of the system call that is exiting. When enabling this event (or using it in a historgram): ~# echo 1 > events/synthetic/syscall_stack/enable Produces a kernel crash! BUG: unable to handle page fault for address: 0000000000400010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEM= PT(lazy) Debian 6.16.3-1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.1= 7.0-1 04/01/2014 RIP: 0010:trace_event_raw_event_synth+0x90/0x380 Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e= 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 <49> 8b 04 24 48 = 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f RSP: 0018:ffffd2670388f958 EFLAGS: 00010202 RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0 RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50 R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010 R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90 FS: 00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:00000000000000= 00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0 Call Trace: ? __tracing_map_insert+0x208/0x3a0 action_trace+0x67/0x70 event_hist_trigger+0x633/0x6d0 event_triggers_call+0x82/0x130 trace_event_buffer_commit+0x19d/0x250 trace_event_raw_event_sys_exit+0x62/0xb0 syscall_exit_work+0x9d/0x140 do_syscall_64+0x20a/0x2f0 ? trace_event_raw_event_sched_switch+0x12b/0x170 ? save_fpregs_to_fpstate+0x3e/0x90 ? _raw_spin_unlock+0xe/0x30 ? finish_task_switch.isra.0+0x97/0x2c0 ? __rseq_handle_notify_resume+0xad/0x4c0 ? __schedule+0x4b8/0xd00 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x1ef/0x2f0 ? do_fault+0x2e9/0x540 ? __handle_mm_fault+0x7d1/0xf70 ? count_memcg_events+0x167/0x1d0 ? handle_mm_fault+0x1d7/0x2e0 ? do_user_addr_fault+0x2c3/0x7f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reason is that the stacktrace field is not labeled as such, and is treated as a normal field and not as a dynamic event that it is. In trace_event_raw_event_synth() the event is field is still treated as a dynamic array, but the retrieval of the data is considered a normal field, and the reference is just the meta data: // Meta data is retrieved instead of a dynamic array str_val =3D (char *)(long)var_ref_vals[val_idx]; // Then when it tries to process it: len =3D *((unsigned long *)str_val) + 1; It triggers a kernel page fault. To fix this, first when defining the fields of the first synthetic event, set the filter type to FILTER_STACKTRACE. This is used later by the second synthetic event to know that this field is a stacktrace. When creating the field of the new synthetic event, have it use this FILTER_STACKTRACE to know to create a stacktrace field to copy the stacktrace into. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://patch.msgid.link/20260122194824.6905a38e@gandalf.local.home Fixes: 00cf3d672a9d ("tracing: Allow synthetic events to pass around stackt= races") Signed-off-by: Steven Rostedt (Google) --- kernel/trace/trace_events_hist.c | 9 +++++++++ kernel/trace/trace_events_synth.c | 8 +++++++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_h= ist.c index 5e6e70540eef..c97bb2fda5c0 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -2057,6 +2057,15 @@ static struct hist_field *create_hist_field(struct h= ist_trigger_data *hist_data, hist_field->fn_num =3D HIST_FIELD_FN_RELDYNSTRING; else hist_field->fn_num =3D HIST_FIELD_FN_PSTRING; + } else if (field->filter_type =3D=3D FILTER_STACKTRACE) { + flags |=3D HIST_FIELD_FL_STACKTRACE; + + hist_field->size =3D MAX_FILTER_STR_VAL; + hist_field->type =3D kstrdup_const(field->type, GFP_KERNEL); + if (!hist_field->type) + goto free; + + hist_field->fn_num =3D HIST_FIELD_FN_STACK; } else { hist_field->size =3D field->size; hist_field->is_signed =3D field->is_signed; diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_= synth.c index 4554c458b78c..45c187e77e21 100644 --- a/kernel/trace/trace_events_synth.c +++ b/kernel/trace/trace_events_synth.c @@ -130,7 +130,9 @@ static int synth_event_define_fields(struct trace_event= _call *call) struct synth_event *event =3D call->data; unsigned int i, size, n_u64; char *name, *type; + int filter_type; bool is_signed; + bool is_stack; int ret =3D 0; =20 for (i =3D 0, n_u64 =3D 0; i < event->n_fields; i++) { @@ -138,8 +140,12 @@ static int synth_event_define_fields(struct trace_even= t_call *call) is_signed =3D event->fields[i]->is_signed; type =3D event->fields[i]->type; name =3D event->fields[i]->name; + is_stack =3D event->fields[i]->is_stack; + + filter_type =3D is_stack ? FILTER_STACKTRACE : FILTER_OTHER; + ret =3D trace_define_field(call, type, name, offset, size, - is_signed, FILTER_OTHER); + is_signed, filter_type); if (ret) break; =20 --=20 2.51.0 From nobody Sat Feb 7 11:31:46 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4520923D7DE for ; Sat, 24 Jan 2026 16:47:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769273224; cv=none; b=ak7Dw5WYpjqyC8tYhAdLYbK8DsdXNHMiMKEJ+DoR7ccz7YLAsibtB2y/Kfj0jqe0w7frFlVPyqcRQVWNR+4s/o91L8g3TB1ukok41CNw7rEGlftSmo1++cSZLJn4Y3fjLChU5ViCw4hH0c4SiOE9JGau5qQYlrjfGEmsX4iaqe8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769273224; c=relaxed/simple; bh=hThp9jWUk6Tk7E1nVmBKT0kjFbhl4aOu0CxfuCZ50A4=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=Cm6TlqhEt+BihI3F9aQpEtnC8oEC9EaYUaksrjDnBNqIREF85vG+H/pvFSEfNWtYch+0rbsE7jpsUdh7CQFU8Z2uOGvn6B+DhdX/pxmBMzF5N621j3UwFUD5bwMzU0knb8m7feVnNT+Ik/t6dnJmc0yRh2InPw3HkxC59b7fDgc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s0ssxfap; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s0ssxfap" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03F20C19425; Sat, 24 Jan 2026 16:47:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769273224; bh=hThp9jWUk6Tk7E1nVmBKT0kjFbhl4aOu0CxfuCZ50A4=; h=Date:From:To:Cc:Subject:References:From; b=s0ssxfaphbKgGWg+MdJ+lLyIztoSNhWXoFw9up6KJOmWgztqDq/ucuR6RK7tkai93 k92gWTGOi1PMuC6dvSmagnKb53QwU4z2lFb7gu1shm0oUI9SJb6TFLACFxXuL94xAF Vre6rj/w70qntkkMdOm856su6xexjbcApbdSrwfN15QDqS02wItnPkkU6WmuVUS28f fp1ABQ8rDedN9y1iA59ToLU0rRhqi4POCHLDlQk41su6VuBRytdyJ2zeFnAKU6rr7l kqeksjNEU23/whr5ji1DgfBVLyMH0dqn1tKptvcyGly52VlkNGQc3bBrt79wsw8CGq 3S6glEcjJA+lg== Received: from rostedt by gandalf with local (Exim 4.99.1) (envelope-from ) id 1vjgnO-00000003CnN-44x3; Sat, 24 Jan 2026 11:47:34 -0500 Message-ID: <20260124164734.844806094@kernel.org> User-Agent: quilt/0.68 Date: Sat, 24 Jan 2026 11:29:45 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , Ian Rogers Subject: [for-linus][PATCH 2/4] tracing: Avoid possible signed 64-bit truncation References: <20260124162943.928691049@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ian Rogers 64-bit truncation to 32-bit can result in the sign of the truncated value changing. The cmp_mod_entry is used in bsearch and so the truncation could result in an invalid search order. This would only happen were the addresses more than 2GB apart and so unlikely, but let's fix the potentially broken compare anyway. Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260108002625.333331-1-irogers@google.com Signed-off-by: Ian Rogers Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) --- kernel/trace/trace.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index baec63134ab6..8bd4ec08fb36 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6115,10 +6115,10 @@ static int cmp_mod_entry(const void *key, const voi= d *pivot) unsigned long addr =3D (unsigned long)key; const struct trace_mod_entry *ent =3D pivot; =20 - if (addr >=3D ent[0].mod_addr && addr < ent[1].mod_addr) - return 0; - else - return addr - ent->mod_addr; + if (addr < ent[0].mod_addr) + return -1; + + return addr >=3D ent[1].mod_addr; } =20 /** --=20 2.51.0 From nobody Sat Feb 7 11:31:46 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 450D21DD0EF for ; Sat, 24 Jan 2026 16:47:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769273224; cv=none; b=Se9fDveMNum0U7v0U45y2iIdI7xe7fTs3Ue4NcNvqrGaAsHjMKsNlU+QrgSe5A87pzb45E9GBotefBDKKucyuTVrxzVasntLPt+JEyiX3YKlkH8z7QkYbvcKlJpOpaUOimtQ8e2G3KxPpzyAkY+04jgwB/XfEvEAzBNRJXlVB9I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769273224; c=relaxed/simple; bh=b3Id3PPIN4zo1LkXARAADpXfvNcm56DyHgcf0+VWAy8=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=Nzxmq2ICUYTv+ZAb/Ih05Rj8VPX6zaCWXN+ORwaGn/b2tyRzk1LnAeHRJyb3YcvYtG71W4I+dRwUVYhlg1jRuEheP0YT66cOPJm/KPKJIeONrc7Vk9A95rhXnERpnqtddA9cDf69rB3owHWa/pC2SJz+ZqYhOSgAKMbWMiVnG4E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ql1VggrZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ql1VggrZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 09138C19423; Sat, 24 Jan 2026 16:47:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769273224; bh=b3Id3PPIN4zo1LkXARAADpXfvNcm56DyHgcf0+VWAy8=; h=Date:From:To:Cc:Subject:References:From; b=ql1VggrZFh2zAWEEZN0qkxGuHIg07Ahd+QB/Pmh7Sa2GLeXJR6gwS0xGIiYzfD1pT sODM5fo/VMHN9UsIeik04KG/ow+NxGY/eIWtumiIkMbwDjCBksIFPW9qoMn1/ydnbp a2jU6kX2mDT8Qf7/VmGLsU1AzQIZjN93kgm1MeKsg5bdeRsDWthIe4qHqLG4hHU2VC unqFzT44DHIgrbQetDKwnoTn8hCRaLnFTO7dEBfycjwUrsMP9LGBrKA2v8DbBlZ7WN aR705n6o0jfiEjB/gzk4ljINE4T7toOJWPCuK88fnWS4miNaQqNnsdYkVvZItx8par G2aeFa0nkJDqw== Received: from rostedt by gandalf with local (Exim 4.99.1) (envelope-from ) id 1vjgnP-00000003Cns-0Rzc; Sat, 24 Jan 2026 11:47:35 -0500 Message-ID: <20260124164734.989597992@kernel.org> User-Agent: quilt/0.68 Date: Sat, 24 Jan 2026 11:29:46 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , Donglin Peng Subject: [for-linus][PATCH 3/4] function_graph: Fix args pointer mismatch in print_graph_retval() References: <20260124162943.928691049@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Donglin Peng When funcgraph-args and funcgraph-retaddr are both enabled, many kernel functions display invalid parameters in trace logs. The issue occurs because print_graph_retval() passes a mismatched args pointer to print_function_args(). Fix this by retrieving the correct args pointer using the FGRAPH_ENTRY_ARGS() macro. Link: https://patch.msgid.link/20260112021601.1300479-1-dolinux.peng@gmail.= com Fixes: f83ac7544fbf ("function_graph: Enable funcgraph-args and funcgraph-r= etaddr to work simultaneously") Acked-by: Masami Hiramatsu (Google) Signed-off-by: Donglin Peng Signed-off-by: Steven Rostedt (Google) --- kernel/trace/trace_functions_graph.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_func= tions_graph.c index b1e9c9913309..1de6f1573621 100644 --- a/kernel/trace/trace_functions_graph.c +++ b/kernel/trace/trace_functions_graph.c @@ -901,7 +901,7 @@ static void print_graph_retval(struct trace_seq *s, str= uct ftrace_graph_ent_entr trace_seq_printf(s, "%ps", func); =20 if (args_size >=3D FTRACE_REGS_MAX_ARGS * sizeof(long)) { - print_function_args(s, entry->args, (unsigned long)func); + print_function_args(s, FGRAPH_ENTRY_ARGS(entry), (unsigned long)func); trace_seq_putc(s, ';'); } else trace_seq_puts(s, "();"); --=20 2.51.0 From nobody Sat Feb 7 11:31:46 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4A6C624677F for ; Sat, 24 Jan 2026 16:47:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769273224; cv=none; b=OTHEHrZXf37WD9BOxSRwQPDQ8QGzEXcm8llvLdhJPZyMddk709Gn90ORH4Z2F0X2fZb9WoI+BomNh90W5OD3n8f1VcIYB64uKRAb+pzqU/PELkaYeUoMJyaNaAQmRcotR43BLUD6rOHMsj3n4lPTlpg0qDcQFLm45PtTY430hOg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769273224; c=relaxed/simple; bh=Loik4NtpaUGTgbbPGsqPlqeVdsjyh+lsRwTPRfSGNkg=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=GKZ3KIPFOxyOCGPhbPlDgkj3rfm1o0R3GqwjX7FoOUca8+3gHfdV4zZ/XJTmSful/m2Fh70oTZOT2Tp7FFqdmiA7izy3e7whbd6zOyQDeBaeXiiJtdW/LQCzqKQKUJLq0zBMRvsGo5U2OszYCjw9MseE0sf5vEPvlYyBq0U6atU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Mmu16mG9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Mmu16mG9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28541C2BC86; Sat, 24 Jan 2026 16:47:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769273224; bh=Loik4NtpaUGTgbbPGsqPlqeVdsjyh+lsRwTPRfSGNkg=; h=Date:From:To:Cc:Subject:References:From; b=Mmu16mG9rMDAr0ywAb0uJCUKsEAnTPhiw3EiSDxhGt02U9ow93APGUr0m88YQDOgo 47dsOiZoza1ro0FdLP6hIvaYZLPlg0a2EQZtkzI6A07C6MIiPuN8Lg0IKZRndKaHgA WpIe31xap4ZlNEaJUrvr+dZocjDVlQgvjHoUTpuICmPe5Hzwh9hAfYdmFRmDlUe3Qp yYWCoE9/mVtNDZkx4/CkI0YIfj+LK+lmiOUaz1QbAmRco7OVRnaKVPOeML8J+Jddea n0b9L7ECFO9LEQ5biqFrw7g7xcuBNJhAVmmqS25S8bhsVHdDGO8bmYuS438xpONq3a rmJBaYFUdbggQ== Received: from rostedt by gandalf with local (Exim 4.99.1) (envelope-from ) id 1vjgnP-00000003CoM-11fh; Sat, 24 Jan 2026 11:47:35 -0500 Message-ID: <20260124164735.123784124@kernel.org> User-Agent: quilt/0.68 Date: Sat, 24 Jan 2026 11:29:47 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , Weigang He Subject: [for-linus][PATCH 4/4] scripts/tracepoint-update: Fix memory leak in add_string() on failure References: <20260124162943.928691049@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Weigang He When realloc() fails in add_string(), the function returns -1 but leaves *vals pointing to the previously allocated memory. This can cause memory leaks in callers like make_trace_array() that return on error without freeing the partially built array. Fix this by freeing *vals and setting it to NULL when realloc() fails. This makes the error handling self-contained in add_string() so callers don't need to handle cleanup on failure. This bug is found by my static analysis tool and my code review. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Fixes: e30f8e61e2518 ("tracing: Add a tracepoint verification check at buil= d time") Link: https://patch.msgid.link/20260119114542.1714405-1-geoffreyhe2@gmail.c= om Signed-off-by: Weigang He Signed-off-by: Steven Rostedt (Google) --- scripts/tracepoint-update.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/scripts/tracepoint-update.c b/scripts/tracepoint-update.c index 90046aedc97b..5cf43c0aac89 100644 --- a/scripts/tracepoint-update.c +++ b/scripts/tracepoint-update.c @@ -49,6 +49,8 @@ static int add_string(const char *str, const char ***vals= , int *count) array =3D realloc(array, sizeof(char *) * size); if (!array) { fprintf(stderr, "Failed memory allocation\n"); + free(*vals); + *vals =3D NULL; return -1; } *vals =3D array; --=20 2.51.0