From: Yonghong Song <yonghong.song@linux.dev>
To: Amery Hung <ameryhung@gmail.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
"Jose E . Marchesi" <jose.marchesi@oracle.com>,
kernel-team@fb.com, Martin KaFai Lau <martin.lau@kernel.org>
Subject: Re: [PATCH bpf-next v4 10/18] bpf: Fix interaction between stack argument PTR_TO_STACK and dead slot poisoning
Date: Thu, 16 Apr 2026 07:21:11 -0700 [thread overview]
Message-ID: <06642779-578a-4d79-b687-080ad8f96791@linux.dev> (raw)
In-Reply-To: <CAMB2axPoszkZqHYh8g3bH0V-c4-BzLX3ywSsF0fFyQOmN0Vp5Q@mail.gmail.com>
On 4/15/26 3:32 PM, Amery Hung wrote:
> On Sat, Apr 11, 2026 at 10:01 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>> The "poison dead stack slots" mechanism (commit 2cb27158adb3) uses
>> static liveness analysis to identify dead stack slots and poisons them
>> as a safety check. However, the static liveness pass cannot track
>> indirect stack references through pointers passed via stack arguments.
>>
>> For register-passed PTR_TO_STACK (e.g., R1 = fp-8 passed to a static
>> subprog), the liveness abstract tracker carries frame/offset info
>> through registers. When the callee dereferences R1, the tracker
>> attributes the read to the parent frame's stack slot, correctly marking
>> it alive. So no poisoning issue arises.
>>
>> For stack-argument-passed PTR_TO_STACK (e.g., fp-8 stored via
>> *(r12-8) = r1), the value goes through BPF_REG_STACK_ARG_BASE (r12)
>> which the liveness pass does not track. When the callee loads the
>> pointer from its incoming stack arg and dereferences it, the liveness
>> pass cannot attribute the read back to the parent frame. The parent's
>> stack slot is determined dead and poisoned before the callee even
>> starts. The callee's subsequent dereference then fails with "slot
>> poisoned by dead code elimination".
>>
>> Fix this by allowing STACK_POISON reads in check_stack_read_fixed_off()
>> when the read targets a parent frame's stack (reg_state != state).
>> Same-frame STACK_POISON reads remain rejected to preserve the safety
>> check for real liveness bugs. Cross-frame reads are safe to allow
>> because:
>> - The pointer to the parent's stack was already validated by the
>> verifier.
>> - The slot contained valid data before being (incorrectly) poisoned.
>> - The read returns an unknown scalar, which is conservative.
>>
>> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
>> ---
> While liveness of stack arg handled differently, can R12 base
> arguments cause some OOB in liveness.c? For example, can
> arg_track_xfer() reference at_out[12] while at_out is defined in
> compute_subprog_args() as struct arg_track at_out[MAX_BPF_REG]?
Yes. The v4 does not have this issue as it does not have arg_track_xfer()
yet when I posted it. But on top of the latest master, this is indeed an
issue and I am aware of this. Thanks for pointing it out!
>
>> kernel/bpf/verifier.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index e664d924e8d4..bfeecd73e66e 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -5764,6 +5764,13 @@ static int check_stack_read_fixed_off(struct bpf_verifier_env *env,
>> }
>> if (type == STACK_INVALID && env->allow_uninit_stack)
>> continue;
>> + /*
>> + * Cross-frame reads may hit slots poisoned by dead code elimination.
>> + * Static liveness can't track indirect references through pointers,
>> + * so allow the read conservatively.
>> + */
>> + if (type == STACK_POISON && reg_state != state)
>> + continue;
>> if (type == STACK_POISON) {
>> verbose(env, "reading from stack off %d+%d size %d, slot poisoned by dead code elimination\n",
>> off, i, size);
>> @@ -5819,6 +5826,8 @@ static int check_stack_read_fixed_off(struct bpf_verifier_env *env,
>> continue;
>> if (type == STACK_INVALID && env->allow_uninit_stack)
>> continue;
>> + if (type == STACK_POISON && reg_state != state)
>> + continue;
>> if (type == STACK_POISON) {
>> verbose(env, "reading from stack off %d+%d size %d, slot poisoned by dead code elimination\n",
>> off, i, size);
>> --
>> 2.52.0
>>
>>
next prev parent reply other threads:[~2026-04-16 14:21 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-12 4:58 [PATCH bpf-next v4 00/18] bpf: Support stack arguments for BPF functions and kfuncs Yonghong Song
2026-04-12 4:58 ` [PATCH bpf-next v4 01/18] bpf: Remove unused parameter from check_map_kptr_access() Yonghong Song
2026-04-12 4:58 ` [PATCH bpf-next v4 02/18] bpf: Change from "arg #%d" to "arg#%d" in verifier log Yonghong Song
2026-04-12 4:58 ` [PATCH bpf-next v4 03/18] bpf: Refactor to avoid redundant calculation of bpf_reg_state Yonghong Song
2026-04-12 5:31 ` bot+bpf-ci
2026-04-13 14:25 ` Yonghong Song
2026-04-12 4:58 ` [PATCH bpf-next v4 04/18] bpf: Refactor to handle memory and size together Yonghong Song
2026-04-12 5:31 ` bot+bpf-ci
2026-04-13 14:27 ` Yonghong Song
2026-04-12 4:58 ` [PATCH bpf-next v4 05/18] bpf: Change some regno type from u32 to int type Yonghong Song
2026-04-12 4:58 ` [PATCH bpf-next v4 06/18] bpf: Use argument index instead of register index in kfunc verifier logs Yonghong Song
2026-04-12 5:43 ` bot+bpf-ci
2026-04-13 14:37 ` Yonghong Song
2026-04-12 22:01 ` Alexei Starovoitov
2026-04-13 14:45 ` Yonghong Song
2026-04-15 23:23 ` Amery Hung
2026-04-16 14:39 ` Yonghong Song
2026-04-12 4:59 ` [PATCH bpf-next v4 07/18] bpf: Introduce bpf register BPF_REG_STACK_ARG_BASE Yonghong Song
2026-04-12 4:59 ` [PATCH bpf-next v4 08/18] bpf: Reuse MAX_BPF_FUNC_ARGS for maximum number of arguments Yonghong Song
2026-04-12 4:59 ` [PATCH bpf-next v4 09/18] bpf: Support stack arguments for bpf functions Yonghong Song
2026-04-12 5:43 ` bot+bpf-ci
2026-04-13 15:22 ` Yonghong Song
2026-04-12 22:23 ` Alexei Starovoitov
2026-04-13 16:33 ` Yonghong Song
2026-04-12 5:00 ` [PATCH bpf-next v4 10/18] bpf: Fix interaction between stack argument PTR_TO_STACK and dead slot poisoning Yonghong Song
2026-04-12 5:43 ` bot+bpf-ci
2026-04-13 16:36 ` Yonghong Song
2026-04-15 22:32 ` Amery Hung
2026-04-16 14:21 ` Yonghong Song [this message]
2026-04-12 5:00 ` [PATCH bpf-next v4 11/18] bpf: Reject stack arguments in non-JITed programs Yonghong Song
2026-04-12 5:00 ` [PATCH bpf-next v4 12/18] bpf: Reject stack arguments if tail call reachable Yonghong Song
2026-04-12 5:43 ` bot+bpf-ci
2026-04-13 16:37 ` Yonghong Song
2026-04-12 5:00 ` [PATCH bpf-next v4 13/18] bpf: Support stack arguments for kfunc calls Yonghong Song
2026-04-12 5:43 ` bot+bpf-ci
2026-04-13 16:43 ` Yonghong Song
2026-04-12 5:00 ` [PATCH bpf-next v4 14/18] bpf: Enable stack argument support for x86_64 Yonghong Song
2026-04-12 5:00 ` [PATCH bpf-next v4 15/18] bpf,x86: Implement JIT support for stack arguments Yonghong Song
2026-04-12 5:43 ` bot+bpf-ci
2026-04-13 16:49 ` Yonghong Song
2026-04-12 22:36 ` Alexei Starovoitov
2026-04-13 17:26 ` Yonghong Song
2026-04-13 19:59 ` Alexei Starovoitov
2026-04-13 20:32 ` Yonghong Song
2026-04-13 20:38 ` Alexei Starovoitov
2026-04-13 21:10 ` Yonghong Song
2026-04-14 16:45 ` Yonghong Song
2026-04-14 17:51 ` Alexei Starovoitov
2026-04-12 5:00 ` [PATCH bpf-next v4 16/18] selftests/bpf: Add tests for BPF function " Yonghong Song
2026-04-12 5:00 ` [PATCH bpf-next v4 17/18] selftests/bpf: Add negative test for greater-than-8-byte kfunc stack argument Yonghong Song
2026-04-12 5:00 ` [PATCH bpf-next v4 18/18] selftests/bpf: Add verifier tests for stack argument validation 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=06642779-578a-4d79-b687-080ad8f96791@linux.dev \
--to=yonghong.song@linux.dev \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jose.marchesi@oracle.com \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
/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