Re: tracing: user events UAF crash report

[Mathias Krause]

On 25.07.24 19:16, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 13:10:21 -0400
> Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>>
>> diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
>> index 3a2b46847c8b..e9ed2826ff46 100644
>> --- a/kernel/trace/trace_events_user.c
>> +++ b/kernel/trace/trace_events_user.c
>> @@ -321,6 +321,8 @@ static void user_event_put(struct user_event *user, bool locked)
>>  	 */
>>  	refcount_set(&user->refcnt, 1);
>>  
>> +	user->call.data = NULL;
> 
> Hmm, it may be possible to just have:
> 
> 	user->call.get_fields = NULL;
> 
> and then it will just use the call->class->fields instead and that should
> be initialized to empty.

Uhm, it's 'user' that has been free'd which makes all of the above
reading/writing already free'd memory. So no, I don't think that'll fly.

In fact, in our test environment with memory sanitation features enabled
we saw that dereferencing 'class' in trace_get_fields() trapping
(because the underlying object was free'd).

> 
> -- Steve
> 

> 
>> +
>>  	if (WARN_ON_ONCE(!schedule_work(&user->put_work))) {
>>  		/*
>>  		 * If we fail we must wait for an admin to attempt delete or
>> @@ -973,6 +975,11 @@ size_t copy_nofault(void *addr, size_t bytes, struct iov_iter *i)
>>  static struct list_head *user_event_get_fields(struct trace_event_call *call)
>>  {
>>  	struct user_event *user = (struct user_event *)call->data;

Dereferencing a potentially free'd object, so 'user' is now "random" data.

>> +	static LIST_HEAD(head);
>> +
>> +	/* If the user event is about to be deleted, return no fields */
>> +	if (!user)
>> +		return &head;
>>  
>>  	return &user->fields;
>>  }
> 

Thanks,
Mathias