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: <20140311025811.GA601@lge.com>
Date:	Tue, 11 Mar 2014 11:58:11 +0900
From:	Joonsoo Kim <iamjoonsoo.kim@....com>
To:	Dave Jones <davej@...hat.com>, Christoph Lameter <cl@...ux.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Pekka Enberg <penberg@...nel.org>, linux-mm@...ck.org,
	David Rientjes <rientjes@...gle.com>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: oops in slab/leaks_show

On Mon, Mar 10, 2014 at 09:24:55PM -0400, Dave Jones wrote:
> On Tue, Mar 11, 2014 at 10:01:35AM +0900, Joonsoo Kim wrote:
>  > On Tue, Mar 11, 2014 at 09:35:00AM +0900, Joonsoo Kim wrote:
>  > > On Fri, Mar 07, 2014 at 11:18:30AM -0600, Christoph Lameter wrote:
>  > > > Joonsoo recently changed the handling of the freelist in SLAB. CCing him.
>  > > > 
>  > > > > I pretty much always use SLUB for my fuzzing boxes, but thought I'd give SLAB a try
>  > > > > for a change.. It blew up when something tried to read /proc/slab_allocators
>  > > > > (Just cat it, and you should see the oops below)
>  > > 
>  > > Hello, Dave.
>  > > 
>  > > Today, I did a test on v3.13 which contains all my changes on the handling of
>  > > the freelist in SLAB and couldn't trigger oops by just 'cat /proc/slab_allocators'.
>  > > 
>  > > So I look at the code and find that there is race window if there is multiple users
>  > > doing 'cat /proc/slab_allocators'. Did your test do that?
>  > 
>  > Opps, sorry. I am misunderstanding something. Maybe there is no race.
>  > Anyway, How do you test it?
> 
> 1. build kernel with CONFIG_SLAB=y.
> 2. boot kernel
> 3. cat /proc/slab_allocators

Okay. I reproduce it with CONFIG_DEBUG_PAGEALLOC=y.

I look at the code and find that the problem doesn't come from my patches.
I think that it is long-lived bug. Let me explain it.

'cat /proc/slab_allocators' checks all allocated objects for all slabs.
The problem is that it considers objects in cpu slab caches as allocated objects.
These objects in cpu slab caches are unmapped if CONFIG_DEBUG_PAGEALLOC=y, so when we
try to access it to get the caller information, oops would be triggered.

I will think more deeply how to fix this problem.
If I am missing something, please let me know.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ