From: sashiko-bot@kernel.org
To: "Guangshuo Li" <lgs201920130244@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH] libbpf: Check full backing type size for bitfield dump
Date: Sun, 05 Jul 2026 03:38:32 +0000 [thread overview]
Message-ID: <20260705033832.C84101F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260705032603.275766-1-lgs201920130244@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The stricter bounds check using `t->size` incorrectly rejects valid narrow bitfields in packed structs, causing a false positive `-E2BIG` failure.
- [Medium] The bounds check for bitfields was updated in `btf_dump_get_bitfield_value` to use `t->size`, but the early bounds check in `btf_dump_type_data_check_overflow` was left unpatched, causing inconsistent behavior.
- [Low] Unused local variables `start_bit` and `nr_bytes` are left behind after the patch.
--
commit dcf1121c5988139c35dcd52cf31ce52003f38d43
Author: Guangshuo Li <lgs201920130244@gmail.com>
libbpf: Check full backing type size for bitfield dump
This patch updates the bounds check in btf_dump_get_bitfield_value() to use
the full backing type size instead of just the bitfield span. This prevents
out-of-bounds reads when constructing bitfield values from narrow data
buffers.
> diff --git a/tools/lib/bpf/btf_dump.c b/tools/lib/bpf/btf_dump.c
> index cc1ba65bb6c5a..a49790e356a83 100644
> --- a/tools/lib/bpf/btf_dump.c
> +++ b/tools/lib/bpf/btf_dump.c
> @@ -1771,7 +1771,7 @@ static int btf_dump_get_bitfield_value(struct btf_dump *d,
> nr_bytes = (start_bit + bit_sz + 7) / 8;
[Severity: Low]
Are start_bit and nr_bytes now unused variables? Since the bounds check
below was updated to use t->size instead of nr_bytes, it looks like these
calculations are dead code and might trigger compiler warnings.
>
> /* Bound check */
> - if (data + nr_bytes > d->typed_dump->data_end)
> + if (data + t->size > d->typed_dump->data_end)
[Severity: High]
Will this stricter bounds check reject valid narrow bitfields in packed
structs? If a user dumps a 1-byte packed struct containing an int
bitfield (e.g., int a:8), the backing type size (t->size) will be 4, but
the valid data size is only 1 byte. Could this cause the libbpf BTF dump
API to fail with -E2BIG for valid structs?
[Severity: Medium]
Does this change create an inconsistency with the early bounds check in
btf_dump_type_data_check_overflow()?
Looking at btf_dump_type_data_check_overflow() in the same file:
if (btf_is_bitfield(t)) {
...
return data + nr_bytes > d->typed_dump->data_end ? -E2BIG : nr_bytes;
}
Since that function still uses nr_bytes, could it succeed while this
function fails, resulting in partial and malformed output where the dump
prints the struct member prefix but fails during value retrieval?
> return -E2BIG;
>
> /* Maximum supported bitfield size is 64 bits */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260705032603.275766-1-lgs201920130244@gmail.com?part=1
next prev parent reply other threads:[~2026-07-05 3:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-05 3:26 [PATCH] libbpf: Check full backing type size for bitfield dump Guangshuo Li
2026-07-05 3:38 ` sashiko-bot [this message]
2026-07-05 22:39 ` Varun R Mallya
2026-07-06 2:29 ` Guangshuo Li
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=20260705033832.C84101F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=lgs201920130244@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.