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

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

[Jérémy Jean]

dup_task_struct() copies user_event_mm from the parent into the child,
without grabbing a reference to it. user_event_mm_dup() should
replace it, but it leaves that copied pointer unmodified if
user_event_mm_alloc() fails.

When the child exits, user_event_mm_remove() decrements a reference
the child never owned, which ultimately frees user_event_mm, while
the parent still as a stale pointer to it. This creates a UAF, which
KASAN reports as:

    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

The fix simply clears the copied pointer before starting the
duplication, before any possible failure. In case of failure,
the child then has nothing to free.

Fixes: 7235759084a4 ("tracing/user_events: Use remote writes for event enablement")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
---

Change in v2:
 Move the pointer reset into user_event_mm_dup(), before the first
 allocation (suggestion by Steven Rostedt).

 kernel/trace/trace_events_user.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
index 2bbc89d4a266..339e18085af3 100644
--- a/kernel/trace/trace_events_user.c
+++ b/kernel/trace/trace_events_user.c
@@ -865,9 +865,12 @@ void user_event_mm_remove(struct task_struct *t)
 
 void user_event_mm_dup(struct task_struct *t, struct user_event_mm *old_mm)
 {
-	struct user_event_mm *mm = user_event_mm_alloc(t);
+	struct user_event_mm *mm;
 	struct user_event_enabler *enabler;
 
+	t->user_event_mm = NULL;
+	mm = user_event_mm_alloc(t);
+
 	if (!mm)
 		return;
 
-- 
2.47.3

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

[Bradley Morgan]

On 26 August 2026 22:44:15 BST, "Jérémy Jean"
<Jeremy.Jean@oss.cyber.gouv.fr> wrote:
>
>dup_task_struct() copies user_event_mm from the parent into the child,
>without grabbing a reference to it. user_event_mm_dup() should
>replace it, but it leaves that copied pointer unmodified if
>user_event_mm_alloc() fails.
>
>When the child exits, user_event_mm_remove() decrements a reference
>the child never owned, which ultimately frees user_event_mm, while
>the parent still as a stale pointer to it. This creates a UAF, which
>KASAN reports as:
>
>    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
>
>The fix simply clears the copied pointer before starting the
>duplication, before any possible failure. In case of failure,
>the child then has nothing to free.
>
>Fixes: 7235759084a4 ("tracing/user_events: Use remote writes for event enablement")
>Cc: stable@vger.kernel.org
>Assisted-by: Codex:gpt-5
>Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
>---
>
>Change in v2:
> Move the pointer reset into user_event_mm_dup(), before the first
> allocation (suggestion by Steven Rostedt).
>
> kernel/trace/trace_events_user.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
>diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
>index 2bbc89d4a266..339e18085af3 100644
>--- a/kernel/trace/trace_events_user.c
>+++ b/kernel/trace/trace_events_user.c
>@@ -865,9 +865,12 @@ void user_event_mm_remove(struct task_struct *t)
> 
> void user_event_mm_dup(struct task_struct *t, struct user_event_mm
> *old_mm)
> {
>-	struct user_event_mm *mm = user_event_mm_alloc(t);
>+	struct user_event_mm *mm;
> 	struct user_event_enabler *enabler;
> 

Comment?

/* Failure must leave the child with no copied state to free. */

I mean, okay, you don't got to, but itd be nice, if your happy with it, add

Reviewed-by: Bradley Morgan <brads@mainlining.org>


Also, let me talk about one of Steve's nits a bit, yk, the one where he
says the description is too long

Maybe you could add this to your memories


"The description length should be about the same as the change being
added,unless there is a splat, or something else like a table which needs
to be added to the description, keep the description length the same as
thepatch size, e.g:

Instead of doing 3 paragraths about a one liner, we could do a small two
or more line description describing:

What causes the issue?
Why is it bad?
How did you fix it?"

That should work for you. Just to prevent annoying other maintainers 


>+	t->user_event_mm = NULL;
>+	mm = user_event_mm_alloc(t);
>+
> 	if (!mm)
> 		return;
> 
>


--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Jérémy Jean]

>> diff --git a/kernel/trace/trace_events_user.c 
>> b/kernel/trace/trace_events_user.c
>> index 2bbc89d4a266..339e18085af3 100644
>> --- a/kernel/trace/trace_events_user.c
>> +++ b/kernel/trace/trace_events_user.c
>> @@ -865,9 +865,12 @@ void user_event_mm_remove(struct task_struct *t)
>> 
>> void user_event_mm_dup(struct task_struct *t, struct user_event_mm
>> *old_mm)
>> {
>> -	struct user_event_mm *mm = user_event_mm_alloc(t);
>> +	struct user_event_mm *mm;
>> 	struct user_event_enabler *enabler;
>> 
> 
> Comment?
> 
> /* Failure must leave the child with no copied state to free. */
> 
> I mean, okay, you don't got to, but itd be nice, if your happy with it, 
> add
> 
> Reviewed-by: Bradley Morgan <brads@mainlining.org>

I usually don't think about adding comments, but yes, that's a good 
suggestion.

> Maybe you could add this to your memories
> 
> "The description length should be about the same as the change being
> added,unless there is a splat, or something else like a table which 
> needs
> to be added to the description, keep the description length the same as
> thepatch size, e.g:
> 
> Instead of doing 3 paragraths about a one liner, we could do a small 
> two
> or more line description describing:
> 
> What causes the issue?
> Why is it bad?
> How did you fix it?"

Sounds like a good practical advice, thanks. Yet in the present case,
since there is a security issue with the UAF, I felt that it was
important to explain where it came from instead of something very
short along the lines ("fixing a UAF"), hence the couple of paragraphs
and the KASAN output.

Anyway, noted, and here is a shortened version that skips some details:

Clear the child's user_event_mm pointer before duplication so that a
failure in user_event_mm_alloc() cannot leave the inherited parent
pointer in place, which otherwise triggers a UAF.
(+ KASAN output)

I will send a v3 if you feel that's good enough.

Regards,
Jérémy

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

[Bradley Morgan]

On 27 August 2026 08:15:33 BST, "Jérémy Jean"
<jeremy.jean@oss.cyber.gouv.fr> wrote:
>
>>> diff --git a/kernel/trace/trace_events_user.c
>b/kernel/trace/trace_events_user.c
>>> index 2bbc89d4a266..339e18085af3 100644
>>> --- a/kernel/trace/trace_events_user.c
>>> +++ b/kernel/trace/trace_events_user.c
>>> @@ -865,9 +865,12 @@ void user_event_mm_remove(struct task_struct *t)
>>> 
>>> void user_event_mm_dup(struct task_struct *t, struct user_event_mm
>>> *old_mm)
>>> {
>>> -	struct user_event_mm *mm = user_event_mm_alloc(t);
>>> +	struct user_event_mm *mm;
>>> 	struct user_event_enabler *enabler;
>>> 
>> 
>> Comment?
>> 
>> /* Failure must leave the child with no copied state to free. */
>> 
>> I mean, okay, you don't got to, but itd be nice, if your happy with it,
>add
>> 
>> Reviewed-by: Bradley Morgan <brads@mainlining.org>
>
>I usually don't think about adding comments, but yes, that's a good
>suggestion.
>
>> Maybe you could add this to your memories
>> 
>> "The description length should be about the same as the change being
>> added,unless there is a splat, or something else like a table which
>needs
>> to be added to the description, keep the description length the same as
>> thepatch size, e.g:
>> 
>> Instead of doing 3 paragraths about a one liner, we could do a small two
>> or more line description describing:
>> 
>> What causes the issue?
>> Why is it bad?
>> How did you fix it?"
>
>Sounds like a good practical advice, thanks. Yet in the present case,
>since there is a security issue with the UAF, I felt that it was
>important to explain where it came from instead of something very
>short along the lines ("fixing a UAF"), hence the couple of paragraphs
>and the KASAN output.
>

umm, you could include a ASCII table or something, that signifies the bug?

>Anyway, noted, and here is a shortened version that skips some details:
>
>Clear the child's user_event_mm pointer before duplication so that a
>failure in user_event_mm_alloc() cannot leave the inherited parent
>pointer in place, which otherwise triggers a UAF.
>(+ KASAN output)

Hmm, I'm iffy on this,

As in, You saying "which triggers a uaf"

Wait no, that does sound right, yeah that's fine, you don't need to su
Bmit
a v3, since the length is fine, but yeah.


>I will send a v3 if you feel that's good enough.
>
>Regards,
>Jérémy

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Steven Rostedt]

On Thu, 27 Aug 2026 10:45:29 +0100
Bradley Morgan <brads@mainlining.org> wrote:

> >I usually don't think about adding comments, but yes, that's a good
> >suggestion.
> >  
> >> Maybe you could add this to your memories
> >> 
> >> "The description length should be about the same as the change being
> >> added,unless there is a splat, or something else like a table which  
> >needs  
> >> to be added to the description, keep the description length the same as
> >> thepatch size, e.g:

No that is not correct. In fact, some of my longest change logs are
one-liners and my big changes are small descriptions.

A one-line can be extremely subtle and require a deep description of the
problem. Big changes may be "Implement this feature" with a description of
the feature that is much shorter than the code used to create it.

> >> 
> >> Instead of doing 3 paragraths about a one liner, we could do a small two
> >> or more line description describing:
> >> 
> >> What causes the issue?
> >> Why is it bad?
> >> How did you fix it?"  
> >
> >Sounds like a good practical advice, thanks. Yet in the present case,
> >since there is a security issue with the UAF, I felt that it was
> >important to explain where it came from instead of something very
> >short along the lines ("fixing a UAF"), hence the couple of paragraphs
> >and the KASAN output.
> >  
> 
> umm, you could include a ASCII table or something, that signifies the bug?

I think the change log is fine and doesn't need to be changed.

The added comment to the code is fine though.

Thanks,

-- Steve

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

[Bradley Morgan]

On 27 August 2026 13:15:31 BST, Steven Rostedt <rostedt@goodmis.org> wrote:
>On Thu, 27 Aug 2026 10:45:29 +0100
>Bradley Morgan <brads@mainlining.org> wrote:
>
>> >I usually don't think about adding comments, but yes, that's a good
>> >suggestion.
>> >  
>> >> Maybe you could add this to your memories
>> >> 
>> >> "The description length should be about the same as the change being
>> >> added,unless there is a splat, or something else like a table which  
>> >needs  
>> >> to be added to the description, keep the description length the same
>as
>> >> thepatch size, e.g:
>
>No that is not correct. In fact, some of my longest change logs are
>one-liners and my big changes are small descriptions.
>
>A one-line can be extremely subtle and require a deep description of the
>problem. Big changes may be "Implement this feature" with a description of
>the feature that is much shorter than the code used to create it.
>

Hmm, could be right, my memory isn't perfect, don't worry.

>> >> 
>> >> Instead of doing 3 paragraths about a one liner, we could do a small
>two
>> >> or more line description describing:
>> >> 
>> >> What causes the issue?
>> >> Why is it bad?
>> >> How did you fix it?"  
>> >
>> >Sounds like a good practical advice, thanks. Yet in the present case,
>> >since there is a security issue with the UAF, I felt that it was
>> >important to explain where it came from instead of something very
>> >short along the lines ("fixing a UAF"), hence the couple of paragraphs
>> >and the KASAN output.
>> >  
>> 
>> umm, you could include a ASCII table or something, that signifies the
>bug?
>
>I think the change log is fine and doesn't need to be changed.
>

Yeah, I do too.

>The added comment to the code is fine though.

:)

>
>Thanks,
>
>-- Steve

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Steven Rostedt]

On Wed, 26 Aug 2026 21:44:15 +0000
Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> wrote:
> diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
> index 2bbc89d4a266..339e18085af3 100644
> --- a/kernel/trace/trace_events_user.c
> +++ b/kernel/trace/trace_events_user.c
> @@ -865,9 +865,12 @@ void user_event_mm_remove(struct task_struct *t)
>  
>  void user_event_mm_dup(struct task_struct *t, struct user_event_mm *old_mm)
>  {
> -	struct user_event_mm *mm = user_event_mm_alloc(t);
> +	struct user_event_mm *mm;

Why this change?

>  	struct user_event_enabler *enabler;
>  
> +	t->user_event_mm = NULL;
> +	mm = user_event_mm_alloc(t);

I don't see why you moved the mm assignment down here. The t->user_event_mm
is not used in user_event_mm_alloc().

-- Steve

> +
>  	if (!mm)
>  		return;
>  

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

[Bradley Morgan]

On 27 August 2026 13:08:39 BST, Steven Rostedt <rostedt@goodmis.org> wrote:
>On Wed, 26 Aug 2026 21:44:15 +0000
>Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> wrote:
>> diff --git a/kernel/trace/trace_events_user.c
>b/kernel/trace/trace_events_user.c
>> index 2bbc89d4a266..339e18085af3 100644
>> --- a/kernel/trace/trace_events_user.c
>> +++ b/kernel/trace/trace_events_user.c
>> @@ -865,9 +865,12 @@ void user_event_mm_remove(struct task_struct *t)
>>  
>>  void user_event_mm_dup(struct task_struct *t, struct user_event_mm
>*old_mm)
>>  {
>> -	struct user_event_mm *mm = user_event_mm_alloc(t);
>> +	struct user_event_mm *mm;
>
>Why this change?
>
>>  	struct user_event_enabler *enabler;
>>  
>> +	t->user_event_mm = NULL;
>> +	mm = user_event_mm_alloc(t);
>
>I don't see why you moved the mm assignment down here. The
>t->user_event_mm
>is not used in user_event_mm_alloc().

Uff, not wrong, I must be dummy dumb dumb, well, I base my reviews off 

Does this fix the bug? And is this a small fix?


>
>-- Steve
>
>> +
>>  	if (!mm)
>>  		return;
>>  
>

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Steven Rostedt]

On Thu, 27 Aug 2026 13:09:44 +0100
Bradley Morgan <brads@mainlining.org> wrote:

> >> @@ -865,9 +865,12 @@ void user_event_mm_remove(struct task_struct *t)
> >>  
> >>  void user_event_mm_dup(struct task_struct *t, struct user_event_mm  
> >*old_mm)  
> >>  {
> >> -	struct user_event_mm *mm = user_event_mm_alloc(t);
> >> +	struct user_event_mm *mm;  
> >
> >Why this change?
> >  
> >>  	struct user_event_enabler *enabler;
> >>  
> >> +	t->user_event_mm = NULL;
> >> +	mm = user_event_mm_alloc(t);  
> >
> >I don't see why you moved the mm assignment down here. The
> >t->user_event_mm
> >is not used in user_event_mm_alloc().  
> 
> Uff, not wrong, I must be dummy dumb dumb, well, I base my reviews off 
> 
> Does this fix the bug? And is this a small fix?
> 

The bug is fixed because it needs to NULL out that value. I asked from v1
to move that change to this function. But this function only needs to add
that line before the return. It doesn't need to modify anything else in
that function.

That is, something like this:

diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
index 8c82ecb735f4..6b89d225b189 100644
--- a/kernel/trace/trace_events_user.c
+++ b/kernel/trace/trace_events_user.c
@@ -868,6 +868,9 @@ void user_event_mm_dup(struct task_struct *t, struct user_event_mm *old_mm)
 	struct user_event_mm *mm = user_event_mm_alloc(t);
 	struct user_event_enabler *enabler;
 
+	/* On failure, do not free parent's copy */
+	t->user_event_mm = NULL;
+
 	if (!mm)
 		return;
 

-- Steve

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

[Bradley Morgan]

On 27 August 2026 13:19:15 BST, Steven Rostedt <rostedt@goodmis.org> wrote:
>On Thu, 27 Aug 2026 13:09:44 +0100
>Bradley Morgan <brads@mainlining.org> wrote:
>
>> >> @@ -865,9 +865,12 @@ void user_event_mm_remove(struct task_struct *t)
>> >>  
>> >>  void user_event_mm_dup(struct task_struct *t, struct user_event_mm  
>> >*old_mm)  
>> >>  {
>> >> -	struct user_event_mm *mm = user_event_mm_alloc(t);
>> >> +	struct user_event_mm *mm;  
>> >
>> >Why this change?
>> >  
>> >>  	struct user_event_enabler *enabler;
>> >>  
>> >> +	t->user_event_mm = NULL;
>> >> +	mm = user_event_mm_alloc(t);  
>> >
>> >I don't see why you moved the mm assignment down here. The
>> >t->user_event_mm
>> >is not used in user_event_mm_alloc().  
>> 
>> Uff, not wrong, I must be dummy dumb dumb, well, I base my reviews off 
>> 
>> Does this fix the bug? And is this a small fix?
>> 
>
>The bug is fixed because it needs to NULL out that value. I asked from v1
>to move that change to this function. But this function only needs to add
>that line before the return. It doesn't need to modify anything else in
>that function.
>
>That is, something like this:
>
>diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
>index 8c82ecb735f4..6b89d225b189 100644
>--- a/kernel/trace/trace_events_user.c
>+++ b/kernel/trace/trace_events_user.c
>@@ -868,6 +868,9 @@ void user_event_mm_dup(struct task_struct *t, struct user_event_mm *old_mm)
> 	struct user_event_mm *mm = user_event_mm_alloc(t);
> 	struct user_event_enabler *enabler;
> 
>+	/* On failure, do not free parent's copy */
>+	t->user_event_mm = NULL;
>+

Sorry to be mr begfortags here, but this also LGTM, this fixes the bug,
andit's short, thanks for the patch, since I'm busy rn, add my tag if jean
is to submit this 

> 	if (!mm)
> 		return;
> 
>
>-- Steve

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Jérémy Jean]

On 2026-08-27 14:19, Steven Rostedt wrote:
> On Thu, 27 Aug 2026 13:09:44 +0100
> Bradley Morgan <brads@mainlining.org> wrote:
> 
>> >> @@ -865,9 +865,12 @@ void user_event_mm_remove(struct task_struct *t)
>> >>
>> >>  void user_event_mm_dup(struct task_struct *t, struct user_event_mm
>> >*old_mm)
>> >>  {
>> >> -	struct user_event_mm *mm = user_event_mm_alloc(t);
>> >> +	struct user_event_mm *mm;
>> >
>> >Why this change?
>> >
>> >>  	struct user_event_enabler *enabler;
>> >>
>> >> +	t->user_event_mm = NULL;
>> >> +	mm = user_event_mm_alloc(t);
>> >
>> >I don't see why you moved the mm assignment down here. The
>> >t->user_event_mm
>> >is not used in user_event_mm_alloc().
>> 
>> Uff, not wrong, I must be dummy dumb dumb, well, I base my reviews off
>> 
>> Does this fix the bug? And is this a small fix?
>> 
> 
> The bug is fixed because it needs to NULL out that value. I asked from 
> v1
> to move that change to this function. But this function only needs to 
> add
> that line before the return. It doesn't need to modify anything else in
> that function.
> 
> That is, something like this:
> 
> diff --git a/kernel/trace/trace_events_user.c 
> b/kernel/trace/trace_events_user.c
> index 8c82ecb735f4..6b89d225b189 100644
> --- a/kernel/trace/trace_events_user.c
> +++ b/kernel/trace/trace_events_user.c
> @@ -868,6 +868,9 @@ void user_event_mm_dup(struct task_struct *t, 
> struct user_event_mm *old_mm)
>  	struct user_event_mm *mm = user_event_mm_alloc(t);
>  	struct user_event_enabler *enabler;
> 
> +	/* On failure, do not free parent's copy */
> +	t->user_event_mm = NULL;
> +
>  	if (!mm)
>  		return;
> 
> 
> -- Steve

Hello Steve,

Thanks for this. I thought that my previous version was okay
so that it was not required to read the details of
user_event_mm_alloc() to get convinced whether user_event_mm is
accessed or not, but it's true that in the end, this is not
required. Your fix is simpler. Do you want me to send a v3
with that simplification and the same changelog as in the v2?

Regards,
Jérémy

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

[Bradley Morgan]

On 27 August 2026 13:27:44 BST, "Jérémy Jean"
<jeremy.jean@oss.cyber.gouv.fr> wrote:
>On 2026-08-27 14:19, Steven Rostedt wrote:
>> On Thu, 27 Aug 2026 13:09:44 +0100
>> Bradley Morgan <brads@mainlining.org> wrote:
>> 
>>> >> @@ -865,9 +865,12 @@ void user_event_mm_remove(struct task_struct
>*t)
>>> >>
>>> >>  void user_event_mm_dup(struct task_struct *t, struct user_event_mm
>>> >*old_mm)
>>> >>  {
>>> >> -	struct user_event_mm *mm = user_event_mm_alloc(t);
>>> >> +	struct user_event_mm *mm;
>>> >
>>> >Why this change?
>>> >
>>> >>  	struct user_event_enabler *enabler;
>>> >>
>>> >> +	t->user_event_mm = NULL;
>>> >> +	mm = user_event_mm_alloc(t);
>>> >
>>> >I don't see why you moved the mm assignment down here. The
>>> >t->user_event_mm
>>> >is not used in user_event_mm_alloc().
>>> 
>>> Uff, not wrong, I must be dummy dumb dumb, well, I base my reviews off
>>> 
>>> Does this fix the bug? And is this a small fix?
>>> 
>> 
>> The bug is fixed because it needs to NULL out that value. I asked from
>v1
>> to move that change to this function. But this function only needs to
>add
>> that line before the return. It doesn't need to modify anything else in
>> that function.
>> 
>> That is, something like this:
>> 
>> diff --git a/kernel/trace/trace_events_user.c
>b/kernel/trace/trace_events_user.c
>> index 8c82ecb735f4..6b89d225b189 100644
>> --- a/kernel/trace/trace_events_user.c
>> +++ b/kernel/trace/trace_events_user.c
>> @@ -868,6 +868,9 @@ void user_event_mm_dup(struct task_struct *t, struct
>user_event_mm *old_mm)
>>  	struct user_event_mm *mm = user_event_mm_alloc(t);
>>  	struct user_event_enabler *enabler;
>> 
>> +	/* On failure, do not free parent's copy */
>> +	t->user_event_mm = NULL;
>> +
>>  	if (!mm)
>>  		return;
>> 
>> 
>> -- Steve
>
>Hello Steve,
>
>Thanks for this. I thought that my previous version was okay
>so that it was not required to read the details of
>user_event_mm_alloc() to get convinced whether user_event_mm is
>accessed or not, but it's true that in the end, this is not
>required. Your fix is simpler. Do you want me to send a v3
>with that simplification and the same changelog as in the v2?
>
>Regards,
>Jérémy
I wouldn't mind, add my tag, I review differently from Steven, so Steven
may not be happy at me :(

I review on


1: does this do what it's intended
2: does it fix X?
3: Any comments, any new functions used instead, any way to get the line count shorter?


And others, I apologise if I'm wrong. I just review in a different style.
--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Steven Rostedt]

On Thu, 27 Aug 2026 13:29:20 +0100
Bradley Morgan <brads@mainlining.org> wrote:

> I review on
> 
> 
> 1: does this do what it's intended
> 2: does it fix X?
> 3: Any comments, any new functions used instead, any way to get the line count shorter?
> 
> 
> And others, I apologise if I'm wrong. I just review in a different style.

Please just focus on correctness, until you understand what the
maintainer's preferences are.

-- Steve

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

[Bradley Morgan]

On 27 August 2026 13:43:06 BST, Steven Rostedt <rostedt@goodmis.org> wrote:
>On Thu, 27 Aug 2026 13:29:20 +0100
>Bradley Morgan <brads@mainlining.org> wrote:
>
>> I review on
>> 
>> 
>> 1: does this do what it's intended
>> 2: does it fix X?
>> 3: Any comments, any new functions used instead, any way to get the line
>count shorter?
>> 
>> 
>> And others, I apologise if I'm wrong. I just review in a different
>style.
>
>Please just focus on correctness, until you understand what the
>maintainer's preferences are.
>

Yep, I already do, I focus on if the code is actually correct too.

So don't panic. :)

>-- Steve

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Steven Rostedt]

On Thu, 27 Aug 2026 14:27:44 +0200
Jérémy Jean <jeremy.jean@oss.cyber.gouv.fr> wrote:

> Thanks for this. I thought that my previous version was okay
> so that it was not required to read the details of
> user_event_mm_alloc() to get convinced whether user_event_mm is
> accessed or not, but it's true that in the end, this is not
> required. Your fix is simpler. Do you want me to send a v3
> with that simplification and the same changelog as in the v2?

Yes, please send a v3.

Thanks,

-- Steve