All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Naveed Khan" <naveed@digiscrypt.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH] libbpf: bounds-check float size in btf_dump_float_data()
Date: Tue, 23 Jun 2026 08:03:01 +0000	[thread overview]
Message-ID: <20260623080301.8DE491F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <178220124597.31744.3595561672327420327@digiscrypt.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Architecture-dependent bounds check breaks dumping of 16-byte floats on 32-bit architectures
--

commit 31fd1a7664b926003f6e360a24ed9cc2bcd8b9c5
Author: Naveed Khan <naveed@digiscrypt.com>

libbpf: bounds-check float size in btf_dump_float_data()

This commit adds a bounds check to btf_dump_float_data() in libbpf to
prevent a stack buffer overflow. It ensures the size of the float type from
the BTF data doesn't exceed the size of the local union used for unaligned
copies.

> diff --git a/tools/lib/bpf/btf_dump.c b/tools/lib/bpf/btf_dump.c
> index cc1ba65bb6c5a..922c8ce32c2ff 100644
> --- a/tools/lib/bpf/btf_dump.c
> +++ b/tools/lib/bpf/btf_dump.c
> @@ -1983,6 +1983,11 @@ static int btf_dump_float_data(struct btf_dump *d,
>  	union float_data fl;
>  	int sz = t->size;
>  
> +	if (sz < 0 || sz > sizeof(fl)) {
> +		pr_warn("unexpected size %d for id [%u]\n", sz, type_id);
> +		return -EINVAL;
> +	}
> +

[Severity: Medium]
Does this bounds check prevent dumping 16-byte floats when running on 32-bit
architectures?

On 32-bit architectures, sizeof(union float_data) may be 8 or 12 depending on
the size of long double. If we process a valid float type with sz = 16, this
check will evaluate to true and return -EINVAL.

Looking further down in btf_dump_float_data(), the function has a handler for
16-byte floats:

	switch (sz) {
	case 16:
		btf_dump_type_values(d, "%Lf", flp->ld);
		break;

Because sz == 16 is expected, this check makes the case 16: statement
unreachable on those platforms.

Should this code allocate a fixed 16-byte stack buffer to receive the
memcpy() instead of relying on the architecture-dependent size of
union float_data?

>  	/* handle unaligned data; copy to local union */
>  	if (!ptr_is_aligned(d->btf, type_id, data)) {
>  		memcpy(&fl, data, sz);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/178220124597.31744.3595561672327420327@digiscrypt.com?part=1

  reply	other threads:[~2026-06-23  8:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23  7:54 [PATCH] libbpf: bounds-check float size in btf_dump_float_data() Naveed Khan
2026-06-23  8:03 ` sashiko-bot [this message]
2026-06-23  8:29 ` bot+bpf-ci
2026-06-23 20:43 ` Andrii Nakryiko
2026-06-24 10:10   ` [PATCH v2] " Naveed Khan
2026-06-24 10:23     ` sashiko-bot
2026-06-24 16:49     ` 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=20260623080301.8DE491F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=naveed@digiscrypt.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.