All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vincent Donnefort" <vdonnefort@google.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v8 3/3] ring-buffer: Prevent truncation of nr_pages / nr_subbufs
Date: Wed, 26 Aug 2026 10:02:17 +0000	[thread overview]
Message-ID: <20260826100218.234A61F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260826094528.3738023-4-vdonnefort@google.com>

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

Pre-existing issues:
- [High] The kernel fails to validate the untrusted `meta->nr_subbufs` value from persistent memory against the expected `nr_pages + 1`, leading to arbitrary heap out-of-bounds writes and potential arbitrary kernel memory corruption.
--

commit 5ed0ab549782b2ff87e1bd2394abb78b10c4b602
Author: Vincent Donnefort <vdonnefort@google.com>

ring-buffer: Prevent truncation of nr_pages / nr_subbufs

Although ring_buffer_per_cpu::nr_pages is defined as unsigned long, it
is capped to 32-bits in a few places, limiting the operations possible
on a very large buffer. Use unsigned long where appropriate and
prevent truncation of values using nr_pages (or nr_subbufs).

While at it, subbuf_size must be at least unsigned int.

Note that persistent, remote and user-mapped ring buffers are capping
the number of pages to 31 bits already, making "int" safe in many
places.

> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 6089fcc67e2b6..1fcf55e2ca81f 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -1745,7 +1744,7 @@ static void *rb_range_meta(struct trace_buffer *buffer, int nr_pages, int cpu)
>  /* Return the start of subbufs given the meta pointer */
>  static void *rb_subbufs_from_meta(struct ring_buffer_cpu_meta *meta)
>  {
> -	int subbuf_size = meta->subbuf_size;
> +	unsigned int subbuf_size = meta->subbuf_size;
>  	unsigned long ptr;
>  
>  	ptr = (unsigned long)meta;

[Severity: High]
This isn't a bug introduced by this patch, but does the next line in this
function perform pointer arithmetic using an unvalidated meta->nr_subbufs?

	ptr = rb_range_align_subbuf(ptr, subbuf_size, meta->nr_subbufs);

Could this yield a corrupted or attacker-controlled subbuf base pointer if
meta->nr_subbufs is read from persistent memory without being checked against
expected limits?

[ ... ]

> @@ -1854,13 +1853,13 @@ static bool rb_meta_init(struct trace_buffer *buffer, int scratch_size)
>   * must be the same.
>   */
>  static bool rb_cpu_meta_valid(struct ring_buffer_cpu_meta *meta, int cpu,
> -			      struct trace_buffer *buffer, int nr_pages,
> +			      struct trace_buffer *buffer, unsigned long nr_pages,
>  			      unsigned long *subbuf_mask)
>  {
> -	int subbuf_size = PAGE_SIZE;
> +	unsigned long subbuf_size = PAGE_SIZE;
>  	unsigned long buffers_start;
>  	unsigned long buffers_end;
> -	int i;
> +	unsigned long i;
>  
>  	if (!subbuf_mask)
>  		return false;

[Severity: High]
This isn't a bug introduced by this patch, but is there a risk of an
out-of-bounds heap write further down in this function?

The subbuf_mask is allocated with nr_pages + 1 bits in rb_range_meta_init(),
but later in rb_cpu_meta_valid() operations use the unvalidated
meta->nr_subbufs value read from persistent memory:

	bitmap_clear(subbuf_mask, 0, meta->nr_subbufs);

	/*
	 * Ensure the meta::buffers array has correct data. The data in each subbufs
	 * are checked later in rb_meta_validate_events().
	 */
	for (i = 0; i < meta->nr_subbufs; i++) {
		if (meta->buffers[i] < 0 ||
		    meta->buffers[i] >= meta->nr_subbufs) {
			pr_info("Ring buffer boot meta [%d] array out of range\n", cpu);
			return false;
		}

		if (test_bit(meta->buffers[i], subbuf_mask)) {
			pr_info("Ring buffer boot meta [%d] array has duplicates\n", cpu);
			return false;
		}

		set_bit(meta->buffers[i], subbuf_mask);
	}

If meta->nr_subbufs is larger than nr_pages + 1, could this write out of
bounds and corrupt kernel memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826094528.3738023-1-vdonnefort@google.com?part=3

      reply	other threads:[~2026-08-26 10:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26  9:45 [PATCH v8 0/3] ring-buffer: Fixes for subbuf resizing and persistent buffers Vincent Donnefort
2026-08-26  9:45 ` [PATCH v8 1/3] tracing: Fix subbuf resize races with trace_pipe_raw readers Vincent Donnefort
2026-08-26  9:59   ` sashiko-bot
2026-08-26 14:37     ` Steven Rostedt
2026-08-26 16:24       ` Vincent Donnefort
2026-08-26 18:31         ` Steven Rostedt
2026-08-27  6:31           ` Vincent Donnefort
2026-08-27 13:15             ` Steven Rostedt
2026-08-27 16:21               ` Vincent Donnefort
2026-08-27 19:33                 ` Steven Rostedt
2026-08-28  8:24                   ` Vincent Donnefort
2026-08-28  8:36                     ` Steven Rostedt
2026-08-26  9:45 ` [PATCH v8 2/3] ring-buffer: Cap static ring buffer nr_pages Vincent Donnefort
2026-08-26  9:45 ` [PATCH v8 3/3] ring-buffer: Prevent truncation of nr_pages / nr_subbufs Vincent Donnefort
2026-08-26 10:02   ` sashiko-bot [this message]

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=20260826100218.234A61F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vdonnefort@google.com \
    /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.