Re: [PATCH] tracing: Take trace_array reference when opening options file

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 01 Sep 2026 20:54:20 +0000
sashiko-bot@kernel.org wrote:

> [Severity: High]
> Does this raw memory address comparison account for reallocation of the
> trace_array struct?
> 
> If a trace instance is deleted, its trace_array is freed. If a new instance
> is subsequently created, it could be allocated at the exact same memory
> address. Could a user holding an O_PATH file descriptor to a core options
> file of the deleted instance reopen it and manipulate the tracer flags of
> the newly allocated instance?

Yes, and we don't care ;-)

If the admin is deleting and creating trace instances and opening
option files at the same time, it's their own fault if the wrong trace
instance option gets changed.

> 
> > +			return __trace_array_get(tr);  
> 
> [Severity: Low]
> Will this compile successfully? It appears __trace_array_get() is an
> undeclared function, which might cause a build failure.

Really?

Then what's this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/trace/trace.c#n614
?

> 
> > +	}
> > +	return -ENODEV;
> > +}  
> 
> [ ... ]
> 
> >  static const struct file_operations trace_options_core_fops = {
> > -	.open = tracing_open_generic,
> > -	.read = trace_options_core_read,
> > -	.write = trace_options_core_write,
> > -	.llseek = generic_file_llseek,
> > +	.open		= trace_options_open,
> > +	.read		= trace_options_core_read,
> > +	.write		= trace_options_core_write,
> > +	.llseek		= generic_file_llseek,
> > +	.release	= trace_options_release,
> >  };  
> 
> [Severity: Critical]
> This is a pre-existing issue, but does this same Use-After-Free
> vulnerability also exist for tracer-specific options and other
> per-instance files?
> 
> While this patch addresses core option files by replacing
> tracing_open_generic with trace_options_open, files like
> tracing_max_latency and tracer-specific options still appear to use
> tracing_open_generic, which doesn't take a reference to the
> trace_array.
> 
> For example, if a user opens a per-instance tracing_max_latency file,
> keeps the descriptor open, and the instance is removed, could a
> subsequent write dereference the freed memory?
> 
> kernel/trace/trace.c:tracing_max_lat_write() {
>     ...
>     return tracing_nsecs_write(filp->private_data, ubuf, cnt, ppos);
> }
> 
> Where tracing_nsecs_write would perform an unlocked write to the
> freed pointer?

Possibly, but this one was a bit more complex than those others will be
to fix.

-- Steve