From: sashiko-bot@kernel.org
To: "Mark Amirkan" <markdamirkan@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next] libbpf: Reject oversized unknown BTF type records
Date: Wed, 02 Sep 2026 09:23:09 +0000 [thread overview]
Message-ID: <20260902092310.5B95E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902091126.59281-1-markdamirkan@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Pointer arithmetic overflow in `btf_parse_type_sec` bounds check allows out-of-bounds memory access on 32-bit architectures.
--
commit ecf66a907aa5b49ad6ebbe3433e5a171a1a7138e
Author: Mark Amirkan <markdamirkan@gmail.com>
libbpf: Reject oversized unknown BTF type records
This patch changes btf_type_size_unknown() to calculate type size using size_t
and rejects sizes greater than INT_MAX. This prevents massive unknown types
from wrapping to negative values when cast to int and crashing libbpf.
> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> index c783359977b46..83a7f199f37df 100644
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
[ ... ]
> @@ -448,7 +449,15 @@ 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 +
> + (size_t)vlen * l[kind].elem_sz;
> + if (type_size > INT_MAX) {
[Severity: High]
This isn't a bug introduced by this patch, but since we are explicitly
allowing type sizes up to INT_MAX, could this trigger a pointer arithmetic
overflow in the caller?
In tools/lib/bpf/btf.c:btf_parse_type_sec(), the size is bounds-checked like
this:
type_size = btf_type_size(btf, next_type);
if (type_size < 0)
return type_size;
if (next_type + type_size > end_type) {
pr_warn("BTF type [%u] is malformed\n", btf->start_id + btf->nr_types);
return -EINVAL;
}
On 32-bit architectures, if type_size is close to INT_MAX and next_type is
high in the address space, next_type + type_size can wrap around. This would
cause the check to erroneously evaluate to false, bypassing the validation and
allowing out-of-bounds memory access.
Would it be safer to subtract pointers to prevent overflow here:
if (type_size > end_type - next_type) {
> + pr_debug("BTF type size %zu for kind %u is too large\n",
> + type_size, kind);
> + return -E2BIG;
> + }
> +
> + return type_size;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260902091126.59281-1-markdamirkan@gmail.com?part=1
next prev parent reply other threads:[~2026-09-02 9:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 9:11 [PATCH bpf-next] libbpf: Reject oversized unknown BTF type records Mark Amirkan
2026-09-02 9:23 ` sashiko-bot [this message]
2026-09-03 0:40 ` Andrii Nakryiko
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=20260902092310.5B95E1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=markdamirkan@gmail.com \
--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.