Re: [PATCH bpf-next 2/4] bpf: Merge pointer types also when both are PTR_TO_MEM

On 8/13/26 11:44 PM, [email protected] wrote:
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 1f2ed6164305e..5daca4ef27278 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -17096,6 +17096,17 @@ static int save_aux_ptr_type(struct bpf_verifier_env *env, enum bpf_reg_type typ
>>   		 * save type to validate intersecting paths
>>   		 */
>>   		*prev_type = type;
>> +	} else if (*prev_type != type && allow_trust_mismatch &&
>> +		   is_ptr_to_mem_or_btf_id(type) &&
>> +		   is_ptr_to_mem_or_btf_id(*prev_type)) {
> 
> Does this condition still leave a gap when the other side is one of
> the remaining reg_type_mismatch_ok() base types?
> 
> Looking at reg_type_mismatch_ok() in verifier.c, it returns false only for
> PTR_TO_CTX, PTR_TO_SOCKET, PTR_TO_SOCK_COMMON, PTR_TO_TCP_SOCK, PTR_TO_XDP_SOCK,
> PTR_TO_BTF_ID and PTR_TO_ARENA. Everything else (PTR_TO_MAP_VALUE, PTR_TO_STACK,
> PTR_TO_PACKET, PTR_TO_BUF, PTR_TO_TP_BUFFER, PTR_TO_MAP_KEY, PTR_TO_FLOW_KEYS)
> is "mismatch ok".
> 
> For such a type paired with PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED at the
> same BPF_LDX:
> 
>    is_ptr_to_mem_or_btf_id(*prev_type) would be false, so this new branch
>    would be skipped
> 
>    reg_type_mismatch() would be false (both sides are mismatch_ok), so
>    nothing is recorded either
> 
>    *prev_type keeps the type of whichever path was verified first
> 
> If that first path was PTR_TO_MAP_VALUE, bpf_convert_ctx_accesses() in
> kernel/bpf/fixups.c falls into the default case - no BPF_PROBE_MEM rewrite
> and no exception table entry - and the untrusted path then takes a plain
> faulting load.
> 
> The commit message says this is being fixed, but doesn't this exact panic
> stay reachable? The existing selftest ldx_is_ok_bad_addr() in
> tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c already loads from
> bpf_rdonly_cast(0, 0) and relies on the PROBE_MEM rewrite; the map-value
> half is just a post-NULL-check bpf_map_lookup_elem() result.
> 
> Should the merge also fire when only one side is PTR_TO_MEM or PTR_TO_BTF_ID
> and that side may_fault_on_deref(), or should such a mix be rejected
> outright?

I'll check this one tomorrow in more detail. Fwiw, the other bot+bpf-ci
reviews are non-issues.

>> +		/*
>> +		 * Have to support a use case when one path through the
>> +		 * program yields a TRUSTED pointer while another is
>> +		 * UNTRUSTED. Merge them into a type which keeps the
>> +		 * BPF_PROBE_MEM/BPF_PROBE_MEMSX rewrite when either
>> +		 * side needs it.
>> +		 */
>> +		*prev_type = merge_ptr_types(type, *prev_type);
>>   	} else if (reg_type_mismatch(type, *prev_type)) {
> 
> [ ... ]