On Tue, 01 Sep 2026 20:54:20 +0000 [email protected] 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
