Clang 20 and 21 miscompute __builtin_object_size() when -fprofile-arcs
is active on 32-bit UML targets, which passes incorrect object size
calculations for local variables through always_inline copy_to_user()
and check_copy_size(), causing spurious compile-time errors:

  include/linux/ucopysize.h:52:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small

The regression was introduced in LLVM commit 02b8ee281947 ("[llvm]
Improve llvm.objectsize computation by computing GEP, alloca and malloc
parameters bound"), which shipped in Clang 20. It was fixed in LLVM
by commit 45b697e610fd ("[MemoryBuiltins] Consider index type size
when aggregating gep offsets"), which was backported to the LLVM 22.x
release branch.

The bug requires 32-bit UML + GCOV_PROFILE_ALL (which uses -fprofile-arcs),
though the exact trigger depends on optimizer decisions influenced by other
enabled configs.

Prevent the bad combination by disabling UML's ARCH_HAS_GCOV_PROFILE_ALL
on 32-bit when using Clang 20.x or 21.x.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604030531.O6FveVgn-lkp@intel.com/
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Assisted-by: Claude:claude-opus-4-6[1m]
Signed-off-by: Kees Cook <kees@kernel.org>
---
 v3: disable via ARCH_HAS_GCOV_PROFILE_ALL instead (Nathan)
 v2: https://lore.kernel.org/lkml/20260408162607.it.347-kees@kernel.org/
 v1: https://lore.kernel.org/lkml/20260408005958.work.271-kees@kernel.org/
Cc: Richard Weinberger <richard@nod.at>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Peter Oberparleiter <oberpar@linux.ibm.com>
Cc: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
Cc: Bill Wendling <morbo@google.com>
Cc: Justin Stitt <justinstitt@google.com>
Cc: <llvm@lists.linux.dev>
Cc: <linux-um@lists.infradead.org>
---
 arch/um/Kconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/um/Kconfig b/arch/um/Kconfig
index 098cda44db22..d9541d13d9eb 100644
--- a/arch/um/Kconfig
+++ b/arch/um/Kconfig
@@ -11,7 +11,9 @@ config UML
 	select ARCH_HAS_CACHE_LINE_SIZE
 	select ARCH_HAS_CPU_FINALIZE_INIT
 	select ARCH_HAS_FORTIFY_SOURCE
-	select ARCH_HAS_GCOV_PROFILE_ALL
+	# Clang 20 & 21 miscompute __builtin_object_size() under -fprofile-arcs
+	# on 32-bit, causing spurious compile-time errors in check_copy_size().
+	select ARCH_HAS_GCOV_PROFILE_ALL if !(!64BIT && CLANG_VERSION >= 200000 && CLANG_VERSION < 220100)
 	select ARCH_HAS_KCOV
 	select ARCH_HAS_STRNCPY_FROM_USER
 	select ARCH_HAS_STRNLEN_USER
-- 
2.34.1

Hi,

Maybe the subject should say "um:" instead of "gcov:" now?

(I'm assuming you want us to apply it to uml tree.)

> Prevent the bad combination by disabling UML's ARCH_HAS_GCOV_PROFILE_ALL
> on 32-bit when using Clang 20.x or 21.x.

You say 20.x or 21.x,

> +	# Clang 20 & 21 miscompute __builtin_object_size() under -fprofile-arcs
> +	# on 32-bit, causing spurious compile-time errors in check_copy_size().
> +	select ARCH_HAS_GCOV_PROFILE_ALL if !(!64BIT && CLANG_VERSION >= 200000 && CLANG_VERSION < 220100)

and I see that 22.0 doesn't even exist, and maybe that's a general
pattern, but it still looks confusing? Wouldn't it be better simpler to
say < 220000? At least to me that more obviously is "up to 21.x". After
all, 20.0 also didn't exist, and you did >=200000, not >200000 or
>=200100?

johannes

On Thu, Apr 09, 2026 at 04:47:32PM +0200, Johannes Berg wrote:
> Hi,
> 
> Maybe the subject should say "um:" instead of "gcov:" now?
> 
> (I'm assuming you want us to apply it to uml tree.)
> 
> > Prevent the bad combination by disabling UML's ARCH_HAS_GCOV_PROFILE_ALL
> > on 32-bit when using Clang 20.x or 21.x.
> 
> You say 20.x or 21.x,
> 
> > +	# Clang 20 & 21 miscompute __builtin_object_size() under -fprofile-arcs
> > +	# on 32-bit, causing spurious compile-time errors in check_copy_size().
> > +	select ARCH_HAS_GCOV_PROFILE_ALL if !(!64BIT && CLANG_VERSION >= 200000 && CLANG_VERSION < 220100)
> 
> and I see that 22.0 doesn't even exist, and maybe that's a general
> pattern, but it still looks confusing? Wouldn't it be better simpler to
> say < 220000? At least to me that more obviously is "up to 21.x". After
> all, 20.0 also didn't exist, and you did >=200000, not >200000 or
> >=200100?

22.0.0 means a development cycle version of LLVM 22, whereas 22.1.0 is
the released version (mirroring how GCC versioning works). The bug was
not fixed in the 22 development cycle, it was fixed at the beginning of
the 23 development cycle then backported to 22.1.0 before the final
release, so I think the bounds is correct as it is. We assume all
versions of 20 and 21 and the development version of 22 have the bug.

Cheers,
Nathan