linux-kernel - Re: Question on KASAN calltrace record in RT

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 14 Apr 2021 08:15:53 +0200
From:   Mike Galbraith <efault@....de>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     "Zhang, Qiang" <Qiang.Zhang@...driver.com>,
        Andrew Halaney <ahalaney@...hat.com>,
        "andreyknvl@...il.com" <andreyknvl@...il.com>,
        "ryabinin.a.a@...il.com" <ryabinin.a.a@...il.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kasan-dev@...glegroups.com" <kasan-dev@...glegroups.com>
Subject: Re: Question on KASAN calltrace record in RT

On Wed, 2021-04-14 at 07:26 +0200, Dmitry Vyukov wrote:
> On Wed, Apr 14, 2021 at 6:00 AM Mike Galbraith <efault@....de> wrote:
>
> > [    0.692437] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:943
> > [    0.692439] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
> > [    0.692442] Preemption disabled at:
> > [    0.692443] [<ffffffff811a1510>] on_each_cpu_cond_mask+0x30/0xb0
> > [    0.692451] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 5.12.0.g2afefec-tip-rt #5
> > [    0.692454] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 09/23/2013
> > [    0.692456] Call Trace:
> > [    0.692458]  ? on_each_cpu_cond_mask+0x30/0xb0
> > [    0.692462]  dump_stack+0x8a/0xb5
> > [    0.692467]  ___might_sleep.cold+0xfe/0x112
> > [    0.692471]  rt_spin_lock+0x1c/0x60
>
> HI Mike,
>
> If freeing pages from smp_call_function is not OK, then perhaps we
> need just to collect the objects to be freed to the task/CPU that
> executes kasan_quarantine_remove_cache and it will free them (we know
> it can free objects).

Yeah, RT will have to shove freeing into preemptible context.

> >
> > [   15.428008] ==================================================================
> > [   15.428011] BUG: KASAN: vmalloc-out-of-bounds in crash_setup_memmap_entries+0x17e/0x3a0
>
> This looks like a genuine kernel bug on first glance. I think it needs
> to be fixed rather than ignored.

I figured KASAN probably knew what it was talking about, I just wanted
it to either go find something shiny or leave lockdep the heck alone.

	-Mike