Re: [PATCH v2 bpf-next 01/18] btf: Extend UAPI to support BTF location (inline site) info

On 01/09/2026 18:17, sashiko-bot@kernel.org wrote:

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] btf_loc_proto_resolve fails to validate the return type location parameter (t->type).
- [Medium] Missing strict validation of unused fields and flags in check_meta callbacks for new BTF kinds.
--

commit 32008454060b92e68c858ee6b661e8885cb28034
Author: Alan Maguire [off-list ref]

btf: Extend UAPI to support BTF location (inline site) info

This commit adds BTF_KIND_LOC_PARAM, BTF_KIND_LOC_PROTO, and
BTF_KIND_LOCSEC to help represent location information for functions.
It enables representing fully or partially inlined functions at
potentially multiple inline sites.

quoted

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 9c2cab08bb794..d74c8668aa3f6 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c

[ ... ]

quoted

+static s32 btf_loc_param_check_meta(struct btf_verifier_env *env,
+				    const struct btf_type *t,
+				    u32 meta_left)
+{
+	const struct btf_loc_param *p = btf_loc_param(t);
+	u32 meta_needed;
+	u32 size;
+
+	meta_needed = sizeof(*p) + sizeof(__u32) * btf_vlen(t);

[Severity: Medium]
Should this function strictly validate that p->flags only contains valid
enum bits, and check that btf_type_kflag(t) is 0? 

The BTF verifier typically rejects non-zero unused fields and unknown flags
to ensure forward compatibility. If malformed BTF objects with arbitrary
garbage in these fields are accepted, they might silently alter behavior
or break if these bits are repurposed in the future.

kflag test makes sense, restricting the semantics of the loc param flags less
so given that we don't use them in the kernel.

 

quoted

+	if (meta_left < meta_needed) {
+		btf_verifier_log_basic(env, t,
+				       "meta_left:%u meta_needed:%u",
+				      meta_left, meta_needed);
+		return -EINVAL;
+	}

[ ... ]

quoted

+static int btf_loc_proto_resolve(struct btf_verifier_env *env,
+				 const struct resolve_vertex *v)
+{
+	const __u32 *params = btf_loc_params(v->t);
+	u32 i, nr_params = btf_type_vlen(v->t);
+	struct btf *btf = env->btf;
+
+	for (i = 0; i < nr_params; i++) {

[Severity: High]
Does this function need to validate the return type location parameter
encoded in v->t->type? 

It appears to validate the vlen parameters (params[i]) but entirely skips
verifying v->t->type. If a malformed BTF object specifies an out-of-bounds
type ID or an incorrect BTF kind in the t->type field, could it result in
type confusion or out-of-bounds memory accesses when subsequent code trusts
this field?

loc params don't have a return type since we can only get at inbound parameters
at the location. We should check for 0 I suppose.

quoted

+		const struct btf_type *param_type;
+		u32 param_type_id = params[i];
+
+		if (!param_type_id)
+			continue;

[ ... ]

quoted

+static s32 btf_locsec_check_meta(struct btf_verifier_env *env,
+				 const struct btf_type *t,
+				 u32 meta_left)
+{
+	u32 meta_needed;
+
+	meta_needed = sizeof(struct btf_loc) * btf_type_vlen(t);

[Severity: Medium]
Similar to the location parameter check, should this callback enforce that
the unused t->size/t->type union and the kflag are 0? Without these
checks, the verifier might accept garbage data in these unused fields which
violates the strict validation design pattern.

Sure.

quoted

+
+	if (meta_left < meta_needed) {
+		btf_verifier_log_basic(env, t,
+				       "meta_left:%u meta_needed:%u",
+				       meta_left, meta_needed);
+		return -EINVAL;
+	}
+	return meta_needed;
+}