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

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

[Jérémy Jean]

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.

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);
 }
 
-- 
2.47.3

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

[Bradley Morgan]

On 24 August 2026 22:10:37 BST, "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.
>
>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;


I had a think about this, I really feel this is okay.

Knowing me, I made a mistake. Hmmm. Should I do tag?

well.. this can't be wrong, it's a one liner, and a acceptable fix for a
bug.

okay, guess this works.

Reviewed-by: Bradley Morgan <include@grrlz.net>

Comment?, wait, no not really needed. Its small, and easy 

(Sorry, I think Out loud sometimes)


> 	user_event_mm_dup(t, old_mm);
> }
> 
>

Thanks!

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

[Steven Rostedt]

[ Replying again, but against the one with the Cc to the mailing lists ]

On Mon, 24 Aug 2026 21:10:37 +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;

Honestly, that line should be in user_event_mm_dup() and not here.

-- Steve

>  	user_event_mm_dup(t, old_mm);
>  }
>  

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

[Jérémy Jean]

On 2026-08-26 21:23, Steven Rostedt wrote:
>> 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;
> 
> Honestly, that line should be in user_event_mm_dup() and not here.

Thanks for the feedback. I have just sent a v2 implementing this.

Regards,
Jérémy

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

[Steven Rostedt]

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

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