Re: [PATCH] tracing: reject trace events with an empty TP_STRUCT__entry

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] tracing: user_events broken by fields_array[0].type check
--

commit e8b9d44518a8f72216cba6b41f5a36c08fdcef3c
Author: Haoran Wang <haoranwangsec@gmail.com>

tracing: reject trace events with an empty TP_STRUCT__entry

This patch adds a check in event_init() to reject trace events that have
an empty TP_STRUCT__entry by returning -EINVAL if the first element of
fields_array has a NULL type.

> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 30c0ddf90887f..9f79fbdf40a20 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -3406,6 +3406,10 @@ static int event_init(struct trace_event_call *call)
>  	if (WARN_ON(!name))
>  		return -EINVAL;
>  
> +	if (call->class->fields_array &&
> +	    !call->class->fields_array[0].type)
> +		return -EINVAL;

[Severity: High]
Does this inadvertently break the user_events subsystem?

In kernel/trace/trace_events_user.c, user_events are assigned a statically
initialized dummy array:

kernel/trace/trace_events_user.c:
static struct trace_event_fields user_event_fields_array[1];

Because this array is size 1 and zero-initialized, its first element's type
field is implicitly NULL. When user_events are registered from userspace via
the ABI, __register_event() calls event_init(), which will evaluate this new
check to true and unconditionally return -EINVAL.

Can we find another way to handle empty TP_STRUCT__entry events that won't
cause a feature regression for user_events?

> +
>  	if (call->class->raw_init) {
>  		ret = call->class->raw_init(call);
>  		if (ret < 0 && ret != -ENOSYS)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/6ad1cad5.856c1b21.18f9b7.a2c3@mx.google.com?part=1