From: Yonghong Song <yonghong.song@linux.dev>
To: sashiko@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v5 11/16] bpf: Support stack arguments for kfunc calls
Date: Sat, 18 Apr 2026 10:46:08 -0700 [thread overview]
Message-ID: <d316bb8a-0695-4328-8b9b-22271003dc40@linux.dev> (raw)
In-Reply-To: <20260417044047.63861C19425@smtp.kernel.org>
On 4/16/26 9:40 PM, sashiko-bot@kernel.org wrote:
> Sashiko AI review found 3 potential issue(s):
> - [Critical] Precision tracking (`mark_chain_precision`) is incorrectly bypassed or misapplied for kfunc scalar arguments passed via the stack, allowing malicious BPF programs to bypass verifier safety checks through state pruning.
> - [High] `get_kfunc_arg_reg()` fetches lookahead stack arguments without bounds checking, leading to an out-of-bounds memory read or NULL pointer dereference when resolving memory sizes.
> - [High] Overwriting `insn->off` in `bpf_fixup_kfunc_call` destroys the BTF file descriptor index, breaking module kfunc calls on architectures that use JIT far calls.
> --
>
> commit 15b2d48bd7c1080e972b83211cc9794ac2ba763f
> Author: Yonghong Song <yonghong.song@linux.dev>
>
> bpf: Support stack arguments for kfunc calls
>
> Extend the stack argument mechanism to kfunc calls, allowing kfuncs
> with more than 5 parameters to receive additional arguments via the
> r11-based stack arg area.
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 739c3127520c3..a3f307909e401 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
> [ ... ]
>
>> @@ -11653,6 +11659,19 @@ bool bpf_is_kfunc_pkt_changing(struct bpf_kfunc_call_arg_meta *meta)
>> return meta->func_id == special_kfunc_list[KF_bpf_xdp_pull_data];
>> }
>>
>> +static struct bpf_reg_state *get_kfunc_arg_reg(struct bpf_verifier_env *env, int argno)
>> +{
>> + struct bpf_func_state *caller;
>> + int spi;
>> +
>> + if (argno < MAX_BPF_FUNC_REG_ARGS)
>> + return &cur_regs(env)[argno + 1];
>> +
>> + caller = cur_func(env);
>> + spi = out_arg_spi(caller, argno - MAX_BPF_FUNC_REG_ARGS);
>> + return &caller->stack_arg_regs[spi];
>> +}
> Does get_kfunc_arg_reg() need to verify that spi is within bounds and the
> stack slot is initialized?
The checking is below:
static bool is_stack_arg_slot_initialized(struct bpf_func_state *state, int spi)
{
if (spi >= (int)(state->stack_arg_depth / BPF_REG_SIZE))
return false;
return state->stack_arg_regs[spi].type != NOT_INIT;
}
if (i < MAX_BPF_FUNC_REG_ARGS) {
reg = ®s[i + 1];
} else {
/* Retrieve the reg state from the outgoing stack arg slot. */
struct bpf_func_state *caller = cur_func(env);
int spi = out_arg_spi(caller, i - MAX_BPF_FUNC_REG_ARGS);
if (!is_stack_arg_slot_initialized(caller, spi)) {
verbose(env, "stack %s not properly initialized\n",
reg_arg_name(env, argno));
return -EINVAL;
}
tmp_reg = caller->stack_arg_regs[spi];
reg = &tmp_reg;
regno = -1;
}
spi has to be valid. Otherwise, verification will fail.
>
> When verifying pointer arguments that have a trailing size argument
> (KF_ARG_PTR_TO_MEM_SIZE), the verifier looks ahead at argno + 1. If a BPF
> program maliciously omits the stack size argument, could spi exceed
> caller->stack_arg_depth and lead to an out-of-bounds memory read?
If the bpf program maliciously omits the stack size argument,
btf_check_func_arg_match() should catch this and reject the program.
>
> [ ... ]
>
>> @@ -12394,9 +12435,11 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
>> reg_arg_name(env, argno));
>> return -EINVAL;
>> }
>> - ret = mark_chain_precision(env, regno);
>> - if (ret < 0)
>> - return ret;
>> + if (regno > 0) {
>> + ret = mark_chain_precision(env, regno);
>> + if (ret < 0)
>> + return ret;
>> + }
> Stack arguments use regno = -1, so it seems mark_chain_precision() is bypassed
> for scalar constants and size arguments passed on the stack.
>
> If precision tracking is bypassed, could the verifier's state equivalence logic
> consider states with different scalar values in these stack slots as equivalent
> and incorrectly prune them?
In this particular case, we know reg is a known constant, we can do
reg->precise = true.
Will fix.
>
> [ ... ]
>
>> @@ -20145,6 +20209,16 @@ int bpf_fixup_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>> if (!bpf_jit_supports_far_kfunc_call())
>> insn->imm = BPF_CALL_IMM(desc->addr);
>>
>> + /*
>> + * After resolving the kfunc address, insn->off is no longer needed
>> + * for BTF fd index. Repurpose it to store the number of stack args
>> + * so the JIT can marshal them.
>> + */
>> + if (desc->func_model.nr_args > MAX_BPF_FUNC_REG_ARGS)
>> + insn->off = desc->func_model.nr_args - MAX_BPF_FUNC_REG_ARGS;
>> + else
>> + insn->off = 0;
> For architectures where bpf_jit_supports_far_kfunc_call() returns true
> (such as s390x, loongarch, and powerpc), they resolve the address later
> using bpf_get_kfunc_addr(), which requires the BTF file descriptor index
> stored in insn->off.
>
> If insn->off is overwritten here, could it destroy the BTF file descriptor
> index and break module kfunc calls during JIT compilation?
>
The JIT implementation has changed and the above is dead code. Will remove.
next prev parent reply other threads:[~2026-04-18 17:46 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 3:46 [PATCH bpf-next v5 00/16] bpf: Support stack arguments for BPF functions and kfuncs Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 01/16] bpf: Remove unused parameter from check_map_kptr_access() Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 02/16] bpf: Refactor to avoid redundant calculation of bpf_reg_state Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 03/16] bpf: Refactor to handle memory and size together Yonghong Song
2026-04-17 4:49 ` sashiko-bot
2026-04-18 16:40 ` Yonghong Song
2026-04-18 0:52 ` bot+bpf-ci
2026-04-18 16:47 ` Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 04/16] bpf: Prepare verifier logs for upcoming kfunc stack arguments Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 05/16] bpf: Introduce bpf register BPF_REG_PARAMS Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 06/16] bpf: Limit the scope of BPF_REG_PARAMS usage Yonghong Song
2026-04-17 4:30 ` bot+bpf-ci
2026-04-18 16:48 ` Yonghong Song
2026-04-17 4:50 ` sashiko-bot
2026-04-18 16:50 ` Yonghong Song
2026-04-18 1:04 ` bot+bpf-ci
2026-04-18 16:54 ` Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 07/16] bpf: Reuse MAX_BPF_FUNC_ARGS for maximum number of arguments Yonghong Song
2026-04-17 4:30 ` bot+bpf-ci
2026-04-18 17:00 ` Yonghong Song
2026-04-18 0:52 ` bot+bpf-ci
2026-04-18 17:03 ` Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 08/16] bpf: Support stack arguments for bpf functions Yonghong Song
2026-04-17 4:35 ` sashiko-bot
2026-04-18 17:10 ` Yonghong Song
2026-04-17 4:43 ` bot+bpf-ci
2026-04-18 17:11 ` Yonghong Song
2026-04-18 1:04 ` bot+bpf-ci
2026-04-17 3:47 ` [PATCH bpf-next v5 09/16] bpf: Reject stack arguments in non-JITed programs Yonghong Song
2026-04-17 4:30 ` bot+bpf-ci
2026-04-18 17:17 ` Yonghong Song
2026-04-18 0:52 ` bot+bpf-ci
2026-04-17 3:47 ` [PATCH bpf-next v5 10/16] bpf: Reject stack arguments if tail call reachable Yonghong Song
2026-04-17 4:08 ` sashiko-bot
2026-04-18 17:18 ` Yonghong Song
2026-04-18 17:37 ` Yonghong Song
2026-04-17 4:30 ` bot+bpf-ci
2026-04-18 1:04 ` bot+bpf-ci
2026-04-18 17:24 ` Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 11/16] bpf: Support stack arguments for kfunc calls Yonghong Song
2026-04-17 4:40 ` sashiko-bot
2026-04-18 17:46 ` Yonghong Song [this message]
2026-04-17 4:43 ` bot+bpf-ci
2026-04-18 17:57 ` Yonghong Song
2026-04-18 1:04 ` bot+bpf-ci
2026-04-18 18:04 ` Yonghong Song
2026-04-17 3:47 ` [PATCH bpf-next v5 12/16] bpf: Enable stack argument support for x86_64 Yonghong Song
2026-04-17 4:30 ` bot+bpf-ci
2026-04-17 5:03 ` sashiko-bot
2026-04-18 18:07 ` Yonghong Song
2026-04-18 1:04 ` bot+bpf-ci
2026-04-17 3:48 ` [PATCH bpf-next v5 13/16] bpf,x86: Implement JIT support for stack arguments Yonghong Song
2026-04-17 4:44 ` sashiko-bot
2026-04-18 16:43 ` Puranjay Mohan
2026-04-18 18:15 ` Yonghong Song
2026-04-18 1:20 ` bot+bpf-ci
2026-04-18 18:23 ` Yonghong Song
2026-04-17 3:48 ` [PATCH bpf-next v5 14/16] selftests/bpf: Add tests for BPF function " Yonghong Song
2026-04-17 4:20 ` sashiko-bot
2026-04-18 0:52 ` bot+bpf-ci
2026-04-18 18:26 ` Yonghong Song
2026-04-17 3:48 ` [PATCH bpf-next v5 15/16] selftests/bpf: Add negative test for greater-than-8-byte kfunc stack argument Yonghong Song
2026-04-17 4:28 ` sashiko-bot
2026-04-18 18:29 ` Yonghong Song
2026-04-18 0:52 ` bot+bpf-ci
2026-04-17 3:48 ` [PATCH bpf-next v5 16/16] selftests/bpf: Add verifier tests for stack argument validation Yonghong Song
2026-04-17 4:38 ` sashiko-bot
2026-04-18 18:36 ` Yonghong Song
2026-04-18 0:52 ` bot+bpf-ci
2026-04-18 16:39 ` [PATCH bpf-next v5 00/16] bpf: Support stack arguments for BPF functions and kfuncs Puranjay Mohan
2026-04-18 18:47 ` Alexei Starovoitov
2026-04-18 18:54 ` Yonghong Song
2026-04-18 17:06 ` Puranjay Mohan
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=d316bb8a-0695-4328-8b9b-22271003dc40@linux.dev \
--to=yonghong.song@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=sashiko@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox