linux-kernel - Re: [PATCH v4 3/6] kasan: print timer and workqueue stack

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CANpmjNP6gKToqT-EZM88ZoedWfyHr86EB2s9sKEtzTxBVQe_Lg@mail.gmail.com>
Date:   Thu, 24 Sep 2020 14:21:20 +0200
From:   Marco Elver <elver@...gle.com>
To:     Alexander Potapenko <glider@...gle.com>
Cc:     Walter Wu <walter-zh.wu@...iatek.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        Linux Memory Management List <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        wsd_upstream <wsd_upstream@...iatek.com>,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v4 3/6] kasan: print timer and workqueue stack

On Thu, 24 Sep 2020 at 14:11, Alexander Potapenko <glider@...gle.com> wrote:
>
> On Thu, Sep 24, 2020 at 1:55 PM Marco Elver <elver@...gle.com> wrote:
> >
> > On Thu, 24 Sep 2020 at 13:47, Alexander Potapenko <glider@...gle.com> wrote:
> > >
> > > On Thu, Sep 24, 2020 at 6:05 AM Walter Wu <walter-zh.wu@...iatek.com> wrote:
> > > >
> > > > The aux_stack[2] is reused to record the call_rcu() call stack,
> > > > timer init call stack, and enqueuing work call stacks. So that
> > > > we need to change the auxiliary stack title for common title,
> > > > print them in KASAN report.
> > > >
> > > > Signed-off-by: Walter Wu <walter-zh.wu@...iatek.com>
> > > > Suggested-by: Marco Elver <elver@...gle.com>
> > > > Acked-by: Marco Elver <elver@...gle.com>
> > > > Reviewed-by: Dmitry Vyukov <dvyukov@...gle.com>
> > > > Reviewed-by: Andrey Konovalov <andreyknvl@...gle.com>
> > > > Cc: Andrey Ryabinin <aryabinin@...tuozzo.com>
> > > > Cc: Alexander Potapenko <glider@...gle.com>
> > > > ---
> > > >
> > > > v2:
> > > > - Thanks for Marco suggestion.
> > > > - We modify aux stack title name in KASAN report
> > > >   in order to print call_rcu()/timer/workqueue stack.
> > > >
> > > > ---
> > > >  mm/kasan/report.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > > > index 4f49fa6cd1aa..886809d0a8dd 100644
> > > > --- a/mm/kasan/report.c
> > > > +++ b/mm/kasan/report.c
> > > > @@ -183,12 +183,12 @@ static void describe_object(struct kmem_cache *cache, void *object,
> > > >
> > > >  #ifdef CONFIG_KASAN_GENERIC
> > > >                 if (alloc_info->aux_stack[0]) {
> > > > -                       pr_err("Last call_rcu():\n");
> > > > +                       pr_err("Last potentially related work creation:\n");
> > >
> > > This doesn't have to be a work creation (expect more callers of
> > > kasan_record_aux_stack() in the future), so maybe change the wording
> > > here to "Last potentially related auxiliary stack"?
> >
> > I suggested "work creation" as it's the most precise for what it is
> > used for now.
>
> I see, then maybe my suggestion is premature.
>
> > What other users do you have in mind in future that are not work creation?
>
> I think saving stacks may help in any case where an object is reused
> for a different purpose without reallocation.
> SKBs, maybe?

I currently don't know, it's hard to say without having a report that
we can't debug without it.

The litmus test for if it's useful would probably be "do we need this
stacktrace to debug a use-after-free/double-free?". If the answer is
maybe (and not yes!), I'd err on the side of not going overboard with
these, because we only have limited storage anyway. "Work creation" is
a clear case of "we loose information to the original caller" and need
it to debug. But of course, if there are similar issues elsewhere, we
need to identify them and then decide if we need it.