Re: [PATCH 00/11] kobject: Require explicit initialization of struct kobj_type::release

On Wed, Oct 14, 2026 at 9:37 AM Kees Cook [off-list ref] wrote:

On Wed, Oct 14, 2026 at 07:36:41AM +0200, Greg Kroah-Hartman wrote:

quoted

On Tue, Oct 13, 2026 at 03:39:35PM -0700, Ian Rogers wrote:

quoted

Clang supports the 'require_explicit_initialization' attribute on struct
fields to enforce that the field is explicitly initialized when an
aggregate object is constructed, emitting -Wuninitialized-explicit-init
(enabled by default) if the field is omitted.

Following discussion at the Linux Plumbers Conference [1], this series
introduces __require_explicit_initialization in
include/linux/compiler_attributes.h and applies it to
struct kobj_type::release.

Cool, sorry I missed that talk.

Yeah, I'm really liking these compile-time checks. :)

quoted

quoted

As Documentation/core-api/kobject.rst notes:
  "One important point cannot be overstated: every kobject must have a
  release() method, and the kobject must persist (in a consistent state)
  until that method is called. If these constraints are not met, the code
  is flawed."

Annotating struct kobj_type::release caught 30 struct kobj_type
definitions across the tree that omitted .release:
- Patches 2-10 fix 10 struct kobj_type definitions where dynamically
  allocated kobjects, ksets, or enclosing structures were either leaked on
  kobject_put() or freed prematurely before kobject release (risking a
  use-after-free when CONFIG_DEBUG_KOBJECT_RELEASE=y).
- Patch 11 annotates struct kobj_type::release with
  __require_explicit_initialization and explicitly sets .release = NULL
  (with explanatory comments) on the remaining legacy struct kobj_type
  definitions whose kobjects are static, per-CPU, or embedded in devm- or
  parent-managed structures.

Sounds great, but let's fix up the users before adding the attribute.
Looks like some of these need another version so it might take a bit of
time to get them all merged.

I'd really like to have the attribute available, and I've got at least
one user I can apply today that don't require fix-ups (seq_file), so
if Miguel is okay with it, I'd like to snag patch 1 and send it with
my seq_file "first user" for this coming merge window so it's available
starting with v7.4-rc1, and we don't end up needing to wait 10 weeks for
other subsystems to be able to use it. And the kobj fixups can continue
in parallel. Does that sounds okay?

I'm happy with that. I'm working to address/incorporate the other
feedback for a v2 of this series, but I can drop individual patches
that have already been merged. Thanks, everyone, for the positive
reception in getting this landed, I plan to follow up with patch
series for the other uses I found.

Thanks!
Ian

--
Kees Cook