Re: [PATCH] mm: thp: Fix refcount leak in thpsize_create() error path

[Guangshuo Li <lgs201920130244@gmail.com>]

Hi Lance, Zi,

Thanks for the review and for pointing this out.

You are right — that was my mistake in the changelog wording. After
rechecking the failure path more carefully, I do not think a
use-after-free can actually happen here. The real issue is that the
error path skips the proper kobject cleanup flow, so the problem is
better described as an unbalanced kobject reference / refcount
handling issue rather than a potential UAF.

I will update the commit message accordingly and send a v2 shortly.

Thanks,
Guangshuo

Zi Yan <ziy@nvidia.com> 于2026年4月12日周日 21:33写道：
>
> On 11 Apr 2026, at 23:24, Lance Yang wrote:
>
> > On 2026/4/12 09:49, Zi Yan wrote:
> >> On 11 Apr 2026, at 10:28, Lance Yang wrote:
> >>
> >>> On Sat, Apr 11, 2026 at 02:21:52PM +0800, Guangshuo Li wrote:
> >>>> After kobject_init_and_add(), the lifetime of the embedded struct
> >>>> kobject is expected to be managed through the kobject core reference
> >>>> counting.
> >>>>
> >>>> In thpsize_create(), if kobject_init_and_add() fails, thpsize is freed
> >>>> directly with kfree() rather than releasing the kobject reference with
> >>>> kobject_put(). This may leave the reference count of the embedded struct
> >>>
> >>> Right. As documented for kobject_init_and_add(), once it has been
> >>> called, the error path should go through kobject_put():
> >>>
> >>> /**
> >>>   * kobject_init_and_add() - Initialize a kobject structure and add it to
> >>>   *                          the kobject hierarchy.
> >>> ...
> >>>   *
> >>>   * This function combines the call to kobject_init() and kobject_add().
> >>>   *
> >>>   * If this function returns an error, kobject_put() must be called to
> >>>   * properly clean up the memory associated with the object.  This is the
> >>> ...
> >>>   */
> >>> int kobject_init_and_add(struct kobject *kobj, const struct kobj_type *ktype,
> >>>                      struct kobject *parent, const char *fmt, ...)
> >>>
> >>>> kobject unbalanced, resulting in a refcount leak and potentially leading
> >>>> to a use-after-free.
> >>>
> >>> IIUC, this looks more like wrong kobject lifetime handling and likely a
> >>> leak, not a clear UAF :)
> >>
> >> kobject_put() ends up with calling kobj_type->release(), which is just
> >> kfree(to_thpsize(kobj)), equivalent to kfree(thpsize) in the old code.
> >> IIUC, there is no leak. Let me know if I miss anything.
> >
> > Right, the fix is correct. I was only commenting on the changelog
> > wording, especially:
> >
> > "resulting in a refcount leak and potentially leading to a use-after-free"
> >
> > The old code does skip the required kobject cleanup path, but is
> > a UAF actually possible there?
>
> That is my question too. The original code might not cause any real issue.
>
> Guangshuo, let us know if we get it wrong. Thanks.
>
> >
> > Just a wording nit.
>
>
> --
> Best Regards,
> Yan, Zi