From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Hungyu Lin" <dennylin0707@gmail.com>, <andrii@kernel.org>,
<bpf@vger.kernel.org>
Cc: <eddyz87@gmail.com>, <ihor.solodrai@linux.dev>,
<daniel@iogearbox.net>, <memxor@gmail.com>,
<martin.lau@linux.dev>, <song@kernel.org>,
<yonghong.song@linux.dev>, <jolsa@kernel.org>,
<emil@etsalapatis.com>, <alan.maguire@oracle.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next] libbpf: Fix sign extension of unaligned enums in btf_dump_get_enum_value()
Date: Sat, 14 Nov 2026 05:58:41 +0000 [thread overview]
Message-ID: <DMUPC8KHIGGC.1GSNJVGA8XC98@gmail.com> (raw)
In-Reply-To: <20261113223449.97604-1-dennylin0707@gmail.com>
On Fri, Nov 13, 2026 at 02:34 PM Hungyu Lin <dennylin0707@gmail.com> wrote:
> btf_dump_get_enum_value() reads unaligned enum values through
> btf_dump_get_bitfield_value() with a zero bit size. That path
> zero-extends the value instead of using the signed loads that are used
Not quite. bit_sz == 0 makes right_shift_bits == 64 in
*value = (num << left_shift_bits) >> right_shift_bits;
That's undefined behavior for __u64 on both endians.
Pls say it in the commit log.
> + if (t->size <= sizeof(buf) && !ptr_is_aligned(d->btf, id, data)) {
> + if (data + t->size > d->typed_dump->data_end)
> + return -E2BIG;
This breaks the dump of struct fs_context when emit_zeroes is not set.
'phase' is an enum bitfield of 8 bits, 3 bytes before the end of the
struct. btf_dump_type_data_check_zero() ignores bit_sz of an enum:
btf_dump_struct_data()
btf_dump_dump_type_data(data = end - 3, bit_sz = 8)
btf_dump_type_data_check_overflow() 1 byte, ok
btf_dump_type_data_check_zero()
btf_dump_get_enum_value() t->size == 4, unaligned
end - 3 + 4 > data_end -E2BIG
Today it reads 1 byte past data_end and the dump succeeds.
The over-read is an old bug of enum bitfields. It needs its own fix.
The fs_context test in test_btf_dump_struct_data() sets emit_zeroes,
so it doesn't notice.
Drop the check. btf_dump_int_data() copies without it.
The check against data_end belongs in one place for all types.
The first case below fails on bpf-next today.
The second case fails with this patch.
I didn't build it and didn't run it:
diff --git a/tools/testing/selftests/bpf/prog_tests/btf_dump.c b/tools/testing/selftests/bpf/prog_tests/btf_dump.c
index b5c90f7..d6fd993 100644
--- a/tools/testing/selftests/bpf/prog_tests/btf_dump.c
+++ b/tools/testing/selftests/bpf/prog_tests/btf_dump.c
@@ -945,7 +945,7 @@ static void test_btf_dump_enum_data(struct btf *btf, struct btf_dump *d,
char *str)
{
__u32 high = 0x80000000;
- __s32 neg = -1;
+ __s32 neg[2] = { -1, -1 };
/* enum where enum value does (and does not) exist */
TEST_BTF_DUMP_DATA_C(btf, d, "enum", str, enum bpf_cmd, BTF_F_COMPACT,
@@ -994,6 +994,8 @@ static void test_btf_dump_enum_data(struct btf *btf, struct btf_dump *d,
"(enum test_enum_u32)TEST_ENUM_HIGH"), "dump unsigned enum");
ASSERT_OK(btf_dump_data(btf, d, "test_enum_s32", NULL, 0, &neg, 4, str,
"(enum test_enum_s32)TEST_ENUM_NEG"), "dump signed enum");
+ ASSERT_OK(btf_dump_data(btf, d, "test_enum_s32", NULL, 0, (void *)neg + 1, 4, str,
+ "(enum test_enum_s32)TEST_ENUM_NEG"), "dump unaligned enum");
btf_dump__free(d);
}
@@ -1182,6 +1184,12 @@ static void test_btf_dump_struct_data(struct btf *btf, struct btf_dump *d,
type_sz = btf__resolve_size(btf, type_id);
str[0] = '\0';
+ /* 'phase' is an enum bitfield 3 bytes before the end */
+ ret = btf_dump__dump_type_data(d, type_id, zero_data, type_sz, &opts);
+ ASSERT_EQ(ret, type_sz,
+ "unexpected return value dumping zeroed fs_context");
+
+ str[0] = '\0';
opts.emit_zeroes = true;
ret = btf_dump__dump_type_data(d, type_id, zero_data, type_sz, &opts);
ASSERT_EQ(ret, type_sz,
pw-bot: cr
prev parent reply other threads:[~2026-11-14 5:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 22:34 [PATCH bpf-next] libbpf: Fix sign extension of unaligned enums in btf_dump_get_enum_value() Hungyu Lin
2026-11-13 22:55 ` sashiko-bot
2026-11-14 5:58 ` Alexei Starovoitov [this message]
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=DMUPC8KHIGGC.1GSNJVGA8XC98@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dennylin0707@gmail.com \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=song@kernel.org \
--cc=yonghong.song@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.