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

Pre-existing issues:
- [High] Integer overflow in per-CPU ring buffer metadata calculations due to 
32-bit arithmetic, leading to memory corruption and false validation rejections 
for trace buffers larger than 2GB/4GB.
--

commit dffcd0268ea5b9908d6dadacec8d07651bd25ceb
Author: Steven Rostedt <[email protected]>

ftrace: Add checking nr_subbufs to persistent ring buffer validation
    
This commit adds a check to the persistent ring buffer validation logic. It
ensures that the saved nr_subbufs in the metadata matches the expected
nr_pages + 1 to prevent mismatches.

Closes: https://lore.kernel.org/all/[email protected]/

> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -1856,6 +1856,11 @@ static bool rb_cpu_meta_valid(struct 
> ring_buffer_cpu_meta *meta, int cpu,
>               return false;
>       }
>  
> +     if (meta->nr_subbufs != nr_pages + 1) {
> +             pr_info("Ring buffer boot meta [%d] invalid nr_subbufs\n", cpu);
> +             return false;
> +     }
> +
>       buffers_start = meta->first_buffer;
>       buffers_end = meta->first_buffer + (subbuf_size * meta->nr_subbufs);

[Severity: High]
This is a pre-existing issue, but could this 32-bit arithmetic overflow for
very large trace buffers? 

In rb_cpu_meta_valid(), subbuf_size is an int and meta->nr_subbufs is a __u32.
If an administrator configures a per-CPU trace buffer larger than 4GB, their
product might truncate before being added to the 64-bit meta->first_buffer.
Would this result in an artificially small buffers_end, causing valid buffers
to falsely fail the bounds check on reboot?

A similar pre-existing issue appears in rb_range_meta(), where both variables
are signed 32-bit ints:

kernel/trace/ring_buffer.c:rb_range_meta() {
    ...
    ptr += subbuf_size * nr_subbufs;
    ...
}

Does this signed multiplication overflow for buffers over 2GB, causing the
ptr to move backward and potentially corrupt memory when written?

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=1

Reply via email to