On 2024-07-08 17:03:58 [-0700], Martin KaFai Lau wrote: > > diff --git a/net/core/filter.c b/net/core/filter.c > > index 403d23faf22e1..ea5bc4a4a6a23 100644 > > --- a/net/core/filter.c > > +++ b/net/core/filter.c > > @@ -6459,6 +6459,8 @@ BPF_CALL_4(bpf_lwt_seg6_store_bytes, struct sk_buff *, skb, u32, offset, > > void *srh_tlvs, *srh_end, *ptr; > > int srhoff = 0; > > + if (!bpf_net_ctx_seg6_state_avail()) > > + return -EINVAL; > > The syzbot stack shows that the seg6local bpf_prog can be run by test_run > like: bpf_prog_test_run_skb() => bpf_test_run(). "return -EINVAL;" will > reject and break the existing bpf prog doing test with test_run. But wouldn't this be the case anyway because seg6_bpf_srh_states::srh isn't assigned? > bpf_test_run() has already done the local_bh_disable() and > bpf_net_ctx_set(). How about doing the > local_[un]lock_nested_bh(&seg6_bpf_srh_states.bh_lock) in bpf_test_run() > when the prog->type == BPF_PROG_TYPE_LWT_SEG6LOCAL? Okay. Sure. And I assume it is limited that only those two call paths can invoke this type of BPF program. Sebastian
