Re: [PATCH bpf v2 2/2] bpf: Reject untrusted pointers in refcount_acquire

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Mon Aug 3, 2026 at 8:48 AM CEST, Ning Ding wrote:
>> I would just disallow it. I don't even know how things would be correct if a
>> untrusted owning or non-owning ref is passed around. I think the case in patch 2
>> is demonstrating that it's a bogus type state for being passed around into the
>> kernel.
>>
>> The only meaningful correct use seems to be reading from such a pointer, for
>> which PTR_UNTRUSTED downgrade instead of invalidating it completely should be
>> good enough.
>
> Just to confirm, semantically should this case be rejected by the verifier?
>
> bpf_rcu_read_lock();
> res = mapval->node;
> bpf_rcu_read_unlock();
> return res->key;
>
> At the final read, res is MEM_ALLOC | NON_OWN_REF | PTR_UNTRUSTED.
> Should this be accepted for scalar reads, or should this pointer state
> be rejected since it could possibly cause read-after-free.

It will work, you can test it yourself. Reads on PTR_UNTRUSTED is fine, it gets
handled by the BPF_PROBE_MEM loads, which handle use-after-free safely.