Re: [PATCH v2 9/9] kobject: Require explicit initialization of struct kobj_type::release

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] fbdev: omapdss: inaccurate kobj_type comments for managers and overlays
- [Low] kobject: inaccurate kobj_type comments on static lifetime and delayed release
--

commit 2811dd0d4494f584b7b3fad73d8e6b9f2f067c96
Author: Ian Rogers <irogers@google.com>

kobject: Require explicit initialization of struct kobj_type::release

This commit annotates struct kobj_type::release with __must_init so the
compiler diagnoses any struct kobj_type initializer that omits .release. For
remaining legacy struct kobj_type definitions that do not free their kobject
via kobject_put(), it explicitly initializes .release = NULL with comments
documenting the kobject lifetime and CONFIG_DEBUG_KOBJECT_RELEASE behavior.

Link: https://lpc.events/event/20/contributions/2392/

>     kobject: Require explicit initialization of struct kobj_type::release
>     
>     Documentation/core-api/kobject.rst states:
>     
>       "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. Note that the kernel will warn you if you forget to provide
>       a release() method. Do not try to get rid of this warning by providing
>       an \"empty\" release function."
>     
>     Annotate struct kobj_type::release with __must_init
>     so the compiler diagnoses any struct kobj_type initializer that omits
>     .release.
>     
>     For the remaining legacy struct kobj_type definitions where the kobject
>     is static, per-CPU, permanent firmware structures, or embedded inside a
>     devm- or parent-managed structure rather than freed by kobject_put(),
>     explicitly initialize .release = NULL with a comment documenting why no
>     release callback is provided.
>     
>     Where the existing teardown is not safe with CONFIG_DEBUG_KOBJECT_RELEASE,
>     because the kobject's memory can be freed or cleared while the delayed
>     kobject cleanup is still pending (ioat, kunpeng_hccs and omapfb display),
>     the comment says so. Fixing those is left to follow-up patches; this
>     change does not alter their behavior.
>     
>     Link: https://lpc.events/event/20/contributions/2392/
>     Signed-off-by: Ian Rogers <irogers@google.com>

[Severity: Low]
The commit message notes that where existing teardown is not safe with
CONFIG_DEBUG_KOBJECT_RELEASE (listing ioat, kunpeng_hccs, and omapfb
display), the comment says so.

Are there additional kobj_type definitions touched in this patch where the
backing memory is freed, zeroed, or unmapped while delayed kobject cleanup is
still pending under CONFIG_DEBUG_KOBJECT_RELEASE, such as omapfb manager_ktype
and overlay_ktype, amdgpu ualink_xcp_info_ktype and xcp_sysfs_ktype, hfi1
sde_ktype, usnic usnic_ib_qpn_type, ab8500_fg_ktype (on the
kobject_init_and_add() error path in ab8500_fg_sysfs_init() before devm frees
di), and the static kobjects/ksets in loadable modules (erofs, f2fs, ocfs2,
and pdc_stable on module unload)?

> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c
> index 17888cf544472..c2cccd924b03c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c
> @@ -885,6 +885,11 @@ static const struct attribute_group ualink_xcp_info_group = {
>  };
>  
>  static const struct kobj_type ualink_xcp_info_ktype = {
> +	/*
> +	 * Pre-existing: xcp->ualink.kobj is embedded in struct amdgpu_xcp_mgr
> +	 * rather than freed individually by kobject_put().
> +	 */
> +	.release = NULL,
>  	.sysfs_ops = &kobj_sysfs_ops
>  };
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c
> index ab14079d1c422..0847134a13917 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c

[ ... ]

> @@ -1061,6 +1066,11 @@ static const struct attribute_group amdgpu_xcp_attrs_group = {
>  };
>  
>  static const struct kobj_type xcp_sysfs_ktype = {
> +	/*
> +	 * Pre-existing: xcp is embedded in struct amdgpu_xcp_mgr
> +	 * rather than freed individually by kobject_put().
> +	 */
> +	.release = NULL,
>  	.sysfs_ops = &kobj_sysfs_ops,
>  };

[Severity: Low]
Should the comments on ualink_xcp_info_ktype and xcp_sysfs_ktype also note the
CONFIG_DEBUG_KOBJECT_RELEASE use-after-free hazard?

During teardown, amdgpu_device_fini_hw() calls amdgpu_ualink_sysfs_fini() and
amdgpu_xcp_sysfs_fini(), which call kobject_put(&xcp->ualink.kobj) and
kobject_put(&xcp->kobj), and then amdgpu_device_fini_sw() frees adev->xcp_mgr
while delayed kobject cleanup may still be pending.

> diff --git a/drivers/infiniband/hw/hfi1/sysfs.c b/drivers/infiniband/hw/hfi1/sysfs.c
> index 372cfd13dc616..5a1aca06b542b 100644
> --- a/drivers/infiniband/hw/hfi1/sysfs.c
> +++ b/drivers/infiniband/hw/hfi1/sysfs.c
> @@ -608,6 +608,11 @@ static const struct sysfs_ops sde_sysfs_ops = {
>  };
>  
>  static struct kobj_type sde_ktype = {
> +	/*
> +	 * Pre-existing: sdma_engine is embedded in dd->per_sdma array
> +	 * rather than freed by kobject_put().
> +	 */
> +	.release = NULL,
>  	.sysfs_ops = &sde_sysfs_ops,
>  };

[Severity: Low]
Does sde_ktype also have the same CONFIG_DEBUG_KOBJECT_RELEASE use-after-free
issue worth noting in this comment?

In the device removal path, hfi1_verbs_unregister_sysfs() calls
kobject_put(&dd->per_sdma[i].kobj) right before remove_one() ->
hfi1_free_devdata() -> sdma_clean() calls kfree(dd->per_sdma).

> diff --git a/drivers/infiniband/hw/usnic/usnic_ib_sysfs.c b/drivers/infiniband/hw/usnic/usnic_ib_sysfs.c
> index fdb63a8fb9974..df0e48070c2ee 100644
> --- a/drivers/infiniband/hw/usnic/usnic_ib_sysfs.c
> +++ b/drivers/infiniband/hw/usnic/usnic_ib_sysfs.c
> @@ -245,6 +245,8 @@ static struct attribute *usnic_ib_qpn_default_attrs[] = {
>  ATTRIBUTE_GROUPS(usnic_ib_qpn_default);
>  
>  static struct kobj_type usnic_ib_qpn_type = {
> +	/* Pre-existing: usnic_ib_qp_grp is embedded in RDMA core-managed struct usnic_ib_qp_grp. */
> +	.release = NULL,
>  	.sysfs_ops = &usnic_ib_qpn_sysfs_ops,
>  	.default_groups = usnic_ib_qpn_default_groups,
>  };

[Severity: Low]
Should this comment on usnic_ib_qpn_type also mention
CONFIG_DEBUG_KOBJECT_RELEASE?

When destroying a QP, ib_destroy_qp_user() calls usnic_ib_destroy_qp() ->
usnic_ib_sysfs_qpn_remove(), which calls kobject_put(&qp_grp->kobj)
immediately before the RDMA core frees the struct usnic_ib_qp_grp allocation.

> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c b/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c
> index 1b644be5fe2ed..40ec750f43155 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c
> @@ -496,6 +496,11 @@ static const struct sysfs_ops manager_sysfs_ops = {
>  };
>  
>  static struct kobj_type manager_ktype = {
> +	/*
> +	 * Pre-existing: mgr->kobj is embedded in static managers[] and
> +	 * zeroed in dss_manager_kobj_uninit().
> +	 */
> +	.release = NULL,
>  	.sysfs_ops = &manager_sysfs_ops,
>  	.default_groups = manager_sysfs_groups,
>  };

[Severity: Low]
Is managers[] actually a static array here, and does this teardown also
corrupt pending delayed cleanup under CONFIG_DEBUG_KOBJECT_RELEASE?

In drivers/video/fbdev/omap2/omapfb/dss/manager.c, managers is dynamically
allocated on the heap in dss_init_overlay_managers() and freed in
dss_uninit_overlay_managers():

static struct omap_overlay_manager *managers;

int dss_init_overlay_managers(void)
{
	int i;

	num_managers = dss_feat_get_num_mgrs();

	managers = kzalloc_objs(struct omap_overlay_manager, num_managers);
	...
}

In addition, dss_manager_kobj_uninit() calls
memset(&mgr->kobj, 0, sizeof(mgr->kobj)) right after kobject_put(&mgr->kobj)
(and dss_uninit_overlay_managers() then calls kfree(managers)), which clobbers
and frees the pending delayed kobject cleanup under
CONFIG_DEBUG_KOBJECT_RELEASE just like display_uninit_sysfs() in
display-sysfs.c.

> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c b/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c
> index 1da4fb1c77b4a..4d333031b18d6 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c
> @@ -429,6 +429,11 @@ static const struct sysfs_ops overlay_sysfs_ops = {
>  };
>  
>  static struct kobj_type overlay_ktype = {
> +	/*
> +	 * Pre-existing: ovl->kobj is embedded in static overlays[];
> +	 * dss_overlay_kobj_uninit() drops the kobject ref.
> +	 */
> +	.release = NULL,
>  	.sysfs_ops = &overlay_sysfs_ops,
>  	.default_groups = overlay_sysfs_groups,
>  };

[Severity: Low]
Similarly, is overlays[] heap-allocated rather than static, with a
use-after-free under CONFIG_DEBUG_KOBJECT_RELEASE?

In drivers/video/fbdev/omap2/omapfb/dss/overlay.c, overlays is allocated via
kzalloc_objs(struct omap_overlay, num_overlays) in dss_init_overlays(), and
dss_uninit_overlays() frees it immediately after dss_overlay_kobj_uninit()
calls kobject_put(&ovl->kobj):

void dss_uninit_overlays(struct platform_device *pdev)
{
	int i;

	for (i = 0; i < num_overlays; ++i) {
		struct omap_overlay *ovl = &overlays[i];
		dss_overlay_kobj_uninit(ovl);
	}

	kfree(overlays);
	overlays = NULL;
	num_overlays = 0;
}

Should the comments on manager_ktype and overlay_ktype describe managers and
overlays as dynamically allocated arrays and note the
CONFIG_DEBUG_KOBJECT_RELEASE hazard as well?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261027223847.652884-1-irogers@google.com?part=9

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/