[syzbot] kernel panic: corrupted stack end in rtnl_newlink

[Dmitry Vyukov]

On Mon, 14 Mar 2022 at 11:44, David Laight <David.Laight at aculab.com> wrote:
>
> From: Dmitry Vyukov
> > Sent: 14 March 2022 09:09
> >
> > On Mon, 14 Mar 2022 at 09:22, Dmitry Vyukov <dvyukov at google.com> wrote:
> > >
> > > On Mon, 14 Mar 2022 at 09:17, syzbot
> > > <syzbot+0600986d88e2d4d7ebb8 at syzkaller.appspotmail.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit:    0966d385830d riscv: Fix auipc+jalr relocation range checks
> > > > git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=17fe80c5700000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=6295d67591064921
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=0600986d88e2d4d7ebb8
> > > > compiler:       riscv64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for
> > Debian) 2.35.2
> > > > userspace arch: riscv64
> > >
> > > +linux-riscv
> > >
> > > Riscv needs to increase stack size under KASAN.
> > > I will send a patch.
>
> With vmalloc()ed stacks is it possible to allocate an extra page
> of KVA that isn't backed by memory as a 'guard page' so that
> stack overflow faults immediately?
>
> Probably worth enforcing for KASAN builds where the compilers
> have a nasty habit of using lot more stack space that might
> be expected.

Yes, this would be useful. At least for x86 we use and rely on this.