linux-kernel - [PATCH AUTOSEL 6.12 91/93] tools/nolibc: use intmax definitions from compiler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250601233402.3512823-91-sashal@kernel.org>
Date: Sun,  1 Jun 2025 19:33:58 -0400
From: Sasha Levin <sashal@...nel.org>
To: patches@...ts.linux.dev,
	stable@...r.kernel.org
Cc: Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
	Willy Tarreau <w@....eu>,
	Sasha Levin <sashal@...nel.org>,
	linux@...ssschuh.net,
	nathan@...nel.org,
	linux-kernel@...r.kernel.org,
	llvm@...ts.linux.dev
Subject: [PATCH AUTOSEL 6.12 91/93] tools/nolibc: use intmax definitions from compiler

From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>

[ Upstream commit e5407c0820ea5fa7117b85ed32b724af73156d63 ]

The printf format checking in the compiler uses the intmax types from
the compiler, not libc. This can lead to compiler errors.

Instead use the types already provided by the compiler.

Example issue with clang 19 for arm64:

nolibc-test.c:30:2: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uintmax_t' (aka 'unsigned long long') [-Werror,-Wformat]

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Acked-by: Willy Tarreau <w@....eu>
Signed-off-by: Sasha Levin <sashal@...nel.org>
---

**YES** This commit should be backported to stable kernel trees. Here's
my extensive analysis: ## Analysis of the Code Changes The commit makes
a targeted fix to resolve compiler format checking errors by changing
the intmax type definitions in `tools/include/nolibc/stdint.h`: ```c
-typedef int64_t intmax_t; -typedef uint64_t uintmax_t; +typedef
__INTMAX_TYPE__ intmax_t; +typedef __UINTMAX_TYPE__ uintmax_t; ``` ##
Why This Should Be Backported ### 1. **Fixes Real Compilation Errors**
The commit addresses actual compiler errors that prevent successful
builds, as demonstrated by the clang 19 error message: ``` nolibc-
test.c:30:2: error: format specifies type 'uintmax_t' (aka 'unsigned
long') but the argument has type 'uintmax_t' (aka 'unsigned long long')
[-Werror,-Wformat] ``` This is a critical build breakage, not just a
warning. ### 2. **Small, Contained, Low-Risk Change** - Only changes 2
lines of code in a single header file - Does not modify any algorithms
or control flow - Uses well-established compiler built-ins that have
been available for decades - No risk of behavioral changes beyond fixing
the type compatibility issue ### 3. **Follows Established Pattern** The
change aligns with existing practice in the same file, which already
uses `__SIZE_TYPE__` for `size_t` definition. This demonstrates that
using compiler built-ins for fundamental types is the established
approach in nolibc. ### 4. **Cross-Platform Compatibility Fix** The
issue particularly affects: - Different compiler backends (GCC vs Clang)
- Different architectures where `long` vs `long long` sizes vary
(especially arm64) - Cross-compilation scenarios - Builds with strict
format checking enabled (`-Wformat -Werror`) ### 5. **Comparison with
Similar Commits** Looking at the reference commits provided: - **Similar
Commit #4** (Status: YES): Also fixes integer type issues in nolibc for
platform compatibility - **Similar Commit #5** (Status: YES): Also fixes
printf format mismatches with explicit stable tree marking (`Cc:
stable@...r.kernel.org`) This commit follows the same pattern of fixing
type/format compatibility issues that have been deemed worthy of
backporting. ### 6. **Tools Subsystem Stability** While this is in the
tools directory, nolibc is used for: - Kernel testing infrastructure -
Minimal userspace environments - Cross-compilation toolchains - Kernel
selftests Breaking builds in these contexts can impact kernel
development workflows across different platforms. ### 7. **No
Architectural Changes** The commit: - Doesn't introduce new features -
Doesn't change APIs - Doesn't modify kernel core functionality - Simply
ensures type consistency between compiler and library definitions ##
Conclusion This is exactly the type of targeted bug fix that stable
trees are designed for: it fixes a real compilation issue that affects
users, uses a minimal and safe approach, follows established patterns,
and has no risk of introducing regressions. The fix ensures that nolibc
can be compiled successfully across different compiler/architecture
combinations, which is essential for kernel development infrastructure.

 tools/include/nolibc/stdint.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/include/nolibc/stdint.h b/tools/include/nolibc/stdint.h
index cd79ddd6170e0..b052ad6303c38 100644
--- a/tools/include/nolibc/stdint.h
+++ b/tools/include/nolibc/stdint.h
@@ -39,8 +39,8 @@ typedef   size_t      uint_fast32_t;
 typedef  int64_t       int_fast64_t;
 typedef uint64_t      uint_fast64_t;
 
-typedef  int64_t           intmax_t;
-typedef uint64_t          uintmax_t;
+typedef __INTMAX_TYPE__    intmax_t;
+typedef __UINTMAX_TYPE__  uintmax_t;
 
 /* limits of integral types */
 
-- 
2.39.5