* [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