* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 10:02 ` Arnd Bergmann
0 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2021-03-16 10:02 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, Russell King - ARM Linux, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 8:59 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Mar 16, 2021 at 8:18 AM syzbot
> <syzbot+0b06ef9b44d00d600183@syzkaller.appspotmail.com> 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@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:
> > [<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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 10:02 ` Arnd Bergmann
0 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2021-03-16 10:02 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, Russell King - ARM Linux, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 8:59 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Mar 16, 2021 at 8:18 AM syzbot
> <syzbot+0b06ef9b44d00d600183@syzkaller.appspotmail.com> 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@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:
> > [<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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
2021-03-16 10:02 ` Arnd Bergmann
(?)
@ 2021-03-16 10:17 ` Dmitry Vyukov
-1 siblings, 0 replies; 39+ messages in thread
From: Dmitry Vyukov @ 2021-03-16 10:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: syzbot, Russell King - ARM Linux, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > <syzbot+0b06ef9b44d00d600183@syzkaller.appspotmail.com> 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@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:
>
> > > [<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.
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
It's available in gcr.io/syzkaller/syzbot container.
(syzbot should have been provided the compiler version, something
broke, I've filed https://github.com/google/syzkaller/issues/2498 for
this)
Yes, KASAN is not enabled on arm32 for now.
Re printing FP, syzbot does not use custom patches:
http://bit.do/syzbot#no-custom-patches
But this does not seem to be syzbot-specific. It seems that any arm32
stack overflow report will be unactionable, so I think it would be
useful to include this into the mainline kernel to make overflow
reports useful for everybody (and for syzbot as a side effect).
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 10:17 ` Dmitry Vyukov
0 siblings, 0 replies; 39+ messages in thread
From: Dmitry Vyukov @ 2021-03-16 10:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: syzbot, Russell King - ARM Linux, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > <syzbot+0b06ef9b44d00d600183@syzkaller.appspotmail.com> 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@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:
>
> > > [<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.
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
It's available in gcr.io/syzkaller/syzbot container.
(syzbot should have been provided the compiler version, something
broke, I've filed https://github.com/google/syzkaller/issues/2498 for
this)
Yes, KASAN is not enabled on arm32 for now.
Re printing FP, syzbot does not use custom patches:
http://bit.do/syzbot#no-custom-patches
But this does not seem to be syzbot-specific. It seems that any arm32
stack overflow report will be unactionable, so I think it would be
useful to include this into the mainline kernel to make overflow
reports useful for everybody (and for syzbot as a side effect).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 10:17 ` Dmitry Vyukov
0 siblings, 0 replies; 39+ messages in thread
From: Dmitry Vyukov @ 2021-03-16 10:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: syzbot, Russell King - ARM Linux, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > <syzbot+0b06ef9b44d00d600183@syzkaller.appspotmail.com> 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@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:
>
> > > [<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.
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
It's available in gcr.io/syzkaller/syzbot container.
(syzbot should have been provided the compiler version, something
broke, I've filed https://github.com/google/syzkaller/issues/2498 for
this)
Yes, KASAN is not enabled on arm32 for now.
Re printing FP, syzbot does not use custom patches:
http://bit.do/syzbot#no-custom-patches
But this does not seem to be syzbot-specific. It seems that any arm32
stack overflow report will be unactionable, so I think it would be
useful to include this into the mainline kernel to make overflow
reports useful for everybody (and for syzbot as a side effect).
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
2021-03-16 10:17 ` Dmitry Vyukov
(?)
@ 2021-03-16 15:44 ` Arnd Bergmann
-1 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2021-03-16 15:44 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, Russell King - ARM Linux, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Tue, Mar 16, 2021 at 8:18 AM syzbot
>
> > > > [<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.
>
> The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
the closest I have installed, and I think the Debian and Ubuntu versions
are generally quite close in case of gcc since they are maintained by
the same packagers.
I see ima_calc_field_array_hash_tfm() shows up as one of the larger
stack users, but not alarmingly high:
../security/integrity/ima/ima_crypto.c: In function
‘ima_calc_field_array_hash_tfm’:
../security/integrity/ima/ima_crypto.c:624:1: warning: the frame size
of 664 bytes is larger than 600 bytes [-Wframe-larger-than=]
none of the other functions from the call chain have more than 600 bytes
in this combination of config/compiler/sourcetree.
In combination, I don't get to more than ~2300 bytes:
[<818033d8>] (panic)
52 [<8181f5b8>] (__schedule)
0 [<81820430>] (preempt_schedule_common)
0 [<818204dc>] (preempt_schedule)
0 [<8048c7c0>] (kernel_init_free_pages)
148 [<804916ac>] (get_page_from_freelist
212 [<80493264>] (__alloc_pages_nodemask)
44 [<8042f034>] (page_cache_ra_unbounded)
36 [<8042f2c8>] (do_page_cache_ra)
28 [<8042f418>] (ondemand_readahead)
0 [<8042f894>] (page_cache_async_ra)
68 [<80420ac8>] (filemap_get_pages)
120 [<80421110>] (filemap_read)
36 [<804215f0>] (generic_file_read_iter)
8 [<805ff430>] (ext4_file_read_iter)
96 [<804da3cc>] (__kernel_read)
8 [<8073772c>] (integrity_kernel_read)
412 [<8073a78c>] (ima_calc_file_hash_tfm)
164 [<8073ad08>] (ima_calc_file_hash)
106 [<8073bf84>] (ima_collect_measurement)
332 [<80738fec>] (process_measurement)
24 [<8073979c>] (ima_file_check)
172 [<804ec66c>] (path_openat)
152 [<804ef670>] (do_filp_open)
40 [<804d79c4>] (do_sys_openat2)
> Re printing FP, syzbot does not use custom patches:
> http://bit.do/syzbot#no-custom-patches
> But this does not seem to be syzbot-specific. It seems that any arm32
> stack overflow report will be unactionable, so I think it would be
> useful to include this into the mainline kernel to make overflow
> reports useful for everybody (and for syzbot as a side effect).
ok.
Arnd
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 15:44 ` Arnd Bergmann
0 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2021-03-16 15:44 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, Russell King - ARM Linux, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Tue, Mar 16, 2021 at 8:18 AM syzbot
>
> > > > [<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.
>
> The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
the closest I have installed, and I think the Debian and Ubuntu versions
are generally quite close in case of gcc since they are maintained by
the same packagers.
I see ima_calc_field_array_hash_tfm() shows up as one of the larger
stack users, but not alarmingly high:
../security/integrity/ima/ima_crypto.c: In function
‘ima_calc_field_array_hash_tfm’:
../security/integrity/ima/ima_crypto.c:624:1: warning: the frame size
of 664 bytes is larger than 600 bytes [-Wframe-larger-than=]
none of the other functions from the call chain have more than 600 bytes
in this combination of config/compiler/sourcetree.
In combination, I don't get to more than ~2300 bytes:
[<818033d8>] (panic)
52 [<8181f5b8>] (__schedule)
0 [<81820430>] (preempt_schedule_common)
0 [<818204dc>] (preempt_schedule)
0 [<8048c7c0>] (kernel_init_free_pages)
148 [<804916ac>] (get_page_from_freelist
212 [<80493264>] (__alloc_pages_nodemask)
44 [<8042f034>] (page_cache_ra_unbounded)
36 [<8042f2c8>] (do_page_cache_ra)
28 [<8042f418>] (ondemand_readahead)
0 [<8042f894>] (page_cache_async_ra)
68 [<80420ac8>] (filemap_get_pages)
120 [<80421110>] (filemap_read)
36 [<804215f0>] (generic_file_read_iter)
8 [<805ff430>] (ext4_file_read_iter)
96 [<804da3cc>] (__kernel_read)
8 [<8073772c>] (integrity_kernel_read)
412 [<8073a78c>] (ima_calc_file_hash_tfm)
164 [<8073ad08>] (ima_calc_file_hash)
106 [<8073bf84>] (ima_collect_measurement)
332 [<80738fec>] (process_measurement)
24 [<8073979c>] (ima_file_check)
172 [<804ec66c>] (path_openat)
152 [<804ef670>] (do_filp_open)
40 [<804d79c4>] (do_sys_openat2)
> Re printing FP, syzbot does not use custom patches:
> http://bit.do/syzbot#no-custom-patches
> But this does not seem to be syzbot-specific. It seems that any arm32
> stack overflow report will be unactionable, so I think it would be
> useful to include this into the mainline kernel to make overflow
> reports useful for everybody (and for syzbot as a side effect).
ok.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 15:44 ` Arnd Bergmann
0 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2021-03-16 15:44 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, Russell King - ARM Linux, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Tue, Mar 16, 2021 at 8:18 AM syzbot
>
> > > > [<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.
>
> The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
the closest I have installed, and I think the Debian and Ubuntu versions
are generally quite close in case of gcc since they are maintained by
the same packagers.
I see ima_calc_field_array_hash_tfm() shows up as one of the larger
stack users, but not alarmingly high:
../security/integrity/ima/ima_crypto.c: In function
‘ima_calc_field_array_hash_tfm’:
../security/integrity/ima/ima_crypto.c:624:1: warning: the frame size
of 664 bytes is larger than 600 bytes [-Wframe-larger-than=]
none of the other functions from the call chain have more than 600 bytes
in this combination of config/compiler/sourcetree.
In combination, I don't get to more than ~2300 bytes:
[<818033d8>] (panic)
52 [<8181f5b8>] (__schedule)
0 [<81820430>] (preempt_schedule_common)
0 [<818204dc>] (preempt_schedule)
0 [<8048c7c0>] (kernel_init_free_pages)
148 [<804916ac>] (get_page_from_freelist
212 [<80493264>] (__alloc_pages_nodemask)
44 [<8042f034>] (page_cache_ra_unbounded)
36 [<8042f2c8>] (do_page_cache_ra)
28 [<8042f418>] (ondemand_readahead)
0 [<8042f894>] (page_cache_async_ra)
68 [<80420ac8>] (filemap_get_pages)
120 [<80421110>] (filemap_read)
36 [<804215f0>] (generic_file_read_iter)
8 [<805ff430>] (ext4_file_read_iter)
96 [<804da3cc>] (__kernel_read)
8 [<8073772c>] (integrity_kernel_read)
412 [<8073a78c>] (ima_calc_file_hash_tfm)
164 [<8073ad08>] (ima_calc_file_hash)
106 [<8073bf84>] (ima_collect_measurement)
332 [<80738fec>] (process_measurement)
24 [<8073979c>] (ima_file_check)
172 [<804ec66c>] (path_openat)
152 [<804ef670>] (do_filp_open)
40 [<804d79c4>] (do_sys_openat2)
> Re printing FP, syzbot does not use custom patches:
> http://bit.do/syzbot#no-custom-patches
> But this does not seem to be syzbot-specific. It seems that any arm32
> stack overflow report will be unactionable, so I think it would be
> useful to include this into the mainline kernel to make overflow
> reports useful for everybody (and for syzbot as a side effect).
ok.
Arnd
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
2021-03-16 15:44 ` Arnd Bergmann
@ 2021-03-16 15:51 ` Russell King - ARM Linux admin
-1 siblings, 0 replies; 39+ messages in thread
From: Russell King - ARM Linux admin @ 2021-03-16 15:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Dmitry Vyukov, syzbot, Linus Walleij, Linux ARM, Andrew Morton,
LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> >
> > > > > [<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.
> >
> > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
>
> Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> the closest I have installed, and I think the Debian and Ubuntu versions
> are generally quite close in case of gcc since they are maintained by
> the same packagers.
>
> I see ima_calc_field_array_hash_tfm() shows up as one of the larger
> stack users, but not alarmingly high:
> ../security/integrity/ima/ima_crypto.c: In function
> ‘ima_calc_field_array_hash_tfm’:
> ../security/integrity/ima/ima_crypto.c:624:1: warning: the frame size
> of 664 bytes is larger than 600 bytes [-Wframe-larger-than=]
> none of the other functions from the call chain have more than 600 bytes
> in this combination of config/compiler/sourcetree.
>
> In combination, I don't get to more than ~2300 bytes:
... which shouldn't be a problem - that's just over 1/4 of the stack
space. Could it be the syzbot's gcc is doing something weird and
inflating the stack frames?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 15:51 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 39+ messages in thread
From: Russell King - ARM Linux admin @ 2021-03-16 15:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Dmitry Vyukov, syzbot, Linus Walleij, Linux ARM, Andrew Morton,
LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> >
> > > > > [<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.
> >
> > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
>
> Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> the closest I have installed, and I think the Debian and Ubuntu versions
> are generally quite close in case of gcc since they are maintained by
> the same packagers.
>
> I see ima_calc_field_array_hash_tfm() shows up as one of the larger
> stack users, but not alarmingly high:
> ../security/integrity/ima/ima_crypto.c: In function
> ‘ima_calc_field_array_hash_tfm’:
> ../security/integrity/ima/ima_crypto.c:624:1: warning: the frame size
> of 664 bytes is larger than 600 bytes [-Wframe-larger-than=]
> none of the other functions from the call chain have more than 600 bytes
> in this combination of config/compiler/sourcetree.
>
> In combination, I don't get to more than ~2300 bytes:
... which shouldn't be a problem - that's just over 1/4 of the stack
space. Could it be the syzbot's gcc is doing something weird and
inflating the stack frames?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
2021-03-16 15:51 ` Russell King - ARM Linux admin
(?)
@ 2021-03-16 16:03 ` Dmitry Vyukov
-1 siblings, 0 replies; 39+ messages in thread
From: Dmitry Vyukov @ 2021-03-16 16:03 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Arnd Bergmann, syzbot, Linus Walleij, Linux ARM, Andrew Morton,
LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > >
> > > > > > [<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.
> > >
> > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> >
> > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > the closest I have installed, and I think the Debian and Ubuntu versions
> > are generally quite close in case of gcc since they are maintained by
> > the same packagers.
> >
> > I see ima_calc_field_array_hash_tfm() shows up as one of the larger
> > stack users, but not alarmingly high:
> > ../security/integrity/ima/ima_crypto.c: In function
> > ‘ima_calc_field_array_hash_tfm’:
> > ../security/integrity/ima/ima_crypto.c:624:1: warning: the frame size
> > of 664 bytes is larger than 600 bytes [-Wframe-larger-than=]
> > none of the other functions from the call chain have more than 600 bytes
> > in this combination of config/compiler/sourcetree.
> >
> > In combination, I don't get to more than ~2300 bytes:
>
> ... which shouldn't be a problem - that's just over 1/4 of the stack
> space. Could it be the syzbot's gcc is doing something weird and
> inflating the stack frames?
It's just a stock Debian-provided gcc. Which I would assume also just
a plain gcc.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 16:03 ` Dmitry Vyukov
0 siblings, 0 replies; 39+ messages in thread
From: Dmitry Vyukov @ 2021-03-16 16:03 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Arnd Bergmann, syzbot, Linus Walleij, Linux ARM, Andrew Morton,
LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > >
> > > > > > [<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.
> > >
> > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> >
> > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > the closest I have installed, and I think the Debian and Ubuntu versions
> > are generally quite close in case of gcc since they are maintained by
> > the same packagers.
> >
> > I see ima_calc_field_array_hash_tfm() shows up as one of the larger
> > stack users, but not alarmingly high:
> > ../security/integrity/ima/ima_crypto.c: In function
> > ‘ima_calc_field_array_hash_tfm’:
> > ../security/integrity/ima/ima_crypto.c:624:1: warning: the frame size
> > of 664 bytes is larger than 600 bytes [-Wframe-larger-than=]
> > none of the other functions from the call chain have more than 600 bytes
> > in this combination of config/compiler/sourcetree.
> >
> > In combination, I don't get to more than ~2300 bytes:
>
> ... which shouldn't be a problem - that's just over 1/4 of the stack
> space. Could it be the syzbot's gcc is doing something weird and
> inflating the stack frames?
It's just a stock Debian-provided gcc. Which I would assume also just
a plain gcc.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 16:03 ` Dmitry Vyukov
0 siblings, 0 replies; 39+ messages in thread
From: Dmitry Vyukov @ 2021-03-16 16:03 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Arnd Bergmann, syzbot, Linus Walleij, Linux ARM, Andrew Morton,
LKML, Linux-MM, syzkaller-bugs
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > >
> > > > > > [<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.
> > >
> > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> >
> > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > the closest I have installed, and I think the Debian and Ubuntu versions
> > are generally quite close in case of gcc since they are maintained by
> > the same packagers.
> >
> > I see ima_calc_field_array_hash_tfm() shows up as one of the larger
> > stack users, but not alarmingly high:
> > ../security/integrity/ima/ima_crypto.c: In function
> > ‘ima_calc_field_array_hash_tfm’:
> > ../security/integrity/ima/ima_crypto.c:624:1: warning: the frame size
> > of 664 bytes is larger than 600 bytes [-Wframe-larger-than=]
> > none of the other functions from the call chain have more than 600 bytes
> > in this combination of config/compiler/sourcetree.
> >
> > In combination, I don't get to more than ~2300 bytes:
>
> ... which shouldn't be a problem - that's just over 1/4 of the stack
> space. Could it be the syzbot's gcc is doing something weird and
> inflating the stack frames?
It's just a stock Debian-provided gcc. Which I would assume also just
a plain gcc.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
2021-03-16 15:51 ` Russell King - ARM Linux admin
@ 2021-03-16 16:03 ` Arnd Bergmann
-1 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2021-03-16 16:03 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Dmitry Vyukov, syzbot, Linus Walleij, Linux ARM, Andrew Morton,
LKML, Linux-MM, syzkaller-bugs, Uwe Kleine-König
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> >
> > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > the closest I have installed, and I think the Debian and Ubuntu versions
> > are generally quite close in case of gcc since they are maintained by
> > the same packagers.
>
> ... which shouldn't be a problem - that's just over 1/4 of the stack
> space. Could it be the syzbot's gcc is doing something weird and
> inflating the stack frames?
It's possible, I think that's really unlikely given that it's just Debian's
gcc, which is as close to mainline as the version I was using.
Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
help if this was the problem though:
https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
My best guess is something going wrong in the interrupt
that triggered the preempt_schedule() which ended up calling
task_stack_end_corrupted() in schedule_debug(), as you suggested
earlier.
Arnd
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 16:03 ` Arnd Bergmann
0 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2021-03-16 16:03 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Dmitry Vyukov, syzbot, Linus Walleij, Linux ARM, Andrew Morton,
LKML, Linux-MM, syzkaller-bugs, Uwe Kleine-König
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> >
> > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > the closest I have installed, and I think the Debian and Ubuntu versions
> > are generally quite close in case of gcc since they are maintained by
> > the same packagers.
>
> ... which shouldn't be a problem - that's just over 1/4 of the stack
> space. Could it be the syzbot's gcc is doing something weird and
> inflating the stack frames?
It's possible, I think that's really unlikely given that it's just Debian's
gcc, which is as close to mainline as the version I was using.
Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
help if this was the problem though:
https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
My best guess is something going wrong in the interrupt
that triggered the preempt_schedule() which ended up calling
task_stack_end_corrupted() in schedule_debug(), as you suggested
earlier.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
2021-03-16 16:03 ` Arnd Bergmann
@ 2021-03-16 16:13 ` Dmitry Vyukov
-1 siblings, 0 replies; 39+ messages in thread
From: Dmitry Vyukov @ 2021-03-16 16:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King - ARM Linux admin, syzbot, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs,
Uwe Kleine-König
On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> > >
> > > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > > the closest I have installed, and I think the Debian and Ubuntu versions
> > > are generally quite close in case of gcc since they are maintained by
> > > the same packagers.
> >
> > ... which shouldn't be a problem - that's just over 1/4 of the stack
> > space. Could it be the syzbot's gcc is doing something weird and
> > inflating the stack frames?
>
> It's possible, I think that's really unlikely given that it's just Debian's
> gcc, which is as close to mainline as the version I was using.
>
> Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
> help if this was the problem though:
> https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
>
> My best guess is something going wrong in the interrupt
> that triggered the preempt_schedule() which ended up calling
> task_stack_end_corrupted() in schedule_debug(), as you suggested
> earlier.
FWIW I see slightly larger frames with the config:
073ab64 <ima_calc_field_array_hash_tfm>:
8073ab64: e1a0c00d mov ip, sp
8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
fp, ip, lr, pc}
8073ab6c: e24cb004 sub fp, ip, #4
8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
page_alloc can also do reclaim, I had the impression that reclaim can
be quite heavy-weight in all respects.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 16:13 ` Dmitry Vyukov
0 siblings, 0 replies; 39+ messages in thread
From: Dmitry Vyukov @ 2021-03-16 16:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King - ARM Linux admin, syzbot, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs,
Uwe Kleine-König
On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> > >
> > > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > > the closest I have installed, and I think the Debian and Ubuntu versions
> > > are generally quite close in case of gcc since they are maintained by
> > > the same packagers.
> >
> > ... which shouldn't be a problem - that's just over 1/4 of the stack
> > space. Could it be the syzbot's gcc is doing something weird and
> > inflating the stack frames?
>
> It's possible, I think that's really unlikely given that it's just Debian's
> gcc, which is as close to mainline as the version I was using.
>
> Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
> help if this was the problem though:
> https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
>
> My best guess is something going wrong in the interrupt
> that triggered the preempt_schedule() which ended up calling
> task_stack_end_corrupted() in schedule_debug(), as you suggested
> earlier.
FWIW I see slightly larger frames with the config:
073ab64 <ima_calc_field_array_hash_tfm>:
8073ab64: e1a0c00d mov ip, sp
8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
fp, ip, lr, pc}
8073ab6c: e24cb004 sub fp, ip, #4
8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
page_alloc can also do reclaim, I had the impression that reclaim can
be quite heavy-weight in all respects.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
2021-03-16 16:13 ` Dmitry Vyukov
@ 2021-03-16 16:28 ` Arnd Bergmann
-1 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2021-03-16 16:28 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Russell King - ARM Linux admin, syzbot, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs,
Uwe Kleine-König
On Tue, Mar 16, 2021 at 5:13 PM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> > > >
> > > > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > > > the closest I have installed, and I think the Debian and Ubuntu versions
> > > > are generally quite close in case of gcc since they are maintained by
> > > > the same packagers.
> > >
> > > ... which shouldn't be a problem - that's just over 1/4 of the stack
> > > space. Could it be the syzbot's gcc is doing something weird and
> > > inflating the stack frames?
> >
> > It's possible, I think that's really unlikely given that it's just Debian's
> > gcc, which is as close to mainline as the version I was using.
> >
> > Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
> > help if this was the problem though:
> > https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
> >
> > My best guess is something going wrong in the interrupt
> > that triggered the preempt_schedule() which ended up calling
> > task_stack_end_corrupted() in schedule_debug(), as you suggested
> > earlier.
>
> FWIW I see slightly larger frames with the config:
>
> 073ab64 <ima_calc_field_array_hash_tfm>:
> 8073ab64: e1a0c00d mov ip, sp
> 8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
> fp, ip, lr, pc}
> 8073ab6c: e24cb004 sub fp, ip, #4
> 8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
Yes, this is the one that the compiler complained about when warning
for stack over 600 bytes. It's not called in this call chain though.
> page_alloc can also do reclaim, I had the impression that reclaim can
> be quite heavy-weight in all respects.
Yes, that is another possibility. What writable file systems or swap
do you normally have mounted that it could be writing to, and on
what storage device?
Arnd
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 16:28 ` Arnd Bergmann
0 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2021-03-16 16:28 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Russell King - ARM Linux admin, syzbot, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs,
Uwe Kleine-König
On Tue, Mar 16, 2021 at 5:13 PM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> > > >
> > > > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > > > the closest I have installed, and I think the Debian and Ubuntu versions
> > > > are generally quite close in case of gcc since they are maintained by
> > > > the same packagers.
> > >
> > > ... which shouldn't be a problem - that's just over 1/4 of the stack
> > > space. Could it be the syzbot's gcc is doing something weird and
> > > inflating the stack frames?
> >
> > It's possible, I think that's really unlikely given that it's just Debian's
> > gcc, which is as close to mainline as the version I was using.
> >
> > Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
> > help if this was the problem though:
> > https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
> >
> > My best guess is something going wrong in the interrupt
> > that triggered the preempt_schedule() which ended up calling
> > task_stack_end_corrupted() in schedule_debug(), as you suggested
> > earlier.
>
> FWIW I see slightly larger frames with the config:
>
> 073ab64 <ima_calc_field_array_hash_tfm>:
> 8073ab64: e1a0c00d mov ip, sp
> 8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
> fp, ip, lr, pc}
> 8073ab6c: e24cb004 sub fp, ip, #4
> 8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
Yes, this is the one that the compiler complained about when warning
for stack over 600 bytes. It's not called in this call chain though.
> page_alloc can also do reclaim, I had the impression that reclaim can
> be quite heavy-weight in all respects.
Yes, that is another possibility. What writable file systems or swap
do you normally have mounted that it could be writing to, and on
what storage device?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
2021-03-16 16:28 ` Arnd Bergmann
@ 2021-03-17 7:47 ` Dmitry Vyukov
-1 siblings, 0 replies; 39+ messages in thread
From: Dmitry Vyukov @ 2021-03-17 7:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King - ARM Linux admin, syzbot, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs,
Uwe Kleine-König
On Tue, Mar 16, 2021 at 5:28 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Mar 16, 2021 at 5:13 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > > > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > > > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> > > > >
> > > > > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > > > > the closest I have installed, and I think the Debian and Ubuntu versions
> > > > > are generally quite close in case of gcc since they are maintained by
> > > > > the same packagers.
> > > >
> > > > ... which shouldn't be a problem - that's just over 1/4 of the stack
> > > > space. Could it be the syzbot's gcc is doing something weird and
> > > > inflating the stack frames?
> > >
> > > It's possible, I think that's really unlikely given that it's just Debian's
> > > gcc, which is as close to mainline as the version I was using.
> > >
> > > Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
> > > help if this was the problem though:
> > > https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
> > >
> > > My best guess is something going wrong in the interrupt
> > > that triggered the preempt_schedule() which ended up calling
> > > task_stack_end_corrupted() in schedule_debug(), as you suggested
> > > earlier.
> >
> > FWIW I see slightly larger frames with the config:
> >
> > 073ab64 <ima_calc_field_array_hash_tfm>:
> > 8073ab64: e1a0c00d mov ip, sp
> > 8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
> > fp, ip, lr, pc}
> > 8073ab6c: e24cb004 sub fp, ip, #4
> > 8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
>
> Yes, this is the one that the compiler complained about when warning
> for stack over 600 bytes. It's not called in this call chain though.
>
> > page_alloc can also do reclaim, I had the impression that reclaim can
> > be quite heavy-weight in all respects.
>
> Yes, that is another possibility. What writable file systems or swap
> do you normally have mounted that it could be writing to, and on
> what storage device?
The root fs is ext4 on virtio-blk.
There are also several dozens of shrinkers that can be called during reclaim:
https://elixir.bootlin.com/linux/latest/C/ident/unregister_shrinker
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-17 7:47 ` Dmitry Vyukov
0 siblings, 0 replies; 39+ messages in thread
From: Dmitry Vyukov @ 2021-03-17 7:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King - ARM Linux admin, syzbot, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs,
Uwe Kleine-König
On Tue, Mar 16, 2021 at 5:28 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Mar 16, 2021 at 5:13 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > > > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > > > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> > > > >
> > > > > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > > > > the closest I have installed, and I think the Debian and Ubuntu versions
> > > > > are generally quite close in case of gcc since they are maintained by
> > > > > the same packagers.
> > > >
> > > > ... which shouldn't be a problem - that's just over 1/4 of the stack
> > > > space. Could it be the syzbot's gcc is doing something weird and
> > > > inflating the stack frames?
> > >
> > > It's possible, I think that's really unlikely given that it's just Debian's
> > > gcc, which is as close to mainline as the version I was using.
> > >
> > > Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
> > > help if this was the problem though:
> > > https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
> > >
> > > My best guess is something going wrong in the interrupt
> > > that triggered the preempt_schedule() which ended up calling
> > > task_stack_end_corrupted() in schedule_debug(), as you suggested
> > > earlier.
> >
> > FWIW I see slightly larger frames with the config:
> >
> > 073ab64 <ima_calc_field_array_hash_tfm>:
> > 8073ab64: e1a0c00d mov ip, sp
> > 8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
> > fp, ip, lr, pc}
> > 8073ab6c: e24cb004 sub fp, ip, #4
> > 8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
>
> Yes, this is the one that the compiler complained about when warning
> for stack over 600 bytes. It's not called in this call chain though.
>
> > page_alloc can also do reclaim, I had the impression that reclaim can
> > be quite heavy-weight in all respects.
>
> Yes, that is another possibility. What writable file systems or swap
> do you normally have mounted that it could be writing to, and on
> what storage device?
The root fs is ext4 on virtio-blk.
There are also several dozens of shrinkers that can be called during reclaim:
https://elixir.bootlin.com/linux/latest/C/ident/unregister_shrinker
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
2021-03-17 7:47 ` Dmitry Vyukov
@ 2021-03-17 8:31 ` Arnd Bergmann
-1 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2021-03-17 8:31 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Russell King - ARM Linux admin, syzbot, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs,
Uwe Kleine-König
On Wed, Mar 17, 2021 at 8:52 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Mar 16, 2021 at 5:28 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Mar 16, 2021 at 5:13 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
> > > > <linux@armlinux.org.uk> wrote:
> > > > > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > > > > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > > > > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> > > > > >
> > > > > > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > > > > > the closest I have installed, and I think the Debian and Ubuntu versions
> > > > > > are generally quite close in case of gcc since they are maintained by
> > > > > > the same packagers.
> > > > >
> > > > > ... which shouldn't be a problem - that's just over 1/4 of the stack
> > > > > space. Could it be the syzbot's gcc is doing something weird and
> > > > > inflating the stack frames?
> > > >
> > > > It's possible, I think that's really unlikely given that it's just Debian's
> > > > gcc, which is as close to mainline as the version I was using.
> > > >
> > > > Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
> > > > help if this was the problem though:
> > > > https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
> > > >
> > > > My best guess is something going wrong in the interrupt
> > > > that triggered the preempt_schedule() which ended up calling
> > > > task_stack_end_corrupted() in schedule_debug(), as you suggested
> > > > earlier.
> > >
> > > FWIW I see slightly larger frames with the config:
> > >
> > > 073ab64 <ima_calc_field_array_hash_tfm>:
> > > 8073ab64: e1a0c00d mov ip, sp
> > > 8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
> > > fp, ip, lr, pc}
> > > 8073ab6c: e24cb004 sub fp, ip, #4
> > > 8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
> >
> > Yes, this is the one that the compiler complained about when warning
> > for stack over 600 bytes. It's not called in this call chain though.
> >
> > > page_alloc can also do reclaim, I had the impression that reclaim can
> > > be quite heavy-weight in all respects.
> >
> > Yes, that is another possibility. What writable file systems or swap
> > do you normally have mounted that it could be writing to, and on
> > what storage device?
>
> The root fs is ext4 on virtio-blk.
>
> There are also several dozens of shrinkers that can be called during reclaim:
> https://elixir.bootlin.com/linux/latest/C/ident/unregister_shrinker
Right, unfortunately I don't see a smoking gun there either, unless you are
also using NFS or devicemapper.
Implementing VMAP_STACK as you suggested earlier is probably the
best way to figure out if there is an actual overrun of the stack.
Alternatively, adding support for GCC_PLUGIN_STACKLEAK might
also help find out if we ever get close to the limit. This is probably
less work, but it might not actually help in this case.
Arnd
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-17 8:31 ` Arnd Bergmann
0 siblings, 0 replies; 39+ messages in thread
From: Arnd Bergmann @ 2021-03-17 8:31 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Russell King - ARM Linux admin, syzbot, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs,
Uwe Kleine-König
On Wed, Mar 17, 2021 at 8:52 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Mar 16, 2021 at 5:28 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Mar 16, 2021 at 5:13 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
> > > > <linux@armlinux.org.uk> wrote:
> > > > > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > > > > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > > > > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> > > > > >
> > > > > > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > > > > > the closest I have installed, and I think the Debian and Ubuntu versions
> > > > > > are generally quite close in case of gcc since they are maintained by
> > > > > > the same packagers.
> > > > >
> > > > > ... which shouldn't be a problem - that's just over 1/4 of the stack
> > > > > space. Could it be the syzbot's gcc is doing something weird and
> > > > > inflating the stack frames?
> > > >
> > > > It's possible, I think that's really unlikely given that it's just Debian's
> > > > gcc, which is as close to mainline as the version I was using.
> > > >
> > > > Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
> > > > help if this was the problem though:
> > > > https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
> > > >
> > > > My best guess is something going wrong in the interrupt
> > > > that triggered the preempt_schedule() which ended up calling
> > > > task_stack_end_corrupted() in schedule_debug(), as you suggested
> > > > earlier.
> > >
> > > FWIW I see slightly larger frames with the config:
> > >
> > > 073ab64 <ima_calc_field_array_hash_tfm>:
> > > 8073ab64: e1a0c00d mov ip, sp
> > > 8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
> > > fp, ip, lr, pc}
> > > 8073ab6c: e24cb004 sub fp, ip, #4
> > > 8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
> >
> > Yes, this is the one that the compiler complained about when warning
> > for stack over 600 bytes. It's not called in this call chain though.
> >
> > > page_alloc can also do reclaim, I had the impression that reclaim can
> > > be quite heavy-weight in all respects.
> >
> > Yes, that is another possibility. What writable file systems or swap
> > do you normally have mounted that it could be writing to, and on
> > what storage device?
>
> The root fs is ext4 on virtio-blk.
>
> There are also several dozens of shrinkers that can be called during reclaim:
> https://elixir.bootlin.com/linux/latest/C/ident/unregister_shrinker
Right, unfortunately I don't see a smoking gun there either, unless you are
also using NFS or devicemapper.
Implementing VMAP_STACK as you suggested earlier is probably the
best way to figure out if there is an actual overrun of the stack.
Alternatively, adding support for GCC_PLUGIN_STACKLEAK might
also help find out if we ever get close to the limit. This is probably
less work, but it might not actually help in this case.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
2021-03-17 8:31 ` Arnd Bergmann
@ 2021-03-17 8:50 ` Dmitry Vyukov
-1 siblings, 0 replies; 39+ messages in thread
From: Dmitry Vyukov @ 2021-03-17 8:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King - ARM Linux admin, syzbot, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs,
Uwe Kleine-König
On Wed, Mar 17, 2021 at 9:32 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > <linux@armlinux.org.uk> wrote:
> > > > > > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > > > > > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > > > > > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> > > > > > >
> > > > > > > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > > > > > > the closest I have installed, and I think the Debian and Ubuntu versions
> > > > > > > are generally quite close in case of gcc since they are maintained by
> > > > > > > the same packagers.
> > > > > >
> > > > > > ... which shouldn't be a problem - that's just over 1/4 of the stack
> > > > > > space. Could it be the syzbot's gcc is doing something weird and
> > > > > > inflating the stack frames?
> > > > >
> > > > > It's possible, I think that's really unlikely given that it's just Debian's
> > > > > gcc, which is as close to mainline as the version I was using.
> > > > >
> > > > > Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
> > > > > help if this was the problem though:
> > > > > https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
> > > > >
> > > > > My best guess is something going wrong in the interrupt
> > > > > that triggered the preempt_schedule() which ended up calling
> > > > > task_stack_end_corrupted() in schedule_debug(), as you suggested
> > > > > earlier.
> > > >
> > > > FWIW I see slightly larger frames with the config:
> > > >
> > > > 073ab64 <ima_calc_field_array_hash_tfm>:
> > > > 8073ab64: e1a0c00d mov ip, sp
> > > > 8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
> > > > fp, ip, lr, pc}
> > > > 8073ab6c: e24cb004 sub fp, ip, #4
> > > > 8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
> > >
> > > Yes, this is the one that the compiler complained about when warning
> > > for stack over 600 bytes. It's not called in this call chain though.
> > >
> > > > page_alloc can also do reclaim, I had the impression that reclaim can
> > > > be quite heavy-weight in all respects.
> > >
> > > Yes, that is another possibility. What writable file systems or swap
> > > do you normally have mounted that it could be writing to, and on
> > > what storage device?
> >
> > The root fs is ext4 on virtio-blk.
> >
> > There are also several dozens of shrinkers that can be called during reclaim:
> > https://elixir.bootlin.com/linux/latest/C/ident/unregister_shrinker
>
> Right, unfortunately I don't see a smoking gun there either, unless you are
> also using NFS or devicemapper.
>
> Implementing VMAP_STACK as you suggested earlier is probably the
> best way to figure out if there is an actual overrun of the stack.
> Alternatively, adding support for GCC_PLUGIN_STACKLEAK might
> also help find out if we ever get close to the limit. This is probably
> less work, but it might not actually help in this case.
VMAP_STACK is quite intrusive as far as I understand. For KASAN I
considered a simpler option: have a debug config that allocates an
extra page after the stack and mprotect's it. It wastes a physical
page per task (fine for a debug config), but I would assume should be
radically simpler to implement. In the end somebody implemented proper
VMAP_STACK support for KASAN, but I still think it may be a reasonable
compromise between time investment and value.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-17 8:50 ` Dmitry Vyukov
0 siblings, 0 replies; 39+ messages in thread
From: Dmitry Vyukov @ 2021-03-17 8:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King - ARM Linux admin, syzbot, Linus Walleij, Linux ARM,
Andrew Morton, LKML, Linux-MM, syzkaller-bugs,
Uwe Kleine-König
On Wed, Mar 17, 2021 at 9:32 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > <linux@armlinux.org.uk> wrote:
> > > > > > On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> > > > > > > On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > > > > > > The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> > > > > > >
> > > > > > > Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
> > > > > > > the closest I have installed, and I think the Debian and Ubuntu versions
> > > > > > > are generally quite close in case of gcc since they are maintained by
> > > > > > > the same packagers.
> > > > > >
> > > > > > ... which shouldn't be a problem - that's just over 1/4 of the stack
> > > > > > space. Could it be the syzbot's gcc is doing something weird and
> > > > > > inflating the stack frames?
> > > > >
> > > > > It's possible, I think that's really unlikely given that it's just Debian's
> > > > > gcc, which is as close to mainline as the version I was using.
> > > > >
> > > > > Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
> > > > > help if this was the problem though:
> > > > > https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
> > > > >
> > > > > My best guess is something going wrong in the interrupt
> > > > > that triggered the preempt_schedule() which ended up calling
> > > > > task_stack_end_corrupted() in schedule_debug(), as you suggested
> > > > > earlier.
> > > >
> > > > FWIW I see slightly larger frames with the config:
> > > >
> > > > 073ab64 <ima_calc_field_array_hash_tfm>:
> > > > 8073ab64: e1a0c00d mov ip, sp
> > > > 8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
> > > > fp, ip, lr, pc}
> > > > 8073ab6c: e24cb004 sub fp, ip, #4
> > > > 8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
> > >
> > > Yes, this is the one that the compiler complained about when warning
> > > for stack over 600 bytes. It's not called in this call chain though.
> > >
> > > > page_alloc can also do reclaim, I had the impression that reclaim can
> > > > be quite heavy-weight in all respects.
> > >
> > > Yes, that is another possibility. What writable file systems or swap
> > > do you normally have mounted that it could be writing to, and on
> > > what storage device?
> >
> > The root fs is ext4 on virtio-blk.
> >
> > There are also several dozens of shrinkers that can be called during reclaim:
> > https://elixir.bootlin.com/linux/latest/C/ident/unregister_shrinker
>
> Right, unfortunately I don't see a smoking gun there either, unless you are
> also using NFS or devicemapper.
>
> Implementing VMAP_STACK as you suggested earlier is probably the
> best way to figure out if there is an actual overrun of the stack.
> Alternatively, adding support for GCC_PLUGIN_STACKLEAK might
> also help find out if we ever get close to the limit. This is probably
> less work, but it might not actually help in this case.
VMAP_STACK is quite intrusive as far as I understand. For KASAN I
considered a simpler option: have a debug config that allocates an
extra page after the stack and mprotect's it. It wastes a physical
page per task (fine for a debug config), but I would assume should be
radically simpler to implement. In the end somebody implemented proper
VMAP_STACK support for KASAN, but I still think it may be a reasonable
compromise between time investment and value.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
2021-03-16 10:02 ` Arnd Bergmann
(?)
@ 2021-03-16 10:37 ` Ard Biesheuvel
-1 siblings, 0 replies; 39+ messages in thread
From: Ard Biesheuvel @ 2021-03-16 10:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Dmitry Vyukov, syzbot, Russell King - ARM Linux, Linus Walleij,
Linux ARM, Andrew Morton, LKML, Linux-MM, syzkaller-bugs
On Tue, 16 Mar 2021 at 11:04, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Mar 16, 2021 at 8:59 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > <syzbot+0b06ef9b44d00d600183@syzkaller.appspotmail.com> 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@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:
>
> > > [<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.
>
FYI, as an aside, the SHASH_DESC_ON_STACK() issue was fixed in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=660d2062190db131d2feaf19914e90f868fe285c
(note that the size of SHASH_DESC_ON_STACK() accounts for two struct
shash_desc instances)
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 10:37 ` Ard Biesheuvel
0 siblings, 0 replies; 39+ messages in thread
From: Ard Biesheuvel @ 2021-03-16 10:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Dmitry Vyukov, syzbot, Russell King - ARM Linux, Linus Walleij,
Linux ARM, Andrew Morton, LKML, Linux-MM, syzkaller-bugs
On Tue, 16 Mar 2021 at 11:04, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Mar 16, 2021 at 8:59 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > <syzbot+0b06ef9b44d00d600183@syzkaller.appspotmail.com> 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@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:
>
> > > [<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.
>
FYI, as an aside, the SHASH_DESC_ON_STACK() issue was fixed in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=660d2062190db131d2feaf19914e90f868fe285c
(note that the size of SHASH_DESC_ON_STACK() accounts for two struct
shash_desc instances)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [syzbot] kernel panic: corrupted stack end in openat
@ 2021-03-16 10:37 ` Ard Biesheuvel
0 siblings, 0 replies; 39+ messages in thread
From: Ard Biesheuvel @ 2021-03-16 10:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Dmitry Vyukov, syzbot, Russell King - ARM Linux, Linus Walleij,
Linux ARM, Andrew Morton, LKML, Linux-MM, syzkaller-bugs
On Tue, 16 Mar 2021 at 11:04, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Mar 16, 2021 at 8:59 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> > <syzbot+0b06ef9b44d00d600183@syzkaller.appspotmail.com> 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@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:
>
> > > [<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.
>
FYI, as an aside, the SHASH_DESC_ON_STACK() issue was fixed in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=660d2062190db131d2feaf19914e90f868fe285c
(note that the size of SHASH_DESC_ON_STACK() accounts for two struct
shash_desc instances)
^ permalink raw reply [flat|nested] 39+ messages in thread