linux-kernel - Re: [PATCH v7 0/3] mm/slub: extend redzone check for kmalloc objects

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: <f9da0749-c109-1251-8489-de3cfb50ab24@suse.cz>
Date:   Fri, 11 Nov 2022 09:16:32 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Feng Tang <feng.tang@...el.com>,
        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>
Cc:     Dave Hansen <dave.hansen@...el.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com
Subject: Re: [PATCH v7 0/3] mm/slub: extend redzone check for kmalloc objects

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?

Thanks!