Re: [syzbot] kernel panic: corrupted stack end in openat

quoted

On Tue, Mar 16, 2021 at 8:18 AM syzbot
[off-list ref] wrote:

quoted

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@syzkaller.appspotmail.com

+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:

quoted

quoted

[<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.