Re: [syzbot] [mm?] INFO: rcu detected stall in kcov_ioctl (3)

[Andrew Morton]

On Wed, 08 Apr 2026 16:31:27 -0700 syzbot <syzbot+8a5907...@syzkaller.appspotmail.com> wrote:

> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 7ca6d1cfec80 Merge tag 'powerpc-7.0-4' of git://git.kernel..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=133b4dda580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=64e78d99d9bf8b4c
> dashboard link: https://syzkaller.appspot.com/bug?extid=8a59070fc852219166ab
> compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
>
> Unfortunately, I don't have any reproducer for this issue yet.

Thanks. I added a few kcov names from MAINTAINERS.

> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/ace9641c44ac/disk-7ca6d1cf.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/6e66f8b9476e/vmlinux-7ca6d1cf.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/d679c066df56/bzImage-7ca6d1cf.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+8a5907...@syzkaller.appspotmail.com
>
> bridge0: received packet on bridge_slave_0 with own address as source address (addr:aa:aa:aa:aa:aa:0c, vlan:0)
> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P23414/1:b..l P27649/1:b..l P27664/1:b..l
> rcu: (detected by 0, t=10502 jiffies, g=200461, q=440 ncpus=2)
> task:syz-executor state:R running task stack:25416 pid:27664 tgid:27664 ppid:5809 task_flags:0x400000 flags:0x00080000
> Call Trace:
> <TASK>
> context_switch kernel/sched/core.c:5298 [inline]
> __schedule+0xfee/0x6120 kernel/sched/core.c:6911
> preempt_schedule_irq+0x50/0x90 kernel/sched/core.c:7238
> irqentry_exit+0x17b/0x670 kernel/entry/common.c:239
> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
> RIP: 0010:__orc_find+0x49/0xf0 arch/x86/kernel/unwind_orc.c:101
> Code: 00 49 89 fe 48 89 f0 49 39 fc 72 7b 48 b9 00 00 00 00 00 fc ff df 49 89 ff 48 89 fd eb 0c 48 8d 6b 04 49 89 df 49 39 ec 72 4e <4c> 89 e2 48 29 ea 48 89 d6 48 c1 ea 3f 48 c1 fe 02 48 01 f2 48 d1
> RSP: 0018:ffffc9000d12f138 EFLAGS: 00000212
> RAX: ffffffff91777f46 RBX: ffffffff90f165c4 RCX: dffffc0000000000
> RDX: ffffffff81aecd9f RSI: 0000000000000000 RDI: ffffffff90f165b8
> RBP: ffffffff90f165b8 R08: ffffffff91777f70 R09: 0000000000000007
> R10: 0000000000000200 R11: 000000000000aecd R12: ffffffff90f165c0
> R13: ffffffff81aecd22 R14: ffffffff90f165b8 R15: ffffffff90f165b8
> orc_find arch/x86/kernel/unwind_orc.c:238 [inline]
> unwind_next_frame+0x2ec/0x1ea0 arch/x86/kernel/unwind_orc.c:510
> __unwind_start+0x3d1/0x7f0 arch/x86/kernel/unwind_orc.c:773
> unwind_start arch/x86/include/asm/unwind.h:64 [inline]
> arch_stack_walk+0x73/0xf0 arch/x86/kernel/stacktrace.c:24
> stack_trace_save+0x8e/0xc0 kernel/stacktrace.c:122
> save_stack+0x162/0x1e0 mm/page_owner.c:165
> __set_page_owner+0x8c/0x540 mm/page_owner.c:341
> set_page_owner include/linux/page_owner.h:32 [inline]
> post_alloc_hook+0x153/0x170 mm/page_alloc.c:1889
> prep_new_page mm/page_alloc.c:1897 [inline]
> get_page_from_freelist+0x111d/0x3140 mm/page_alloc.c:3962
> __alloc_frozen_pages_noprof+0x27c/0x2ba0 mm/page_alloc.c:5250
> __alloc_pages_noprof mm/page_alloc.c:5284 [inline]
> alloc_pages_bulk_noprof+0x782/0x1490 mm/page_alloc.c:5204
> ___alloc_pages_bulk mm/kasan/shadow.c:345 [inline]
> __kasan_populate_vmalloc_do mm/kasan/shadow.c:370 [inline]
> __kasan_populate_vmalloc+0xf0/0x210 mm/kasan/shadow.c:424
> kasan_populate_vmalloc include/linux/kasan.h:580 [inline]
> alloc_vmap_area+0x95d/0x2bd0 mm/vmalloc.c:2129
> __get_vm_area_node+0x1ca/0x330 mm/vmalloc.c:3232
> __vmalloc_node_range_noprof+0x213/0x1530 mm/vmalloc.c:4024
> vmalloc_user_noprof+0x9e/0xe0 mm/vmalloc.c:4218
> kcov_ioctl+0x4c/0x720 kernel/kcov.c:726
> vfs_ioctl fs/ioctl.c:51 [inline]

I assume the fuzzer is asking kcov_ioctl() to allocate ludicrous
amounts of memory.

case KCOV_INIT_TRACE:
/*
* Enable kcov in trace mode and setup buffer size.
* Must happen before anything else.
*
* First check the size argument - it must be at least 2
* to hold the current position and one PC.
*/
size = arg;
if (size < 2 || size > INT_MAX / sizeof(unsigned long))
return -EINVAL;
area = vmalloc_user(size * sizeof(unsigned long));

KCOV_REMOTE_MAX_HANDLES looks to be OK.

/sys/debug/kcov is mode 0600 so this is no emergency.

Maintainers, perhaps we can do something more ... restrained here?