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:   Thu, 1 Dec 2022 00:05:41 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Feng Tang <feng.tang@...el.com>, Marco Elver <elver@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Oliver Glitta <glittao@...il.com>,
        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>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] mm/slub, kunit: Add a test case for kmalloc
 redzone check

On 11/30/22 09:54, Feng Tang wrote:
> kmalloc redzone check for slub has been merged, and it's better to add
> a kunit case for it, which is inspired by a real-world case as described
> in commit 120ee599b5bf ("staging: octeon-usb: prevent memory corruption"):
> 
> "
>   octeon-hcd will crash the kernel when SLOB is used. This usually happens
>   after the 18-byte control transfer when a device descriptor is read.
>   The DMA engine is always transferring full 32-bit words and if the
>   transfer is shorter, some random garbage appears after the buffer.
>   The problem is not visible with SLUB since it rounds up the allocations
>   to word boundary, and the extra bytes will go undetected.
> "
> 
> To avoid interrupting the normal functioning of kmalloc caches, a
> kmem_cache mimicing kmalloc cache is created with similar flags, and
> kmalloc_trace() is used to really test the orig_size and redzone setup.
> 
> Suggested-by: Vlastimil Babka <vbabka@...e.cz>
> Signed-off-by: Feng Tang <feng.tang@...el.com>
> ---
> Changelog:
> 
>   since v2:
>     * only add SLAB_KMALLOC to SLAB_CACHE_FLAGS and SLAB_FLAGS_PERMITTEDa,
>       and use new wrapper of cache creation(Vlastimil Babka)
> 
>   since v1:
>     * create a new cache mimicing kmalloc cache, reduce dependency
>       over global slub_debug setting (Vlastimil Babka)
> 
>  lib/slub_kunit.c | 22 ++++++++++++++++++++++
>  mm/slab.h        |  4 +++-
>  2 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/slub_kunit.c b/lib/slub_kunit.c
> index 5b0c8e7eb6dc..ff24879e3afe 100644
> --- a/lib/slub_kunit.c
> +++ b/lib/slub_kunit.c
> @@ -135,6 +135,27 @@ static void test_clobber_redzone_free(struct kunit *test)
>  	kmem_cache_destroy(s);
>  }
>  
> +static void test_kmalloc_redzone_access(struct kunit *test)
> +{
> +	struct kmem_cache *s = test_kmem_cache_create("TestSlub_RZ_kmalloc", 32,
> +				SLAB_KMALLOC|SLAB_STORE_USER|SLAB_RED_ZONE);
> +	u8 *p = kmalloc_trace(s, GFP_KERNEL, 18);
> +
> +	kasan_disable_current();
> +
> +	/* Suppress the -Warray-bounds warning */
> +	OPTIMIZER_HIDE_VAR(p);
> +	p[18] = 0xab;
> +	p[19] = 0xab;
> +
> +	kmem_cache_free(s, p);
> +	validate_slab_cache(s);
> +	KUNIT_EXPECT_EQ(test, 2, slab_errors);

With this ordering the expectation was failing as slab_Errors was 0, had to
fix it up to look more like TestSlub_RZ_alloc:

> +	kasan_enable_current();
> +	kmem_cache_destroy(s);
> +}
> +

--- a/lib/slub_kunit.c
+++ b/lib/slub_kunit.c
@@ -148,11 +148,11 @@ static void test_kmalloc_redzone_access(struct kunit *test)
        p[18] = 0xab;
        p[19] = 0xab;
 
-       kmem_cache_free(s, p);
        validate_slab_cache(s);
        KUNIT_EXPECT_EQ(test, 2, slab_errors);
 
        kasan_enable_current();
+       kmem_cache_free(s, p);
        kmem_cache_destroy(s);
 }

With that, added both to slab.git branch slab/for-6.2/kmalloc_redzone
Thanks!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ