Re: [PATCH RFC net-next 1/9] net: add bpf_setsockopt for SK_BPF_CB_TIMESTAMPING_V2

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: TOCTOU race in sk_bpf_set_get_cb_flags() corrupts global static key
--

commit 1e7a759ab84f855625d2d275769f450b5e750f84
Author: Jason Xing <kerneljasonxing@gmail.com>

net: add bpf_setsockopt for SK_BPF_CB_TIMESTAMPING_V2

Introduce a per-socket bit SK_BPF_CB_TIMESTAMPING_V2 for BPF Timestamping
V2, that allows a socket opt into recording a "start time" on every
skb it produces or receives.

> diff --git a/net/core/filter.c b/net/core/filter.c
> index 61940e7535523..3486c5c2d1703 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -5468,6 +5468,13 @@ static int sk_bpf_set_get_cb_flags(struct sock *sk, char *optval, bool getopt)
>  	if (sk_bpf_cb_flags & ~SK_BPF_CB_MASK)
>  		return -EINVAL;
>  
> +	if ((sk_bpf_cb_flags ^ sk->sk_bpf_cb_flags) & SK_BPF_CB_TIMESTAMPING_V2) {
> +		if (sk_bpf_cb_flags & SK_BPF_CB_TIMESTAMPING_V2)
> +			bpfts_v2_enable();
> +		else
> +			bpfts_v2_disable();
> +	}
> +
>  	sk->sk_bpf_cb_flags = sk_bpf_cb_flags;
>  
>  	return 0;

[Severity: High]
Does this unprotected compare-and-branch allow concurrent threads to trigger
unmatched global enable/disable calls, permanently corrupting the reference
state?

If multiple threads concurrently call bpf_unlocked_sk_setsockopt(SK_BPF_CB_FLAGS)
on a shared socket, they evaluate (sk_bpf_cb_flags ^ sk->sk_bpf_cb_flags)
without locks. Both threads could observe the same initial state and invoke
bpfts_v2_enable() twice, but the socket will only decrement it once during
__sk_destruct().

Could this permanently degrade system-wide performance by leaking the static
key, or underflow it and break the feature for other active users?

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