linux-kernel - Re: [LKP] Re: [kasan] 97593cad00: RIP:kasan_record_aux

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 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]

Date:   Thu, 31 Dec 2020 08:37:33 +0800
From:   Rong Chen <rong.a.chen@...el.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        kernel test robot <oliver.sang@...el.com>
Cc:     Andrey Konovalov <andreyknvl@...gle.com>,
        Vincenzo Frascino <Vincenzo.Frascino@....com>,
        Marco Elver <elver@...gle.com>,
        Alexander Potapenko <glider@...gle.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Branislav Rankov <Branislav.Rankov@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Evgenii Stepanov <eugenis@...gle.com>,
        Kevin Brodsky <kevin.brodsky@....com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Will Deacon <will.deacon@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
        kernel test robot <lkp@...el.com>
Subject: Re: [LKP] Re: [kasan] 97593cad00: RIP:kasan_record_aux_stack



On 12/31/20 4:49 AM, Linus Torvalds wrote:
> On Tue, Dec 29, 2020 at 6:59 PM kernel test robot <oliver.sang@...el.com> wrote:
>> [  235.553325] BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1351
>> [  235.554684] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 7515, name: trinity-c1
>> [  235.555890] 2 locks held by trinity-c1/7515:
>> [  235.556506]  #0: ffffffff8323dd38 (&ids->rwsem){....}-{3:3}, at: semctl_down+0x6d/0x686
>> [  235.557684]  #1: ffff888128ccc868 (&mm->mmap_lock#2){....}-{3:3}, at: do_user_addr_fault+0x196/0x59e
>> [  235.559020] CPU: 1 PID: 7515 Comm: trinity-c1 Not tainted 5.10.0-g97593cad003c #2
>> [  235.560317] Call Trace:
>> [  235.560767]  dump_stack+0x7d/0xa3
>> [  235.561371]  ___might_sleep+0x2c4/0x2df
>> [  235.562063]  ? do_user_addr_fault+0x196/0x59e
>> [  235.562834]  do_user_addr_fault+0x234/0x59e
>> [  235.563519]  exc_page_fault+0x70/0x8b
>> [  235.564112]  asm_exc_page_fault+0x1b/0x20
> Btw, I wonder if the kernel test robot dumps could be please run through the
>
>   scripts/decode_stacktrace.sh
>
> script to give line numbers and inlining information?
>
> That does require CONFIG_DEBUG_INFO to work, but it would help things
> like this when you don't have to try to guess where the exact access
> happens.
>
> Now, in this case, it seems to be a recursive issue with the original
> fault happening in:
>
>> [  235.564754] RIP: 0010:kasan_record_aux_stack+0x64/0x74
> And yeah, that explains why it then bisects to 97593cad003c ("kasan:
> sanitize objects when metadata doesn't fit")
>
> The faulting instruction sequence decodes to
>
>    10:   48 39 f3                cmp    %rsi,%rbx
>    13:   48 0f 46 f3             cmovbe %rbx,%rsi
>    17:   e8 6f e5 ff ff          callq  .. something ..
>    1c:   bf 00 08 00 00          mov    $0x800,%edi
>    21:   48 89 c3                mov    %rax,%rbx
>    24:*  8b 40 08                mov    0x8(%rax),%eax           <--
> trapping instruction
>    27:   89 43 0c                mov    %eax,0xc(%rbx)
>
> and I *think* that "call something" is the call to
> kasan_get_alloc_meta. And there is no check for a NULL return.
>
> So I think this was already fixed by commit 13384f6125ad ("kasan: fix
> null pointer dereference in kasan_record_aux_stack").
>
> But see about that "decode_stacktrace,sh" script request. I thought I
> had already asked for this, but I now realize that I think that was
> just for syzbot.
>
> Can we do that for these kernel test robot reports too? Please?
>
>               Linus

Hi Linus,

Sorry for the inconvenience and we're working on it right now.

Happy New Year!

Best Regards,
Rong Chen