Re: [PATCH] tracing/user_events: Clear copied tracing state before fork duplication
From: Steven Rostedt
Date: Tue Aug 25 2026 - 10:50:19 EST
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
On Mon, 24 Aug 2026 21:50:40 -0400
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> On Mon, 24 Aug 2026 21:08:15 +0000
> Jérémy Jean <Jeremy.Jean@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx>
> > ---
> > 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
>
>
> > }
> >
>