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: <Z2KSR5QrAWYDEBVh@google.com>
Date: Wed, 18 Dec 2024 09:13:43 +0000
From: Vincent Donnefort <vdonnefort@...gle.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,
	Jeongjun Park <aha310510@...il.com>, david@...hat.com
Subject: Re: [PATCH] ring-buffer: Fix a oob in __rb_map_vma

On Tue, Dec 17, 2024 at 07:40:15PM -0500, Steven Rostedt 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
> > >   
> > 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).

I wanted to look at the reproducer sent by Jeongjung yesterday but got
preempted. My bad.

To avoid repeating the (nr_subbufs + 1) << subbuf_order How about?

-       nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; /* + meta-page */
+       nr_pages = ((nr_subbufs + 1) << subbuf_order); /* + meta-page */
+
+       if (pgoff > nr_pages)
+               return -EINVAL;
+
+       nr_pages -= pgoff;


And probably also 

Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions")

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