Re: [GIT PULL] kmalloc_obj treewide refactor for v7.0-rc1

[Eric Biggers]

On Sat, Feb 21, 2026 at 03:19:56PM -0800, Kees Cook wrote:
> On Sat, Feb 21, 2026 at 03:01:15PM -0800, Linus Torvalds wrote:
> > But I think I found the real bug:
> > 
> >    #define overflows_flex_counter_type(TYPE, FAM, COUNT)           \
> >            (!overflows_type(COUNT, typeof_flex_counter(((TYPE *)NULL)->FAM)))
> > 
> > WTF is up with that '!' there? That seems entirely bogus. So now
> > overflows_flex_counter_type() will return true in it *doesn't*
> > overflow the type.
> > 
> > So I think clang was not actually the problem. That whole code looks buggy.
> 
> I would agree. This code mutated a few times but the logic and
> docs for this function are in sync ("Returns: true if @COUNT can be
> represented") but I renamed it somewhere along the way in a confusing
> way and then got the above quoted macro's usage wrong.
> 
> > But that actually makes me *less* happy, because it means that this
> > whole patch must have been ENTIRELY untested in any shape or form.
> > 
> > If I read this right, none of this should have successfully booted
> > anywhere if you had actually tested it outside of just compile-testing
> > it.
> 
> Right, I am surprised as well, since I explicitly did boot testing on
> the tree-wide refactor, though I admit the most recent validation over
> the last few weeks has been on the compile testing side due to tracking
> down type mismatches.
> 
> FWIW, I have now been able to reproduce the objtool warning, though,
> using Fedora 42's Clang 20. I'm frustrated that it didn't show with the
> other builds I did, and that 0day never sent a single email about it
> over the weeks that I've had my tree up for testing.

Just spent a while bisecting why the kernel wasn't booting on
8934827db540 with clang 21.1.8 before I noticed Linus's fix (for a pull
request that wasn't Cc'ed to any mailing lists other than linux-kernel).

Do we have a sense of how this made it in?  __flex_counter expands to
'(void *)NULL' for clang versions before 22 (despite the incorrect
comment above it that says clang >= 19), causing typeof_flex_counter to
evaluate to size_t, causing (!overflows_type(COUNT,
typeof_flex_counter(((TYPE *)NULL)->FAM))) to always be true on 64-bit.
So it looks like k*alloc_flex() always returned NULL, unless the kernel
was built with pre-release clang 22.  Not sure what I'm missing.

It looks like the conversions of kmalloc() et al to kmalloc_flex() et al
were never in linux-next, so presumably that was a factor?

- Eric