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

> 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?

> +		/*
> +		 * 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)) {

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/31743446421