Re: [PATCH v3 bpf-next 08/11] bpf: tcp: Reject BPF_SOCK_OPS_RCVQ_CB if receive queue is not empty.
From: bot+bpf-ci@kernel.org
Date: 2026-05-23 09:20:48
Also in:
bpf
quoted hunk ↗ jump to hunk
diff --git a/net/core/filter.c b/net/core/filter.c index 82ec2291d6f0..4041b9fc1c74 100644 --- a/net/core/filter.c +++ b/net/core/filter.c@@ -5390,6 +5390,9 @@ static int __bpf_sock_ops_cb_flags_set(struct sock *sk, int val) return 0; } + if (!skb_queue_empty(&sk->sk_receive_queue)) + return -EUCLEAN; +
Is there a TOCTOU issue here? The check occurs before acquiring
sk->sk_callback_lock, which means:
Thread A (process context)
__bpf_sock_ops_cb_flags_set()
if (!skb_queue_empty(&sk->sk_receive_queue)) // queue is empty
// check passes
Thread B (softirq context)
tcp_rcv_established()
// adds packet to sk->sk_receive_queue
Thread A (continuing)
__bpf_sock_ops_cb_flags_set()
write_lock_bh(&sk->sk_callback_lock);
// sets bpf_sock_ops_cb_flags despite queue being non-empty
Looking at the tcp_in_sockmap() check below, it contains
lockdep_assert_held(&sk->sk_callback_lock), showing that related
validation checks are expected to be performed under this lock:
if (unlikely(sk_is_mptcp(sk)))
return -EOPNOTSUPP;
write_lock_bh(&sk->sk_callback_lock);
if (unlikely(tcp_in_sockmap(sk))) {
write_unlock_bh(&sk->sk_callback_lock);
return -EBUSY;
}The commit message says the goal is to "strictly prevent any potential race conditions" by ensuring the receive queue is empty when BPF_SOCK_OPS_RCVQ_CB is enabled. Can this check be moved after the write_lock_bh() call to eliminate the race window? --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26328541814