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

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

On Wed, Jul 01, 2026 at 12:04:14PM +0200, Jakub Sitnicki wrote:
>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 lock this down to just iter/sockmap allowing these updates from
arbitrary context is too hard to reason about.