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

On Mon Aug 3, 2026 at 7:57 AM CEST, Ning Ding wrote:
>> Same comment as the new set; split kernel commits and selftest commits into
>> separate ones. As for the fix, I think it would make more sense if
>> type_is_ptr_alloc_obj() was fixed to PTR_UNTRUSTED by definition, instead of
>> having to add extra checks on top.
>
> I tried this change on bpf-next 60781269e26c. It fixes the
> refcount_acquire case; the focused tests pass 43/43, and the
> list/rbtree tests pass 176/176.
>
> But here is one concern: type_is_ptr_alloc_obj() is also used by
> type_is_non_owning_ref() and reg_btf_record(). In particular,
> type_is_non_owning_ref() is defined in terms of it. After the final
> RCU unlock, a graph-object pointer has MEM_ALLOC | NON_OWN_REF |
> PTR_UNTRUSTED. Excluding PTR_UNTRUSTED from the shared helper makes
> type_is_non_owning_ref() return false.
>
> This also seems inconsistent with d8939cb0a03c, which allowed extra
> flags, including PTR_UNTRUSTED, for metadata lookup.

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.