Re: [SECURITY] tracing: splice(2) trace_pipe peek outside the access lock

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 10 Nov 2026 19:51:37 +0800 (GMT+08:00)
n3rd <18670333770@163.com> wrote:

> 4. Conditions
> Requires local root to write

Here you state that it requires local root to exploit.

> /sys/kernel/tracing/buffer_subbuf_size_kb and trace_marker and to
> read trace_pipe, tracefs mounted, and at least two CPUs so that the
> order change and the splice reader really run concurrently. The order
> change is what frees the page; a splice(2) reader without concurrent
> order changes does not trigger it. CONFIG_TRACING=y is required for
> the tracefs files and CONFIG_KASAN=y makes the read visible as a
> KASAN report; without KASAN the read is silent. Tested on x86_64
> only, with QEMU TCG and two vCPUs.
> 


> 
> 6. Suggested fix
> Move the trace_find_next_entry_inc() call in
> tracing_splice_read_pipe() below trace_event_read_lock() and
> trace_access_lock(), matching tracing_read_pipe(), so that the peek
> is covered by the same RING_BUFFER_ALL_CPUS access lock that
> serializes ring_buffer_subbuf_order_set(). Alternatively copy the
> event out while the reader lock is held, the way rb_iter_head_event()
> does. No upstream patch exists as of v7.3-rc7.

Feel free to send a patch.

> 
> 
> 7. Mitigation
> Restrict write access to tracefs to trusted processes and avoid
> changing buffer_subbuf_size_kb while trace_pipe is being read with
> splice(2). This reduces exposure but does not fix the root cause.

Now you state the mitigation in to only allow access to tracefs to
trusted processes, which as you stated above, is the default.

This is *not* a security bug. Please continue this conversation in the
linux-trace-kernel. mailing list.

Thanks,

-- Steve