Re: [PATCH bpf v2 1/2] bpf: Preserve escaped dynptr slice ancestry on subprog return

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] A subprogram can return or spill a memory slice (PTR_TO_MEM) derived from a local dynptr backed by its own stack frame, leading to a stack Use-After-Free in the caller.
- [Critical] Creating a local dynptr from a referenced dynptr slice via bpf_dynptr_from_mem strips lifetime tracking, allowing use-after-free.
--

commit 670ebab06aaf35b7713f2c4efe3dba56988a2162
Author: Xu Yunxiang <xyx2021@mail.ustc.edu.cn>

bpf: Preserve escaped dynptr slice ancestry on subprog return

Before freeing a callee, reparent surviving PTR_TO_MEM slices of every
dynptr with a parent to that parent. This preserves the lifetime link after
the local dynptr disappears for both reference-owning dynptrs and dynptrs
constructed from referenced objects.

Link: https://lore.kernel.org/r/20260829040712.B1B511F000E9@smtp.kernel.org

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 72a3f5998dd27..ee41b7386f752 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -800,6 +800,39 @@ static int dynptr_ref_cnt(struct bpf_verifier_env *env, int v_parent_id)
>  	return ref_cnt;
>  }
>  
> +static void reparent_dynptr_slices_on_func_exit(struct bpf_verifier_env *env,
> +						struct bpf_func_state *callee)
> +{
> +	struct bpf_verifier_state *vstate = env->cur_state;
> +	struct bpf_func_state *state;
> +	struct bpf_reg_state *reg;
> +	int i;
> +
> +	for (i = 0; i < callee->allocated_stack / BPF_REG_SIZE; i++) {
> +		struct bpf_stack_state *slot = &callee->stack[i];
> +		struct bpf_reg_state *dynptr = &slot->spilled_ptr;
> +
> +		if (slot->slot_type[0] != STACK_DYNPTR ||
> +		    !dynptr->dynptr.first_slot ||
> +		    !dynptr->parent_id)
> +			continue;

[Severity: Critical]
This is a pre-existing issue, but does this logic leave a gap for local
dynptrs backed by a callee's stack frame?

Because local dynptrs have parent_id = 0, they are skipped here. This seems
to allow a subprogram to return or spill a PTR_TO_MEM slice derived from a
local dynptr into the caller's state.

Since prepare_func_exit() only prevents returning PTR_TO_STACK in R0, could a
PTR_TO_MEM alias created via bpf_dynptr_data() escape and allow a stack
use-after-free in the caller?

[ ... ]

[Severity: Critical]
This is also a pre-existing issue, but does bpf_dynptr_from_mem() strip
lifetime tracking when used with referenced dynptr slices?

If a program reserves a ringbuf dynptr, gets a PTR_TO_MEM slice via
bpf_dynptr_data(), and then passes that slice to bpf_dynptr_from_mem():

kernel/bpf/helpers.c:bpf_dynptr_from_mem_proto() {
    ...
    .arg1_type = ARG_PTR_TO_UNINIT_MEM,
    ...
}

kernel/bpf/verifier.c:mark_stack_slots_dynptr() {
    ...
    parent_id = ref_obj->id;
    ...
}

The new dynptr's parent_id is incorrectly assigned 0 because the slice's
parent_id is not propagated. Could the resulting local dynptr be accessed
after the original ringbuf reservation is discarded, leading to a
use-after-free of referenced kernel objects?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910044006.2279547-1-xyx2021@mail.ustc.edu.cn?part=1