[syzbot] kernel panic: corrupted stack end in rtnl_newlink

25 views
Skip to first unread message

syzbot

unread,
Mar 14, 2022, 4:17:28ā€ÆAM3/14/22
to da...@davemloft.net, dsa...@kernel.org, ku...@kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, syzkall...@googlegroups.com, yosh...@linux-ipv6.org
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

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

Kernel panic - not syncing: corrupted stack end detected inside scheduler
CPU: 0 PID: 2049 Comm: syz-executor.0 Not tainted 5.17.0-rc1-syzkaller-00002-g0966d385830d #0
Hardware name: riscv-virtio,qemu (DT)
Call Trace:
[<ffffffff8000a228>] dump_backtrace+0x2e/0x3c arch/riscv/kernel/stacktrace.c:113
[<ffffffff831668cc>] show_stack+0x34/0x40 arch/riscv/kernel/stacktrace.c:119
[<ffffffff831756ba>] __dump_stack lib/dump_stack.c:88 [inline]
[<ffffffff831756ba>] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:106
[<ffffffff83175742>] dump_stack+0x1c/0x24 lib/dump_stack.c:113
[<ffffffff83166fa8>] panic+0x24a/0x634 kernel/panic.c:233
[<ffffffff831a688a>] schedule_debug kernel/sched/core.c:5541 [inline]
[<ffffffff831a688a>] schedule+0x0/0x14c kernel/sched/core.c:6187
[<ffffffff831a6b00>] preempt_schedule_common+0x4e/0xde kernel/sched/core.c:6462
[<ffffffff831a6bc4>] preempt_schedule+0x34/0x36 kernel/sched/core.c:6487
[<ffffffff831afd78>] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline]
[<ffffffff831afd78>] _raw_spin_unlock_irqrestore+0x8c/0x98 kernel/locking/spinlock.c:194
[<ffffffff80b09fdc>] __debug_check_no_obj_freed lib/debugobjects.c:1002 [inline]
[<ffffffff80b09fdc>] debug_check_no_obj_freed+0x14c/0x24a lib/debugobjects.c:1023
[<ffffffff80410994>] free_pages_prepare mm/page_alloc.c:1358 [inline]
[<ffffffff80410994>] free_pcp_prepare+0x24e/0x45e mm/page_alloc.c:1404
[<ffffffff804142fe>] free_unref_page_prepare mm/page_alloc.c:3325 [inline]
[<ffffffff804142fe>] free_unref_page+0x6a/0x31e mm/page_alloc.c:3404
[<ffffffff8041471e>] free_the_page mm/page_alloc.c:706 [inline]
[<ffffffff8041471e>] __free_pages+0xe2/0x112 mm/page_alloc.c:5474
[<ffffffff8046d728>] __free_slab+0x122/0x27c mm/slub.c:2028
[<ffffffff8046d8ce>] free_slab mm/slub.c:2043 [inline]
[<ffffffff8046d8ce>] discard_slab+0x4c/0x7a mm/slub.c:2049
[<ffffffff8046deec>] __unfreeze_partials+0x16a/0x18e mm/slub.c:2536
[<ffffffff8046e006>] put_cpu_partial+0xf6/0x162 mm/slub.c:2612
[<ffffffff8046d0ec>] __slab_free+0x166/0x29c mm/slub.c:3378
[<ffffffff8047258c>] do_slab_free mm/slub.c:3497 [inline]
[<ffffffff8047258c>] ___cache_free+0x17c/0x354 mm/slub.c:3516
[<ffffffff8047692e>] qlink_free mm/kasan/quarantine.c:157 [inline]
[<ffffffff8047692e>] qlist_free_all+0x7c/0x132 mm/kasan/quarantine.c:176
[<ffffffff80476ed4>] kasan_quarantine_reduce+0x14c/0x1c8 mm/kasan/quarantine.c:283
[<ffffffff804742b2>] __kasan_slab_alloc+0x5c/0x98 mm/kasan/common.c:446
[<ffffffff8046fa8a>] kasan_slab_alloc include/linux/kasan.h:260 [inline]
[<ffffffff8046fa8a>] slab_post_alloc_hook mm/slab.h:732 [inline]
[<ffffffff8046fa8a>] slab_alloc_node mm/slub.c:3230 [inline]
[<ffffffff8046fa8a>] slab_alloc mm/slub.c:3238 [inline]
[<ffffffff8046fa8a>] __kmalloc+0x156/0x318 mm/slub.c:4420
[<ffffffff82bde908>] kmalloc include/linux/slab.h:586 [inline]
[<ffffffff82bde908>] kzalloc include/linux/slab.h:715 [inline]
[<ffffffff82bde908>] fib_create_info+0xade/0x2d8e net/ipv4/fib_semantics.c:1464
[<ffffffff82becedc>] fib_table_insert+0x1a0/0xebe net/ipv4/fib_trie.c:1224
[<ffffffff82bd1222>] fib_magic+0x3f4/0x438 net/ipv4/fib_frontend.c:1087
[<ffffffff82bd6178>] fib_add_ifaddr+0xd2/0x2e2 net/ipv4/fib_frontend.c:1109
[<ffffffff82bd66ea>] fib_netdev_event+0x362/0x4b0 net/ipv4/fib_frontend.c:1466
[<ffffffff800aac84>] notifier_call_chain+0xb8/0x188 kernel/notifier.c:84
[<ffffffff800aad7e>] raw_notifier_call_chain+0x2a/0x38 kernel/notifier.c:392
[<ffffffff8271d086>] call_netdevice_notifiers_info+0x9e/0x10c net/core/dev.c:1919
[<ffffffff827422c8>] call_netdevice_notifiers_extack net/core/dev.c:1931 [inline]
[<ffffffff827422c8>] call_netdevice_notifiers net/core/dev.c:1945 [inline]
[<ffffffff827422c8>] __dev_notify_flags+0x108/0x1fa net/core/dev.c:8179
[<ffffffff827436f6>] dev_change_flags+0x9c/0xba net/core/dev.c:8215
[<ffffffff82767e16>] do_setlink+0x5d6/0x21c4 net/core/rtnetlink.c:2729
[<ffffffff8276a6a2>] __rtnl_newlink+0x99e/0xfa0 net/core/rtnetlink.c:3412
[<ffffffff8276ad04>] rtnl_newlink+0x60/0x8c net/core/rtnetlink.c:3527
[<ffffffff8276b46c>] rtnetlink_rcv_msg+0x338/0x9a0 net/core/rtnetlink.c:5592
[<ffffffff8296ded2>] netlink_rcv_skb+0xf8/0x2be net/netlink/af_netlink.c:2494
[<ffffffff827624f4>] rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:5610
[<ffffffff8296cbcc>] netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
[<ffffffff8296cbcc>] netlink_unicast+0x40e/0x5fe net/netlink/af_netlink.c:1343
[<ffffffff8296d29c>] netlink_sendmsg+0x4e0/0x994 net/netlink/af_netlink.c:1919
[<ffffffff826d264e>] sock_sendmsg_nosec net/socket.c:705 [inline]
[<ffffffff826d264e>] sock_sendmsg+0xa0/0xc4 net/socket.c:725
[<ffffffff826d7026>] __sys_sendto+0x1f2/0x2e0 net/socket.c:2040
[<ffffffff826d7152>] __do_sys_sendto net/socket.c:2052 [inline]
[<ffffffff826d7152>] sys_sendto+0x3e/0x52 net/socket.c:2048
[<ffffffff80005716>] ret_from_syscall+0x0/0x2
SMP: stopping secondary CPUs
Rebooting in 86400 seconds..


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Dmitry Vyukov

unread,
Mar 14, 2022, 4:22:34ā€ÆAM3/14/22
to syzbot, da...@davemloft.net, dsa...@kernel.org, ku...@kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, syzkall...@googlegroups.com, yosh...@linux-ipv6.org, linux-riscv
On Mon, 14 Mar 2022 at 09:17, syzbot
<syzbot+060098...@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.

Dmitry Vyukov

unread,
Mar 14, 2022, 5:08:48ā€ÆAM3/14/22
to syzbot, da...@davemloft.net, dsa...@kernel.org, ku...@kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, syzkall...@googlegroups.com, yosh...@linux-ipv6.org, linux-riscv
On Mon, 14 Mar 2022 at 09:22, Dmitry Vyukov <dvy...@google.com> wrote:
>
> On Mon, 14 Mar 2022 at 09:17, syzbot
> <syzbot+060098...@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.

FTR proposed fix:
https://lore.kernel.org/linux-riscv/20220314090652.1...@google.com/T/#u

David Laight

unread,
Mar 14, 2022, 6:44:01ā€ÆAM3/14/22
to Dmitry Vyukov, syzbot, da...@davemloft.net, dsa...@kernel.org, ku...@kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, syzkall...@googlegroups.com, yosh...@linux-ipv6.org, linux-riscv
From: Dmitry Vyukov
> Sent: 14 March 2022 09:09
>
> On Mon, 14 Mar 2022 at 09:22, Dmitry Vyukov <dvy...@google.com> wrote:
> >
> > On Mon, 14 Mar 2022 at 09:17, syzbot
> > <syzbot+060098...@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)

Dmitry Vyukov

unread,
Mar 14, 2022, 8:05:20ā€ÆAM3/14/22
to David Laight, syzbot, da...@davemloft.net, dsa...@kernel.org, ku...@kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, syzkall...@googlegroups.com, yosh...@linux-ipv6.org, linux-riscv
Yes, this would be useful. At least for x86 we use and rely on this.
Reply all
Reply to author
Forward
0 new messages