Re: [PATCH bpf-next v3 1/2] bpf, sockmap: disallow update and delete from tc, xdp and flow_dissector

[John Fastabend <john.fastabend@gmail.com>]

On Mon, Jun 29, 2026 at 11:24:49AM -0700, Alexei Starovoitov wrote:
>On Mon Jun 29, 2026 at 10:27 AM PDT, Sechang Lim wrote:
>> sock_map_update_common() and __sock_map_delete() hold stab->lock and call
>> sock_map_unref() -> sock_map_del_link(), which takes sk_callback_lock for
>> write. That gives the order stab->lock -> sk_callback_lock.
>>
>> The reverse order comes from the SK_SKB stream parser.
>> sk_psock_strp_data_ready() holds sk_callback_lock for read, and after the
>> verdict tcp_bpf_strp_read_sock() acks the consumed data inline via
>> __tcp_cleanup_rbuf(). The ACK goes out egress, where a sched_cls program
>> deletes from the sockmap and takes stab->lock:
>>
>>   WARNING: possible circular locking dependency detected
>>   ------------------------------------------------------
>>   syz.9.8824 is trying to acquire lock:
>>   (&stab->lock){+.-.}-{3:3}, at: __sock_map_delete net/core/sock_map.c:421
>>   but task is already holding lock:
>>   (clock-AF_INET){++.-}-{3:3}, at: sk_psock_strp_data_ready net/core/skmsg.c:1173
>>
>>   -> #1 (clock-AF_INET){++.-}-{3:3}:
>>          _raw_write_lock_bh
>>          sock_map_del_link net/core/sock_map.c:167
>>          sock_map_unref net/core/sock_map.c:184
>>          sock_map_update_common net/core/sock_map.c:509
>>          sock_map_update_elem_sys net/core/sock_map.c:588
>>          map_update_elem kernel/bpf/syscall.c:1805
>>
>>   -> #0 (&stab->lock){+.-.}-{3:3}:
>>          _raw_spin_lock_bh
>>          __sock_map_delete net/core/sock_map.c:421
>>          sock_map_delete_elem net/core/sock_map.c:452
>>          bpf_prog_06044d24140080b6
>>          tcx_run net/core/dev.c:4451
>>          sch_handle_egress net/core/dev.c:4541
>>          __dev_queue_xmit net/core/dev.c:4808
>>          ...
>>          tcp_bpf_strp_read_sock net/ipv4/tcp_bpf.c:701
>>          strp_data_ready net/strparser/strparser.c:402
>>          sk_psock_strp_data_ready net/core/skmsg.c:1174
>>          tcp_data_queue net/ipv4/tcp_input.c:5661
>>
>>   Possible unsafe locking scenario:
>>
>>          CPU0                    CPU1
>>          ----                    ----
>>     rlock(clock-AF_INET);
>>                                  lock(&stab->lock);
>>                                  lock(clock-AF_INET);
>>     lock(&stab->lock);
>>
>>    *** DEADLOCK ***
>>
>> A tc, xdp or flow_dissector program has no reason to update or delete a
>> sockmap, and redirect does not go through here. Drop them from
>> may_update_sockmap() so the verifier rejects it. It also closes the
>> matching sockhash inversion.
>>
>> Suggested-by: John Fastabend <john.fastabend@gmail.com>
>> Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
>
>John,
>
>please ack.

Hi Sechang,

I think we additionally need to also block BPF_PROG_TYPE_SOCKET_FILTER? 
Did you check this case I guess the same case is possible there?

Then another patch needs to restrict BPF_SOCK_OPS users. For that
we need to block BPF_SOCK_OPS_HDR_OPT_LEN_CB and BPF_SOCK_OPS_WRITE_*.
Let me know if you want to do those as well. Let me know if you want
to do both patches or just the prog blocking above with the possible
addition of SOCKET_FILTER. I didn't search very hard so probably need
to check all the BPF_SOCK_OPS_* to find the valid cases.

Thanks,
John