From: Yonghong Song <yonghong.song@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v7 07/22] bpf: Resume a covered call at its landing pad
Date: Tue, 29 Sep 2026 17:28:26 -0700 [thread overview]
Message-ID: <5c4797c6-8fdb-4072-a134-31784b8e8481@linux.dev> (raw)
In-Reply-To: <20260929003106.3A0211F00893@smtp.kernel.org>
On 9/28/26 5:31 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Critical] bpf: landing pad state desync via discarded memory mutations allows OOB access
> --
>
> commit 41b3c5e14924fae7175095b7012838a14c2e5ffc
> Author: Yonghong Song <yonghong.song@linux.dev>
>
> bpf: Resume a covered call at its landing pad
>
> This commit allows a covered call to resume at its landing pad when bpf_unwind()
> is invoked by a subprogram. It pushes a cleanup pad branch with the caller's
> pre-call state and handles bpf_unwind() by returning PROCESS_BPF_EXIT for
> nested frames.
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index fc3df452de2e4..ee074d4a936b5 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
> [ ... ]
>
>> @@ -19167,6 +19186,57 @@ enum {
>> INSN_IDX_UPDATED = 2,
>> };
>>
>> +static int push_cleanup_pad_branch(struct bpf_verifier_env *env, int insn_idx)
>> +{
>> + struct bpf_verifier_state *branch;
>> + struct bpf_func_state *frame;
>> + int pad = bpf_exc_pad_of_call(env, insn_idx);
>> +
>> + if (pad < 0)
>> + return 0;
>> + branch = push_stack(env, pad, insn_idx, false);
>> + if (IS_ERR(branch))
>> + return PTR_ERR(branch);
>> + frame = branch->frame[branch->curframe];
>> + /*
>> + * The state at that call with the caller-saved registers gone: the
>> + * callee's epilogue put r6-r9 and the stack back on the way out.
>> + */
>> + clear_caller_saved_regs(env, frame->regs);
>> + mark_reg_unknown(env, frame->regs, BPF_REG_0);
>> + return 0;
>> +}
>> +
>> +static int process_bpf_unwind(struct bpf_verifier_env *env, int *insn_idx,
>> + bool *do_print_state)
>> +{
>> + struct bpf_func_state *frame = cur_func(env);
>> + int pad = bpf_exc_pad_of_call(env, *insn_idx);
>> + int err;
>> +
>> + if (pad < 0) {
>> + err = check_resource_leak(env, false, !env->cur_state->curframe,
>> + "an unwind with no landing pad");
>> + if (err)
>> + return err;
>> + if (env->cur_state->curframe)
>> + return PROCESS_BPF_EXIT;
> [Severity: Critical]
> When process_bpf_unwind() returns PROCESS_BPF_EXIT here, the verifier stops
> exploring the callee and discards its state. Does this discard any memory
> mutations made by the callee to pointer arguments before calling bpf_unwind()?
You are right. It is my mistake. The key problem is here (in v7):
+static int push_cleanup_pad_branch(struct bpf_verifier_env *env, int insn_idx)
+{
+ struct bpf_verifier_state *branch;
+ struct bpf_func_state *frame;
+ int pad = bpf_exc_pad_of_call(env, insn_idx);
+
+ if (pad < 0)
+ return 0;
+ branch = push_stack(env, pad, insn_idx, false);
+ if (IS_ERR(branch))
+ return PTR_ERR(branch);
+ frame = branch->frame[branch->curframe];
+ /*
+ * The state at that call with the caller-saved registers gone: the
+ * callee's epilogue put r6-r9 and the stack back on the way out.
+ */
+ clear_caller_saved_regs(env, frame->regs);
+ mark_reg_unknown(env, frame->regs, BPF_REG_0);
+ return 0;
+}
esp.
branch = push_stack(env, pad, insn_idx, false);
it ignored the state change in callee, e.g., a value in stack
may get changed. This will make verification incorrect due to
such changed value.
>
> Since the CPU unwinds the stack without undoing memory writes at runtime,
> could this desynchronize the verifier state from runtime state and allow
> out-of-bounds memory accesses?
Yes, see the above.
>
>> + /*
>> + * The main program's frame returns at once, which is the
>> + * program returning. Mark r0 the zero the fixups leave after
>> + * the call, and leave through the exit, which is what holds
>> + * that zero to the program type.
>> + */
>> + mark_reg_unknown(env, cur_regs(env), BPF_REG_0);
>> + mark_reg_known_zero(env, cur_regs(env), BPF_REG_0);
>> + return process_bpf_exit_full(env, do_print_state, false);
>> + }
>> + clear_caller_saved_regs(env, frame->regs);
>> + mark_reg_unknown(env, frame->regs, BPF_REG_0);
>> + *insn_idx = pad;
>> + return INSN_IDX_UPDATED;
>> +}
>> +
> [ ... ]
>
>> @@ -19421,7 +19491,29 @@ static int do_check_insn(struct bpf_verifier_env *env, bool *do_print_state)
>> return -EINVAL;
>> }
>> }
>> + if (bpf_is_unwind_kfunc(insn) || bpf_is_unwind_resume_kfunc(insn)) {
>> + err = check_kfunc_allowed_only(env, insn, env->insn_idx);
>> + if (err)
>> + return err;
>> + if (bpf_is_unwind_kfunc(insn))
>> + return process_bpf_unwind(env, &env->insn_idx,
>> + do_print_state);
>> + /*
>> + * Mark r0 a known zero -- unknown first, as
>> + * the known-zero helper keeps the type it
>> + * finds, which here is NOT_INIT. The fixups
>> + * lower this to 'r0 = 0; exit', so the frame
>> + * returns a real zero.
>> + */
>> + mark_reg_unknown(env, cur_regs(env), BPF_REG_0);
>> + mark_reg_known_zero(env, cur_regs(env), BPF_REG_0);
>> + return process_bpf_exit_full(env, do_print_state, false);
>> + }
>> mark_reg_scratched(env, BPF_REG_0);
>> + /* An unwind out of this call resumes at the pad. */
>> + err = push_cleanup_pad_branch(env, env->insn_idx);
>> + if (err)
>> + return err;
> [Severity: Critical]
> push_cleanup_pad_branch() pushes a branch using a snapshot of the pre-call
> state. If the callee modified a stack variable (e.g., an array index) and then
> unwound the stack, does the verifier evaluate the landing pad with the original
> unmodified value?
>
> Could a BPF program use this to bypass bounds checks by mutating an index in
> the callee before unwinding, causing the verifier to optimize out the checks
> in the landing pad while using the out-of-bounds value at runtime?
You are right. See the above explanation. Will fix.
>
>> if (bpf_in_stack_arg_cnt(&env->subprog_info[cur_func(env)->subprogno]))
>> cur_func(env)->no_stack_arg_load = true;
>> if (bpf_is_callx(insn))
next prev parent reply other threads:[~2026-09-30 0:28 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 0:16 [PATCH bpf-next v7 00/22] bpf: Run exception cleanup landing pads when bpf_unwind() unwinds Yonghong Song
2026-09-29 0:16 ` [PATCH bpf-next v7 01/22] bpf: Pack bpf_insn_aux_data flags into bit fields Yonghong Song
2026-09-29 0:16 ` [PATCH bpf-next v7 02/22] bpf: Accept the compiler's exception cleanup table at program load Yonghong Song
2026-09-29 0:16 ` [PATCH bpf-next v7 03/22] bpf: Add the bpf_unwind() and bpf_unwind_resume() kfuncs Yonghong Song
2026-09-29 0:16 ` [PATCH bpf-next v7 04/22] bpf: Add lookups for exception cleanup resumes and landing pads Yonghong Song
2026-09-29 0:33 ` sashiko-bot
2026-09-29 21:58 ` Yonghong Song
2026-09-29 0:16 ` [PATCH bpf-next v7 05/22] bpf: Prepare for an exception cleanup table before the CFG walk Yonghong Song
2026-09-29 0:31 ` sashiko-bot
2026-09-29 22:04 ` Yonghong Song
2026-09-29 0:16 ` [PATCH bpf-next v7 06/22] bpf: Make exception landing pads reachable in the CFG Yonghong Song
2026-09-29 0:16 ` [PATCH bpf-next v7 07/22] bpf: Resume a covered call at its landing pad Yonghong Song
2026-09-29 0:31 ` sashiko-bot
2026-09-30 0:28 ` Yonghong Song [this message]
2026-09-29 0:16 ` [PATCH bpf-next v7 08/22] bpf: Require an unwind to leave a frame holding what it entered with Yonghong Song
2026-09-29 0:36 ` sashiko-bot
2026-09-30 1:09 ` Yonghong Song
2026-09-29 0:52 ` bot+bpf-ci
2026-09-30 1:10 ` Yonghong Song
2026-09-29 0:16 ` [PATCH bpf-next v7 09/22] bpf: Refuse a landing pad that does not resume Yonghong Song
2026-09-29 0:16 ` [PATCH bpf-next v7 10/22] bpf: Refuse a private stack for a program that can unwind Yonghong Song
2026-09-29 0:16 ` [PATCH bpf-next v7 11/22] bpf: Dispatch cleanup pads by rewriting return addresses Yonghong Song
2026-09-29 1:14 ` bot+bpf-ci
2026-09-30 1:18 ` Yonghong Song
2026-09-29 0:17 ` [PATCH bpf-next v7 12/22] bpf, x86: Dispatch exception cleanup pads at run time Yonghong Song
2026-09-29 0:30 ` sashiko-bot
2026-09-30 1:34 ` Yonghong Song
2026-09-29 0:17 ` [PATCH bpf-next v7 13/22] bpf, arm64: " Yonghong Song
2026-09-29 1:14 ` bot+bpf-ci
2026-09-29 0:17 ` [PATCH bpf-next v7 14/22] libbpf: Resolve the compiler's _Unwind_Resume to the kernel's kfunc Yonghong Song
2026-09-29 0:17 ` [PATCH bpf-next v7 15/22] libbpf: Add cleanup_info to bpf_prog_load_opts Yonghong Song
2026-09-29 0:17 ` [PATCH bpf-next v7 16/22] libbpf: Collect .bpf_cleanup records and pass them to the kernel Yonghong Song
2026-09-29 0:17 ` [PATCH bpf-next v7 17/22] libbpf: Carry the exception cleanup table through the light skeleton Yonghong Song
2026-09-29 0:17 ` [PATCH bpf-next v7 18/22] libbpf: Let the static linker carry .bpf_cleanup relocations Yonghong Song
2026-09-29 0:17 ` [PATCH bpf-next v7 19/22] selftests/bpf: Add end-to-end and negative .bpf_cleanup exception tests Yonghong Song
2026-09-29 0:52 ` bot+bpf-ci
2026-09-30 1:42 ` Yonghong Song
2026-09-29 0:17 ` [PATCH bpf-next v7 20/22] selftests/bpf: Add __set_global() and __ret_global() test tags Yonghong Song
2026-09-29 0:52 ` bot+bpf-ci
2026-09-30 1:46 ` Yonghong Song
2026-09-29 0:17 ` [PATCH bpf-next v7 21/22] selftests/bpf: Cover more accepted .bpf_cleanup exception shapes Yonghong Song
2026-09-29 0:52 ` bot+bpf-ci
2026-09-30 2:19 ` Yonghong Song
2026-09-29 0:17 ` [PATCH bpf-next v7 22/22] selftests/bpf: Load an exception cleanup program from a light skeleton Yonghong Song
2026-09-29 0:52 ` bot+bpf-ci
2026-09-30 3:12 ` Yonghong Song
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=5c4797c6-8fdb-4072-a134-31784b8e8481@linux.dev \
--to=yonghong.song@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.