Re: [PATCH] tracing/user_events: Clear copied tracing state before fork duplication

[Bradley Morgan]

On 25 August 2026 15:44:33 BST, Steven Rostedt <rostedt@xxxxxxxxxxx> 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@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
>> 
>> 
>> >  }
>> >    
>> 
>
>

Thanks!