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]
Date:   Fri, 11 Nov 2022 16:29:43 +0800
From:   Feng Tang <feng.tang@...el.com>
To:     Vlastimil Babka <vbabka@...e.cz>
CC:     Andrew Morton <akpm@...ux-foundation.org>,
        Christoph Lameter <cl@...ux.com>,
        Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Hyeonggon Yoo <42.hyeyoo@...il.com>,
        "Dmitry Vyukov" <dvyukov@...gle.com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        "Kees Cook" <keescook@...omium.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kasan-dev@...glegroups.com" <kasan-dev@...glegroups.com>
Subject: Re: [PATCH v7 0/3] mm/slub: extend redzone check for kmalloc objects

On Fri, Nov 11, 2022 at 04:16:32PM +0800, Vlastimil Babka wrote:
> On 10/21/22 05:24, Feng Tang wrote:
> > kmalloc's API family is critical for mm, and one of its nature is that
> > it will round up the request size to a fixed one (mostly power of 2).
> > When user requests memory for '2^n + 1' bytes, actually 2^(n+1) bytes
> > could be allocated, so there is an extra space than what is originally
> > requested.
> > 
> > This patchset tries to extend the redzone sanity check to the extra
> > kmalloced buffer than requested, to better detect un-legitimate access
> > to it. (dependson SLAB_STORE_USER & SLAB_RED_ZONE)
> > 
> > The redzone part has been tested with code below:
> > 
> > 	for (shift = 3; shift <= 12; shift++) {
> > 		size = 1 << shift;
> > 		buf = kmalloc(size + 4, GFP_KERNEL);
> > 		/* We have 96, 196 kmalloc size, which is not power of 2 */
> > 		if (size == 64 || size == 128)
> > 			oob_size = 16;
> > 		else
> > 			oob_size = size - 4;
> > 		memset(buf + size + 4, 0xee, oob_size);
> > 		kfree(buf);
> > 	}
> 
> Sounds like a new slub_kunit test would be useful? :) doesn't need to be
> that exhaustive wrt all sizes, we could just pick one and check that a write
> beyond requested kmalloc size is detected?

Just git-grepped out slub_kunit.c :), will try to add a case to it.
I'll also check if the case will also be caught by other sanitizer
tools like kasan/kfence etc.

Thanks,
Feng


> Thanks!
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ