linux-kernel - [PATCH AUTOSEL 6.12 04/26] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20250530124012.2575409-4-sashal@kernel.org>
Date: Fri, 30 May 2025 08:39:50 -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-kernel@...r.kernel.org,
	clang-built-linux@...glegroups.com
Subject: [PATCH AUTOSEL 6.12 04/26] 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. ##
Detailed Analysis: ### Code Changes Analysis: The commit makes a
targeted fix to `tools/include/nolibc/stdint.h` by replacing: ```c
typedef int64_t intmax_t; typedef uint64_t uintmax_t; ``` with: ```c
typedef __INTMAX_TYPE__ intmax_t; typedef __UINTMAX_TYPE__ uintmax_t;
``` ### Problem Being Fixed: This addresses a **compiler format checking
incompatibility** where: - The compiler's printf format checking uses
intmax types from the compiler itself, not from libc - This mismatch
causes compilation errors with clang 19 on arm64 - The error occurs
because nolibc defined intmax_t as `unsigned long long` while the
compiler expected `unsigned long` ### Evidence Supporting Backport: **1.
Similar Pattern Match:** This closely follows the pattern of Similar
Commit #4 and #5 (both marked YES for backport): - Similar Commit #4:
Fixed integer type definitions for 32-bit platforms (backported) -
Similar Commit #5: Fixed printf format mismatches with compiler warnings
(backported with Cc: stable@...r.kernel.org) **2. Bug Fix Nature:** This
is clearly a **bug fix** that: - Resolves compilation failures with
clang 19 - Fixes format checking incompatibilities between compiler and
library definitions - Affects actual build failures, not just warnings
**3. Low Risk/High Impact:** - **Minimal change scope**: Only changes 2
typedef lines - **Contained to nolibc**: Affects only the tools/nolibc
subsystem - **Uses compiler-provided types**: More robust than hardcoded
definitions - **Fixes build breakage**: Critical for users with newer
compilers **4. Aligns with Stable Criteria:** - Fixes important build
issues affecting users - Small, contained change with minimal regression
risk - No architectural changes or new features - Resolves compatibility
with current/newer toolchains **5. Historical Context:** From the kernel
repository examination: - Previous similar format-related fixes (commit
92098b1c10cb) were already tagged for stable with `Cc:
stable@...r.kernel.org` - The nolibc subsystem has a history of
backporting compiler compatibility fixes - The pattern of using
compiler-provided types (like `__SIZE_TYPE__`) is already established in
the codebase **6. User Impact:** This prevents build failures for users
with: - clang 19 on arm64 - Potentially other compiler/architecture
combinations where intmax_t definitions differ - Any nolibc-based
applications or tests The commit represents exactly the type of fix that
stable trees are designed for: a small, targeted fix that resolves build
breakage without introducing new features or architectural changes.

 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