From: Bradley Morgan <include@grrlz.net>
To: "Steven Rostedt" <rostedt@goodmis.org>,
"Jérémy Jean" <Jeremy.Jean@oss.cyber.gouv.fr>
Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
LKML <linux-kernel@vger.kernel.org>,
Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>
Subject: Re: [PATCH] tracing/user_events: Clear copied tracing state before fork duplication
Date: Tue, 25 Aug 2026 15:46:41 +0100 [thread overview]
Message-ID: <1198FC08-4DFE-4504-AD09-73131E09CF16@grrlz.net> (raw)
In-Reply-To: <20260825104433.2f08ba46@gandalf.local.home>
On 25 August 2026 15:44:33 BST, Steven Rostedt <rostedt@goodmis.org> wrote:
>
>Oh, and you forgot to Cc any mailing list. You need to Cc linux-kernel and
>linux-trace-kernel to have this include, otherwise it will never appear in
>patchwork, which means it will never appear in the kernel.
>
>-- Steve
>
He knows, don't worry. He submitted another version, I thought it looked
okay. But you didn't, sorry for being wrong :(
>
>On Mon, 24 Aug 2026 21:50:40 -0400
>Steven Rostedt <rostedt@goodmis.org> wrote:
>
>> On Mon, 24 Aug 2026 21:08:15 +0000
>> Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> wrote:
>>
>> > User events keep per-mm tracing state in task_struct::user_event_mm.
>It
>> > tracks the registrations and enablers created through the tracefs
>> > user_events_data interface.
>> >
>> > dup_task_struct() starts a fork by copying this pointer from the
>parent.
>> > user_events_fork() must then either share it for CLONE_VM, or create
>new
>> > state for a child with a separate address space.
>> >
>> > The second case can fail. If user_event_mm_dup() cannot allocate the
>new
>> > state or copy one of its enablers, it returns without replacing the
>> > pointer copied by dup_task_struct(). The child now points at the
>parent's
>> > tracing state, but did not take a task reference to it.
>> >
>> > When the child exits, user_event_mm_remove() can drop the parent's
>task
>> > count to zero and queue its tracing state for release. The next
>> > user-events registration in the parent calls current_user_event_mm()
>and
>> > writes to the freed object.
>>
>> Please, do not cut and paste AI into your change log. Read it,
>> understand it, and summerize it!
>>
>> The above is just mumbo jumble and is way too verbose for such a simple
>> change. Show me you understand what the bug is. And tell me what was
>> wrong. The above is totally not helpful for a change log. It's way too
>> verbose and makes it very difficult to know what the bug is.
>>
>> >
>> > KASAN reports:
>> >
>> > BUG: KASAN: slab-use-after-free in
>current_user_event_mm+0x51/0x1d0
>> > Write of size 4 at addr ffff888005010d30 by task init/44
>> >
>> > Call Trace:
>> > <TASK>
>> > kasan_report+0xce/0x100
>> > kasan_check_range+0x10f/0x1e0
>> > current_user_event_mm+0x51/0x1d0
>> > user_events_ioctl+0x82e/0x15c0
>> > __x64_sys_ioctl+0x139/0x1c0
>> > do_syscall_64+0xce/0x450
>> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
>> >
>> > Allocated by task 44:
>> > __kasan_kmalloc+0x8f/0xa0
>> > __kmalloc_cache_noprof+0x180/0x3a0
>> > user_event_mm_alloc+0x3c/0x1f0
>> > current_user_event_mm+0x88/0x1d0
>> >
>> > Freed by task 42:
>> > __kasan_slab_free+0x43/0x70
>> > kfree+0x13a/0x390
>> > process_one_work+0x696/0xf90
>> > worker_thread+0x420/0xba0
>> >
>> > Clear the child's copied user_event_mm before starting the fallible
>> > duplication. If duplication fails, the child has no user-events
>tracing
>> > state to release. The CLONE_VM case remains unchanged because
>> > user_events_fork() explicitly installs the shared pointer and
>increments
>> > its task count.
>> >
>> > Fixes: 7235759084a4 ("tracing/user_events: Use remote writes for event
>enablement")
>> > Assisted-by: Codex:gpt-daybreak-blue
>> > Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
>> > ---
>> > include/linux/user_events.h | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/include/linux/user_events.h b/include/linux/user_events.h
>> > index 57d1ff0..2c9ac7b 100644
>> > --- a/include/linux/user_events.h
>> > +++ b/include/linux/user_events.h
>> > @@ -48,6 +48,7 @@ static inline void user_events_fork(struct
>task_struct *t,
>> > return;
>> > }
>> >
>> > + t->user_event_mm = NULL;
>> > user_event_mm_dup(t, old_mm);
>>
>> Honestly, that line should be in user_event_mm_dup() and not here.
>>
>> -- Steve
>>
>>
>> > }
>> >
>>
>
>
Thanks!
next prev parent reply other threads:[~2026-08-25 14:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260824210814.3726486-2-Jeremy.Jean@oss.cyber.gouv.fr>
[not found] ` <20260824215040.0509ff1b@fedora>
2026-08-25 14:44 ` [PATCH] tracing/user_events: Clear copied tracing state before fork duplication Steven Rostedt
2026-08-25 14:46 ` Bradley Morgan [this message]
2026-08-24 21:10 Jérémy Jean
2026-08-24 23:49 ` Bradley Morgan
2026-08-26 19:23 ` Steven Rostedt
2026-08-26 21:48 ` Jérémy Jean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1198FC08-4DFE-4504-AD09-73131E09CF16@grrlz.net \
--to=include@grrlz.net \
--cc=Jeremy.Jean@oss.cyber.gouv.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox