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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete fix for lock inversion deadlock: BPF_PROG_TYPE_SOCK_OPS can still trigger the exact same AB-BA deadlock on sockmap deletion.
--

commit a83dfc6fb81e4e2eb338be86e16b21c433de50ac
Author: Sechang Lim <rhkrqnwk98@gmail.com>

bpf, sockmap: disallow update and delete from tc, xdp, socket_filter and flow_dissector

The patch prevents a potential circular locking dependency by dropping several
BPF program types from may_update_sockmap(). This addresses a deadlock where
a sched_cls program taking stab->lock can invert the lock ordering against
sk_callback_lock held during stream parser receive.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 25aea4271cd08..83ea3b33ff679 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -8488,12 +8488,7 @@ static bool may_update_sockmap(struct bpf_verifier_env *env, int func_id)
>  		if (func_id == BPF_FUNC_map_delete_elem)
>  			return true;
>  		break;

[Severity: High]
This isn't a bug introduced by this patch, but does allowing
BPF_PROG_TYPE_SOCK_OPS to call BPF_FUNC_map_delete_elem still leave the same
lock inversion deadlock open?

If CPU0 calls bpf_map_delete_elem() from process context, acquires stab->lock
via __sock_map_delete(), and blocks waiting for a write lock on
sk_callback_lock inside sock_map_del_link():

CPU0
__sock_map_delete()
   takes stab->lock
   sock_map_del_link()
      blocks on sk_callback_lock (write)

And concurrently on CPU1, network receive processing invokes
sk_psock_strp_data_ready() and holds sk_callback_lock for read:

CPU1
sk_psock_strp_data_ready()
   holds sk_callback_lock (read)
   ...
   tcp_send_ack()
      __tcp_transmit_skb()
         tcp_established_options()
            synchronously executes attached BPF_PROG_TYPE_SOCK_OPS program

Can the BPF program call bpf_map_delete_elem() on a SOCKMAP, attempting to
acquire stab->lock and deadlocking against CPU0?

> -	case BPF_PROG_TYPE_SOCKET_FILTER:
> -	case BPF_PROG_TYPE_SCHED_CLS:
> -	case BPF_PROG_TYPE_SCHED_ACT:
> -	case BPF_PROG_TYPE_XDP:
>  	case BPF_PROG_TYPE_SK_REUSEPORT:
> -	case BPF_PROG_TYPE_FLOW_DISSECTOR:
>  	case BPF_PROG_TYPE_SK_LOOKUP:
>  		return true;
>  	default:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630145410.3648099-1-rhkrqnwk98@gmail.com?part=1