On Tue, Mar 16, 2021 at 8:59 AM Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > > On Tue, Mar 16, 2021 at 8:18 AM syzbot > <syzbot+0b06ef9b44d00d600183@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: 1e28eed1 Linux 5.12-rc3 > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=167535e6d00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=e0cee1f53de33ca3 > > dashboard link: https://syzkaller.appspot.com/bug?extid=0b06ef9b44d00d600183 > > userspace arch: arm > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+0b06ef9b44d00d600183@xxxxxxxxxxxxxxxxxxxxxxxxx > > +arm32 maintainer > I think this is a real stack overflow on arm32, the stack is indeed deep. Nice find. I see there was already a second report, so it seems to be reproducible as well. If you are able to trigger this reliably, you could try printing the frame pointer while unwinding to see what is actually going on: --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -68,8 +68,8 @@ void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long end = frame + 4 + sizeof(struct pt_regs); #ifdef CONFIG_KALLSYMS - printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS)\n", - loglvl, where, (void *)where, from, (void *)from); + printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS), frame %08lx\n", + loglvl, where, (void *)where, from, (void *)from, frame); #else printk("%sFunction entered at [<%08lx>] from [<%08lx>]\n", loglvl, where, from); If that doesn't help, I could have a look at the binary to see which functions in the call chain take a lot of stack space, if any. Which exact compiler version do you use for building these kernels? I can try doing a build with the same commit and config. This one function is one that I have seen before when looking at build warnings with KASAN: > > [<8073772c>] (integrity_kernel_read) from [<8073a904>] (ima_calc_file_hash_tfm+0x178/0x228 security/integrity/ima/ima_crypto.c:484) > > [<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_shash security/integrity/ima/ima_crypto.c:515 [inline]) > > [<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_hash+0x124/0x8b8 security/integrity/ima/ima_crypto.c:572) ima_calc_file_hash_tfm() has a SHASH_DESC_ON_STACK(), which by itself can use up 512 bytes, but KASAN sometimes triples this number. However, I see you do not actually have KASAN enabled, so there is probably more to it. Arnd
