From: Vincent Donnefort <vdonnefort@google.com>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] ring-buffer: Fix subbuf_ids memory leak in rb_allocate_cpu_buffer() error path
Date: Thu, 30 Jul 2026 09:13:08 +0100 [thread overview]
Message-ID: <amsHlMCNHV9JWA0l@google.com> (raw)
In-Reply-To: <178539491147.180138.1181424244288838594.stgit@devnote2>
On Thu, Jul 30, 2026 at 04:01:51PM +0900, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> In rb_allocate_cpu_buffer(), cpu_buffer->subbuf_ids is allocated using
> kcalloc() when buffer->remote is non-NULL. If a subsequent page allocation
> fails (e.g., ring_buffer_desc_page() returns NULL or rb_allocate_pages()
> fails), execution jumps to fail_free_reader.
>
> While __free(kfree) automatically frees the outer cpu_buffer structure
> at scope exit, kfree(cpu_buffer) does not recursively free nested heap
> pointers such as cpu_buffer->subbuf_ids, resulting in a memory leak.
>
> Fix this by explicitly freeing cpu_buffer->subbuf_ids in the
> fail_free_reader error unwinding path when cpu_buffer->remote is set.
>
> Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes")
> Assisted-by: Antigravity:gemini-3.6-flash
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> ---
> kernel/trace/ring_buffer.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 78d3875a47a5..03f6baf6a5f5 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -2599,6 +2599,8 @@ rb_allocate_cpu_buffer(struct trace_buffer *buffer, long nr_pages, int cpu)
> return_ptr(cpu_buffer);
>
> fail_free_reader:
> + if (cpu_buffer->remote)
> + kfree(cpu_buffer->subbuf_ids);
alloc_cpu_buffer() being kzalloc, I suppose here we could just unconditionally
call kfree(cpu_buffer->subbuf_ids) ?
> free_buffer_page(cpu_buffer->reader_page);
>
> return NULL;
>
--
Vincent
next prev parent reply other threads:[~2026-07-30 8:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 7:01 [PATCH] ring-buffer: Fix subbuf_ids memory leak in rb_allocate_cpu_buffer() error path Masami Hiramatsu (Google)
2026-07-30 8:13 ` Vincent Donnefort [this message]
2026-07-30 12:26 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=amsHlMCNHV9JWA0l@google.com \
--to=vdonnefort@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.