* [syzbot] [bpf?] WARNING in maybe_exit_scc @ 2025-09-15 18:28 syzbot 2025-09-15 22:34 ` Eduard Zingerman 2025-09-16 10:20 ` syzbot 0 siblings, 2 replies; 6+ messages in thread From: syzbot @ 2025-09-15 18:28 UTC (permalink / raw) To: andrii, ast, bpf, daniel, eddyz87, haoluo, john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau, sdf, song, syzkaller-bugs, yonghong.song Hello, syzbot found the following issue on: HEAD commit: f83ec76bf285 Linux 6.17-rc6 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=137d0e42580000 kernel config: https://syzkaller.appspot.com/x/.config?x=8f01d8629880e620 dashboard link: https://syzkaller.appspot.com/bug?extid=3afc814e8df1af64b653 compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=104a947c580000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14467b62580000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/be9b26c66bc1/disk-f83ec76b.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/53dc5627e608/vmlinux-f83ec76b.xz kernel image: https://storage.googleapis.com/syzbot-assets/398506a67fd8/bzImage-f83ec76b.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+3afc814e8df1af64b653@syzkaller.appspotmail.com ------------[ cut here ]------------ verifier bug: scc exit: no visit info for call chain (1)(1) WARNING: CPU: 1 PID: 6013 at kernel/bpf/verifier.c:1949 maybe_exit_scc+0x768/0x8d0 kernel/bpf/verifier.c:1949 Modules linked in: CPU: 1 UID: 0 PID: 6013 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:maybe_exit_scc+0x768/0x8d0 kernel/bpf/verifier.c:1949 Code: ff ff e8 cb 8e e7 ff c6 05 0a b5 bf 0e 01 90 48 89 ee 48 89 df e8 f8 41 fb ff 48 c7 c7 a0 9b b5 8b 48 89 c6 e8 59 33 a6 ff 90 <0f> 0b 90 90 e9 4e ff ff ff e8 0a ee 4d 00 e9 7f f9 ff ff 4c 8b 4c RSP: 0018:ffffc900041bf500 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888079840000 RCX: ffffffff817a4388 RDX: ffff88807d3f8000 RSI: ffffffff817a4395 RDI: 0000000000000001 RBP: ffff888079846328 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 1ffff92000837ea7 R13: 0000000000000000 R14: ffff88805cf87400 R15: dffffc0000000000 FS: 000055557c9b5500(0000) GS:ffff8881247b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055557c9b5808 CR3: 0000000073b4d000 CR4: 00000000003526f0 Call Trace: <TASK> update_branch_counts kernel/bpf/verifier.c:2040 [inline] do_check kernel/bpf/verifier.c:20135 [inline] do_check_common+0x20cc/0xb410 kernel/bpf/verifier.c:23264 do_check_main kernel/bpf/verifier.c:23347 [inline] bpf_check+0x869f/0xc670 kernel/bpf/verifier.c:24707 bpf_prog_load+0xe41/0x2490 kernel/bpf/syscall.c:2979 __sys_bpf+0x4a3f/0x4de0 kernel/bpf/syscall.c:6029 __do_sys_bpf kernel/bpf/syscall.c:6139 [inline] __se_sys_bpf kernel/bpf/syscall.c:6137 [inline] __x64_sys_bpf+0x78/0xc0 kernel/bpf/syscall.c:6137 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fd1d078eba9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffee0400aa8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX: 00007fd1d09d5fa0 RCX: 00007fd1d078eba9 RDX: 0000000000000048 RSI: 00002000000017c0 RDI: 0000000000000005 RBP: 00007fd1d0811e19 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fd1d09d5fa0 R14: 00007fd1d09d5fa0 R15: 0000000000000003 </TASK> --- 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 syzkaller@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. If the report is already addressed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to overwrite report's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the report is a duplicate of another one, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [bpf?] WARNING in maybe_exit_scc 2025-09-15 18:28 [syzbot] [bpf?] WARNING in maybe_exit_scc syzbot @ 2025-09-15 22:34 ` Eduard Zingerman 2025-09-15 23:40 ` Eduard Zingerman 2025-09-16 10:20 ` syzbot 1 sibling, 1 reply; 6+ messages in thread From: Eduard Zingerman @ 2025-09-15 22:34 UTC (permalink / raw) To: syzbot, andrii, ast, bpf, daniel, haoluo, john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau, sdf, song, syzkaller-bugs, yonghong.song On Mon, 2025-09-15 at 11:28 -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: f83ec76bf285 Linux 6.17-rc6 > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=137d0e42580000 > kernel config: https://syzkaller.appspot.com/x/.config?x=8f01d8629880e620 > dashboard link: https://syzkaller.appspot.com/bug?extid=3afc814e8df1af64b653 > compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=104a947c580000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14467b62580000 > > Downloadable assets: > disk image: https://storage.googleapis.com/syzbot-assets/be9b26c66bc1/disk-f83ec76b.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/53dc5627e608/vmlinux-f83ec76b.xz > kernel image: https://storage.googleapis.com/syzbot-assets/398506a67fd8/bzImage-f83ec76b.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+3afc814e8df1af64b653@syzkaller.appspotmail.com > > ------------[ cut here ]------------ > verifier bug: scc exit: no visit info for call chain (1)(1) > WARNING: CPU: 1 PID: 6013 at kernel/bpf/verifier.c:1949 maybe_exit_scc+0x768/0x8d0 kernel/bpf/verifier.c:1949 Both this and [1] are reported for very similar programs: <this> <[1]> -------------------------------------------------------------------------------------------- (b7) r0 = -1023213567 (b7) r0 = -1023213567 (bf) r3 = r10 (bf) r3 = r10 (07) r3 += -512 (07) r3 += -504 (72) *(u8 *)(r10 -16) = -8 (72) *(u8 *)(r10 -16) = -8 (71) r4 = *(u8 *)(r10 -16) (71) r4 = *(u8 *)(r10 -16) (65) if r4 s> 0xff000000 goto pc+2 (65) if r4 s> 0xff000000 goto pc+2 (2d) if r0 > r4 goto pc+5 (2d) if r0 > r4 goto pc+5 (20) r0 = *(u32 *)skb[60673] (20) r0 = *(u32 *)skb[60673] (7b) *(u64 *)(r3 +0) = r0 (7b) *(u64 *)(r3 +0) = r0 (1d) if r4 == r4 goto pc+0 (1d) if r4 == r4 goto pc+0 (7a) *(u64 *)(r10 -512) = -256 (7a) *(u64 *)(r10 -512) = -256 (db) lock *(u64 *)(r3 +0) |= r0 (db) r0 = atomic64_fetch_and((u64 *)(r3 +0), r0) (b5) if r0 <= 0x0 goto pc-2 (b5) if r0 <= 0x0 goto pc-2 (95) exit (95) exit So, I assume it's the same issue. Looking into it. [1] https://lore.kernel.org/bpf/68c85b0d.050a0220.2ff435.03a5.GAE@google.com/T/#u > Modules linked in: > CPU: 1 UID: 0 PID: 6013 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 > RIP: 0010:maybe_exit_scc+0x768/0x8d0 kernel/bpf/verifier.c:1949 > Code: ff ff e8 cb 8e e7 ff c6 05 0a b5 bf 0e 01 90 48 89 ee 48 89 df e8 f8 41 fb ff 48 c7 c7 a0 9b b5 8b 48 89 c6 e8 59 33 a6 ff 90 <0f> 0b 90 90 e9 4e ff ff ff e8 0a ee 4d 00 e9 7f f9 ff ff 4c 8b 4c > RSP: 0018:ffffc900041bf500 EFLAGS: 00010282 > RAX: 0000000000000000 RBX: ffff888079840000 RCX: ffffffff817a4388 > RDX: ffff88807d3f8000 RSI: ffffffff817a4395 RDI: 0000000000000001 > RBP: ffff888079846328 R08: 0000000000000001 R09: 0000000000000000 > R10: 0000000000000001 R11: 0000000000000000 R12: 1ffff92000837ea7 > R13: 0000000000000000 R14: ffff88805cf87400 R15: dffffc0000000000 > FS: 000055557c9b5500(0000) GS:ffff8881247b2000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 000055557c9b5808 CR3: 0000000073b4d000 CR4: 00000000003526f0 > Call Trace: > <TASK> > update_branch_counts kernel/bpf/verifier.c:2040 [inline] > do_check kernel/bpf/verifier.c:20135 [inline] > do_check_common+0x20cc/0xb410 kernel/bpf/verifier.c:23264 > do_check_main kernel/bpf/verifier.c:23347 [inline] > bpf_check+0x869f/0xc670 kernel/bpf/verifier.c:24707 > bpf_prog_load+0xe41/0x2490 kernel/bpf/syscall.c:2979 > __sys_bpf+0x4a3f/0x4de0 kernel/bpf/syscall.c:6029 > __do_sys_bpf kernel/bpf/syscall.c:6139 [inline] > __se_sys_bpf kernel/bpf/syscall.c:6137 [inline] > __x64_sys_bpf+0x78/0xc0 kernel/bpf/syscall.c:6137 > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > do_syscall_64+0xcd/0x4e0 arch/x86/entry/syscall_64.c:94 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > RIP: 0033:0x7fd1d078eba9 > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007ffee0400aa8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 > RAX: ffffffffffffffda RBX: 00007fd1d09d5fa0 RCX: 00007fd1d078eba9 > RDX: 0000000000000048 RSI: 00002000000017c0 RDI: 0000000000000005 > RBP: 00007fd1d0811e19 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 > R13: 00007fd1d09d5fa0 R14: 00007fd1d09d5fa0 R15: 0000000000000003 > </TASK> > > > --- > 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 syzkaller@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > If the report is already addressed, let syzbot know by replying with: > #syz fix: exact-commit-title > > If you want syzbot to run the reproducer, reply with: > #syz test: git://repo/address.git branch-or-commit-hash > If you attach or paste a git patch, syzbot will apply it before testing. > > If you want to overwrite report's subsystems, reply with: > #syz set subsystems: new-subsystem > (See the list of subsystem names on the web dashboard) > > If the report is a duplicate of another one, reply with: > #syz dup: exact-subject-of-another-report > > If you want to undo deduplication, reply with: > #syz undup ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [bpf?] WARNING in maybe_exit_scc 2025-09-15 22:34 ` Eduard Zingerman @ 2025-09-15 23:40 ` Eduard Zingerman 2025-09-16 9:14 ` Eduard Zingerman 0 siblings, 1 reply; 6+ messages in thread From: Eduard Zingerman @ 2025-09-15 23:40 UTC (permalink / raw) To: syzbot, andrii, ast, bpf, daniel, haoluo, john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau, sdf, song, syzkaller-bugs, yonghong.song On Mon, 2025-09-15 at 15:34 -0700, Eduard Zingerman wrote: [...] > > verifier bug: scc exit: no visit info for call chain (1)(1) > > WARNING: CPU: 1 PID: 6013 at kernel/bpf/verifier.c:1949 maybe_exit_scc+0x768/0x8d0 kernel/bpf/verifier.c:1949 > > Both this and [1] are reported for very similar programs: > > <this> <[1]> > -------------------------------------------------------------------------------------------- > (b7) r0 = -1023213567 (b7) r0 = -1023213567 > (bf) r3 = r10 (bf) r3 = r10 > (07) r3 += -512 (07) r3 += -504 > (72) *(u8 *)(r10 -16) = -8 (72) *(u8 *)(r10 -16) = -8 > (71) r4 = *(u8 *)(r10 -16) (71) r4 = *(u8 *)(r10 -16) > (65) if r4 s> 0xff000000 goto pc+2 (65) if r4 s> 0xff000000 goto pc+2 > (2d) if r0 > r4 goto pc+5 (2d) if r0 > r4 goto pc+5 > (20) r0 = *(u32 *)skb[60673] (20) r0 = *(u32 *)skb[60673] > (7b) *(u64 *)(r3 +0) = r0 (7b) *(u64 *)(r3 +0) = r0 > (1d) if r4 == r4 goto pc+0 (1d) if r4 == r4 goto pc+0 > (7a) *(u64 *)(r10 -512) = -256 (7a) *(u64 *)(r10 -512) = -256 > (db) lock *(u64 *)(r3 +0) |= r0 (db) r0 = atomic64_fetch_and((u64 *)(r3 +0), r0) > (b5) if r0 <= 0x0 goto pc-2 (b5) if r0 <= 0x0 goto pc-2 > (95) exit (95) exit > > So, I assume it's the same issue. Looking into it. > > [1] https://lore.kernel.org/bpf/68c85b0d.050a0220.2ff435.03a5.GAE@google.com/T/#u Minimal reproducer: SEC("socket") __caps_unpriv(CAP_BPF) __naked void syzbot_bug(void) { asm volatile ( "r0 = 100;" "1:" "*(u64 *)(r10 - 512) = r0;" "if r0 <= 0x0 goto 1b;" "exit;" ::: __clobber_all); } And corresponding verifier log: Live regs before insn: 0: .......... (b7) r0 = 100 1 1: 0......... (7b) *(u64 *)(r10 -512) = r0 1 2: 0......... (b5) if r0 <= 0x0 goto pc-2 3: 0......... (95) exit Global function syzbot_bug() doesn't return scalar. Only those are supported. 0: R1=ctx() R10=fp0 ; asm volatile ( @ verifier_and.c:118 0: (b7) r0 = 100 ; R0_w=100 1: (7b) *(u64 *)(r10 -512) = r0 ; R0_w=100 R10=fp0 fp-512_w=100 2: (b5) if r0 <= 0x0 goto pc-2 mark_precise: frame0: last_idx 2 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r0 stack= before 1: (7b) *(u64 *)(r10 -512) = r0 mark_precise: frame0: regs=r0 stack= before 0: (b7) r0 = 100 2: R0_w=100 3: (95) exit from 2 to 1 (speculative execution): R0_w=scalar() R1=ctx() R10=fp0 fp-512_w=100 1: R0_w=scalar() R1=ctx() R10=fp0 fp-512_w=100 1: (7b) *(u64 *)(r10 -512) = r0 verifier bug: scc exit: no visit info for call chain (1) processed 5 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 [...] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [bpf?] WARNING in maybe_exit_scc 2025-09-15 23:40 ` Eduard Zingerman @ 2025-09-16 9:14 ` Eduard Zingerman 0 siblings, 0 replies; 6+ messages in thread From: Eduard Zingerman @ 2025-09-16 9:14 UTC (permalink / raw) To: syzbot, andrii, ast, bpf, daniel, haoluo, john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau, sdf, song, syzkaller-bugs, yonghong.song On Mon, 2025-09-15 at 16:40 -0700, Eduard Zingerman wrote: > On Mon, 2025-09-15 at 15:34 -0700, Eduard Zingerman wrote: > > [...] > > > > verifier bug: scc exit: no visit info for call chain (1)(1) > > > WARNING: CPU: 1 PID: 6013 at kernel/bpf/verifier.c:1949 maybe_exit_scc+0x768/0x8d0 kernel/bpf/verifier.c:1949 > > > > Both this and [1] are reported for very similar programs: > > > > <this> <[1]> > > -------------------------------------------------------------------------------------------- > > (b7) r0 = -1023213567 (b7) r0 = -1023213567 > > (bf) r3 = r10 (bf) r3 = r10 > > (07) r3 += -512 (07) r3 += -504 > > (72) *(u8 *)(r10 -16) = -8 (72) *(u8 *)(r10 -16) = -8 > > (71) r4 = *(u8 *)(r10 -16) (71) r4 = *(u8 *)(r10 -16) > > (65) if r4 s> 0xff000000 goto pc+2 (65) if r4 s> 0xff000000 goto pc+2 > > (2d) if r0 > r4 goto pc+5 (2d) if r0 > r4 goto pc+5 > > (20) r0 = *(u32 *)skb[60673] (20) r0 = *(u32 *)skb[60673] > > (7b) *(u64 *)(r3 +0) = r0 (7b) *(u64 *)(r3 +0) = r0 > > (1d) if r4 == r4 goto pc+0 (1d) if r4 == r4 goto pc+0 > > (7a) *(u64 *)(r10 -512) = -256 (7a) *(u64 *)(r10 -512) = -256 > > (db) lock *(u64 *)(r3 +0) |= r0 (db) r0 = atomic64_fetch_and((u64 *)(r3 +0), r0) > > (b5) if r0 <= 0x0 goto pc-2 (b5) if r0 <= 0x0 goto pc-2 > > (95) exit (95) exit > > > > So, I assume it's the same issue. Looking into it. > > > > [1] https://lore.kernel.org/bpf/68c85b0d.050a0220.2ff435.03a5.GAE@google.com/T/#u > > Minimal reproducer: > > SEC("socket") > __caps_unpriv(CAP_BPF) > __naked void syzbot_bug(void) > { > asm volatile ( > "r0 = 100;" > "1:" > "*(u64 *)(r10 - 512) = r0;" > "if r0 <= 0x0 goto 1b;" > "exit;" > ::: __clobber_all); > } > > And corresponding verifier log: > > Live regs before insn: > 0: .......... (b7) r0 = 100 > 1 1: 0......... (7b) *(u64 *)(r10 -512) = r0 > 1 2: 0......... (b5) if r0 <= 0x0 goto pc-2 > 3: 0......... (95) exit > Global function syzbot_bug() doesn't return scalar. Only those are supported. > 0: R1=ctx() R10=fp0 > ; asm volatile ( @ verifier_and.c:118 > 0: (b7) r0 = 100 ; R0_w=100 > 1: (7b) *(u64 *)(r10 -512) = r0 ; R0_w=100 R10=fp0 fp-512_w=100 > 2: (b5) if r0 <= 0x0 goto pc-2 > mark_precise: frame0: last_idx 2 first_idx 0 subseq_idx -1 > mark_precise: frame0: regs=r0 stack= before 1: (7b) *(u64 *)(r10 -512) = r0 > mark_precise: frame0: regs=r0 stack= before 0: (b7) r0 = 100 > 2: R0_w=100 > 3: (95) exit > > from 2 to 1 (speculative execution): R0_w=scalar() R1=ctx() R10=fp0 fp-512_w=100 > 1: R0_w=scalar() R1=ctx() R10=fp0 fp-512_w=100 > 1: (7b) *(u64 *)(r10 -512) = r0 > verifier bug: scc exit: no visit info for call chain (1) > processed 5 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 > > [...] Here is what happens: - Verification process starts and gets to instruction (2) w/o creating any checkpoints. - A speculative execution of the false branch is pushed onto states stack; main execution process predicts the branch as false and continues to exit. Still no checkpoints. - Speculative execution branch is popped from stack and proceeds from instruction (1). - Speculative execution immediately terminates, because verifier detects an infinite loop and signals an error. - update_branch_counts() is called for speculative execution state and its branches count reaches zero. - update_branch_counts() -> maybe_exit_scc() is called for a state with insn_idx in SCC #1. - maybe_exit_scc() assumes that when it is called for a state with insn_idx in some SCC, there should be an instance of struct bpf_scc_visit allocated for this SCC, which is not the case here. Why the assumption about bpf_scc_visit existence is made by maybe_exit_scc()? While performing non-speculative symbolic execution there are three ways to terminate execution path: a. Verification error is found. In this case update_branch_counts() is not called and bpf_scc_visit existence does not matter. b. Top level BPF_EXIT is reached. Exit instructions are never a part of an SCC, so compute_scc_callchain() in maybe_scc_exit() will return false and maybe_scc_exit() will return early. c. A checkpoint is reached and matched. Checkpoints are created by is_state_visited(), which calls maybe_enter_scc(), which allocates bpf_scc_visit instances for checkpoints within SCCs. Hence, for non-speculative symbolic execution paths there is no way to reach a state when maybe_scc_exit() is called for a state within an SCC, but bpf_scc_visit instance does not exist. However, the above logic falls short for speculative symbolic execution paths, because verification errors (option (a) above) lead to update_branch_counts() calls. And the test case above demonstrates exactly that scenario. I'll send a patch disabling bpf_scc_visit existence assertion for speculative paths in the morning. Something along the lines: --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -1950,6 +1950,8 @@ static int maybe_exit_scc(struct bpf_verifier_env *env, struct bpf_verifier_stat return 0; visit = scc_visit_lookup(env, callchain); if (!visit) { + if (st->speculative) + return 0; verifier_bug(env, "scc exit: no visit info for call chain %s", format_callchain(env, callchain)); return -EFAULT; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [bpf?] WARNING in maybe_exit_scc 2025-09-15 18:28 [syzbot] [bpf?] WARNING in maybe_exit_scc syzbot 2025-09-15 22:34 ` Eduard Zingerman @ 2025-09-16 10:20 ` syzbot 2025-09-29 7:57 ` Luis Gerhorst 1 sibling, 1 reply; 6+ messages in thread From: syzbot @ 2025-09-16 10:20 UTC (permalink / raw) To: andrii, ast, bpf, daniel, eddyz87, haoluo, henriette.herzog, john.fastabend, jolsa, kpsingh, linux-kernel, luis.gerhorst, martin.lau, memxor, sdf, song, syzkaller-bugs, yonghong.song syzbot has bisected this issue to: commit d6f1c85f22534d2d9fea9b32645da19c91ebe7d2 Author: Luis Gerhorst <luis.gerhorst@fau.de> Date: Tue Jun 3 21:24:28 2025 +0000 bpf: Fall back to nospec for Spectre v1 bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17753762580000 start commit: f83ec76bf285 Linux 6.17-rc6 git tree: upstream final oops: https://syzkaller.appspot.com/x/report.txt?x=14f53762580000 console output: https://syzkaller.appspot.com/x/log.txt?x=10f53762580000 kernel config: https://syzkaller.appspot.com/x/.config?x=8f01d8629880e620 dashboard link: https://syzkaller.appspot.com/bug?extid=3afc814e8df1af64b653 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=104a947c580000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14467b62580000 Reported-by: syzbot+3afc814e8df1af64b653@syzkaller.appspotmail.com Fixes: d6f1c85f2253 ("bpf: Fall back to nospec for Spectre v1") For information about bisection process see: https://goo.gl/tpsmEJ#bisection ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [bpf?] WARNING in maybe_exit_scc 2025-09-16 10:20 ` syzbot @ 2025-09-29 7:57 ` Luis Gerhorst 0 siblings, 0 replies; 6+ messages in thread From: Luis Gerhorst @ 2025-09-29 7:57 UTC (permalink / raw) To: bpf Cc: andrii, ast, daniel, eddyz87, haoluo, henriette.herzog, john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau, memxor, sdf, song, syzkaller-bugs, yonghong.song syzbot <syzbot+3afc814e8df1af64b653@syzkaller.appspotmail.com> writes: > syzbot has bisected this issue to: > > commit d6f1c85f22534d2d9fea9b32645da19c91ebe7d2 > Author: Luis Gerhorst <luis.gerhorst@fau.de> > Date: Tue Jun 3 21:24:28 2025 +0000 > > bpf: Fall back to nospec for Spectre v1 > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17753762580000 > start commit: f83ec76bf285 Linux 6.17-rc6 > git tree: upstream > final oops: https://syzkaller.appspot.com/x/report.txt?x=14f53762580000 > console output: https://syzkaller.appspot.com/x/log.txt?x=10f53762580000 > kernel config: https://syzkaller.appspot.com/x/.config?x=8f01d8629880e620 > dashboard link: https://syzkaller.appspot.com/bug?extid=3afc814e8df1af64b653 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=104a947c580000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14467b62580000 > > Reported-by: syzbot+3afc814e8df1af64b653@syzkaller.appspotmail.com > Fixes: d6f1c85f2253 ("bpf: Fall back to nospec for Spectre v1") > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection Sorry for the delay as I was out of office. I will be looking into this and also [1] shortly. [1] https://lore.kernel.org/bpf/68c8de6b.050a0220.3c6139.0d26.GAE@google.com/ ("Re: [syzbot] [bpf?] WARNING in do_check (2)") ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-09-29 8:07 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-09-15 18:28 [syzbot] [bpf?] WARNING in maybe_exit_scc syzbot 2025-09-15 22:34 ` Eduard Zingerman 2025-09-15 23:40 ` Eduard Zingerman 2025-09-16 9:14 ` Eduard Zingerman 2025-09-16 10:20 ` syzbot 2025-09-29 7:57 ` Luis Gerhorst
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox