LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Cc: Marco Elver <elver@google.com>,
	Nicholas Tang <nicholas.tang@mediatek.com>,
	Andrew Yang <andrew.yang@mediatek.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	Alexander Potapenko <glider@google.com>,
	Chinwen Chang <chinwen.chang@mediatek.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	kasan-dev@googlegroups.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH 1/2] kasan, mm: reset tag when access metadata
Date: Tue, 27 Jul 2021 20:22:18 +0100	[thread overview]
Message-ID: <20210727192217.GV13920@arm.com> (raw)
In-Reply-To: <b6b96caf30e62996fa3b75ae8d146c9cc0dcbbf6.camel@mediatek.com>

On Tue, Jul 27, 2021 at 04:32:02PM +0800, Kuan-Ying Lee wrote:
> On Tue, 2021-07-27 at 09:10 +0200, Marco Elver wrote:
> > +Cc Catalin
> > 
> > On Tue, 27 Jul 2021 at 06:00, Kuan-Ying Lee <
> > Kuan-Ying.Lee@mediatek.com> wrote:
> > > 
> > > Hardware tag-based KASAN doesn't use compiler instrumentation, we
> > > can not use kasan_disable_current() to ignore tag check.
> > > 
> > > Thus, we need to reset tags when accessing metadata.
> > > 
> > > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
> > 
> > This looks reasonable, but the patch title is not saying this is
> > kmemleak, nor does the description say what the problem is. What
> > problem did you encounter? Was it a false positive?
> 
> kmemleak would scan kernel memory to check memory leak.
> When it scans on the invalid slab and dereference, the issue
> will occur like below.
> 
> So I think we should reset the tag before scanning.
> 
> # echo scan > /sys/kernel/debug/kmemleak
> [  151.905804]
> ==================================================================
> [  151.907120] BUG: KASAN: out-of-bounds in scan_block+0x58/0x170
> [  151.908773] Read at addr f7ff0000c0074eb0 by task kmemleak/138
> [  151.909656] Pointer tag: [f7], memory tag: [fe]

It would be interesting to find out why the tag doesn't match. Kmemleak
should in principle only scan valid objects that have been allocated and
the pointer can be safely dereferenced. 0xfe is KASAN_TAG_INVALID, so it
either goes past the size of the object (into the red zone) or it still
accesses the object after it was marked as freed but before being
released from kmemleak.

With slab, looking at __cache_free(), it calls kasan_slab_free() before
___cache_free() -> kmemleak_free_recursive(), so the second scenario is
possible. With slub, however, slab_free_hook() first releases the object
from kmemleak before poisoning it. Based on the stack dump, you are
using slub, so it may be that kmemleak goes into the object red zones.

I'd like this clarified before blindly resetting the tag.

-- 
Catalin

  parent reply	other threads:[~2021-07-27 19:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-27  4:00 [PATCH 0/2] " Kuan-Ying Lee
2021-07-27  4:00 ` [PATCH 1/2] " Kuan-Ying Lee
2021-07-27  7:10   ` Marco Elver
2021-07-27  8:32     ` Kuan-Ying Lee
2021-07-27  9:34       ` Marco Elver
2021-07-27 19:22       ` Catalin Marinas [this message]
2021-07-28 11:05         ` Kuan-Ying Lee
2021-07-28 12:43           ` Marco Elver
2021-07-30 14:57         ` Andrey Konovalov
2021-07-30 15:24           ` Catalin Marinas
2021-07-27  4:00 ` [PATCH 2/2] kasan, mm: reset tag for hex dump address Kuan-Ying Lee
2021-07-27  7:20   ` Marco Elver
2021-07-27  8:54     ` Kuan-Ying Lee

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=20210727192217.GV13920@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=Kuan-Ying.Lee@mediatek.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew.yang@mediatek.com \
    --cc=andreyknvl@gmail.com \
    --cc=chinwen.chang@mediatek.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=nicholas.tang@mediatek.com \
    --cc=ryabinin.a.a@gmail.com \
    --subject='Re: [PATCH 1/2] kasan, mm: reset tag when access metadata' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).