Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 7 Aug 2020 19:20:48 +0200
From:   Marco Elver <elver@google.com>
To:     Kees Cook <keescook@chromium.org>
Cc:     Alexander Potapenko <glider@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        David Rientjes <rientjes@google.com>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Pekka Enberg <penberg@kernel.org>,
        Christoph Lameter <cl@linux.com>, kasan-dev@googlegroups.com,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Odd-sized kmem_cache_alloc and slub_debug=Z
Message-ID: <20200807172048.GB1467156@elver.google.com>
References: <20200807160627.GA1420741@elver.google.com>
 <202008071010.69B612E@keescook>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <202008071010.69B612E@keescook>
User-Agent: Mutt/1.14.4 (2020-06-18)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Aug 07, 2020 at 10:16AM -0700, Kees Cook wrote:
> On Fri, Aug 07, 2020 at 06:06:27PM +0200, Marco Elver wrote:
> > I found that the below debug-code using kmem_cache_alloc(), when using
> > slub_debug=Z, results in the following crash:
> > 
> > 	general protection fault, probably for non-canonical address 0xcccccca41caea170: 0000 [#1] PREEMPT SMP PTI
> > 	CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.8.0+ #1
> > 	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
> > 	RIP: 0010:freelist_dereference mm/slub.c:272 [inline]
> > 	RIP: 0010:get_freepointer mm/slub.c:278 [inline]
> 
> That really looks like more fun from my moving the freelist pointer... 
> 
> > 	R13: cccccca41caea160 R14: ffffe7c6a072ba80 R15: ffffa3a41c96d540
> 
> Except that it's all cccc at the start, which doesn't look like "data"
> nor the hardened freelist obfuscation.
> 
> > 	FS:  0000000000000000(0000) GS:ffffa3a41fc00000(0000) knlGS:0000000000000000
> > 	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > 	CR2: ffffa3a051c01000 CR3: 000000045140a001 CR4: 0000000000770ef0
> > 	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > 	DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > 	PKRU: 00000000
> > 	Call Trace:
> > 	 ___slab_alloc+0x336/0x340 mm/slub.c:2690
> > 	 __slab_alloc mm/slub.c:2714 [inline]
> > 	 slab_alloc_node mm/slub.c:2788 [inline]
> > 	 slab_alloc mm/slub.c:2832 [inline]
> > 	 kmem_cache_alloc+0x135/0x200 mm/slub.c:2837
> > 	 start_kernel+0x3d6/0x44e init/main.c:1049
> > 	 secondary_startup_64+0xb6/0xc0 arch/x86/kernel/head_64.S:243
> > 
> > Any ideas what might be wrong?
> > 
> > This does not crash when redzones are not enabled.
> > 
> > Thanks,
> > -- Marco
> > 
> > ------ >8 ------
> > 
> > diff --git a/init/main.c b/init/main.c
> > index 15bd0efff3df..f4aa5bb3f2ec 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -1041,6 +1041,16 @@ asmlinkage __visible void __init start_kernel(void)
> >  	sfi_init_late();
> >  	kcsan_init();
> >  
> > +	/* DEBUG CODE */
> > +	{
> > +		struct kmem_cache *c = kmem_cache_create("test", 21, 1, 0, NULL);
> > +		char *buf;
> > +		BUG_ON(!c);
> > +		buf = kmem_cache_alloc(c, GFP_KERNEL);
> > +		kmem_cache_free(c, buf);
> > +		kmem_cache_destroy(c);
> > +	}
> > +
> >  	/* Do the rest non-__init'ed, we're now alive */
> >  	arch_call_rest_init();
> >  
> 
> Which kernel version? Can you send your CONFIG too?

Sorry, didn't see this before I replied to the other -- it's here:
https://lkml.kernel.org/r/20200807171849.GA1467156@elver.google.com

Thanks,
-- Marco