linux-kernel - Re: [PATCH 0/3] kasan: memorize and print call

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1588746219.16219.10.camel@mtksdccf07>
Date:   Wed, 6 May 2020 14:23:39 +0800
From:   Walter Wu <walter-zh.wu@...iatek.com>
To:     Qian Cai <cai@....pw>
CC:     Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Alexander Potapenko <glider@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        "Paul E . McKenney" <paulmck@...nel.org>,
        "Josh Triplett" <josh@...htriplett.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        <kasan-dev@...glegroups.com>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        wsd_upstream <wsd_upstream@...iatek.com>,
        <linux-mediatek@...ts.infradead.org>
Subject: Re: [PATCH 0/3] kasan: memorize and print call_rcu stack

On Wed, 2020-05-06 at 01:53 -0400, Qian Cai wrote:
> 
> > On May 6, 2020, at 1:19 AM, Walter Wu <walter-zh.wu@...iatek.com> wrote:
> > 
> > This patchset improves KASAN reports by making them to have
> > call_rcu() call stack information. It is helpful for programmers
> > to solve use-after-free or double-free memory issue.
> > 
> > The KASAN report was as follows(cleaned up slightly):
> > 
> > BUG: KASAN: use-after-free in kasan_rcu_reclaim+0x58/0x60
> > 
> > Freed by task 0:
> > save_stack+0x24/0x50
> > __kasan_slab_free+0x110/0x178
> > kasan_slab_free+0x10/0x18
> > kfree+0x98/0x270
> > kasan_rcu_reclaim+0x1c/0x60
> > rcu_core+0x8b4/0x10f8
> > rcu_core_si+0xc/0x18
> > efi_header_end+0x238/0xa6c
> > 
> > First call_rcu() call stack:
> > save_stack+0x24/0x50
> > kasan_record_callrcu+0xc8/0xd8
> > call_rcu+0x190/0x580
> > kasan_rcu_uaf+0x1d8/0x278
> > 
> > Last call_rcu() call stack:
> > (stack is not available)
> > 
> > 
> > Add new CONFIG option to record first and last call_rcu() call stack
> > and KASAN report prints two call_rcu() call stack.
> > 
> > This option doesn't increase the cost of memory consumption. It is
> > only suitable for generic KASAN.
> 
> I don’t understand why this needs to be a Kconfig option at all. If call_rcu() stacks are useful in general, then just always gather those information. How do developers judge if they need to select this option or not?

Because we don't want to increase slub meta-data size, so enabling this
option can print call_rcu() stacks, but the in-use slub object doesn't
print free stack. So if have out-of-bound issue, then it will not print
free stack. It is a trade-off, see [1].

[1] https://bugzilla.kernel.org/show_bug.cgi?id=198437

Thanks