Re: [PATCH net-next 03/15] bpf: Accept trusted pointers to kern ctx type for kfunc ctx args

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] bpf: unvalidated PTR_TO_BTF_ID offset in kfunc ctx args leads to OOB access
- [Medium] bpf: premature loop exit in check_kfunc_args() leaves meta->ret_btf_id uninitialized
--

commit ea1588dd82a28e6c8256a75b8fbee8a46aedb584
Author: Jakub Sitnicki <jakub@cloudflare.com>

bpf: Accept trusted pointers to kern ctx type for kfunc ctx args

This commit updates kfunc argument handling to accept trusted PTR_TO_BTF_ID
pointers for KF_ARG_PTR_TO_CTX arguments, provided they match the expected
kernel context type. It allows passing derived kernel pointers, such as
those from bpf_skb_fclone_twin(), to kfuncs expecting a context pointer.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 41b49c56e1237..da5d6de58650f 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -12891,6 +12891,23 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_call_arg_me
>  			break;
>  		case KF_ARG_PTR_TO_CTX:
>  			if (reg->type != PTR_TO_CTX) {
> +				/* Only accept trusted kernel-context pointers from
> +				 * vmlinux BTF. reg->btf_id is scoped to reg->btf,
> +				 * so a module-local ID could otherwise alias the
> +				 * vmlinux context type ID.
> +				 */
> +				if (base_type(reg->type) == PTR_TO_BTF_ID &&
> +				    reg->btf == btf_vmlinux &&
> +				    is_trusted_reg(env, reg) &&
> +				    !bpf_type_has_unsafe_modifiers(reg->type)) {
> +					ret = get_kern_ctx_btf_id(&env->log,
> +								  resolve_prog_type(env->prog));
> +					if (ret < 0)
> +						return -EINVAL;
> +					if (reg->btf_id == ret)
> +						break;

[Severity: High]
Does this code allow a PTR_TO_BTF_ID with a non-zero fixed offset to be
passed to the kfunc?

Earlier in check_kfunc_args(), btf_id_fixed_off_ok defaults to true for
KF_ARG_PTR_TO_CTX. When __check_func_arg_reg_off() is called, it permits
the non-zero offset for PTR_TO_BTF_ID. The newly added explicit type check
here then breaks out of argument checking without verifying that
reg->off == 0. Can this allow a user to shift a trusted kernel pointer by
an arbitrary offset before passing it to a kfunc, leading to out-of-bounds
memory reads or writes within the kernel?

[Severity: Medium]
Will this break statement prematurely exit the switch(base_type(kf_arg_type))
block instead of bypassing just the -EINVAL error condition?

If a BPF program calls bpf_cast_to_kern_ctx() and passes a trusted
PTR_TO_BTF_ID that matches the context type, hitting this break statement
completely skips the explicit initialization block of meta->ret_btf_id for
KF_bpf_cast_to_kern_ctx at the bottom of the case KF_ARG_PTR_TO_CTX block:

    if (meta->func_id == special_kfunc_list[KF_bpf_cast_to_kern_ctx]) {
        ret = get_kern_ctx_btf_id(&env->log, resolve_prog_type(env->prog));
        if (ret < 0)
            return -EINVAL;
        meta->ret_btf_id  = ret;
    }
    break;

Does this leave meta->ret_btf_id uninitialized as 0 (void type), corrupting
the verifier's type tracking and causing valid BPF programs to be rejected?

> +				}
> +
>  				verbose(env, "%s expected pointer to ctx, but got %s\n",
>  					reg_arg_name(env, argno), reg_type_str(env, reg->type));
>  				bpf_diag_call_arg_fmt(env, insn_idx, argno, func_name,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-bpf-meta-gated-tracepoints-v1-0-844dbf3e1edf@cloudflare.com?part=3