Re: [PATCH v5 01/18] tracing/remotes: Gate tracefs files opening on trace remote registration

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 [off-list ref]
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().

quoted

--- a/kernel/trace/trace_remote.c
+++ b/kernel/trace/trace_remote.c

[ ... ]

quoted

@@ -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/20260812161340.2417322-1-vdonnefort@google.com?part=1