Re: [PATCH] ring-buffer: Fix a oob in __rb_map_vma
From: Jeongjun Park <hidden>
Date: 2024-12-18 01:23:45
Also in:
lkml
Steven Rostedt [off-list ref] wrote: On Wed, 18 Dec 2024 07:43:46 +0800 Edward Adam Davis [off-list ref] wrote:quoted
quoted
A proper fix is being discussed here:First, my fix is the first one.Yes I saw that.quoted
Second, the root cause of the problem is an overflow when calculating nr_pages.quoted
https://lore.kernel.org/linux-trace-kernel/20241216164931.57323-1-aha310510@gmail.com/ (local) Thank you, -- Steve
Oh, I did not propose a patch that fixes the root cause of this oob. My patch is a separate patch that fixes the wrong order, such as reading the array before checking the variable s with the WARN function in the loop. So I think both of these patches should be applied. Regards, Jeongjun Park
quoted
The calculation of nr_pages below overflows because the pgoff value is 8, the nr_subbufs value is 3, and the subbuf_order value is 0.So basically you are saying that passing in the the mmap with the pgoff is what's causing it.quoted
quoted
quoted
nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; /* + meta-page */ nr_vma_pages = vma_pages(vma);Thanks, I believe I now have a reproducer. And yes, I'll take your patch. (If Vincent is OK with it). Here's the reproducer: ------------------------8<------------------------- #include <fcntl.h> #include <stdlib.h> #include <unistd.h> #include <asm/types.h> #include <sys/mman.h> int main(int argc, char **argv) { int page_size = getpagesize(); int fd; void *meta; system("echo 1 > /sys/kernel/tracing/buffer_size_kb"); fd = open("/sys/kernel/tracing/per_cpu/cpu0/trace_pipe_raw", O_RDONLY); meta = mmap(NULL, page_size, PROT_READ, MAP_SHARED, fd, page_size * 5); } ------------------------>8------------------------- Thanks, -- Steve