From: sashiko-bot@kernel.org
To: Tw <tw19881113@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v2] libpf: Fix for the potential undefined behavior due to shifting
Date: Thu, 27 Aug 2026 00:15:12 +0000 [thread overview]
Message-ID: <20260827001513.129011F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260827001007.1420507-1-tw19881113@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch attempts to fix undefined behavior in `BTF_INFO_ENC` but places the cast incorrectly, leaving the undefined behavior unresolved. According to the C standard (C11 6.5.3.3), the logical negation operator `!` always yields a signed `int` (0 or 1), regardless of the operand's type. Thus, `!!((__u32)kind_flag)` evaluates to a signed `int`. Left-shifting this signed `int` by 31 places (`!!(...) << 31`) continues to trigger undefined behavior by shifting a bit into the sign bit of a 32-bit signed integer. To correctly prevent the undefined behavior, the cast must be applied after the logical negation, e.g., `((__u32)!!(kind_flag) << 31)`.
--
commit ce021dde7807eb8995ad265d12e0e7372294cfb7
Author: Tw <tw19881113@gmail.com>
libpf: Fix for the potential undefined behavior due to shifting
This patch aims to fix an undefined behavior issue reported by UBSAN in
libbpf ("left shift of 1 by 31 places cannot be represented in type 'int'")
by casting the operand to an unsigned type before shifting.
[ ... ]
> diff --git a/tools/lib/bpf/libbpf_internal.h b/tools/lib/bpf/libbpf_internal.h
> index 4c46d34fc055d..2df1df3f3f22c 100644
> --- a/tools/lib/bpf/libbpf_internal.h
> +++ b/tools/lib/bpf/libbpf_internal.h
> @@ -77,7 +77,7 @@
> #define JUMPTABLES_SEC ".jumptables"
>
> #define BTF_INFO_ENC(kind, kind_flag, vlen) \
> - ((!!(kind_flag) << 31) | ((kind) << 24) | ((vlen) & BTF_MAX_VLEN))
> + ((!!((__u32)kind_flag) << 31) | ((kind) << 24) | ((vlen) & BTF_MAX_VLEN))
[Severity: Medium]
Does this cast actually resolve the undefined behavior, or is the regression
still present?
According to C11 6.5.3.3, the logical negation operator (!) always yields a
signed int (0 or 1), regardless of the operand's type. This means
!!((__u32)kind_flag) evaluates to a signed int.
Left-shifting this signed int by 31 places continues to shift a bit into
the sign bit of a 32-bit signed integer.
Could the cast be applied after the logical negation instead, such as
((__u32)!!(kind_flag) << 31)?
> #define BTF_TYPE_ENC(name, info, size_or_type) (name), (info), (size_or_type)
> #define BTF_INT_ENC(encoding, bits_offset, nr_bits) \
> ((encoding) << 24 | (bits_offset) << 16 | (nr_bits))
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260827001007.1420507-1-tw19881113@gmail.com?part=1
prev parent reply other threads:[~2026-08-27 0:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 0:08 [PATCH v2] libpf: Fix for the potential undefined behavior due to shifting Tw
2026-08-27 0:15 ` sashiko-bot [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=20260827001513.129011F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tw19881113@gmail.com \
/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.