From: sashiko-bot@kernel.org
To: "Yonghong Song" <yonghong.song@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 03/12] bpf: Support by-value struct arguments up to 16 bytes
Date: Fri, 04 Sep 2026 05:23:04 +0000 [thread overview]
Message-ID: <20260904052304.9AB2C1F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260904051013.3978240-1-yonghong.song@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Out-of-bounds array write in `btf_prepare_func_args` when an argument passed by value requires multiple slots, overflowing the `sub->args` array.
--
commit d1c6556d5925344f81e73a6b534000285b7cee65
Author: Yonghong Song <yonghong.song@linux.dev>
bpf: Support by-value struct arguments up to 16 bytes
This commit adds support for passing struct arguments up to 16 bytes by value
to global BPF functions. The arguments are split into multiple register slots
based on their size.
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 22828b489b778..dbd64cee1b27a 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -8103,6 +8103,14 @@ int btf_prepare_func_args(struct bpf_verifier_env *env, int subprog)
> for (i = 0, slots_used = 0; i < nargs; i++) {
> u32 tags = 0;
>
> + if (slots_used >= MAX_BPF_FUNC_ARGS) {
> + if (!is_global)
> + return -EINVAL;
> + bpf_log(log, "Arguments of %s() need more than %d argument slots\n",
> + tname, MAX_BPF_FUNC_ARGS);
> + return -EINVAL;
> + }
> +
[ ... ]
> @@ -8231,6 +8239,31 @@ int btf_prepare_func_args(struct bpf_verifier_env *env, int subprog)
> sub->args[slots_used++].arg_type = ARG_ANYTHING;
> continue;
> }
> + if (btf_type_is_struct(t)) {
> + u32 nslots;
> +
> + if (!t->size || t->size > 2 * BPF_REG_SIZE) {
> + if (!is_global)
> + return -EINVAL;
> + bpf_log(log,
> + "Arg#%d type %s in %s() has size %u, only 1 to %d bytes "
> + "can be passed by value\n",
> + i, btf_type_str(t), tname, t->size, 2 * BPF_REG_SIZE);
> + return -EINVAL;
> + }
> + if (!btf_struct_is_composed_of(env, btf, t, BTF_MEMBER_SCALAR)) {
> + if (!is_global)
> + return -EINVAL;
> + bpf_log(log, "Arg#%d type %s in %s() is not composed of scalars\n",
> + i, btf_type_str(t), tname);
> + return -EINVAL;
> + }
> +
> + nslots = (t->size + BPF_REG_SIZE - 1) / BPF_REG_SIZE;
> + while (nslots--)
> + sub->args[slots_used++].arg_type = ARG_ANYTHING;
[Severity: High]
Can this loop write out-of-bounds of the sub->args[] array?
The bounds check for slots_used is only performed at the beginning of the
outer for-loop in btf_prepare_func_args(). If a function argument is evaluated
when slots_used is exactly MAX_BPF_FUNC_ARGS - 1, and this argument is a
16-byte struct requiring 2 slots (nslots = 2), the inner while loop will
increment slots_used twice.
This will cause an out-of-bounds write when setting arg_type for the second
slot.
Since struct bpf_subprog_info defines args as having exactly
MAX_BPF_FUNC_ARGS elements, writing past the end will corrupt adjacent
memory fields like stack_arg_cnt.
Should the code verify if slots_used + nslots > MAX_BPF_FUNC_ARGS before
entering this loop?
> + continue;
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904050957.3976119-1-yonghong.song@linux.dev?part=3
next prev parent reply other threads:[~2026-09-04 5:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 5:09 [PATCH bpf-next 00/12] bpf: Support by-value struct and __int128 arguments Yonghong Song
2026-09-04 5:10 ` [PATCH bpf-next 01/12] selftests/bpf: Add a test for an __int128 by-value argument Yonghong Song
2026-09-04 5:10 ` [PATCH bpf-next 02/12] bpf: Index global function arguments by argument slot Yonghong Song
2026-09-04 5:10 ` [PATCH bpf-next 03/12] bpf: Support by-value struct arguments up to 16 bytes Yonghong Song
2026-09-04 5:23 ` sashiko-bot [this message]
2026-09-04 6:09 ` bot+bpf-ci
2026-09-04 5:10 ` [PATCH bpf-next 04/12] bpf: Support __int128 as a by-value function argument Yonghong Song
2026-09-04 5:32 ` sashiko-bot
2026-09-04 6:09 ` bot+bpf-ci
2026-09-04 5:10 ` [PATCH bpf-next 05/12] bpf: Support by-value struct and __int128 kfunc arguments Yonghong Song
2026-09-04 6:18 ` sashiko-bot
2026-09-04 6:24 ` bot+bpf-ci
2026-09-04 5:10 ` [PATCH bpf-next 06/12] bpf: Add a JIT helper for the outgoing stack of kfunc calls Yonghong Song
2026-09-04 5:25 ` sashiko-bot
2026-09-04 5:10 ` [PATCH bpf-next 07/12] bpf, x86: Place kfunc arguments per the SysV calling convention Yonghong Song
2026-09-04 5:36 ` sashiko-bot
2026-09-04 23:58 ` Alexei Starovoitov
2026-09-04 5:10 ` [PATCH bpf-next 08/12] bpf: Record a 16-byte argument alignment in the function model Yonghong Song
2026-09-04 6:09 ` bot+bpf-ci
2026-09-04 5:10 ` [PATCH bpf-next 09/12] bpf, arm64: Place kfunc arguments per AAPCS64 Yonghong Song
2026-09-04 6:09 ` bot+bpf-ci
2026-09-04 5:10 ` [PATCH bpf-next 10/12] selftests/bpf: Add C tests for by-value arguments up to 16 bytes Yonghong Song
2026-09-04 5:19 ` sashiko-bot
2026-09-04 6:09 ` bot+bpf-ci
2026-09-04 5:10 ` [PATCH bpf-next 11/12] selftests/bpf: Add inline-asm tests for by-value arguments Yonghong Song
2026-09-04 6:09 ` bot+bpf-ci
2026-09-04 5:11 ` [PATCH bpf-next 12/12] selftests/bpf: Add tests for by-value kfunc arguments 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=20260904052304.9AB2C1F00A3E@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@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