linux-kernel - Re: [PATCH 1/1] alloc_tag: work around clang-14 issue with __builtin_object

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] [day] [month] [year] [list]

Message-ID: <202502061011.BD9611CEA@keescook>
Date: Thu, 6 Feb 2025 10:13:21 -0800
From: Kees Cook <kees@...nel.org>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Suren Baghdasaryan <surenb@...gle.com>, akpm@...ux-foundation.org,
	nathan@...nel.org, ndesaulniers@...gle.com, morbo@...gle.com,
	justinstitt@...gle.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
	kernel test robot <lkp@...el.com>
Subject: Re: [PATCH 1/1] alloc_tag: work around clang-14 issue with
 __builtin_object_size()

On Wed, Feb 05, 2025 at 03:16:12PM -0500, Kent Overstreet wrote:
> On Wed, Feb 05, 2025 at 11:18:35AM -0800, Kees Cook wrote:
> > On Sat, Feb 01, 2025 at 12:05:03PM -0800, Suren Baghdasaryan wrote:
> > To Kent's comment[1], I believe I was using __builtin_object_size() here
> > because I have a knee-jerk aversion to sizeof() due to it blowing up on
> > flexible arrays, but that's not relevant here. ARRAY_SIZE() would work,
> > but only if type checking to "char *" succeeds, as Kent suggests.
> 
> Yeah, that rational for __builtin_object_size() makes sense - although
> it's not what the gcc docs say, those talk about getting the size from
> an attribute on the allocation function (!).
> 
> ARRAY_SIZE() is sizeof() underneath, just used creatively to guarantee
> that the input is an array - although that property is probably what we
> want here, since strtomem_pad() really only makes sense on static or
> flex-arrays, no?

Okay, here's my proposed fix, and confirmed that it solves the problem:
https://lore.kernel.org/lkml/20250206175216.work.225-kees@kernel.org

-Kees

-- 
Kees Cook