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

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

[Steven Rostedt]

From: Steven Rostedt <rostedt@goodmis.org>

The options files do not take the trace_array reference for the options
they represent. This could cause a use-after-free kernel crash if one of
these files is opened by one task and another task removes the instance
that the option is for. Because it doesn't take a reference upon opening,
it will not stop the removal which will free the options descriptor that
is being used.

As the options are somewhat dynamic in their creation at boot up, each
file represents a flag in the trace_array. The trace_array has an array of
indexes to represent each of these flags that is stored in the
trace_flags_index array. The address of the index array element is used to
pass to the inode->i_private pointer. Then that element is read which
holds the index (which represents the flag) and then the index is used to
calculate the trace_array descriptor from its trace_flags_index array.

One issue is that the index element can not be referenced until the
trace_array's reference is taken. To handle this, create a new helper
function called: trace_array_options_get() that will iterate all the
existing trace_arrays in the ftrace_trace_arrays list (under the
trace_types_lock), and compare the passed in address of the index element
with the entire array of the trace_array's trace_flags_index array.
If it matches, then up the corresponding trace_array's reference and
return.

Cc: stable@vger.kernel.org
Fixes: 577b785f55168 ("tracing: add tracer dependent options to options directory")
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/linux-trace-kernel/20260828135858.2AC501F000E9@smtp.kernel.org/
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 kernel/trace/trace.c | 67 +++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 63 insertions(+), 4 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index a946e0183fd1..61ca05ee991d 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -7842,11 +7842,70 @@ trace_options_core_write(struct file *filp, const char __user *ubuf, size_t cnt,
 	return cnt;
 }
 
+/*
+ * The tr_index is the address of a trace_array->trace_flags_index[]
+ * element that holds the index of the trace flag. But since the
+ * trace_array reference has not been taken yet, it cannot be referenced
+ * as it could have been freed by a rmdir of the instance the trace_array
+ * represents.
+ *
+ * Search the list of trace_arrays and compare the tr_index to the
+ * address of the entire trace_array trace_flags_index array for each
+ * trace_array in the list. If one is matched, then take the reference
+ * and return it. If not, the trace_array no longer exits.
+ */
+static int trace_array_options_get(void *tr_index)
+{
+	struct trace_array *tr;
+	int ret;
+
+	ret = security_locked_down(LOCKDOWN_TRACEFS);
+	if (ret)
+		return ret;
+
+	if (tracing_disabled)
+		return -ENODEV;
+
+	guard(mutex)(&trace_types_lock);
+	list_for_each_entry(tr, &ftrace_trace_arrays, list) {
+		if (tr_index >= &tr->trace_flags_index[0] &&
+		    tr_index < &tr->trace_flags_index[TRACE_FLAGS_MAX_SIZE])
+			return __trace_array_get(tr);
+	}
+	return -ENODEV;
+}
+
+static int trace_options_open(struct inode *inode, struct file *filp)
+{
+	void *tr_index = inode->i_private;
+
+	if (trace_array_options_get(tr_index) < 0)
+		return -ENODEV;
+
+	filp->private_data = tr_index;
+
+	return 0;
+}
+
+static int trace_options_release(struct inode *inode, struct file *filp)
+{
+	void *tr_index = filp->private_data;
+	struct trace_array *tr;
+	unsigned int index;
+
+	get_tr_index(tr_index, &tr, &index);
+
+	trace_array_put(tr);
+
+	return 0;
+}
+
 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,
 };
 
 struct dentry *trace_create_file(const char *name,
-- 
2.53.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] Identifying trace arrays by raw memory address in `trace_array_options_get()` introduces an ABA/pointer reuse vulnerability, allowing cross-instance manipulation.
- [Low] Call to undeclared function `__trace_array_get()` will break the build.

Pre-existing issues:
- [Critical] This problem wasn't introduced by this patch, but the patch addresses a Use-After-Free for core option files while overlooking tracer-specific option files and other per-instance tracefs files, leaving them vulnerable to the exact same Use-After-Free.
--

commit a7557d52083622c7b02bffa097f88009b072e692
Author: Steven Rostedt <rostedt@goodmis.org>

tracing: Take trace_array reference when opening options file

This commit fixes a Use-After-Free vulnerability in trace options files
by ensuring the trace_array reference is taken when the file is opened.
It introduces trace_array_options_get() to safely acquire the reference.

Link: https://lore.kernel.org/linux-trace-kernel/20260828135858.2AC501F000E9@smtp.kernel.org/

> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index d3005279165d9..3e001ed8cf376 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c

[ ... ]

> +static int trace_array_options_get(void *tr_index)
> +{
> +	struct trace_array *tr;
> +	int ret;
> +
> +	ret = security_locked_down(LOCKDOWN_TRACEFS);
> +	if (ret)
> +		return ret;
> +
> +	if (tracing_disabled)
> +		return -ENODEV;
> +
> +	guard(mutex)(&trace_types_lock);
> +	list_for_each_entry(tr, &ftrace_trace_arrays, list) {
> +		if (tr_index >= &tr->trace_flags_index[0] &&
> +		    tr_index < &tr->trace_flags_index[TRACE_FLAGS_MAX_SIZE])

[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?

> +			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.

> +	}
> +	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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901163620.6cbe0ada@gandalf.local.home?part=1

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

[Steven Rostedt]

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

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

[Steven Rostedt]

On Tue, 1 Sep 2026 19:13:39 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> > 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?

Not sure what tree you are looking at.

> > 
> > kernel/trace/trace.c:tracing_max_lat_write() {

That function has been moved to trace_snapshot.c

> >     ...
> >     return tracing_nsecs_write(filp->private_data, ubuf, cnt, ppos);
> > }
> > 
> > Where tracing_nsecs_write would perform an unlocked write to the
> > freed pointer?  

and this has been fixed by:

  7d660c9b2bc95 ("tracing: Have tracing_max_latency inc the trace array ref count")

That was added in 2023.

-- Steve

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

[kernel test robot]

Hi Steven,

kernel test robot noticed the following build warnings:

[auto build test WARNING on trace/for-next]
[also build test WARNING on linus/master v7.3-rc1 next-20260901]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Steven-Rostedt/tracing-Take-trace_array-reference-when-opening-options-file/20260901-163620
base:   https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace for-next
patch link:    https://lore.kernel.org/r/20260901163620.6cbe0ada%40gandalf.local.home
patch subject: [PATCH] tracing: Take trace_array reference when opening options file
config: openrisc-randconfig-r072-20260902 (https://download.01.org/0day-ci/archive/20260902/202609021814.YH14WR0q-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 14.3.0
smatch: v0.5.0-9187-g5189e3fb
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260902/202609021814.YH14WR0q-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202609021814.YH14WR0q-lkp@intel.com/

All warnings (new ones prefixed by >>):

   kernel/trace/trace.c: In function 'trace_array_options_get':
>> kernel/trace/trace.c:7871:30: warning: comparison of distinct pointer types lacks a cast [-Wcompare-distinct-pointer-types]
    7871 |                 if (tr_index >= &tr->trace_flags_index[0] &&
         |                              ^~
   kernel/trace/trace.c:7872:30: warning: comparison of distinct pointer types lacks a cast [-Wcompare-distinct-pointer-types]
    7872 |                     tr_index < &tr->trace_flags_index[TRACE_FLAGS_MAX_SIZE])
         |                              ^


vim +7871 kernel/trace/trace.c

  7844	
  7845	/*
  7846	 * The tr_index is the address of a trace_array->trace_flags_index[]
  7847	 * element that holds the index of the trace flag. But since the
  7848	 * trace_array reference has not been taken yet, it cannot be referenced
  7849	 * as it could have been freed by a rmdir of the instance the trace_array
  7850	 * represents.
  7851	 *
  7852	 * Search the list of trace_arrays and compare the tr_index to the
  7853	 * address of the entire trace_array trace_flags_index array for each
  7854	 * trace_array in the list. If one is matched, then take the reference
  7855	 * and return it. If not, the trace_array no longer exits.
  7856	 */
  7857	static int trace_array_options_get(void *tr_index)
  7858	{
  7859		struct trace_array *tr;
  7860		int ret;
  7861	
  7862		ret = security_locked_down(LOCKDOWN_TRACEFS);
  7863		if (ret)
  7864			return ret;
  7865	
  7866		if (tracing_disabled)
  7867			return -ENODEV;
  7868	
  7869		guard(mutex)(&trace_types_lock);
  7870		list_for_each_entry(tr, &ftrace_trace_arrays, list) {
> 7871			if (tr_index >= &tr->trace_flags_index[0] &&
  7872			    tr_index < &tr->trace_flags_index[TRACE_FLAGS_MAX_SIZE])
  7873				return __trace_array_get(tr);
  7874		}
  7875		return -ENODEV;
  7876	}
  7877	

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Steven Rostedt]

On Wed, 2 Sep 2026 18:36:45 +0800
kernel test robot <lkp@intel.com> wrote:

> All warnings (new ones prefixed by >>):
> 
>    kernel/trace/trace.c: In function 'trace_array_options_get':
> >> kernel/trace/trace.c:7871:30: warning: comparison of distinct pointer types lacks a cast [-Wcompare-distinct-pointer-types]  
>     7871 |                 if (tr_index >= &tr->trace_flags_index[0] &&
>          |                              ^~
>    kernel/trace/trace.c:7872:30: warning: comparison of distinct pointer types lacks a cast [-Wcompare-distinct-pointer-types]
>     7872 |                     tr_index < &tr->trace_flags_index[TRACE_FLAGS_MAX_SIZE])
>          |                              ^

Hmm, I thought void pointers could compare to anything. Oh well, I'll
typecast the address too.

-- Steve