lkml.org 
[lkml]   [2022]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [syzbot] kernel panic: corrupted stack end in rtnl_newlink
Date
From: Dmitry Vyukov
> Sent: 14 March 2022 09:09
>
> On Mon, 14 Mar 2022 at 09:22, Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > On Mon, 14 Mar 2022 at 09:17, syzbot
> > <syzbot+0600986d88e2d4d7ebb8@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.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
\
 
 \ /
  Last update: 2022-03-14 11:45    [W:0.091 / U:0.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site