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
| ||
|
Date: Wed, 30 Dec 2020 12:49:45 -0800 From: Linus Torvalds <torvalds@...ux-foundation.org> To: 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: [kasan] 97593cad00: RIP:kasan_record_aux_stack 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
Powered by blists - more mailing lists