From: sashiko-bot@kernel.org
To: "Nuoqi Gui" <gnq25@mails.tsinghua.edu.cn>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf 1/2] bpf: Preserve dynptr slice lifetime across rdonly_cast
Date: Mon, 15 Jun 2026 11:24:34 +0000 [thread overview]
Message-ID: <20260615112434.BDA2C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260615-f01-09-rdonly-cast-dynptr-lifetime-v1-1-2dd0a369e153@mails.tsinghua.edu.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The verifier tracking logic intended to invalidate `bpf_rdonly_cast` aliases during dynptr stack overwrites can be bypassed by passing an unchecked `PTR_MAYBE_NULL` slice or by chaining casts.
--
commit 4dccf7918016a6c3b330526f04f7eae4bbeed8d8
Author: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
Subject: bpf: Preserve dynptr slice lifetime across rdonly_cast
This patch updates the verifier to track lifetime metadata across
bpf_rdonly_cast(). It attaches the ref_obj_id and dynptr_id to casted
registers and ensures typed aliases are invalidated when a dynptr stack
slot is overwritten.
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -12082,8 +12088,17 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
> continue;
> }
>
> - if (is_kfunc_arg_ignore(btf, &args[i]) || is_kfunc_arg_implicit(meta, i))
> + if (is_kfunc_arg_ignore(btf, &args[i]) || is_kfunc_arg_implicit(meta, i)) {
> + if (meta->func_id == special_kfunc_list[KF_bpf_rdonly_cast] &&
> + i == 0 && is_spillable_regtype(reg->type)) {
> + meta->rdonly_cast_src.id = reg->id;
> + if (base_type(reg->type) == PTR_TO_MEM)
> + meta->rdonly_cast_src.dynptr_id = reg->dynptr_id;
[Severity: Medium]
Could this logic be bypassed by chaining casts?
If a slice is first cast to a struct, the result is PTR_TO_BTF_ID and it
stores the dynptr_id in its id field.
If that result is then cast to void * (returning PTR_TO_MEM),
base_type(reg->type) == PTR_TO_MEM will be false, so
meta->rdonly_cast_src.dynptr_id remains 0.
The returned PTR_TO_MEM will get dynptr_id = 0, which would bypass the
invalidation checks in destroy_if_dynptr_stack_slot() entirely.
> + meta->rdonly_cast_src.ref_obj_id = reg->ref_obj_id;
> + }
> +
> continue;
> + }
>
> t = btf_type_skip_modifiers(btf, args[i].type, NULL);
[ ... ]
> @@ -12932,10 +12947,17 @@ static int check_special_kfunc(struct bpf_verifier_env *env, struct bpf_kfunc_ca
> regs[BPF_REG_0].type = PTR_TO_BTF_ID | PTR_UNTRUSTED;
> regs[BPF_REG_0].btf = desc_btf;
> regs[BPF_REG_0].btf_id = meta->arg_constant.value;
> + regs[BPF_REG_0].id = meta->rdonly_cast_src.id;
> + if (!regs[BPF_REG_0].id)
> + regs[BPF_REG_0].id = meta->rdonly_cast_src.dynptr_id;
[Severity: Medium]
Does this correctly handle PTR_MAYBE_NULL slices passed to bpf_rdonly_cast?
Because bpf_rdonly_cast uses an __ign argument, it can accept an unchecked
PTR_MAYBE_NULL slice. These slices have a non-zero null-tracking id.
If meta->rdonly_cast_src.id is non-zero, this logic prioritizes the
null-tracking ID over dynptr_id. The returned typed alias will inherit the
null-tracking ID instead of the dynptr_id.
Later, when the parent dynptr is overwritten, the invalidation in
destroy_if_dynptr_stack_slot() will fail because it checks if the
dreg->id == dynptr_id.
> + regs[BPF_REG_0].ref_obj_id = meta->rdonly_cast_src.ref_obj_id;
> } else if (btf_type_is_void(ret_t)) {
> mark_reg_known_zero(env, regs, BPF_REG_0);
> regs[BPF_REG_0].type = PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-f01-09-rdonly-cast-dynptr-lifetime-v1-0-2dd0a369e153@mails.tsinghua.edu.cn?part=1
next prev parent reply other threads:[~2026-06-15 11:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 8:57 [PATCH bpf 0/2] bpf: Preserve rdonly_cast dynptr slice lifetime Nuoqi Gui
2026-06-15 8:57 ` [PATCH bpf 1/2] bpf: Preserve dynptr slice lifetime across rdonly_cast Nuoqi Gui
2026-06-15 11:24 ` sashiko-bot [this message]
2026-06-15 8:57 ` [PATCH bpf 2/2] selftests/bpf: Cover rdonly_cast dynptr slice lifetime Nuoqi Gui
2026-06-15 9:08 ` sashiko-bot
2026-06-15 9:40 ` [PATCH bpf 0/2] bpf: Preserve " Kumar Kartikeya Dwivedi
2026-06-15 17:24 ` Eduard Zingerman
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=20260615112434.BDA2C1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=gnq25@mails.tsinghua.edu.cn \
--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