[PATCH] tracing: Take trace_types_lock when dropping the buffer_meta reference

tracing_buffer_meta_open() drops the trace_array reference with
__trace_array_put() when ring_buffer_meta_seq_init() fails, without
holding trace_types_lock. Use trace_array_put() like every other open
error path.

Fixes: 950032ffcee7 ("ring-buffer: Add output of ring buffer meta page")
Signed-off-by: David Carlier <redacted>
---
 kernel/trace/trace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 8658cad53cb5..c8295324ffaa 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c

@@ -5881,7 +5881,7 @@ static int tracing_buffer_meta_open(struct inode *inode, struct file *filp)
 
 	ret = ring_buffer_meta_seq_init(filp, tr->array_buffer.buffer, cpu);
 	if (ret < 0)
-		__trace_array_put(tr);
+		trace_array_put(tr);
 	return ret;
 }
 

-- 
2.55.0

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

Pre-existing issues:
- [High] Reading a per-CPU buffer_meta file for an offline or unallocated CPU causes a NULL pointer dereference.
--

commit f8d13605bef286fcf84c808917e1ab8eeeade189
Author: David Carlier [off-list ref]

tracing: Take trace_types_lock when dropping the buffer_meta reference

This commit fixes the error path in tracing_buffer_meta_open() by using
trace_array_put() instead of __trace_array_put(). This ensures the
trace_types_lock is properly held when dropping the trace array reference
if ring_buffer_meta_seq_init() fails.

[Severity: High]
This is a pre-existing issue, but reading a per-CPU buffer_meta file for an
offline or unallocated CPU causes a NULL pointer dereference.

A user with privileges to read tracefs can open and read
/sys/kernel/tracing/per_cpu/cpuX/buffer_meta where cpuX is a CPU that has
never been online. This invokes tracing_buffer_meta_open(), which blindly
initializes the seq_file via ring_buffer_meta_seq_init():

kernel/trace/ring_buffer.c:ring_buffer_meta_seq_init() {
        ...
        m = file->private_data;
        m->private = buffer->buffers[cpu];
        ...
}

Because alloc_buffer() only dynamically allocates cpu_buffer structs for
currently online CPUs via CPU hotplug callbacks, this pointer is NULL for
unallocated CPUs. The subsequent read invokes rbm_start(), which immediately
dereferences the NULL pointer:

kernel/trace/ring_buffer.c:rbm_start() {
        struct ring_buffer_cpu_meta *meta = cpu_buffer->ring_meta;
        ...
}

Should there be NULL validation for buffer->buffers[cpu] before allowing
the file to be successfully opened, or perhaps a check inside rbm_start()
to handle it gracefully?

 	if (ret < 0)
-		__trace_array_put(tr);
+		trace_array_put(tr);
 	return ret;
 }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260913133829.15307-1-devnexen@gmail.com?part=1

This time seems legit I ll prepare a v2 at some point.

On Sun, 13 Sept 2026 at 14:49, [off-list ref] wrote:

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

Pre-existing issues:
- [High] Reading a per-CPU buffer_meta file for an offline or unallocated CPU causes a NULL pointer dereference.
--

commit f8d13605bef286fcf84c808917e1ab8eeeade189
Author: David Carlier [off-list ref]

tracing: Take trace_types_lock when dropping the buffer_meta reference

This commit fixes the error path in tracing_buffer_meta_open() by using
trace_array_put() instead of __trace_array_put(). This ensures the
trace_types_lock is properly held when dropping the trace array reference
if ring_buffer_meta_seq_init() fails.

quoted

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c

@@ -5881,7 +5881,7 @@ static int tracing_buffer_meta_open(struct inode *inode, struct file *filp)

      ret = ring_buffer_meta_seq_init(filp, tr->array_buffer.buffer, cpu);

[Severity: High]
This is a pre-existing issue, but reading a per-CPU buffer_meta file for an
offline or unallocated CPU causes a NULL pointer dereference.

A user with privileges to read tracefs can open and read
/sys/kernel/tracing/per_cpu/cpuX/buffer_meta where cpuX is a CPU that has
never been online. This invokes tracing_buffer_meta_open(), which blindly
initializes the seq_file via ring_buffer_meta_seq_init():

kernel/trace/ring_buffer.c:ring_buffer_meta_seq_init() {
        ...
        m = file->private_data;
        m->private = buffer->buffers[cpu];
        ...
}

Because alloc_buffer() only dynamically allocates cpu_buffer structs for
currently online CPUs via CPU hotplug callbacks, this pointer is NULL for
unallocated CPUs. The subsequent read invokes rbm_start(), which immediately
dereferences the NULL pointer:

kernel/trace/ring_buffer.c:rbm_start() {
        struct ring_buffer_cpu_meta *meta = cpu_buffer->ring_meta;
        ...
}

Should there be NULL validation for buffer->buffers[cpu] before allowing
the file to be successfully opened, or perhaps a check inside rbm_start()
to handle it gracefully?

quoted

      if (ret < 0)
-             __trace_array_put(tr);
+             trace_array_put(tr);
      return ret;
 }

--
Sashiko AI review · https://sashiko.dev/#/patchset/20260913133829.15307-1-devnexen@gmail.com?part=1