Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> writes: > On 2024-08-31 13:55:02 [-0700], syzbot wrote: >> syzbot suspects this issue was fixed by commit: >> >> commit 401cb7dae8130fd34eb84648e02ab4c506df7d5e >> Author: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> >> Date: Thu Jun 20 13:22:04 2024 +0000 >> >> net: Reference bpf_redirect_info via task_struct on PREEMPT_RT. >> >> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12597c63980000 >> start commit: 36534d3c5453 tcp: use signed arithmetic in tcp_rtx_probe0_.. >> git tree: bpf >> kernel config: https://syzkaller.appspot.com/x/.config?x=333ebe38d43c42e2 >> dashboard link: https://syzkaller.appspot.com/bug?extid=cca39e6e84a367a7e6f6 >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13390aea980000 >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10948741980000 > > This looks like ri->tgt_value is a NULL pointer (dst in > dev_map_enqueue()). The commit referenced by syz should not have fixed > that. > It is possible that there were leftovers in bpf_redirect_info (from a > previous invocation) which were memset(,0,) during the switch from > per-CPU to stack usage and now it does not trigger anymore. Yes, I believe you are right. AFAICT, the original issue stems from the SKB path and XDP path using the same numeric flag values in the ri->flags field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). So if bpf_redirect_neigh() was used and subsequently, an XDP redirect was performed using the same bpf_redirect_info struct, the XDP path would get confused and end up crashing. Now, with the stack-allocated bpf_redirect_info, this sharing can no longer happen, so the crash doesn't happen anymore. However, different code paths using identically-numbered flag values in the same struct field still seems like a bit of a mess, so I'll send a patch to fix this just to be safe in case we ever move back to sharing this data structure. -Toke
