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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] check_ptr_to_btf_access() incorrectly allows writes to PTR_UNTRUSTED allocated objects or triggers a verifier_bug WARN_ONCE when reading from them.
--

--- Patch [2]: [PATCH bpf v2 2/2] bpf: Reject untrusted pointers in refcount_acquire ---
commit 80e6c61503b2eee2d4804b0a7ec8927827ed7d92
Author: Ning Ding <dingning04@gmail.com>

bpf: Reject untrusted pointers in refcount_acquire

This commit fixes an issue where a refcounted map kptr could still be passed
to bpf_refcount_acquire() after being marked PTR_UNTRUSTED due to
bpf_rcu_read_unlock(). It updates check_kfunc_args() to reject PTR_UNTRUSTED
arguments for KF_ARG_PTR_TO_REFCOUNTED_KPTR.

Link: https://lore.kernel.org/r/20260726021304.97ED91F000E9@smtp.kernel.org

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 1e7343b625de5..63b1d997fe804 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -12414,6 +12414,11 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
>  			meta->subprogno = reg->subprogno;
>  			break;
>  		case KF_ARG_PTR_TO_REFCOUNTED_KPTR:
> +			if (reg->type & PTR_UNTRUSTED) {
> +				verbose(env, "%s is an untrusted refcounted kptr\n",
> +					reg_arg_name(env, argno));
> +				return -EACCES;
> +			}

[Severity: Critical]
This is a pre-existing issue, but I noticed a similar problem with
PTR_UNTRUSTED handling in check_ptr_to_btf_access() for allocated objects:

kernel/bpf/verifier.c:check_ptr_to_btf_access() {
...
		if (atype != BPF_READ && !type_is_ptr_alloc_obj(reg->type)) {
			verbose(env, "only read is supported\n");
			return -EACCES;
		}

		if (type_is_alloc(reg->type) && !type_is_non_owning_ref(reg->type) &&
		    !(reg->type & MEM_RCU) && !reg_is_referenced(env, reg)) {
			verifier_bug(env, "allocated object must have a referenced id");
			return -EFAULT;
		}
...
}

Does this logic incorrectly allow writes to PTR_UNTRUSTED allocated objects
or trigger a verifier_bug WARN_ONCE when reading from them?

If a program loads a program-allocated kptr containing an RCU-protected field
inside bpf_rcu_read_lock(), the verifier marks it MEM_ALLOC | MEM_RCU (and
NON_OWN_REF if it contains a bpf_rb_node or bpf_list_node). When the program
calls bpf_rcu_read_unlock(), it strips MEM_RCU and adds PTR_UNTRUSTED.

If the program subsequently tries to read or write this pointer,
type_is_ptr_alloc_obj(reg->type) evaluates to true because it ignores
PTR_UNTRUSTED, bypassing the read-only check for writes.

Then, if the pointer lacks NON_OWN_REF, it hits the type_is_alloc() condition
and triggers a verifier_bug(), leading to a BPF_WARN_ONCE. If it has
NON_OWN_REF, it bypasses the verifier_bug() check entirely, and proceeds to
allow a memory write to the untrusted pointer.

Could a malicious BPF program exploit this to achieve a local denial of
service via panic_on_warn or a use-after-free memory write?

>  			if (!type_is_ptr_alloc_obj(reg->type)) {
>  				verbose(env, "%s is neither owning or non-owning ref\n",
>  					reg_arg_name(env, argno));

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260726235030.1152542-1-dingning04@gmail.com?part=2