Re: [PATCH bpf] bpf: Keep refcount_acquire nullable for borrowed RCU kptrs

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] bpf_refcount_acquire() permits untrusted pointers due to inadequate modifier checks, leading to Use-After-Free.
--

--- Patch [1]: [PATCH bpf] bpf: Keep refcount_acquire nullable for borrowed RCU kptrs ---
commit 5798e6cddf6ec01af2fa26e9f86dfc1bb3fd1681
Author: Ning Ding <dingning04@gmail.com>

bpf: Keep refcount_acquire nullable for borrowed RCU kptrs
    
bpf_refcount_acquire() can fail for a refcounted map kptr loaded
within RCU. Another execution can replace the map kptr and drop the
last owning reference after the pointer is loaded but before the
acquire, causing refcount_inc_not_zero() to fail.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 7aa47342dc659..1e7343b625de5 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -12419,7 +12419,7 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
>  					reg_arg_name(env, argno));
>  				return -EINVAL;
>  			}

[Severity: Critical]
This is a pre-existing issue, but does bpf_refcount_acquire() permit untrusted
pointers due to inadequate modifier checks, potentially leading to a
use-after-free?

In check_kfunc_args(), KF_ARG_PTR_TO_REFCOUNTED_KPTR skips the is_trusted_reg()
checks that are applied to other pointer types. The argument is subsequently
validated using type_is_ptr_alloc_obj():

include/linux/bpf_verifier.h:type_is_ptr_alloc_obj() {
    return base_type(type) == PTR_TO_BTF_ID && type_flag(type) & MEM_ALLOC;
}

Since type_is_ptr_alloc_obj() only requires MEM_ALLOC to be set and does not
restrict unsafe modifiers, it returns true for a pointer with the PTR_UNTRUSTED
flag.

If a BPF program loads a refcounted pointer from a map inside an RCU read-side
critical section, checks it for NULL, and then drops the RCU lock using
bpf_rcu_read_unlock(), the pointer's verifier type is updated to include the
PTR_UNTRUSTED flag.

The program can then pass this untrusted pointer to bpf_refcount_acquire(),
which bypasses trusted register checks and accepts it. At runtime, the
bpf_refcount_acquire_impl kfunc executes refcount_inc_not_zero() on the
provided untrusted address.

Since the address might have already been freed outside the RCU critical
section, could this result in memory corruption or a kernel panic? While this
patch sets meta->arg_owning_ref = false for untrusted inputs, does it fail to
prevent the unsafe input pointer from being dereferenced inside the kfunc
itself?

> -			if (!type_is_non_owning_ref(reg->type))
> +			if (!type_is_non_owning_ref(reg->type) && reg_is_referenced(env, reg))
>  				meta->arg_owning_ref = true;
>  
>  			rec = reg_btf_record(reg);

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