From: sashiko-bot@kernel.org
To: "Xu Yunxiang" <xyx2021@mail.ustc.edu.cn>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH 6.6.y 2/2] bpf: Invalidate dynptr clones in every call frame on release
Date: Sat, 29 Aug 2026 04:07:12 +0000 [thread overview]
Message-ID: <20260829040712.B1B511F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260829033701.2365648-1-xyx2021@mail.ustc.edu.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Dynptr slices belonging to a cross-frame clone are not invalidated if the subprogram containing the clone returns before the original dynptr is released, leading to a Use-After-Free on ringbuf memory.
--
commit f98ee666f54971a2824f38f254185708f60a777a
Author: Amery Hung <ameryhung@gmail.com>
Date: Sat Aug 29 03:37:01 2026 +0000
bpf: Invalidate dynptr clones in every call frame on release
This commit modifies unmark_stack_slots_dynptr to iterate over all active
call frames rather than just the current frame when invalidating dynptr clones.
It also adds a cross-frame clone regression test.
Link: https://lore.kernel.org/r/20260529014936.2811085-6-ameryhung@gmail.com
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 62fa2895a9205..fa88e7a35f901 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -1026,22 +1026,31 @@ static int unmark_stack_slots_dynptr(struct bpf_verifier_env *env, struct bpf_re
> WARN_ON_ONCE(release_reference(env, ref_obj_id));
> invalidate_slices_of_dynptr(env, state->stack[spi].spilled_ptr.id);
>
> - /* Invalidate any dynptr clones */
> - for (i = 1; i < state->allocated_stack / BPF_REG_SIZE; i++) {
> - if (state->stack[i].spilled_ptr.ref_obj_id != ref_obj_id)
> + /* Invalidate any dynptr clones, including those in other frames.
> + * Do not turn a failing release_reference() into -EINVAL: that
> + * rejects legitimate cross-frame single releases on 6.6/6.12/6.13.
> + */
> + for (frm = 0; frm <= env->cur_state->curframe; frm++) {
[Severity: Critical]
This isn't a bug introduced by this patch, but does this loop restriction fail
to invalidate slices belonging to clones in frames that have already returned?
If a subprogram (Frame 1) clones a ringbuf dynptr, the clone receives a unique
clone->id but shares the original ref_obj_id X. If Frame 1 then creates a slice
from this clone via bpf_dynptr_slice_rdwr, the slice sets dynptr_id = clone->id
but leaves ref_obj_id = 0.
If Frame 1 spills this slice pointer to the caller's (Frame 0) stack and
returns, the clone goes out of scope without an explicit release. When Frame 0
later releases the original dynptr:
release_reference(X) executes, but does not clear the spilled slice because the
slice's ref_obj_id is 0.
unmark_stack_slots_dynptr then executes, but since the subprogram returned,
curframe is 0. The loop only checks Frame 0 and fails to find the clone because
Frame 1's stack is already gone.
Since it never discovers clone->id, invalidate_slices_of_dynptr(clone->id) is
never called. Does this leave the spilled slice on Frame 0's stack fully valid,
allowing an unprivileged BPF program to read or write freed ringbuf memory?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260829032754.2324760-1-xyx2021@mail.ustc.edu.cn?part=2
next prev parent reply other threads:[~2026-08-29 4:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-29 3:27 [PATCH 6.6.y 0/2] bpf: fix dynptr lifetime invalidation on release Xu Yunxiang
2026-08-29 3:36 ` [PATCH 6.6.y 1/2] bpf: Invalidate dynptr slices by dynptr_id " Xu Yunxiang
2026-08-29 3:56 ` sashiko-bot
2026-08-29 3:37 ` [PATCH 6.6.y 2/2] bpf: Invalidate dynptr clones in every call frame " Xu Yunxiang
2026-08-29 4:07 ` sashiko-bot [this message]
2026-09-09 4:28 ` [PATCH bpf 0/2] bpf: Preserve escaped dynptr slice ancestry Xu Yunxiang
2026-09-09 4:28 ` [PATCH bpf 1/2] bpf: Preserve escaped dynptr slice ancestry on subprog return Xu Yunxiang
2026-09-09 5:18 ` bot+bpf-ci
2026-09-09 4:28 ` [PATCH bpf 2/2] selftests/bpf: Test slices escaping a clone call frame Xu Yunxiang
2026-09-09 4:34 ` sashiko-bot
2026-09-09 5:18 ` bot+bpf-ci
2026-08-29 10:26 ` [PATCH 6.6.y v2 0/3] bpf: fix dynptr release handling Xu Yunxiang
2026-08-29 10:26 ` [PATCH 6.6.y v2 1/3] bpf: Invalidate dynptr slices by dynptr_id on release Xu Yunxiang
2026-08-29 10:26 ` [PATCH 6.6.y v2 2/3] bpf: Propagate referenced dynptr release errors Xu Yunxiang
2026-08-29 10:42 ` sashiko-bot
2026-08-29 10:26 ` [PATCH 6.6.y v2 3/3] bpf: Invalidate dynptr clones in every call frame on release Xu Yunxiang
2026-08-30 2:56 ` [PATCH 6.6.y v2 0/3] bpf: fix dynptr release handling Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260829040712.B1B511F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=xyx2021@mail.ustc.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.