On Thu, 13 Aug 2026 13:54:39 +0000
[email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
> to consider:
>
> Pre-existing issues:
> - [Critical] A data race and locking mismatch between
> `ring_buffer_subbuf_order_set()`, `ring_buffer_alloc_read_page()`, and
> `ring_buffer_free_read_page()` allows `cpu_buffer->free_page` to cache a page
> of an old order while `buffer->subbuf_order` reflects a new larger order.
> This leads to heap buffer overflow and buddy allocator corruption.
> --
>
> --- Patch [1]: [PATCH v5 01/10] ring-buffer: Free cpu_buffer::free_page with
> subbuf_order ---
> commit f550c0bfeadcc22eca47316e1820b4d91f6ef261
> Author: Vincent Donnefort <[email protected]>
>
> ring-buffer: Free cpu_buffer::free_page with subbuf_order
>
> When sub-buffers use an order greater than 0, cpu_buffer->free_page is
> allocated with subbuf_order. Use the correct order for
> cpu_buffer->free_page.
>
> > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> > index 2667992f0aa29..a3d28b2e2c94a 100644
> > --- a/kernel/trace/ring_buffer.c
> > +++ b/kernel/trace/ring_buffer.c
> > @@ -2631,7 +2631,7 @@ static void rb_free_cpu_buffer(struct
> > ring_buffer_per_cpu *cpu_buffer)
> > free_buffer_page(bpage);
> > }
> >
> > - free_page((unsigned long)cpu_buffer->free_page);
> > + free_pages((unsigned long)cpu_buffer->free_page,
> > cpu_buffer->buffer->subbuf_order);
>
> [Severity: Critical]
> This is a pre-existing issue, but does this change expose a buddy allocator
> corruption if cpu_buffer->free_page contains a page of a smaller order than
> buffer->subbuf_order?
Hmm, I think you have to fix cpu_buffer->{free_page,subbuf_order} race issue at
first.
Let me try another series to fix it.
Thank you,
--
Masami Hiramatsu (Google) <[email protected]>
