Re: [BUG] bpf: use-after-free in hashtab BPF_F_LOCK in-place update path

[Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>]

On 3/31/26 1:55 AM, Kumar Kartikeya Dwivedi wrote:
> On Fri, 27 Mar 2026 at 17:09, Mykyta Yatsenko
> <mykyta.yatsenko5@gmail.com> wrote:
>>
>> Kumar Kartikeya Dwivedi <memxor@gmail.com> writes:
>>
>>> On Fri, 27 Mar 2026 at 03:54, Aaron Esau <aaron1esau@gmail.com> wrote:
>>>>
>>>> Puranjay Mohan <puranjay12@gmail.com> writes:
>>>>
>>>>> Yes, if all the users have BPF_F_LOCK then it will work because the
>>>>> re-used element will have the same lock and everything is serialized.
>>>>> But this reproducer is trying to show that the elements are being
>>>>> re-used, which they are.
>>>>
>>>> Updated reproducer attached. All operations now use BPF_F_LOCK (updates,
>>>> re-add after delete, and lookups), so value access is serialized via the
>>>> element's embedded spin_lock. The value size is ~4000 bytes. Torn writes
>>>> are still observed (3 in 2.7M).
>>>>
>>>> With full spin_lock coverage, the only remaining unlocked write path is
>>>> alloc_htab_elem() -> copy_map_value(), which copies into a newly
>>>> allocated element prior to insertion. For this to race with a locked
>>>> reader or writer, the reader must be dereferencing a stale pointer to
>>>> memory that has been freed and reallocated -- a use-after-free.
>>>>
>>>> The root cause is bpf_mem_cache_free() in htab_elem_free(), which
>>>> immediately returns memory to the per-CPU freelist rather than deferring
>>>> via RCU. This allows reuse while the syscall path is still within an RCU
>>>> read-side critical section. Preallocated maps do not have this problem
>>>> because freed elements remain within a pool of valid htab_elems.
>>>>
>>>> Switching to bpf_mem_cache_free_rcu(), as Puranjay showed earlier in this
>>>> thread, eliminates the corruption.
>>>
>>> As I said, the reuse is intended behavior. We won't be switching to
>>> bpf_mem_cache_free_rcu().
>>> This is mostly for performance reasons, in case you're perplexed as to why.
>>> That said, we could do copy_map_value_locked() if map_flags &
>>> BPF_F_LOCK to fix this particular case.
>>> Such that if the value is being reused we will still have serialization.
>> I think we should do copy_map_value_locked() on the reuse path.
> 
> Do you want to follow up on this? Otherwise I will get to it
> eventually, either way is fine.
> Thanks

I'll send a patch.