From: CGEL <cgel.zte@gmail.com>
To: Marco Elver <elver@google.com>
Cc: glider@google.com, akpm@linux-foundation.org, dvyukov@google.com,
kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, xu xin <xu.xin16@zte.com.cn>,
Zeal Robot <zealci@zte.com.cn>
Subject: Re: [PATCH] mm/kfence: fix a potential NULL pointer dereference
Date: Wed, 27 Apr 2022 08:45:29 +0000 [thread overview]
Message-ID: <626902ab.1c69fb81.44f01.9c06@mx.google.com> (raw)
In-Reply-To: <CANpmjNM8hKG+HH+pBR4cDLcU-sUWFO6t4CF89bt5uess0Zm3dg@mail.gmail.com>
On Wed, Apr 27, 2022 at 09:33:52AM +0200, Marco Elver wrote:
> On Wed, 27 Apr 2022 at 09:11, <cgel.zte@gmail.com> wrote:
> >
> > From: xu xin <xu.xin16@zte.com.cn>
> >
> > In __kfence_free(), the returned 'meta' from addr_to_metadata()
> > might be NULL just as the implementation of addr_to_metadata()
> > shows.
> >
> > Let's add a check of the pointer 'meta' to avoid NULL pointer
> > dereference. The patch brings three changes:
> >
> > 1. Add checks in both kfence_free() and __kfence_free();
> > 2. kfence_free is not inline function any longer and new inline
> > function '__try_free_kfence_meta' is introduced.
>
> This is very bad for performance (see below).
>
> > 3. The check of is_kfence_address() is not required for
> > __kfence_free() now because __kfence_free has done the check in
> > addr_to_metadata();
> >
> > Reported-by: Zeal Robot <zealci@zte.com.cn>
>
> Is this a static analysis robot? Please show a real stack trace with
> an actual NULL-deref.
>
> Nack - please see:
> https://lore.kernel.org/all/CANpmjNO5-o1B9r2eYS_482RBVJSyPoHSnV2t+M8fJdFzBf6d2A@mail.gmail.com/
>
Thanks for your reply. It's from static analysis indeed and no actual
NULL-deref event happened yet.
I'm just worried that what if address at the edge of __kfence_pool and
thus addr_to_metadata() returns NULL. Is is just a guess, I'm not sure.
But if __kfence_free make sure that the given address never is at the
edge of __kfence_pool, then the calculation and check in
addr_to_metadata() is extra performance consumption:
"index = (addr - (unsigned long)__kfence_pool) / (PAGE_SIZE * 2) - 1;
if (index < 0 || index >= CONFIG_KFENCE_NUM_OBJECTS) 240
return NULL;"
> >Signed-off-by: xu xin <xu.xin16@zte.com.cn>
> > ---
> > include/linux/kfence.h | 10 ++--------
> > mm/kfence/core.c | 30 +++++++++++++++++++++++++++---
> > 2 files changed, 29 insertions(+), 11 deletions(-)
> >
> > diff --git a/include/linux/kfence.h b/include/linux/kfence.h
> > index 726857a4b680..fbf6391ab53c 100644
> > --- a/include/linux/kfence.h
> > +++ b/include/linux/kfence.h
> > @@ -160,7 +160,7 @@ void *kfence_object_start(const void *addr);
> > * __kfence_free() - release a KFENCE heap object to KFENCE pool
> > * @addr: object to be freed
> > *
> > - * Requires: is_kfence_address(addr)
> > + * Requires: is_kfence_address(addr), but now it's unnecessary
>
> (As an aside, something can't be required and be unnecessary at the same time.)
Oh, I'm sorry for this. In my opinion, inner addr_to_metadata(),
is_kfence_address is executed for the second time, so not necessary here.
next prev parent reply other threads:[~2022-04-27 8:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-27 7:11 [PATCH] mm/kfence: fix a potential NULL pointer dereference cgel.zte
2022-04-27 7:33 ` Marco Elver
2022-04-27 8:45 ` CGEL [this message]
2022-04-27 8:51 ` kernel test robot
2022-04-27 11:37 ` kernel test robot
2022-04-27 12:18 ` kernel test robot
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=626902ab.1c69fb81.44f01.9c06@mx.google.com \
--to=cgel.zte@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=xu.xin16@zte.com.cn \
--cc=zealci@zte.com.cn \
/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.