From: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
To: Marco Elver <elver@google.com>
Cc: 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>,
Catalin Marinas <catalin.marinas@arm.com>,
<Kuan-Ying.Lee@mediatek.com>
Subject: Re: [PATCH 1/2] kasan, mm: reset tag when access metadata
Date: Tue, 27 Jul 2021 16:32:02 +0800 [thread overview]
Message-ID: <b6b96caf30e62996fa3b75ae8d146c9cc0dcbbf6.camel@mediatek.com> (raw)
In-Reply-To: <CANpmjNM03Pag9OvBBVnWnSBePRxsT+BvZtBwrh_61Qzmvp+dvA@mail.gmail.com>
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]
[ 151.910195]
[ 151.910876] CPU: 7 PID: 138 Comm: kmemleak Not tainted 5.14.0-rc2-
00001-g8cae8cd89f05-dirty #134
[ 151.912085] Hardware name: linux,dummy-virt (DT)
[ 151.912868] Call trace:
[ 151.913211] dump_backtrace+0x0/0x1b0
[ 151.913796] show_stack+0x1c/0x30
[ 151.914248] dump_stack_lvl+0x68/0x84
[ 151.914778] print_address_description+0x7c/0x2b4
[ 151.915340] kasan_report+0x138/0x38c
[ 151.915804] __do_kernel_fault+0x190/0x1c4
[ 151.916386] do_tag_check_fault+0x78/0x90
[ 151.916856] do_mem_abort+0x44/0xb4
[ 151.917308] el1_abort+0x40/0x60
[ 151.917754] el1h_64_sync_handler+0xb4/0xd0
[ 151.918270] el1h_64_sync+0x78/0x7c
[ 151.918714] scan_block+0x58/0x170
[ 151.919157] scan_gray_list+0xdc/0x1a0
[ 151.919626] kmemleak_scan+0x2ac/0x560
[ 151.920129] kmemleak_scan_thread+0xb0/0xe0
[ 151.920635] kthread+0x154/0x160
[ 151.921115] ret_from_fork+0x10/0x18
[ 151.921717]
[ 151.922077] Allocated by task 0:
[ 151.922523] kasan_save_stack+0x2c/0x60
[ 151.923099] __kasan_kmalloc+0xec/0x104
[ 151.923502] __kmalloc+0x224/0x3c4
[ 151.924172] __register_sysctl_paths+0x200/0x290
[ 151.924709] register_sysctl_table+0x2c/0x40
[ 151.925175] sysctl_init+0x20/0x34
[ 151.925665] proc_sys_init+0x3c/0x48
[ 151.926136] proc_root_init+0x80/0x9c
[ 151.926547] start_kernel+0x648/0x6a4
[ 151.926987] __primary_switched+0xc0/0xc8
[ 151.927557]
[ 151.927994] Freed by task 0:
[ 151.928340] kasan_save_stack+0x2c/0x60
[ 151.928766] kasan_set_track+0x2c/0x40
[ 151.929173] kasan_set_free_info+0x44/0x54
[ 151.929568] ____kasan_slab_free.constprop.0+0x150/0x1b0
[ 151.930063] __kasan_slab_free+0x14/0x20
[ 151.930449] slab_free_freelist_hook+0xa4/0x1fc
[ 151.930924] kfree+0x1e8/0x30c
[ 151.931285] put_fs_context+0x124/0x220
[ 151.931731] vfs_kern_mount.part.0+0x60/0xd4
[ 151.932280] kern_mount+0x24/0x4c
[ 151.932686] bdev_cache_init+0x70/0x9c
[ 151.933122] vfs_caches_init+0xdc/0xf4
[ 151.933578] start_kernel+0x638/0x6a4
[ 151.934014] __primary_switched+0xc0/0xc8
[ 151.934478]
[ 151.934757] The buggy address belongs to the object at
ffff0000c0074e00
[ 151.934757] which belongs to the cache kmalloc-256 of size 256
[ 151.935744] The buggy address is located 176 bytes inside of
[ 151.935744] 256-byte region [ffff0000c0074e00, ffff0000c0074f00)
[ 151.936702] The buggy address belongs to the page:
[ 151.937378] page:(____ptrval____) refcount:1 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0x100074
[ 151.938682] head:(____ptrval____) order:2 compound_mapcount:0
compound_pincount:0
[ 151.939440] flags:
0xbfffc0000010200(slab|head|node=0|zone=2|lastcpupid=0xffff|kasantag=0x
0)
[ 151.940886] raw: 0bfffc0000010200 0000000000000000 dead000000000122
f5ff0000c0002300
[ 151.941634] raw: 0000000000000000 0000000000200020 00000001ffffffff
0000000000000000
[ 151.942353] page dumped because: kasan: bad access detected
[ 151.942923]
[ 151.943214] Memory state around the buggy address:
[ 151.943896] ffff0000c0074c00: f0 f0 f0 f0 f0 f0 f0 f0 f0 fe fe fe
fe fe fe fe
[ 151.944857] ffff0000c0074d00: fe fe fe fe fe fe fe fe fe fe fe fe
fe fe fe fe
[ 151.945892] >ffff0000c0074e00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 fe
fe fe fe fe
[ 151.946407] ^
[ 151.946939] ffff0000c0074f00: fe fe fe fe fe fe fe fe fe fe fe fe
fe fe fe fe
[ 151.947445] ffff0000c0075000: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 151.947999]
==================================================================
[ 151.948524] Disabling lock debugging due to kernel taint
[ 156.434569] kmemleak: 181 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
>
> Perhaps this should have been "kmemleak, kasan: reset pointer tags to
> avoid false positives" ?
Thanks for the suggestions.
But I think it doesn't belong to false
positive becuase scan block
touched invalid metadata certainly.
Maybe "kmemleak, kasan: reset tags when scanning block"?
>
> > ---
> > mm/kmemleak.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> > index 228a2fbe0657..73d46d16d575 100644
> > --- a/mm/kmemleak.c
> > +++ b/mm/kmemleak.c
> > @@ -290,7 +290,7 @@ static void hex_dump_object(struct seq_file
> > *seq,
> > warn_or_seq_printf(seq, " hex dump (first %zu bytes):\n",
> > len);
> > kasan_disable_current();
> > warn_or_seq_hex_dump(seq, DUMP_PREFIX_NONE, HEX_ROW_SIZE,
> > - HEX_GROUP_SIZE, ptr, len, HEX_ASCII);
> > + HEX_GROUP_SIZE, kasan_reset_tag((void
> > *)ptr), len, HEX_ASCII);
> > kasan_enable_current();
> > }
> >
> > @@ -1171,7 +1171,7 @@ static bool update_checksum(struct
> > kmemleak_object *object)
> >
> > kasan_disable_current();
> > kcsan_disable_current();
> > - object->checksum = crc32(0, (void *)object->pointer,
> > object->size);
> > + object->checksum = crc32(0, kasan_reset_tag((void *)object-
> > >pointer), object->size);
> > kasan_enable_current();
> > kcsan_enable_current();
> >
> > @@ -1246,7 +1246,7 @@ static void scan_block(void *_start, void
> > *_end,
> > break;
> >
> > kasan_disable_current();
> > - pointer = *ptr;
> > + pointer = *(unsigned long *)kasan_reset_tag((void
> > *)ptr);
> > kasan_enable_current();
> >
> > untagged_ptr = (unsigned long)kasan_reset_tag((void
> > *)pointer);
> > --
> > 2.18.0
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "kasan-dev" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to kasan-dev+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit
> > https://urldefense.com/v3/__https://groups.google.com/d/msgid/kasan-dev/20210727040021.21371-2-Kuan-Ying.Lee*40mediatek.com__;JQ!!CTRNKA9wMg0ARbw!wNP4ZkYDM7Xvs9xfzKwYuG1X2h9zFqST8_Vm2jSvZUl9BiS8SPFMTvMp3VAPKCnuWELL7Q$
> > .
next prev parent reply other threads:[~2021-07-27 8:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-27 4:00 [PATCH 0/2] kasan, mm: reset tag when access metadata 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 [this message]
2021-07-27 9:34 ` Marco Elver
2021-07-27 19:22 ` Catalin Marinas
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-08-04 5:31 ` kuan.ying lee
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=b6b96caf30e62996fa3b75ae8d146c9cc0dcbbf6.camel@mediatek.com \
--to=kuan-ying.lee@mediatek.com \
--cc=akpm@linux-foundation.org \
--cc=andrew.yang@mediatek.com \
--cc=andreyknvl@gmail.com \
--cc=catalin.marinas@arm.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 \
/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 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).