From nobody Mon Oct 6 15:12:20 2025 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 009501C54A9; Sat, 19 Jul 2025 17:57:53 +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=1752947874; cv=none; b=qRkg7E5gC8sgHAabZ0tuNVaUG6cgfC3GJfBYIeoU5lVC85mii7wX0qkHwG2jhgWB1Z0JXSENoI8Pj1A99+Cogv9LpsY5xvky6DsQS3rWftebJ2hRWSJySsh0lZ4sYJrHmy19XiN53j4lGHN3UzutLtPQ7SkmYXtHEhbSNLdkR30= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752947874; c=relaxed/simple; bh=WSJfvxABQUegGVEsD35iWMJc1eMNZLiGFspF49+SlAM=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=YAXPz3PY4PqJqw3JpbEKYpPEODLu4IQMxnPIUGhWeOHd7WS0ysu6BpZ2Vph4YrLLDe6o5W9XdUoLgaWUToqcoBnusTiiVs0l/wwrAZVvlNG4Y/tlKOK8WKz8G6eGOpkZ1QwrK7uvSy+nv1dcvmVB1MJ81Cw5pJ693lcS7Yig12Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=d5jLqyk0; 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="d5jLqyk0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 924DEC4CEF1; Sat, 19 Jul 2025 17:57:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752947873; bh=WSJfvxABQUegGVEsD35iWMJc1eMNZLiGFspF49+SlAM=; h=Date:From:To:Cc:Subject:References:From; b=d5jLqyk0TRQBeLjVzJU2PFggU7hADK62biPRt2L73GthtBhC1xtANPNnW9rBFxkLD dzs9XfwFjSqXIAkGHBUgWKiIhjtE+maKaNRjgTmHGcfH351bjJLRsieHbz6Bezq58n cpFIpvOwpHTgu87+A1eJKZ/XNWujfZjuc/4SlP5k03JZFKDJSRWy1i7DMY6iFC0QME wd7W0t73jtYcDiIjBU4LEBgGtZZ5AxC3b3tZ1QnQjbOH21UmsCI0EjHcG0svVGmmCE YD8/MyXogmFMd+5wpBP7qxRAx+1oEeULcpedrFvaMgO3V1ZlC32PevcTaSCrDQN+SN vUAaxrOkArrTA== Received: from rostedt by gandalf with local (Exim 4.98.2) (envelope-from ) id 1udBpD-000000085HO-3ULw; Sat, 19 Jul 2025 13:58:19 -0400 Message-ID: <20250719175819.682506779@kernel.org> User-Agent: quilt/0.68 Date: Sat, 19 Jul 2025 13:57:55 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, John Kacur , Luis Goncalves , Attila Fazekas , Tomas Glozar Subject: [for-linus][PATCH 1/2] tracing/osnoise: Fix crash in timerlat_dump_stack() References: <20250719175754.996594784@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: Tomas Glozar We have observed kernel panics when using timerlat with stack saving, with the following dmesg output: memcpy: detected buffer overflow: 88 byte write of buffer size 0 WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x5= 5/0xa0 CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-= 200.fc42.x86_64 #1 PREEMPT(lazy) Call Trace: ? trace_buffer_lock_reserve+0x2a/0x60 __fortify_panic+0xd/0xf __timerlat_dump_stack.cold+0xd/0xd timerlat_dump_stack.part.0+0x47/0x80 timerlat_fd_read+0x36d/0x390 vfs_read+0xe2/0x390 ? syscall_exit_to_user_mode+0x1d5/0x210 ksys_read+0x73/0xe0 do_syscall_64+0x7b/0x160 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e __timerlat_dump_stack() constructs the ftrace stack entry like this: struct stack_entry *entry; ... memcpy(&entry->caller, fstack->calls, size); entry->size =3D fstack->nr_entries; Since commit e7186af7fb26 ("tracing: Add back FORTIFY_SOURCE logic to kernel_stack event structure"), struct stack_entry marks its caller field with __counted_by(size). At the time of the memcpy, entry->size contains garbage from the ringbuffer, which under some circumstances is zero, triggering a kernel panic by buffer overflow. Populate the size field before the memcpy so that the out-of-bounds check knows the correct size. This is analogous to __ftrace_trace_stack(). Cc: stable@vger.kernel.org Cc: John Kacur Cc: Luis Goncalves Cc: Attila Fazekas Link: https://lore.kernel.org/20250716143601.7313-1-tglozar@redhat.com Fixes: e7186af7fb26 ("tracing: Add back FORTIFY_SOURCE logic to kernel_stac= k event structure") Signed-off-by: Tomas Glozar Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) --- kernel/trace/trace_osnoise.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c index 6819b93309ce..fd259da0aa64 100644 --- a/kernel/trace/trace_osnoise.c +++ b/kernel/trace/trace_osnoise.c @@ -637,8 +637,8 @@ __timerlat_dump_stack(struct trace_buffer *buffer, stru= ct trace_stack *fstack, u =20 entry =3D ring_buffer_event_data(event); =20 - memcpy(&entry->caller, fstack->calls, size); entry->size =3D fstack->nr_entries; + memcpy(&entry->caller, fstack->calls, size); =20 trace_buffer_unlock_commit_nostack(buffer, event); } --=20 2.47.2 From nobody Mon Oct 6 15:12:20 2025 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 3EC0F221550; Sat, 19 Jul 2025 17:57:53 +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=1752947874; cv=none; b=r6veibJNUxowvlK9ksMuLTLupVmkzDz16LTG4qp310JdSdIEak+ysi7ajmD/bzXnyTDL5He5IbtVImvw9w0b6wWnHoY8Chy/i2S5TNgSDwAaAtTfAFeWvqEawdg7z8vle4CEMQAfTYabmHDVqZzdBiLq2jEWGYYyKCB71IYh4oU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752947874; c=relaxed/simple; bh=SgO5r3HKnNBU0sLniQLn4+H/1Vma8XHldf0X3/vnXwc=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=mxDTThmPiEfJ6hHg0zB8rrgnUtO0QTCJKiPQkQMiiPWwV8ncNaOFQooKmQEhnYthYN539c/YlWyKJSB2EyTHBRhi9kxRL0IIbOxAruHDLq1r9jrbss1yhRt7vVUOV7Tdcyjo8Yf4EBXmQxG9avP6ccgBsJ4DlV17GgeV36/egdw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U7A9GgoL; 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="U7A9GgoL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8795C4CEF5; Sat, 19 Jul 2025 17:57:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752947873; bh=SgO5r3HKnNBU0sLniQLn4+H/1Vma8XHldf0X3/vnXwc=; h=Date:From:To:Cc:Subject:References:From; b=U7A9GgoLDs99xBBf3ewA2NCTsfRjYQxUwpS3gO5dd5ps0CBIdfD3YsbwKagrmtm7G YC3JXQtrGxpkStp7XaleCXWMjbj6vKV5hlf235AwWvQwUtLbSp9dHxq79hzOgJODTA 8JBYU3jVg4jE7GXN1c8iUSkOrHQsG/VwOkDLEw0JRoBWadmJT6+RWP5jHxR6YvH6lk 7ndL+IBC1quvU8LtgVhpzjlpkQz7iCQuB7mONoVAaLPiF+tF0Tj9k5tyZ1NSXiJP2M 36JpuT+CMWKDpDyVJ7zTP0PP1olrK/RgYgcWB23EIRFxsQltd4T7lOGCbI8Xm2dKgE WdAMTtMubzHXg== Received: from rostedt by gandalf with local (Exim 4.98.2) (envelope-from ) id 1udBpE-000000085Ht-00DT; Sat, 19 Jul 2025 13:58:20 -0400 Message-ID: <20250719175819.850873535@kernel.org> User-Agent: quilt/0.68 Date: Sat, 19 Jul 2025 13:57:56 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, =?UTF-8?q?Fusheng=20Huang(=E9=BB=84=E5=AF=8C=E7=94=9F)?= Subject: [for-linus][PATCH 2/2] tracing: Add down_write(trace_event_sem) when adding trace event References: <20250719175754.996594784@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Steven Rostedt When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values. If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel. The addition of the event should take the trace_event_sem for write while it adds the new event. Also add a lockdep_assert_held() on that semaphore in __trace_add_event_dirs() as it iterates the list. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Acked-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/20250718223158.799bfc0c@batman.local.home Reported-by: Fusheng Huang(=E9=BB=84=E5=AF=8C=E7=94=9F) Closes: https://lore.kernel.org/all/20250717105007.46ccd18f@batman.local.ho= me/ Fixes: 110bf2b764eb6 ("tracing: add protection around module events unload") Signed-off-by: Steven Rostedt (Google) --- kernel/trace/trace_events.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 120531268abf..d01e5c910ce1 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -3136,7 +3136,10 @@ __register_event(struct trace_event_call *call, stru= ct module *mod) if (ret < 0) return ret; =20 + down_write(&trace_event_sem); list_add(&call->list, &ftrace_events); + up_write(&trace_event_sem); + if (call->flags & TRACE_EVENT_FL_DYNAMIC) atomic_set(&call->refcnt, 0); else @@ -3750,6 +3753,8 @@ __trace_add_event_dirs(struct trace_array *tr) struct trace_event_call *call; int ret; =20 + lockdep_assert_held(&trace_event_sem); + list_for_each_entry(call, &ftrace_events, list) { ret =3D __trace_add_new_event(call, tr); if (ret < 0) --=20 2.47.2