[PATCH bpf] libbpf: Fix type size overflow in btf_type_size_unknown

[PATCH bpf] libbpf: Fix type size overflow in btf_type_size_unknown

[Alan Maguire]

A layout section with a large elem_sz/vlen can lead to a 32-bit
overflow in btf_parse_type_sec() at the point where a large
type_size is added to the next_type [1]; a sufficiently large type_size
on a 32-bit system could lead to the bounds check

	if (next_type + type_size > end_type)

not triggering (since next_type + type_size wraps to a value low
in the 32-bit address space).  This would lead to a bad value for
next_type when we add the type size.  Avoid this by ensuring that
the type_size we return from btf_type_size_unknown() falls within
the range of <current type, end_type>.

[1] https://lore.kernel.org/bpf/20260417170712.74E77C19425@smtp.kernel.org/

Reported-by: sashiko <sashiko-bot@kernel.org>
Fixes: 2ecbe53e0e991 ("libbpf: Use layout to compute an unknown kind size")
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
---
 tools/lib/bpf/btf.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
index ceb57b46a878..d48ac5460d1d 100644
--- a/tools/lib/bpf/btf.c
+++ b/tools/lib/bpf/btf.c
@@ -420,9 +420,11 @@ static int btf_parse_layout_sec(struct btf *btf)
 static int btf_type_size_unknown(const struct btf *btf, const struct btf_type *t)
 {
 	__u32 l_cnt = btf->hdr.layout_len / sizeof(struct btf_layout);
+	const void *end_type = btf->types_data + btf->hdr.type_len;
 	struct btf_layout *l = btf->layout;
 	__u16 vlen = btf_vlen(t);
 	__u32 kind = btf_kind(t);
+	int type_size;
 
 	/* Fall back to base BTF if needed as they share layout information */
 	if (!l) {
@@ -448,7 +450,13 @@ static int btf_type_size_unknown(const struct btf *btf, const struct btf_type *t
 		return -EINVAL;
 	}
 
-	return sizeof(struct btf_type) + l[kind].info_sz + vlen * l[kind].elem_sz;
+	type_size = sizeof(struct btf_type) + l[kind].info_sz + vlen * l[kind].elem_sz;
+	if ((size_t)type_size > (size_t)(end_type - (const void *)t)) {
+		pr_debug("Overflow in type size %d for kind %u\n",
+			 type_size, kind);
+		return -EINVAL;
+	}
+	return type_size;
 }
 
 static int btf_type_size(const struct btf *btf, const struct btf_type *t)
-- 
2.39.3

Re: [PATCH bpf] libbpf: Fix type size overflow in btf_type_size_unknown

[Mykyta Yatsenko]

On 4/22/26 11:32 AM, Alan Maguire wrote:
> A layout section with a large elem_sz/vlen can lead to a 32-bit
> overflow in btf_parse_type_sec() at the point where a large
> type_size is added to the next_type [1]; a sufficiently large type_size
> on a 32-bit system could lead to the bounds check
> 
> 	if (next_type + type_size > end_type)
> 
> not triggering (since next_type + type_size wraps to a value low
> in the 32-bit address space).  This would lead to a bad value for
> next_type when we add the type size.  Avoid this by ensuring that
> the type_size we return from btf_type_size_unknown() falls within
> the range of <current type, end_type>.
> 
> [1] https://lore.kernel.org/bpf/20260417170712.74E77C19425@smtp.kernel.org/
> 
> Reported-by: sashiko <sashiko-bot@kernel.org>
> Fixes: 2ecbe53e0e991 ("libbpf: Use layout to compute an unknown kind size")
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> ---

Beginner question: how does targeting bpf tree helps libbpf patch, it's 
not available unless we sync to github and release a new libbpf version, 
isn't it?
I would rebase this on bpf-next: it does not apply cleanly on bpf-next 
and dealing with conflicts for this change does not sound amazing.

>   tools/lib/bpf/btf.c | 10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> index ceb57b46a878..d48ac5460d1d 100644
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
> @@ -420,9 +420,11 @@ static int btf_parse_layout_sec(struct btf *btf)
>   static int btf_type_size_unknown(const struct btf *btf, const struct btf_type *t)
>   {
>   	__u32 l_cnt = btf->hdr.layout_len / sizeof(struct btf_layout);
> +	const void *end_type = btf->types_data + btf->hdr.type_len;
>   	struct btf_layout *l = btf->layout;
>   	__u16 vlen = btf_vlen(t);
>   	__u32 kind = btf_kind(t);
> +	int type_size;
>   
>   	/* Fall back to base BTF if needed as they share layout information */
>   	if (!l) {
> @@ -448,7 +450,13 @@ static int btf_type_size_unknown(const struct btf *btf, const struct btf_type *t
>   		return -EINVAL;
>   	}
>   
> -	return sizeof(struct btf_type) + l[kind].info_sz + vlen * l[kind].elem_sz;
> +	type_size = sizeof(struct btf_type) + l[kind].info_sz + vlen * l[kind].elem_sz;
> +	if ((size_t)type_size > (size_t)(end_type - (const void *)t)) {
> +		pr_debug("Overflow in type size %d for kind %u\n",
> +			 type_size, kind);
> +		return -EINVAL;
> +	}
> +	return type_size;
>   }
>   
>   static int btf_type_size(const struct btf *btf, const struct btf_type *t)

Re: [PATCH bpf] libbpf: Fix type size overflow in btf_type_size_unknown

[Alan Maguire]

On 22/04/2026 15:19, Mykyta Yatsenko wrote:
> On 4/22/26 11:32 AM, Alan Maguire wrote:
>> A layout section with a large elem_sz/vlen can lead to a 32-bit
>> overflow in btf_parse_type_sec() at the point where a large
>> type_size is added to the next_type [1]; a sufficiently large type_size
>> on a 32-bit system could lead to the bounds check
>>
>>     if (next_type + type_size > end_type)
>>
>> not triggering (since next_type + type_size wraps to a value low
>> in the 32-bit address space).  This would lead to a bad value for
>> next_type when we add the type size.  Avoid this by ensuring that
>> the type_size we return from btf_type_size_unknown() falls within
>> the range of <current type, end_type>.
>>
>> [1] https://lore.kernel.org/bpf/20260417170712.74E77C19425@smtp.kernel.org/
>>
>> Reported-by: sashiko <sashiko-bot@kernel.org>
>> Fixes: 2ecbe53e0e991 ("libbpf: Use layout to compute an unknown kind size")
>> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
>> ---
> 
> Beginner question: how does targeting bpf tree helps libbpf patch, it's not available unless we sync to github and release a new libbpf version, isn't it?
> I would rebase this on bpf-next: it does not apply cleanly on bpf-next and dealing with conflicts for this change does not sound amazing.
> 

Sure, happy to do this if it makes things easier. In this case the bug did exist prior to
the vlen expansion work, but only for a short period of time. As I understand it bpf fixes
are resynced regularly with bpf-next, but that does require merging. In this case the merge should
be straightforward I think, but if maintainers would prefer a bpf-next-targeted patch I'll do that
instead. Thanks!

>>   tools/lib/bpf/btf.c | 10 +++++++++-
>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
>> index ceb57b46a878..d48ac5460d1d 100644
>> --- a/tools/lib/bpf/btf.c
>> +++ b/tools/lib/bpf/btf.c
>> @@ -420,9 +420,11 @@ static int btf_parse_layout_sec(struct btf *btf)
>>   static int btf_type_size_unknown(const struct btf *btf, const struct btf_type *t)
>>   {
>>       __u32 l_cnt = btf->hdr.layout_len / sizeof(struct btf_layout);
>> +    const void *end_type = btf->types_data + btf->hdr.type_len;
>>       struct btf_layout *l = btf->layout;
>>       __u16 vlen = btf_vlen(t);
>>       __u32 kind = btf_kind(t);
>> +    int type_size;
>>         /* Fall back to base BTF if needed as they share layout information */
>>       if (!l) {
>> @@ -448,7 +450,13 @@ static int btf_type_size_unknown(const struct btf *btf, const struct btf_type *t
>>           return -EINVAL;
>>       }
>>   -    return sizeof(struct btf_type) + l[kind].info_sz + vlen * l[kind].elem_sz;
>> +    type_size = sizeof(struct btf_type) + l[kind].info_sz + vlen * l[kind].elem_sz;
>> +    if ((size_t)type_size > (size_t)(end_type - (const void *)t)) {
>> +        pr_debug("Overflow in type size %d for kind %u\n",
>> +             type_size, kind);
>> +        return -EINVAL;
>> +    }
>> +    return type_size;
>>   }
>>     static int btf_type_size(const struct btf *btf, const struct btf_type *t)
> 

Re: [PATCH bpf] libbpf: Fix type size overflow in btf_type_size_unknown

[Alexei Starovoitov]

On Wed, Apr 22, 2026 at 8:07 AM Alan Maguire <alan.maguire@oracle.com> wrote:
>
> On 22/04/2026 15:19, Mykyta Yatsenko wrote:
> > On 4/22/26 11:32 AM, Alan Maguire wrote:
> >> A layout section with a large elem_sz/vlen can lead to a 32-bit
> >> overflow in btf_parse_type_sec() at the point where a large
> >> type_size is added to the next_type [1]; a sufficiently large type_size
> >> on a 32-bit system could lead to the bounds check
> >>
> >>     if (next_type + type_size > end_type)
> >>
> >> not triggering (since next_type + type_size wraps to a value low
> >> in the 32-bit address space).  This would lead to a bad value for
> >> next_type when we add the type size.  Avoid this by ensuring that
> >> the type_size we return from btf_type_size_unknown() falls within
> >> the range of <current type, end_type>.
> >>
> >> [1] https://lore.kernel.org/bpf/20260417170712.74E77C19425@smtp.kernel.org/
> >>
> >> Reported-by: sashiko <sashiko-bot@kernel.org>
> >> Fixes: 2ecbe53e0e991 ("libbpf: Use layout to compute an unknown kind size")
> >> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> >> ---
> >
> > Beginner question: how does targeting bpf tree helps libbpf patch, it's not available unless we sync to github and release a new libbpf version, isn't it?
> > I would rebase this on bpf-next: it does not apply cleanly on bpf-next and dealing with conflicts for this change does not sound amazing.
> >
>
> Sure, happy to do this if it makes things easier. In this case the bug did exist prior to
> the vlen expansion work, but only for a short period of time. As I understand it bpf fixes
> are resynced regularly with bpf-next, but that does require merging. In this case the merge should
> be straightforward I think, but if maintainers would prefer a bpf-next-targeted patch I'll do that
> instead. Thanks!

Mykyta's point is that 'bpf' tree is for kernel fixes.
We send libbpf fixes to bpf tree only when they're part of
kernel fixes and they have to go together.
Not the case here.

pw-bot: cr

Re: [PATCH bpf] libbpf: Fix type size overflow in btf_type_size_unknown

[sashiko-bot]

Sashiko AI review found 2 potential issue(s):
- [High] This problem wasn't introduced by this patch, but the patch attempts to fix a pointer wrap-around vulnerability and leaves it completely unfixed for standard BTF kinds.
- [Medium] The bounds check added in btf_type_size_unknown() performs pointer subtraction between unrelated memory allocations, leading to C Undefined Behavior.
--

commit ac478ac510f0298a2cc2458f409eff3e04fdd3b5
Author: Alan Maguire <alan.maguire@oracle.com>

libbpf: Fix type size overflow in btf_type_size_unknown

This commit attempts to fix a 32-bit pointer arithmetic wrap-around in
btf_parse_type_sec() by adding a bounds check in btf_type_size_unknown().
This aims to prevent a large type_size from wrapping when added to next_type,
which would bypass the existing bounds checks.

Link: https://lore.kernel.org/bpf/20260417170712.74E77C19425@smtp.kernel.org/

> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> index ceb57b46a8782..d48ac5460d1de 100644
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
> @@ -420,9 +420,11 @@ static int btf_parse_layout_sec(struct btf *btf)
>  static int btf_type_size_unknown(const struct btf *btf, const struct btf_type *t)
>  {
>  	__u32 l_cnt = btf->hdr.layout_len / sizeof(struct btf_layout);
> +	const void *end_type = btf->types_data + btf->hdr.type_len;
>  	struct btf_layout *l = btf->layout;
>  	__u16 vlen = btf_vlen(t);
>  	__u32 kind = btf_kind(t);
> +	int type_size;
>  
>  	/* Fall back to base BTF if needed as they share layout information */
>  	if (!l) {

[ ... ]

> @@ -448,7 +450,13 @@ static int btf_type_size_unknown(const struct btf *btf, const struct btf_type *t
>  		return -EINVAL;
>  	}
>  
> -	return sizeof(struct btf_type) + l[kind].info_sz + vlen * l[kind].elem_sz;
> +	type_size = sizeof(struct btf_type) + l[kind].info_sz + vlen * l[kind].elem_sz;
> +	if ((size_t)type_size > (size_t)(end_type - (const void *)t)) {

Is it safe to subtract these pointers? When btf_type_size_unknown() is used
outside of parsing, such as in btf_dedup(), t might point to a newly
allocated new_types buffer while end_type points to the old btf->types_data.

Subtracting pointers from distinct memory allocations is undefined behavior
in C, which can cause crashes if tools linking libbpf are compiled with UBSan
using -fsanitize=pointer-subtract. Should this bounds check be relocated
into btf_parse_type_sec() instead?

> +		pr_debug("Overflow in type size %d for kind %u\n",
> +			 type_size, kind);
> +		return -EINVAL;
> +	}
> +	return type_size;
>  }

This patch attempts to fix a pointer wrap-around vulnerability, but does this
approach leave standard BTF kinds vulnerable?

Since the bounds check is only added to btf_type_size_unknown(), standard
kinds like BTF_KIND_STRUCT are evaluated directly in btf_type_size() without
any bounds check.

If a malicious BTF file provides a BTF_KIND_STRUCT with a maximum vlen, it
can yield a type_size up to ~786KB. On a 32-bit system, if the buffer is
allocated near the top of the address space, adding this size could wrap
around to a small value.

The overflow check next_type + type_size > end_type in btf_parse_type_sec()
would then evaluate to false, potentially bypassing validation and leading to
an out-of-bounds write in btf_bswap_type_rest().

Would it be safer to fix the vulnerability for all kinds by changing the
check in btf_parse_type_sec() to avoid pointer addition entirely?

For example:
if ((size_t)type_size > (size_t)(end_type - next_type))

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260422103206.533695-1-alan.maguire@oracle.com?part=1

Re: [PATCH bpf] libbpf: Fix type size overflow in btf_type_size_unknown

[Andrii Nakryiko]

On Wed, Apr 22, 2026 at 3:32 AM Alan Maguire <alan.maguire@oracle.com> wrote:
>
> A layout section with a large elem_sz/vlen can lead to a 32-bit
> overflow in btf_parse_type_sec() at the point where a large
> type_size is added to the next_type [1]; a sufficiently large type_size
> on a 32-bit system could lead to the bounds check
>
>         if (next_type + type_size > end_type)
>
> not triggering (since next_type + type_size wraps to a value low
> in the 32-bit address space).  This would lead to a bad value for
> next_type when we add the type size.  Avoid this by ensuring that
> the type_size we return from btf_type_size_unknown() falls within
> the range of <current type, end_type>.
>
> [1] https://lore.kernel.org/bpf/20260417170712.74E77C19425@smtp.kernel.org/
>
> Reported-by: sashiko <sashiko-bot@kernel.org>
> Fixes: 2ecbe53e0e991 ("libbpf: Use layout to compute an unknown kind size")
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> ---
>  tools/lib/bpf/btf.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>

Is this a real issue? If provided BTF data is corrupted, we don't
really guarantee anything, do we? And if it's not corrupted, then
32-bit overflow cannot happen because btf_header cannot even express a
type section bigger than 4GB.

I'd prefer not to pollute logic with unnecessary defensive checks
meant to satisfy AI complaints.


> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> index ceb57b46a878..d48ac5460d1d 100644
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
> @@ -420,9 +420,11 @@ static int btf_parse_layout_sec(struct btf *btf)
>  static int btf_type_size_unknown(const struct btf *btf, const struct btf_type *t)
>  {
>         __u32 l_cnt = btf->hdr.layout_len / sizeof(struct btf_layout);
> +       const void *end_type = btf->types_data + btf->hdr.type_len;
>         struct btf_layout *l = btf->layout;
>         __u16 vlen = btf_vlen(t);
>         __u32 kind = btf_kind(t);
> +       int type_size;
>
>         /* Fall back to base BTF if needed as they share layout information */
>         if (!l) {
> @@ -448,7 +450,13 @@ static int btf_type_size_unknown(const struct btf *btf, const struct btf_type *t
>                 return -EINVAL;
>         }
>
> -       return sizeof(struct btf_type) + l[kind].info_sz + vlen * l[kind].elem_sz;
> +       type_size = sizeof(struct btf_type) + l[kind].info_sz + vlen * l[kind].elem_sz;
> +       if ((size_t)type_size > (size_t)(end_type - (const void *)t)) {
> +               pr_debug("Overflow in type size %d for kind %u\n",
> +                        type_size, kind);
> +               return -EINVAL;
> +       }
> +       return type_size;
>  }
>
>  static int btf_type_size(const struct btf *btf, const struct btf_type *t)
> --
> 2.39.3
>

Re: [PATCH bpf] libbpf: Fix type size overflow in btf_type_size_unknown

[Alan Maguire]

On 22/04/2026 22:22, Andrii Nakryiko wrote:
> On Wed, Apr 22, 2026 at 3:32 AM Alan Maguire <alan.maguire@oracle.com> wrote:
>>
>> A layout section with a large elem_sz/vlen can lead to a 32-bit
>> overflow in btf_parse_type_sec() at the point where a large
>> type_size is added to the next_type [1]; a sufficiently large type_size
>> on a 32-bit system could lead to the bounds check
>>
>>         if (next_type + type_size > end_type)
>>
>> not triggering (since next_type + type_size wraps to a value low
>> in the 32-bit address space).  This would lead to a bad value for
>> next_type when we add the type size.  Avoid this by ensuring that
>> the type_size we return from btf_type_size_unknown() falls within
>> the range of <current type, end_type>.
>>
>> [1] https://lore.kernel.org/bpf/20260417170712.74E77C19425@smtp.kernel.org/
>>
>> Reported-by: sashiko <sashiko-bot@kernel.org>
>> Fixes: 2ecbe53e0e991 ("libbpf: Use layout to compute an unknown kind size")
>> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
>> ---
>>  tools/lib/bpf/btf.c | 10 +++++++++-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
> 
> Is this a real issue? If provided BTF data is corrupted, we don't
> really guarantee anything, do we? And if it's not corrupted, then
> 32-bit overflow cannot happen because btf_header cannot even express a
> type section bigger than 4GB.
> 

As I understand it, it's the sum of the type_size and the current type pointer that 
could overflow on 32-bit systems; so AI seemed to be saying if the current type pointer 
was high in the 32-bit address space I guess it'd be a theoretical possibility for legit 
BTF, but I'd assume other things would fall over prior to that (how would we even read
that BTF fully into memory?). Maybe there's a way we could finesse the AI prompting to 
avoid garbage-in-garbage-out style problems for libbpf, not sure.


> I'd prefer not to pollute logic with unnecessary defensive checks
> meant to satisfy AI complaints.
>