[PATCH bpf-next] bpf: Fix out-of-bounds btf->types write for split BTF

[PATCH bpf-next] bpf: Fix out-of-bounds btf->types write for split BTF

[Feng Yang]

From: Feng Yang <yangfeng@kylinos.cn>

btf_add_type() bounds the btf->types array by BTF_MAX_TYPE, but for a
split BTF the type ids it registers are start_id .. start_id +
nr_types - 1, so what is actually left of the id space is
BTF_MAX_TYPE - start_id.  Two things follow from that:

 - the limit check is an equality test,
   'start_id + btf->types_size == BTF_MAX_TYPE'.  It is evaluated only
   when the array has to grow, with btf->types_size == btf->nr_types,
   and the growth (T' = min(BTF_MAX_TYPE, T + max(T / 4, 16)), starting
   from 0) is clamped to BTF_MAX_TYPE, which it lands on exactly (...,
   928143, then min(BTF_MAX_TYPE, 1160178)).  So unless
   BTF_MAX_TYPE - start_id is one of the 48 sizes that sequence hits,
   the check does not fire for a split BTF at all;

 - new_size is clamped to BTF_MAX_TYPE instead of
   BTF_MAX_TYPE - start_id, so the array can still grow to
   BTF_MAX_TYPE entries even though only BTF_MAX_TYPE - start_id type
   ids exist.

As a result nr_types can reach BTF_MAX_TYPE for a split BTF while its
type ids have already gone past BTF_MAX_TYPE; a type never validates its
own id, only the ids it references (btf_ref_type_check_meta()).  At that
point btf->types_size == btf->nr_types == BTF_MAX_TYPE and the growth
branch computes the same size again: it allocates a fresh BTF_MAX_TYPE
entry array, copies the entries, and the loop is left with
btf->types_size != btf->nr_types, so that branch is not taken anymore.
Every type after this writes btf->types[btf->nr_types++] past the end of
the array: BTF_MAX_TYPE * 8 == 8388600 bytes are requested, so the first
such write lands in the 8 byte rounding slack of the 8MB allocation, and
each further type writes another 8 bytes beyond it.

Fix both by bounding the array with BTF_MAX_TYPE - start_id and by
turning the equality check into a '>=' one, so that the array stops
exactly where the id space ends. Base BTF behavior (start_id ==
0) is unchanged.

Fixes: 951bb64621b8 ("bpf: Add in-kernel split BTF support")
Signed-off-by: Feng Yang <yangfeng@kylinos.cn>
---
 kernel/bpf/btf.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 80b6f96263f1..6e54cd6c2eb5 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -1724,15 +1724,17 @@ static int btf_add_type(struct btf_verifier_env *env, struct btf_type *t)
 		/* Expand 'types' array */
 
 		struct btf_type **new_types;
-		u32 expand_by, new_size;
+		u32 expand_by, new_size, max_size;
 
-		if (btf->start_id + btf->types_size == BTF_MAX_TYPE) {
+		if (btf->start_id >= BTF_MAX_TYPE ||
+		    btf->start_id + btf->types_size >= BTF_MAX_TYPE) {
 			btf_verifier_log(env, "Exceeded max num of types");
 			return -E2BIG;
 		}
 
+		max_size = BTF_MAX_TYPE - btf->start_id;
 		expand_by = max_t(u32, btf->types_size >> 2, 16);
-		new_size = min_t(u32, BTF_MAX_TYPE,
+		new_size = min_t(u32, max_size,
 				 btf->types_size + expand_by);
 
 		new_types = kvzalloc_objs(*new_types, new_size,
-- 
2.25.1

Re: [PATCH bpf-next] bpf: Fix out-of-bounds btf->types write for split BTF

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: unchecked btf_add_type() return value in btf_check_all_metas()
--

commit 4ac38a4f66ed4b8171a028c6c026eb14f1efb57a
Author: Feng Yang <yangfeng@kylinos.cn>

bpf: Fix out-of-bounds btf->types write for split BTF

This commit bounds the btf->types array growth in btf_add_type() by
subtracting btf->start_id from the maximum type limit and replacing the
equality check with a greater-than-or-equal check to prevent out-of-bounds
writes when parsing split BTF.

> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 538129ed24188..7949704712791 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -1752,15 +1752,17 @@ static int btf_add_type(struct btf_verifier_env *env, struct btf_type *t)
>  		/* Expand 'types' array */
>  
>  		struct btf_type **new_types;
> -		u32 expand_by, new_size;
> +		u32 expand_by, new_size, max_size;
>  
> -		if (btf->start_id + btf->types_size == BTF_MAX_TYPE) {
> +		if (btf->start_id >= BTF_MAX_TYPE ||
> +		    btf->start_id + btf->types_size >= BTF_MAX_TYPE) {
>  			btf_verifier_log(env, "Exceeded max num of types");
>  			return -E2BIG;
>  		}

[Severity: High]
Does returning -E2BIG (or -ENOMEM when kvzalloc_objs() fails) in
btf_add_type() actually stop BTF verification when its sole caller,
btf_check_all_metas(), ignores the return value?

In kernel/bpf/btf.c:btf_check_all_metas():

	while (cur < end) {
		struct btf_type *t = cur;
		s32 meta_size;

		meta_size = btf_check_meta(env, t, end - cur);
		if (meta_size < 0)
			return meta_size;

		btf_add_type(env, t);
		cur += meta_size;
		env->log_type_id++;
	}

	return 0;

When btf_add_type() returns an error here, it returns before appending the
type to btf->types[btf->nr_types++], but btf_check_all_metas() continues
looping over the remaining types and returns 0.

In the btf_parse() path, btf_check_all_types() only iterates up to
btf->nr_types, so if no earlier type references the dropped tail types,
verification succeeds with a silently truncated btf->types array.

In the btf_parse_base() and btf_parse_split() paths, btf_check_all_types() is
not called at all:

kernel/bpf/btf.c:btf_parse_split() {
	...
	err = btf_check_all_metas(env);
	if (err)
		goto errout;

	err = btf_check_modifier_chain_length(env, btf, btf_nr_types(base_btf));
	if (err)
		goto errout;

	return btf;
}

If a split BTF exceeds the limit and an earlier split BTF type references a
dropped type ID at the boundary (which still passes the metadata check in
btf_check_meta()), btf_parse_module() -> btf_parse_split() succeeds with a
truncated btf->types array. Subsequent relocation in btf_relocate() ->
btf_mark_embedded_composite_type_ids() in tools/lib/bpf/btf_relocate.c then
looks up that dropped ID:

	while (next_id) {
		t = btf_type_by_id(r->btf, next_id);
		switch (btf_kind(t)) {

Because next_id is >= btf->start_id + btf->nr_types, btf_type_by_id() returns
null and btf_kind(t) dereferences it, while btf_relocate_rewrite_type_id() can
also read past the end of r->id_map[].

Similarly, if kvzalloc_objs() fails in btf_add_type(), btf_check_all_metas()
can return 0 with btf->types left null or with types shifted after a transient
allocation failure.

Should btf_check_all_metas() check and propagate the error returned by
btf_add_type()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261023063133.563998-1-yangfeng59949@163.com?part=1

Re: [PATCH bpf-next] bpf: Fix out-of-bounds btf->types write for split BTF

[Feng Yang]

On Fri, 23 Oct 2026 06:46:07 +0000 sashiko-bot@kernel.org wroted:

> [...]
> Should btf_check_all_metas() check and propagate the error returned by
> btf_add_type()?

The previous patch at https://lore.kernel.org/all/20261022064727.747304-1-yangfeng59949@163.com/
has fixed this issue.

Re: [PATCH bpf-next] bpf: Fix out-of-bounds btf->types write for split BTF

[Mahe Tardy]

On Fri, Oct 23, 2026 at 02:31:33PM +0800, Feng Yang wrote:
> From: Feng Yang <yangfeng@kylinos.cn>
> 
> btf_add_type() bounds the btf->types array by BTF_MAX_TYPE, but for a
> split BTF the type ids it registers are start_id .. start_id +
> nr_types - 1, so what is actually left of the id space is
> BTF_MAX_TYPE - start_id.  Two things follow from that:
> 
>  - the limit check is an equality test,
>    'start_id + btf->types_size == BTF_MAX_TYPE'.  It is evaluated only
>    when the array has to grow, with btf->types_size == btf->nr_types,
>    and the growth (T' = min(BTF_MAX_TYPE, T + max(T / 4, 16)), starting
>    from 0) is clamped to BTF_MAX_TYPE, which it lands on exactly (...,
>    928143, then min(BTF_MAX_TYPE, 1160178)).  So unless
>    BTF_MAX_TYPE - start_id is one of the 48 sizes that sequence hits,
>    the check does not fire for a split BTF at all;
> 
>  - new_size is clamped to BTF_MAX_TYPE instead of
>    BTF_MAX_TYPE - start_id, so the array can still grow to
>    BTF_MAX_TYPE entries even though only BTF_MAX_TYPE - start_id type
>    ids exist.
> 
> As a result nr_types can reach BTF_MAX_TYPE for a split BTF while its
> type ids have already gone past BTF_MAX_TYPE; a type never validates its
> own id, only the ids it references (btf_ref_type_check_meta()).  At that
> point btf->types_size == btf->nr_types == BTF_MAX_TYPE and the growth
> branch computes the same size again: it allocates a fresh BTF_MAX_TYPE
> entry array, copies the entries, and the loop is left with
> btf->types_size != btf->nr_types, so that branch is not taken anymore.
> Every type after this writes btf->types[btf->nr_types++] past the end of
> the array: BTF_MAX_TYPE * 8 == 8388600 bytes are requested, so the first
> such write lands in the 8 byte rounding slack of the 8MB allocation, and
> each further type writes another 8 bytes beyond it.
> 
> Fix both by bounding the array with BTF_MAX_TYPE - start_id and by
> turning the equality check into a '>=' one, so that the array stops
> exactly where the id space ends. Base BTF behavior (start_id ==
> 0) is unchanged.
> 
> Fixes: 951bb64621b8 ("bpf: Add in-kernel split BTF support")
> Signed-off-by: Feng Yang <yangfeng@kylinos.cn>

Reviewed-by: Mahe Tardy <mahe.tardy@gmail.com>

Indeed taking toy BTF_MAX_TYPE = 10 and start_id = 2 we can see the
array can grow from 0 to 10 directly, get filled, enter the growth
branch then the condition is for E2BIG is 2 + 10 which is already beyond
10 and thus never match: we re-allocate the array, copy and write out of
bounds. Fix looks reasonable to me (but disclaimer I just read that code
for the first time).

> ---
>  kernel/bpf/btf.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 80b6f96263f1..6e54cd6c2eb5 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -1724,15 +1724,17 @@ static int btf_add_type(struct btf_verifier_env *env, struct btf_type *t)
>  		/* Expand 'types' array */
>  
>  		struct btf_type **new_types;
> -		u32 expand_by, new_size;
> +		u32 expand_by, new_size, max_size;
>  
> -		if (btf->start_id + btf->types_size == BTF_MAX_TYPE) {
> +		if (btf->start_id >= BTF_MAX_TYPE ||
> +		    btf->start_id + btf->types_size >= BTF_MAX_TYPE) {
>  			btf_verifier_log(env, "Exceeded max num of types");
>  			return -E2BIG;
>  		}
>  
> +		max_size = BTF_MAX_TYPE - btf->start_id;
>  		expand_by = max_t(u32, btf->types_size >> 2, 16);
> -		new_size = min_t(u32, BTF_MAX_TYPE,
> +		new_size = min_t(u32, max_size,
>  				 btf->types_size + expand_by);
>  
>  		new_types = kvzalloc_objs(*new_types, new_size,
> -- 
> 2.25.1
> 

Re: [PATCH bpf-next] bpf: Fix out-of-bounds btf->types write for split BTF

[Alexei Starovoitov]

On Fri, Oct 23, 2026 at 12:38 AM Feng Yang <yangfeng59949@163.com> wrote:
>
> On Fri, 23 Oct 2026 06:46:07 +0000 sashiko-bot@kernel.org wroted:
>
> > [...]
> > Should btf_check_all_metas() check and propagate the error returned by
> > btf_add_type()?
>
> The previous patch at https://lore.kernel.org/all/20261022064727.747304-1-yangfeng59949@163.com/
> has fixed this issue.

Pls respin targeting bpf tree.