From: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
To: <sashiko-reviews@lists.linux.dev>,
"Yiyang Chen" <chenyy23@mails.tsinghua.edu.cn>
Cc: <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v4 1/2] bpf: Enforce trusted BTF ID argument provenance
Date: Mon, 19 Oct 2026 04:11:29 +0200 [thread overview]
Message-ID: <DM8G84CGPV1M.24HT5CS3KKB9F@gmail.com> (raw)
In-Reply-To: <sashiko-outbox-163202@kernel.org>
On Wed Oct 7, 2026 at 6:43 PM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] bpf: check_func_arg() allows PTR_UNTRUSTED | MEM_RCU into KF_RCU kfuncs
> --
>
> commit 1e71cf476e59d8805f3765efcab69f9c9d9bba4a
> Author: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
>
> bpf: Enforce trusted BTF ID argument provenance
>
> This commit modifies the verifier to make the provenance check contract-driven
> by marking generated BTF ID kfunc argument types with PTR_TRUSTED and explicitly
> adding MEM_RCU only for KF_RCU kfuncs. It uses the normalized type for modifier
> checks while reference lookup uses the original register.
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 353bde9ae2274..a0ab793f041d8 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
> [ ... ]
>> @@ -9605,8 +9614,10 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg, u32 slot, u32 p
>> }
>> }
>>
>> - if (is_kfunc(meta) && (!is_trusted_reg(env, reg) ||
>> - bpf_type_has_unsafe_modifiers(reg->type))) {
>> + reg_type = reg->type & ~(arg_type & PTR_MAYBE_NULL);
>> + if ((arg_type & PTR_TRUSTED) &&
>> + (!is_trusted_reg_type(env, reg, reg_type) ||
>> + bpf_type_has_unsafe_modifiers(reg_type))) {
>> if (!(arg_type & MEM_RCU)) {
> [ ... ]
>> return -EINVAL;
>> }
>> if (!is_rcu_reg(reg)) {
> [ ... ]
>> return -EINVAL;
>> }
>> }
>
> [Severity: High]
> Does this allow a register with both MEM_RCU and PTR_UNTRUSTED modifiers to be
> passed into KF_RCU kfuncs?
>
> If a BPF program loads a pointer that is marked as PTR_UNTRUSTED | MEM_RCU (for
> example, when loading an __rcu pointer embedded in a union) inside an RCU
> critical section, and passes it to a KF_RCU kfunc:
>
> 1. The arg_type has MEM_RCU, so the first inner check !(arg_type & MEM_RCU) is
> false.
> 2. The register has MEM_RCU, so the second inner check !is_rcu_reg(reg) is
> false.
> 3. The validation falls through and succeeds, even though the register has the
> PTR_UNTRUSTED modifier.
>
> Since check_reg_type() bypasses the strict compatible_reg_types check for kfunc
> BTF_ID arguments, this appears to leave the verifier without any checks that
> would reject the untrusted modifier here. Can this result in untrusted garbage
> pointers being used as valid RCU pointers?
Yiyang, could you please follow up with a fix for this corner case as well?
Thanks a lot for the existing fix.
next prev parent reply other threads:[~2026-10-19 2:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 16:25 [PATCH bpf-next v4 0/2] bpf: Enforce trusted BTF ID argument provenance Yiyang Chen
2026-10-07 16:25 ` [PATCH bpf-next v4 1/2] " Yiyang Chen
2026-10-07 16:43 ` sashiko-bot
2026-10-19 2:11 ` Kumar Kartikeya Dwivedi [this message]
2026-10-07 22:30 ` Amery Hung
2026-10-07 16:25 ` [PATCH bpf-next v4 2/2] selftests/bpf: Cover " Yiyang Chen
2026-10-07 22:24 ` Amery Hung
2026-10-19 2:10 ` [PATCH bpf-next v4 0/2] bpf: Enforce " patchwork-bot+netdevbpf
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=DM8G84CGPV1M.24HT5CS3KKB9F@gmail.com \
--to=memxor@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=chenyy23@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.