public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yonghong Song" <yonghong.song@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v5 11/16] bpf: Support stack arguments for kfunc calls
Date: Fri, 17 Apr 2026 04:40:46 +0000	[thread overview]
Message-ID: <20260417044047.63861C19425@smtp.kernel.org> (raw)
In-Reply-To: <20260417034754.2630932-1-yonghong.song@linux.dev>

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?

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?

[ ... ]

> @@ -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?

[ ... ]

> @@ -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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260417034658.2625353-1-yonghong.song@linux.dev?part=11

  reply	other threads:[~2026-04-17  4:40 UTC|newest]

Thread overview: 45+ 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  0:52   ` bot+bpf-ci
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-17  4:50   ` sashiko-bot
2026-04-18  1:04   ` bot+bpf-ci
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  0:52   ` bot+bpf-ci
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-17  4:43   ` bot+bpf-ci
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  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-17  4:30   ` bot+bpf-ci
2026-04-18  1:04   ` bot+bpf-ci
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 [this message]
2026-04-17  4:43   ` bot+bpf-ci
2026-04-18  1:04   ` bot+bpf-ci
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  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-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-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  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  0:52   ` bot+bpf-ci

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=20260417044047.63861C19425@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko@lists.linux.dev \
    --cc=yonghong.song@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