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] [day] [month] [year] [list]
Message-ID: <1605787613.29084.32.camel@mtksdccf07>
Date:   Thu, 19 Nov 2020 20:06:53 +0800
From:   Kuan-Ying Lee <Kuan-Ying.Lee@...iatek.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
CC:     Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Alexander Potapenko <glider@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Matthias Brugger" <matthias.bgg@...il.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        Linux-MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "Linux ARM" <linux-arm-kernel@...ts.infradead.org>,
        <linux-mediatek@...ts.infradead.org>, <nicholas.tang@...iatek.com>,
        Miles Chen <miles.chen@...iatek.com>,
        <guangye.yang@...iatek.com>,
        wsd_upstream <wsd_upstream@...iatek.com>
Subject: Re: [PATCH v2 1/1] kasan: fix object remain in offline per-cpu
 quarantine

On Tue, 2020-11-17 at 08:13 +0100, Dmitry Vyukov wrote:
> On Tue, Nov 17, 2020 at 7:46 AM Kuan-Ying Lee
> <Kuan-Ying.Lee@...iatek.com> wrote:
> >
> > On Mon, 2020-11-16 at 10:26 +0100, Dmitry Vyukov wrote:
> > > On Mon, Nov 16, 2020 at 7:30 AM Kuan-Ying Lee
> > > <Kuan-Ying.Lee@...iatek.com> wrote:
> > > >
> > > > We hit this issue in our internal test.
> > > > When enabling generic kasan, a kfree()'d object is put into per-cpu
> > > > quarantine first. If the cpu goes offline, object still remains in
> > > > the per-cpu quarantine. If we call kmem_cache_destroy() now, slub
> > > > will report "Objects remaining" error.
> > > >
> > > > [   74.982625] =============================================================================
> > > > [   74.983380] BUG test_module_slab (Not tainted): Objects remaining in test_module_slab on __kmem_cache_shutdown()
> > > > [   74.984145] -----------------------------------------------------------------------------
> > > > [   74.984145]
> > > > [   74.984883] Disabling lock debugging due to kernel taint
> > > > [   74.985561] INFO: Slab 0x(____ptrval____) objects=34 used=1 fp=0x(____ptrval____) flags=0x2ffff00000010200
> > > > [   74.986638] CPU: 3 PID: 176 Comm: cat Tainted: G    B             5.10.0-rc1-00007-g4525c8781ec0-dirty #10
> > > > [   74.987262] Hardware name: linux,dummy-virt (DT)
> > > > [   74.987606] Call trace:
> > > > [   74.987924]  dump_backtrace+0x0/0x2b0
> > > > [   74.988296]  show_stack+0x18/0x68
> > > > [   74.988698]  dump_stack+0xfc/0x168
> > > > [   74.989030]  slab_err+0xac/0xd4
> > > > [   74.989346]  __kmem_cache_shutdown+0x1e4/0x3c8
> > > > [   74.989779]  kmem_cache_destroy+0x68/0x130
> > > > [   74.990176]  test_version_show+0x84/0xf0
> > > > [   74.990679]  module_attr_show+0x40/0x60
> > > > [   74.991218]  sysfs_kf_seq_show+0x128/0x1c0
> > > > [   74.991656]  kernfs_seq_show+0xa0/0xb8
> > > > [   74.992059]  seq_read+0x1f0/0x7e8
> > > > [   74.992415]  kernfs_fop_read+0x70/0x338
> > > > [   74.993051]  vfs_read+0xe4/0x250
> > > > [   74.993498]  ksys_read+0xc8/0x180
> > > > [   74.993825]  __arm64_sys_read+0x44/0x58
> > > > [   74.994203]  el0_svc_common.constprop.0+0xac/0x228
> > > > [   74.994708]  do_el0_svc+0x38/0xa0
> > > > [   74.995088]  el0_sync_handler+0x170/0x178
> > > > [   74.995497]  el0_sync+0x174/0x180
> > > > [   74.996050] INFO: Object 0x(____ptrval____) @offset=15848
> > > > [   74.996752] INFO: Allocated in test_version_show+0x98/0xf0 age=8188 cpu=6 pid=172
> > > > [   75.000802]  stack_trace_save+0x9c/0xd0
> > > > [   75.002420]  set_track+0x64/0xf0
> > > > [   75.002770]  alloc_debug_processing+0x104/0x1a0
> > > > [   75.003171]  ___slab_alloc+0x628/0x648
> > > > [   75.004213]  __slab_alloc.isra.0+0x2c/0x58
> > > > [   75.004757]  kmem_cache_alloc+0x560/0x588
> > > > [   75.005376]  test_version_show+0x98/0xf0
> > > > [   75.005756]  module_attr_show+0x40/0x60
> > > > [   75.007035]  sysfs_kf_seq_show+0x128/0x1c0
> > > > [   75.007433]  kernfs_seq_show+0xa0/0xb8
> > > > [   75.007800]  seq_read+0x1f0/0x7e8
> > > > [   75.008128]  kernfs_fop_read+0x70/0x338
> > > > [   75.008507]  vfs_read+0xe4/0x250
> > > > [   75.008990]  ksys_read+0xc8/0x180
> > > > [   75.009462]  __arm64_sys_read+0x44/0x58
> > > > [   75.010085]  el0_svc_common.constprop.0+0xac/0x228
> > > > [   75.011006] kmem_cache_destroy test_module_slab: Slab cache still has objects
> > > >
> > > > Register a cpu hotplug function to remove all objects in the offline
> > > > per-cpu quarantine when cpu is going offline. Set a per-cpu variable
> > > > to indicate this cpu is offline.
> > > >
> > > > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@...iatek.com>
> > > > Suggested-by: Dmitry Vyukov <dvyukov@...gle.com>
> > > > Reported-by: Guangye Yang <guangye.yang@...iatek.com>
> > > > Cc: Andrey Ryabinin <aryabinin@...tuozzo.com>
> > > > Cc: Alexander Potapenko <glider@...gle.com>
> > > > Cc: Andrew Morton <akpm@...ux-foundation.org>
> > > > Cc: Matthias Brugger <matthias.bgg@...il.com>
> > > > ---
> > > >  mm/kasan/quarantine.c | 35 +++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 35 insertions(+)
> > > >
> > > > diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> > > > index 4c5375810449..16e618ea805e 100644
> > > > --- a/mm/kasan/quarantine.c
> > > > +++ b/mm/kasan/quarantine.c
> > > > @@ -29,6 +29,7 @@
> > > >  #include <linux/srcu.h>
> > > >  #include <linux/string.h>
> > > >  #include <linux/types.h>
> > > > +#include <linux/cpuhotplug.h>
> > > >
> > > >  #include "../slab.h"
> > > >  #include "kasan.h"
> > > > @@ -43,6 +44,7 @@ struct qlist_head {
> > > >         struct qlist_node *head;
> > > >         struct qlist_node *tail;
> > > >         size_t bytes;
> > > > +       bool offline;
> > > >  };
> > > >
> > > >  #define QLIST_INIT { NULL, NULL, 0 }
> > > > @@ -188,6 +190,11 @@ void quarantine_put(struct kasan_free_meta *info, struct kmem_cache *cache)
> > > >         local_irq_save(flags);
> > > >
> > > >         q = this_cpu_ptr(&cpu_quarantine);
> > > > +       if (q->offline) {
> > > > +               qlink_free(&info->quarantine_link, cache);
> > > > +               local_irq_restore(flags);
> > > > +               return;
> > > > +       }
> >
> > I think we need to make sure objects will not be put in per-cpu
> > quarantine which is offline.
> >
> > > >         qlist_put(q, &info->quarantine_link, cache->size);
> > > >         if (unlikely(q->bytes > QUARANTINE_PERCPU_SIZE)) {
> > > >                 qlist_move_all(q, &temp);
> > > > @@ -328,3 +335,31 @@ void quarantine_remove_cache(struct kmem_cache *cache)
> > > >
> > > >         synchronize_srcu(&remove_cache_srcu);
> > > >  }
> > > > +
> > > > +static int kasan_cpu_online(unsigned int cpu)
> > > > +{
> > > > +       this_cpu_ptr(&cpu_quarantine)->offline = false;
> > > > +       return 0;
> > > > +}
> > > > +
> > > > +static int kasan_cpu_offline(unsigned int cpu)
> > > > +{
> > > > +       struct qlist_head *q;
> > > > +
> > > > +       q = this_cpu_ptr(&cpu_quarantine);
> > > > +       q->offline = true;
> > > > +       qlist_free_all(q, NULL);
> > >
> > > Looks much nicer now!
> > >
> > > What is the story with interrupts in these callbacks?
> > > In the previous patch you mentioned that this CPU can still receive
> > > interrupts for a brief period of time. If these interrupts also free
> > > something, can't we corrupt the per-cpu quarantine? In quarantine_put
> > > we protect it by disabling interrupts I think.
> > >
> >
> > Here is a situation.
> > After we freed all objects from the per-cpu quarantine which is going
> > offline, the interrupts happened. These interrupts free something and
> > put objects into this per-cpu quarantine. If we call
> > kmem_cache_destroy() now, slub still detect objects remain in
> > the per-cpu quarantine and report "Object remaining" error.
> >
> > Thus, we need to check q->offline in quarantine_put and make sure
> > the offline per-cpu quarantine is not corrupted.
> 
> If an interrupt can happen later, can't it happen right during our
> call to qlist_free_all and corrupt the per-cpu cache?
> Perhaps we need something like:
> 
> // ... explain the subtleness ...
> WRITE_ONCE(q->offline, true);
> barrier();
> qlist_free_all(q, NULL);
> 
> ?

Yes, we need to add barrier to ensure the ordering.
I did not think about that before.
Thanks for the reminder.
I will fix in v3.

> 
> > > > +       return 0;
> > > > +}
> > > > +
> > > > +static int __init kasan_cpu_offline_quarantine_init(void)
> > > > +{
> > > > +       int ret = 0;
> > > > +
> > > > +       ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "mm/kasan:online",
> > > > +                               kasan_cpu_online, kasan_cpu_offline);
> > > > +       if (ret < 0)
> > > > +               pr_err("kasan offline cpu quarantine register failed [%d]\n", ret);
> > > > +       return ret;
> > > > +}
> > > > +late_initcall(kasan_cpu_offline_quarantine_init);
> > > > --
> > > > 2.18.0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ