From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Eduard Zingerman <eddyz87@gmail.com>,
Emil Tsalapatis <emil@etsalapatis.com>,
kkd@meta.com, kernel-team@meta.com
Subject: [PATCH bpf-next v1 06/14] bpf: Correct kfunc argument diagnostics
Date: Sun, 16 Aug 2026 03:57:34 +0200 [thread overview]
Message-ID: <20260816015746.2632990-7-memxor@gmail.com> (raw)
In-Reply-To: <20260816015746.2632990-1-memxor@gmail.com>
The Call Type Safety diagnostics mishandle three kfunc argument classes.
BTF type ID 0 represents void, but btf_show_name() also uses zero to end
type traversal. A pointer that resolves to void therefore loses its pointee
name and is rendered as "()". End traversal directly for concrete terminal
types, but resolve referenced types before testing for ID zero, and name the
void terminal type explicitly. Format the complete parameter pointer type
for nullable kfunc arguments, so void pointers are reported as (void *).
Also add the missing structured report when an __szk memory-size argument is
not a verifier-known constant. Describe the generic bpf_refcount_acquire()
contract without deriving an object type from its void pointer prototype.
Link: https://lore.kernel.org/bpf/668871823f90f69896d3db27b56db2f53e481162.camel@gmail.com/
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
kernel/bpf/btf.c | 8 ++++----
kernel/bpf/verifier.c | 22 +++++++++++++---------
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 5b9d767895c9..6967d48bba49 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -1169,19 +1169,19 @@ static const char *btf_show_name(struct btf_show *show)
id = t->type;
break;
default:
- id = 0;
- break;
+ goto resolved;
}
+ t = btf_type_skip_qualifiers(show->btf, id);
if (!id)
break;
- t = btf_type_skip_qualifiers(show->btf, id);
}
/* We may not be able to represent this type; bail to be safe */
if (i == BTF_SHOW_MAX_ITER)
return "";
+resolved:
if (!name)
- name = btf_name_by_offset(show->btf, t->name_off);
+ name = btf_type_is_void(t) ? "void" : btf_name_by_offset(show->btf, t->name_off);
switch (BTF_INFO_KIND(t->info)) {
case BTF_KIND_STRUCT:
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 7ef324e384f4..da2ec0655b17 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -12653,12 +12653,12 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_call_arg_me
!type_may_be_null(kf_arg_type)) {
const char *expected_type;
- expected_type = bpf_diag_fmt_btf_type(env, btf, ref_id);
+ expected_type = bpf_diag_fmt_btf_type(env, btf, args[i].type);
verbose(env, "Possibly NULL pointer passed to trusted %s\n",
reg_arg_name(env, argno));
bpf_diag_call_arg_fmt(env, insn_idx, argno, func_name,
"Add a NULL check and call the kfunc only on the non-NULL path.",
- "the pointer may be NULL, but this kfunc requires a non-NULL pointer to %s",
+ "the pointer may be NULL, but this kfunc requires a non-NULL value of type %s",
expected_type);
return -EACCES;
}
@@ -13095,8 +13095,14 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_call_arg_me
break;
case KF_ARG_CONST_MEM_SIZE:
ret = process_const_arg(env, reg, argno, meta);
- if (ret < 0)
+ if (ret < 0) {
+ if (ret == -EINVAL)
+ bpf_diag_call_arg_fmt(env, insn_idx, argno, func_name,
+ "Pass a compile-time constant or a value the verifier can prove is constant at this call.",
+ "the kfunc requires this memory size to be a verifier-known constant, but %s is variable on this path",
+ reg_arg_name(env, argno));
return ret;
+ }
fallthrough;
case KF_ARG_MEM_SIZE:
{
@@ -13160,15 +13166,13 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_call_arg_me
break;
case KF_ARG_PTR_TO_REFCOUNTED_KPTR:
if (!type_is_ptr_alloc_obj(reg->type)) {
- const char *expected_type;
-
- expected_type = bpf_diag_fmt_btf_type(env, btf, ref_id);
verbose(env, "%s is neither owning or non-owning ref\n",
reg_arg_name(env, argno));
bpf_diag_call_arg_fmt(env, insn_idx, argno, func_name,
- "Pass a pointer returned by the matching BPF object allocation or lookup operation for this kfunc.",
- "the kfunc expects a pointer to BPF-managed refcounted object type %s, but this argument is not such an object pointer",
- expected_type);
+ "Pass an owning or non-owning pointer to a BPF-managed object containing a bpf_refcount field.",
+ "the kfunc expects a pointer to a BPF-managed refcounted object, but %s is %s",
+ reg_arg_name(env, argno),
+ bpf_diag_reg_type_plain(env, reg->type));
return -EINVAL;
}
if (!type_is_non_owning_ref(reg->type))
--
2.53.0
next prev parent reply other threads:[~2026-08-16 1:57 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-16 1:57 [PATCH bpf-next v1 00/14] Follow ups for verifier errors set Kumar Kartikeya Dwivedi
2026-08-16 1:57 ` [PATCH bpf-next v1 01/14] bpf: Correct verifier diagnostic attribution for stack reads Kumar Kartikeya Dwivedi
2026-08-16 6:34 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 02/14] selftests/bpf: Test verifier stack-read diagnostic attribution Kumar Kartikeya Dwivedi
2026-08-16 2:45 ` bot+bpf-ci
2026-08-16 6:35 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 03/14] bpf: Preserve R0 lineage across helper calls Kumar Kartikeya Dwivedi
2026-08-16 2:30 ` bot+bpf-ci
2026-08-16 6:12 ` Eduard Zingerman
2026-08-16 6:36 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 04/14] bpf: Drop dead spill diagnostic condition Kumar Kartikeya Dwivedi
2026-08-16 6:39 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 05/14] bpf: Use canonical stack argument names in diagnostics Kumar Kartikeya Dwivedi
2026-08-16 6:40 ` Eduard Zingerman
2026-08-16 1:57 ` Kumar Kartikeya Dwivedi [this message]
2026-08-16 2:45 ` [PATCH bpf-next v1 06/14] bpf: Correct kfunc argument diagnostics bot+bpf-ci
2026-08-16 6:50 ` Eduard Zingerman
2026-08-16 6:52 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 07/14] selftests/bpf: Test " Kumar Kartikeya Dwivedi
2026-08-16 6:53 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 08/14] bpf: Report non-sleepable kfunc programs accurately Kumar Kartikeya Dwivedi
2026-08-16 2:30 ` bot+bpf-ci
2026-08-16 7:32 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 09/14] selftests/bpf: Test non-sleepable kfunc context Kumar Kartikeya Dwivedi
2026-08-16 2:30 ` bot+bpf-ci
2026-08-16 7:37 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 10/14] bpf: Correct Program Structure diagnostic context Kumar Kartikeya Dwivedi
2026-08-16 2:45 ` bot+bpf-ci
2026-08-16 7:58 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 11/14] bpf: Preserve source attribution without source text Kumar Kartikeya Dwivedi
2026-08-16 8:01 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 12/14] selftests/bpf: Test Program Structure diagnostic context Kumar Kartikeya Dwivedi
2026-08-16 8:06 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 13/14] bpf: Distinguish function references in policy diagnostics Kumar Kartikeya Dwivedi
2026-08-16 1:57 ` [PATCH bpf-next v1 14/14] selftests/bpf: Test pseudo-function " Kumar Kartikeya Dwivedi
2026-08-16 2:45 ` bot+bpf-ci
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=20260816015746.2632990-7-memxor@gmail.com \
--to=memxor@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=kernel-team@meta.com \
--cc=kkd@meta.com \
/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.