Re: [PATCH bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap

[Michal Luczaj]

On 10/17/26 01:52, Alexei Starovoitov wrote:
> On Fri, Oct 16, 2026 at 11:09 PM Michal Luczaj <mhal@xxxxxxx> wrote:
>> [2]: commit 64c2f93fc325 ("bpf, sockmap: Take state lock for af_unix iter")
> 
> unix_state_lock() in bpf_iter_unix_seq_show() was added only for
> unix_stream_bpf_update_proto() called from the iter prog.
> iter/unix cannot get there anymore.
> can we drop it ? can be a follow up...

So we don't care about having a stable socket state while iterating? Which
is the case for iter/sockmap, but is unlike iter/{tcp,udp}.

>> +		if (eatype == BPF_TRACE_ITER &&
>> +		    env->prog->type == BPF_PROG_TYPE_TRACING &&
>> +		    !strcmp(afname + strlen(BPF_ITER_FUNC_PREFIX), "sockmap"))
>>  			return true;
> 
> iter/sockmap prog is not limited to ctx->sk it seems.
> bpf_skc_to_unix_sock(ctx->sk)->peer is a plain PTR_TO_BTF_ID and
> the value arg of bpf_map_update_elem() accepts it.
> The peer doesn't have to be in any map, so it has no psock,
> and sock_map_seq_show() holds nothing but rcu.
> sock_map_update_elem() takes bh_lock_sock(), then sock_map_link() does
> sk_psock_init() and unix_stream_bpf_update_proto() on a socket
> that unix_release_sock() can be tearing down.
> That's the same unlocked socket as in iter/task_file.

I'm not sure I see the (stream sock) issue above. psock->sk_pair holds the
peer, so peer pointer remains valid during proto update. iter/sockmap is
safe, because sk is held by RCU. And for iter/unix we currently take
unix_state_lock().

But iter/sockmap dgram peer is a problem, right? No sk_pair, no lock, and
connect(AF_UNSPEC) can get the peer dropped.

> Should we restrict it to ctx->sk somehow?

I recall a discussion about having BPF helpers accept only trusted
pointers:
https://lore.kernel.org/bpf/CAADnVQK_93g_KkNFYXSr8ZvA1fYh4hoFRJCJFPS-zs4ox0HhAA@xxxxxxxxxxxxxx/
Restricting only iter/unix seems better?