Re: [PATCH bpf v2 1/4] bpf, sockmap: Reject unhashed UDP sockets on sockmap update

[Jakub Sitnicki <jakub@cloudflare.com>]

On Mon, Jun 29, 2026 at 11:40 PM +02, Michal Luczaj wrote:
> On 6/29/26 13:37, Jakub Sitnicki wrote:
>> On Sun, Jun 28, 2026 at 11:59 PM +02, Michal Luczaj wrote:
>>> On 6/26/26 22:58, sashiko-bot@kernel.org wrote:
>>>> [Severity: High]
>>>> Could a memory ordering regression here allow unbound UDP sockets to still
>>>> bypass this check?
>>>>
>>>> In udp_v4_get_port(), the flag and hash are set:
>>>>
>>>> net/ipv4/udp.c:udp_v4_get_port() {
>>>>     ...
>>>>     sock_set_flag(sk, SOCK_RCU_FREE);
>>>>     sk_add_node_rcu(sk, &hslot->head);
>>>>     ...
>>>> }
>>>>
>>>> Because these stores lack a memory barrier between them, could sk_hashed(sk)
>>>> return true on another CPU while SOCK_RCU_FREE is not yet visible, allowing
>>>> the leak to still trigger?
>>>
>>> I'd like to verify it on a weakly-ordered CPU; please give me a day or two.
>> 
>> False positive, IMO.
>> Both ->get_port and sock_map_sk_state_allowed run with sk_lock held.
>
> What about an update coming from iter/task_file? You get an unlocked socket
> via bpf_sock_from_file(ctx->file). And sock_map_update_elem()'s
> bh_lock_sock(sk) doesn't care if socket is owned.

You're right. No exclusive access to socket there.

I think we should block map updates from all iterators but iter/sockmap,
where we know the socket is already in the correct state.

This is in the spirit of the API lockdown that is in progress [1]

[1] https://msgid.link/akRZ_e7DJh2aP-2i@john-p8

> I was looking at iter/task_file in the context of [0]'s follow-up. With or
> without [1], we're getting closer to enforcing (stronger) locking in
> sock_map_update_elem(), per Martin's suggestion. Along the lines of
>
>    if (!has_current_bpf_ctx() && sock_owned_by_user_nocheck(sk))
>       ret = -EBUSY;
>    else if (WARN_ON_ONCE(has_current_bpf_ctx() && !sock_owned_by_user_nocheck(sk)))
>       ret = -EINVAL;
>    ...
>
> Would that fly?
>
> [0]: https://lore.kernel.org/bpf/20260414-unix-proto-update-null-ptr-deref-v4-0-2af6fe97918e@rbox.co/
> [1]: https://lore.kernel.org/bpf/20260629172704.1302218-1-rhkrqnwk98@gmail.com/