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

[Michal Luczaj <mhal@rbox.co>]

On 10/19/26 21:40, Alexei Starovoitov wrote:
> On Mon, Oct 19, 2026 at 08:20 AM Michal Luczaj <mhal@rbox.co> wrote:
>> On 10/17/26 01:52, Alexei Starovoitov wrote:
>>> 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}.
> 
> Not sure. Is there a value?

Isn't it (currently) necessary for iter/{unix,sockmap} dgram peer
disappearing on connect(AF_UNSPEC)?

But, if I understand correctly, the removal of plain PTR_TO_BTF_ID will
make pointers like `peer` inaccessible to helpers. And we just accept progs
have to deal with potentially stale data, e.g. the value of sk_shutdown.

>>> 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@mail.gmail.com/
>> Restricting only iter/unix seems better?
> 
> we just discussed at bpf sync meeting that it's time to
> finally remove plain PTR_TO_BTF_ID.
> Otherwise we keep hitting this bug everywhere.
> 
> in the meantime can we do it for this one arg ?
> Mark ctx->sk as PTR_TRUSTED in sock_map_iter_reg
> like iter/tcp and iter/udp do ?

Ah, sure. So the same bit for unix_reg_info left for later?

I've noticed commit 7cc639dc45c5 ("bpf: Don't take an extension for an
iterator program") got merged. Should I post v2 with the env->prog->type
check dropped or you guys don't want to restrict iters anymore?