From: Yonghong Song <yonghong.song@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v6 07/10] bpf: Enable aggregate return types up to 16 bytes
Date: Mon, 17 Aug 2026 09:12:23 -0700 [thread overview]
Message-ID: <edef89b1-08ad-48b0-ab03-5a80c3ce3940@linux.dev> (raw)
In-Reply-To: <20260817044241.BADD71F000E9@smtp.kernel.org>
On 8/16/26 9:42 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> New issues:
> - [High] Attaching a BPF trampoline to a function returning a 16-byte struct silently corrupts the return value because the trampoline fails to preserve the second return register.
>
> Pre-existing issues:
> - [Medium] Kfuncs returning structs with padding or sizes that are not a multiple of 8 may leak uninitialized kernel memory to BPF programs.
> --
>
> --- Patch [7]: [PATCH bpf-next v6 07/10] bpf: Enable aggregate return types up to 16 bytes ---
> commit 5c9b0fdbdfee0f07315dc190bc0c039af9bce8bd
> Author: Yonghong Song <yonghong.song@linux.dev>
>
> bpf: Enable aggregate return types up to 16 bytes
>
> This commit relaxes the verifier and BTF distillation to accept by-value
> struct or union return types up to 16 bytes. These are returned in the
> R0:R2 register pair.
>
>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>> --- a/kernel/bpf/btf.c
>> +++ b/kernel/bpf/btf.c
>> @@ -7591,7 +7591,7 @@ int btf_distill_func_proto(struct bpf_verifier_log *log,
>> return -EINVAL;
>> }
>> ret = __get_type_size(btf, func->type, &t);
>> - if (ret < 0 || btf_type_is_struct(t)) {
>> + if (ret < 0 || ret > 16) {
> [Severity: High]
> By relaxing this check to allow up to 16-byte returns, does this silently
> break fentry and freplace programs attached to such functions?
>
> While bpf_check_attach_target() rejects programs if they explicitly use the
> trampoline retval:
>
> bpf_check_attach_target() {
> if (tgt_info->fmodel.ret_size > 8 &&
> attach_uses_trampoline_retval(prog->expected_attach_type)) {
> ...
> }
> }
>
> It appears to still allow fentry and freplace programs to attach. When a
> BPF program attaches to a kernel function returning a 16-byte struct, the
> target function returns its value in RAX and RDX (on x86-64).
>
> The BPF trampoline epilogue calls __bpf_tramp_exit(), which clobbers
> caller-saved registers like RDX.
>
> If the trampoline only restores RAX from the stack before returning, won't
> RDX be left with garbage, corrupting the upper 8 bytes of the original
> function's return value?
For fentry, we should be okay as there are no return values.
For freplace, in patch "bpf: Add verifier support for 16-byte returns in R0:R2",
the return value cannot be more than 8 bytes.
So we should be okay here.
>
>> bpf_log(log,
>> "The function %s return type %s is unsupported.\n",
>> tname, btf_type_str(t));
>> [ ... ]
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> [ ... ]
>> @@ -14008,7 +14008,7 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>> * otherwise a pointer field would be laundered into a scalar
>> * and escape provenance and reference tracking.
>> */
>> - if (!__btf_type_is_scalar_struct(env, desc_btf, t, 0)) {
>> + if (!btf_type_is_scalar_struct(env, desc_btf, t, 0)) {
> [Severity: Medium]
> This isn't a bug introduced by this patch, but since the scope of by-value
> returns is expanded from 8 bytes to 16 bytes, it might be worth verifying.
>
> In check_kfunc_call(), the verifier immediately calls mark_kfunc_ret_regs()
> after this check:
>
> check_kfunc_call() {
> if (!btf_type_is_scalar_struct(env, desc_btf, t, 0)) {
> ...
> return -EINVAL;
> }
> mark_kfunc_ret_regs(env, regs, t->size);
> }
>
> If a kfunc returns a struct containing padding bytes, the C compiler might
> leave those padding bytes uninitialized. Since the verifier marks the entire
> return registers as fully initialized scalars, could this allow a BPF
> program to read uninitialized kernel memory via the padding bytes?
This should not be a problem. For kfunc, the return value (if size is less
than 8), the compiler will do proper narrowing.
>
>> verbose(env,
>> "kernel function %s returns %s %s that is not composed of scalars\n",
>> func_name, btf_type_str(t),
next prev parent reply other threads:[~2026-08-17 16:12 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 4:21 [PATCH bpf-next v6 00/10] bpf: Support aggregate return values up to 16 bytes Yonghong Song
2026-08-17 4:21 ` [PATCH bpf-next v6 01/10] bpf: Factor check_global_ret_scalar_reg() out of the global return check Yonghong Song
2026-08-17 4:21 ` [PATCH bpf-next v6 02/10] bpf: Add helpers to describe the R0:R2 return register pair Yonghong Song
2026-08-17 5:17 ` bot+bpf-ci
2026-08-17 15:20 ` Yonghong Song
2026-08-17 4:21 ` [PATCH bpf-next v6 03/10] bpf: Wire up JIT support for 16-byte kfunc returns Yonghong Song
2026-08-17 4:37 ` sashiko-bot
2026-08-17 15:25 ` Yonghong Song
2026-08-17 4:22 ` [PATCH bpf-next v6 04/10] bpf: Handle R2 as a return register in precision backtracking Yonghong Song
2026-08-17 5:17 ` bot+bpf-ci
2026-08-17 15:27 ` Yonghong Song
2026-08-17 4:22 ` [PATCH bpf-next v6 05/10] bpf: Account R2 of register-pair returns in live register analysis Yonghong Song
2026-08-17 4:43 ` sashiko-bot
2026-08-17 15:40 ` Yonghong Song
2026-08-17 4:22 ` [PATCH bpf-next v6 06/10] bpf: Add verifier support for 16-byte returns in R0:R2 Yonghong Song
2026-08-17 4:42 ` sashiko-bot
2026-08-17 15:46 ` Yonghong Song
2026-08-17 5:17 ` bot+bpf-ci
2026-08-17 16:02 ` Yonghong Song
2026-08-17 4:22 ` [PATCH bpf-next v6 07/10] bpf: Enable aggregate return types up to 16 bytes Yonghong Song
2026-08-17 4:42 ` sashiko-bot
2026-08-17 16:12 ` Yonghong Song [this message]
2026-08-17 4:22 ` [PATCH bpf-next v6 08/10] selftests/bpf: Add C tests for 16-byte returns in R0:R2 Yonghong Song
2026-08-17 4:45 ` sashiko-bot
2026-08-17 16:32 ` Yonghong Song
2026-08-17 4:22 ` [PATCH bpf-next v6 09/10] selftests/bpf: Add inline-asm and subprog tests for R0:R2 returns Yonghong Song
2026-08-17 4:42 ` sashiko-bot
2026-08-17 16:53 ` Yonghong Song
2026-08-17 5:17 ` bot+bpf-ci
2026-08-17 17:12 ` Yonghong Song
2026-08-17 4:22 ` [PATCH bpf-next v6 10/10] Documentation/bpf: Document up to 16-byte kfunc return values in R0:R2 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=edef89b1-08ad-48b0-ab03-5a80c3ce3940@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox