On Wed, Aug 12, 2026 at 04:31:10PM +0000, [email protected] wrote: > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) > to consider: > - [High] Incomplete tracefs gating: Caller-created tracefs files bypass the > newly introduced `trace_remote_tracefs_open` gating, leaving them fully > accessible if registration fails. > -- > > --- Patch [1]: [PATCH v5 01/18] tracing/remotes: Gate tracefs files opening > on trace remote registration --- > commit 63ef30c302e1341f240b4f5b82d4e65d421da4cf > Author: Vincent Donnefort <[email protected]> > tracing/remotes: Gate tracefs files opening on trace remote registration > > This commit adds a global list of registered trace remotes and a gating > function to prevent access to tracefs files for remotes that are being > destroyed or failed to register. Standard trace remote file operations > are wrapped to check this list before allowing open(). > > > --- a/kernel/trace/trace_remote.c > > +++ b/kernel/trace/trace_remote.c > > [ ... ] > > > @@ -932,8 +999,12 @@ int trace_remote_register(const char *name, struct > > trace_remote_callbacks *cbs, > > } > > > > ret = cbs->init ? cbs->init(remote->dentry, priv) : 0; > > - if (ret) > > + if (ret) { > > pr_err("Init failed for trace remote '%s' (%d)\n", name, ret); > > + } else { > > + guard(mutex)(&trace_remotes_lock); > > + list_add(&remote->node, &trace_remotes); > > + } > > > > return ret; > > } > > [Severity: High] > Does this leave caller-created tracefs files exposed if cbs->init() fails? > > If a remote's initialization fails halfway through, any custom tracefs files > already created by cbs->init() will leak and remain accessible. Because > trace_remote_tracefs_open() is static to trace_remote.c, the caller cannot > wrap their custom files' open() callbacks with this new gating mechanism. > > For example, if KVM's hyp_trace_init_tracefs() successfully creates > a 'write_event' file but fails later, trace_remote_register() returns an > error and the remote is not added to the trace_remotes list. > > Userspace could then open the leaked 'write_event' file, bypassing the > gating entirely, and trigger kvm_call_hyp_nvhe() against the uninitialized > hypervisor stub. > > Should trace_remote_tracefs_open() be exported so that subsystems can gate > their custom files, or should the leaked files be cleaned up when > trace_remote_register() returns an error? > > -- > Sashiko AI review ยท > https://sashiko.dev/#/patchset/[email protected]?part=1
In the following patch, the tracefs folder is entirely removed on init failure. -- Vincent
