From: Kees Cook <keescook@chromium.org>
To: Marco Elver <elver@google.com>
Cc: Pekka Enberg <penberg@gmail.com>,
Alexander Potapenko <glider@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Christoph Lameter <cl@linux.com>,
kasan-dev <kasan-dev@googlegroups.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Odd-sized kmem_cache_alloc and slub_debug=Z
Date: Thu, 8 Oct 2020 16:10:36 -0700 [thread overview]
Message-ID: <202010081608.E1401C067@keescook> (raw)
In-Reply-To: <CANpmjNNhG4VuGq2_kocsTD3CnCv-Y4Kvnz7_VuvZ9Eug+-T=Eg@mail.gmail.com>
On Mon, Aug 17, 2020 at 08:31:35PM +0200, Marco Elver wrote:
> On Fri, 7 Aug 2020 at 21:06, Pekka Enberg <penberg@gmail.com> wrote:
> ...
> > Yeah, it reproduces with defconfig too, as long as you remember to
> > pass "slub_debug=Z"... :-/
> >
> > The following seems to be the culprit:
> >
> > commit 3202fa62fb43087387c65bfa9c100feffac74aa6
> > Author: Kees Cook <keescook@chromium.org>
> > Date: Wed Apr 1 21:04:27 2020 -0700
> >
> > slub: relocate freelist pointer to middle of object
> >
> > Reverting this commit and one of it's follow up fixes from Kees from
> > v5.8 makes the issue go away for me. Btw, please note that caches with
> > size 24 and larger do not trigger this bug, so the issue is that with
> > small enough object size, we're stomping on allocator metadata (I
> > assume part of the freelist).
>
> Was there a patch to fix this? Checking, just in case I missed it.
Hi! I've finally carved out time to look at this, and I've figured it
out. My prior redzoning fix was actually wrong; I'll send a patch to
fix it harder. In the meantime, I've also discovered that the redzoning
code wasn't safe for sizes smaller than sizeof(void *). This oversight
is, I think, what caused me to incorrectly handle the changed offset the
first time. :P
Anyway, patches incoming...
--
Kees Cook
next prev parent reply other threads:[~2020-10-08 23:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-07 16:06 Odd-sized kmem_cache_alloc and slub_debug=Z Marco Elver
2020-08-07 17:06 ` Pekka Enberg
2020-08-07 17:18 ` Marco Elver
2020-08-07 19:06 ` Pekka Enberg
2020-08-17 18:31 ` Marco Elver
2020-10-08 23:10 ` Kees Cook [this message]
2020-08-07 17:16 ` Kees Cook
2020-08-07 17:20 ` Marco Elver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202010081608.E1401C067@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@gmail.com \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.