From: Yonghong Song <yonghong.song@linux.dev>
To: sashiko@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v5 12/16] bpf: Enable stack argument support for x86_64
Date: Sat, 18 Apr 2026 11:07:53 -0700 [thread overview]
Message-ID: <22ab7b8e-73ad-4675-959d-d4d6801954f2@linux.dev> (raw)
In-Reply-To: <20260417050346.F2E3FC19425@smtp.kernel.org>
On 4/16/26 10:03 PM, sashiko-bot@kernel.org wrote:
> Sashiko AI review found 1 potential issue(s):
> - [High] Enabling `bpf_jit_supports_stack_args()` for x86_64 without the corresponding JIT implementation introduces a bisection-breaking regression that can lead to arbitrary kernel memory writes and ABI violations.
> --
>
> commit b40feee41e4472d0e27be38b4c99c940abe3c1ba
> Author: Yonghong Song <yonghong.song@linux.dev>
>
> bpf: Enable stack argument support for x86_64
>
> This commit enables stack argument support for the x86_64 JIT and verifier
> to allow BPF programs and kfuncs to use more than 5 arguments.
>
>> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
>> index e9b78040d703e..32864dbc2c4e8 100644
>> --- a/arch/x86/net/bpf_jit_comp.c
>> +++ b/arch/x86/net/bpf_jit_comp.c
>> @@ -3937,6 +3937,11 @@ bool bpf_jit_supports_kfunc_call(void)
>> return true;
>> }
>>
>> +bool bpf_jit_supports_stack_args(void)
>> +{
>> + return true;
>> +}
>> +
> Does enabling this without the actual JIT implementation break bisection?
>
> If bpf_jit_supports_stack_args() returns true, the verifier will allow
> instructions using BPF_REG_PARAMS (register 11) to handle stack arguments.
> However, since the JIT support isn't implemented in this commit,
> BPF_REG_PARAMS is not yet defined in the JIT's reg2hex array.
>
> Could this cause reg2hex[11] to implicitly default to 0, which maps to
> RAX (BPF_REG_0)? If the verifier emits instructions using BPF_REG_PARAMS,
> the x86 JIT might miscompile them using RAX as the base register, potentially
> allowing an arbitrary kernel memory write since R0 is controllable by the
> BPF program.
>
> Additionally, it appears kfunc calls with >5 arguments won't have their
> arguments correctly marshaled to the System V ABI (like moving the 6th
> argument to R9), which could lead to reading uninitialized garbage from
> registers and the stack.
>
> I see the JIT implementation is added later in the series in commit
> 41dcf99330b6b ("bpf,x86: Implement JIT support for stack arguments").
> Should the JIT implementation be merged before or in the same patch as
> this feature enablement to maintain bisection?
Good point. Will enable stack args in JIT patch.
>
> [ ... ]
>
parent reply other threads:[~2026-04-18 18:08 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20260417050346.F2E3FC19425@smtp.kernel.org>]
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=22ab7b8e-73ad-4675-959d-d4d6801954f2@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