lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <3D642609-2738-41BB-AB0D-A14F58469A78@gmail.com>
Date: Wed, 18 Dec 2024 10:23:32 +0900
From: Jeongjun Park <aha310510@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Edward Adam Davis <eadavis@...com>, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, mathieu.desnoyers@...icios.com,
 mhiramat@...nel.org, syzbot+345e4443a21200874b18@...kaller.appspotmail.com,
 syzkaller-bugs@...glegroups.com, Vincent Donnefort <vdonnefort@...gle.com>,
 david@...hat.com
Subject: Re: [PATCH] ring-buffer: Fix a oob in __rb_map_vma



> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> On Wed, 18 Dec 2024 07:43:46 +0800
> Edward Adam Davis <eadavis@...com> wrote:
> 
>>> 
>>> A proper fix is being discussed here:  
>> First, my fix is the first one.
> 
> Yes I saw that.
> 
>> Second, the root cause of the problem is an overflow when calculating nr_pages.
>>> 
>>> https://lore.kernel.org/linux-trace-kernel/20241216164931.57323-1-aha310510@gmail.com/
>>> 
>>> 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

>> 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.
> 
>>>>    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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ