linux-kernel - Re: [linux-next-20130422] Bug in SLAB?

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: <0000013e6b0fcf7b-9fabe4c8-2667-4bea-a9d1-f1c77e18fe78-000000@email.amazonses.com>
Date:	Fri, 3 May 2013 15:43:18 +0000
From:	Christoph Lameter <cl@...ux.com>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
cc:	glommer@...allels.com, penberg@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [linux-next-20130422] Bug in SLAB?

On Fri, 3 May 2013, Tetsuo Handa wrote:

> I don't think this patch is sufficient. There are functions (e.g. kstrdup())
> which call variant functions (e.g. kmalloc_track_caller()). I think we need to
> check size at functions which determine index from size (e.g. kmalloc_slab()).

Right.

> > Index: linux/include/linux/slab_def.h
> > ===================================================================
> > --- linux.orig/include/linux/slab_def.h	2013-05-02 15:02:45.864728115 -0500
> > +++ linux/include/linux/slab_def.h	2013-05-02 15:06:14.940474110 -0500
> > @@ -126,6 +126,9 @@ static __always_inline void *kmalloc(siz
> >  		if (!size)
> >  			return ZERO_SIZE_PTR;
> >
> > +		if (size >= KMALLOC_MAX_SIZE)
> > +			return NULL;
> > +
>
> Why not (size > KMALLOC_MAX_SIZE) ?

Correct.

We also would want some diagnostics as to who is doing these large allocs
so that these issues can be fixed. Updated patch:

Subject: slab: Return NULL for oversized allocations

The inline path seems to have changed the SLAB behavior for very large
kmalloc allocations. This patch restores the old behavior but also
adds diagnostics so that we can figure where in the code these
large allocations occur.

Signed-off-by: Christoph Lameter <cl@...ux.com>


Index: linux/include/linux/slab_def.h
===================================================================
--- linux.orig/include/linux/slab_def.h	2013-05-03 10:36:46.019564801 -0500
+++ linux/include/linux/slab_def.h	2013-05-03 10:37:28.860302188 -0500
@@ -126,6 +126,11 @@ static __always_inline void *kmalloc(siz
 		if (!size)
 			return ZERO_SIZE_PTR;

+		if (size > KMALLOC_MAX_SIZE) {
+			WARN_ON(1);
+			return NULL;
+		}
+
 		i = kmalloc_index(size);

 #ifdef CONFIG_ZONE_DMA
@@ -172,6 +177,11 @@ static __always_inline void *kmalloc_nod
 		if (!size)
 			return ZERO_SIZE_PTR;

+		if (size > KMALLOC_MAX_SIZE) {
+			WARN_ON(1);
+			return NULL;
+		}
+
 		i = kmalloc_index(size);

 #ifdef CONFIG_ZONE_DMA
Index: linux/mm/slab_common.c
===================================================================
--- linux.orig/mm/slab_common.c	2013-05-03 10:36:46.019564801 -0500
+++ linux/mm/slab_common.c	2013-05-03 10:38:29.045351837 -0500
@@ -373,6 +373,11 @@ struct kmem_cache *kmalloc_slab(size_t s
 {
 	int index;

+	if (size > KMALLOC_MAX_SIZE) {
+		WARN_ON(1);
+		return NULL;
+	}
+
 	if (size <= 192) {
 		if (!size)
 			return ZERO_SIZE_PTR;


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