Re: [PATCH bpf-next v3 0/3] bpf: Fix a struct_ops use-after-free behind a flaky assoc_in_timer test

[Qiliang Yuan <odys.yuan@gmail.com>]

On Thu, Oct 15, 2026 at 10:41 AM Amery Hung <ameryhung@gmail.com> wrote:
> I think this fix is heading in the wrong direction. The struct_ops map
> association was designed as an RCU-protected pointer: asynchronous
> users may outlive the map and observe a NULL association. The existing
> selftest explicitly verifies this behavior.
>
> The problem is that the disassociation now happens after the grace
> period initiated by bpf_map_put(). Could we instead make
> disassociation safe in map_free_pre_rcu(), before that existing grace
> period, rather than adding another deferred-free path?

Agreed, that is simpler. v4 [1] does it in two steps:

1. Replace st_ops_assoc_mutex with a spinlock taken with irqs disabled,
   and put the map of a non-struct_ops prog after dropping it.
   map_free_pre_rcu() runs wherever the last reference is dropped,
   which can be softirq, e.g. bpf_struct_ops_put() from
   tcp_cleanup_congestion_control().

2. Call bpf_struct_ops_map_dissoc_progs() from
   bpf_struct_ops_map_free_pre_rcu() instead of
   bpf_struct_ops_map_free().

One thing to confirm: bpf_map_put() waits only for a regular RCU grace
period unless free_after_mult_rcu_gp is set, and no struct_ops sets it
today. bpf_wq_work() runs the callback of a struct_ops prog under
rcu_read_lock_trace(), and that callback can read the association too,
so v4 sets free_after_mult_rcu_gp for every struct_ops map. Would you
rather leave that to each struct_ops?

On a KASAN kernel with v4, st_ops_assoc_in_timer_free passes 100 of 100
runs, where it hits the int3 Oops on run 1 without the fix, and lockdep
reports nothing over the struct_ops and tcp_ca selftests.

[1] https://lore.kernel.org/r/20261016-selftests-bpf-struct-ops-assoc-timer-v4-0-9ad31c21220c@gmail.com