Re: [PATCH] tracing/user_events: Fail fork when event state duplication fails

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 6 Oct 2026 08:01:14 -0400
Jeff Barnes <jeffbarnes@linux.microsoft.com> wrote:

> Yes, that was intentional. My concern with allowing fork() to succeed
> after removing the child's user_events state is that the allocation
> failure then becomes a silent loss of inherited tracing state.
> 
> The enable word is the userspace-visible indication that an event is
> enabled. If the child loses its inherited enablers, later enable and
> disable changes will no longer be reflected in that child. Removing the
> state fixes the stale-value inconsistency, but userspace has no
> indication from fork() that the child is no longer following the
> inherited tracing state.
> 
> I also think there is a potential security implication here. If
> user_events are being used for tracing or auditing, an allocation
> failure could result in a successfully created child silently no longer
> following subsequent enablement changes. I don't want to characterize
> that as a security vulnerability without a demonstrated security
> boundary, but silently losing that state seems undesirable for auditing
> in particular.
> 
> That is why I favored returning -ENOMEM: either the child is created
> with the inherited user_events state intact, or the failure is visible
> to userspace and the fork is unwound.
> 
> I agree that uprobes provides a useful comparison. If you think
> user_events should likewise be best-effort across fork, then removing
> the state on duplication failure would address the inconsistency without
> introducing the new fork() failure path.

Question, to use user events the application needs to be involved,
correct? That is, there's code in the application specific for
user_events, as supposed to uprobes that can attach to any application.

Thus, it makes sense for uprobes to only warn on failure. Why should a
task fail to fork if something attaches a uprobe on it and it causes
issues.

Now if user_events is driven by the application that has them, then
yes, it makes sense for fork() to fail if the user_event it created
fails processing inside the fork(). If the user application is
expecting something, then if it fails it should know about it.

But this is only if user_events is driven by the application doing the
fork().

-- Steve