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

[Steven Rostedt <rostedt@goodmis.org>]

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@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
> 
> 
> >  }
> >    
>