Messages in this thread | | | From | David Laight <> | Subject | RE: [syzbot] kernel panic: corrupted stack end in rtnl_newlink | Date | Mon, 14 Mar 2022 10:43:58 +0000 |
| |
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)
| |